Sundhedsadresseringsservicen (EAS) - Arkitektur og design

Referencer

Baggrund

I 2020 udarbejdede Sundhedsdatastyrelsen Målbillede for meddelelseskommunikation på sundhedsområdet [EHMI-ARK], som dannede grundlag for en efterfølgende pilotafprøvning.

Den fremtidige meddelelseskommunikation på sundhedsområdet skal baseres på eDelivery – en standardiseret, domæneneutral infrastruktur for effektiv meddelelsesudveksling, udviklet i EU-regi. Denne infrastruktur anvendes allerede på andre områder end sundhed i både EU og Danmark.

I Danmark omtales eDelivery-infrastrukturen til sundhedsområdet som EHMI – Enhanced Healthcare Messaging Infrastructure. Formålet med afprøvningen af EHMI er at realisere visionen i Målbilledet for meddelelseskommunikation på sundhedsområdet, som udstikker rammer og retning for EHMI-produktionspiloten. Visionen er, at MedCom-kommunikationen skal bevæge sig fra den nuværende EDIFACT-/VANS-infrastruktur over til EHMI-infrastrukturen.

EAS – EHMI Addressing Service – er en fælles forretningsadresseringsservice på sundhedsområdet, som er etableret på den nationale serviceplatform (NSP) som led i EHMI-produktionspiloten. EAS anvendes af fagsystemer til at fremsøge adressen på en modtager af en meddelelse – eksempelvis når modtageren ikke entydigt kan identificeres ud fra en given klinisk kontekst. EAS videresender forespørgsler til relevante autoritative kilder og returnerer det nødvendige svar til fagsystemet. På den måde afkobler EAS fagsystemerne fra de bagvedliggende kilder, så logikken for at fremsøge modtagere i forskellige situationer nu centraliseres og vedligeholdes ét sted – i EAS.

I den nuværende implementering understøtter EAS følgende søgefunktioner:

• Fremsøg en patients (sikringsgruppe 1) praktiserende læge og dennes modtageradresse
• Fremsøg modtageradresse via ydernummer
• Fremsøg modtageradresse via SOR id
• Fremsøg en liste af mulige modtagere (og deres modtageradresser) via postnummer

Disse funktioner dækker behovene i produktionspiloten, og EAS udbygges løbende med yderligere fremsøgningsscenarier.

Applikationsarkitektur

Et samlet overblik over EAS-applikationsarkitekturen ses i figuren nedenfor.

Figur 1: Applikationsarkitektur - overblik

EAS realiseres via en HAPI FHIR Plain Server (FHIR facade server). Facade-serveren er valgt, da EAS ikke selv opbevarer data, men i stedet henter og behandler data fra forskellige autoritative registre on-demand.

FHIR Ressourcer udtrykkes, hvor det er muligt, via den kanoniske informationsmodel i HL7-FHIR R4, og der hvor R4 ikke er tilstrækkelig, anvendes HL7-FHIR R5/R6 Extensions som inspiration.

EAS-operationerne er defineret via HL7-FHIR R4 CapabilityStatement.

Adresseringsforretningslogik

EAS realiserer følgende fire use cases (jf. EAS FHIR Implementation Guide):

• UC1: Get General Practitioner for a Patient by PatientId (Health Insurance Group 1)
• UC2: Get General Practitioner for a Patient by GPId (Health Insurance Group 1)
• UC3: Get possible General Practitioner for a Patient by PostalCodes (Health Insurance Group 2)
• UC4: Get ReceivingOrganization by SOR id

De fire use cases benytter de fire FHIR-operationer beskrevet nedenfor. I Figur 2 er de fire operationer fremhævet med mørkeblå farve. 

Figur 2: Forretningslogik

EasCorePatient, EasSorOrganization, EasMessagingOrganization og EasOperationOutcome er FHIR ressourcer og specificeret via [EAS-FHIR-IG]. 

Input parameteren MessageType er en streng, der angiver en meddelelsestype. Ved kald til EAS ønsker serviceaftageren at afgrænse output til EndPoints, som understøtter en af de meddelelsestyper, der fremgår af MessageType input-listen.  I pilotprojektet fokuseres alene på endpoints, der understøtter meddelelsestypen ”kommunalt prøvesvar” (homecareobservation). 

Sekvensdiagrammer for både solskinsscenarier og fejlscenarier for hver af de fire FHIR-operationer fremgår af [EAS-FHIR-IG]. Nedenfor gives et eksempel på solskinsscenariet for use case 1 og 3. Use case 2 og 4 minder om use case 1, dog med den forskel at de ikke laver opslag i PersonInformation og Sikrede. 

Figur 3: Sekvensdiagram for use case 1 (Get General Practitioner for a Patient by PatientId)

Af sekvensdiagrammet Figur 3 fremgår der, at operationen getReceivingOrganizationByPatientId bygger på opslag i følgende autoritative registre: 

1. Personinformation: CPR-data, hvor det verificeres, om borgeren eksisterer. 
2. Sikrede: Indeholder sygesikringsinformationer; herfra hentes ydernummeret på den praktiserende læge, som borgeren er tilknyttet (såfremt borgeren er i sygesikringsgruppe 1). 
3. SOR: Sundhedsvæsenets organisationsregister, hvor ydernumre mappes til SOR-id’er og hvor organisations-data kan aflæses. I SOR-registeret kan et ydernummer være tilknyttet flere SOR-noder indenfor samme organisation. Alle disse SOR-noder skal udtrækkes, samt de SOR-noder, der ligger hierarkisk under og over de SOR-noder, der har ydernummeret tilknyttet*. 
4. EER: [EER-FHIR-IG] – EHMI Endpoint Register (EER) er et register etableret af MedCom i regi af EHMI-pilotprojektet, som indeholder oplysninger om en SOR-enheds endpoints i form af GLN-numre. EER kaldes med alle returnerede SOR-noder fra SOR-opslaget. 

 * En organisation (eksempelvis en lægepraksis) er i SOR-registeret repræsenteret som et hierarki af SOR-noder (jf. eksemplet på figuren nedenfor). Som det fremgår af figuren, så er noderne med SOR-id xx6 og xx7 tilknyttet ydernummer=c. I dette tilfælde skal forældrene også udtrækkes – dvs. det bliver i alt noderne xx6, xx7, xx4 og xx1. Hvis det derimod var ydernummer=b, som skal fremsøges, så bliver det med forældre og børn noderne xx5, xx3 og xx1. 

Figur 4: Eksempel på et SOR-hierarki for en almin praksis

Figur 5: Sekvensdiagram for use case 3 (Get possible General Practitioner for a Patient by PostalCodes)

Af sekvensdiagrammet ovenfor fremgår der, at use case 3 (Get possible General Practitioner for a Patient by PostalCodes) benytter to EAS-opslag: 

• Først benyttes EAS-operationen getListOfGpByPostalCode til at hente en liste med alle lægepraksisser indenfor de medsendte postnumre. EAS anvender SOR-registeret til opslag efter lægepraksis ud fra postnummer. EAS returnerer det komplette hierarki af SOR-noder*, for hver lægepraksis indenfor de efterspurgte postnumre. De enkelte SOR-noder og deres hierarkiske relationer mappes til en liste af EasSorOrganisation FHIR ressourcer før output returneres fra EAS. 

• Anvenderen udvælger de SOR-noder, som repræsenter den eller de lægepraksisser, som meddelelsen skal sendes til.  
• Derefter benyttes EAS-operationen getReceivingOrganizationBySORId til at hente EndPointAdresserne (EasMessagingOrganisation) for de udvalgte SOR-noder. EAS anvender EER-registeret til at hente EndPointAdresserne (disse returneres som FHIR Endpoint-ressourcer side om side med EASMessagingOrganizations). 

*I eksemplet på figuren ovenfor (SOR-hierarki) vil det komplette hierarki være alle SOR-noderne (xx1, xx2, xx3, xx4, xx5, xx6 og xx7). 

 Diagrammet på Figur 2 illustrer de fysiske eksterne (i forhold til EAS) registre, der modsvarer de logiske registre på sekvensdiagrammet;  

1. PersonInformation (NSP service) 

1. SikredeInformation (NSP service) 

1. SOR opslagsservice (SORES) (NSP Service) 

1. EER (MedCom service) 

PersonInformation er en REST service på NSP (jf. https://www.nspop.dk/display/public/web/SDM+-+Guide+til+anvendere#SDMGuidetilanvendere-5.6CPRregistret:personinformation). Servicen skal anvendes til at afgøre om cpr-nummeret eksisterer. 

SikredeInformation er en REST service på NSP. SikredeInformation har en enkel operation, der tager en borgers CPR nummer som input og returnerer ydernummeret på borgerens egen læge. 

’SikredeInformation’ bygger på database-opslag i NSP’ens stamdatamodul (som indeholder en kopi af data fra Sygesikringssystemet Luna – jf. https://www.nspop.dk/display/public/web/Sikrede).  

SORES er en REST-service på NSP til opslag i SOR-registeret, se https://www.nspop.dk/display/public/web/SORES+-+Anvenderguide. SORES eksponerer en operation, der tager en liste af postnumre og en SOR enhedstype som input og returnerer de tilhørende SOR entiteter. I use case 3 er det SOR enhedstype ”Almen lægepraksis” der efterspørges.  

EER udstiller en FHIR-operation getReceivingOrganizationBySORID, der tager en liste med SOR-id’er og en liste af MessageType som input. EER undersøger, om der er tilknyttet eDelivery endpoints til de SOR-id’er, der fremgår af input. De udvalgte endpoints skal samtidig understøtte en af de meddelelsestyper, som fremgår af listen af MessageType’s. Output fra EER er EasMessagingOrganization samt deres Endpoint-adresser (GLN-numre), som lever op til ovenstående kriterier. Output er sidestillede EerMessagingOrganization og deres refererede Endpoint-ressourcer. 

Såvel PersonInformation, SikredeInformation og SORES er NSP-interne REST-services og kan kaldes uden sikkerhedsbillet. Derimod er EER en ekstern service, som kræver, at klienten (dvs. EAS) først får udstedt et OAuth access token ved Sundhedsdatastyrelsens (Keycloak-baserede) Authorization Server. EAS integrerer til Authorization Serveren og EER som beskrevet i afsnit 7.3 i [EHMI-SIK]. 

EAS operationerne (getReceivingOrganizationByPatientId, getReceivingOrganizationByGPId og getReceivingOrganizationBySORId) returnerer en liste med EasMessagingOrganization og Endpoint FHIR ressourcer til Serviceaftageren. Denne må ikke forveksles med EerMessagingOrganization, da det er to forskellige ressourcer, og output fra henholdsvis EAS- og EER-servicen. 

Inden EasMessagingOrganization returneres, bliver den beriget med information fra SOR og EER opslaget. Det drejer sig hovedsageligt om (jf. [EAS-FHIR-IG]): 

1. SOR-id samt OID for SOR’s autoritative register 

1. SOR-hierarki – information om nodens type (IE, SI og OE). 

1. SOR-enhedstype – eksempelvis ”hjemmeplejeenhed”, ”almen lægepraksis” og ”klinisk enhed” 

1. Navn – organisationsnavn fra SOR. 

1. Address – organisationsadresse fra SOR. 

1. PartOf – reference til forældre SOR-noden. 

1. Endpoint – reference til FHIR ressourcen som indeholder EndPoint’et. 

EAS operationen (getReceivingOrganizationByPostalCode) returnerer en liste af EasSorOrganization FHIR ressourcer til Serviceaftageren. 

Inden EasSorOrganization returneres, bliver den beriget med information fra SOR-opslaget. Det drejer sig hovedsageligt om (jf. [EAS-FHIR-IG]): 

1. SOR-id samt OID for SOR’s autoritative register. 

1. Ydernummer samt OID for Ydres autoritative register. 

1. SOR-enhedstype – eksempelvis ”hjemmeplejeenhed”, ”almen lægepraksis” og ”klinisk enhed”. 

1. Navn – organisationsnavn fra SOR. 

1. Address – organisationsadresse. 

1. PartOf – reference til forældre SOR-noden 

Sikkerhedslogik 

Figur 6: Sikkerhedslogik

EAS servicen realiserer OAuth sikkerhedsmodellen som er beskrevet i [EHMI-SIK] og som er illustreret i ovenstående figur. Aftagere af EAS servicen (eksempelvis i et klinisk fagsystem) skal kalde EAS med et access token som de har fået udstedt af Sundhedsdatastyrelsens Authorization Server (Keycloak). Sikkerhedsprotokollen er baseret på 2-vejs TLS, hvor klientens access token er kryptografisk bundet til klientens TLS-klientcertifikatet (se [EHMI-SIK] for detaljer). I EAS deployment setup’et termineres TLS i en foranstillet netværkskomponent (NGINX), som på standard vis viderefører klientens TLS-klientcertifikat til EAS i en HTTP header. 

EAS validerer de indkommende access token som illustreret i HAPI FHIR Security Interceptor i Figur 6. Konkret validerer EAS at: 

1. Signaturen på tokenet er valid og at tokenet er signeret af en trusted part (dvs. SDS’ Keycloak Authorization Server) 
2. Klientens TLS certifikat (som netværks/TLS-proxy’en viderefører til EAS i en HTTP header) matcher certifikatoplysningen i tokenets ’cnf’ claim.  
3. Tokenet er gyldig i tid, dvs. hverken er udløbet eller endnu ikke gyldig 
4. Tokenets level of assurance er på minimum NIST niveau 3 
5. Tokenets scope claim indeholder de fornødne scopes, som er ’EAS’ og ’system/Organization.rs’ 
6. Tokenets audience (’aud’ claimet) er sat til ’EAS’ 

Der bemærkes, at NSP AccessHandler varetager parsningen af JTP-H access tokenet, samt står for validering 1. og 3. i ovenstående liste. 

Access- og audit-logning håndteres via NSP AccessHandler. 

Sikkerhedsmodel for Security API (NSP Accesshandler Ticket)

Følgende afsnit beskriver sikkerhedsmodellen for den Ticket EAS validerer (De grønne processer i billedet ovenfor). Jf. Security API - Guide til anvendere

Ifølge EHMI-SIK er det kun systembrugere der kan kalde EAS. 
Et eksempel på en udstedt JTP-H JWT Token for en systembruger mod EAS kan ses i følgende skærmbillede:

33257872

Sundhedsdatastyrelsen

89c9afe9-9466-4fb7-a1d2-7776ce57d93c