Fælles miljø. NSP Testmiljøer. Dato: Version: 1.0

Transkript

1 NSP Testmiljøer National Sundheds-IT - Sammenhængende testdata Islandsbrygge 39 Dato: Version: 1.0 Udarbejdet af: NSI 2300 København S Fælles miljø CPR CPR CPR NSI SCRIPTS SDM STS FMK DDV Resumé Nationale services og lokale it-systemer anvender i stadigt større omfang fælles datakilder som f.eks. CPR-registret og Taksten, og der er derfor et voksende behov for at sikre sammenhængende testdata i testforløb, hvor lokale it-systemer afprøver anvendelsen af nationale services. Tilsvarende er der i undervisningsforløb behov for konsistens på tværs af de anvendte it-systemer, så brugerne oplever et virkelighedstro billede af it-systemernes brug. Nærværende notat beskriver den løsningsmodel, NSI stiller til rådighed i forhold til at generere og vedligeholde sammenhængende testdata i de fælles test- og uddannelsesmiljøer. Version Ansvarlig Kommentar 0.1 CHE Første udkast 0.9 CHE Små rettelser efter feedback fra RH og NSI. 1.0 CHE Pixibog tilføjet som appendiks, samt redaktionelle rettelser. Side 1

2 Indholdsfortegnelse 1 Indledning Baggrund Målgruppe Formål og afgrænsning Hvad er sammenhængende testdata? Hvad opnås ved brug af løsningen? Ansvarsområder og opgaver fordelt på aktørerne Løsningens indhold Sammenhængende testdatasæt Stamdata Statiske stamdata genereres til det enkelte miljø Dynamiske stamdata hentes fra produktionsmiljøet Kliniske data Ind- og udlæsning af kliniske data Kliniske skabeloner Automatiseret generering af data Administration af testdatasæt Omfanget af den centrale styring af sammenhængende testdatasæt NSI stiller nationale skabeloner til rådighed for nationale services Sikring af lokal sammenhæng ved indlæsning af kliniske data Appendiks A: Praktisk guide til sammenhængende testdata Bestilling af stamdata Kliniske testdata Administration af kliniske testdata Brug af scripts til at kalde Dump og Restore Vær opmærksom på følgerne af Dump og Restore Referencer Side 2

3 1 Indledning 1.1 Baggrund Den nationale udrulning af FMK har bragt fokus på behovet for fælles miljøer, hvori der kan gennemføres testforløb og uddannelse af brugere, og NSI, RSI og regionerne har derfor i fællesskab specificeret og etableret et antal fælles test- og uddannelsesmiljøer, der kan tilgås af relevanter parter indenfor sundhedssektoren. Behovet for fælles miljøer til test og uddannelse rækker udover FMK, og der er derfor blevet specificeret en arkitektur, hvor nationale services kan tilføjes efterhånden som de bliver udviklet. Da testmiljøerne i sagens natur er komplekse at etablere og vedligeholde, idet de mange komponenter og services interagerer med hinanden og i forskelligt omfang deler datagrundlag, er denne opgave placeret hos NSP-operatøren. En væsentlig del af et testmiljø er oprettelse og vedligehold af testdata. Generering af gode testdatasæt er en opgave, der selv i relativt ukomplicerede it-systemer kan være krævende. Generering af gode og sammenhængende testdatasæt i national sammenhæng er både kompleks og besværlig, idet data skal oprettes i mange registre og konsistens skal sikres på tværs af registrene, og der er derfor blevet etableret dels en central, administrativ grænseflade, hvor anvendere af et testmiljø kan få tildelt testdata, dels etableret den nødvendige funktionalitet til at oprette sammenhængende og konsistente testdatasæt. 1.2 Målgruppe Sammenhængende testdata er beskrevet i relativt ikke-tekniske termer. Notatet kan derfor med fordel læses af overordnede beslutningstagere og andre interessenter, der ønsker et indblik i mulighederne løsningen giver, samt principperne bag sammenhængende testdatasæt i fælles miljøer. NSP-operatøren har udarbejdet en teknisk dokumentation af løsningen, der beskriver snitflader og tekniske forudsætninger for brugen af sammenhængende testdata, og der henvises til dette dokumentationsmateriale for en teknisk gennemgang af løsningen [TESTDATA- TEKNISK]. 1.3 Formål og afgrænsning Notatet beskriver principper, forudsætninger og afgrænsninger forbundet med generering og vedligehold af sammenhængende testdatasæt i de fælles miljøer, NSI udstiller til uddannelses- og testformål. Notatet foreskriver ikke hvordan de lokale it-systemer implementeres, ej heller hvordan sammenhængende testdatasæt anvendes og udbredes på tværs af lokale it-systemer. 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. 1.4 Hvad er sammenhængende testdata? Sammenhængende testdata er en væsentlig del af fundamentet for testforløb af høj kvalitet i de fælles testmiljøer udstillet af NSI, og sammenhængende testdata medvirker til at give et virkelighedstro billede for brugere, der uddannes i brugen af lokale it-systemer og nationale services i det fælles uddannelsesmiljø. Side 3

4 Sammenhængende testdata dækker over flere aspekter ved de fælles test- og uddannelsesmiljøer, og omhandler både faktiske data, metoder til oprettelse og vedligehold af data samt en central administrationsfunktion. Datamæssigt er sammenhængende testdata data i et af de fælles miljøer, og består af et sæt af informationer i en række registre og nationale services, hvor der er sikret indbyrdes konsistens mellem de enkelte registre og dataindholdet i de nationale services i det givne miljø. Konceptuelt betragtes et testdatasæt som værende opdelt i stamdata og kliniske data, hvor stamdata er placeret i NSP-regi, og kliniske data hos de nationale services. Procesmæssigt er sammenhængende testdata styret af en række scripts, der opretter data på basis af cpr-lister (én liste per anvender). Disse scripts sikrer bl.a. at de relevante CPRnumre oprettes i testcpr-registret, og at referencer til andre registre er valide, f.eks. at der ved opslag i Sikrede fås gyldige referencer til Yderregistret, og at de tilhørende sundhedsfaglige personer kan slås op i Autorisationsregistret. Cpr-listerne og eksekvering af de tilhørende scripts håndteres af NSP-operatøren. Funktionalitetsmæssigt giver sammenhængende testdata mulighed for at tage et øjebliksbillede af kliniske data for en testpatient, og efterfølgende genindlæse øjebliksbilledet. Denne funktionalitet gør det muligt at definere et kendt udgangspunkt for én eller flere testpatienter, og på enkel vis genetablere dette udgangspunkt (til f.eks. kurser eller iterative testforløb). En anden og nyttig egenskab ved disse øjebliksbilleder er muligheden for at udskifte cprnummeret ved genindlæsning, således at et øjebliksbillede kan fungere som skabelon for andre testpatienter. Sammenhængende testdata giver endvidere mulighed for automatisk oprettelse af kliniske data for alle testpatienter på basis af skabeloner, og det er dermed muligt at populere selv meget store testdatasæt med klinisk meningsfyldte data. 1.5 Hvad opnås ved brug af løsningen? Løsningen tilvejebringer en metode til automatisk oprettelse af store og små testdatasæt til brug ved testforløb i de fælles miljøer. Anvendere af miljøet opnår dermed sikkerhed for at miljøets data har en kendt og høj kvalitet ved opstart af et testforløb. Løsningen giver endvidere mulighed for på enkel vis at tage øjebliksbilleder af kliniske data og efterfølgende genindlæse dem i miljøet, således at testforløb kan gentages med samme udgangspunkt, og klassesæt til uddannelsesforløb kan genbruges. 1.6 Ansvarsområder og opgaver fordelt på aktørerne Der er en række opgaver og ansvarsområder, der er fordelt på de involverede aktører. Fordelingen er som følger: - Anvender (regioner, LPS-leverandører, kommuner, m.fl.) o Efter behov tage kliniske øjebliksbilleder og opbevare billederne til senere brug o Bestille cpr-numre hos NSP-operatøren til eget brug og formidle cpr-listerne internt i egen organisation o Eventuelt tilrette testdata til specifikke formål (f.eks. overskrive de automatisk genererede kliniske data med særlige patienttyper som kronikere, diabetikere, cancerpatienter, osv.) - Serviceudbyder (FMK, DDV, m.fl.) Side 4

5 o Generere et passende sæt af kliniske skabeloner, således at der kan dannes meningsfyldte kliniske data for alle testpatienter på cpr-listerne o Udstille service, der kan anvendes til at tage øjebliksbilleder og indlæse kliniske data (til brug for både anvenderne og NSP-operatøren) - NSP-operatør o Opbevare og publicere cpr-lister for alle anvenderne, således at det er muligt at identificere præcis hvilken anvender, der ejer et cpr-nummer o Generere statiske stamdata og indlæse de tilhørende kliniske skabeloner ved opdateringer på cpr-listerne 1.7 Løsningens indhold De etablerede testmiljøer afspejler en kompleks virkelighed i produktionsmiljøet, hvor en række nationale datakilder leverer stamdata til fælles brug gennem NSP ens stamdataservice. Der er dermed i produktionsmiljøet sikret entydighed i forhold til oprindelse af data og ajourføring af kildedata. Dette er illustreret på simplificeret form for produktionsmiljøet på Figur 1, hvor det ses at en række registre opsamles og udstilles gennem stamdataservicen. 1 Stamdataregistre+fra+en+række+myndigheder+ CPRregistret Autorisationsregistret Yderregistret Sikrede Taksten SOR SKS NSP Stamdata service Figur 1 NSP ens stamdataservice i produktionsmiljøet opsamler registerinformationer fra en række bagvedliggende registre og sikrer, at alle parter har nem adgang til samme version af registrene. I testmiljøerne er ikke alle de bagvedliggende stamdataregistre tilgængelige til testformål, og det er derfor nødvendigt at frembringe testdata til disse registre på anden vis. Løsningen beskrevet i dette dokument tilvejebringer disse testdata ved hjælp af cpr-lister og automatiserede generering af testdata, hvorved der sikres konsistens og sammenhæng mellem registrene. Stamdata som beskrevet ovenfor udgør kun en del af det datamæssige fundament i et givet miljø. De nationale services, der er tilgængelige i miljøet, rummer hver især et sæt kliniske data for de tilknyttede patienter. Som illustreret på Figur 2 udstilles de nationale services gennem NSP, og de kliniske data opbevares af de respektive services. 1 På NSP-operatørens hjemmeside ses en komplet oversigt over udstillede registre. Side 5

6 Kliniske(data(fra(na.onale(services( FMK DDV NSP Figur 2 Kliniske data fra de nationale services udstillet gennem NSP opbevares af de respektive services. I testmiljøerne er der oprettet separate testinstanser af de tilknyttede nationale services. Testudgaverne af disse services oprettes uden kliniske data, og det er derfor hensigtsmæssigt automatisk at kunne oprette et passende testdatasæt for testpatienterne i testmiljøerne. Løsningen beskrevet i dette dokument giver mulighed for automatisk oprettelse af kliniske data i de relevante nationale services tilknyttet et testmiljø. Side 6

7 2 Sammenhængende testdatasæt I produktionsmiljøet er opgaven med at sikre konsistens mellem registrene (og løbende vedligehold af registrenes indhold) placeret hos de respektive dataejere. I test- og uddannelsesmiljøerne er det ikke muligt at opretholde denne kobling i fuldt omfang, idet ikke alle nationale datakilder giver mulighed for separate testmiljøer. Der er derfor behov for en alternativ løsning, hvor entydigheden bevares (indenfor det givne miljø), og hvor der kan oprettes sammenhængende testdatasæt for de relevante stamdataregistre. Data fra registre i produktionsmiljøet benævnes dynamiske stamdata, idet de opdateres af en ekstern instans (dataejeren). Data fra registre, der i de fælles miljøer genereres automatisk af NSI, benævnes statiske stamdata, idet de i praksis er statiske, da indholdet ikke vedligeholdes manuelt. Testinstanserne af de nationale services, der eksisterer i de fælles miljøer, indeholder kliniske testdata for testpatienterne. De tre typer af data er illustreret på Figur 3, hvor det ses at stamdata stilles til rådighed for alle parter i et testmiljø (dvs. både anvendere af miljøet og testudgaverne af de nationale services) gennem stamdataservicen, og de kliniske data er tilgængelige for anvenderne af testmiljøet gennem de udstillede snitflader for de nationale services. Det bemærkes, at kliniske data adskiller sig principielt fra de andre typer testdata, idet de vedligeholdes af anvenderne af systemet (testbrugerne) gennem de formelle snitflader, hvor stamdata som beskrevet ovenfor enten oprettes automatisk (statiske stamdata) eller hentes fra eksterne dataleverandører (dynamiske stamdata). Sta$ske(stamdata( Dynamiske(stamdata( Kliniske(data(fra(( na$onale(services((test)( CPRregistret Autorisationsregistret Yderregistret Sikrede Taksten SOR SKS FMK DDV NSP Stamdata service Figur 3 I et testmiljø hentes udvalgte registre fra de officielle datakilder, og andre genereres automatisk. De kliniske testdata er konsistente med stamdata i det givne miljø og opbevares i testimplementeringerne af de nationale services. Registrene anvendes både af de nationale services og af de lokale it-systemer, og det er altafgørende for anvendeligheden af testdatasættet i et givet testmiljø at der dels er konsistens imellem registrenes indhold og referencer på tværs mellem registre, dels at alle parter i miljøet anvender samme udgave af registrene. Løsningen giver derfor anvendere af de fælles miljøer mulighed for at oprette og vedligeholde testdatasæt med konsistens mellem de anvendte registre. Ved oprettelse af en testpatient sikres det automatisk, at referencerne mellem de relevante registre eksisterer, f.eks. at testpatientens egen læge eksisterer i yderregistret, og at vedkommende har et autorisationsid i Side 7

8 autorisationsregistret. Som en del af løsningen er det endvidere muligt at få genereret kliniske data på automatiseret vis. Den samlede løsning for sammenhængende testdatasæt gør det derfor muligt at oprette et komplet og sammenhængende datasæt (både stamdata og kliniske data) for en liste af testpatienter og testbrugere, således at en anvender af et givet testmiljø har et solidt og konsistent datagrundlag allerede inden ibrugtagningen af miljøet. Tilsvarende sikres det, at de registre, der indeholder stamdata for testpatienter og testbrugere, anvendes af de tilknyttede nationale services, f.eks. at FMK anvender samme testudgave af autorisationsregistret som anvendere af et miljø kan tilgå gennem NSP ens stamdataservice. 2.1 Stamdata Som beskrevet ovenfor er stamdata i testmiljøerne opdelt i statiske og dynamiske stamdata. De dynamiske stamdata hentes fra de samme datakilder som anvendes i produktionsmiljøet. Denne kobling er mulig for registre, hvor det er tilladt at anvende produktionsdata til testformål, og hvor der ikke er behov for at oprette særlige testdata. De statiske stamdata er registre, hvor det af forskellige årsager ikke er muligt eller tilladt at anvende produktionsdata til testformål. Som det fremgår af Figur 4 er der en række registre, der indeholder personhenførbare og potentielt personfølsomme oplysninger og derfor ikke uden videre kan anvendes til testformål. Disse registre udfyldes derfor med automatisk genereret indhold, men vedligeholdes ikke løbende som deres modparter i produktionsmiljøet. Sta$ske(stamdata( Dynamiske(stamdata( CPRregistret Autorisationsregistret Yderregistret Sikrede Taksten SOR SKS Indeholder personhenførbare og potentielt personfølsomme oplysninger. Produktionsdata må ikke anvendes. Indeholder ikke-følsomme informationer, der er offentligt tilgængelige og må anvendes til testformål. Produktionsdata må anvendes. Figur 4 Personorienterede stamdata genereres til hvert miljø og betragtes derfor som statiske. De resterende registre kan hentes fra produktionsmiljøet med passende intervaller og betragtes derfor som dynamiske. Det bemærkes at det for hvert miljø er muligt at opdatere dynamiske registre efter aftale, således at dynamikken er kontrolleret (dette er relevant i forhold til f.eks. uddannelsesmiljøet, hvor der ikke ønskes opdateringer i takt med produktionsmiljøet). Opdateringsfrekvensen fastlægges individuelt for de enkelte fællesmiljøer Statiske stamdata er ens på tværs af alle testmiljøerne Følgende registre betragtes som statiske i test- og uddannelsesmiljøerne: - CPR-registret o Indeholder CPR-oplysninger for testpatienterne, herunder navn og adresse - Autorisationsregistret o Indeholder sundhedsfaglig autorisation for testbrugerne Side 8

9 - Yderregistret o Indeholder yderoplysninger for de privatpraktiserende sundhedsfaglige testbrugere, herunder læger, speciallæger og tandlæger - Sikrede o Indeholder koblingen mellem testpatienterne og egen læge Det bemærkes, at de enkelte stamdataregistre er indbyrdes afhængige, idet der refereres på tværs af registrene. I oprettelsen af de statiske stamdata sikres konsistens imellem registrene, således at der er sikkerhed for at f.eks. en testpatients egen læge i sikrede også eksisterer i yderregistret og autorisationsregistret. Afhængighederne mellem stamdataregistrene er skitseret på Figur 5. Som det ses er cpr-registret et centralt register, der refereres fra de andre statiske registre. Afhængighederne rækker udover de direkte referencer, idet der også er behov for indirekte sammenhæng, f.eks. at der eksisterer sundhedsfaglige personer (i autorisationsregistret) til ydernumrene i yderregistret. Sikrede CPRregistret Autorisationsregistret Yderregistret Figur 5 De statiske stamdataregistre er indbyrdes afhængige, og det er derfor en del af løsningen at der sikres konsistens mellem registrene ved oprettelse af sammenhængende testdatasæt. De statiske stamdata er de samme på tværs af de fælles miljøer, og det er dermed muligt at gennemføre identiske testforløb på forskellige miljøer Dynamiske stamdata hentes fra produktionsmiljøet Følgende registre hentes fra produktionsmiljøet 2 : - SOR o Indeholder organisatoriske oplysninger for udvalgte dele af sundhedsvæsnet - SKS o Som SOR, blot for Sundhedsvæsenets Klassifikationssystem - Taksten o Lægemiddelstyrelsens officielle takst over lægemidler De dynamiske stamdata er ikke nødvendigvis på tværs af miljøerne, idet miljøerne er konfigureret forskelligt i forhold til hvor ofte data synkroniseres med produktionsmiljøet. 2 Registrene hentes fra samme datakilder som produktionsudgaverne, og er indholdsmæssigt og strukturelt identiske med registrene på NSP ens stamdataservice i produktionsmiljøet. For yderligere information om registrenes indhold og anvendelsesformål henvises derfor til NSP-operatørens dokumentation af stamdataservicen. Side 9

10 2.2 Kliniske data De nationale services, der kan tilgås i de fælles miljøer, er oprettet som separate instanser, der hver især indeholder kliniske data for de patienter, der eksisterer i de enkelte miljøer. Testudgaverne af de nationale services er ved opstart af et miljø tomme for kliniske data, og der oprettes derfor automatisk kliniske data for samtlige testpatienter i hvert enkelt miljø. For hver patient udvælges der som en del af løsningen automatisk en passende klinisk skabelon for hver af de tilknyttede nationale services (se afsnit 2.3 nedenfor for en beskrivelse af skabelon-begrebet), og indholdet fra skabelonerne indlæses i de respektive services. FMK FMK$ data$ DDV DDV$ data$ Figur 6 Hver national service opbevarer egne kliniske data, der kun er tilgængelige gennem de formelle snitflader til servicen. Det er derfor nødvendigt at etablere en alternativ metode til ind- og udlæsning af kliniske data i de fælles miljøer Ind- og udlæsning af kliniske data Som en del af løsningen er de nationale services blevet udvidet med funktionalitet, der gør det muligt at ind- og udlæse kliniske data for testpatienter. Funktionaliteten gør det muligt at gennemføre den automatiske oprettelse af testpatienter, der udføres af NSP-operatøren som en del af vedligeholdet af cpr-listerne. Restore- Dump- FMK FMK$sni(lade- Funktionaliteten udstilles på separate snitflader som illustreret på Figur 7 og er derfor ikke en del af den nationale services officielle snitflade. Denne skelnen er vigtig, da funktionaliteten giver mulighed for administrative justeringer af datagrundlaget, og det er nødvendigt at tillade indlæsningen uden validering af brugerens sundhedsfaglige rettigheder. Funktionaliteten må derfor ikke være tilgængelig i de sundhedsfaglige it-systemer. Det er derfor heller ikke muligt at foretage en indlæsning af data i produktionsmiljøet, da snitfladen ikke udstilles i produktion. Figur 7 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. Side 10

11 Ind- og udlæsning af kliniske data giver anvenderne af et miljø mulighed for en meget finkornet kontrol over testdatasættet, da der ikke er tekniske begrænsninger for hvordan funktionaliteten anvendes. Det forudses at funktionaliteten vil blive anvendt til f.eks. etablering af klassesæt til brug i undervisningsforløb, og til etablering af et kendt udgangspunkt for iterative testforløb. Data udlæst af en national service kan betragtes som datapakker, hvor hver pakke indeholder et komplet øjebliksbillede (inklusiv historik) for en given testpatient i den givne service. For FMK vil et øjebliksbillede f.eks. være testpatientens medicinkort. En anvender, der tager et sådant øjebliksbillede af en testpatient, modtager datapakken som en fil, og anvenderen opbevarer selv datapakken til eventuel senere brug. Datapakken er låst i den forstand at den ikke kan ændres af anvenderen, og alene kan anvendes til genindlæsning af testpatienten. F.eks. vil et klassesæt bestå af et antal datapakker, opbevaret et sted i underviserens regi, og ved kursusstart vil underviseren foranledige at datapakkerne genindlæses i den nationale service (ved kald til Restore metoden) i det fælles uddannelsesmiljø. 2.3 Kliniske skabeloner Datapakker udlæst af en national service ved anvendelse af Dump-funktionaliteten beskrevet ovenfor har en yderligere anvendelse, idet det er muligt at anvende et klinisk øjebliksbillede af en testpatient som skabelon for andre testpatienter. Datapakken indeholder det komplette kliniske øjebliksbillede af testpatienten, men ved genindlæsning af datapakken i den nationale service angives det, at data ikke skal oprettes for den oprindelige testpatient, men i stedet oprettes for en anden testpatient. Restore-metoden vil substituere det oprindelige cprnummer og indlæse de kliniske data i den anden testpatients navn. Side 11

12 FMK FMK testpatient 1 FMK$sni(ladetestpatient 2 Trin-2:-Indlæsning-af-øjebliksbillede- (skabelon)- Dump- Restoretestpatient1 Data-pakke: testpatient1 Data-pakke: testpatient1 FMK$sni(lade- cpr$nr:- testpa3ent1- Trin-1:-Udlæsning-af-øjebliksbillede- cpr$nr:- testpa3ent2- Figur 8 Kliniske øjebliksbilleder kan anvendes som skabeloner gennem en totrinsproces, hvor data først udlæses for en given testpatient, og efterfølgende indlæses for en anden testpatient. Anvendelsen af øjebliksbilleder som skabeloner er illustreret på Figur 8. Som det fremgår af figuren udlæses et øjebliksbillede og anvendes efterfølgende som skabelon for en anden testpatient. En skabelon er dermed blot et klinisk øjebliksbillede, der konceptuelt har fået skabelonstatus, og der er derfor ikke knyttet tekniske begrænsninger til anvendelsen. Dette giver en lang række muligheder for manipulation med testdata, og fungerer som fundament for den automatiske oprettelse af kliniske data for nye testpatienter, idet oprettelsen af kliniske data her er baseret på kliniske skabeloner. I praksis vil en skabelon blive oprettet 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 tilpassede efter de konkrete behov, oprettes et øjebliksbillede ved kald til servicens Dump-funktionalitet, og der haves nu en kopi af testpatientens kliniske data i en separat datapakke, der kan anvendes både som skabelon og til genindlæsning af testpatienten. Side 12

13 2.4 Automatiseret generering af data NSP-operatøren vedligeholder en række automatiserede scripts, der genererer sammenhængende testdata. De automatiserede scripts bygger på cpr-lister, og danner dels de statiske stamdata, dels kliniske data. Anvendere af de fælles miljøer har separate cpr-lister, der rummer testcpr-numre ejet af de enkelte anvendere. NSP-operatøren publiserer listerne og godkender tilføjelser til de enkelte lister (med det formål at sikre, at hvert testcpr-nummer alene optræder på én liste, så der er entydigt ejerskab over cpr-numrene). Fælles miljø CPR CPR CPR NSI SCRIPTS SDM STS FMK DDV Figur 9 NSI stiller scripts til rådighed, der på basis af (konfigurerede) cpr-lister genererer kliniske data og stamdata. Cpr-listerne giver mulighed for angivelse af udvalgte karakteristika for testpatienter og testbrugere. De nøjagtige konfigurationsmuligheder er dokumenteret særskilt i den tekniske dokumentation fra NSP-operatøren. Ønskes der særlige kliniske data for udvalgte testpatienter overskrives de automatisk genererede kliniske data blot ved anvendelse af Restore-funktionaliteten. Side 13

14 3 Administration af testdatasæt 3.1 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 (Dump og Restore). Disse metoder er stillet til rådighed for anvenderne af de fælles miljøer, og anvendelsen af metoderne er underlagt de generelle retningslinjer, anvenderne i fællesskab har specificeret for de enkelte miljøer (også omtalt som fælles spilleregler ). 3.2 NSI stiller nationale skabeloner til rådighed for nationale services Den automatiske generering af kliniske data finder sted gennem anvendelse af et sæt af skabeloner, der stilles til rådighed af NSI for hver enkelt national service. I FMK-regi pågår der i efteråret 2012 et arbejde med anonymisering af produktionsdata, og afledt af dette projekt produceres der et stort antal kliniske skabeloner, der fungerer som datagrundlag for den automatiserede generering af FMK kliniske testdata. 3.3 Sikring af lokal sammenhæng ved indlæsning af kliniske data Sammenhængende testdata sikrer at stamdata og kliniske data i oprettelsesøjeblikket er konsistente og sammenhængende i de enkelte miljøer. Sikringen gælder for den nationale del af infrastrukturen, dvs. for data på den nationale serviceplatform og de nationale services. I forhold til de lokale it-systemer, der anvender de sammenhængende testdata som beskrevet her, er der en opgave forbundet med at sikre intern konsistens. Ved oprettelse af en testpatient i de fælles miljøer, hvor testpatienten eksisterer i forvejen i de lokale it-systemer, kan der være uoverensstemmelse både i stamdata og kliniske data. Tilsvarende vil der ved nulstilling af en testpatient (f.eks. genindlæsning i et kursusforløb) være behov for at sikre, at lokale it-systemer tilsvarende nulstilles. Denne opgave ligger hos de enkelte anvendere, og bør tages i betragtning når de fælles miljøer anvendes. Side 14

15 4 Appendiks A: Praktisk guide til sammenhængende testdata Sammenhængende testdata består af stamdata og kliniske data. Stamdata bestilles hos NSP-operatøren gennem NSP-support, og der skal påregnes 1-2 arbejdsdag til levering af nye stamdata. 4.1 Bestilling af stamdata Bestilling af stamdata foregår ved at der i en supporthenvendelse til NSP-support angives følgende: - - Testpatienter o En specifik liste af cpr-numre, der ønskes oprettet Testklinikere o En specifik liste af cpr-numre For hver testkliniker angives cpr-nummer, autorisationsid og rolle Bemærk at dobbeltgængere ikke er tilladt, så ved angivelse af en liste bliver den valideret af NSP-operatøren op mod allerede udstedte cpr-numre (for samtlige anvendere), og dobbeltgængere afvises. Allerede oprettede testpatienter og testklinikere kan ses på NSP-operatørens offentlige oversigt på NSP-operatørens hjemmeside. 4.2 Kliniske testdata Kliniske testdata genereres automatisk af NSP-operatøren, når der oprettes stamdata. Det betyder f.eks. at alle testpatienter har et medicinkort i FMK med anonymiserede produktionsdata. Der er ikke behov for at gøre yderligere for at få kliniske testdata oprettet automatisk. Bemærk at det er en god ide at tage et Dump af alle testpatienterne, så snart de er oprettet, da det på den måde er nemt at nulstille hele testsættet, hvis der skulle være behov for dette. Alternativt kan man genbestille cpr-numrene hos NSP-operatøren, men det tager kalendertid. 4.3 Administration af kliniske testdata Der er to måder, der kan foretages administration af kliniske testdata: - - Teknisk o Kald til Dump og Restore metoderne Brugerorienteret o Anvendelse af egne testsystemer eller onlineløsninger Metoderne kan kombineres, så det f.eks. er en bruger, der i EPJ tilretter data i et klassesæt for samtlige testpatienter, og efterfølgende (eventuelt med hjælp fra en tekniker) sørger for at kalde Dump for hele klassesættet. Side 15

16 Ved kald til Dump returneres en binær fil, der indeholder testpatientens kliniske data. Denne fil skal opbevares et passende sted, så den efterfølgende kan bruges hvis der er behov for at genetablere patientens tilstand. Der udstilles en DGWS snitflade for hver national service i hvert af de fælles miljøer til metoderne - - Dump o Metode, der tager et cpr-nummer som input og som returnerer en binær fil, der indeholder de tilhørende kliniske data. o Den binære fil skal opbevares til eventuel senere brug, f.eks. i en folder på brugerens harddisk. Restore o Metode, der tager et cpr-nummer samt en dump-fil som input, og som overskriver de kliniske data for det angivne cpr-nummer med de kliniske data i dump-filen. WSDL og anden dokumentation for Dump og Restore (herunder endpoints til de forskellige services i de forskellige miljøer) kan findes her på NSP-operatørens hjemmeside. 4.4 Brug af scripts til at kalde Dump og Restore NSI har udarbejdet eksempler på scripts, der kan bruges ved kald til Dump og Restore. Disse scripts kan eventuelt fungere som inspiration, og kan downloades fra NSP-operatørens hjemmeside. Det bemærkes, at de leverede scripts er Pythonscripts, og derfor forudsætter en pythonfortolker på den maskine, hvor de eksekveres. Kommandolinjekaldene er udarbejdet til Unix/Linux, og kan også afvikles på en Windowsplatform under forudsætning af at der installeres en passende shell (f.eks. CygWin (gratis), der kan hentes her: Kommandolinjekald til Dump:./make-dump-request.py [cpr-nummer - uden bindestreg]./perform-request.py [URL til dump-snitflade] [PORT] dump - > [sti til dump-fil] Eksempel:./make-dump-request.py /performrequest.py triforkfaellestest.lms.trifork.com 80 dump - > /tmp/ dump Side 16

17 Kommandolinjekald til Restore: cat [sti til dump-fil]./make-restore-request.py [cpr-nummer der skal skrives til i den nationale service - uden bindestreg] -./perform-request.py [URL til restoresnitflade] [port] restore - Eksempel: cat /tmp/ dump./make-restore-request.py /performrequest.py triforkfaellestest.lms.trifork.com 80 restore - Bemærk at en Restore-operation kan tage én patients dump-fil som input og skrive det til en anden patient, og dermed fungerer første patient som "skabelon" for den anden patient. 4.5 Vær opmærksom på følgerne af Dump og Restore Lokale it-systemer har ofte cachede data fra de nationale services, og ved brug af Restoremetoden ændres hele datagrundlaget for den pågældende testpatient i den nationale service. Hvis et eller flere lokale it-systemer beror på f.eks. versionsnummeret af et medicinkort til at sikre at seneste version er cachet, vil dette kunne fejle, idet det er det komplette datagrundlag, der ændres i den nationale service, herunder versionsnumre. Det er derfor nødvendigt at man sikrer, at de lokale it-systemer håndterer en Restore operation. Side 17

18 5 Referencer Reference Beskrivelse Placering TESTDATA-TEKNISK NSP-operatørens tekniske dokumentationssæt for sammenhængende testdata Findes på NSP-operatørens hjemmeside ( Side 18