SDSD Projektmodel Kravspecifikation 007d.01 Stamdata Register Infrastrukturprogrammet fase 2 FMKi projektet Dato: 13.12.2010 Version: 1.0 Udarbejdet af: Digital Sundhed Sammenhængende Sundhed i Danmark www.sdsd.dk Islands brygge 39 2300 København S Digital Digital Sundhed Program for infrastruktur og sikkerhed Kravspecifikation for Stamdata register Side 1 af 13
Indholdsfortegnelse Stamdata registre... 3 Indledning... 3 Om kravspecifikationen... 4 Kravenes form... 4 Forudsætninger... 4 Delspecifikation A: Stamdata register på NDP... 5 Delspecifikation B: Service enabling af stamdata... 7 Generelle krav... 9 Leverance og test... 11 Referencer... 12 Dokumenthistorik... 13 Dokumentplacering... 13 Revisionshistorik... 13 Side 2 af 13
Stamdata registre Indledning Stamdataregistret er i dag realiseret som et modul hos Lægemiddelstyrelsen (LMS) der stiller opdaterede og validerede stamdata til rådighed, bl.a. for det Fælles Medicin Kort (FMK), Medicin-IT og Det Danske Vaccineregister (DDV). Stamdataregistret indeholder i sin nuværende form data fra en række registre, bl.a.: CPR-data inkl. Relationer forældre/børn, værge- og myndighedsforhold Oplysninger fra autorisationsregistret Organisatoriske oplysninger fra SOR og SKS Yderregistret Lægemiddelstyrelsens Takst Alle oplysninger fra disse registre udbydes i versionerede udgaver, så også applikationer, der kræver et historisk datagrundlag tilgodeses. Stamdataregistret er udarbejdet således, at det forholdsvist nemt kan udvides med yderligere registre. Der er taget beslutning om at udstille stamdataregistret som en service på den Nationale Service Platform (NSP), med standardiseret adgang til informationer samt et ensartet serviceniveau, idet eksisterende og kommende services på NSP har brug for at kunne tilgå stamdata af sikkerhedsmæssige hensyn (f.eks. Security Token Service-STS og Behandlingsrelationsservicen). Det forventes endvidere, at standardiseret adgang til stamdata på NSP kan indløse arbejdsbesparende potentialer ved at erstatte ofte manuelle og ressourcekrævende opslag i autorisationsregistret og andre registre med automatiske servicekald til stamdata servicen på NSP til gavn både for regionerne og for de centrale myndigheder (f.eks. LMS, SSI og SST). Stamdata servicen skal realiseres i NSP v2 arkitekturen. Denne arkitektur består af en række NSP instanser, der er ens på nær konfiguration, samt en central databærende enhed (National Data Platform). NDP skubber data ud på NSP instanserne gennem en replikeringsmekanisme. For en beskrivelse af NSP version 2 henvises til [NSP v2]. Nærværende kravspecifikation indeholder krav til indsamling af stamdata på NDP platform samt efterfølgende service enabling af stamdata på NSP instanserne. Der bør tages udgangspunkt i det eksisterende stamdata modul hos LMS. Leverandøren skal i sin besvarelse af nærværende kravsspecifikation specificere og begrunde hvorvidt der er tale om portering af kode eller nyudvikling af servicen på NSP. Side 3 af 13
Om kravspecifikationen Dette afsnit forklarer kravenes form og hvordan kravene tænkes at tilgodese kundens forretningsmæssige mål. Kravenes form Kravene er opdelt i kapitler efter deres art. I hvert kapitel er kravene opstillet i afsnit der vedrører en bestemt arbejdsopgave eller emne. Kravene indeholder flg.: Kravnummer eller Optionsnummer Overskrift Beskrivelse (Info) Løsningsforslag (Info) Hyppighed (Info) Verificering (Info) Andre informationer (eksempel, kommentar ) De første tre punkter er obligatoriske og udgør selve kravet. Foruden disse punkter kan kravet foreslå en løsning, redegøre for hyppighed, hvordan kunden har tænkt sig at verificere kravet samt andre oplysninger. Disse oplysninger er ikke en del af kravet, men nogle nyttige informationer til tilbudsgiver/leverandøren, der kan hjælpe eller guide mod den rigtige løsning. Kravene har fortløbende unikke numre og kan således utvetydigt refereres til med deres kravnummer, f.eks. Krav 1 eller K1. Forudsætninger Koordination med LMS aktiviteter for stamdata service forudsættes Aftale om brug af de enkelte registre (hvilke registre må anvendes og under hvilke betingelser) forudsættes etableret Side 4 af 13
Delspecifikation A: Stamdata register på NDP I anden sammenhæng etableres en National Data Platform (NDP) som selvstændig databærende platform, indeholdende en MySQL databaseserver samt replikeringsmekanisme, der muliggør distribution af data til de enkelte NSP instanser. Replikeringen er konfigurerbar således, at man eksempelvis kan konfigurere, hvilke data der skal replikeres. Stamdata registre er omfangsrige og loads kan være ressourcekrævende, specielt de initielle. For ikke at blokere for øvrige services på NSP skal stamdata servicen etableres på NSP på en sådan måde, at ressourcer kan styres og kontrolleres. Nedenstående figur illustrerer principperne. Figur 1: De fuldt optrukne pile fra NDP til registrene repræsenterer servicekald. Gennem disse kald hentes data, dvs. dataflow er modsat pilens retning. De stiplede pile repræsenterer database replikering, hvor data replikeres i pilens retning. Krav 1. Krav 2. Etablering af stamdataregister på NDP Der skal leveres et stamdataregister (en database) på NDP. Databasen skal realiseres i NDP-arkitekturen, ved anvendelse af den MySQL database, som stilles til rådighed på NDP. Database skemaet skal være baseret på tilsvarende skema for stamdataregistret hos LMS, og eventuelle ændringer skal der redegøres og dokumenteres for. Der skal leveres en samlet specifikation af database skemaet i form af ER diagrammer, mv. Mekanismer til opsamling af stamdata Leverandøren skal foreslå forskellige løsninger til indlæsning af stamdataregistre, f.eks. gennem ftp eller servicekald. Leverandøren skal sandsynliggøre, at løsningerne tilsikrer fleksibilitet i forhold til at kunne tilføje eventuelle nye registre på et senere tidspunkt. Leverandøren skal samtidig Side 5 af 13
sandsynliggøre, at løsningerne er robust over for utilgængelighed af dele af stamdatakilderne. Løsningen skal koordineres med tilsvarende funktionalitet hos LMS, og skal som udgangspunkt være en kopi af denne løsning. Eventuelle afvigelser skal dokumenteres og begrundes. Krav 3. Stamdataparser Det skal leveres en parser på NDP s applikationserver, der kan behandle data fra eksterne registre og placere dem i stamdataregistret, på lignende måde som det pt. foregår for det eksisterende stamdataregister hos LMS. Relevante datakilder der skal hentes data fra er begrænset til: - CPR - Autorisationsregistret - SOR - Yderregister - Lægemiddeltaksten - Sikrede - Doseringsforslag Løsningen skal være designet på en sådan måde, at der er taget højde for, at der i fremtiden indhentes data fra nye registre. Leverandøren skal redegøre for, hvorledes dette er imødekommet. Leverandøren kan vælge at portere eksisterende software eller nyudvikle parseren. Mulighederne skal belyses og valg begrundes. Krav 4. Krav 5. Krav 6. Initielt load Det skal leveres et initielt load af data således, at stamdataregistret fra begyndelsen er etableret med stamdata inden det normale flow kan igangsættes. Angivelse af kilde til data i stamdataregistret Løsningen skal give mulighed for, at data i stamdataregistret kan spores tilbage til kilden. Historik for stamdata Løsningen skal indeholde fuld historik på data i stamdataregistret, inklusiv tidsstempler for opdatering af de enkelte registre. Dels for at kunne vurdere om data er gamle og således bør fornyes, dels for at kunne tilgodese applikationer, der har brug for historiske data. Side 6 af 13
Delspecifikation B: Service enabling af stamdata Stamdata skubbes ud på de enkelte NSP instanser gennem den replikeringsmekanisme, der stilles til rådighed på NSP v2. Nærværende delspecifikation omhandler krav til service enabling af stamdata på NSP instanserne. Krav 7. Service enabling af hele registre Stamdataregistre på NSP skal stilles til rådighed for sundhedsvæsnets parter gennem en service enabling. Eksterne aktører (som f.eks. LMS) skal kunne forespørge på stamdata. Der skal leveres metoder til to typer af forespørgsler: - Forespørgsel på ændringer til et stamdata register ( delta, siden sidst der blev overført stamdata til den pågældende aktør) - Forespørgsel på totale registre Løsningsforslag: Sidste type af forespørgsel må gerne implementeres som et særtilfælde af den første type. Servicen, der udstilles, skal implementeres som et SOAP kald i henhold til DGWS, version 1.0.1. på sikkerhedsniveau 3, dvs. med brug af SOSI System IDkort (enten VOCES eller FOCES). Servicen skal rumme mulighed for at angive hvilket register der ønskes returneret fra servicen. Nuværende kilder er begrænset til CPR, SOR, LMS Taksten, SKS, Yderregister, Autorisationsregistret, Sikrede, Doseringsforslag. Servicen skal designes således, at det er muligt at tilføje nye data kilder. Det skal sikres, at kaldende organisation har rettigheder til at modtage ønskede registre. Se også Krav 9. Krav 8. Returnering af registre fra servicen Der er tale om potentielt store mængder af data, der skal returneres fra stamdata servicen. Leverandøren skal tilvejebringe en løsning, der er robust, skalerbar og fleksibel over for potentielt store mængder af data. Leverandøren skal vælge, beskrive og begrunde et egnet XML format til leverance af stamdata, evt. per stamdata register. Løsningsforslag: Det initielle request via DGWS kan bruges til at udveksle en url, hvorved stamdataregistret kan åbne for download af store mængder af Side 7 af 13
data. Der kan tilbydes forskellige protokoller (f.eks. ftp, http) og formater (XML, FastInfoset, JSON) til dette. Paging kan eventuelt benyttes til at dele overførslen op i håndterbare dele. Leverandøren skal begrunde sine valg. Krav 9. Krav 10. Administrationsinterface til håndtering af publikationsrettigheder De enkelte registre (dvs. datakilder), der stilles til rådighed på NSP, kan være underlagt restriktioner, eksempelvis omkring publikation. Der ønskes en løsning, hvorved man kan konfigurere hvilke organisationer, der har adgang til hvilke registre. Det skal således være muligt at kontrollere adgang til servicen på organisations (CVR) niveau. Til dette formål skal der udvikles et simpelt administrationsmodul som kun kan tilgås af operatøren for NSP. I administrationsmodulet skal det være muligt at markere hvilke kilder (registre), der er frit tilgængelige samt hvilke kilder, der kun er begrænset publikationsrettighed til, samt hvilke organisationer, der har lov til at tilgå disse registre. Service enabling af autorisationsregistret Der skal leveres en service på NSP der på givet Navn og CPR nummer som input returnerer tilhørende autorisationskode samt yderligere relevant data fra registret. Side 8 af 13
Generelle krav Krav 11. Krav 12. Krav 13. Krav 14. Krav 15. Krav 16. Krav 17. Krav 18. Overholdelse af operatørkrav Kravene specificeret i [SDSD Operatør] skal overholdes eksplicit. Eventuelle fravigelser fra kravene på grund af manglende relevans eller sammenfald med krav i nærværende kravspecifikation skal begrundes. Overholdelse af krav til teknisk dokumentation Kravene specificeret i [SDSD Teknisk] skal overholdes eksplicit. Eventuelle fravigelser fra kravene på grund af manglende relevans eller sammenfald med krav i nærværende kravspecifikation skal begrundes. Performance Services, der udstilles på NSP som følge af Krav 7 og Krav 10 er ikke kritiske. Løsningen skal derfor kunne håndtere 10 samtidige kald og svartider skal være i overensstemmelse med normal praksis inden for området. De leverede komponenter skal være robust over for en stigende belastning, således at svartiderne og den tidsmæssige spredning af svartiderne ikke forøges nævneværdigt ved stigende belastning. Ved overbelastning skal komponenterne fortsat virke korrekt, hvilket betyder at de funktionelt fungerer, og ikke afleverer forkerte resultater. Overholdelse af dette krav skal dokumenteres, eventuelt som en del af testrapporten der skal udarbejdes i Krav 20. Open Source JAVA komponenter Nærværende kravspecifikations komponenter skal udvikles i JAVA under open source licens i overensstemmelse med anbefalingerne i [SDSD OSS]. Anvendelse af SOSI biblioteket Leverandøren skal benytte egnede SOSI-biblioteker i udviklingen af komponenterne. Såfremt leverandøren afviger fra dette skal der argumenteres herfor. Monitoreringssnitflade Til brug for operatøren af NSP skal leverandøren udstille en monitoreringssnitflade således, at status på alle dele af løsningen (stamdataregistre, parser, replikering, service enabling) kan monitoreres. Monitoreringen skal udarbejdes i overensstemmelse med [SDSD Teknisk]. Log Leverandøren skal som en del af løsningen logge på SLA (Service Level Agreement) niveau såvel som på audit niveau til den centrale log, som beskrevet i [SDSD Teknisk]. Standarder Alle XML formater skal i videst muligt omfang følge de i Den Gode Webservice, version 1.0.1 beskrevne standarder (se [DGWS]), herunder SOAP 1.2, WS-Security, XML-signatur, SAML, osv. Sikkerhedsniveauet for webservices skal være niveau 4, dvs. digitalt signeret id-kort skal anvendes, med mindre lavere sikkerhedsniveauer eksplicit er nævnt i nærværende kravspecifikation. Side 9 af 13
Hvis leverandøren finder det nødvendigt at fravige fra dette, skal det eksplicit bemærkes og begrundes. Side 10 af 13
Leverance og test Krav til form og tidsplan for leverancen beskrives i det følgende. Krav 19. Krav 20. Test af Stamdataregistret Leverandøren skal gennemføre en test af Stamdata Registret, der demonstrerer, at den overholder kravene i nærværende kravspecifikation. Der skal udarbejdes testplan, testsuites, testcases og testdata. Resultatet af testen skal ligeledes dokumenteres. Der skal ydermere gennemføres kode test (unit testing) med minimum 80% coverage. Performancetest Der skal udføres en automatiseret performancetest, der indeholder flg. - En skaleringstest der viser sammenhængen mellem svartider og stigende belastning indtil overbelastningspunktet nås. Endvidere skal skaleringstesten vise spredningen af svartiderne. - En load/stresstest, der identificerer overbelastningspunktet og identificerer hvilke symptomer systemet udviser ved overbelastning og om eller hvornår systemet bryder sammen. Det skal påvises at systemet virker korrekt ved overbelastning, hvilket betyder at den funktionelt fungerer, og ikke afleverer forkerte resultater. - Endurancetest der viser at systemet ikke har ressourcelækager (CPU, RAM) ved længerevarende jævn belastning. Testen planlægges i en testplan og dokumenteres i en testrapport. Den automatiserede test skal kunne afvikles i forbindelse med alle opdateringer af software og hardware. Krav 21. Krav 22. Tidsplan Tilbudsgiver skal vedlægge tidsplan, der i kalendertid angiver mulige starttidspunkter for projektet, varigheden af projektet, samt hvilke personressourcer, der tildeles. Afviklingsmiljøer De udviklede komponenter skal etableres i 3 miljøer. - Et produktionsmiljø - Præproduktionsmiljø - Et testmiljø / udviklermiljø Alle aspekter af komponenten skal kunne testes i præproduktionsmiljøet. Krav 23. Løsningsbeskrivelse Tilbudsgiver skal i forbindelse med aflevering af løsningsbeskrivelse med prisoverslag også levere et estimat på forventet tidsforbrug specificeret på relevante funktionelle delelementer. Side 11 af 13
Referencer SDSD Teknisk SDSD OSS SDSD NSP Note om teknisk dokumentation for arkitekturkomponenter Operatørvurdering og prioritering Note on recommended Open Source Software licenses in Digital Health Denmark Beskrivelse af den Nationale Service Platform, version 1. Dokumentationen er sammenfattet i en række specifikationer. http://arkitektur.sdsd.dk/t wiki/bin/view/servicedes k/arkitekturkomponenter http://arkitektur.sdsd.dk/t wiki/bin/view/operator/ar kitekturkomposslicens Ved henvendelse til SDSD SDSD NSPv2 Kravspecifikation på NSP v2 Ved henvendelse til SDSD Side 12 af 13
Dokumenthistorik Dokumentplacering Kilden til dette dokument vil blive placeret på www.sdsd.dk. Revisionshistorik Revisionsnummer Revisionsdato Oversigt over rettelser Rettet af Rettelser markeret 0.1 30/08-2010 Første udkast SRJ 0.2 16/09-2010 Rettelser efter review SRJ 0.7 20/09-2010 Rettelser efter review SRJ 0.71 28/09-2010 Rettelser efter EDA review SRJ 0.72&0.73 29/10-2010 Rettelser efter møde med sdsd SRJ 0.74 10.11.2010 Rettelser efter review SRJ 0.75 25/11-2010 Rettelser efter sdsd review. SRJ Tilføjelse af doseringsforslag til krav 4 0.76 10/12-2010 Omskrivelse efter sdsd review SRJ og beslutning om central databærende platform 0.77 13/12-2010 CHE review SRJ 1.0 13/12-2010 SRJ Side 13 af 13