NSP Testmiljøer. Dato: Version: 1.0

Transkript

1 NSP Testmiljøer National Sundheds-IT - Sammenhængende test-systemer i NSI-regi Islandsbrygge 39 Dato: Version: 1.0 Udarbejdet af: NSI 2300 København S Resumé Den nationale serviceplatform anvendes af regioner og andre aktører. Nærværende notat opsummerer regionernes ønsker og behov i forhold til sammenhængende testsystemer i NSI-regi, og skitserer et antal centrale testmiljøer, der fremadrettet vil opfylde disse ønsker og behov. Version Ansvarlig Kommentar 0.4 LAE 0.5 CHE Uddybet udgave på basis af arbejdsmøder og feedback fra alle parter, JRI review. 0.6 CHE Præciseringer og justeringer efter møde torsdag d. 21/9 mellem NSI og regionerne. 0.7 CHE Præciseringer efter regionernes tilbagemelding per 01/ CHE Konsekvensrettelse: PREPROD ændret til PRODTEST 1.0 LAE Side 1

2 Indholdsfortegnelse 1 Sammenhængende test- systemer i NSI- regi Baggrund Krav og ønsker fra regionerne Flere testsystemer Flere testlæger og testpatienter Realistiske testdata End- to- end test Forslag til fremtidige test- og uddannelsesmiljøer Afgrænsninger Opsummering og gruppering af ønsker til fælles miljøer Fælles nationale test- og uddannelsesmiljøer Overordnet arkitektur for hvert miljø Miljøer er selvstændige og indbyrdes uafhængige Miljøer tilgås gennem NSP enten som udstillet af miljøet eller lokalt Versionering af services og snitflader Krav til serviceleverandører Separat service-instans til hvert fælles miljø Funktionalitet til ind- og udlæsning af kliniske data Brug af fælles stamdata Udvidelse af testdatagrundlaget og administration af data Regionerne udsteder selv testcertifikater (Digital Signatur) SLA Fælles spilleregler Proces, Økonomi og leverance Bevægelse fra nuværende til ønsket løsning Økonomi Appendiks A: Miljøbeskrivelser for fælles miljøer Fælles for alle miljøer TEST1: Dynamisk testmiljø TEST2: Miljø med stabile, kommende versioner PRODTEST: Produktionslignende UDD: Uddannelse Appendix B: Sammenhængende testdatasæt Automatiserede scripts til generering af testdata Mulighed for ind- og udlæsning af kliniske data Kliniske skabeloner Lokal og national anvendelse af kliniske skabeloner Oprettelse og genetablering af en ønsket klinisk tilstand Skabeloner tilbudt af NSI Særlige forhold Omfanget af den centrale styring af sammenhængende testdatasæt Side 2

3 1 Sammenhængende test-systemer i NSI-regi 1.1 Baggrund NSI har gennem en række projekter etableret en portefølje af systemer, som udstiller services til sundhedsvæsnets parter FMK, DDV, NSP, NPI m.fl. Hidtil har opgaven med at udstille testsystemer ligget under de enkelte projekter eller programmer, således at FMK-programmet f.eks. leverer testmuligheder til FMK brugere. Da et af NSI's formål er at sikre en sammenhæng i forbindelse med digitaliseringen af sundhedssektoren, er alle NSI produkter en del af en sammenhængende serviceorienteret arkitektur. Det betyder at man i forskellige services bygger på samme fundament, og at services i flere tilfælde gør brug af andres services. I relation til test betyder dette, at det ofte ikke er muligt at teste en enkelt service isoleret, men at man skal have et integreret miljø, hvor der er testudgaver af alle de services, der anvendes af den service man egentligt ønsker at teste op imod. For at en region kan teste FMK skal der f.eks. som minimum være adgang til en FMK-test server, en test-nsp (eller en NIAB), en test-sts og en test-pem server. Ud over de konkrete services, der skal være tilgængelige, er de fleste services også afhængige af stamdata, der skal være sammenhængende på tværs af test-systemerne. Hvis man igen tager FMK eksempel skal man for at en test-læge kan slå en testpatient op på FMK også sikre at test-lægen har et test-autorisations-id (som skal findes i et test-autorisations-register) og at både testlæge og testpatients cpr-nummer findes i test-cpr-registeret. Yderligere skal koblingen mellem testpatienten og denne egen (test-)praktiserende læge, findes i et testregister over sikrede. For kunne levere ordentlige test-systemer, skal der således både være et sammenhængende setup af test-systemer, og en test-verden med et sammenhængende sæt af testlæger, testpatienter og test stamdata-baser. Samtidig er det næsten umuligt for anvenderne af test-systemerne at forstå alle disse enkelt komponenters betydning, hvilket betyder at brugerne med den nuværende organisering, har meget svært ved at få tingene til virke, da de ikke ved hvor de skal henvende sig dels for at få adgang til data, dels når der opstår fejl i eller inkonsistens imellem testsystemernes data. Opgaven med at definere, bygge og vedligeholde og supportere et sådant test-setup bør derfor været et fælles NSI anliggende, og ansvaret for al ekstern test (test set fra brugernes side) bør derfor flyttes ud af projekterne og ind i en central funktion. Dette notat har til formål at beskrive et sæt rimelige krav til, hvad en sådan central funktion skal levere, for at eksempelvis regionerne vil kunne gennemføre passende test af deres EPJ-systemers integration med services i NSI's portefølje. Side 3

4 2 Krav og ønsker fra regionerne Specielt regionernes udrulning af FMK vanskeliggøres af begrænsning i det nuværende setup. Udfordringerne rækker ud over udrulningsperioden, da et solidt test-setup også er en forudsætning for såvel normal håndtering af de løbende releases af regionernes EPJsystemer, som løbende test, fejlfinding og uddannelse. De væsentligste behov som nævnes af regionerne er: 1. Adgang til flere test-systemer end de 2 der er i dag 2. Behov for mange flere testpatienter og test-læger per region 3. Mulighed for vedligehold af regionale test- og uddannelsesdata (oprettelse, ændring og nulstilling ) 4. End-to-End test med andre parter/systemer i sundhedssektoren 2.1 Flere testsystemer Regionerne ønsker at man nationalt stiller 4 centrale testsystemer til rådighed. Region H har lavet nedenstående skitse af de ønskede miljøer, der opfylder Region H s konkrete behov. Det er oplagt at lade sig inspirere af dette setup. Side 4

5 De 4 nationale systemer tænkes af Region H anvendt til følgende typer test: System Test1 Test2 UDD PRODTEST 1 Funktion Installationstest samt test af nye releases fra leverandører, der leverer komponenter til NSP. Miljøet anvendes derudover til test af tekniske og driftsorienterede installationer. Regressionstest af releases der snart skal i produktion. Test 2 miljøet er tænkt som det primære testmiljø, hvor leverancerne i eget EPJ-system intensivt kan testes op mod eventuelle leverancer fra FMK. Uddannelse af brugere. Det er et væsentligt krav til dette miljø, at miljøet (dvs. data) skal kunne nulstilles ( flushes ), således at uddannelsesforløb kan gennemføres på samme datagrundlag. Et produktionslignende miljø, hvor der kan gennemføres test i forbindelse med f.eks. incidents og fejlsøgning. Med produktionslignende menes samme versioner af services og komponenter som i produktion. Hardware og datamængder er dimensioneret til test med den performance af systemet, som dette indebærer. Bemærkninger: ñ I dag kan regionerne have lokale NiaB som er koblet op mod de respektive regioners FMK-test servere, som er placeret hos den centrale FMK driftsleverandør (Neitc, red.). ñ Hvis regionerne fremover ønsker at bruge fælles testsystemer i forhold til egne FMKtest servere, er det vigtigt at bemærke, at regionerne skal være enige om opdateringspolitikkerne for f.eks. Taksten på test-systemerne. Det kan betyder at regionerne selv skal følge samme politikker for interne opdateringer af EPJ-test og uddannelsessystemer. ñ Stresstest håndteres ved en aftale mellem anvenderne af systemerne (regioner, LPS, kommuner mv.), således at det bliver muligt at reservere prodtest miljøet til dette formål på bestemte tidspunkter. 2.2 Flere testlæger og testpatienter I det nuværende setup får hver region tildelt 20 testpatienter og 5 testlæger. Dette er for lidt til organisationer af regionernes størrelse, da det er næsten umuligt at administrere, hvem der anvender hvilket testpatienter på hvilket tidspunkt endnu værre er det i undervisningssituationer, hvor mange kursus-deltagere skal sidde og arbejde på forskellige testpatienter samtidigt. Dette antal skal derfor øges betragteligt. I forhold til at op-skalere antallet af testpatienterne, så består opgaven i at udvælge cprintervaller af passende størrelse, samt at udvide test-cpr databasen med stamdata for de testpatienter, man ønsker at anvende. Det er muligvis også nødvendigt at udvide andre 1 Bemærk at miljøet i det oprindelige materiale fra RH er navngivet PREPROD. Dette er ændret, da PRE- PROD er et navn, der typisk knyttes til ekstremt produktionsnære miljøer (som f.eks. de eksisterende PREPROD miljøer for hhv. NSP og FMK), der har andre karakteristika end nærværende PRODTEST miljø (jævnfør beskrivelsen af miljøet i tabellen). Side 5

6 test stamdata registre med information for disse test-personer. Dette kunne f.eks. være Sikrede, der indeholder en kobling til testpatientens praktiserende læge. Opgaven med at oprette flere test-læger er en større opgave, idet der, udover at sikre at test-lægerne findes i CPR, også skal sikres at der oprettes digital-signatur på disse testlæger. Test-lægerne skal endvidere findes i test-autorisationsregisteret, samt evt. i testyder-register og test-sikrede. 2.3 Realistiske testdata Det er afgørende for ordentligt test at der findes realistiske testdata. Det skal således sikres at testpatienter i FMK-testsystemerne har realistisk medicinkort, med virkelighedstro ordinationer, recepter og effektueringer. Ud over disse data, skal det være muligt for regionerne selv at oprette og vedligeholde testdata. Det skal ligeledes være muligt at lave et snapshot af et sæt testdata, og senere kunne reetablere ( nulstille ) testpatienterne til denne tilstand. Dette er f.eks. for at kunne gentage test eller uddannelsesforløb. 2.4 End-to-end test Testpatienter i de fælles test-systemer skal kunne deles mellem forskellige systemleverandører, således at man kan lave end-to-end mellem f.eks. et EPJ-system og et praksis-system. En sådan end-to-end test vil selvfølgelig indebære at man enten selv har adgang til begge systemer, eller har en dialog med den anden part. Side 6

7 3 Forslag til fremtidige test- og uddannelsesmiljøer I det foregående afsnit er regionernes behov og ønsker kort skitseret. Nærværende afsnit beskriver et forslag til fremtidige test- og uddannelsesmiljøer, der opfylder ønsker og behov som beskrevet af regionerne. De nationale miljøer skal fremadrettet understøtte aktørerne i forhold til en række ønsker og behov vedrørende test- og uddannelsesforløb. Regionerne og NSI har derfor i fællesskab gennemført et afdæknings- og analysearbejde i et intensivt projektforløb første halvdel af september 2012, med det formål at afdække og præcisere regionernes behov og ønsker til fælles miljøer til anvendelse af parterne i sundhedssektoren. Resultatet af dette arbejde er nærværende notat. Det bemærkes, at processen primært har været orienteret mod regionernes behov, men at andre parters (dvs. kommunerne og de privatpraktiserende læger) interesser så vidt muligt er tænkt ind i resultatet. Analysearbejdet har dækket en bred vifte af områder, der har indflydelse på anvendelsesmulighederne af de fælles miljøer, og regionernes ønsker og behov er indarbejdet i løsningsforslaget. 3.1 Afgrænsninger I analysearbejdet er der afdækket en lang række ønsker og behov, der stort set alle kan opfyldes i den foreslåede løsning. Følgende emner er blevet identificeret som potentielle problemstillinger, der ikke håndteres i dette projekt, og som det anbefales at der tages stilling til i anden sammenhæng: Emne Receptserveren ( løse recepter ) Anvendelse af produktions Digital Signatur i test Beskrivelse Det blev meget tidligt i projektforløbet konstateret, at receptserveren har nogle væsentlige begrænsninger i forhold til både de eksisterende testmiljøer og også fremadrettet. Konkret er udfordringen, at udbyderen kun tilbyder 2 testmiljøer for Receptserveren, dels at administration af testdata er en manuel, og dermed både tidskrævende og bekostning. Som en del af projektet afdækkes de økonomiske og tidsmæssige rammer for etablering af både testmiljøer og passende struktur for administration af testdata. Det vil være teknisk muligt at anvende medarbejdernes rigtige Digitale Signatur i testog uddannelsesmiljøerne. Der er en række administrative og juridiske aspekter, der i givet fald skal afklares. I nærværende projekt er afklaringen af dette Side 7

8 ikke inkluderet. Det bemærkes at der sandsynligvis vil være ikke ubetydelige økonomiske konsekvenser forbundet med at hærde de udstillede miljøer til de forventede krav. 3.2 Opsummering og gruppering af ønsker til fælles miljøer I analysearbejdet udført i fællesskab med regionerne er der fremkommet en række overordnede ønsker til testmiljøer. Ønskerne kan grupperes som følger på basis af regionernes input: Udvikling og integration - Test af nye installationer - Test af nye integrationer til andre miljøer såsom medicinmoduler m.v. - Test af ændringer til scripts af nye databaseændringer - Test af nye driftsrelaterede, systemrelaterede issues i dette miljø - Prætest med test af den/de første iterationer af EPJ-leverandørers ændringer i forbindelse med FMK - Test af nye leverancer fra NSI vedr. ændringer til central FMK - Test af senere iterationer af EPJ-leverandørers ændringer i forbindelse med FMK. De mere produktionsnære, stabile og tidskrævende leverancer af EPJ/FMK-løsningerne, som kræver grundigere test Uddannelse - Uddannelse af nye brugere i FMK. Formentlig oftest i forbindelse med hver regionernes uddannelse i egne EPJ-systemer og disses interaktion med FMK. Fejlfinding og produktionsklargørelse - Miljø til fejlfinding af produktionsrelaterede fejl, hvor man kan foretage sig ændringer og support, som man ikke må i et produktionsmiljø 3.3 Fælles nationale test- og uddannelsesmiljøer Med udgangspunkt i regionernes ønsker og behov er der skitseret følgende fælles testmiljøer, der tilsammen vurderes at opfylde behovene. Det bemærkes, at miljøerne er opbygget ens rent it-arkitekturmæssigt og i forhold til hvilke komponenter og services der udstilles, og at forskellene i forhold til teknik mellem miljøerne alene er konfiguration af services og hvilke versioner der udstilles, samt styring af hvorledes miljøerne opdateres i forhold til dynamiske stamdata. Derudover er der en administrativ forskel imellem miljøerne i forhold til det erklærede formål med miljøerne, samt hvilke SLA-krav, der stilles. Miljøerne er kort beskrevet nedenfor, og for yderligere detaljer henvises der til Appendiks A, hvor miljøerne er beskrevet dybere, og hvor formål og grundvilkår for de enkelte miljøer gennemgås. NSI varetager den administrative styring af versioner i de enkelte miljøer, der er underlagt stram versionsstyring. 2 2 For TEST1 gælder lidt løsere styring af versionerne, da miljøet er dynamisk af karakter, men der fastholdes en central versionsstyring desuagtet. Side 8

9 End-to-end test foretages i de fælles testmiljøer, da miljøerne er fælles, og der ikke er indført tekniske restriktioner i forhold til anvendelsen af de udstillede services. Testforløb kan derfor aftales indbyrdes mellem parterne (f.eks. end-to-end test mellem flere regioner og LPS systemer). - TEST1 o Et dynamisk, ad hoc anvenderorienteret testmiljø, hvor komponentleverandører til NSP og nationale services kan udstille meget tidlige versioner af snitflader med det formål at gennemføre afklarende, tværgående testforløb - TEST2 o Et stabilt Testmiljø, hvor der kan testes mod kvalitetssikrede, kommende services og komponenter og tilhørende snitflader. - - PRODTEST o UDD o Et Produktionslignende testmiljø, der er konfigureret som produktionsmiljøet mht. versioner af komponenter og services, og som giver mulighed for fejlfinding af fejl fundet i produktion samt sikring af kvaliteten af anvendernes egne leverancer. Et Uddannelsesmiljø, der adskiller sig fra det produktionslignende testmiljø i forhold til dynamiske stamdata, der her kun opdateres efter aftale og ikke automatisk som i produktion. De foreslåede miljøer kan anvendes fra de lokale miljøer efter behov som illustreret på Figur 1 nedenfor. Hver aktør kan mappe testbehov for egne miljøer op mod de fælles miljøers muligheder, og resultatet af mapningen afgør koblingen mellem lokale miljøer og de fælles miljøer. Lokalt testmiljø (f.eks. EPJ) Lokalt testmiljø (f.eks. EPJ) Lokalt uddannelsesmiljø Lokalt præprodmiljø TEST1 TEST2 UDD PRODTEST Figur 1 Et eksempel på hvordan en region kan anvende de fælles miljøer fra egne lokale test- og uddannelsesmiljøer. 3.4 Overordnet arkitektur for hvert miljø Den generelle tekniske arkitektur er modelleret over de eksisterende muligheder for miljøer som de i dag stilles til rådighed dels gennem FMK-projektet, med en NSP-instans og et bagvedliggende FMK-miljø (herunder FMK Online), dels det eksisterende centrale testmiljø Fællestest, der udstilles af NSP-operatøren. Der introduceres derfor ikke nye komponenter i forhold til de eksisterende testmiljøer (dog er der skærpede krav til serviceleverandører i forhold til kliniske testdata, jævnfør afsnit 3.4.3). Side 9

10 Fælles miljø FMK DDV Bagvedliggende* services* SDM STS NSP*komponenter* og*services* Figur 2 Hvert miljø består af bagvedliggende services (pt. alene FMK og FMK online, men med andre services på vej, f.eks. DDV), og anvendelse af miljøet foregår gennem en NSP-instans. Et fælles miljø består som illustreret på Figur 2 af en NSP-instans, der udstilles centralt af NSI, samt bagvedliggende services. I skrivende stund er det alene FMK, der tilbyder miljøer til dette formål, men arkitekturen er bygget til at kunne rumme ikke blot FMK, men også andre bagvedliggende services Miljøer er selvstændige og indbyrdes uafhængige Når et miljø etableres, etableres der også selvstændige installationer af de tilhørende komponenter og services. I praksis betyder det, at der ikke deles data på tværs af miljøerne, og at hvert enkelt miljø konfigureres uafhængigt af de andre. TEST1 TEST2 UDD PRODTEST Figur 3 De foreslåede miljøer er separate, og tilgås gennem de NSP-instanser, der udstilles i hvert enkelt miljø. Data deles ikke mellem miljøerne, og der er vandtætte skodder mellem hvert miljø Miljøer tilgås gennem NSP enten som udstillet af miljøet eller lokalt I produktion giver NSP-arkitekturen mulighed for at regioner og andre parter kan have en fysisk NSP-instans installeret i eget hostingmiljø i form af en såkaldt dnsp (hvor d står for decentral ). Tilsvarende giver arkitekturen mulighed for at parter uden ønske om eller mulighed for at have egen NSP-instans kan anvende en såkaldt cnsp (hvor c står for central ). cnsp er i produktionsmiljøet hostet af NSP-driftsleverandøren. Side 10

11 Fælles miljø FMK cnsp dnsp SDM STS SDM STS Figur 4 Hvert miljø udstiller to varianter af NSP-snitfladen til anvendelse af services og komponenter dermed kan miljøerne benyttes af både regioner, kommuner og lægepraksissystemer. I de fælles miljøer er der mulighed for at anvende både en cnsp og en dnsp, idet miljøerne udstiller begge instanser. Det er endvidere muligt at få en dnsp installeret i eget servermiljø, hvis ikke en centralt placeret decentral NSP opfylder regionens behov Versionering af services og snitflader Som i produktionsmiljøet er services og snitflader versionerede, og der udstilles ofte flere versioner af samme snitflade. Anvendere vælger selv hvilken version af en given service eller snitflade, de ønsker at kalde. Versionering af services og snitflader er en vigtig egenskab ved miljøerne, idet den giver forskellige anvendere af miljøerne mulighed for at teste eller anvende nøjagtig den version, de har brug for i en given sammenhæng, uden at det påvirker andre anvendere af miljøerne. I TEST1 er der mulighed for at afprøve nye og relativt utestede muligheder, og derfor er TEST1 stedet, hvor parterne i fællesskab trykprøver nye versioner. I TEST2 og PRODTEST er miljøerne stabile, og der er stram versionsstyring. 3.5 Krav til serviceleverandører Serviceleverandører, der udstiller funktionalitet til brug gennem NSP, og som stiller testmiljøer til rådighed, skal opfylde en række krav for at passe ind i de fælles miljøer Separat service-instans til hvert fælles miljø Serviceleverandører skal stille et miljø til rådighed til brug for hvert af de fælles miljøer. Instansen skal være uafhængig af andre instanser af samme service, og data må ikke deles på tværs af instanserne. Som beskrevet i afsnit 3.1 vedrørende afgrænsninger er der her et kendt udestående med Receptserveren, der kun udstiller to testmiljøer, og hvor det pt. ikke er muligt at få oprettet yderligere miljøer Funktionalitet til ind- og udlæsning af kliniske data Serviceleverandører udvide deres funktionalitet med to metoder til brug i testøjemed: 3 Konceptet med en centralt placeret dnsp kan virke selvmodsigende, men formålet er at stille en dnsp-snitflade til rådighed i testøjemed uden at kræve at hver enkelt region skal have en NSP-instans til hvert miljø. Side 11

12 1. Dump funktion, som man kan kalde med en liste af CPR-numre. Der returneres en XML-struktur, der for hvert CPR-nummer i listen indeholder den samlede mængde (kliniske) data for CPR-nummeret. 2. Restore funktion, som man kan kalde med en XML-struktur, der indeholder den samlede mængde data for et eller flere CPR-numre. For hvert CPR-nummer etableres den "FMK-tilstand" der er repræsenteret i XML-strukturen. Eksisterende data for CPR-nummeret slettes forud, således at "FMK-tilstanden" er nøjagtig som ved kald til Dump. Formatet af XML-strukturen er ens i de to metoder, og skal dokumenteres af serviceleverandøren. Formålet er at give administratorer i et testmiljø mulighed for dels at tage et "snapshot" af de kliniske data for en given testpatient (eller liste af testpatienter), dels at gøre det muligt at genetablere disse snapshots. Restore- Dump- FMK FMK$sni(lade- Figur 5 FMK (og kommende services) udvides med to nye snitflader til testformål: Dump og Restore, der anvendes til at ind- og udlæse kliniske data. Det bemærkes, at der derudover er ønske om at tredjepart skal kunne manipulere de genererede snapshots og dermed justere kliniske data udenfor rammerne af den udstillede service, dels at tredjepart skal kunne generere dumps som skal kunne indlæses af servicen. Dette medfører skærpede krav til validering af indlæsningen (dog alene validering af at data overholder servicens regler, ikke om der er kliniske fejl i data). Af sikkerhedshensyn bør Restore snitfladen ikke udstilles i produktionsmiljøet. I alle øvrige miljøer vil der derimod være stor gevinst forbundet med muligheden for at kunne tage et snapshot i ét miljø og efterfølgende indlæse det i et andet. En serviceleverandør skal således sikre at Restore snitfladen kan konfigureres ud af produktionsmiljøet Brug af fælles stamdata I det omfang en service gør brug af data udstillet på NSP, skal servicen anvende en af de to NSP er, der er tilknyttet et givet testmiljø. Dette krav sikrer, at der bevares sammenhæng i testdata, også på tværs af de bagvedliggende services. 3.6 Udvidelse af testdatagrundlaget og administration af data I de eksisterende testmiljøer tilbydes et meget begrænset testdatasæt, hvor hver enkelt anvender får tildelt et mindre antal cpr-numre, brugere og testcertifikater. Dette har begrænset anvendeligheden af testmiljøerne, og fremadrettet er der derfor behov for dels et udbygget testdatasæt (som udgangspunkt flere hundrede cpr-numre per anvender), dels mulighed for at udføre detaljeret administration af testdatasættet. Fremover bliver det muligt at udvide testdatasættet, så det afspejler et bredt udsnit af befolkningen (f.eks. i forhold til køn, alder, fødselsdato, kronikere mv.). Der vil være services til Side 12

13 rådighed, således at de enkelte regioner selv kan lave deres testdatasæt. Disse services vil for den enkelte region give mulighed for at lave særlige testdata (f.eks tilladelsespræparater, forskningspræparater mv.). Der vil ligeledes blive mulighed for forskellige roller (testlæger, testsygeplejersker mv.). Med et stort testdatasæt bliver det muligt at lave en administrativ opdeling af data til brug i forskellige sammenhænge, og på den måde anvende det samme testmiljø til flere formål parallelt, f.eks. både regressionstest og uddannelse. Administrationen foretages af den enkelte aktør i miljøet, og NSI s rolle i forhold til administration af testdata er derfor begrænset til at sikre, at der ikke er sammenfald af cpr-numre. Med en udbygget administrationssnitflade skal det være muligt at tilpasse, gemme og nulstille et udvalgt område af testdatasættet, og dermed genbruge området til f.eks. uddannelsesformål (afholdelse af kursusforløb på samme sæt af cpr-numre hver gang), eller afvikle et sæt standard test i forbindelse med en ny release. I de fælles miljøer er der mulighed for både overordnet og detaljeret administration af testdata, herunder nulstilling og tilbagestilling til tidligere gemt tilstand af dele af data, samt udveksling af testdata på tværs af aktørerne (til bl.a. end-2-end test formål). Testdata er principielt opdelt i stamdata og kliniske data, og beskrives i overordnede termer i de følgende afsnit. For en grundigere beskrivelse henvises til Appendiks B. Fælles miljø Kliniske(data( FMK DDV Sta-ske(stamdata( Dynamiske(stamdata( SDM STS Figur 6 - De kliniske data hører til i de bagvedliggende systemer. De statiske og dynamiske stamdata fastholdes i stamdataservicen (SDM) på NSP. I produktionsmiljøet opsamler NSP en stamdata fra en række kilder og anvender data både til stamdataservicen og til intern brug i forhold til sikkerhedskomponenterne på NSP. I de fælles miljøer er stamdata opdelt i statiske stamdata (f.eks. CPR-oplysninger og autorisationsid er), der genereres af et automatiseret script, og dynamiske stamdata (f.eks. SOR og SKS), der leveres af eksterne kilder. Det konfigureres for hvert enkelt miljø, hvordan de dynamiske stamdata opdateres. De fælles miljøer og produktionsmiljøet har identisk opførsel i forhold til kliniske data, idet disse vedligeholdes i de nationale services, der udstilles gennem NSP. Der er dog den forskel, at det i de fælles miljøer er muligt at ind- og udlæse kliniske data gennem en særlig administrationssnitflade, og på den måde på simpel og effektiv vis etablere og genetablere kendte tilstande for data. Se evt. afsnit for yderligere detaljer. Side 13

14 3.7 Regionerne udsteder selv testcertifikater (Digital Signatur) I produktionsmiljøet anvender klinikere og andre brugere (herunder it-systemer) digital signatur i form af medarbejdersignatur (og systemcertifikater) for at autentificere sig overfor nationale services. I de fælles testmiljøer anvendes der også digital signatur, men til forskel fra produktionsmiljøerne anvendes der testcertifikater. Rammerne for udstedelse og brug af testcertifikater er beskrevet af OCES-operatøren (læs evt. mere her, hvor OCES-operatøren har beskrevet konceptet i et letlæseligt produktblad: _OCES_LRA_testsystem.pdf). Det er dermed muligt for aktører, der har en Test-LRA funktion, at udstede og administrere testcertifikater til brug i de enkelte miljøer. 3.8 SLA Som i produktionsmiljøet tilstræbes der en éntydig SLA per miljø, og der lægges op til at det er samme support-funktion, der varetager henvendelser fra brugere af de nye miljøer. 3.9 Fælles spilleregler Med anvendelsen af fælles testmiljøer introduceres en lang række afhængigheder på tværs af regionerne (og andre anvendere af testmiljøerne). Der er et ønske om at afhængighederne så vidt muligt skal håndteres organisatorisk gennem udarbejdelsen af et sæt fælles spilleregler. Nærværende projekt leverer ikke disse regler, men lægger op til at de udarbejdes af regionerne, eventuelt i samarbejde med NSI og andre aktører (f.eks. repræsentanter for kommunerne og LPS). Spillereglerne udarbejdes som et led i forberedelsen til at tage de fælles testmiljøer i brug. Reglerne kan indeholde regulering af f.eks. - Hver parts udarbejdelse af et sæt udstillingspatienter, der illustrerer gyldige særheder i parternes systemer (f.eks. komplekse ordinationer, langvarige behandlingsforløb, osv.) - Gensidig varsling ved planlagte, resursekrævende testforløb (der kan forstyrre andres brug af et givet testmiljø) - Brug af andre parters testdata, f.eks. til end-2-end testforløb - Fælles krav til konfiguration af de forskellige testmiljøer (konfiguration af komponenterne i testmiljøet, f.eks. STS og GW) Listen er ikke udtømmende og er alene tænkt som inspiration til det videre arbejde. Side 14

15 4 Proces, Økonomi og leverance Hovedparten af opgaverne forbundet med dels at etablere de fælles testmiljøer, dels at fastlægge rammerne for brugen af miljøerne, ligger hos tre parter, nemlig NSP-operatøren, FMK-leverandøren samt regionerne. 4.1 Bevægelse fra nuværende til ønsket løsning Der skal udføres et stykke arbejde for at komme fra den nuværende situation til den ønskede løsning. Opgaverne fordeler sig som følger: NSP-operatøren - Udviklingsaktivitet: Udvidelse af eksisterende testdatascripts til håndtering af kliniske data og skabeloner - Etablering af supportfunktion til administration af CPR-numre og afvikling af testdatascripts i de enkelte miljøer - Udvidelse af eksisterende NSP supportfunktion til at kunne håndtere henvendelser vedrørende de nye miljøer - Udviklingsaktivitet: Etablering af funktionalitet til udstilling og administration af de to nye service-snitflader (ind- og udlæsning af kliniske data) - Dokumentation af de nye muligheder for test og uddannelse, både teknisk og anvenderorienteret - Oprettelse af de fire miljøer på NSP-siden FMK-leverandøren - Implementering af ind- og udlæsning af kliniske data - Udviklingsaktivitet: Hærdning af eksisterende FMK testmiljø-arkitektur til at kunne håndtere mange flere brugere end i dag (og de forventede SLA-krav) - Oprettelse af de fire miljøer på FMK-siden Regionerne - Udarbejdelse af fælles spilleregler - Specifikation af SLA til de forskellige miljøer - Sikring af at de respektive SDN opkoblinger er tilstrækkelige. Den ekstra belastning på SDN ved normal brug af UDD og PRODTEST vurderes at være marginal. I samarbejde mellem parterne - Overførsel af eksisterende testdata (hvis ønsket) til nye miljøer Side 15

16 Opgaverne forløber i store træk parallelt, men der er dog visse indbyrdes afhængigheder, som illustreret på nedenstående gantdiagram. 4.2 Økonomi Der er indhentet en række estimater for dels etableringen af den ønskede løsning, dels den efterfølgende drift. Økonomidrøftelser omkring etablering af testmiljø og den efterfølgende drift og vedligehold varetages af ledelsen i DR og NSI. Side 16

17 5 Appendiks A: Miljøbeskrivelser for fælles miljøer I dette appendiks gennemgås de miljøer, der er beskrevet i afsnit 3.3, men i yderligere detaljer. 5.1 Fælles for alle miljøer - Alle miljøer består af en fælles snitflade (udstillet gennem en NSP hos NSI), stamdata, kliniske data samt bagvedliggende services (pt. alene FMK). Fælles miljø FMK cnsp dnsp SDM STS SDM STS Figur 7 Hvert miljø består af bagvedliggende services samt to NSP-instanser. Hver NSP-instans peger på de bagvedliggende services (her er kun illustreret FMK) Alle miljøer stilles til rådighed for anvenderne gennem hhv. en cnsp og en dnsp. Der vil i første omgang alene blive stillet NSP-instanser til rådighed efter behov, dvs. fokus på dnsp, da det er regionerne, der er første anvendere af miljøerne. De udstillede miljøer er ikke fuldstændig komplette, da NSP arkitekturen i testøjemed indeholder udvalgte dele af den bagvedliggende dataopsamlings- og distributionsfunktion (DoDi). Dette har alene konsekvens i forhold til dynamiske stamdata, herunder muligheden for cpr-abonnementer, der i testmiljøerne er statiske, samt behandlingsrelationsservicen. Alle snitflader er tilgængelige, men ikke alle snitflader giver dynamiske svar. Det er en forudsætning for forudsigelighed i forhold til data, at alle parter respekterer opdelingen i forhold til ejerskab af CPR-numre, og at man alene anvender andre parters CPR-numre efter aftale. Der er en sikring af snitfladerne til indlæsning af testdata, således at en aktør kun kan foretage maskinel indlæsning af testpatienter for cprnumre ejet af aktøren. Formålet som beskrevet for hver enkelt miljø er en hensigtserklæring med miljøet. Regionerne udarbejder som de første anvendere et sæt spilleregler, der regulerer parternes adfærd i de enkelte miljøer, udover de tekniske krav stillet af NSI. Spillereglerne opretholdes ikke af tekniske foranstaltninger. Reservation af et miljø til særlig anvendelse i et tidsrum, f.eks. afvikling af stresstest, aftales indbyrdes mellem parterne og bør være reguleret af de fælles spilleregler. Side 17

18 - - De fælles miljøer er opstillet på basis af de overordnede ønsker og behov, der er kommet fra regionerne i forhold til test og uddannelse. De enkelte regioner har forskellige testtilgange og navngiver deres egne testmiljøer på forskellig vis. De fælles miljøer er derfor karakteriserede gennem dels en formålserklæring, dels et forslag om hvilke grundvilkår, der skal gælde for anvendelsen. Det er dermed op til de enkelte regioner at mappe de fælles miljøer til deres egne miljøer, og det understreges at det er muligt at anvende et af de fælles miljøer fra flere lokale miljøer. Alle snitflader er versionerede, og snitflader ændrer ikke opførsel som følge af at der kommer nye snitflader til. Gamle snitflader stilles til rådighed tilsvarende hvad der er til rådighed i produktionsmiljøet, dvs. når en version af en snitflade udgår i produktionsmiljøet, udgår den også i de andre miljøer. 5.2 TEST1: Dynamisk testmiljø Formål Formålet er todelt: Dels tidlig afprøvning af tværgående aspekter, dels fejlrettelse i eksisterende (produktions)versioner: Tidlig anvenderafprøvning af funktionalitet, både fra NSI (dvs. NSP komponenter og bagvedliggende services som FMK, men også andre aktørers services fremover, f.eks. hvis LPR eller SSR enabler deres services på et tidspunkt). Nationale services udvider typisk deres funktionalitet som følge af krav fra en eller flere anvendere. Dette miljø giver mulighed for at koordinere indsatsen (og sikre fælles forståelse af krav gennem tidlig afprøvning) mellem det kravstillende projekt og den nationale service. Miljøet har derudover som formål at give mulighed for at afprøve fejlrettelser i eksisterende (produktions)versioner uden at forstyrre det stabile testmiljø (miljø 2). Grundvilkår - Leverandører og underleverandører kan afprøve nye og eksisterende snitflader, både i forhold til egne systemer og andres. - Miljøet er tænkt som et dynamisk testmiljø, hvor der ikke er indbygget garanti for at versioner fastholdes, tværtimod lægges der op til hurtige iterationer og hotfixes, og samarbejde på tværs af leverandører i forhold til at afprøve ny funktionalitet. En forudsætning for at dette lykkes er, at der sker en central styring af kommunikationen heraf, og at anvendelse af miljøet forudsætter en accept af at det tekniske fundament kan ændre sig med meget kort varsel (dog ikke uden varsel). - Nationale services og komponentleverandører kan sætte stubbe op, således at der inden udvikling af decideret funktionalitet kan gennemføres en simpel snitfladeafprøvning fra anvendersiden. Bemærkninger - Dette anvenderorienterede miljø er et supplement til det komponentleverandørmiljø, der eksisterer i en grundform allerede i dag. De to miljøer tjener hver deres (beslægtede) formål, og er separate og indbyrdes uafhængige. 5.3 TEST2: Miljø med stabile, kommende versioner Formål Afprøvning af kommende funktionalitet i services og NSP komponenter, f.eks. nye snitflader i FMK eller nye komponenter (hvis miljøet fandtes sidste år kunne det have være brugt til f.eks. stamdataservicen på NSP). Miljøet giver mulighed for gennemfø- Side 18

19 re testforløb inden national funktionalitet lægges i produktion, således at anvenderne kan være klar meget hurtigt efter (i princippet samtidig med) at den nye funktionalitet udstilles. Grundvilkår - I dette miljø kan anvenderne forvente at der udstilles stabile og kvalitetssikrede versioner af services og komponenter. Der vil komme nye versioner i takt med at serviceleverandørerne har stabile versioner klar og det passer i de planlagte servicevinduerat lægge dem i produktion i miljøet (styret af NSI). - Opdateringer af miljøet (versioner og konfigurationer) kommunikeres ud i god tid, således at man som anvender kan forvente, at hvis noget skifter adfærd derudover, er det med høj sandsynlighed ens eget system, der er årsagen (vigtig parameter i forhold til test og fejlfinding). - Miljøet er tænkt til afprøvning af parternes eksisterende og kommende versioner af egne systemer, hvor der ønskes en sikkerhed for at funktionalitet fungerer som ønskes også overfor kommende nationale services/komponenter. - Dynamiske stamdata opdateres i synk med produktionsmiljøet. Bemærkninger - Dette miljø eksisterer ikke idag, dog tages der udgangspunkt i det eksisterende FMK fællestest miljø. 5.4 PRODTEST: Produktionslignende Formål Fejlfinding i forhold til fejl opstået i produktionsmiljøet. E2e test i et stabilt, produktionslignende miljø. Certificering af it-systemer, der anvender FMK. 4 Grundvilkår - Alle komponenter og services udstillet i dette miljø er konfigureret og med samme version som i produktionsmiljøet. - Dynamiske stamdata (pt. alene Taksten) opdateres i synk med produktionsmiljøet. - Anvenderne afprøver kun gennemtestet funktionalitet i dette miljø, og alle parter kan derfor forvente at andres opførsel (og data) er produktionslignende. - Da miljøet ønskes produktionslignende er dette miljø tilgængeligt over sundhedsdatanettet. - Med produktionslignende refereres der til snitflader, versioner og adgangsvej (SDN) dimensionering og performance er indrettet til testformål. Bemærkninger - Dette miljø eksisterer i dag, men er ikke konfigureret og SLA et som ønsket endnu. Det tilgås pt. over internettet. 5.5 UDD: Uddannelse Formål Uddannelse af brugere. 4 Det bemærkes, at certificering generelt ikke er en NSI-opgave, og at formålet her alene er at stille et miljø til rådighed for de parter, der ønsker at varetage en given certificering; her FMK. Side 19

20 Grundvilkår - Miljøet er statisk i den forstand, at dynamiske stamdata kun opdateres efter aftale (f.eks. hvert halve år). De dynamiske stamdata indeholder bl.a. Taksten og rigtige SOR-data fra produktionsmiljøet. - Miljøet er produktionsnært i den forstand, at versioner i produktion også er tilgængelige i miljøet. - Fremtidige versioner af services og komponenter er også tilgængelige på dette miljø (under forudsætning af at de ikke på nogen måde ændrer på de eksisterende versioner). - Miljøet anses for at være et produktionsmiljø i forhold til SLA, idet der er store konsekvenser forbundet med fejl og uplanlagte nedetider. - Anvendere af dette miljø skal opføre sig pænt, idet misbrug af miljøet kan medføre alvorlige gener for andre parter. - Dette miljø er tilgængeligt over sundhedsdatanettet. Bemærkninger - Dette miljø eksisterer ikke endnu. Side 20

21 6 Appendix B: Sammenhængende testdatasæt Indenfor et givet miljø er der mulighed for at etablere sammenhængende testdatasæt, dels på automatiseret vis, dels gennem manuel oprettelse og justering af kliniske data. Den underliggende tanke for sammenhængende testdata er dels, at data kan opdeles i henholdsvis statiske stamdata, dynamiske stamdata og kliniske data, dels at de kliniske data ikke har interaktion på tværs af CPR-numre for testpatienter/borgere. Fælles miljø Kliniske(data( FMK DDV Sta-ske(stamdata( Dynamiske(stamdata( SDM STS Figur 8 De kliniske data hører til i de bagvedliggende systemer. De statiske og dynamiske stamdata fastholdes i stamdataservicen (SDM) på NSP. I det nuværende setup har man adgang til et meget begrænset testsæt, og kan købe sig til yderligere testdata hos FMK-leverandøren. Fremadrettet er der i princippet ikke en øvre grænse for hvor store mængder testdata de enkelte anvendere af et miljø kan få tildelt, da genereringen af testdata bliver foretaget ved hjælp af en række automatiserede scripts. 6.1 Automatiserede scripts til generering af testdata Der eksisterer i dag et sæt af disse scripts, udviklet for og vedligeholdt af NSI, og de tager lister af CPR-numre og et par andre parametre som input. På basis af disse lister genereres der i dag statiske stamdata, der består af CPR-stamdata (navn, adresse, m.v.), Autorisationsregister, Yderregister samt Sikrede (kobling mellem borger og læge/ydernummer). De automatiserede scripts er udviklet, således at de genererer de samme tilfældige statiske stamdata for et givet cpr-nummer, uanset hvor eller hvornår scriptet afvikles. Det er derudover muligt at lave en (valgfri) konfiguration af scriptet for de enkelte cpr-numre, og på den måde skræddersy hele listen eller dele af listen til særlige formål. Angives der ikke noget for de enkelte cpr-numre, vælger scriptet automatisk en konfiguration. Side 21

22 Fælles miljø CPR...,, CPR...,,...,,...,, CPR...,,...,,...,,...,,...,,...,,...,,...,,...,,...,,...,, NSI SCRIPTS Kliniske&data& Stamdata& SDM STS FMK DDV Figur 9 NSI stiller scripts til rådighed, der på basis af (konfigurerede) cpr-lister genererer kliniske data og stamdata. De nøjagtige konfigurationsmuligheder er dokumenteret særskilt i den tekniske dokumentation. For testpatienter vil der som udgangspunkt være mulighed for at udover cpr-nummer at specificere ydernummer og klinisk skabelon. For klinikere kan der angives ydernummer, autorisations-id og organisatorisk tilhørsforhold. 6.2 Mulighed for ind- og udlæsning af kliniske data Fremadrettet bliver det et krav til alle testsystemer, der udstiller kliniske data for testpatienter, at de giver mulighed for dels at man kan få en datapakke indeholdende en given testpatients samlede sæt af kliniske data, dels at testsystemerne kan modtage en sådan datapakke og erstatte eksisterende kliniske informationer for en given testpatient med datapakkens indhold. Restore- Dump- FMK FMK$sni(lade- Figur 10 FMK (og kommende services) udvides med to nye snitflader til testformål: Dump og Restore, der anvendes til at ind- og udlæse kliniske data. Med disse to nye snitflader åbnes der for at anvenderne af et miljø kan dels oprette kliniske data på automatiseret vis, dels at anvenderne kan tage et øjebliksbillede af en klinisk tilstand for én eller flere testpatienter, og genetablere denne tilstand på simpel vis. I de følgende afsnit beskrives konsekvenserne af dette i forhold til automatisk generering af testdata samt for genetablering af ønskede kliniske tilstande. Side 22

23 6.3 Kliniske skabeloner Ved automatisk generering af testdata er det et væsentligt krav fra regionerne, at der er mulighed for at styre de kliniske testdata, således at der kan etableres datasæt til forskellige formål, f.eks. uddannelse i forskelligt regi, test af datamæssigt besværlige testpatienter, osv. Dette krav imødekommes gennem begrebet klinisk skabelon, der basalt set er en datapakke som beskrevet i ovenstående afsnit for en enkelt testpatient. Datapakken består som beskrevet ovenfor af et klinisk øjebliksbillede for en enkelt testpatient i et givet nationalt itsystem. En skabelon oprettes ved at der for en given testpatient foretages de ønskede kliniske justeringer af data, indtil det samlede billede i det givne it-system er som ønsket. Justeringerne foretages gennem it-systemets klinikerrettede snitflade, og det er derfor muligt at tilrette den udvalgte testpatients data til det konkrete behov, skabelonen skal opfylde, f.eks. i forhold til cancer, diabetes, kroniske forløb, osv. Når de kliniske data i det givne it-system er som ønsket, kaldes testsystemets snapshot funktionalitet, og der haves nu en kopi af testpatientens kliniske data. Det erhvervede snapshot er ikke i sig selv en skabelon, men blot et udtræk af testpatientens kliniske data i form af en fil på en harddisk, og kan som sådan anvendes til flere formål. Udtrækket kan ophøjes til at være en skabelon, hvilket blot betyder at det navngives passende og placeres et sted hvor de automatiserede scripts har adgang til at indlæse udtrækket. Fremadrettet skal de automatiserede scripts udvides med (valgfri) mulighed for at angive en reference til en klinisk for hvert CPR-nummer, hvor den angivne skabelon bruges til at generere kliniske data for det pågældende CPR-nummer i det it-system, skabelonen tilhører. I første omgang er det alene skabeloner til FMK, der kan benyttes, og når der kommer yderligere testsystemer til vil det være muligt at tilføje kliniske skabeloner for disse systemer også. 6.4 Lokal og national anvendelse af kliniske skabeloner De automatiserede scripts er selvstående i den forstand, at de kan afvikles både lokalt og i regi af de fælles miljøer. I praksis betyder det, at ønsker en anvender af et miljø at stille en skabelon til rådighed for de andre anvendere, kan skabelonen indleveres til NSI, der sørger for at give skabelonen et unikt navn og offentliggøre den medfølgende beskrivelse. Andre anvendere af testsystemet kan efterfølgende anvende skabelonen til egne formål. Det er tilsvarende muligt at anvende skabeloner i lokale kopier af de automatiserede scripts. Dette vil være relevant f.eks. ved udarbejdelse af kursusmateriale til uddannelse, hvor der kan være behov for et antal testpatienter, der er klinisk identiske, så kursister kan gennemføre samme opgaver for hver deres sæt af testpatienter. 6.5 Oprettelse og genetablering af en ønsket klinisk tilstand Anvendelse af skabeloner giver mulighed for at skabe et stort sæt af testdata, der opfylder forskellige kliniske behov. I forhold til f.eks. testforløb og kurser kan der være behov for at tage ét eller flere øjebliksbilleder, så det er muligt at genetablere en given klinisk tilstand. Dette opnås gennem samme fremgangsmåde som ved etablering af skabeloner, dog vil øjebliksbillederne oftest alene være af lokal interesse, og i modsætning til skabelonerne kan Side 23

24 øjebliksbillederne indeholde data for en række cpr-numre (f.eks. et klassesæt til undervisningsbrug). Alle de relevante tetspatienter justeres til de hver især har den ønskede kliniske tilstand, og testsystemets snapshot funktionalitet kaldes for alle testpatienter (idet det er muligt at angive en liste af cpr-numre i kaldet, og der genereres dermed blot en enkelt, sandsynligvis meget omfangsrig datapakke indeholdende data for samtlige testpatienter i listen). Det er muligt at tage flere øjebliksbilleder af de samme testpatienter på forskellige tidspunkter, og man kan således på simpel vis gennemføre planlagte forløb, hvor man sikrer en kendt tilstand på flere etaper i forløbet ved at indlæse de forskellige øjebliksbilleder efter behov. 6.6 Skabeloner tilbudt af NSI NSI tilbyder i første omgang et mindre sæt af kliniske skabeloner baseret på anonymiserede produktionsdata. NSI tilbyder endvidere at ophøje skabeloner udarbejdet af de enkelte regioner til nationale skabeloner, således at det kliniske arbejde udført i den enkelte region kan komme andre til gavn. 6.7 Særlige forhold Der er pt. krav om at cpr-numre skal overholde samme tekniske krav som rigtige cprnumre, dvs. de skal bestå af en gyldig dato efterfulgt af fire cifre. Det er dermed pt. ikke muligt at anvende erstatningscpr-numre. 6.8 Omfanget af den centrale styring af sammenhængende testdatasæt Den centrale styring af sammenhængende testdatasæt består dels i udarbejdelse og vedligehold af de automatiserede scripts, dels i sikring af, at cpr-listerne til de enkelte anvendere af et miljø ikke har sammenfald af cpr-numre. Snitflader til administration af testdatasæt er bevidst gjort så simple som muligt, da der ønskes minimal afvigelse fra produktionsmiljøerne, og der er derfor som nævnt ovenfor alene introduceret to nye metoder til ud- og indlæsning af kliniske data. For at minimere risikoen for at forskellige anvendere at et miljø uforvarende nulstiller data tilhørende andre anvendere, er restore -snitfladen til de enkelte bagvedliggende systemer udstillet af NSI, og der er indbygget en kontrol af at en anvender alene kalder denne snitflade med cpr-numre, der er på anvenderens cpr-liste. Det er tilladt at lave udtræk af andre anvenderes kliniske data, f.eks. til inspiration til skabeloner. Side 24