Opstartsmøde fase 2: Implementering og etablering af miljøerne Fælles (test)miljøer Opstartsmøde fase 2: Implementering og etablering af miljøerne Mødedeltagere: NSI: Lene Ærbo, Steen Manniche, Thomas Sonne, Christian Ernstsen Region Nord: Johnny Vest-Nielsen, Lisbeth Røhr Kristiansen Region Syd: Kim Løve Østerbye Region Sjælland: Karina Belinda Reimer Hansen Region Hovedstaden: Henrik Hermann RSI: Jørgen Hougaard Afbud: Region Midt (Hans Henrik Bøttger) Afbud: LPS-leverandørerne (formidlet gennem Alice Kristensen, MedCom).

Dagsorden Status på projektet Gennemgang af kommentarer og spørgsmål fra regionerne Processen fremadrettet Milepælene og opgaver hos parterne som følge af leverancerne Forslag til emner på næste møde

Status på projektet Fase 1 er gennemført 4 miljøer vedtaget, enkelte udeståender Aktivitetsplan med 4 milepæle vedtaget Aktiviteter påbegyndt parallel Milepæl 1 (1. november) er på sporet

Kommentarer til arbejdsnotatet 1/6 Kan produktionscertifikater benyttes i de fælles miljøer? Svar: Nej, ikke i de planlagte miljøer Hvis dette ønskes, skal følgende gennemføres De økonomiske konsekvenser (etablering og drift) skal afdækkes Der skal gennemføres tekniske ændringer af sikkerhedskomponenterne Miljøerne skal sikres, så personhenførbare og potentielt personfølsomme oplysninger behandles passende Herunder sikring af netværk og teknisk adgang til databaser m.v. NSI udarbejder en kort beskrivelse af de tekniske konsekvenser forbundet med at sammenblande produktions- og testcertifikater i et miljø (bl.a. at STS skal ændres, så der kan veksles fra produktion til test). Beskrivelsen vil blive anvendt i regionalt regi som del af beslutningsgrundlaget for om der ønskes denne mulighed. Ønsket kommer på observationsliste, og opgaven estimeres efter dette projekt. Der er pres på for at gennemføre dette projekt, så øvrige aktiviteter nedprioriteres. Opgaven er et ønske fra Region Midt. Det bemærkes, at beskrivelsen udarbejdes under den antagelse, at der ønskes produktionscertifikater til autentificering af brugeren (idet brugeroplevelsen dermed ikke ændres i forhold til produktionsmiljøet for RM), og at sikkerhedsinfrastrukturen efterfølgende veksler til sikkerhedsbilletter underskrevet med miljøets testcertifikat.

Kommentarer til arbejdsnotatet 2/6 Navngivning af PRODTEST-miljøet – det er en nedgradering af miljøet! Svar: Navngivningen afspejler miljøets reelle formål og egenskaber, som det er blevet beskrevet på de foregående møder. Der kan i princippet godt etableres en kopi af produktionsmiljøet– dette vil i givet fald kræve at der afsættes væsentligt flere økonomiske ressourcer. Navnet PREPROD signalerer, at det er et miljø, der afspejler et setup, der ikke er i produktion endnu. PRODTEST er en kopi af produktionsmiljøet, og er på udvalgte områder (versioner af kode og konfigurationer) meget tro overfor produktionsmiljøets setup. Fremfor at lave en eksakt kopi af produktionsmiljøet, hvilket vil kræve væsentligt flere økonomiske ressourcer både til etablering og drift, er der fokus på at opfylde anvendernes behov til brugen af miljøet. Der leveres derfor i første omgang et PRODTEST, der minder meget om det eksisterende FMK PRODTEST i forhold til miljøets egenskaber, og efterfølgende kan anvenderne komme med ændringsforslag til miljøets muligheder (f.eks. håndtering af mange samtidige requests, et mere omfattende testdatasæt, m.v.). Pointen er, at det planlagte setup vurderes at opfylde de nuværende behov, og at der efterfølgende kan udvides med yderligere muligheder. Det bemærkes, at regionale stresstests vil typisk levere en femtedel af det load, produktionsmiljøet kan klare (idet produktionsmiljøet er dimensioneret til brug fra alle parter). Der er derfor ikke behov for dimensionering af PRODTEST tilsvarende produktionsmiljøet, givet regionerne og andre anvendere kan aftale sig frem til at reservere miljøet til dette formål.

Kommentarer til arbejdsnotatet 3/6 Hvordan fejlsøger man i produktion? Kan der etableres adgang også for regioner og LPS-leverandører? Fejlene vil typisk være datarelaterede Svar: Der tilbydes mulighed for udtræk af produktionsdata fra FMK og DDV under visse restriktioner (er ikke specificeret endnu) Yderligere adgang til produktionsdata udenom de formelle snitflader er ikke dækket af nærværende projekt Der er et stort og anerkendt behov for at kunne fejlsøge på fejl opstået i produktion. Fejlmeldinger fra klinikere er præget af en travl hverdag og et ufravigeligt krav om at kunne fejlmelde på meget kort tid og efterfølgende fortsætte behandling af den pågældende patient, og der er derfor et stort behov for at kunne etablere dels et “øjebliksbillede” af situationen samt handlingerne, der har ledt frem til fejlen. Dette behov fremføres i andet regi. Nærværende projekt bidrager i begrænset omfang til løsning af problemet, idet der ved hjælp af Dump-funktionaliteten kan tages et øjebliksbillede af patientens kliniske tilstand i FMK og DDV. Dette løser ikke problemet, men vil med stor sandsynlighed indgå i en fremtidig løsning, og NSI medtager derfor denne mulighed i overvejelserne om hvordan behovet for fejlsøgning i produktionsmiljøet opfyldes. Dump vil være muligt fra produktionsmiljøet i forbindelse med fejlsøgning. Ikke som en udstillet service, men som en administrativ handling, udført af NSI. Rammer og restriktioner for dette er ikke dækket af nærværende projekt, der alene tilvejebringer den tekniske mulighed. Dump af produktionsdata skal være omfattet af strenge regler vedrørende personhenførbarhed. Specificeringen af dette er under udarbejdelse. Diskussioner har været ført bl.a. hos TriFork omkring anonymisering af data holdt over for genskabelsen af de reelle kliniske situationer. Det bemærkes, at data, der ikke er i NSI’s varetægt, ikke kan tilvejebringes af NSI; f.eks. data fra et regionalt EPJ eller et LPS-system.

Kommentarer til arbejdsnotatet 4/6 Hvad indebærer dump/restore? Og kan man dumpe data fra produktion og anonymisere dem til brug i et testmiljø? Svar: Ja, dump-funktionaliteten vil findes i produktionsmiljøet for udvalgte services Der er ikke etableret regler for hvordan det vil foregå i praksis Hvad indebærer dump/restore – fælles gennemgang Der leveres en dokumentationspakke i milepæl 4, hvori dokumentationen af sammenhængende testdata indgår. NSI prioriterer udarbejdelsen af dokumentationen højt, og projektdeltagerne får adgang til dokumentationen så snart den er udarbejdet – så vidt muligt længe før milepæl 4, så alle deltagere får mulighed for at vurdere om dokumentationen er tilstrækkelig. Efter levering af dokumentationen indgår vurdering af dokumentationen på det følgende møde i den planlagte møderække. Der kører parallelt med dette projekt et anonymiseringsprojekt, der går ud på at have populere databaser med produktionslignende data til testformål. Der er en lang række udfordringer, idet det har vist sig, at man selv med relativt få kliniske data og stamdata kan identificere en ellers anonymiseret person, f.eks. gennem fødselsdatoer i en familie (fødselsdatoer i en familie på fire vil ofte være tilstrækkeligt til at identificere familien, givet man fastholder familierelationerne i testdata). Samtidig ønsker man at bibeholde tilstrækkeligt med faktorer til at de anonymiserede data er nogenlunde meningsfyldte. Disse udfordringer håndteres i anonymiseringsprojektet, og nærværende projekt drager nytte af det arbejde, der foretages der. I praksis betyder det, at de automatisk genererede testdatasæt vil have højere klinisk kvalitet end først stillet i udsigt, med en bred aldersmæssig spredning på testpatienterne. NSI har fortsat ansvaret for generering og passende anonymisering af de automatisk genererede testdatasæt. Regionerne og andre anvendere af testmiljøerne har naturligvis samme muligheder som stillet i udsigt i forhold til at tage kliniske øjebliksbilleder af testpatienter (f.eks. til uddannelsesforløb) og anvende udvalgte patienter som kliniske skabeloner.

Kommentarer til arbejdsnotatet 5/6 Beskrivelse af snitfladeversioner mangler – hvordan bruges de samtidig uden at noget går galt? Svar: Det er samme problemstilling som i produktion – og det håndteres af serviceudbyderen I ethvert kald til FMK angives det hvilken snitfladeversion, der ønskes benyttet Kald til samme snitflade, men til forskellige versioner af snitfladen, giver ikke anledning til datafejl eller andre problemer. Det er serviceudbyderen, der har opgaven med at sikre konsistens i data på tværs af snitfladeversioner. De planlagte miljøer adskiller sig ikke fra produktionsmiljøet i denne henseende. Det bemærkes, af f.eks. Opus bruger FMK-snitfladeversionerne 1.2.2, 1.2.4 og 1.2.6. Der er derfor ikke øget risiko for datafejl eller andre fejl ved forskellige anvenderes samtidige kald til forskellige snitfladeversioner på samme service. Der er dermed ikke risiko for at ødelægge snitflader for de andre regioner på miljøerne.

Kommentarer til arbejdsnotatet 6/6 Er end-to-end testforløb mulige? Svar: Ja, ikke blot mulige, men helt oplagte Der er samme muligheder som i produktionsmiljøet Projektet giver det tekniske fundament til end-to-end testforløb. Der ligger en ikke ubetydelig opgave i koordinering af testforløb på tværs af organisationer, f.eks. hvis en region ønsker at gennemføre et testforløb i samarbejde med et antal LPS-leverandører eller med andre regioner. Denne opgave varetages bilateralt af anvenderne, dog vil det være oplagt at koordinere med FMK eller MedCom, så der sikres passende brede testforløb med relevante anvendere involveret.

Øvrige kommentarer Emner til intern afklaring i regionerne Opdateringsfrekvens for dynamiske stamdata Roller og certifikater Økonomi Ønske om bedre beskrivelse af stamdata Opdateringsfrekvens for dynamiske stamdata: Regionerne dikterer og NSI sørger for implementeringen af politikken Roller og certifikater: Alle regionerne har en LRA (Local Registration Authority), der kan varetage opgaven med at oprette og forny testcertifikater. Økonomi: Mette Harbo og Lene Ærbo er i dialog og vil udsende information omkring økonomi for projektet. Ønske om bedre beskrivelse af stamdata: Der er på nspop.dk netop offentliggjort beskrivelser af stamdataregistre, og mere information forventes at tilflyde løbende.

Processen fremadrettet Aktiviteter pågår parallelt Møderække Milepæle for at sikre og synliggøre fremdrift Møderækken blev aftalt ændret, således at der afholdes følgende møder, alle med “tung” dagsorden: Onsdag d. 7/11 i Århus. Torsdag 22/11 i Kbh. Mandag d. 3/12 i Århus Tirsdag d. 18/12 i Kbh. Med disse ændringer tilgodeses dels ønske fra RM om ændring af ugedag, dels afholdes færre møder, da der er opnået et godt udgangspunkt på det første møde. Jørgen Hougaard sætter evt. et møde op med RM, hvor de vigtigste pointer fra nærværende møde opsummeres. Christian Ernstsen udsender forslag til dagsorden og indkaldelser. I forhold til aktiviteterne bemærkes det, at projektet bør stille krav til de to sidste aktiviteter på figuren: Implementering og Uddannelse/støtte.

De fire milepæle: Milepæl 1 1. november 2012: Adgang til TEST2 TEST2 er ved milepæl 1 det eksisterende NSP FÆLLESTEST konfigureret til at bruge det eksisterende FMK FÆLLESTEST Planlagte udeståender Sammenhængende testdata …herunder testdatascripts og fælles stamdata Ind- og udlæsning af kliniske data (dump/restore) DoDi ikke inkluderet endnu Aktiviteter Teknisk afprøvning af TEST2 Vurdering af brugbarhed af miljøet

De fire milepæle: Milepæl 2 15. november 2012: Adgang til PRODTEST Nyt NSP miljø konfigureret til brug af det eksisterende FMK PRODTEST Samme udeståender som ved milepæl 1 Miljøet tilgås over SDN Aktiviteter Som ved milepæl 1 …dog ekstra opgaver forbundet med afprøvning over SDN

De fire milepæle: Milepæl 3 15. december 2012: Sammenhængende testdata TEST2 og PRODTEST udvides med funktionalitet til sammenhængende testdata Teknisk: Dump/Restore i FMK og DDV Organisatorisk: Funktionelle scripts leveres af NSI, og testdata kan oprettes ved både NSI-afvikling og egen afvikling af scripts CPR-lister administreres af NSI (gennem NSP-operatøren) Aktiviteter Det afprøves hvordan Dump/Restore virker i praksis i forhold til de konkrete behov Teknisk og konceptuel validering af at det leverede opfylder ønsker og behov

De fire milepæle: Milepæl 4 31. december 2012: Alle miljøer etableret Miljøerne UDD og TEST1 oprettes på basis af PRODTEST og TEST2 Den færdige dokumentationspakke leveres De aftalte miljøer er klar til ibrugtagelse Supportfunktionen er klar til håndtering af de nye miljøer Aktiviteter Forankring i organisationerne (SSI) Opsamling på eventuelle ændringsønsker fremkommet i processen

Opgaver hos parterne Parallelle forløb: NSI, NSP, FMK og regionerne NSP-operatøren Definere arbejdsgange i forhold til anvendelse og administration (”governance”) Udvide eksisterende scripts (herunder kravspecificere på baggrund af arbejdsgruppens konklusioner) Etablere fire miljøer Levere teknisk dokumentation FMK og DDV Udvide med ny snitflade (Dump og Restore) Etablere passende testmiljøer SSI/NSI Projektledelse Anvenderorienteret dokumentation

Opgaver hos parterne Regionerne Deltagelse i møder til afklaringer og orientering Udarbejdelse af fælles spilleregler Dækker også eventuelle præciseringer af miljøerne SLA-krav til de enkelte miljøer Aftestning af leverancerne ved de enkelte milepæle Region Nord melder ind med særligt engagement i forhold til teknisk aftestning. Det bemærkes, at RN har konkrete behov i forhold til anvendelse af et fælles testmiljø snarest, da deres leverandør afleverer en opdatering i november, og denne ønskes testet op mod FMK. Dette opfyldes umiddelbart af leverancen i milepæl 1, og projektet holder alle parter, i særdeleshed RN, orienteret om eventuelle tidligere leverancer, der kan påvirke RN testforløbet positivt i forhold til kalendertid.

Emner til næste møde? Følgende emner blev foreslået til næste møde: - Evaluering af TEST2 - Status på dokumentation NSI (Christian Ernstsen) udsender et forslag til dagsorden, hvor ovenstående indgår, sammen med projektstatus og eventuelle problemstillinger/afklaringer, der er opstået i mellemtiden.