US AARH. Notat vedrørende OpenTele og KIH Database snitflader og kommunikation

Transkript

1 US AARH Notat vedrørende OpenTele og KIH Database snitflader og kommunikation Opgave vedr. vurdering / dokumentation for snitflader mellem OpenTele og KIH Databasen Version 1.0, 1. april 2015 Michael Christensen, Institut for Datalogi, Aarhus Universitet Institut for Datalogi Aarhus Universitet IT-Parken, Åbogade Aarhus C Tlf.: Fax: cs@au.dk

2 Indhold Introduktion Resumé af anbefalinger KIH Databasen / Dokumentation / Udstillede services / Monitoring Dataset Service - MDSS / KIH Databasen og internationale standarder (IHE og HL7) / HL7 PHMR og XDS / Benyttede snitflader og services / NSP / Sundhed.dk / Laboratoriedatabank / Arkitektur og modulopbygning OpenTele Server / Dokumentation / Snitflader med lokale opsamlingsenheder / OpenTele 2.x JSON / Snitflader i fht. regional og national infrastruktur / OpenTele 2.x arkitektur Referencer Appendix A - KIH DB verifikation af web services... 22

3 Introduktion På opdrag af Center for Telemedicin, Region Midtjylland, er der udført der en teknisk undersøgelse af KIH Databasen og OpenTele. Undersøgelsen har fokuseret på vurdering af snitfladerne mellem OpenTele og KIH databasen, samt systemernes nuværende stade af modulopdeling. Snitfladerne er især vurderet med henblik på om / i hvor høj grad der er anvendt internationale standarder (IHE og HL7). Det er ligeledes vuderet om / i hvor høj grad snitflader og dataformater er dokumenterede og om der er åbenlyse mangler. Resultatet af den tekniske undersøgelse er dokumenteret ved nærværende notat, som dels opridser konklusioner i fht. systemernes nuværende status i fht. de nævnte fokusområder, dels opridser anbefalinger og ændringsforslag. Følgende har været i fokus for undersøgelsen: KIH Database med fokus på: o o o o snitflader og kommunikation i fht. datakilder (herunder OpenTele) snitflader og kommunikation i fht. dataanvendere krav og/eller begrænsninger i fht. indholdsformater (data/dokumenter) modul-, komponent og kommunikationsstrukturer OpenTele Server med fokus på: o o snitflader og kommunikation i fht. regionale og nationale infrastrukturer (KIH Database) Nye modul-, komponent og kommunikationsstrukturer i fht. status i fb. med OpenTele analyserapport Denne tekniske undersøgelse fokuserer således på en begrænset mængde egenskaber ved systemerne, især: Graden af anvendte standarder, navnligt med orientering mod sættet af standarder anbefalet i [RefArkBorger] og [RefArkDok]. Afhængigheder mellem overordnede moduler og koblinger mellem hovedkomponenter. Notatets forfatter har i øvrigt fra starten været opmærksom på den mere generelle undersøgelse og evaluering af KIH Databasen, som Lakeside har foretaget. I den anledning har notatets forfatter været i kommunikation med Jan Riis hos Lakeside og i øvrigt sidst i forløbet læst og kommenteret på dennes rapport. Baggrundsmateriale: For KIH Databasens vedkommende er der anvendt dokumentation tilgængelig via 4s-online.dk ( og kildekode tilgængelig via 4S kodedepot på Bitbucket ( For OpenTeles vedkommende er der anvendt et pre-release af dokumentationen for OpenTele 2.x og et pre-release af kildekoden for OpenTele 2.x. Disse er i skrivende stund ikke tilgængelige via hhv. 4S-online og 4S Bitbucket, men kan indtil da rekvireres hos notatets forfatter. Metode: Notatet er blevet til via en kritisk, teknisk orienteret gennemgang af dokumentation sammenholdt med analyse af relevante dele af kildekoden for de involverede systemer. Som pejlemærker har analysen anvendt nationale referencearkitekturer, nationale standarder, internationale standarder og anbefalinger. Disse er løbende gennem notatet refereret, hvor relevant. Afgrænsninger: Dette notat har udelukkende fokus på de ovennævnte emner og er ikke en generel teknologi- og/eller modenhedsvurdering af de involverede systemer og indeholder således f.eks. ikke analyse og anbefalin- Side 3/22

4 ger vedrørende performance og andre non-funktionelle kvaliteter. For sådanne henvises til den kommende rapport om KIH Databasen fra Lakeside og til [OT_ANALYSE2014]. Rammerne for notatet har ikke tilladt interaktion, i form af eksempelvis interviews, med teknologiernes kerneinteressenter. Notation: Der refereres i dokumentets brødtekst til notatets forfatter som MC/AU. Eksplicitte anbefalinger er anført i de enkelte afsnit under overskriften Anbefalinger: Medmindre der eksplicit er anført ekstern kilde i figurtekst, så er diagrammer og figurer i dette notat udført af notatets forfatter og dermed et udtryk for dennes fortolkninger og analyse. Side 4/22

5 1.0 Resumé af anbefalinger Nedenfor listes notatets anbefalinger i forkortet form. Bemærk: Anbefalinger er ikke i prioriteret rækkefølge. MC/AU er til rådighed for en nærmere diskussion af prioritering. KIH Database Dokumentation (afsnit 2.1) 1. Referencer og snitfladdokumentation: Der bør ryddes op i uklarheder og mangler. 2. Afspejling af nuværende situation: Dokumentation bør klart afspejle, hvad der er nuværende status for systemet. Udstillede Services - Monitoring Dataset Service - MDSS (afsnit 2.2.1) 1. Inaktive snitflader: Ældre, ikke længere aktive versioner af snitfladen bør fjernes. 2. Dokumentation: Dokumentationen er uklar med hensyn til MDSS og anvendte versioner af denne. Dette bør rettes op og der være mere detaljeret dokumentation af selve anvendelsen. Udstillede Services - KIH Databasen og internationale standarder (IHE og HL7) (afsnit 2.2.2) 1. XDS test: Der bør gennemføres tests og yderligere verifikation af at KIH Databasen opfylder kravene til at agere som XDS.b Repository aktør (IHE Test Tools og IHE Connectathon). 2. ATNA: Det bør eksplicit undersøges og dokumenteres, hvordan og om KIH Databasen opfylder kravene i IHE ATNA integrationsprofilen. 3. Dataverifikation: Det bør overvejes, om man ved registrering af dokumenter ønsker verifikation af korrekte metadata, samt evt. verifikation af understøttede/ønskede indholdsformater. 4. Dokumentation: Der bør udformes mere konkret teknisk dokumentation af de implementerede XDS-snitflader. 5. Pilottest: Der bør gennemføres egentlige pilottests af KIH Databasen som XDS aktør. HL7 PHMR og XDS (afsnit 2.3) 1. MDSS, XDS og PHMR: Afhængigheder mellem specifikationerne af disse og deres konkrete implementeringer i KIH Databasen og OpenTele bør analyseres, og hvis muligt bør den tekniske implementering og arkitektur reducere konsekvenser af ændringer i en eller flere af disse. 2. PHMR og XDS metadata profiler: Det bør udredes om KIH databasen lever op til de danske profileringer af HL7 PHMR og XDS metadata. Benyttede snitflader og services - NSP (afsnit 2.4.1) 1. NSP og stamdata snitflader: Snitflader til indsamling af stamdata fra NSP og andre datakilder bør afklares og implementeres. Benyttede snitflader og services - sundhed.dk (afsnit 2.4.2) 1. Sundhed.dk og datainkonsistens: Inkonsistens/asymmetri mellem data inddateret via XDSsnitflader og data inddateret via MDSS bør elimineres. Man bør først se på en løsning, hvor sundhed.dk indgår som decideret XDS dokumentanvender. Arkitektur og modulopbygning (afsnit 2.5) 1. Det bør overvejes om man bør lave en yderligere separation of concerns og udskille XDS- og PHMR-delene af KIH Databasen til helt separate applikationer. PHMR eventuelt til OpenTele. OpenTele Server Dokumentation (afsnit 3.1) 1. Afspejling af nuværende situation: Dokumentation bør klart afspejle, hvad der er nuværende status for systemet. 2. Navngivning: Der bør anvendes mere konsistent navngivning, når der tales om dele af systemet. Side 5/22

6 Snitflader med lokale opsamlingsenheder (afsnit 3.2) 1. Standardisering: Der bør laves et design for, hvordan OpenTelekommunikationen mellem klienter og serverdel kan bringes til at leve op til anbefalingerne i [RefArkBorger] og To-be arkitektur i [OT_ANALYSE2014]. Der bør i sammenhæng hermed ses på en mulig anvendelse af HL7 spørgeskemastanderne og sammenhæng med 4SDC-modulerne. 2. Genbrugelighed: Alle komponenter som har at gøre med serialisering/deserialisering/berigelse af de standardiserede formater bør så vidt muligt designes og implementeres som selvstændige og genbruelige komponenter/services. Snitflader med lokale opsamlingsenheder - OpenTele 2.x JSON (afsnit 3.2.1) 1. Konsolidering af snitflader: Man bør lave en nærmere analyse af de nu to eksisterende snitflader mellem OpenTele Borger Services og OpenTele klienter, og dette, sammenholdt med anbefalinger omkring den standariserede vej udstukket i [RefArkBorger], bør udmunde i et roadmap og design for entydig og standardiseret snitflade i forhold til klienter af alle typer. 2. HL7 FHIR: I forbindelse med eventuel konsolidering / yderligere udbygning af API( er) bygget over RESTful principper bør det undersøges om der kan bygges ovenpå / forlængelse af HL7s FHIR rammeværk [HL7FHIR]. Snitflader i fht. regional og national infrastruktur (afsnit 3.3) 1. Centralt opsamlingspunkt: Der bør overvejes at gøre OpenTele serverdelen til et selvstændigt centralt opsamlingspunkt ved at gøre den til en XDS dokumentkilde og ved at løfte PHMR genereringen fra KIH Databasen til OpenTele. 2. PHMR og XDS metadata: Det bør udredes hvilke organisationsidentifikationer og stamdata, som OpenTele har ansvar for at indhente og mangler bør implementeres, så OpenTele og KIH Database komplekset er i overensstemmelse med og kan afprøve anvendelsen af den danske profilering af PHMR [MEDCOM_PHMR] og den danske profilering af XDS metadata [XDSMETA_DK]. OpenTele 2.x arkitektur (afsnit 3.4) 1. Løs kobling: Der bør laves en nærmere analyse og undersøges designs/arkitekturmønstre for en endnu løsere kobling mellem OpenTele systemets hovedkomponenter. Side 6/22

7 2.0 KIH Databasen I dette afsnit gennemgås KIH Databasens udstillede og benyttede eksterne snitflader samt krav og begrænsninger i forhold til indholdsformater. Desuden gennemgås systemets overordnede struktur. Systemet gives følgende overordnede karakteristik i dokumentationen: KIH databasen er et centralt nationalt system, som opsamler, bevarer og tilgængeliggør telemedicinske måle- og monitoreringsdata på tværs af systemer og sektorer [KIHDB_KS2014] Diagrammer og nedenstående gennemgang er resultat af dels en gennemlæsning af KIH Databasens dokumentation, dels af analytiske punktnedslag i kildekoden for systemet. 2.1/ Dokumentation Mht. dokumentation så virker den overordnet af udemærket kvalitet. På visse punkter bør det dog prioriteres at få ryddet nogle uklarheder af vejen. Det gælder især: Uklare og/eller manglende referencer til eksterne dokumenter. Uklar og/eller manglende dokumentation for understøttede og anvendte web service snitflader. Forvirring omkring om dokumentationen afspejler nuværende situation eller ønskede/mulige fremtider. Mht. det sidstnævnte, så det glimrende at medtage mulige fremtider i dokumentation - især når det har indflydelse på arkitektur og design. Men der bør eksempelvis ryddes op/ud i sætninger som (MC/AUs fremhævninger i kursiv): De overordnede sammenhænge som er eller på kort sigt forventes - etableret i systemkomplekset KIH Databasen indgår i, illustreres nedenfor med udgangspunkt i snitfladerne mellem systemernes komponenter. [KIHDB_AD2014] Det er desuden MC/AUs erfaringer med opsætning af miljø til videreudvikling af KIH Databasen at der med fordel fra guiden til videreudviking [KIHDB_GU2014] kan refereres til systemets øvrige dokumentation. Dette gælder især dele af den såkaldte systemdokumentation [KIHDB_SYS2014]. Anbefalinger: 3. Referencer og snitfladdokumentation: Der bør ryddes op i uklarheder og mangler. 4. Afspejling af nuværende situation: Dokumentation bør klart afspejle, hvad der er nuværende status for systemet. Hvor der tales om mulige/planlagte fremtidsscenarier skal dette stå klart i fht. dokumentationen af det nuværende system. 2.2/ Udstillede services Dette afsnit gennemgår de services, som KIH Databasen udstiller overfor eksterne systemer KIH Databasen udstiller overordnet to grupper af web services: Web services baseret på den såkaldte Monitoring Dataset Service (MDSS) Web service baseret på IHE XDS.b profilen Jf. Figur 1, næste side. Side 7/22

8 Figur 1 KIH Databasens udstillede og benyttede snitflader 2.2.1/ Monitoring Dataset Service - MDSS Via MDSS udstilles håndtag til at hente, uploade og slette monitoreringsdata. MDSS benyttes af Opentele Server til upload af data og af sundhed.dk til hentning af data (jf.! Figur 1). Når data uploades via MDSS (fra OpenTele) gemmes data i den såkaldte måledata del af KIH Databasens underliggende SQL-database (databasen er delt op i måledata, XDS dokumenter, hændelseslog og brugere og rollerettigheder ). MDSS er oprindeligt baseret på MedComs specifikation af Den Gode Kroniker Service [DGKS2012], med fokus på data segment 15 vedrørende Monitorerings og måledata. I løbet af KIH projektet er der dog videreudviklet på MDSS og i alt udstiller KIH Databasen tre varianter af snitfladen: to varianter af MDSS v1.0.1 og en variant af MDSS v I KIH Databasens dokumentation af Kronikerservice [KIHDB_KS2014] er MonitoringDataset service v opført som selvstændig reference, men uden videre kildeangivelse 1. Ifølge dokumentationen [KIHDB_AD2014] benytter sundhed.dk MDSS v1.0.1 til udtræk af data og en granskning af kildekoden for OpenTele Server tyder på at samme version (v1.0.1) benyttes til upload herfra. Det er uklart om nogen eksterne systemer anvender MDSS v1.0.2 snitfladen. Ifølge [KIHDB_AD] autentificerer MDSS-snitfladen ved hjælp af Den Gode Web Service og ifølge [KIHDB_KS2014] anvender nogle versioner af snitfladen derudover den såkaldte Healthcare Service User Identification (HSUID) header [HSUID2013]. HSUID bruges til informationer om brugeren af de sundhedsfaglige services, hvad enten brugeren er borger eller sundhedsperson. Men da den specifikke anvendelse af DGWS og HSUID ikke er nærmere dokumenteret, og da det er udover nærværende notats rammer nærmere at analysere sikkerhedsaspekter, er det uklart om/hvor der udelukkende er tale om system-tilsystem autentificering, og om/hvornår der anvendes stærkere autentificering (noget af dette kan sandsynligvis udredes via [DGKS2014_2]). Anbefalinger 3. Inaktive snitflader: Ældre, ikke længere aktive versioner af snitfladen bør fjernes. Da mængden af eksterne systemer, som i øjeblikket benytter KIH Databasen er lille, bør dette være en overskueligt opgave. 4. Dokumentation: Dokumentationen er uklar med hensyn til om MDSS er en servicesnitflade og/eller et indholds- og lagringsformat, og hvordan dette forholder sig til betegnelsen Den Gode 1 Under udformningen af dette notat er MC/AU dog via MedCom blevet opmærksom på [DGKS2014] og [DGKS2014_2]. Dokumentationen for KIH Databasen bør sandsynligvis henvise til disse og angive systemets specifikke fortolkninger af de generelle snitfladebeskrivelser. Side 8/22

9 Kroniker Service, Kronikerservice og Den gode KIH-service (jf. fodnote 1). Dette bør stilles klart op, og der bør være en klar og detaljeret definition af MDSS og den specifikke anvendelse. Dokumentation for såvel KIH Databasen som for OpenTele efterlader desuden uklarhed omkring, hvilke dele/versioner af MDSS-snitfladen, der er i aktiv brug og/eller bør være det. Der bør ryddes op i versionsnumre på MDSS web services (i [KIHDB_KS2014] tales der f.eks. om v1, v2 og v3), og det bør fremgå klart, hvilken version der anbefales til hvilken brug / KIH Databasen og internationale standarder (IHE og HL7) Ifølge dokumentationen kan KIH databasen indgå i en XDS arkitektur som et XDS.b Document Repository [KIHDB_AD2014]. Dvs. hvis KIH Databasen sammensættes med XDS.b Document Registry aktør, så understøtter den umiddelbart upload, registrering og udtræk af dokumentbaserede data på XDS-vis. Dette giver sig i koden udtryk dels i at systemet udstiller web services svarende til Provide and Register Document Set - b (ITI-41) og Retrieve Document Set (ITI-43) - jf. " Figur 1- dels i at der kaldes en web service svarende til Register Document Set -b (ITI-42) - jf. # Figur 1. Dette svarer til det nedre del af Figur 2. Figur 2 Cross Enterprise Document Sharing - Actors & Transactions [IHEWIKI_XDS] MC/AU har verificeret tilstedeværelse og understøttelsen af disse snitflader ved kodegranskning og ved basal verifikation af kørende officiel testinstans af KIH Databasen samt kørende version af open source version, jf. Appendix A. Bemærk i den sammenhæng, at, omend den generelle XDS-funktionalitet forklares helt overordnet i dokumentationen (med referencer til IHE-dokumenter), så savnes der mere konkret teknisk dokumentation af de implementerede snitflader. Der er umiddelbart ikke begrænsninger på typerne af dokumenter som kan modtages og udtrækkes via de udstillede XDS-snitflader. Dette er i overensstemmelse med IHEs generelle koncept omkring XDS som værende document content neutral [IHEWIKI_XDS]. Der kræves således heller ikke nogen form for verifikation i forhold til dokumenter, som modtages på en ITI-41 service. En implementering af dette kan overvejes, især hvis KIH Databasen i fremtiden skal benyttes som generelt XDS Repository for en række forskellige telemedicinske datakilder. Af hensyn til genbrug, performance og konsistens i fht. andre komponenter, som fungerer som XDS aktører, bør en sådan verifikation implementeres som en løst-koblet komponent og/eller service (kunne f.eks. være en infrastrukturkomponent under governance af 4S [4S]). Side 9/22

10 Bemærk at, udover snitfladerne illustreret ved Figur 2, så afhænger XDS profilen af to andre IHE integrationsprofiler, Audit Trail and Node Authentication (ATNA) [ITI-TF1, s. 68] og Consistent Time (CT) [ITI-TF1, s. 59]: Figur 3 Uddrag af Table 2-1 Integration Profile Dependencies, [ITI-TF1, s. 21]. [ITI-TF1, s. 14] gør det klart at An actor must implement all required transactions in the prerequisite profiles in addition to those in the desired profile. Overordnet sætter ATNA-profilen krav op omkring brugerautentificering, forbindelseautentificering og auditlogging. CT-profilen sikrer synkroniseret tid og konsitente tidsstempler på tværs af netværkskomponenter. Det har været udover nærværende notats rammer at undersøge nærmere om KIH Databasen kan siges at understøtte disse profiler, eller i afkræftende fald, hvor omfattende en evt. implementering af disse profiler er. Det kan dog konstateres, at der eksempelvis i forbindelse med understøttelse af ATNA og CT kan være krav til opsætning af web service container (f.eks. for den specifikke understøttelse af TLS-kommunikation) og opsætning af driftsplaform (tidssynkronisering i fht. NTP). Sådanne krav og/eller instruktioner har ikke kunnet findes i dokumentationen for KIH Databasen. Så vidt MC/AU er informeret har KIH Databasens XDS-relaterede snitflader ikke været aktivt anvendt i KIH og TeleCare Nord projekterne eller på anden vis været testet i pilottest/-drift. Dog har KIH Databasen nyligt (marts 2015) været demonstreret som XDS Document Source og Repository i laboratoriebaseret testsetup i regi af det såkaldte Initiativ 1.4, spor 2 i sammenhæng med NSP Dokumentdelingsservices (DDS), som anvendte Healthshare Foundation som XDS Registry, og med en EOJ-aktør (KMD), som dataanvender. Rapport angående dette er under udarbejdelse hos Alexandra Instituttet. Anbefalinger 6. XDS test: Der bør gennemføres tests og yderligere verifikation af at KIH Databasen opfylder kravene til at agere som XDS.b Repository aktør. a. Etablering og dokumentation af lokalt testsetup, f.eks. med anvendelse af IHE Test Tools [IHEWIKI_TEST] b. Gennemførelse af et IHE Connectathon [IHECONNECT] 7. ATNA: Det bør eksplicit undersøges og dokumenteres, hvordan og om KIH Databasen opfylder kravene i IHE ATNA integrationsprofilen. Herunder bør eventuelle krav til opsætning af web service container og opsætning af driftsplatform dokumenteres. 8. Dataverifikation: Det bør overvejes, om man ved registrering af dokumenter ønsker verifikation af korrekte metadata, samt evt. verifikation af understøttede/ønskede indholdsformater. 9. Dokumentation: Der bør udformes mere konkret teknisk dokumentation af de implementerede XDS-snitflader. 10. Pilottest: Der bør gennemføres egentlige pilottests af KIH Databasen som XDS aktør. Dvs. KIH Databasen bør både pilottestes som selvstændig XDS Repository aktør (ITI-42, ITI-43 og ITI-44) og som grupperet XDS Document Source og Repository (jr. afsnit 2.3/). En sådan pilot kunne typisk foregå i forlængelse af / sammenhæng med ovennævnte Initiativ 1.4, spor 2 demonstrationsaktiviteter. 2.3/ HL7 PHMR og XDS KIH Databasen indeholder muligheden for at generere HL7 PHMR dokumenter [MEDCOM_PHMR] og gemme og registrere dem i XDS. Dette gøres ved at et asynkront job med jævne mellemrum læser fra den underliggende SQL-databases måledata del og med udgangspunkt heri genererer dels XDS metadata, Side 10/22

11 dels et PHMR dokument. Dokumentet gemmes i den underliggende XDS dokument del af SQLdatabasen og metadata registreres i en tilknyttet, ekstern XDS Registry. Dette er overordnet skitseret i Figur 4. Figur 4 Konceptuel tegning af sammenhæng mellem KIH måledata og PHMR Dokumentet vil herefter kunne fremsøges i den eksterne XDS Registry og kunne udtrækkes via KIH Databasens Retrieve Document Set (ITI-43) snitflade (jf. jf. " Figur 1). Opbygningen af PHMR benytter Net4Care PHMR Builder [4S_PHMR]. PHMR dokumenterne genereres her i en totrinsproces: Først opbygger anvenderen af PHMR Builder (i dette tilfælde KIH Databasen) en såkaldt 'greencda' [HL7GCDA], som indeholder alle de dynamiske elementer i PHMR'en (oplysninger om patient, involverede klinikere/institutioner, målinger m.v.), dernæst overgives denne til selve builder'en, som så udfylder al den på forhånd givne, statiske information (OID'er m.v.). Med den nuværende rollefordelingen mellem KIH Database og OpenTele servere er det de data, som indløber via MDSS-snitfladen, som er kilden til oplysninger om eksempelvis den behandlende organisation. Et eksempel på, sådanne data, som udfyldes i greencda-delen af KIH Databasen, er det såkaldte custodian -element i PHMR (den ansvarlige organisation i fht. behandlingen). Dette er i den danske profil af PHMR specificeret til at skulle være koder fra SOR-registeret. På lignende vis er det også MDSS som er kilden til XDS metadata i KIH Databasen. Dvs. der er i KIH Database / OpenTele systemkomplekset en relativt stærk afhængighed mellem [MEDCOM_PHMR] og [XDSMETA_DK] på den ene side, og [DGKS2014_2] på den anden side. Udkastet til den danske XDS metadata profil specificerer desuden, at visse af disse elementer har CDA (jf. [XDSMETA_DK], dvs. PHMR-dokumentet, som kilde. Det bør afklares, hvordan det skal tolkes i ovenstående sammenhæng. Det har været udover dette notats rammer systematisk at analysere/efterprøve, om KIH Databasen lever op til [MEDCOM_PHMR] og [XDSMETA_DK]. Anbefalinger: 3. MDSS, XDS og PHMR: Afhængigheder mellem specifikationerne af disse og deres konkrete implementeringer i KIH Databasen og OpenTele bør analyseres, og hvis muligt bør den tekniske implementering og arkitektur reducere konsekvenser af ændringer i en eller flere af disse. Side 11/22

12 4. PHMR og XDS metadata profiler: Det bør udredes om KIH databasen lever op til de danske profileringer af HL7 PHMR og XDS metadata. jf. i øvrigt anbefalinger i afsnit 3.3/. 2.4/ Benyttede snitflader og services 2.4.1/ NSP Ifølge dokumentationen bruger KIH Databasen CPR/stamdata servicen udstillet på den Nationale Service Platform for at berige med CPR data i forbindelse med data udtræk og ved generering af PHMR dokumenter [KIHDB_AD2014]. Dokumentationen understreger i øvrigt at snitfladerne til evt. indsamling af stamdata fra NSP og andre datakilder ikke er færdigafklarede/designede. Anbefalinger: 1. NSP og stamdata snitflader: Snitflader til indsamling af stamdata fra NSP og andre datakilder bør afklares og implementeres. jf. i øvrigt diskussioner i afsnit 2.3/ og afsnit 3.3/ / Sundhed.dk KIH Databasen opdaterer et såkaldt Personaliseringsindeks hos sundhed.dk, for derved overfor sundhed.dk at indikere at databasen har data, som kan udstilles for den enkelte borger. KIH Databasen registrerer på denne vis hos sundhed.dk tilstedeværelsen af de enkelte målingsdata for individuelle borgere. Data kan herefter hentes via MDSS-snitfladen fra KIH Databasen til fremvisning for borgeren på sundhed.dk. Bemærk at dette introducerer en inkonsistens mellem data uploadet via MDSS-snitfladerne og data uploadet via XDS snitfladen ITI-41, idet sidstnævnte ikke registreres i sundhed.dk og heller ikke er tilgængelige via MDSS-snitfladen. Noget sådant ville kræve at indkomne dokumenter blev analyseret med henblik på, om de 1) er PHMR-dokumenter og 2) har måledata, som kan gemmes i KIH Databasens Måledata del (jf. Figur 4). Anbefalinger: 1. Datainkonsistens: Inkonsistens/asymmetri mellem data inddateret via XDS-snitflader og data inddateret via MDSS bør elimineres. Fremfor en løsning, hvor man bagudgenererer MDSSkompatible data fra PHMR bør man i tråd med [RefArkDok] og [RefArkBorger] først se på en løsning, hvor sundhed.dk indgår som decideret XDS dokumentanvender / Laboratoriedatabank KIH Databasen indeholder muligheden for at eksportere data til Laboratoriedatabanken. Der mangler dokumentation for dette, og det har været udover rammerne for dette notat at analysere nærmere på denne snitfalde. Der henvises i øvrigt til pointerne angående snitfladen anført i den kommende rapport om KIH Databasen fra Lakeside. 2.5/ Arkitektur og modulopbygning For en generel vurdering af KIH Databasens arkitektur og opbygning henvises til den kommende rapport fra Lakeside vedrørende KIH Databasen. Overordnet er KIH Databasen opbygget som en typisk Grails [GRAILS] applikation, og er som sådan en lagdelt arkitektur domineret af Model-View-Controller arkitekturmønstret. Kommunikation og snitflader med eksterne systemer er modulariseret ud i hver deres separate komponenter (Grails services / Spring Beans), og det gennemgående indtryk af koden er, at modul- og lagdeling er gennemtænkt og at koden har en god kvalitet. Det er dog også i den nuværende struktur tydeligt at KIH Databasen først er tænkt og designet som en Kronikerservice, understøttende kronikerdatasæt og snitflader relateret hertil. Først senere er PHMR og XDS funktionalitet kommet til som tilføjelser, der afhænger af den oprindelige struktur. Det kan overvejes om man i den sammenhæng bør lave en yderligere separation of concerns og udskille XDS- og PHMRdelene til helt separate applikationer. PHMR eventuelt til OpenTele jf. 3.3/ og XDS-delen som en enhed i sig selv. Sidstnævnte ville give yderligere fleksibilitet i forhold til at anvende/afprøve andre XDS produkter. Side 12/22

13 Anbefalinger: 1. Det bør overvejes om man bør lave en yderligere separation of concerns og udskille XDS- og PHMR-delene af KIH Databasen til helt separate applikationer. PHMR eventuelt til OpenTele jf. 3.3/ og XDS-delen som en enhed i sig selv. Side 13/22

14 3.0 OpenTele Server OpenTele som samlet system, gives i dokumentationen følgende karakteristik OpenTele datamonitoreringsplatformen er et monitoreringssystem dedikeret til central opsamling af telemedicinske målinger direkte fra borgere i deres hjem. [OT_AD2015] 3.1/ Dokumentation Figur 5 OpenTele systemkompleks iflg. [OT_AD2015] MC/AU har først relativt sent i denne proces haft adgang til et pre-release af dokumentationen for Open- Tele 2.x. Der har således ikke været mulighed for en detaljeret gennemgang af denne. Overordnet virker dokumentationen dog grundig og saglig. Anbefalinger: 3. Afspejling af nuværende situation: Dokumentation bør klart afspejle, hvad der er nuværende status for systemet. Hvor der tales om mulige/planlagte fremtidsscenarier skal dette stå klart i fht. dokumentationen af det nuværende system. (jf. sammen pointe for KIH Databasens dokumentation, afsnit 2.1/) 4. Navngivning: Der bør anvendes mere konsistent navngivning, når der tales om dele af systemet. Der tales f.eks. om OpenTele borger services, OpenTele Citizen server og OpenTele Datamonitorering Borger services. 3.2/ Snitflader med lokale opsamlingsenheder Overordnet kommunikerer OpenTele Borger Services med OpenTele klienter via HTTP og ved hjælp af HTTP GET og POST sendes data i OpenTele specifikke JSON-formater. Figur 6 Kommunikation mellem OpenTele Borger Services og OpenTele klienter Side 14/22

15 Fra OpenTele Borger Services til OpenTele klienter flyder hovedsageligt data indenfor følgende kategorier: Spørgeskemaer Målingsdata i form af grafer og tabeller (historiske data for patienten) Beskeder (fra kliniker til patient) Påmindelser og kvitteringer Fra OpenTele klienter til OpenTele Borger Services flyder hovedsageligt data indenfor kategorierne: Spørgeskemabesvarelser Beskeder (fra patient til kliniker) Dvs. spørgeskemabesvarelser indeholder såvel opsamlede måledata (blodtryk, puls o.l.) som svar på mere typiske spørgeskemaspørgsmål besvaret af brugeren ("Har du åndenød?", Er du utilpas? o.l.). Omend de nuværende snitflader og involverede dataformater er veldokumenterede (med muligt forbehold i fht. nedenstående OpenTele 2.x JSON tiltag) og åbne i den forstand at også kildekoden hertil er open source, så er denne kommunikationsform specifik for OpenTele platformen og ikke standardiseret. Det er MC/AUs vurdering at der i nær fremtid bør ses på hvor og hvordan de internationale standarder kan bringes i spil i forhold til kommunikationen mellem OpenTele klienter og OpenTele serversiden. Blandt de ovennævnte kategorier af data gælder dette især for spørgeskemaer og spørgeskemabesvarelser. Med hensyn til sidstnævnte kan [RefArkBorger] og Lakesides OpenTele analyserapport [OT_ANALYSE2014] med fordel genbesøges: I [RefArkBorger] angives følgende som logisk teknisk målbillede : Figur 7 'Logisk teknisk målbillede' fra [RefArkBorger] Det er således [RefArkBorger] s hovedanbefaling at man baserer sig dels på rammeværket fra Continua Health Alliance, som er en profilering af en række eksisterende standarder for kommunikation af data fra sundhedsfagligt måleudstyr, dels på den HL7-standard (PHMR) dels IHE Patient Care Device PCD-01. Med denne anbefaling sikres det, at referencearkitekturen også kan indgå i en internationalsammenhæng. Side 15/22

16 Og det hedder endvidere med [RefArkBorger] s ord: IHE PCD-01, Patient Care Device 01 transaktion, definerer en meget simpel beskedmekanisme, hvormed den lokale opsamlingsenhed kan overføre observationer fra måleudstyr. Formålet er at holde processering af måleenhed og lokalt opsamlingspunkt enkel, og dermed lade en sundhedsprofessionel tjeneste overføre budskabet til CDA dokument. Anvendelse af PCD-01 kræver at data konverteres til et anvendelsesorienteret dokumentformat, f.eks. PHMR ved aflevering af data til XDS infrastrukturen. Anvendelsen af PCD-01 og den underliggende HL7 ORU format er også anført i To-Be arkitekturen i Lakesides OpenTele analyserapport [OT_ANALYSE2014]. Med ovenstående i baghovedet er det således MC/AUs vurdering, at der bør ses på hvordan/om spørgeskemabesvarelser i OpenTele kan splittes op i en PCD-01 baseret del og i en mere klassisk spørgeskemabessvarelsesdel. Det er oplagt samtidigt at se på hvordan/om man også kan anvende og afprøve den danske profilering af HL7 spørgeskemastandarderne Questionnaire Form Definition Document (QFDD) og Questionnaire Response Document (QRD), som MedCom i øjeblikket står i spidsen for [MEDCOM_Q]. I forlængelse af dette bør det medtages, hvorledes relaterede CDA-dokumenter (PHMR og QRD) inddateres som sådanne i den centrale XDS infrastruktur. Et stærkt forsimplet muligt målbillede kunne i den sammenhæng se ud som følger: Figur 8 Et muligt målbillede for standardiseret kommunikation Men det skal understreges, at der bør en nærmere analyse til i forhold til anvendelsen af QFDD og QRD i denne sammenhæng, og at [RefArkBorger] ikke inkluderer dette eksplicit, men taler generelt om anvendelse af CDA-baserede formater. Det skal også nævnes at MC/AU er bekendt med at Alexandra Instituttet i forbindelse med forlængelse af TeleCare Nord projektet undersøger muligheden for at udskille OpenTele spørgeskemaeditoren som en helt selvstændig komponent, og netop muligheden for at anvende HL7 QFDD i denne sammenhæng. Der bør ligeledes i sammenhæng med en eventuel PCD-01 komponent ses på sammenhæng med det nye 4S Device Communication modul [4SDC], idet Continua Health Alliances anbefaling af PCD-01 bl.a. baserer sig på nem oversættelse fra standardfølgende kommunikationslag i forhold til måleenheder. Alle komponenter som har at gøre med serialisering/deserialisering/berigelse af de standardiserede formater bør så vidt muligt designes og implementeres som selvstændige og genbruelige komponenter/services. Anbefalinger: 3. Standarisering: Der bør laves et design for, hvordan OpenTelekommunikationen mellem klienter og serverdel kan bringes til at leve op til anbefalingerne i [RefArkBorger] og To-be arkitektur i [OT_ANALYSE2014]. Der bør i sammenhæng hermed ses på en mulig anvendelse af HL7 spørgeskemastanderne og sammenhæng med 4SDC-modulerne. 4. Genbrugelighed: Alle komponenter som har at gøre med serialisering/deserialisering/berigelse af de standardiserede formater bør så vidt muligt designes og implementeres som selvstændige og genbruelige komponenter/services / OpenTele 2.x JSON Med den såkaldte OpenTele 2.x er der etableret en ny variant af OpenTele JSON-snitfladen, som understøttes parallelt med den eksisterende snitflade. I [OT_SYS2015] introduceres den nye snitflade således: I OpenTele 2.x er der etableret en ny JSON snitflade. Tanken er, at den nye snitflade skal tilbyde en løsere kobling mellem OpenTele serveren og klienter der benytter snitfladen. Dette opnås ved i høj grad at basere designet af snitfladen på RESTful principper. Snitfladen er under udvikling, og er endnu ikke komplet i Side 16/22

17 forhold til de services OpenTele Citizen serveren tilbyder. Desuden er Android native klienten (endnu) ikke porteret til snitfladen. OpenTele Citizen serveren understøtter derfor stadig OpenTele 1.x JSON snitfladen, som dog på sigt forventes at udgå. JSON snitfladen benyttes af OpenTele HTML5 klienten. Figur 9 OpenTele 2.x platformens nuværende snitflader med klienter Med den sene tilgængelighed af OpenTele 2.x dokumentationen og den begrænsede natur af dokumentationen herfor, har det ikke været muligt indenfor dette notats rammer at evaluere dybere på dette nye tiltag. Umiddelbart er det dog MC/AUs vurdering, at en løsere kobling mellem OpenTele server(e) og klienter er en ønskværdig kvalitet for den samlede platform, og at bygge på RESTful principper virker i den sammenhæng som en fornuftig vej at gå. Det stiller dog også platformen overfor udfordringer, som bør adresseres snarligst: Den nye OpenTele 2.x JSON snitflade synes ikke umiddelbart at bevæge platformen nærmere en standardiseret tilgang som anbefalet i [RefArkBorger]. Det er en udfordring i forhold til Open- Tele som generel telemedicinsk dataopsamlingsplatform. Det er ikke i sig selv et problem at have flere forskellige klienter, som kan koble op mod samme centrale opsamlingspunkt. Det er tværtimod generelt ønskværdigt at understøtte dette. Men da der er ikke synes at være tale om to versioner af samme snitflade, men snarere tale om to væsensforskellige snitflader, så er der en ikke negligerbar vedligeholdelsesproblematik. Især da OpenTele native Android klient, i det mindste i en periode, antageligt vil videreføres, idet Open- Tele HTML5 klienten for nuværende kun understøtter et subset af OpenTele native Android klient (eksempelvis understøttes integration med måleapparater over Bluetooth og USB indtil videre ikke i HTML5 klient, jr. [OT_AD2015]). Anbefalinger: 3. Konsolidering af snitflader: Man bør lave en nærmere analyse af de nu to eksisterende snitflader mellem OpenTele Borger Services og OpenTele klienter, og dette, sammenholdt med anbefalinger omkring den standariserede vej udstukket i [RefArkBorger], bør udmunde i et roadmap og design for entydig og standardiseret snitflade i forhold til klienter af alle typer. 4. HL7 FHIR: I forbindelse med eventuel konsolidering / yderligere udbygning af API( er) bygget over RESTful principper bør det undersøges om der kan bygges ovenpå / forlængelse af HL7s FHIR (Fast Healthcare Interoperability Resources) rammeværk [HL7FHIR], som anvender RESTful principper i sammenhæng med bl.a. JSON og XML-formater. 3.3/ Snitflader i fht. regional og national infrastruktur I OpenTele 2.x håndteres kommunikation med regional og national infrastruktur af en OpenTele Kliniker Server (også kaldet OpenTele Kliniker Services). Denne kommunikerer med tre eksterne systemer: KIH Databasen National Service Platform (NSP) Milou Til Milou eksporteres opsamlede CTG-målinger, men MC/AU har ikke haft adgang til nærmere information vedrørende denne integration. Det følgende omhandler således de to førstnævnte. Som allerede forklaret under udredningen af KIH Databasens eksterne snitflader, så uploader OpenTele Kliniker Server opsamlede målinger i MDSS format (jf. afsnit 2.2.1/). Dette har MC/AU dog ikke kunnet finde nedskrevet nogetsteds i selve dokumentationen for OpenTele. En kort analyse af kildekoden tyder dog på at er MDSS, som benyttes og umiddelbart er snitfladekoden genereret ud fra en version af MDSS. Side 17/22

18 Den Nationale Service Platform benyttes i forbindelse med opslag af stamdata for borgere baseret på CPR-nummer 2. Så vidt MC/AU kan vurdere indhentes ikke andre organisationsidentifikationer fra NSP (eller andetsteds)og der udestår en udredning i forhold til generering af de nødvendige metadata for PHMR og XDS, jf. afsnit 2.3/. Figur 10 OpenTele Kliniker Servers kommunikation med eksterne systemer [RefArkBorger] s beskrivelse af det centrale opsamlingspunkt kan inddrages til vurdering af OpenTele platformens rolle i forhold til national/regional infrastruktur (jf. iøvrigt Figur 7 'Logisk teknisk målbillede' fra [RefArkBorger]): Det centrale opsamlingspunkt har systemmæssigt følgende funktionelle egenskaber: Modtagelse af måledata fra lokale opsamlingsenheder Berigelse af måledata og evt. veksling til patient-id Sikring af at de fornødne metadata findes og er korrekte for måledata Optræder som dokument kilde i forhold XDS infrastrukturen Leverer metadata til fremsøgning i IHE XDS Implementerer kobling mellem sikret og ikke sikret netværk (sundhedsdatanettet, som anvendes ved kommunikation mellem sundhedsvæsenets parter og det åbne internet) I henhold til dette kan OpenTele serverdelen ikke alene udfylde rollen som centralt opsamlingspunkt, idet den ikke optræder som dokumentkilde i forhold til XDS-infrastrukturen og heller ikke leverer metadata hertil. Dette er i hvert fald kun indirekte, i den grad at der via MDSS leveres data til KIH Databasen, som så til gengæld (jf. afsnit 2.2.2/) agerer kombineret XDS dokumentkilde og XDS repository, og som samtidigt i rollen som dokumentkilde står får generering af XDS metadata. Hvis OpenTele Borger Services sammen med OpenTele Kliniker Server skal påtage sig rollen som centralt opsamlingspunkt så skal man løfte PHMR genereringsdelen ud af KIH Databasen og over i OpenTele Kliniker Server. Dette ville umiddelbart give en arkitektonisk mere entydig rollefordeling mellem OpenTele og KIH Database og ville samtidigt stille OpenTele og eventuelt øvrige klienter til KIH Databasen lige. Dvs. OpenTele vil så agere som XDS Document Source og KIH Databasen udelukkende med rollen som XDS 2 Derudover er det angivet i dokumentationen at OpenTele anvender NSP ens STS-service til autentifikation af IDkort som NSP bruger ved opslag i KIH Databasen, Side 18/22

19 Document Repository. Det vil samtidigt betyde at indhentning af stamdata, officielle organisationsidentifikationer (fra SOR m.v.) og lignende umiddelbart burde kunne isoleres til OpenTele, som så alene står for berigelsen af PHMR før afsendelse til XDS infrastruktur. Dette vil eliminere udfordringer i forhold til den indirekte indhentning af metadata for PHMR-dokumenter og XDS metadata, som er nødvendig i KIH Databasen i dag, jf. afsnit 2.3/. Det skal understreges at såvel [RefArkBorger] som IHE XDS profilerne ikke udelukker den nuværende konstruktion, men da man allerede nu med den asymmetriske konstruktion har udfordringer i forhold til inkonsistens for dataanvendere - jf. afsnit 2.4.2/ - bør ovennævnte løsning overvejes. Anbefaling: 3. Centralt opsamlingspunkt: Der bør overvejes at gøre OpenTele serverdelen til et selvstændigt centralt opsamlingspunkt ved at gøre den til en XDS dokumentkilde og ved at løfte PHMR genereringen fra KIH Databasen til OpenTele. 4. PHMR og XDS metadata: Det bør udredes hvilke organisationsidentifikationer og stamdata, som OpenTele har ansvar for at indhente og mangler bør implementeres, så OpenTele og KIH Database komplekset er i overensstemmelse med og kan afprøve anvendelsen af den danske profilering af PHMR [MEDCOM_PHMR] og den danske profilering af XDS metadata [XDSMETA_DK]. 3.4/ OpenTele 2.x arkitektur Den væsentligste ændring på OpenTele serverdelen, fra version 1.x til version 2.x, er at serverdelen nu er splittet i to separate serverapplikationer, som i dokumentationen [OT_AD2015] beskrives som følger: OpenTele borger services OpenTele borger services er en serverapplikation som er ansvarlig for JSON kommunikation med Open- Tele klienter vedr. spørgeskemaer, resultater og beskeder. OpenTele kliniker services OpenTele kliniker services er en serverapplikation med en klinisk brugergrænseflade, som anvendes til at administrere spørgeskemaer, patienter og monitoreringsresultater samt til kommunikation med patienter ved hjælp af et simpelt beskedsystem. Derudover har serveren også ansvar for at relevante målinger eksporteres til KIH Database og Milou. Disse to tilgår begge en fælles underliggende SQL-database og deler i funktionalitet via en ny sammensat komponent (et Grails plugin), som kaldes OpenTele Core plugin. Dette sidstnævnte indeholder ifølge dokumentationen komponenter vedrørende Auditlog og sikkerhed, Data Access Objects og Database. Den gennemførte opsplitning virker umiddelbart fornuftig ud fra især sikkerhedsmæssige perspektiver. Det forlanger dog en nærmere analyse om man ved opsplitningen også har opnået en løsere kobling mellem elementerne i OpenTele platformen. Netop ved at hele den underliggende datamodel umiddelbart er delt gennem det nye OpenTele Core plugin er der i hvert fald risiko for uforudsete bindinger og afhængigheder mellem kildekode/intern struktur af OpenTele Borger og OpenTele Kliniker del. Det bør undersøges om der er behov for en klarere opsplitning af datamodellen i fælles og separate dele. Generelt omkring mulighederne for en løsere koblet arkitektur og mulighederne for opsplitning af Open- Tele i mindre og separate services skal det nævnes at der netop i øjeblikket ses på disse ting i forbindelse med med forlængelse af TeleCare Nord projektet. Der vil igennem 4S blive initieret en åben proces, hvor disse emner kan diskuteres af såvel aftagere som leverandøreres arkitekter. Anbefaling: 1. Løs kobling: Der bør laves en nærmere analyse og undersøges designs/arkitekturmønstre for en endnu løsere kobling mellem OpenTele systemets hovedkomponenter. Side 19/22

20 Referencer [4S]: 4S, Stiftelsen for Softwarebaserede Sundhedsservices, [4SDC]: [4S_PHMR]: Net4Care PHMR Builder, [DGKS2012]: Den Gode Kroniker Service, MedCom, okt [DGKS2014]: Den Gode KIH-Service, web beskrivelse, MedCom, [DGKS2014_2]: Den gode KIH-service, version , MedCom, sept [GRAILS]: A powerful Groovy-based web application framework for the JVM, [HL7FHIR]: FHIR Fast Healthcare Interoperability Resources, summary, [HL7GCDA]: GreenCDA Project, [HSUID2013]: IFS0006 Health Service User Identification Header, Snitfladebeskrivelse, NPI Common, version 1.1, National Sundheds-IT, apr [IHEWIKI_XDS]: Cross Enterprise Document Sharing, Enterprise_Document_Sharing. [IHECONNECT]: IHE Connectathon, [IHEWIKI_TEST]: IHE Test Tool Information, [ITI-TF1]: IHE IT Infrastructure (ITI) Technical Framework Volume 1 (ITI TF-1) Integration Profiles, Revision 11.0, IHE International Inc., sept. 23, [KIHDB_AD2014]: KIH Database, Arkitektur og Design, sept [KIHDB_GU2014]: KIH Database, Guide til videreudvikling, sept [KIHDB_KS2014]: KIH Database, Kronikerservice - en teknisk guide, sept [KIHDB_SYS2014]: KIH Database, Systemdokumentation for KIH Databasen, sept [MEDCOM_PHMR]: HL7 Implementation Guide for CDA Release 2.0 Personal Healthcare Monitoring Report (PHMR) (Danish profile PHMR DK), Draft, Release 1.0, MedCom, juni [MEDCOM_Q]: Dansk profilering af HL7-spørgeskemastandarder: QFDD og QRD, [OT_AD2015]: OpenTele datamonitoreringsplatform, Arkitektur og design, marts [OT_ANALYSE2014]: OpenTele analyserapport, Analyse og arkitekturvurdering af Open Source platformen OpenTele, version 1.0, Lakeside, april [OT_SYS2015]: OpenTele datamonitoreringsplatform, Systemsnitflader, marts [RefArkBorger]: Referencearkitektur for opsamling af helbredsdata hos borgen, National Sundheds-it, juni 2013, %20dansk/Sundhedsdata%20og%20it/NationalSundhedsIt/Standardisering/Referencearkitektur%20for %20opsamling%20af%20helbredsdata%20hos%20borgeren%20v%20%201.ashx [RefArkDok]: Referencearkitektur for deling af dokumenter og billeder, National Sundheds-it, juni 2012, Side 20/22

21 %20dansk/Sundhedsdata%20og%20it/NationalSundhedsIt/Standardisering/Referencearkitektur%20for% 20deling%20af%20dokumenter%20og%20billeder%20v%20%201%200.ashx. [XDSMETA_DK]: XDS Metadata for Document Sharing, Danish profile, Draft profile for Trial Use, National Sundheds-it, jan Side 21/22

22 Appendix A - KIH DB verifikation af web services Via den offentligt tilgængelige testinstans af KIH Databasen er der, ved opslag på verificeret at følgende web services udstilles: Via instans af KIH Databasen baseret på 4S open source koden er det verificeret at tilsvarende sæt af web services som ovenfor udstilles: Side 22/22