Forprojekt: Microservices til telesundhed

Transkript

1 Forprojekt: Microservices til telesundhed Slutnotat vedrørende proof of concept for microservices til telesundhedsløsninger Version 1.3 D MICHAEL CHRISTENSEN ALEXANDRA INSTITUTTET APRIL 2017

2 Side 2 41 Indholdsfortegnelse 1 Indledning Ledelsesresumé Leverancer Målarkitektur og anbefalinger for serviceplatform Målarkitekturens bestanddele Prototyper Implementeret serviceplatform Dele af serviceplatform, som er inkluderede i den nuværende prototype: Dele af serviceplatform, som er udeladt fra den nuværende prototype: Implementerede microservices Ikke implementerede microservices Apps Oplæg til roadmap og generelle anbefalinger Leverandørkompetencer Tekniske forudsætninger Migrering og videreudvikling Risici Anbefalet fremgangsmåde Bibliography APPENDIX A: Consent management in a micro service architecture Introduction Privacy principles Architecture... 30

3 Side Obtaining consents asynchronously Responsibilities of services Diagram Synchronous request Asynchronous registration of consents APPENDIX B: Use cases Overordnet flow Use cases: nuværende OpenTele: APPENDIX C: Vejledende beskrivelse af indhold i OpenTele-kontrakter Baggrund Kontrakter om OpenTele og udbud Generelle opmærksomhedspunkter Samarbejdet med 4S Beskrivelse af leverancer til 4S repository... 40

4 Side Indledning Dette notat opsummerer resultater og anbefalinger for projektet Forprojekt: Microservices til telesundhed Projektet er finansieret af Center for Telemedicin, Region Midtjylland. Desuden indgår der i projektets arbejde resultater, som er finansieret af Alexandra Instituttets resultatkontrakter vedrørende Økosystem for sundhed og velfærd [1] og Sikkerheds- og privacyværktøjer [2]. Proof of concept projektet har fokuseret på en microservicebaseret infrastruktur for telemedicin, kaldet OpenTele3, som der er lagt op til i [3] og [4]. Af historiske årsager har samlingen af open source microservices fået navnet OpenTele3. Der er imidlertid så afgørende forskelle på den nye samling open source microservices og versionerne OpenTele 1 og OpenTele 2, at der er tale om et grundlæggende skifte både mht. teknologi og basalt tankesæt. OpenTele 1 og OpenTele 2 var færdige end-to-end løsninger, hvorimod en ny samling af open source microservices er byggeklodser, der indgår i end-to-end løsninger løsninger, der sammensættes af open source og closed source-elementer efter leverandørens/kundens valg. Projektet har overordnet stræbt efter vha. prototyper at levere en konkretisering af basisinfrastruktur, dvs en platform for telemedicinske microservices, udvalgte microservices, som understøtter strategisk/kritisk forretningsfunktionalitet, hvilke services, der er nødvendige for at migrere fra OpenTele 1 til OpenTele3 for gravide med komplikationer I forhold til den samlede telemedicinske infrastruktur adresserer OpenTele3 det centrale opsamlingspunkt (jf. [5]), samt borger og sundhedsprofessionelle klienter. Figur 1: Projektfokus Hovedfokus for projektet har således været på microservices og platform som udgør (1) i Figur 1. Dvs. projektet har i et agilt og accelereret forløb på små tre måneder, udviklet kode og kørende prototyper for disse dele. Derudover har projektet udviklet kørende prototyper af rudimentære klient apps for borger

5 Side 5 41 og sundhedsprofessionel hhv. (2) og (3) i Figur 1. Endelig har projektet konfigureret et XDS-arkiv [6] (jf. (4) i Figur 1), som benyttes, når microservices arkiverer HL7 CDA dokumenter [7]. Platformskomponenter og services er udviklet og/eller konfigureret til forskellig færdigheds- eller modenhedsgrad, og det er langt fra alle dele ift. et målbillede for hele systemet, som har kørende kode bag sig. Da projektets formål udelukkende har været at levere proof of concept befinder de udviklede komponenterne sig således typisk på mockup/tidlig prototype stadie. Modenhedsniveau for de enkelte dele er søgt angivet i projektets tekniske dokumentation [8]. Bemærk omkring sprog i dette notat: Dokumentet indeholder figurer og referencer til dokumenter, som er en del af projektets open source release. Disse er på engelsk (i overenstemmelse med 4S s retningslinjer). 2 Ledelsesresumé Projektet har som proof of concept på en telemedicinsk infrastruktur, baseret på microservices, udviklet prototyper for en serviceplatform for telemedicinske microservices, udvalgte microservices, som understøtter opsamling og udstilling af måledata og spørgeskemaer På basis af de udviklede prototyper har projektet formuleret en målarkitektur sammen med et sæt af anbefalinger til en kommende serviceplatform for telemedicinske microservices. Desuden har projektet specificeret et oplæg til et minimumssæt af microservices, som vurderes nødvendige for at understøtte telemedicin som det udføres på Afdeling Y, AUH, og med udgangspunkt i de telemedicinske scenarier som er kendte fra særligt TeleCare Nord og de øvrige KIH projekter. Projektet vurderer, at man med udgangspunkt i den foreslåede målarkitektur og sættet af anbefalinger vil kunne udvikle en telemedicinsk infrastruktur, som effektivt understøtter de strategiske målsætninger om at understøtte en open source flerleverandørstrategi, forbedrede mulighederne ift. CE-mærkning og kvalitetssikring, kunne tilpasse løsninger til individuelle kommunale og regionale forhold, være i overensstemmelse med den standardiserede vej, som er udstukket i de nationale referencearkitekturer. Figur 2 opridser målarkitekturens hovedbestanddele samt kategorier af microservices. Projektet har resulteret i en række anbefalinger angående kompetencer hos leverandører til udvikling af serviceplatform og microservices samt en vurdering af tekniske forudsætninger hos såvel kunde som leverandør. For begges vedkommende fokuseres der på aspekter omkring evner til såvel teknisk som organisatorisk at understøtte såkaldt continuous delivery og deployment. Dvs. for det første en understøttelse af en høj grad af automatisering af de skridt i udviklingsprocessen, som drejer sig om at bygge, teste og integrere softwarekomponenter, og for det andet en tæt integration af disse skridt med de skridt, som er involveret i at idriftsætte selvsamme komponenter. Endelig anbefaler projektet en fremgangsmåde, hvor kernen af microserviceplatform og microservices i en første version udvikles af én leverandør. Herefter bør man meget hurtigt involvere andre leverandører på de enkelte microservices, så man hindrer, at én leverandør i realiteten kan skabe en siloløsning ved at diktere struktur, snitflader og dokumentationsniveau og -kvalitet. Apps til borger og sundhedsprofessionelle bør kunne udvikles af andre leverandører. Dog med den afhængighed at visse snitflader i kernen skal være fastlagte først.

6 Side 6 41 Figur 2: Målarkitektur med kategorier af microservices 3 Leverancer I overensstemmelse med projektbeskrivelsen i den indgåede kontrakt er projektets leverancer: 1. PoC OpenTele3 basisinfrastruktur og services: a. Kildekode: b. Dokumentation: i. Nærværende dokument ii. iii. Byg og kørsels dokumentation for de enkelte projekter på 2. Oplæg til krav til serviceplatform for microservice infrastruktur: Nærværende dokument. 3. Specifikation minimumssæt af microservices, som er nødvendige for at understøtte et basalt telemedicin setup: Nærværende dokument. 4. Oplæg til roadmap for udvikling af OpenTele3 til gravide med komplikationer: Nærværende dokument.

7 Side Målarkitektur og anbefalinger for serviceplatform Projektets forslag til målarkitektur er dels udarbejdet på basis af de forud formulerede mål og kriterier, som gennemgås nedenfor, dels er den udarbejdet på basis af de konkrete erfaringer gjort i projektets agile og iterative proof of concept forløb. Det overordnede udgangspunkt for formuleringen af en målarkitektur har været de strategiske mål for OpenTele3, som formuleret i [4] og [3]. Dvs. OpenTele3 skal effektiv understøtte: Open source flerleverandørstrategi Sammenhængen med projekt Modning af Telemedicinsk Infrastruktur (MaTIS) Det tværsektorielle samspil mellem regioner, kommuner og øvrige sundhedsaktører Forbedrede muligheder ift. CE-mærkning og kvalitetssikring Dvs. visionen har således fra starten været at muliggøre, at flere leverandører i parallel kan udvikle bedre løsninger til brugerne via en opsplitning af OpenTele i løstkoblede komponenter og services. På forhånd var ønskede kvaliteter for OpenTele3 på den baggrund formuleret som Uafhængighed: Mulighed for parallel udvikling og løbende og mere uafhængig udrulning. Individuel tilpasning: Muligheden for at skræddersy løsninger efter behov. Genbrug: Øget modularisering via øget opsplitning i komponenter. Veldefinerede snitflader: Benyttelse af veldefinerede, standardiserede snitflader og formater. Indkapsling af kritisk funktionalitet: Nemmere understøttelse af certificering og kvalitetssikring. Målrettet skalerbarhed: Muligheden for individuel skalering via små enheder 1. Med ovenstående som basis og med udgangspunkt i de use cases, som ønskes understøttet, lagde projektet ud med en prioritering af ønskede kvalitetsattributter for systemet. Prioriteringen af kvalitetsattributterne adresserer det ønskede målsystem, og formålet med prioriteringen er at fungere som en ledetråd for de valg, der gøres omkring softwarearkitekturen. Prioriteringen som formuleret i projektets tekniske dokumentation: Prioritization of software quality attributes The qualities listed are inspired by 'Software Architecture in Practice', Len Bass, Paul Clements, Rick Kasman. Scale: 1-5 where 5 is the highest priority and 1 lowest. Simplistically said, in decisions between different designs the design that fulfils a higher category quality take precedence over the design that fulfils a lower category. A cat. 1 quality does not mean that the system should not possess this quality, it is just prioritized lower than all other qualities. A cat. 3 priority means we judge it a normal or average priority. Category 5: Modifiability: other groups or individuals can easily add new functionality to the platform and/or the microservices. Monitorability: it must be possible to monitor resource usage, errors, dependencies and other important aspects of the system. As a part of a microservice system, it is crucial to be able to monitor the system at all times. 1 Inden for telekommunikation og softwareudvikling, er skalerbarhed en ønskværdig egenskab ved et system, et netværk eller en proces, der indikerer systemets evne til enten at håndtere voksende mængder af arbejde på en effektiv måde, eller at være yderst fleksibel og mulig at kapacitetsudvide indenfor en overskuelig tid. [wikipedia] Med microservices kan man skrue op og ned for kapacitet ift. individuelle services.

8 Side 8 41 Developer distribution: distributed and independent development teams must be able to develop on the system in parallel. In an open source world this must be prioritized as high as possible. Usability (of architecture): from the developers' point view, it must be easy to add new components and/or use existing components as easy as possible (i.e. usability is not towards the end users - in this project, all though this is how Bass et al meant it). Category 4: Interoperability: since there are many different suppliers to the real system, the various microservices in the system must be able to communicate easily, and the microservice-platform must be able to communicate easily with the microservices. Security: must have high priority but not a cat. 5 since this would mean security dominates over everything below. Testability: it must be easy to test the microservices and the integration of the microservices with each other and the platform. Category 3: Deployability (single service): it should be easy to deploy single services. Scalability: both horizontal scaling and load balancing must be a part of the architectural solution Availability: it is not mission critical or life critical that the system is running 24/7. If the system is down for 2 minutes, it is okay, and this is why it is prioritized this as cat 3 and not higher Variability: the system is able to handle different kinds of tasks and in different domains. But in this project the design needs only to include tasks in the telemedicine domain (regional and municipal use) Category 2: Mobility (like elasticity): it must not be a requirement that the components/microservices scale automatically, but the services must be able to be replaced or moved as needed. Performance: since this is not a high-performance system with low latency requirements (it is for instance not crucial if responses are delivered within milliseconds), and since there are not an enormous amount of concurrent users of the system (not twitter or linked-in scale), this attribute is prioritized relatively low. Category 1: Deployability (whole platform): the production system is not intended to be moved around from time to time. Rather, we know that the system will be deployed at specific hosts. Portability: it is not necessary that the production system is able to run on a bunch of different platforms. Tabel 1: Kvalitetsattributter Projektets målarkitektur er således formuleret med prioriteringen af kvalitetsattributter som guide og med basis i de ovennævnte mål og brugsscenarier. Desuden har projektteamets ekspertise indenfor microserviceorienteret og Internet of Things arkitektur spillet en væsentlig rolle ift. udformningen af arkitekturen. Målarkitekturen er i overordnet perspektiv illustreret i Figur 3.

9 Side 9 41 Figur 3 Overordnet microservicebaseret målarkitektur Dvs. vi foreslår en arkitektur, hvor apps og udstyr vendt mod borgere og sundhedsprofessionelle har et kommunikationsmæssigt single-point-of-entry i form af en API gateway, som dirigerer kommunikationen videre til specialiserede borger- og sundhedsprofessionelle backend-for-frontend (BFF) services, som igen indkapsler den centrale, microservicebaserede infrastruktur. De centrale microservices behandler, gemmer, udstiller de indkomne data. Desuden sørger microservices for videresendelse af de indkomne data til centrale arkiver (via XDS eller anden standard snitflade). Microserviceinfrastrukturen udstiller data til apps via HL7 FHIR snitflader [9], som er velegnede til kommunikation med mobile og webbaserede klientsystemer. Der benyttes også FHIR, når microservices kommunikerer synkront, REST-baseret. Den hyppigst forekommende kommunikationsmetode, internt mellem microservices, er dog via det asynkrone beskedsystem, som via en publish-subscribe baseret protokol giver løst koblet kommunikation mellem services. Microserviceinfrastrukturen fungerer i forhold til de centrale arkiver som en cache af de masterdata, som lagres i arkiverne. For overskuelighedens skyld er det ikke alle overordnede bestanddele af arkitekturen, som er tegnet ind i Figur 3: Anvendelsen af letvægts containerteknologi til procesmæssig isolering og nem deployment af services. Sikkerhedsinfrastruktur med Identity Provider (IdP) og Secure Token Service (STS). Eksterne systemer som der kommunikeres med via såkaldte adaptor microservices (eksempelvis NSP stamdataservice (CPR) og Medexa Milou [10] til lagring og visning af CTG). Microservices proxy eller lokal gateway foranstillet hver service. Dvs. mulighed for proxy services, som indeholder generisk funktionalitet (f.eks. i relation til sikkerhed), og som lægger sig som et kommunikationslag foran alle microservices.

10 Side Målarkitekturens bestanddele I det følgende gennemgås den overordnede målarkitekturs bestanddele. Disse bestanddele udgør en væsentlig del af projektets arkitekturmæssige anbefalinger og er således beskrevet i nogen detalje. API gateway: Foran microservicesinfrastrukturen står en API gateway. Dette er single point of entry for borgerrettede og sundhedsprofessionelles apps. API gateway en indkapsler den interne microserviceinfrastruktur og sørger for at dirigere trafikken videre til infrastrukturen på indersiden af gateway en. Derudover kan gateway en typisk også være involveret i andre opgaver, såsom load balancing, caching og autentificering. Backend-for-frontends: Hvor API gateway en står for den basale routing af trafik, så er backend-forfrontends (BFF) der, hvor man samler og udstiller den forretningsfunktionalitet, som retter sig mod specifikke typer af klienter. Alternativet til en BFF strategi vil enten være at have én samlet server-side API mod alle klienter af alle typer, eller alternativt at lade klienter have dybt kendskab til den interne microservice infrastruktur og kalde direkte på disse gennem API gateway en. Det sidste alternativ er generelt ikke ønskværdigt, idet alle eksterne klienter dermed bliver hårdt koblet ift. den interne microserviceinfrastruktur dvs. ændringer på en enkelt microservice s API vil kunne medføre at alle klienter skal ændres. Det første alternativ har typisk ulemper i de situationer, hvor klient apps kører på forskellige typer af platforme med forskellige krav til grænseflade og båndbredde. I vores tilfælde afhænger kravene til grænseflade, båndbredde og funktionalitet af om den er rettet mod borger eller mod sundhedsprofessionel. Derfor foreslår vi i første omgang to BFFer, nemlig en rettet mod de borgerrettede apps og en rettet mod de sundhedsprofessionelle apps. Mere om BFF kan læses i artiklen Pattern: Backends For Frontends [11], hvorfra figurerne i Tabel 2 er taget. Tabel 2: BFF versus general purpose server-side API iflg. [11] Et eksempel på funktionalitet i Healthcare Professional backend-for-frontend kunne være en funktion, som med udgangspunkt i den sundhedsprofessionelle, som er logget ind, henter en liste af patienter, som denne sundhedsprofessionelle har ansvar for at overvåge dvs. en slags hent mine patienter funktion. Denne funktion vil så have ansvar for at kalde de interne microservices mhp. bl.a. at udrede samtykke og patienter tilknyttet den sundhedsprofessionelles afdeling og/eller patienter tilknyttet team / rolle / individ. Noget som vil involvere flere forskellige services i infrastrukturen, men som via BFF en kan udstilles til apps med en enkelt funktion i snitfladen.

11 Side Input services: Input services er målrettet de borgerrettede apps og apparater, og det er her, at disse apps og apparater afleverer deres data i forskellige formater. Input services lever på linje med BFF er på grænsen mellem apps og den indre microservice infrastruktur. I en vis forstand kan de ses som en del af BFF strategien, men de implementeres som separate services: Én for hver type af input, som ønskes understøttet. Dvs. det er input services, som implementerer den standardiserede grænseflade mellem lokal opsamlingsenhed og centralt opsamlingspunkt (jf. [5] og [12]). Der kan således være separate input services for: IHE Patient Care Device PCD-01: Modtagelse af målinger over SOAP i PCD format som anbefalet i [5]. HL7 FHIR Observation: Modtagelse af målinger via REST i FHIR Observation ressource format som det ventes anbefalet i den kommende version af Continua Design Guidelines 2. Modtagelse af spørgeskema svar: o Modtagelse HL7 QRD: Modtagelse af spørgeskemasvar via REST som anbefalet i [12]. o HL7 FHIR QuestionnaireResponse: Modtagelse af spørgeskemasvar via REST i FHIR QuestionnaireResponse format som det ventes anbefalet i den kommende version af Continua Design Guidelines. Kontinuert strøm af CTG fra Monica AN24. Bemærk at offline (ikke-kontinuert) CTG bør kunne modtages på en standard snitflade til målinger dvs. via FHIR Observation på REST eller via PDC API på SOAP. Figur 4 illustrerer princippet omkring inputservices, som implementerer de standardiserede snitflader ud ad til, og som videresender selve det modtagne indhold til beskedsystemet. Herefter overtager andre microservices, som abonnerer på indhold af specifikke typer den videre behandling (se eksempel nedenfor under Asynchronous messaging system) Input services har ikke tilstand i form af en underliggende database e.l., men pakker typisk bare det leverede indhold ud (fra en SOAP- eller REST-snitflade) og sender det ud på en kanal på det asynkrone beskedsystem (se nedenfor). Dog, hvis input er en kontinuert strøm (som det kan være fra Monica AN24), kan andre videresendelsesstrategier komme på tale. Andre input services kan understøtte velfærdsteknologiske scenarier i form af input fra IoT apparater, som løbende eller periodisk indsender data uden brugerens intervention. Kunne f.eks. være fra lys- / bevægelsessensorer hjemmet, som sender data til en input service som understøtter MQTT-protokollen [13]. 2 I rammerne af Personal Connected Health Alliance arbejdes der i øjeblikket med udformning af guidelines for overførsel af målinger og spørgeskemasvar ved anvendelse af HL7 FHIR. De norske myndigheder er meget aktive i fb.m. dette. Alexandra Instituttet er medlem af PHCA og følger arbejdet i de tekniske arbejdsgrupper tæt.

12 Side Figur 4: Input services udstiller standardiserede snitflader Asynchronous messaging system: Kommunikation imellem microservices kan enten være synkron eller asynkron. RESTful kommunikation er eksempelvis typisk synkron, idet der umiddelbart gives et svar på hvert kald. I asynkron kommunikation ventes der ikke på svar. Når beskeder udsendes fra en service, fortsætter servicen umiddelbart med sin processering og venter ikke på svaret. Et eventuelt svar kan komme på et vilkårligt senere tidspunkt hvis der da overhovedet gives og/eller forventes et svar. Asynkrone beskedsystemer anvendes hyppigt i microservicearkitekturer, hvor man ønsker lav kobling mellem komponenter, og hvor man, på forskellige steder og med forskelligt formål, ønsker at kunne tage imod, udlæse og løbende behandle større datamængder. Disse karakteristika er oplagt sammenfaldende med kvaliteterne for vores microservicebaserede telemedicinske system. Asynkrone beskedsystemer understøtter ofte såvel punkt-til-punkt kommunikation som publish-subscribe baseret kommunikation. Af hensyn til løs kobling lægger vi vægt på, at beskedsystemet understøtter sidstnævnte type. Dvs. et beskedsystem, hvor services kan sende beskeder og data under forskellige emner til beskedsystemet. Andre services vil abonnere på bestemte emner og vil således modtage beskeder/data fra disse emner, når beskedsystemet modtager disse. Eksempel: En FHIR Observation input service modtager udefra en FHIR Observation ressource. Denne ressource sendes til beskedsystemet under emner FHIR Observation. Der er to forskellige services, som abonnerer på dette emne: En som gemmer indkommende FHIR Observations i en database og en som tager konverterer indkommende FHIR Observations til HL7 PHMR format (for herefter at sende PHMR en ud under passende emne på beskedsystemet).

13 Side Bemærk: Et asynkront beskedsystemet er ingen hindring for, at der på teknisk niveau kan sendes en kvittering for modtagelsen af data f.eks. når en måling er modtager og gemt af FHIR Observation servicen eller når samme er modtaget og gemt af en XDS database. Logging / monitoring: Det er et fundementalt princip i microserviceorienterede arkitekturer, at services skal kunne fungere som små uafhængige enheder. Dvs. hver service skal kunne fungere uden resten af systemet og skal typisk kunne idriftsættes uden, at omgivende services behøver ændres. Dette princip giver mange fordele, men efterhånden som vi introducerer flere og flere små services i vores infrastruktur, møder vi typisk en udfordring i forhold til en mere monolitisk orienteret arkitektur: Det er sværere at overvåge og udtale sig om systemets samlede sundhedstilstand. Hvis der pludseligt er noget galt langsomme svartider i klienter eller lignende er det med kun én server relativt enkelt at starte fejlfindingen ved at se på denne ene servers performance, svartider og fejllogs. Med en microservicebaseret infrastruktur med måske services er det straks vanskeligere at vide, hvor man skal starte. Selvom microservices skal kunne fungere autonomt mht. idriftsætning o.l., så lever de jo netop ikke alene, men kommunikerer med omgivelserne, som udgøres af andre microservices. Uden de rette logging-/monitoreringsværktøjer og mekanisker kan det være svært, når det samlede system ikke opfører sig pænt, at afgøre om det er en enkelt service, der er synderen, eller om det er pga. mere komplicerede, afledte sammenhænge mellem disse. Det er her, at omfattende logging og monitorering med central aggregering og indeksering af logdata bliver meget vigtig og bør således tænkes ind i en indbygget understøttelse i arkitekturens komponenter. Discovery: Når microservices skal kommunikere direkte med hinanden, skal de naturligvis have en måde at finde hinanden på. Dvs. basalt skal de kende hinandens netværkslokation i form af IP-adresse og portnummer. Men IP-adresser er typisk dynamisk allokerede og udviklere kan ændre portnumre over tid. For også på netværksniveau at understøtte løs kobling, har vi derfor brug for en mekaniske, så vi kan opdage og kommunikere med hinanden uden disse specifikke adressedetaljer. Til dette bruger vi en discoverymekanisme. Discovery- og routingmekanisker skal sætte os i stand til at kunne adressere en service på en form som fremfor som På det basale niveau anbefaler vi således en generel DNS-baseret discoverymekanisme, typisk kombineret med load balancerende funktionalitet i en service og routing gateway, således at kommunikation kan fordeles hensigtsmæssigt mellem kloner samme service. RESTful kommunikation, HL7 FHIR: Kommunikationsmæssigt kan man vælge at basere en microservicearkitektur på et rent asynkront, event sourced eller eventbaseret paradigme se f.eks. [14]. Dette kan typisk hænge godt sammen med anvendelse af Command Query Responsibility Segregation (CQRS, jf. [15]) en arkitekturstil, som kunne give mening i forbindelse med telemedicin, idet der er stor forskel på måden, hvorpå data modtages, og måden hvorpå data tilgås. Vi har dog valgt at designe en arkitektur, hvor der benyttes en blanding af det eventbaserede og RESTful kommunikation, sidstnævnte baseret på HL7 FHIR. Dette dels med udgangspunkt i 4S s målarkitektur for OpenTele3 [16] og dels med argumentet, at en ren CQRS-/eventbaseret arkitektur kan være sværere at forstå og arbejde med. Netop i vores tilfælde er forståeligheden af arkitekturen prioriteret højt af hensyn open source flerleverendørmålsætningen. Valget af FHIR er gjort i overensstemmelse med principper og målsætninger i OpenTele3 roadmap for næste skridt 3 [4] og [3] dvs. danske referencearkitekturer og Continua Guidelines overholdes, mens FHIR anvendes på de snitflader, hvor det i øvrigt giver mening. Mht. FHIR udbredelse og modenhed observerer vi desuden, at FHIR er på vej mod frigivelsen af STU3 versionen (forventet feb. 2017), hvor man ikke længere er i Draft version 3 Reviewet af 4S Softwaregruppen

14 Side Continua (PHCA) er på vej med et sæt nye guidelines, hvor der introduceres profiler for kommunikationen mellem lokal opsamlingsenhed og centralt opsamlingspunkt baseret på FHIR. Flere af de nordiske lande, særligt Norge, orienterer sig mod anvendelse af FHIR, især på det telemedicinske område. Store spillere på det internationale marked for sundheds-it, som Epic, Cerner, og Meditech arbejder seriøst med FHIR snitflader. I Danmark anvender Systematic FHIR til interne snitflader i forbindelse med EOJ en (Columna Cura) til Aarhus og Københavns kommuner. Mht. vores brug af FHIR i projektet og til kommende produktionsversion af OpenTele3 har vi gjort os følgende observationer: Der bør laves en gapanalyse af CDA og FHIR målrettet målingsdata (PHMR vs FHIR Observation, Device mv.) og spørgeskemaer (HL7 QFDD/QRD vs FHIR Questionnaire/Questionnaire- Response). Der behøver ikke være 100% overlap mellem de to, men det er vigtigt at vide, hvornår/om vi har brug for FHIR extensions o.l. Man bør lave danske profiler af de FHIR ressourcer, som er relevante i forhold til telemedicinske målingsdata og spørgeskemaer. Ligesom man i øjeblikket i MedCom regi profilerer FHIR Appointment ressourcen til dansk brug samtidig med, at man profilerer CDA-baserede aftaler. Der har i projektgruppen været diskussion om FHIR er godt til både eksterne og interne snitflader. De eksterne er der ingen tvivl om aht. standardisering, men særligt effektiviteten ved at sende relativt store hele FHIR ressourcer rundt internt har været debatteret. Det viser sig dog, at FHIR STU3 kommer med specifikation af såkaldt patch-funktionalitet på REST-snitfladerne. Det betyder, at man kan nøjes med at sende præcis de ændrede attributter og ikke hele ressourcer rundt. Dette burde imødegå performancebekymringer. FHIR Conformance statement er en vigtig del af FHIR, også i en microserviceverden, hvor dokumentation og verifikation af API er er en prioritet. Et FHIR Conformance statement er en specifikation, som enhver kørende service, der understøtter FHIR, skal udstille overfor sine omgivelser. Med dette statement specificerer servicen, hvilke dele af FHIR specifikationen, den overholder. Udover at udnytte det i testsammenhæng vil man, i en arkitektur som vores, jævnligt kunne checke conformance statement hos kørende services, som man afhænger af, eller alternativt kunne bygge et check ind i service discovery. Dette vil bidrage til at sikre, at de service API er, som man afhænger af, svarer til forventningerne. I en RESTful verden som FHIRs, så indeholder ressourcer URL-referencer til andre ressourcer. Disse lever potentielt på andre servere (microservices). Man bør via anvendelse af passende discovery- og routingmekanismer sikre sig mod, at disse referencer bliver forældede, når services flytter eller ændrer sig. FHIR understøtter transaktioner 4 via såkaldte transaction interactions, når mere end en ressource opdateres. Når ressourcer spredes over flere services er dette ikke automatisk understøttet. Der er teknikker til at implementere distribuerede transaktioner (altså transaktioner, som virker på tværs af services), men i en microservicearkitektur bør man overveje, om man ikke kan designe sig udenom transaktioner og leve med eventual consistency, jf. Martin Fowler [17]. Eventual consistency er kort og populært sagt en egenskab ved systemer, som har et teknisk 4 A transaction, in the context of a database, is a logical unit that is independently executed for data retrieval or updates. In relational databases, database transactions must be atomic, consistent, isolated and durable--summarized as the ACID acronym.

15 Side design, der ikke altid kan garantere, at alle replika af data kan findes på alle systemets servere, men i den sidste ende ( eventually ), så vil data nå frem til alle servere. Sikkerhedsinfrastruktur: Projektets generelle tanker omkring sikkerhedsinfrastruktur i en microserviceverden er dokumenteret i Appendix A. Ud over pointerne i Appendix A bør der i vores sammenhæng lægges vægt på, at arkitekturen skal kunne integrere med autentifikationsmekanismer, som er implementeret separat fra microservicedelen og separat fra den del af infrastrukturen, som specifikt understøtter telemedicin. Dette skal sikre, at man eksempelvis vil kunne bruge en eksisterende Active Directory eller lignede løsning i forbindelse med autentifikation af sundhedsprofessionelle og en NemID-baseret løsning til autentifikation af borgere. Dette skal så suppleres med en service, der, i vores microservicedel af arkitekturen, sørger for at skabe og vedligeholde relationen mellem den eksterne autentifikationsmekanismes id og et rolle/identitets begreb, som giver mening internt i microservicedelen. Sidstnævnte kan f.eks. for borgerens vedkommende være relationen til et id på en FHIR Patient ressource. Desuden kan det ift. Appendix A bemærkes, at anvendelsen af microservices ikke nødvendigvis altid betyder, at hver eneste service skal checke samtykke for alle kald og afledte kald. I vores tilfælde vil det f.eks. være en sikkerhedsmæssigt gangbar metode at checke samtykke først ved perimeteren til vores microserviceverden dvs. ved BFF erne og derefter muligvis også ved de specifikke services som lagrer/cacher personfølsomme data (hvis data er indhentet med forskelligt formål). Det sidstnævnte gælder langt fra alle microservices. Det giver således mening at vurdere sikkerhedsrisici ved de enkelte services / dele af infrastrukturen fremfor blindt at pålægge alle serviceudviklere samme sikkerhedspolitikker. Letvægts containerteknologi: Uden en virtualiseringsteknologi bliver det hurtigt en tung og fejlbehæftet affære, at få en mængde af microservices op at køre og til at spille sammen. I den forbindelse er anvendelsen af letvægts containerteknologi et vigtigt værktøj til procesmæssig isolering og nem provisionering og deployment af microservices. På grund af hastigheden i arbejdsprocesserne med letvægtscontainere bør disse i forbindelse med microservices foretrækkes fremfor den mere traditionelle virtualiseringsteknologi i form af fulde virtuelle maskiner. I forbindelse med letvægts containerteknologi er det svært at ignorere Docker [18], som har en uforlignelig markedspenetration. Hvis man overvejer andre containerløsninger vurderer vi, at man bør se efter teknologier, der ligesom Docker, er baseret på LXC Linux Containers [19] teknologi. Når det kommer til deployment og orkestrering af containere bør man se på teknologier som Kubernetes eller Docker SWARM, men den konkrete løsning afhænger her både af valgt containerteknologi og af valgt deploymentmiljø (bruges Amazon Web Services vil man typisk bruge Amazon Container Service til orkestrering). Adaptor services: I overensstemmelse med OpenTele3 principperne jf. [3] anbefaler vi at integration med eksterne systemer indkapsles i adaptor eller facade microservices. Disse services bør overfor microserviceverdenen udstille en enkel og, hvis muligt, standardiseret snitflade, mens de i retning af de eksterne systemer implementerer interaktion med proprietære og/eller legacy protokoller og snitflader. Microservice proxy / lokal API gateway: Ofte er der dele af det arbejde, som microservices udfører i forbindelse med indgående trafik, som er ens for alle. Det kan f.eks. være sikkerhedsmæssigt eller at logge alle indgående REST-kald e.l. Her kan en lokal API gateway eller microservice proxy, der billedligt talt er foranstillet hver service, være nyttig. Proxy en lægger sig altså som et kommunikationslag foran alle microservices. 5 Prototyper Projektet har udviklet prototyper for udvalgte microservices og udvalgte dele af serviceplatform, samt prototyper af rudimentære klient apps for borger og sundhedsprofessionel.

16 Side Figur 5 illustrerer i overblik de implementerede microservices og platformselementer. Elementer illustreret med gråt er elementer, som er udviklet til et vist proof of concept niveau, men som ikke i øjeblikket indgår aktivt i den sammenhængende prototype på microserviceinfrastruktur. Figur 5: Prototypeimplementationer - microservices og serviceplatform 5.1 Implementeret serviceplatform Ikke alle dele af målarkitekturens serviceplatform er implementeret i prototypen. I proof of concept projektet har der været fokuseret på at de dele, der blev implementeret og konfigureret skulle give mere end blot erfaring med at installere et stykke standardteknologi, som virker ud af boksen. Samtidigt har der været større fokus på udviklingsdelen af processen end på idriftsættelse Dele af serviceplatform, som er inkluderede i den nuværende prototype: Asynchronous messaging system: Her er der i prototypen valgt Apache Kafka [20]. Kafka er valgt fordi

17 Side Den er stærk i sammenhænge, som vores, hvor man gerne vil kunne læse data forskellige steder med forskellige formål. Den motiverer med sin publish-subscribe baserede arkitektur til løs kobling mellem services. Den er særdeles velegnet til at tage imod meget store datamængder. Derudover benyttes Kafka f.eks. af Alexandra i andre mere IoT-orienterede scenarier, hvor apparater sender kontinuerte strømme af data ind. Scenarier som også vil komme på tale, når de traditionelle telesundhedsscenarier udvides med bredere velfærdsteknologiske scenarier, hvor mange forskellige apparater hos borgeren potentielt indsender data. Et alternativ til Kafka kunne være RabbitMQ [21], som prinicipielt kan det samme, men dog ikke vurderes til at skalere så godt som Kafka. Til rene telemedicinske formål ville RabbitMQ sandsynligvis kunne skalere tilstrækkeligt, men hvis velfærds-/iot-scenarier inddrages bør man overveje om Kafka er løsningen. RabbitMQ understøtter modsat Kafka RPC (Remote Procedure Call 5 ), men hvis dette udnyttes skal man være opmærksom på, at man giver køb på den løse kobling. Figur 6 Microservice med Kafka consumer og producer Figur 6 illustrerer dele af en typisk af microservice i vores infrastruktur, hvor de to nederste kasser, Topic A og Topic B, er emner i Kafkas beskedsystem, og servicen (hele den øverste fede kasse) indeholder både en Kafka consumer og en Kafka producer. Consumeren læser beskeder fra Topic A efterhånden 5 RPC er en form for kommunikation, hvor en klient service kalder funktionalitet ( procedure ) på en anden server service direkte, og hvor server servicen giver svar tilbage til klient servicen med resultatet af kaldet.

18 Side som de publiceres, og efter noget behandling i Business logic laget producerer servicen så noget output på Topic B. Bemærk i øvrigt mht. anvendelsen af Kafka i prototypen, at der udestår et mere detaljeret Topic-design. For nu er der benyttet et meget simpelt design, som ikke skalerer til mere avanceret brug af notifikationer mv. Backend-for-frontends: Der er implementeret én BFF Clinician API i Figur 5 - som servicerer de sundhedsprofessionelle apps. For at illustrere princippet omkring en BFF implementerer den kun helt basale ting, som at kunne hente en liste af patienter og at kunne hente indkomne målinger på en bestemt patient begge dele stilles til rådighed i FHIR baserede snitflader. Derudover opfattes kafka2websocket servicen (jf. Figur 5) også som en del af BFF-funktionaliteten. Denne stiller en service til rådighed, hvor Kafka events videresendes over en web socket kanal. Dette sætter sundhedsprofessionelle apps i stand til at modtage og filtrere på bestemte begivenheder i systemet, såsom en notifikation om at der er kommet nye målinger ind. Bemærk at denne funktionalitet i et produktionssystem bør implementeres via en mere avanceret service, som understøtter forskellige typer af abonnementer på notifikationer om begivenheder, som giver mening på et forretningsplan. Notification servicen udgør en start på dette arbejde, men blev i prototypen parkeret til fordel for en mere simpel, demonstrerbar funktionalitet. Input services: Følgende input services er implementeret: QuestionnaireResponse Input Observation Input PCD input QuestionnaireResponse Input servicen implementerer modtagelse af spørgeskemaer i HL7 QRD og i HL7 FHIR QuestionnaireResponse formater. For begges vedkommende sender servicen disse formater videre ind i microserviceverden ved at publicere dem til Kafka. Observation Input servicen implementerer modtagelse af målinger via REST i FHIR Observation ressource format. Servicen sender FHIR Observations videre ind i microserviceverden ved at publicere dem til Kafka. Lige nu håndteres udelukkende modtagelse af Observation ressourcer, men i den endelige version bør også information om måleapparat i form af referencer til FHIR Device / DeviceComponent ressourcer håndteres. PCD input servicen modtager målinger over SOAP i PCD format. PCD-indholdet sendes herefter videre ud på Kafka. Figur 7 illustrerer opbygningen af en typisk input service, hvor der ud mod omverdenen udstilles en FHIR snitflade via HAPI FHIR implementationen (se nedenfor) og efter behandling i en forretningslogikdel (typisk er den meget tynd eller måske helt fraværende i input services) sendes det modtagne indhold videre til Kafka via en Kafka producer.

19 Side Figur 7: Typisk opbygning af en input service Logging / monitoring: Figur 8 illustrerer prototypens implementering af detaljeret logging og monitorering af de enkelte microservices. Hver service kører i sin egen Docker container, og den enkelte service producerer output i JSON format (JavaScript Object Notation). Via et simpelt plugin/driver opsamler Fluentd [22] data fra de enkelte dockerinstanser og sender videre til en aggregator, som så igen videresender til elasticsearch [23], som indekserer og gemmer logs. I den sidste ende benyttes Kibana [24] til søgning og avanceret visualisering af logoutput. Figur 8: Prototypens logaggregring, indeksering og visualisering

20 Side Udover ovennævnte har projektet også benyttet systemet Shipyard [25] til overordnet overvågning og management af Dockerinstanser. Figur 9: Screenshot fra Shipyard med nogle af projektets Dockerinstanser I produktion, og ved anvendelse af Docker Swarm, ville vi sandsynligvis erstatte Shipyard med et værktøj som Portainer [26], eller Kubernetes Web UI ved anvendelse af Kubernetes. For alternative monitorering- og loggingteknologier se evt. RESTful kommunikation, HL7 FHIR: I projektets prototypemicroservices anvendes open source referenceimplementationen af FHIR kaldet HAPI FHIR. HAPI FHIR har både biblioteker til at implementere FHIR klienter og servere og sidstnævnte kan konfigureres til om de skal tale med et databaselag eller ej. HAPI FHIR har den fordel, at det er open source og fungerer som referenceimplementation for den officielle HL7 FHIR standard. HAPI FHIR har således implementationer af alle hidtidige versioner af FHIR (DSTU1, DSTU2 og STU3), og man kan nemt sætte det op til at køre den ene eller anden version. Under projektet har vi dog oplevet den ulempe ved HAPI FHIR, at det på server-siden synes mest at være orienteret mod at implementere én stor server, som servicerer alle FHIR ressourcer. Man kan dog konfigurere sig udenom dette, og det synes heller ikke på sigt en uoverstigelig hindring for brugen af HAPI FHIR. Særligt set i forhold til, hvis man selv skal implementere FHIR standarden fra bunden.

21 Side Figur 10: Microservice med FHIR API, database og Kafka producer/consumer Letvægts containerteknologi: Prototyperne anvender Docker som deploymentplatform. Dvs. hver microservice er indkapslet på sin egen Dockerinstans. Derudover kører en mængde af platformens værktøjer, såsom Shipyard, fluentd og Kafka på Docker containere. Adaptor services: Der er ikke som sådan implementeret adaptor services i prototypen, men Patient servicen (jf. Figur 5) har stub-kode, som markerer at her skal der indhentes CPR og stamdata fra eksterne kilder. Desuden kan CDA2XDS servicen karakter af adoptor service, idet den indkapsler skrivning til en ekstern XDS-database. Microservice proxy / lokal API gateway: Separat fra prototypen, som indeholder serviceplatform og microservices er der lavet en mindre prototype, som demonstrerer nogle af de basale sikkerhedsprincipper, som er forklaret i Appendix A. Denne prototype benytter Kong, som microservice proxy / lokal API Dele af serviceplatform, som er udeladt fra den nuværende prototype: API Gateway: API gateways, som f.eks. NGINX, er standardteknologi, som anvendes i web installationer (microservice eller ej) verden over. Det blev ikke vurderet at installering af en sådan ville bidrage væsentligt til projekts resultater. Container orkestreringsteknologi: Docker Swarm [27] og Kubernetes [28] blev overvejet, men som tidligere nævnt afhænger valget af orkestreringsteknologi en del af deploymentmiljøet. Derudover er orkestreringsteknologien ikke noget som indbygges i infrastrukturen, men kan

22 Side applicereres efterfølgende på eksisterende containere. Af disse årsager og for at prioritere funktionalitet i microservices valgte vi stedet at etablere én udviklingsserver, hvorpå alle dockerinstanser med microservices blev manuelt deployeret. Discovery: DNS-baseret discovery er standardteknologi, og det blev ikke vurderet at opsætning af dette ville bidrage væsentlig til projekts resultater. Hvad angår konkrete teknologier bør Consul [29] nævnes som en af de teknologier, der kommer med en indbygget DNS server. Teknologier som Consul og SkyDNS [30] benyttes hyppigt i kombination med Registrator, som står for automatisk registrering og deregistrering af Docker containere i trit med, at de startes/stoppes. Andre alternativer er Dockers egen Docker Swarm eller Kubernetes, som begge, udover deres orkestreringsmæssige funktionaliteter, understøtter service discovery. 5.2 Implementerede microservices Figur 5 illustrerer i overblik de implementerede microservices. Microservices, der lever på kanten af microserviceinfrastrukturen i form af BFF er og input services, er gennemgået ovenfor i afsnittet om Implementeret serviceplatform. Derudover er følgende microservices implementeret: FHIR ressource services: o QuestionnaireResponse service o Questionnaire service o Patient service o Observation service Alle disse services implementerer via HAPI FHIR en FHIR RESTful API for den ressources, som de understøtter. Derudover understøtter hver service persistering af ressourcer i egen database. Endelig har disse services typisk en Kafka consumer, som lytter på indkommende ressourcer af den understøttede type, og som i forbindelse med sådanne events gemmer ressourcen i egen database, hvorefter den notificerer omgivelserne (via Kafka) om dette. Figur 10 illustrerer bestanddelene af en sådan service. Converter services: o FHIRObservation2PHMR service o QRD2FHIR service o QFDD2FHIR service o CDA2XDS service o PCD2FHIR service FHIRObservation2PHMR tager FHIR Observations publiceret på Kafka, konverterer dem til PHMR og sender PHMR ud på Kafka. Konverteringen i denne service er ikke komplet, men komplet nok til at illustrere princippet i en konvertering fra det ene til det andet format. QRD2FHIR og QFDD2FHIR tager de to spørgeskemaformater i CDA, konverterer til deres genparter i FHIR ressourceverdenen og publicerer sidstnævnte på Kafka. Dog skal det bemærkes, at disse to services kun er skelet-implementationer og ikke indeholder nogen egentlig konverteringsfunktionalitet. CDA2XDS tager CDA dokumenter, som f.eks. PHMR, fra Kafka og sender dem videre til en XDS database. Denne service benytter det nye 4S CDA builder bibliotek udviklet af Systematic, og den konkrete prototype har anvendt en konfiguration af OpenXDS som XDS backend. PCD2FHIR tager PCD fra Kafka og omsætter det til et FHIR bundle med FHIR Observation, FHIR Device og FHIR Patient ressourcer. Herefter sender servicen indholdet til en en testserver hos HAPI FHIR projektet. Dvs. denne service kommunikerer ikke videre til resten af prototypeinfrastrukturen via Kafka.

23 Side Notification service: Se ovenfor i afsnittet Implementeret serviceplatform under Backend-forfrontends. De ovenstående microservices er udvalgt med fokus på at kunne illustrere, hvordan man i en microservicesinfrastruktur understøtter et flow af målinger og spørgeskemaer, fra borgerklient, over input services og convertere, til FHIR ressource services og XDS backend. Samt illustrering af, hvordan disse data kan benyttes af apps vendt mod sundhedsprofessionelle. Denne prioritering er i overensstemmelse med den oprindelige opgaveformulering og er undervejs afstemt med Region Midtjyllands deltagere i projektet (projektleder og arkitekt). 5.3 Ikke implementerede microservices Nedenstående services er identificeret som kandidater til et minimumssetup for et basalt telemedicinsk setup, som det der benyttes på Afdeling Y på AUH. Der er oprindeligt taget udgangspunkt i de use cases som er listet i Appendix B og sidenhen er der justeret ift. feedback fra såvel klinikere som arkitekter fra Region Midtjylland. Der er søgt taget hensyn til, at der, som med den nuværende OpenTele, skal kunne understøttes et langt bredere brugssetup end et som er rettet mod gravide med komplikationer. Det bør bemærkes, at nedenstående er et første bud på services, og det bør justeres i en agil og iterativ udviklingsproces af de endelige services. Healthcare User service: Indeholder information om de sundhedsprofessionelle brugere af systemet. Dette er ikke tænkt som en egentlig brugerdatabase, men som en skyggerepræsentation af de brugere, som benytter de telemedicinske system. Servicen repræsenterer de sundhedsprofessionelle som FHIR ressourcer, men kommunikerer med eksterne systemer for at indhente information om brugeren, dennes roller m.v. User2id service: Service som afbilder fra ekstern identifikationstoken til identifikation af bruger i microserviceinfrastruktur. Healthcare Organisation service: Understøtter de organisationsinformationer, som er relevante for det telemedicinske system. Det kan dreje sig om sygehus/kommune/afdelingsinformation. Disse informationer er ikke ejet af microserviceinfrastrukturen, men indhentes fra eksterne systemer og benytter f.eks. typisk SOR registeret til identifikation af organisatoriske enheder. Servicen bør dog også kunne inkorporere organisatoriske inddelinger, som ikke findes i eksterne systemer. F.eks. teams i en afdeling, som har ansvar for bestemte grupper af patienter. Det er uklart om data af sidstnævnte type er registreret og til rådighed i eksisterende digitale systemer. Citizen API service: En backend-for-frontend service til de borgerrettede apps. Monitoring Plan service: Håndtering af monitoreringsplaner for patienter. Monitoreringsplanen knytter patienten til specifikke spørgeskemaer/målinger og tidspunkter/frekvenser for måling. Note Adaptor service: Notetagningsservice som integrerer med EPJ/EOJ-system, så noter taget i det telemedicinske system ikke skal dobbeltregistreret i journalsystem. Kan f.eks. i fremtiden foregår ved at noter gemmes i CDA-dokumenter og deles via XDS-infrastruktur. Notification service: Notifikations og abonnementsservice, som understøtter abonnementer og notifikation på begivenheder på forretningsniveau. F.eks. begivenheder som der er kommet nye målinger på patient X. Patient Master Data Adaptor service: Adaptor til kommunikation med eksterne systemer om indhentning af stamdata på patienten. Hentes fra CPR service og evt. andre systemer som stiller yderligere stamdata til rådighed. Patient Profile service: Håndterer sygdoms-/behandlingsprofil ift. telemedicinsk behandling. Fungerer som en slags template, hvor spørgeskemaer, standard grænseværdier, målingstyper