OpenTele datamonitoreringsplatform

Transkript

1 OpenTele datamonitoreringsplatform Arkitektur og design 17. marts 2015 Side 1 af 35

2 Indholdsfortegnelse Indholdsfortegnelse Indledning Systemlandskab / Arkitekturoverblik Brugsscenarier Scenarie 1: Kliniker knytter spørgeskema til patient Scenarie 2: Patient udfylder spørgeskema Scenarie 3: Kliniker kvitterer for indsendt spørgeskema Scenarie 4: Kliniker kvitterer for alle grønne spørgeskemaer Scenarie 5: Patient sender besked til hospitalet Scenarie 6: Kliniker besvarer besked fra patient Scenarie 7: Målinger eksporteres til KIH Databasen OpenTele server-design/-arkitektur Væsentlige designparametre Applikationsarkitektur Komponent allokering Realiseret applikationsarkitektur Anvendelse af OpenTele fra eksterne systemer Kort baggrund om Grails Etablering af service API til eksterne brugergrænseflader Sikkerhedsmodel Rettigheder Patientadgang Spørgeskema-editor Batch jobs på OpenTele kliniker serveren Datamodel Logisk datamodel Driftsarkitektur Overvejelser om skalering OpenTele Android klient-design/-arkitektur JSON-parser/-generator Spørgeskema-motor Layout-motor Integrationer til måle-enheder Continua Health Alliance baserede integrationer Bluetooth integration til Monica CTG-apparat (ikke-continua) USB integration til AccuChek blodsukkermåler OpenTele HTML5 klient-design/-arkitektur Android wrapper Side 2 af 35

3 Native-funktionalitet HTML5 web applikation Spørgeskemafortolker Grafgenerator Beskedhåndtering Dokumenthistorik Side 3 af 35

4 Indledning Dette dokument udgør arkitektur- og designdokumentationen for OpenTele datamonitoreringsplatformen. OpenTele datamonitoreringsplatformen er et monitoreringssystem dedikeret til central opsamling af telemedicinske målinger direkte fra borgere i deres hjem. Et væsentligt aspekt i forståelsen af platformens arkitektur er, at den forventes at udvikle sig over tid. Arkitekturen som er beskrevet i nærværende dokument, tager udgangspunkt i datamonitoreringsløsningen etableret i TeleSkejby projektet. På sigt forventes arkitekturen at rette sig mod gældende anbefalinger og standarder fra IHE og Continua Health Alliance. OpenTele datamonitoreringsplatformen består overordnet af en kliniker-rettet server-applikation med en tilhørende database, samt borgervendte tablet klienter, som opsamler og indsender måledata til en borger-rettet web service. Den borgerrettede web service gemmer data i systemets database, hvorfra data stilles til rådighed for klinikere via den kliniker-rettede serverapplikation. I de følgende afsnit beskrives platformens bestanddele. Først beskrives den overordnede systemkontekst platformen opererer i. Herefter gennemgås en række udvalgte brugsscenarier og til sidst beskrives den tekniske arkitektur for henholdsvis OpenTele server platformen og OpenTele klienterne. Side 4 af 35

5 Systemlandskab / Arkitekturoverblik De overordnede sammenhænge som er eller på sigt forventes - etableret i OpenTele systemkomplekset, illustreres nedenfor med udgangspunkt i snitfladerne mellem systemernes komponenter. Det fremhæves at arkitekturen forventes at udvikle sig over tid. Figur 1: Overblik over komponenter og sammenhænge i systemkomplekset OpenTele indgår i OpenTele systemkomplekset udgøres overordnet af fire OpenTele komponenter samt nogle eksterne systemer, som i forhold til illustrationen ovenfor beskrives fra venstre side mod højre: 1. Målingskilde Saturations-, blodtryks-, CTG-, blodsukkermålere, vægte eller andre målingskilder, som en borger/patient anvender til at foretage målinger. Målingskilderne er standard apparater, der producerer målinger. Målingerne overføres til en tablet eller telefon klient ved manuel indtastning, via USB eller via en Bluetooth protokol. For målingskilder med Bluetooth understøttelse, anvendes bl.a Continua Health Alliance godkendte ISO protokoller. 2. OpenTele tablet klient Klienten er en tablet app som borgere/patienter anvender til at afvikle spørgeskemaer, sende og modtage beskeder til klinikere og til få et overblik over deres målinger. Spørgeskemaer hentes fra OpenTele Datamonitorering Borger services som JSON formaterede dokumenter via en sikker forbindelse. Spørgeskemaerne kan indeholde en række forskellige Side 5 af 35

6 knuder. F.eks. ja/nej spørgsmål eller knuder som opsamler monitoreringsresultater fra måleapparater. Når et spørgeskema er udfyldt, sendes resultatet til OpenTele Datamonitorering Borger services. Modtagelse og afsendelse af beskeder fungerer efter samme principper. Visning af patientens målinger sker i brugergrænsefladen i OpenTele Datamonitorering Kliniker services. P.t. er der udviklet to klienter: en Android tablet klient, der kan modtage målinger via manuel indtastning, Bluetooth og USB og en HTML5 Android tablet klient der kan modtage målinger via manuel indtastning. 3. OpenTele borger services OpenTele borger services er en serverapplikation som er ansvarlig for JSON kommunikation med OpenTele klienter vedr. spørgeskemaer, resultater og beskeder. 4. 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. 5. KIH database KIH Databasen er en national database til deling af hjemmemonitoreringsdata. OpenTele kan indsende målinger til KIH Databasen via Sundhedsdatanettet. KIH Databasen gør data tilgængelige for autentificerede brugere på tværs af sektorer f.eks. via NSP ens Dokumentdelingsservice eller sundhed.dk. 6. Milou Milou er et system til håndtering af CTG målinger. CTG målinger indsamlet i OpenTele eksporteres til Milou for at give klinikerne adgang til disse målinger i samme system som de normalt bruger til CTG målinger. 7. NSP NSP (National serviceplatform) er en platform der udbyder services til brug indenfor sundhedsdomænet. OpenTele anvender NSP ens STS-service til autentifikation af IDkort som NSP bruger ved opslag i KIH Databasen, samt til opslag mod NSP ens CPR service. OpenTele kan hente kontaktdata vedr. borgere via NSP ens CPR service. Opslaget sker i forbindelse med oprettelse af nye patienter/borgere i OpenTele. I det følgende afsnit beskrives nogle udvalgte brugsscenarier for OpenTele. Efterfølgende beskrives applikationsarkitekturen for OpenTele og OpenTele klienterne. Side 6 af 35

7 Brugsscenarier I dette afsnit gennemgås udvalgte brugsscenarier for OpenTele. Listen er ikke udtømmende, men scenarierne er udvalgt, så de tilsammen giver et godt overblik over hvordan systemet kan anvendes og fungerer i praksis. Scenarie 1: Kliniker knytter spørgeskema til patient Når en patient tilknyttes et forløb i OpenTele, skal der tilknyttes et eller flere spørgeskemaer til patienten. Dette sker i platformens kliniker-rettede web-applikation. Antagelse: Klinikeren er logget ind i OpenTele web-applikationen og har fremsøgt den pågældende patient. Skridt Kliniker Web-applikation 1 Viser teksten Ingen tilknyttede eller aktive spørgeskemaer 2 Klikker på Monitoreringsplan 3 Viser side med teksten Der findes ikke en monitoreringsplan for... samt knappen Ny monitoreringsplan 4 Klikker på Ny monitoreringsplan 5 Viser dato-felter til udfyldelse 6 Udfylder startdato for monitoreringsplanen 7 Klikker på Opret 8 Opretter ny monitoreringsplan 9 Viser side med monitoreringsplanens startdato samt en tom liste af tilknyttede spørgeskemaer 10 Klikker på Tilføj spørgeskema 11 Viser side hvor det ønskede skema vælges, samt muligheder for planlægning af skema-udfyldelse (bestemte ugedage, bestemte dage i hver måned, hver n te dag, samt hvilk(e) tidspunkt(er) på dagen spørgeskemaerne skal udfyldes). 12 Vælger det ønskede spørgeskema 13 Vælger evt. planlægning af skema. 14 Klikker på Opret Side 7 af 35

8 15 Føjer det valgte spørgeskema til patientens monitoreringsplan 16 Viser side med monitoreringsplanens startdato samt en tom liste af tilknyttede spørgeskemaer, hvor det nyligt tilføjede spørgeskema nu fremgår Scenarie 2: Patient udfylder spørgeskema En blodtryksmåling gennemføres. Scenariet varierer alt efter hvilket spørgeskema patienten vælger at udfylde, og ikke alle spørgeskemaer involverer målinger med måleapparater. Antagelse: Patienten er logget ind i OpenTele klient Android app en KIH Datamonitorering. Skridt Patient Klient-app (Android) 1 Viser hovedmenu med mulighed for at vælge Gennemfør måling 2 Trykker på Gennemfør måling 3 Viser liste af spørgeskemaer tilknyttet patienten. 4 Trykker på spørgeskemaet Blodtryk 5 Viser information til brugeren: Sæt manchetten på armen og tryk på START-knappen på blodtryksmåleren 6 Sætter manchetten på armen 7 Trykker på START-knappen på blodtryksmåleren 8 Afventer resultat på blodtryksmåleren 9 Viser information til brugeren: Venter på måling. Hold dig i ro. 10 Afslutter blodtryksmåling 11 Viser information til brugeren, eksempelvis: Har modtaget følgende værdier. Systolisk blodtryk: 126. Diastolisk blodtryk: 54. Puls: Trykker på OK 13 Viser dialog: Vil du sende data til hospitalet? 14 Trykker på Ja 15 Viser information til brugeren: Indsendelse af svar gik godt Side 8 af 35

9 16 Trykker på OK 17 Viser hovedmenu Scenarie 3: Kliniker kvitterer for indsendt spørgeskema Sidst indsendte spørgeskema for en given patient inspiceres og kvitteres. Et meget relevant alternativt forløb er tilfældet hvor patientens indsendte data ikke ligger inden for de definerede normalområder, eller der af anden årsag er grund til at tage handling. I dette tilfælde konfereres med læger og evt. patienten for at følge korrekt op på situationen. Antagelse: Klinikeren er logget ind i OpenTele web-applikationen. Skridt Kliniker Web-applikation 1 Viser patientoverblik, hvor alle klinikerens tilknyttede patienter med ubehandlede data vises. 2 Klikker på ikonet for ukvitterede spørgeskemaer ud for den ønskede patient 3 Folder detaljer for patienten ud: Alle spørgsmål og svar for de ukvitterede spørgeskemaer samt grafer for de sidste 30 dage for alle patientens spørgeskemaer 4 Nærlæser svarene på sidst indsendte spørgeskema 5 Klikker på kvittér-knappen 6 Viser dialog: Er du sikker på at du vil kvittere? 7 Klikker på OK 8 Markerer det pågældende spørgeskema som kvitteret 9 Viser patientoverblik Scenarie 4: Kliniker kvitterer for alle grønne spørgeskemaer I stedet for at nærlæse alle indsendte spørgeskemaer, kan klinikeren vælge at kvittere for alle grønne spørgeskemaer, dvs. spørgeskemaer hvor alle svar ligger inden for normalområdet for patienten. Side 9 af 35

10 Antagelse: Klinikeren er logget ind i OpenTele web-applikationen. Skridt Kliniker Web-applikation 1 Viser patientoverblik, hvor alle klinikerens tilknyttede patienter med ubehandlede data vises. 2 Klikker på Kvitter for alle grønne 3 Markerer det pågældende spørgeskema som kvitteret 4 Viser patientoverblik Scenarie 5: Patient sender besked til hospitalet Patienten har et spørgsmål til hospitalet og bruger OpenTele-klienten til at indsende spørgsmålet. Antagelse: Patienten er logget ind i OpenTele klient Android app en OpenTele. Skridt Patient Klient-app (Android) 1 Viser hovedmenu med mulighed for at vælge Beskeder 2 Trykker på Beskeder 3 Viser liste ulæste beskeder 4 Trykker på Ny besked 5 Viser dialog til oprettelse af beskeder med felterne Til, Overskrift og Besked 6 Trykker på Overskrift -feltet og udfylder en overskrift 7 Trykker på Besked -feltet og udfylder en besked 8 Trykker på Send 9 Viser information: beskeden er nu indsendt til hospitalet 10 Trykker på OK 11 Viser liste med ulæste beskeder Scenarie 6: Kliniker besvarer besked fra patient Side 10 af 35

11 Skridt Kliniker Web-applikation 1 Viser patientoverblik, hvor alle klinikerens tilknyttede patienter med ubehandlede data vises. Ikonet for ulæste beskeder vises ud for den relevante patient. 2 Klikker på ikonet for ulæste beskeder 3 Viser beskeder fra patienten. Nyeste besked vises som Ikke læst. 4 Klikker på Besvar 5 Viser dialog til oprettelse af besked, hvor Emne er forudfyldt med tidligere emne 6 Udfylder indhold 7 Klikker på Send 8 Gemmer besked 9 Viser beskeder fra patienten, samt nyeste besked fra kliniker. Nyeste besked vises som Ikke læst. Scenarie 7: Målinger eksporteres til KIH Databasen Skridt Web-applikation KIH Databasen 1 Gemmer alle målinger som kommer ind sammen med spørgeskemabesvarelser 2 Job scheduler starter jobbet som eksporterer målinger til KIH Databasen 3 Alle målinger der endnu ikke er eksporteret fremfindes og hver måling sendes til KIH Databasen 4 Kvitterer for alle målinger der modtages uden fejl 5 Kvitterede målinger markeres eksporterede Side 11 af 35

12 OpenTele server-design/-arkitektur I dette afsnit beskrives OpenTele platformens server-applikationsarkitektur. OpenTele datamonitoreringsplatformen er etableret med udgangspunkt i den platform, som er udviklet i TeleSkejby projektet. Platformen opsamler monitoreringsdata fra mobile Android enheder over internettet via https protokollen og gør data tilgængelige via en browserbaseret brugergrænseflade for klinikere. Separate instanser af platformen kan med fordel etableres for afgrænsede brugergrupper. F.eks. er selvstændige instanser af OpenTele platformen etableret for henholdsvis Region Hovedstaden, Region Midtjylland og Region Nordjylland. Nedenstående illustrationen giver et overblik over platformens elementer og anvendere. Figur 2: Arkitekturoverblik for OpenTele datamonitoreringsplatformen OpenTele platformen består grundlæggende af følgende bestanddele: Side 12 af 35

13 1. OpenTele kliniker server (provider server) Kliniker serveren indeholder en brugergrænseflade til klinikere. Brugergrænsefladen håndterer kommunikation vedr. spørgeskemaer, monitoreringsresultater og beskedhåndtering med den borger-/patientrettede OpenTele tablet applikation. Serveren indeholder også en mindre administrativ brugergrænseflade, som anvendes til f.eks. brugerstyring og administration af spørgeskemaer. Klinikerserveren anvender systemets database som datalager og er ansvarlig for indberetning af CTG målinger til en Milou server, samt indberetning af monitoreringsdata til en central KIH database. 2. OpenTele borger server (citizen server) Borgerserveren indeholder web services til borgerrettede funktioner såsom at hente spørgeskemaer, indsende svar på spørgeskemaer, sende og modtage beskeder, se kvitteringer m.v. Borgerserveren anvender samme database som OpenTele klinikerserveren. 3. OpenTele Android (Tablet) klient OpenTele Android app en varetager dialogen med borgeren/patienten. I app en afvikles spørgeskemaer, som hentes fra OpenTele borgerserveren. I forbindelse med afvikling af spørgeskemaer opsamler app en monitoreringsdata fra måleapparater og indsender disse til OpenTele borger serveren via en krypteret snitflade. App en indeholder også en simpel beskedklient, som patienter kan benytte til at kommunikere med de klinikere, der er ansvarlige for deres forløb. 4. OpenTele HTML5 klient OpenTele HTML5 klienten er på sigt tænkt som afløser for OpenTele Android klienten. Herved gøres det nemmere at tilbyde en klient på flere platforme, f.eks. både Android og ios. P.t. indeholder HTML5 klienten et subset af den funktionalitet der er til rådighed på Android klienten. F.eks. er der endnu ikke udviklet integration med målerudstyr. Det er planen at HTML5 klienten på sigt skal have samme funktionalitet som Android klienten. Væsentlige designparametre De non-funktionelle krav til OpenTele-platformen er ikke beskrevne. Der er derfor etableret 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 OpenTele platformen 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 systemet at komme til at indeholde særdeles store datamængder. Anvendelsen af systemet forventes ligeledes at stige væsentligt over tid. Side 13 af 35

14 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 Komponenterne i OpenTele applikationsserverne er illustreret nedenfor: Figur 3: Overordnet komponentmodel for OpenTele applikationsserveren. Moduler med grå baggrund anvendes i både borger- og klinikerserveren. Komponentmodellen for OpenTele applikationsserverne er opdelt med dedikerede snitfladeelementer som håndterer dataimport/-eksport, brugergrænseflader for administratorer og klinikere, samt kommunikation med OpenTele klienter. En sikkerhedskomponent håndterer autentifikation og autorisation af brugere og al brugerrelateret adgang til data registreres i en hændelses-log (auditlog). Side 14 af 35

15 OpenTele applikationsserverne skal kunne tilgås fra OpenTele tablet klienter via internettet og sandsynligvis via et lokalt regionalt net. Sikkerhedskomponenten skal derfor kunne håndtere login fra: Klinikere, hvor autentificering sker med brug af brugernavn/adgangskode. På sigt forventes autentificering migreret til at tilbyde single sign-on, via integration til lokale LDAP servere eller lignende Administratorer, i nuværende version med simpel brugernavn/password baseret autentificering, men på sigt lig klinikerne forventes autentificering via lokal LDAP Borgere/patienter som logger ind via OpenTele klienter. Autentificering sker her med brugernavn/adgangskode. På sigt forudses skift til f.eks. NemID baseret autentifikation. OpenTele servernes servicelag er designet tilstandsløst, så det kan flyttes til separate fysiske noder, hvis behovet opstår. Systemets komponenter implementeres i en lagdelt arkitektur, som er nærmere beskrevet i de følgende afsnit. Komponent allokering I forhold til ovenstående beskrevne applikationsarkitektur giver det nedenstående allokering af OpenTele server komponenterne: Figur 4: OpenTele komponent allokering Side 15 af 35

16 Realiseret applikationsarkitektur Applikationsarkitekturen for OpenTele kliniker og borger serverne er realiseret overordnet i et standard Java EE baseret setup, baseret på en, eller flere Java EE Web containere, der kommunikerer med et underliggende databaselag. Overordnet er følgende teknologier anvendt: Grails (Groovy baseret web-framework bygger ovenpå Spring) Grails Database Migration Plugin Java 1.7 JavaScript/HTML til den klinikervendte brugergrænseflade JSON over HTTPS til borgerservice snitfladen Quartz (Jobskedulering for data eksport mv.) Apache Tomcat 7 SQL Database (H2, MySQL eller MicrosoftSQL Server) OpenTele kliniker serveren udstiller en HTML/JavaScript baseret brugergrænseflade til klinikere og OpenTele borger serveren en JSON-snitflade til klienter. Begge servere er implementeret i Grails 1, der er et opinionated framework og derfor i store træk definerer serverapplikationens interne struktur. Applikationsarkitekturen er lagdelt, således at de forskellige lag er ansvarlige for velafgrænsede elementer af arkitekturen. Der henvises til afsnittet vedr. etablering af alternative brugergrænseflader eller Grails dokumentationen for detaljeret gennemgang af den overordnede struktur af servernes lagdelte arkitektur, som er skitseret i nedenstående illustration. 1 Se Side 16 af 35

17 Figur 5: OpenTele serverapplikationens modulære- og lagdelte arkitektur Et typisk request fra en browser eller en JSON klient vil passere gennem et sikkerhedsfilter, og efterfølgende ramme en Controller som evt. benytter sig af Services og tilgår databasen via domæne-entiteter. Som svar på requesten renderes svaret (reply) i et view. Spørgeskema-editoren benytter ikke Grails-modellen. Mere herom i afsnittet om spørgeskemaeditoren. Side 17 af 35

18 Anvendelse af OpenTele fra eksterne systemer I flere sammenhænge har der været udtrykt behov for: Etablering af alternative (eksterne) brugergrænseflader til OpenTele Mulighed for at OpenTele kan indgå i en eksisterende Service Orienteret Arkitektur I dette afsnit beskrives strategien for imødegåelse af ovennævnte behov. Den anbefalede løsning til begge er den samme; nemlig at anvende eksisterende, eller at tilføje nye, OpenTele web services (konkret REST API er). Som beskrevet i dette dokument er OpenTele opdelt i to overordnede komponenter; OpenTele borger server og OpenTele kliniker server. På det tekniske plan er strategien for tilføjelse af API er fælles for de to komponenter, da begge anvender Grails frameworket, og dermed dets konventioner med hensyn til etablering af f.eks. services og controllere. Ved etablering af en konkret ny snitflade/api, skal der som del i designet tages stilling til om snitfladen er dedikeret til borgere eller klinikere/administratorer. Afhængigt af hvem API et er beregnet til, tilføjes det på borger- eller klinikerserveren - eller evt. som del af en ny dedikeret servicekomponent. Kort baggrund om Grails Grails er overordnet bygget efter Model View Controller (MVC) mønstret. I MVC håndterer modellen data repræsentation og operationer, viewet står for visning af data og controlleren håndterer den kode som forbinder brugeren til systemet. Controlleren modtager forespørgsler eller hændelser, og sikrer de rette data og den rette forretningslogik bliver afviklet, og returnerer et view, som repræsenterer resultatet af handlingen. Grails implementerer MVC med domæneobjekter, services, controllers og views. I det følgende er de væsentligste begreber i Grails kort beskrevet: Grails domain objects I Grails domæneobjekter etableres systemets datamodel. Grails Services Grails services er modelleret på Spring services. I OpenTele placeres forretningslogik i servicelaget, og ikke i controllerlaget. Der findes ældre Side 18 af 35

19 OpenTele controllere med forretningslogik. Logikken i disse skal over tid flyttes til Grails services. Grails Services og Grails domæneobjekter udgør tilsammen modellen i MVC. Grails Controllers Grails Controllers opfylder C et i MVC. Grails controllers er ansvarlige for at håndtere web baserede forespørgsler. Controllers i Grails er som udgangspunkt ikke transaktionelle. Grails Views Grails Views opfylder MVC s View rolle. I Grails views etableres den brugergrænseflade brugeren præsenteres for. Grails Views i OpenTele er udviklet i GSP (Groovy Server Pages), samt Javascript og HTML. I relation til REST baserede API er er viewet den JSON som returneres fra API ets controller. De væsentligste komponenter i Grails arkitektur er skitseret nedenfor. Figur 6: Grails elementer i OpenTele Etablering af service API til eksterne brugergrænseflader Hvis der skal etableres nye brugergrænseflader i selve OpenTele håndteres dette ved etablering af de relevante services, controllers og views, samt hvis Side 19 af 35

20 nødvendigt, udvidelser til datamodellen ved tilføjelse af nye domæneobjekter. Hvis man ønsker at etablere brugergrænseflader i eksterne systemer som trækker på funktionalitet i OpenTele, er den foretrukne model, at etablere et service API i OpenTele som det eksterne system kan anvende til at sammensætte sin brugergrænseflade. Dette API bør etableres som et REST API, lig det API OpenTele HTML5 klienten anvender. Konkret etableres API et som en eller flere Grails Controllers der trækker på forretningslogik fra en eller flere Grails Services. Illustrationen nedenfor skitserer hvor eksisterende (eller ny) forretningslogik kan gøres tilgængelig for anvendelse i en ekstern brugergrænseflade. Figur 7: Eksempel på etablering af nyt API til brug fra eksterne systemer. Eksisterende OpenTele komponenter er vist med lys blå baggrund, nye komponenter med rødlig baggrund og eksterne systemer med grøn baggrund. Side 20 af 35

21 Sikkerhedsmodel Sikkerheden i OpenTele er implementeret med to ortogonale systemer: Rettigheder til operationer (en traditionel ACL) og adgang til patienter. Rettigheder Rettighederne er implementeret ved roller, der hver især er tilknyttet en liste af rettigheder. En bruger i systemet kan så tilknyttes et antal roller. Figur 8: Objektmodel for systemets bruger-, rolle- og rettighedsmodel De tilgængelige rettigheder er fast defineret i systemet, men fordelingen på roller og brugere kan redigeres og dermed tilpasses de enkelte afdelingers behov. Ved login i systemet tjekkes via Spring Security 2 kun at brugernavn og password passer, og at kontoen ikke er låst af den ene eller anden årsag. Samtlige operationer i systemet er beskyttet af rettighedstjek, hvilket er implementeret ved annoteringer i controller-koden og tilhørende konfiguration af Spring Security. Rettighedstjekket sikrer, at der ikke gives adgang til en bestemt funktionalitet medmindre den tilhørende controller-metode er white-listet med en rettighed som brugeren er i besiddelse af. Rettighederne er langt hen ad vejen defineret ud fra sammenhængende funktionalitet, såsom: Rettighed QUESTIONNAIRE_READ QUESTIONNAIRE_READ_ALL QUESTIONNAIRE_WRITE QUESTIONNAIRE_DELETE QUESTIONNAIRE_ACKNOWLEDGE Beskrivelse Må læse enkelte spørgeskemaer Må se oversigt af spørgeskemaer Må opdatere informationer på et spørgeskema Må slette et spørgeskema Må godkende et spørgeskema Patientadgang For at tilgå en patients data skal man som kliniker have patienten i behandling. I praksis implementeres dette ved, at det kræves klinikere er tilknyttet en eller flere patientgrupper, som patienten indgår i. Dette gælder også selvom man i rettighedsmodellen har lov til at se en bestemt type patientdata. 2 Læs om Spring Security på Side 21 af 35

22 En patient er tilknyttet et antal patientgrupper, der igen er tilknyttet en afdeling på et sygehus. Tilsvarende er en kliniker tilknyttet et antal patientgrupper. For at en kliniker har adgang til en patients data, skal de to lister af patientgrupper have mindst én fælles patientgruppe. Figur 9: Overordnet objektmodel for patientgrupper, klinikere og patienter Beskyttelse mod visning af data for patienter som klinikeren ikke har adgang til, sikres via et sikkerhedsfilter. Når data for en patient vises, sættes patienten som kontekst. Ved udgangen af controller-metoder tjekkes via et sikkerhedsfilter for om patienten i kontekst må være synlig for klinikeren. Beskyttelse mod ændring i data for patienter som klinikeren ikke har adgang til, sikres ved at alle controller metoder eksplicit skal annoteres med den rettighed brugeren skal have for at kunne anvende den specifikke controller metode. Det egentlige tjek af adgang til patientdata sker derefter i ovennævnte sikkerhedsfilter. Spørgeskema-editor Idet spørgeskema-editoren er bygget op om at brugeren sidder længe og tilretter et diagram på en side, er denne del ikke opbygget som en typisk klient-server-løsning. I stedet er editoren udviklet som en rig klient. Klienten er baseret på JavaScript-libraries, som kommunikerer med OpenTele kliniker serveren via JSON. I princippet kan spørgeskema-editoren betragtes som en separat klient, der dog kører i en browser på linje med resten af server-gui en. Batch jobs på OpenTele kliniker serveren På OpenTele kliniker serveren kører flere periodiske jobs, herunder: Beregning af såkaldte blå alarmer eksport til Milou eksport til KIH Databasen Side 22 af 35

23 Milou-eksporten finder alle CTG-målinger der ikke allerede er eksporteret til Milou, og overfører målinger til Milou via en web service. Tilsvarende finder jobbet, som sender data til KIH Databasen, relevante målinger og eksporter disse til KIH Databasen. Side 23 af 35

24 Datamodel I dette afsnit beskrives et udvalgt udsnit af den logiske- samt den fysiske datamodel for OpenTele-serveren. Logisk datamodel Dette afsnit beskriver kort og overordnet den logiske datamodel for OpenTele. De væsentligste elementer i modellen er illustreret, og efterfølgende overordnet beskrevet nedenfor. Figur 10: Logisk datamodel for OpenTele Patienter kan indgå i en eller flere patientgrupper. En patientgruppe knyttes til en organisatorisk enhed, f.eks. en afdeling på et sygehus eller en lægepraksis. Kun klinikere tilknyttet en patientgruppe, der omfatter en patient, har adgang til at se patientens registreringer. Klinikere administrerer en monitoreringsplan som beskriver hvilke spørgeskemaer en patient skal besvare og med hvilken frekvens besvarelsen skal ske. Et spørgeskema er et centralt begreb i modellen. Spørgeskemaet er modelleret som en flowchart - eller mere præcist en Side 24 af 35

25 acyklisk graf - og kan bestå af alt fra én enkelt blodtryksmålings- node til komplekse strukturer sammensat af både målinger, valg og spørgsmål som besvares skriftligt. Spørgeskemaer er versionerede og oprettes først i form af generelle skabeloner. Skabelonerne tildeles til en konkret patient, og kan i forbindelse med tildelingen individualiseres til patienten. Patienten besvarer spørgeskemaet, f.eks. via en Android tablet applikation, og sender resultatet tilbage til serveren. I forbindelse med modtagelse af resultatet, registreres dette som et gennemført spørgeskema med tilhørende strukturerede resultater. I dokumentet OpenTele Fysisk Datamodel findes en mere detaljeret gennemgang af objekterne i datamodellen. Side 25 af 35

26 Driftsarkitektur Serverens applikationsarkitektur kan 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. F,.eks. at udvide hardware kapaciteten og/eller ved at etablere parallelitet i arkitekturen. Nedenstående illustration viser et driftssetup hvor både OpenTele kliniker server og OpenTele borger server kører på samme applikationsserver. Dette er det simpleste setup, hvor kliniker services og borger services tilgås via samme netværk. Figur 11: Eksempel på driftsarkitektur for OpenTele datamonitoreringsplatform Af hensyn til sikkerhed kan det være relevant at afvikle kliniker services og borger services på hver sit netværk. Et eksempel på sådan et driftssetup er vist nedenfor. Side 26 af 35

27 Figur 12: Borger- og kliniker server installeret på separate maskiner Som udgangspunkt er OpenTele serverapplikationerne designet, så de er simple 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. OpenTele serverapplikationerne er baseret på Grails og er testet i web containeren Apache Tomcat 7. Umiddelbart bør alle web containere, som understøttes af Grails kunne anvendes uden større problemer. På databasesiden er applikationen testet på databaserne: H2, MySQL og MS SQL Server Se listen over supporterede Java EE containere på adressen: Side 27 af 35

28 Hvis andre databaseteknologier ønskes anvendt, skal systemets DataSource muligvis tilpasses 4 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. 4 Kan ske enten i systemets kildekode, eller i en konfigurationsfil Side 28 af 35

29 OpenTele Android klient-design/- arkitektur Android klienten benyttes af patienten til at udfylde spørgeskemaer og kommunikere med serveren. En vigtig bestanddel af udfyldningen af spørgeskemaer er integration til diverse måleapparater. Hvor klienten modtager målinger fra måleapparaterne, f.eks. via Bluetooth. Klienten er implementeret som en Android-app. De forskellige komponenter i klienten er afbildet på nedenstående figur. Figur 13: OpenTele Android klientdesign/-arkitektur JSON-parser/-generator Al kommunikation mellem klient og server sker med JSON, så klienten kan fortolke JSON og konvertere spørgeskemaer til en passende struktur med spørgeskema-knuder repræsenteret ved specifikke klasser. Omvendt serialiseres gennemførte spørgeskemaer også tilbage til JSON som serveren efterfølgende kan håndtere. Side 29 af 35

30 Der refereres til systemsnitfladebeskrivelsen for yderligere dokumentation af JSON-formatet til udveksling af spørgeskemaer. Spørgeskema-motor Spørgeskemaerne modelleres på serveren som grafer - et antal knuder med veje imellem dem. Klienten implementerer udførelsen af disse spørgeskemaer, således at brugeren ledes gennem knuderne. Der findes flere typer af knuder, bl.a.: Logiske knuder: Sammenligner tidligere værdier for at beslutte hvilken vej der skal gås. Visningsknuder: Viser tekst for brugeren Indtastningsknuder: Lader brugeren f.eks, indtaste tekst eller tal i indtastningsfelter eller lader brugeren vælge mellem et fast defineret antal udfald, f.eks. Ja eller Nej Måleknuder: Integrerer med en måle-enhed, såsom et blodtryksapparat, en saturationsmåler eller en CTG-måler og gemmer resultatet af målingen. Hele klientens logiske flow uden om de patientrettede spørgeskemaer er også implementeret via spørgeskema- motoren, således at login, visning af tilgængelige spørgeskemaer, visning af beskedliste mv. er implementeret som spørgeskema-knuder. Serveren kender ikke til disse spørgeskema-knuder. Layout-motor Idet klienten er bygget op omkring begrebet spørgeskemaer, er det nyttigt med en generel mekanisme til at vise skærmbilleder for brugeren. Klienten implementerer et antal grafiske elementer som kombineres i et skærmbillede. Layout-motoren sørger for at vise elementerne på en fornuftig måde. Integrationer til måle-enheder Klienten kan forbinde til et antal forskellige apparater via forskellige protokoller. Disse integrationer skitseres kort her. Continua Health Alliance baserede integrationer Denne protokol anvender Bluetooth via Bluetooth-profilen Health Device Profile (HDP). Et antal apparater kan kommunikere via denne protokol: Nonin-saturationsmåler A&D-blodtryksmåler og A&D-vægt. Der er implementeret et framework til generel håndtering af Continua-protokollen. I frameworket specificerer de enkelte apparat-integrationer blot hvilken type apparat der integreres mod, samt Side 30 af 35

31 hvordan svar fra apparatet fortolkes. For integration til A&D-blodtryksmåleren er implementeret følgende klasser (de blå klasser er en del af det implementerede Continua-framework): Figure 14: Integration til A&D-blodtryksmåler Hver af de fire klasser er minimale. Tilsvarende findes der fire klasser for A&D-vægten og Nonin-saturationsmåleren. Der refereres til følgende dokumenter for information om Continua-protokollen og specifikationerne for de enkelte typer apparater for yderligere beskrivelse af protokollen: Generelt om ISO/IEEE standarden: DS/EN ISO Optimized Exchange protocol, beskrivelse af hvordan informationer udveksles i ASN-1: DS/EN ISO Puls-oximeter-specialiseringen: DS/EN ISO Blodtryks-målings-specialiseringen: DS/EN ISO Kropsanalysevægt-specialiseringen: DS/EN ISO Bluetooth integration til Monica CTG-apparat (ikke-continua) Integrationen til Monica Healthcare CTG apparatet sker via en tilpasset udgave af Philips Series 50-protokol over Bluetooth. Målingsværdier modtages løbende, men ikke nødvendigvis med en helt fast frekvens. For at håndtere den ujævne modtagelse af CTG-data implementerer klienten en del heuristik for at kontrollere at målingsværdier ikke går tabt. Side 31 af 35

32 USB integration til AccuChek blodsukkermåler På tidspunktet for skrivning af dette dokument er der i OpenTele projektet implementeret to USB baserede integrationer, nemlig integration til AccuChek og Abbott Freestyle Navigator II blodsukkermåleapparater. For AccuChek er integrationen implementeret som simpel indlæsning af en kommasepareret (CSV) fil fra måleapparatet. For at integrationen skal fungere konfigureres blodsukkermåleapparatet til at fungere som helt almindelig USB-storage, hvor OpenTele Android klienten blot henter en CSV-fil fra en bestemt placering på apparatet. For Abbott Freestyle Navigator II sker overførsel via en proprietær protokol hvor OpenTeleklienten agerer USB host. Side 32 af 35

33 OpenTele HTML5 klient-design/- arkitektur OpenTele HTML5-Klienten benyttes af patienten til at udfylde spørgeskemaer og kommunikere med klinikeren. I modsætning til Android-klienten, så understøtter HTML5-klienten på nuværende tidspunkt ikke integration med måleapparater. Alle måleresultater skal derfor indtastes manuelt af patienten. HTML5 klienten er implementeret som en HTML5 web applikation der bliver pakket ind i en tynd Android app, kaldet en Android wrapper. De forskellige komponenter i klienten er afbildet på nedenstående figur. Patient Android wrapper HTML5 web app Server Nativefunktionalitet Spørgeskemaparser HTTPS Beskedhåndtering HTTPS Native-JavaScript snitflade Grafgenerator Figur 15: HTML5 klient design Android wrapper Android wrapperen er en simpel Android app med ansvar for at pakke HTML5-klienten i en traditionel Android indpakning og give HTML5-klienten adgang til native Android funktionalitet. Native-funktionalitet Native-laget i Android wrapperen står for at sende notifikationer til brugeren og hente enhedsbeskrivelser fra tabletten. På sigt vil det ligeledes være muligt at tilgå eksterne apparater via bluetooth på samme måde som i den oprindelige native Android app. Native-til-JavaScript snitflade Side 33 af 35

34 For at kunne matche funktionaliteten i en native Android klient, gør Android wrapperen en snitflade tilgængelig overfor HTML5-klienten der tillader denne at kalde Androids native-lag. Dermed er det muligt for HTML5-klienten at tilgå al native Android funktionalitet beskrevet i det tidligere afsnit. HTML5 web applikation HTML5 web applikationen står for at præsentere spørgeskemaer, grafer, beskeder, etc. overfor patienten samt kommunikere frem og tilbage med OpenTele borger serveren. Spørgeskemafortolker Spørgeskemaerne modelleres på serveren som grafer - et antal knuder forbundet med stier. Klienten implementerer en fortolker af disse spørgeskemaer, således brugeren bliver ledt gennem knuderne. Der findes flere typer af knuder, bl.a.: Logiske knuder: Sammenligner tidligere værdier for at beslutte vejen gennem skemaet Visningsknuder: Viser tekst for brugeren Indtastningsknuder: Lader brugeren f.eks, indtaste tekst eller tal i indtastningsfelter eller lader brugeren vælge mellem et fast defineret antal udfald, f.eks. Ja eller Nej Måleknuder: Integrerer med en måle-enhed, såsom et blodtryksapparat, en saturationsmåler eller en CTG-måler og gemmer resultatet af målingen. Grafgenerator Når klienten skal vise en graf for en given type målinger, returnerer serveren en repræsentation af denne i form af en række målepunkter med tilhørende metadata. Disse måledata transformeres om til en datastruktur, som kan gives videre til hhv. en tabel- og en grafrenderingsfunktion. Beskedhåndtering Klienten implementerer komponenter som tillader brugeren at sende og modtage beskeder, samt modtage bekræftelser og notifikationer om opkommende spørgeskemaer der skal udfyldes. Side 34 af 35

35 Dokumenthistorik Version Dato Initialer Ændring Initiel version PU Tilføjet HTML5 klient beskrivelse RA Opdateret i forhold til OpenTele HRA Opdateret i forhold til OpenTele Afsnit vedr. brug af OpenTele fra eksterne systemer tilføjet. Side 35 af 35