OpenTele datamonitoreringsplatform

Transkript

1 OpenTele datamonitoreringsplatform Arkitektur og design 1. maj 2013 Side 1 af 42

2 Indholdsfortegnelse Indholdsfortegnelse...2 Indledning...4 Systemlandskab / Arkitekturoverblik...5 Brugsscenarier...7 Scenarie 1: Kliniker knytter spørgeskema til patient...7 Scenarie 2: Patient udfylder spørgeskema...8 Scenarie 3: Kliniker kvitterer for indsendt spørgeskema...9 Scenarie 4: Kliniker kvitterer for alle grønne spørgeskemaer...9 Scenarie 5: Patient sender besked til hospitalet Scenarie 6: Kliniker besvarer besked fra patient OpenTele server-design/-arkitektur Væsentlige designparametre Applikationsarkitektur Realiseret applikations arkitektur Sikkerhedsmodel Rettigheder Patientadgang Spørgeskema-editor Planlagte jobs Datamodel Logisk datamodel Fysisk datamodel Model for brugere, roller og rettigheder Model for patienter Model for klinikere Model for organisation og patientgrupper Model for tærskelværdier Model for beskedhåndtering Model for hændelseslog Model for spørgeskema skabeloner og spørgeskemaer Model for monitoreringsplaner Model for spørgeskemaresultater og måledata Model for kits- og målere Driftsarkitektur Overvejelser om skalering OpenTele klient-design/-arkitektur JSON-parser/-generator Spørgeskema-motor Side 2 af 42

3 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 Dokumenthistorik Side 3 af 42

4 Indledning Dette dokument udgør arkitektur- og designdokumentationen for OpenTeledatamonitoreringsplatformen. OpenTele-datamonitoreringsplatformen (til tider også benævnt KIH datamonitorering) 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. Indledende, som beskrevet i nærværende dokument, tages 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 en borgervendt Android baseret klient, som opsamler måledata fra måleapparater og indsender disse til den centrale 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 Android klienten. Side 4 af 42

5 Systemlandskab / Arkitekturoverblik De overordnede sammenhænge som er eller på kort sigt forventes - etableret i systemkomplekset OpenTele-datamonitoreringsplatformen indgår i, illustreres nedenfor med udgangspunkt i snitfladerne mellem systemernes komponenter. Det fremhæves at arkitekturen forventes at udvikle sig over tid, og at integrationen mellem OpenTele platformen og KIH databasen i skrivende stund (ultimo april 2013) endnu ikke er implementeret. 3 1 Manuel indtastning, USB eller bluetooth overførsel Målingskilde Brorgere/ Patienter OpenTele tablet klient (Android) 2 Proprietært JSON format / https Sundhedsprofessionelle OpenTele Datamonitorering services Klinisk browser brugergrænseflade Anvendende systemer KIH Database services 4 Fælles Kroniker Data XML / https SQL/JDBC SQL/JDBC OpenTele DB KIH Database DB "Hjemme" hos patienten "Telemonitoreringscenter" Separat installation pr. region Fælles database med kronikerdata Figur 1: Overblik over komponenter og sammenhænge i systemkomplekset OpenTele datamonitoreringsplatformen indgår i Systemkomplekset udgøres overordnet af fire komponenter, 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 Android klienten ved manuel indtastning, via USB eller via en krypteret Bluetooth protokol. For målingskilder med Bluetooth understøttelse, anvendes primært Continua Health Alliance godkendte ISO protokoller. Side 5 af 42

6 2. OpenTele Datamonitoreringsklient Datamonitoreringsklienten er en Android tablet app som borgere/patienter anvender til at afvikle spørgeskemaer og sende beskeder til klinikere. Spørgeskemaer hentes fra OpenTele datamonitoreringsserveren som JSON formaterede dokumenter via en sikker forbindelse. Spørgeskemaerne kan indeholde en række forskellige 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 datamonitoreringsserveren. Modtagelse og afsendelse af beskeder fungerer efter samme principper. 3. OpenTele datamonitoreringsserver Serverapplikation som tager udgangspunkt i prototypen udviklet i TeleSkejby projektet.. Serveren er ansvarlig for JSON kommunikation med OpenTele klienter vedr. spørgeskemaer, resultater og beskeder. Serveren indeholder en klinisk brugergrænseflade, som anvendes til at administrere spørgeskemaer, patienter og monitoreringsresultater samt til kommunikation med patienterne ved hjælp af et simpelt beskedsystem. På kort sigt forventes en dataoverførsel til KIH Databasen etableret, således OpenTele datamonitoreringsserveren sørger for, at modtagne målinger kan sendes/indberettes til en central KIH database. 4. KIH database KIH databasen er et centralt system på Sundhedsdatanettet, som via XML baserede web service snitflader, modtager telemedicinske monitoreringsdata fra OpenTele servere, og forventeligt på sigt også andre datakilder. KIH Databasens snitflader gør det også muligt for autentificerede brugere at hente data f.eks. via EPJ systemer. I det følgende afsnit beskrives nogle udvalgte brugsscenarier for OpenTele datamonitoreringsplatformen. Efterfølgende beskrives applikationsarkitekturen for KIH databasen, datamonitoreringsplatformen og klienten. Side 6 af 42

7 Brugsscenarier I dette afsnit gennemgås udvalgte brugsscenarier for OpenTele-datamonitoreringsplatformen. 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 Side 7 af 42

8 13 Vælger evt. planlægning af skema. 14 Klikker på Opret 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 mulighederne Gennemfør måling og Beskeder 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? Side 8 af 42

9 14 Trykker på Ja 15 Viser information til brugeren: Indsendelse af svar gik godt 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 Side 9 af 42

10 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. 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 KIH Datamonitorering. Skridt Patient Klient-app (Android) 1 Viser hovedmenu med mulighederne Gennemfør måling og 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: Besvarelserne er nu indsendt til hospitalet 10 Trykker på OK Side 10 af 42

11 11 Viser liste med ulæste beskeder Scenarie 6: Kliniker besvarer besked fra patient 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. Side 11 af 42

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. Administrator Kliniker Patient Browser Browser OpenTele Android klient Måleapparater KIH database OpenTele applikationsserver Milou server Figur 2: Arkitekturoverblik for OpenTele datamonitoreringsplatformen OpenTele datamonitoreringsplatformen består grundlæggende af følgende bestanddele: 1. OpenTele applikationsserver Applikationsserveren indeholder en brugergrænseflade til klinikere som håndterer kommunikation vedr. spørgeskemaer, monitoreringsresultater og beskedhåndtering med OpenTele tablet applikationen. Applikationsserveren indeholder også en mindre administrativ brugergrænseflade, som anvendes til f.eks. brugerstyring. Side 12 af 42

13 Applikationsserveren rummer desuden systemets database og håndterer indberetning af CTG målinger til en Milou server, samt (på sigt) indberetning af monitoreringsdata til en central KIH database. 2. OpenTele Android (Tablet) App App en varetager dialogen med slutbrugeren/patienten. I app en afvikles spørgeskemaer, som hentes fra OpenTele applikationsserveren. I forbindelse med afvikling af spørgeskemaer opsamler app en monitoreringsdata fra måleapparater og sender disse til OpenTele serveren via en krypteret snitflade. App en indeholder også en simpel besked-klient, som patienter kan benytte til at kommunikere med de klinikere, som er ansvarlige for deres forløb. 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. 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 applikationsserveren er illustreret nedenfor: Side 13 af 42

14 Admin GUI Kliniker GUI Tablet Snitflade Admin services Auditlog og sikkerhed Cinical services KIH eksport services Data Access Objects Database Scheduler Figur 3: Overordnet komponentmodel for OpenTele applikationsserveren Komponentmodellen for OpenTele applikationsserveren 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). OpenTele applikationsserveren 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. Når en mobil NemID verifikation forefindes anbefales det kraftigt at overveje et skift til denne. OpenTele serverens 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. Side 14 af 42

15 Realiseret applikations arkitektur Applikationsarkitekturen for OpenTele serveren 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.6 JavaScript/HTML til den klinikervendte brugergrænseflade Quartz (Jobskedulering for data eksport mv.) Tomcat 7 Java EE Web container SQL Database (H2, MySQL eller MS SQL Server) OpenTele-serveren udstiller en HTML/JavaScript baseret brugergrænseflade til klinikere og en JSON-snitflade til klienter. Serveren er implementeret i Grails 1, der er et opinionated framework og derfor i store træk definerer serverapplikationens interne struktur. Applikationsarkitekturen er lagdelt, 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. Der henvises til dokumentationen for Grails for detaljeret gennemgang af den overordnede struktur af serverens lagdelte arkitektur, som er skitseret i nedenstående illustration. 1 Se Side 15 af 42

16 Figur 4: 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 dog ikke Grails-modellen. Mere herom i afsnittet om spørgeskemaeditoren på side 18. Side 16 af 42

17 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 5: 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, således 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 Beskrivelse QUESTIONNAIRE_READ Må læse enkelte spørgeskemaer QUESTIONNAIRE_READ_ALL Må se oversigt af spørgeskemaer QUESTIONNAIRE_WRITE Må opdatere informationer på et spørgeskema QUESTIONNAIRE_DELETE Må slette et spørgeskema QUESTIONNAIRE_ACKNOWLEDGE 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, at man som kliniker 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 17 af 42

18 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 6: 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 at patienten i kontekst bør være synlig for klinikeren. Beskyttelse mod ændring i data for patienter som klinikeren ikke har adgang til, sikres ved at sikkerhedsfilteret kun tillader POST når den relevante controller-metode eksplicit er annoteret med en white-list-annotering. Det egentlige tjek af adgang til patient sker så i controller-koden. 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 lavet en rig klient, baseret på JavaScript-libraries, som kommunikerer med serveren via JSON. I princippet kan spørgeskema-editoren altså betragtes som en separat klient, der dog kører i en browser på linje med resten af server-gui en. Planlagte jobs I serveren kører tre jobs periodisk: Opdatering af patientnoter, beregning af såkaldte blå alarmer samt eksport til Milou. Milou-eksporten finder alle CTG-målinger der ikke allerede er eksporteret til Milou, og kalder en WSDL-snitflade på en konfigureret Milou-server. Side 18 af 42

19 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 OpenTele-server. De væsentligste elementer i modellen er illustreret, og efterfølgende overordnet beskrevet nedenfor. Figur 7: Logisk datamodel for første version af KIH datamonitoreringsplatformen 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. Side 19 af 42

20 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 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. Fysisk datamodel I dette afsnit beskrives væsentlige dele af det fysiske datamodel for OpenTele serveren. OpenTele serverens underliggende datamodel kan overordnet opdeles i flere indbyrdes sammenhængende dele: 1) Brugere, roller og rettigheder 2) Patienter 3) Klinikere 4) Organisationsstruktur 5) Tærskelværdier 6) Beskedhåndtering 7) Hændelseslog 8) Spørgeskema skabeloner og spørgeskemaer 9) Monitoreringsplaner 10) Spørgeskemaresultater og måledata 11) Kits- og målere I det følgende gennemgås hver del af modellen kort, og illustreres med database-diagrammer baseret på en MySQL implementation. Det understreges at nogle entiteter vil optræde på flere illustrationer, da fokus i hver illustration er på et specifikt område i modellen. OBS: I dokumentationen indgår et samlet diagram over den fysiske datamodel i filen OpenTele Datamodel.png. Side 20 af 42

21 Model for brugere, roller og rettigheder Figur 8: Datamodel for brugere, roller og rettigheder Datamodellen for brugere, roller og rettigheder består af tre primære entiteter, samt mange-tilmange 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 21 af 42

22 Model for patienter Figur 9: datamodel for patient- og relaterede entiteter Tabelnavn patient next_of_kin_person Beskrivelse Tabellen indeholder systemets patienter. Patient er en central entitet, som refereres eller refererer mange af systemets andre entiteter. Pårørende til en patient patient_blue_alarm_questionaireids Tabel som indeholder primærnøgler (ID er) for de spørgeskemaer, hvor et batchjob i systemet har bestemt at der skal oprettes en blå alarm for at indikere, at spørgeskemaets plan ikke er overholdt. Side 22 af 42

23 Model for klinikere Figur 10: Datamodel for kliniker og relaterede entiteter Tabelnavn Beskrivelse clinician Tabellen indeholder systemets klinikere. clinician_questionnaire_preference Tabel hvor de spørgeskema-knuder (spørgsmål) klinikere har valgt skal vises øverst i spørgeskema-visningen i systemets brugergrænseflade er registreret. Side 23 af 42

24 Model for organisation og patientgrupper Figur 11: Datamodel for organisation og patientgrupper Tabelnavn department patient_group Beskrivelse Tabel indeholdende afdelinger oprettet i systemet. En afdeling kan have en række kits tilføjet, og grupperer en mængde af patientgrupper. Indeholder de patientgrupper der er oprettet i systemet. En patientgruppe skal altid referere til én afdeling. Patienter og klinikere kan være tilknyttet en eller flere - patientgrupper mange-til-mange relationerne i mellem henholdsvis patientgruppe og kliniker-tabellen, samt patientgruppe og patient tabellen. En patientgruppe er også har også en direkte reference fra patienttabellen, som modellerer dataansvarlig begrebet. For en patientgruppe kan eksistere et standard tærskelværdi sæt, som Side 24 af 42

25 grupperer en mængde af standard tærskelværdier tilknyttet patientgruppen. patient2patient_group Mange-til-mange relation mellem en patient og de patientgrupper patienten indgår i. clinician2patient_group Mange-til-mange relation mellem en kliniker og de patientgrupper klinikeren deltager i. Side 25 af 42

26 Model for tærskelværdier Figur 12: Datamodel for tærskelværdier OBS: Datamodellen for tærskelværdier er i høj grad kandidat til en store refaktorering. Den mangler væsentlige referencer- og regler, som i stedet er implementeret i applikationens forretningslogik-lag. Tabelnavn standard_threshold_set Beskrivelse Grupperingsentitet, som grupperer standardtærskelværdierne for en patientgruppe. Side 26 af 42

27 threshold En konkret tærskelværdi. Er i systemets objektmodel superklassen i et nedarvningshieraki, hvor numeric_-, blood_pressure-, urine-, og urine_glucose_threshold tabellerne nedarver fra. Er kandidat til en databaserefaktorering, så en strategi for persistering af et nedarvningshieraki ikke mappes til implicitte relationer, som det er tilfældet her. standard_threshold_set_threshold Redundant relationstabel som udpeger de tærskelværdier der indgår i et standard-tærskelværdi sæt. patient_threshold Udpeger patientspecifikke tærskelværdier. numeric_threshold blood_pressure_threshold urine_threshold urine_glucose_threshold Indeholder numeriske tærskelværdier. Modellerer en subklasse til threshold tabellen. Indeholder tærskelværdier for blodtryk (systolisk og diastolisk. Modellerer en sub-klasse til threshold tabellen. Indeholder tærskelværdier for protein i urin. Modellerer en sub-klasse til threshold tabellen. Indeholder tærskelværdier for glucoseindhold i urin. Modellerer en sub-klasse til threshold tabellen. Side 27 af 42

28 Model for beskedhåndtering Figur 13: Datamodel for beskeder og patient noter Tabelnavn message patient_note patient_note_clinician Beskrivelse Modellerer en besked fra en afdeling til en patient, eller fra en patient til en afdeling. Beskeden kan være et svar på en tidligere besked. Dette korrespondence begreb er modelleret med en selv-refererende reference fra én besked til en anden. Patientnoter er noter klinikere opretter vedr. patienter. En reference til patient tabellen udpeger den patient noten omhandler. Det er muligt at registrere at noten er set ved at tilføje en reference til kliniker tabellen via nedenstående patient_note_clinician tabel. Registrerer om en patient note er set af en kliniker. Side 28 af 42

29 Model for hændelseslog Figur 14: Datamodel for hændelseslog Tabelnavn audit_log_entry audit_log_parameter 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. audit_log_controller_entity Lookup tabel, som logger Grails controller og actions på controlleren i til brug for visning i søgebilledet i hændelsesloggen. Side 29 af 42

30 Model for spørgeskema skabeloner og spørgeskemaer Figur 15: Datamodel for spørgeskema-skabeloner og patientspecifikke spørgeskemaer Datamodellen for spørgeskemaer er opdelt i en skabelon-del og en patientspecifik del. Den oprindelige designtanke og kravet - var, at der skulle eksistere spørgeskemaskabeloner, som kunne anvendes som de var, eller som kunne individualiseres og frit tilpasses til den enkelte patient. I praksis er denne funktionalitet ikke prioriteret højt, og det skal derfor overvejes om skabelon/instans modellen i virkeligheden gør denne del af datamodellen unødvendigt fleksibel. Tabelnavn questionnaire Beskrivelse Topknude i en spørgeskemaskabelon. Indeholder skemaets navn, versionering med videre, og refereres af skabelonens knuder (noder). Side 30 af 42

31 questionnaire_node Skabelon-knude i et spørgeskema. choice_value questionnaire2meter_type Hvis en spørgeskemaskabelon-knude er en type hvor brugeren sal vælge mellem en liste af valgmuligheder, modelleres valgmulighederne i denne tabel. Relationstabel som udpeger de måleapparattyper, der anvendes i skemaet. patient_questionnaire Patientrettet / individualiseret / instantieret version af en spørgeskemaskabelon. Refererer den skabelon skemaet blev dannet ud fra, og refereres også fra de tabeller som tilsammen opsamler og opbevarer resultaterne af en udførelse af spørgeskemaet. patient_questionnaire_node Patientrettet / individualiseret / instantieret version af en spørgeskemaskabelon-node. patient_choice_value Patientrettet / individualiseret / instantieret version af choice_node. Side 31 af 42

32 Model for monitoreringsplaner Tabelnavn monitoring_plan Figur 16: Datamodel for monitoreringsplanen Beskrivelse Modellerer en patients monitoreringsplan. På nuværende tidspunkt kan en patient have én og kun én monitoreringsplan. Monitoreringsplanen kan ses som en overordnet gruppering af skemasatte spørgeskemaer. questionnaire_schedule En questionnaire_schedule er en skemasætning af et spørgeskema. Skemasætningen beskriver hvornår- og evt. med hvilken frekvens et spørgeskema skal udføres af en patient. Side 32 af 42

33 Model for spørgeskemaresultater og måledata Tabelnavn measurement_type measurement Figur 17: Datamodel for målinger og spørgeskemaresultater Beskrivelse Målingstype. Identificeres med et unikt navn. Angiver de målingstyper systemet understøtter, og refereres fra måling (measurement) tabellen. Målingstypen anvendes også til at angive hvilken målingstype et knude-resultat (node_result) indeholder. En telemedicinsk måling af den type, som beskrives ved referencen til målingstype tabellen. F.eks. puls, blodtryk, ctg, saturation, m.v. En måling kan produceres via et spørgeskema. Hvilket spørgeskema og hvilken knude målingen stammer fra, kan identificeres ved at følge referencen til node-resultat tabellen, og videre derfra. Tabellen er modelleret, så ikke alle felter er udfyldt for alle målingstyper. F.eks. er der dedikerede felter til CTG oplysninger. tabellen har en 0-til mange relation til meter så det er muligt at registrere hvilke måleapparat målingen stammer fra. Denne relation er i nuværende version af systemet (1. maj 2013) ikke i anvendelse. Side 33 af 42

34 completed_questionnaire Grupperingsentitet som samler resultatet af et gennemført (/udfyldt) spørgeskema. Skemaet refereres fra kliniker tabellen, så det er muligt at modellere hvilken knliniker som evt. har kvitteret for resultatet, og/eller hvilken kliniker som har valgt at resultatet skal ignoreres. node_result Registrering af resultatet fra gennemførelse af en knude i et spørgeskema. Afhængigt af knudens type, kan resultatet være f.eks. svaret på et simpelt spørgsmål, eller et ja/nej valg. Hvis den gennemførte knude er en målingsknude registreres resultatet/resultaterne af målingen i målingstabellen (measurement). Noderesultatet er i applikationens objektmodel modelleret med et nedarvningshieraki, hvor alle klasser i hierarkiet gemmes i samme tabel. class attributten anvendes af Grails til at skelne hvilket klasse den enkelte record i tabellen skal modelleres som. Side 34 af 42

35 Model for kits- og målere Figur 18: Datamodel for kits- og målere Tabelnavn meter monitor_kit meter_type Beskrivelse Indeholder registrering af målere/apparater. Et apparat kan indgå i et kit, og er af den type som målertype (meter_type) angiver. Indeholder registrering af kits, herunder hvilken afdeling kittet tilhører. Et kit grupperer et mængde af målere. Måler-/apparattyper. Anvendes som type table for målere samt til at angive hvilken type måling en spørgeskemaknude omfatter, samt (redundant) hvilke målertyper et spørgeskema skal bruge for at kunne udføres. Side 35 af 42

36 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, både ved at udvide hardwarekapacitet og ved at etablere parallelitet i arkitekturen. Produktnavne mv. i nedenstående er forslag som kan tilpasses den konkrete driftsleverandørs præferencer. Bluetooth, USB Klinikere (Browser) Borgere- og patienter (Android tablet) Måleudstyr Internet eller f.eks. sundhedsdatanet https/port 443 https/port 443 KIH Database OpenTele applikationsserver (f.eks. Tomcat) JDBC Milou Databaseserver (f.eks. MySQL el. SQL*Server) Figur 19: Eksempel på driftsarkitektur for OpenTele datamonitoreringsplatform Som udgangspunkt er OpenTele 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. Side 36 af 42

37 OpenTele serverapplikationen er baseret på Grails og bygges og afvikles med Java 1.6. Applikationen er testet web containerne Tomcat 7 og JBoss. 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 5 og MS SQL Server 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. 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. 3 Se listen over supporterede Java EE containere på adressen: 4 Kan ske enten i systemets kildekode, eller i en konfigurationsfil Side 37 af 42

38 OpenTele klient-design/-arkitektur Klienten benyttes af patienten til at udfylde spørgeskemaer og kommunikere med klinikeren. En vigtig bestanddel af udfyldning af spørgeskemaer er integration til diverse måleapparater, fx til at måle blodtryk og overføre resultaterne til klienten. Klienten er implementeret som en Androidapp. De forskellige komponenter i klienten er afbildet på nedenstående figur. 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. Der refereres til systemsnitfladebeskrivelsen for yderligere dokumentation af JSON-formatet til udveksling af spørgeskemaer. Side 38 af 42

39 Spørgeskema-motor Spørgeskemaerne modelleres på serveren som grafer - et antal knuder med veje imellem dem. Klienten implementerer udførslen af disse spørgeskemaer, således at brugeren ledes igennem 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: Informér brugeren i form af tekst. Indtastningsknuder: Lad brugeren indtaste tekst eller tal i indtastningsfelter, lad brugeren vælge mellem et fast defineret antal udfald, lad brugeren vælge Ja eller Nej,... Måleknuder: Integrér med en måle-enhed, såsom et blodtryksapparat, en saturationsmåler eller en CTG-måler og gem resultatet af målingen. Hele klientens logiske flow uden om spørgeskemaerne er også implementeret via spørgeskema-motoren, således at login, visning af tilgængelige spørgeskemaer, visning af beskedliste osv. også 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 til brugeren. Klienten implementerer et antal grafiske elementer der så kan kombineres i et skærmbillede, og 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 kører over 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 generelt at håndtere Continua-protokollen, hvor de enkelte apparat-integrationer blot specificerer hvilken type apparat der integreres mod, samt 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): Side 39 af 42

40 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ærdierne 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. USB integration til AccuChek blodsukkermåler På tidspunktet for skrivning af dette dokument er der i OpenTele projektet implementeret én USB baseret integration, nemlig integration til AccuChek blodsukkermåleapparater. Integrationen er implementeret som simpel indlæsning af en kommasepareret (CSV) fil fra måleapparatet. Side 40 af 42

41 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. Side 41 af 42

42 Dokumenthistorik Version Dato Initialer Ændring Initiel version Side 42 af 42