KIH Database. Arkitektur og design. 12. september Side 1 af 24

KIH Database Arkitektur og design 12. september 2014 Side 1 af 24

Indholdsfortegnelse Indholdsfortegnelse Indledning Systemlandskab / Arkitekturoverblik Brugsscenarier Scenarie 1: Eksternt system indberetter telemedicinske målinger til KIH Databasen Scenarie 2: Administrator fremsøger indberettede data data for borger Scenarie 3: Administrator anvender hændelseslog Scenarie 4: KIH database opdaterer personaliseringsindeks KIH Database server-design/-arkitektur Væsentlige designparametre Applikationsarkitektur Komponentmodel Systemsnitflader Datamodel Model for brugere, roller og rettigheder Model for hændelseslog Model for målingsdelen af KIH databasen Model for XDS realisering i KIH Databasen Realisering af KIH databasens applikationsarkitektur Driftsarkitektur Overvejelser om skalering Referencer Dokumenthistorik Side 2 af 24

Indledning Dette dokument udgør den tekniske arkitektur og designdokumentation for KIH Databasen. KIH databasen er et centralt nationalt system, som opsamler, opbevarer og tilgængeliggør telemedicinske måle og monitoreringsdata på tværs af systemer og sektorer. Databasen modtager måle og monitoreringsdata fra f.eks. OpenTele datamonitorerings platformen eller andre systemer via udvalgte dele af webservicesnitfladen specificeret i Monitoring Dataset Service 1.0.1 samt 1.0.2 (MDSS). Derudover udstiller KIH databasen også XDS.b DocumentRepository snitflade. Databasens indhold stilles til rådighed for klienter via DGKS, MDSS, samt via HL7 PHMR (Personal Healthcare Monitoring Record) [PHMR] dokumenter i en XDS.b [XDS.b] baseret infrastruktur. Data stilles derudover til rådighed for patienter og sundhedsfaglige igennem sundhed.dk, som anvender MDSS 1.0.1 snitfladen. DGKS webservicen, der stiller data til rådighed for andre systemer, forventes etableret som en proxy service på den Nationale Service Platform (NSP) [NSP], hvorfra brugere via EPJ og/eller f.eks. praksissystemer kan aflæse data. Adgang til databasens indhold håndteres som udgangspunkt ved brug af eksisterende sikkerhedsløsninger igennem Den Gode Web Werservice (DGWS). Arkitekturbeskrivelsen i nærværende dokument tager udgangspunkt i, at læseren har kendskab til tankerne bag KIH Databasen og den kontekst den skal fungere i. Specifikt berører dokumentet kun funktionaliteten og anvendelsen af systemet sporadisk med få udvalgte brugsscenarier, men fokuserer primært på de tekniske aspekter i arkitekturen. I de følgende afsnit beskrives KIH Databasens bestanddele. Først beskrives den overordnede systemkontekst platformen opererer i. Herefter gennemgås nogle udvalgte brugsscenarier og til sidst beskrives den tekniske arkitektur for henholdsvis platformen. Side 3 af 24

Systemlandskab / Arkitekturoverblik 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. Det fremhæves, at arkitekturen forventes at udvikle sig over tid. Det forventes, at der bliver etableret flere og flere integrationer mellem KIH databasen og andre eksterne systemer. Figur 1: Overblik over komponenter og sammenhænge i systemkomplekset KIH Databasen indgår i Systemkomplekset udgøres overordnet af fire komponenter, som i forhold til illustrationen ovenfor beskrives fra venstre side mod højre: 1. Decentrale opsamlingssystemer KIH Database gør det muligt for forskellige systemer, som indeholder telemedicinske data, at overfører målinger på en struktureret form til KIH Databasen. 2. KIH database KIH databasen er et centralt system på Sundhedsdatanettet, som via XML baserede Side 4 af 24

web service snitflader, modtager telemedicinske monitoreringsdata fra opsamlingsystemer, heriblandt OpenTele servere. KIH Databasens snitflader gør det også muligt for autentificerede brugere at hente data og indberette data f.eks. via EPJ systemer eller via sundhed.dk. På baggrund af de indberettede måling dannelse et HL7/PHMR dokument per indberetning. Disse dokumenter registreres i et XDS.b Document Registry. For nuværende forventes PHMR dokumenterne at blive registreret i NPI, men dette er administrativt slået fra mens de sidste afklaringer om den danske PHMR profilering forestår. 3. Personaliseringsindeks Sundhed.dk udstiller et Personaliseringsindeks, som anvendes til at registrere, hvilke systemer har data, som kan være relevant for sundhed.dk at udstille til en borger. Når der registreres en måling på en borger, bliver Personaliseringsindeks opdateret, med at pågældende borger har data i KIH Databasen. Selve opdateringen sker asynkront fra indberetningen af data. 4. XDS.b Document Registry KIH databasen indgår i en XDS arkitektur som et XDS.b Document Repository. KIH Database danne HL7/CDA/PHMR dokument på baggrund af de målinger, som indberettet til KIH Databasen. Dokumenterne generes i henhold til standard, og bliver generet en gang. Dokumenterne bliver registreret i et XDS.b Document Registry. Rollen som Document Registry for KIH Databasen forventes udfyldt af NPI. I det følgende afsnit beskrives nogle udvalgte brugsscenarier for KIH Databasen. Efterfølgende beskrives dens applikationsarkitektur. Side 5 af 24

Brugsscenarier I dette afsnit gennemgås nogle få udvalgte brugsscenarier for KIH Databasen. Scenarie 1: Eksternt system indberetter telemedicinske målinger til KIH Databasen Eksterne systemer indsamler telemedicinske målingsdata og indberetter disse til en central KIH Database. Antagelse: Det eksterne system sender webservice requests, som er autentificeret i henhold til DGWS. Skridt Eksternt system KIH Database 1 Sender webservice request med valid IDCard 2 Apache CXF Inbound interceptor (SosiInInterceptor) modtager beskeden, og validerer, at requested er autentificeret af STS en, samt at der IDCard i request er valid. Der ekstraheres ud fra IDCard information om det kaldende system for brug til audit log. I tilfælde af ikke validt request (ikke autentificeret, udløbet token etc), afvises requestet med en SOAP fault til det kaldende system. 3 Data request bliver parset og der gemmes data i databasen. 4 Der svares tilbage til afsender 5 System behandler svar Side 6 af 24

Scenarie 2: Administrator fremsøger indberettede data data for borger Administrator logger ind i webportal og fremsøger indberettede data for borger. Et forløb hvor administratoren som dataansvarlig er blevet bedt om at undersøge hvad der er indsendt data om en konkret patient. Antagelse: Administrator er logget ind i KIH Databasens administrative web baserede brugergrænseflade. Skridt Administrator KIH Database (web applikation) 1 Viser forside med menu punkter, samt søg patient indtastningsfelt, med mulighed for at søge efter en borger/patient 2 Indtaster patientens CPR nummer og trykker søg 3 Viser en linje med navn og CPR for patienten, som har det angivne CPR nummer 4 Trykker på linjen med patientens navn og CPR 5 Viser de stamdata KIH Databasen har om patienten. Dvs. navn og adresseoplysninger, samt en liste med målinger 6 Trykker på en af målingerne i listen for at se yderligere oplysninger om målingen 7 Viser er stamdata billede for målingen, hvor administratoren kan se målingen omfatter. F.eks. ID, oprettelsestidspunkt, målingstype, målepunkter, navn samt angivelse af, hvem der har indberettet målingen. 8 Trykker på et målepunkt for at få yderligere detaljer om dette 9 Viser detaljerede oplysninger om målepunktet. Scenarie 3: Administrator anvender hændelseslog Administrator anvender hændelseslog til at fremsøge handlinger relateret til en konkret borger/patient. Side 7 af 24

Et forløb hvor administratoren som dataansvarlig er blevet bedt om at undersøge hvem og hvornår der er indsendt data om en konkret patient, samt hvem der har hentet oplysninger om patienten. Antagelse: Administratoren er logget ind i KIH Databasens administrative web applikation. Skridt Administrator KIH Database (web applikation) 1 Viser forside med menu punkter, samt søg patient indtastningsfelt, med mulighed for at søge efter en borger/patient 2 Trykker på menu punktet Hændelseslog 3 Indtaster CPR nummeret på den patient der ønskes oplysninger om, vælger et tids interval og trykker søg 4 Viser en sorteret liste med de handlinger der er udført på patientens data i KIH Databasen i den angivne periode. 5 Gennemgår listen, og udvælger én hændelse som ikke umiddelbart burde forekomme 6 Trykker på den interessante hændelse for at se yderligere oplysninger om den 7 Viser detaljerede oplysninger om hændelsen 8 Noterer sig tidspunkt, brugernavn, IP adresse og system hvorfra hændelsen er udført 9 Kontakter det kaldende systems systemansvarlige og fortsætter undersøgelsen af hændelsen undenfor KIH Databasen. Scenarie 4: KIH database opdaterer personaliseringsindeks Sundhed.dk s personaliseringsindeks anvendes til at registrere, hvilke systemer har data for en borger. KIH Database udstiller hjemmemonitorningsdata til en viewer hos sundhed.dk. Linket til denne viewer, skal kun vises for borgeren, hvis borgeren har data i KIH databasen. Skridt KIH Database Personaliseringsindeks 1 KIH Database finder borgere, som ikke er registeret i Sundhed.dk s personaliseringsindeks. Dette styres ved hjælp af boolean værdien Side 8 af 24

inpersonalizationindex på Citizen domæne model objektet. 2 For hver borger, som ikke er registeret sendes et request til Personaliseringsindeks med CPR numret, og applikationsid for KIH Databasen 3 Personaliseringsindeks bliver opdateret og returkode bliver givet som svar. 4 I tilfælde af registeringen er gået godt, bliver feltet inpersonalizationindex sat til true, således at vedkommende ikke bliver registreret igen. Side 9 af 24

KIH Database server design/ arkitektur KIH databasen er som et centralt system, med en række snitflader til eksisterende eller kommende systemer. På nedenstående illustration skitseres den overordnede kontekst KIH databasen indgår i, med fokus på snitflader til andre systemer og datakilder. Figur 2: KIH Databasen i kontekst KIH databasen modtager monitoreringsdata fra f.eks. OpenTele platformen via dens snitflade. De modtagne data gemmes i systemets database og gøres tilgængelige for eksterne brugere. Efter data er gemt, bliver der via et asynkront job generet først et tilsvarende HL7 PHMR dokument, og på baggrund af dettes registreres dokumentet i KIH Databasen XDS.b Document Registry. KIH Databasen trækker på endvidere på bl.a. CPR service udstillet på den Nationale Service Platform (NSP) [NSP] for at berige med CPR data i forbindelse med data udtræk og generation af PHMR dokumenter. Data fra KIH Database udstilles til borgere og klinikere igennem Sundhed.dk, som trækker data fra MDSS snitfladen. Side 10 af 24

Autentificering af brugere baseres på medarbejdercertifikater med udgangspunkt i sikkerhedsmodellen beskrevet for Den Gode Webservice (DGWS) [DGWS 1.1]. Side 11 af 24

Væsentlige designparametre De non funktionelle krav til KIH databasen er ikke endeligt beskrevet. Der etableres derfor en fleksibel skalerbar applikationsarkitektur, ud fra den forventning, at systemet vil starte småt, men over en periode stille væsentlig større krav til afviklingsplatform med hensyn til performancekrav, transaktionsmængder, båndbredde, behov for diskplads mv. Grundlæggende for designet er, at KIH databasen i en indledende periode indeholder begrænsede mængder af data og kun forventes at have en meget begrænset mængde brugere. På sigt forudses KIH databasen at komme til at indeholde særdeles store datamængder. Anvendelsen af systemet forventes ligeledes at stige væsentligt over tid. Det er derfor væsentligt, at databasens arkitektur giver mulighed for skalering i forskellig grad. Både med hensyn til performance og transaktionsmængder, samt med hensyn til diskplads. I det følgende beskrives derfor en applikationsarkitektur, som lever op til ovennævnte designparametre, men som indledende kan realiseres i et forholdsvist lille teknisk setup. Applikationsarkitektur KIH databasen etableres med en lagdelt applikationsarkitektur, hvor de forskellige lag er ansvarlige for velafgrænsede elementer af arkitekturen. Herved sikres, lagene kan skaleres forskelligt, f.eks. ved at distribuere dem på forskellige platforme/servere. Den overordnede lagdeling er illustreret nedenfor: Side 12 af 24

Komponentmodel Figur 3: KIH databasens lagdelte logiske applikationsarkitektur Overordnet opdeles funktionaliteten i løsningen i en række adskilte komponenter, med hver deres egne ansvarsområder. Komponentmodellen for KIH databasen vises nedenfor. Figur 4: Overordnede bestanddele (komponenter) i KIH databasen Side 13 af 24

Komponenterne placeres på de forskellige lag i løsningen. I implementeringen er sikret, at følgende kriterier er opfyldt. Forretningsservicelaget og webservicekomponenten skal være tilstandsløse, således lagene kan skalere horisontalt, ved f.eks. tilføjelse af flere parallelle servere Den administrative brugergrænseflade er sessionsbaseret. Da brugergrænsefladen forventeligt har meget få brugere, skal den tekniske arkitektur sikre, at administratorerne altid rammer samme server indenfor samme session Al adgang til data, dvs. både skrivning og læsning, registreres i en auditlog Sikkerhed for services baseres på eksisterende standarder (DGWS) Systemsnitflader KIH databasen har to primære snitflader til eksterne systemer/datakilder, som skitseret og efterfølgende beskrevet nedenfor: Figur 5: KIH databasens primære snitflader Udstillede services: 1) MonitoringDataset webservice version 1.0.1 og 1.0.2 (MDSS) Servicen er etableret med udgangspunkt i MDSS 1.0.1 og anvendes til modtagelse af hjemmemonitoreringsdata. Snitfladen autentificerer ved hjælp af den eksisterende sikkerhedsmodel for web services på Sundhedsdatanettet (DGWS). 2) XDS.b Document Repository webservice KIH Database udstiller en XDS.b Document Repository snitflade, som muliggøre at hant PHMR dokument baseret på målinger i KIH Database som en del af en XDS arkitektur. Snitfladen autentificerer ved hjælp af den eksisterende sikkerhedsmodel for web services på Sundhedsdatanettet Den Gode Web Service (DGWS). Konsumerede services: Side 14 af 24

1) XDS.b Document Registry webservice KIH Database opdatere et XDS.b Document Registry på baggrund af de lagrede XDS dokumenter i KIH Databasen. 2) Personaliseringsindeks service KIH Databasen opdaterer Personaliseringsindekset hos Sundhed.dk i faste intervaller. Indekset opdateres med CPR nummer og KIH Databasens applikationsid. 3) Stamdata opslag KIH Databasen laver opslag mod StamdataLookupService på NPS en i forbindelse med PHMR generering og i forbindelse med, at der hentes data fra MDSS snitfladerne. Datamodel KIH Databasens underliggende datamodel er overordnet opdelt i tre dele: 1) Brugere og rolle rettigheder 2) Hændelseslog 3) Måledata 4) XDS dokumenter I det nedenstående gennemgås hver del af modellen kort, og illustreres med databasediagrammer baseret på en MySQL implementation. Model for brugere, roller og rettigheder I nedenstående illustration vises de entiteter der indgår i KIH databasens datamodel rettet mod brugere, roller og rettigheder. Side 15 af 24

Figur 6: Datamodel for brugere, roller og rettigheder Datamodellen for brugere, roller og rettigheder består af tre primære entiteter, samt mange til mange relationer mellem disse. I nedenstående tabel gennemgås entiteterne kort. Tabelnavn Users Role user_role Permission role_permission Beskrivelse Tabel indeholdende systemets brugere En rolle er en gruppering af rettigheder, som anvendes for at lette administrationen af systemet. De roller en bruger er tildelt. Tabellen modellerer en mange til mange relation, idet brugere kan have mange roller, og roller kan tildeles mange forskellige brugere. Systemets rettigheder Mange til mange relation, som udpeger de rettigheder der indgår i en rolle. Side 16 af 24

Model for hændelseslog Figur 7: Datamodel for systemets hændelseslog Tabelnavn audit_log_entry audit_log_parameter audit_log_controller_entit y Beskrivelse Tabel som indeholder en række per tilgang til KIH Databasen. Der logges både for web requests, såvel som web service request. Tabel som indeholder parameter i forbindelse med et request. Parameter er knyttet til en række i audit_log_entry tabellen. Lookup tabel, som logger Grails controller og actions på controlleren i til brug for visning i søgebilledet i hændelsesloggen. Side 17 af 24

Model for målingsdelen af KIH databasen Figur 8: Datamodel for målingsdelen af KIH databasen Tabelnavn Citizen self_monitoring_sampl e Beskrivelse Tabel, som anvendes til at gemme information omkring borgeren, som dikteret af MDSS 1.0.1 og MDSS 1.0.2 Tabel, som anvendes til at gemme information omkring en måling (SelfMonitoringSample), som matcher MDSS 1.01 og MDSS 1.0.2 laboratory_report Tabel, som anvendes til at gemme information omkring et målepunkt (LaboratoryReport og LaboratoryReportExtended) som matcher MDSS 1.0.1og MDSS 1.0.2 lab_producer Tabel, som matcher LabProducer information fra MDSS 1.0.1 og MDSS 1.0.2 Iupaccode Tabel, som matcher IUPACCOde fra MDSS 1.0.1 og MDSS 1.0.2 Instrument Tabel, som matcher Instrument på LaboratoryReportExtended fra MDSS 1.0.1 og MDSS 1.0.2 Side 18 af 24

Model for XDS realisering i KIH Databasen Figur 9 Datamodel for XDS struktur Tabelnavn xdsmetadata xdsdocument Beskrivelse Tabel som anvendes til at holde det serialiserede XDS metadata, som er generet i forbindelse med skabelsen af et XDS Dokument, eller som er brugt i forbindelse med upload af et XDS dokument til KIH Databasen Tabel, som anvendes til at gemme XDS dokument som er generet i forbindelse med skabelsen af et XDS Dokument, eller som er brugt i forbindelse med upload af et XDS dokument til KIH Databasen Realisering af KIH databasens applikationsarkitektur Applikationsarkitekturen for KIH databasen realiseres i et standard Java EE baseret setup, baseret på en, eller flere Java EE web containere, der kommunikerer med et underliggende databaselag, som skitseret på nedenstående illustration. Side 19 af 24

Figur 10: Overordnet realiseres KIH databasens applikationsarkitektur med en Java EE web container og en SQL database Applikationsarkitekturen er udvidbar, således der kan tilføjes flere parallelle Java EE web containere, eller f.eks. databaseservere hvis systemets belastningsprofil viser det nødvendigt. I realiseringen af applikationsarkitekturen forventes følgende komponenter / frameworks anvendt: Grails (Groovy baseret web framework bygger ovenpå Spring) Seal.JAVA (Håndtering af sikkerhed jf. DGWS) Apache CXF (Web services) JEE Web container SQL Database (MySQL eller anden SQL database) Driftsarkitektur Applikationsarkitekturen realiseres med nedenfor skitserede overordnede driftsarkitektur. Arkitekturen skal kunne skalere horisontalt og vertikalt. Således det er muligt at skrue op for kapaciteten i de forskellige lag i løsningen, både ved at udvide hardwarekapacitet og ved at etablere parallelitet i arkitekturen. Produktnavne mv. i nedenstående illustration forventes at ændre sig i forbindelse med, at arkitekturen tilpasses til den endelige driftsleverandørs foretrukne standarder. Som udgangspunkt designes KIH databasen, så den indledende er simpel at flytte mellem applikationsservere og SQL databaser fra forskellige leverandører. Systemet designes desuden, så det muliggør afvikling på forskellige typer operativsystem, blot operativsystemet understøtter de valgte webserver, applikationsserver og database teknologier. Side 20 af 24

På netværkssiden skal servicen udstilles på Sundhedsdatanettet, og der skal etableres aftaler mv. til/fra de systemer servicen skal kommunikere med. Flere elementer i illustrationen er ikke færdigafklarede/designede. Det drejer sig konkret om snitfladerne til evt. indsamling af stamdata fra NSP og/eller andre datakilder, samt evt. snitflade til bulk import af monitoreringsdata fra OpenTele datamonitoreringsplatformen. Figur 11 : Overordnet driftsarkitektur for KIH databasen I situationen hvor der etableres mere end én web container, skal der etableres en loadbalancer foran web containerne. Loadbalanceren konfigureres så webservice kald fordeles optimalt mod de bagvedliggende web containere. Som udgangspunkt er KIH Database serverapplikationen designet, så den indledende er simpel at flytte mellem applikationsservere og SQL databaser fra forskellige leverandører. Systemet er desuden designet, så det muliggør afvikling på forskellige typer operativsystem, blot operativsystemet understøtter de valgte Java EE web container og database teknologier. KIH Database serverapplikationen er baseret på Grails 2.3.11. Den bygges og afvikles med Java 1.6. Applikationen er testet på web containerne Tomcat 7 og JBoss. Umiddelbart bør Side 21 af 24

1 alle web containere, som understøttes af Grails 2.3.11 kunne anvendes uden større problemer. På databasesiden er applikationen testet på databaserne: H2, MySQL 5 og MS SQL Server 2008. Hvis andre databaseteknologier ønskes anvendt, skal systemets DataSource muligvis 2 tilpasses og evt. skal der i mindre omfang implementeres en mapning af konkrete datatyper i systemets kode. Overvejelser om skalering I situationen hvor der etableres mere end én web container, skal der etableres en loadbalancer foran web containerne. Loadbalanceren konfigureres så webservice kald fordeles optimalt mod de bagvedliggende web containere. Hvis administrative brugere og klinikere ledes ind i systemet via loadbalanceren, skal det sikres at loadbalanceren leder brugerne til samme server i samme session, mao. loadbalanceren skal være sticky for den browserbaserede web brugergrænseflade. Med henblik på overvågning af systemet, er der etableret en simpel isalive http service på systemet, som undersøger om alle lagene i løsningen er tilgængelige. Referencer [XDS.b] Cross Enterprise Document Sharing b (XDS.b). Website: http://wiki.ihe.net/index.php?title=cross Enterprise_Document_Sharing b_%28xds.b%29 Beskrevet i dokumentet: IHE IT Infrastructure Technical Framework Supplement 2007 2008 Cross Enterprise Document Sharing b (XDS.b), dateret 15. august 2007, som kan hentes fra: http://www.ihe.net/technical_framework/upload/ihe_iti_tf_supplement_xds 2.pdf [PHMR] Personal Health Monitoring Record. [DGWS 1.1] Den Gode Webservice version 1.1, version 1.1, dateret 1. juli 2008. Kan hentes hos Medcom på adressen: http://www.medcom.dk/wm110731 [DGKS 1.0.1] Den Gode Kronikerservice, version 1.0.1 dateret 24. april 2013. 1 Se listen over supporterede Java EE containere på adressen: http://grails.org/doc/2.1.0/guide/single.html#supportedjavaeecontainers 2 Kan ske enten i systemets kildekode, eller i en konfigurationsfil Side 22 af 24

Web site med WSDL, XSD skemaer mv.: http://svn.medcom.dk/svn/drafts/standarder/den%20gode%20kronikerservice/ [MDSS 1.0.1] MonitoringDataset Service, version 1.0.1 dateret 24. april 2013. Web site med WSDL, XSD skemaer mv.: http://svn.medcom.dk/svn/drafts/standarder/den%20gode%20kronikerservice/ wsdl/1.0.1 [NSP] NSP Website. https://nsp.nsi.dk/confluence/display/website/platform Side 23 af 24

Dokumenthistorik Version Dato Initialer Ændring 1.0 01 05 2013 Initiel version 1.2 15 09 2014 Opdateret til for version 1.2 af KIH Database Side 24 af 24