Page History

Table of Contents

Referencer

Baggrund

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

...

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.

Image ModifiedFigur 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.

...

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

Adresseringsforretningslogik

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

...

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

Image ModifiedFigur 2: Forretningslogik

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

...

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. 

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

Af sekvensdiagrammetFigur 3 fremgår der, at operationen getReceivingOrganizationByPatientIdbygger 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 etableretafMedCom 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åraf 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. 

Nedenstående figur viser et eksempel Image AddedFigur 4: Eksempel på et SOR-hierarki for en almin praksis:Image Removed

Image ModifiedFigur 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 (Getpossible General Practitioner for a Patient by PostalCodes) benytter to EAS-opslag: 

...

• Anvenderen udvælger de SOR-noder, som repræsenterdeneller delægepraksisser, som meddelelsen skal sendes til.  
• Derefterbenyttes EAS-operationen getReceivingOrganizationBySORId til at hente EndPointAdresserne (EasMessagingOrganisation)for de udvalgteSOR-noder.EAS anvender EER-registeret til at hente EndPointAdresserne (disse returneres som FHIR Endpoint-ressourcer side om side med EASMessagingOrganizations). 

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

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

1. PersonInformation (eksisterende NSP service) 

1. SikredeInformation (kommende NSP service) 

1. SOR opslagsservice (SORES) (eksisterende NSP Service, som bliver udvidet med opslag på postnummer) 

1. EER (kommende MedCom service – eksisterer dog allerede nu i en foreløbig testudgave uden sikkerhedsfunktionalitet) 

 PersonInformation er en eksisterende REST  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. 

...

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 eDeliveryendpoints 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 de EasMessagingOrganization samt deres Endpoint-adresser (GLN-numre), som lever op til ovenstående kriterier. Output pakkes ind i en liste af EerMessagingOrganization FHIRer 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 OAuthaccesstoken ved Sundhedsdatastyrelsens kommende Sundhedsdatastyrelsens (Keycloak-baserede) Authorization Server. EAS integrerer til Authorization Serveren og EER som beskrevet i afsnit 7.3 i [EHMI-SIK]. 

EASoperationerne (getReceivingOrganizationByPatientId, getReceivingOrganizationByGPIdog getReceivingOrganizationBySORId)returnereren 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 EasMessagingOrganizationreturneres, skal bliver den berigesberiget medinformation fra SOR og EER opslaget. Det drejer sig hovedsageligt om (jf. [EAS-FHIR-IG]): 

...

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

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

...

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

Sikkerhedslogik 

Image AddedFigur 6: Sikkerhedslogik

EAS servicen realisererOAuthsikkerhedsmodellen 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 accesstoken som de har fået udstedt af Sundhedsdatastyrelsens Authorization Server (Keycloak). Sikkerhedsprotokollen er baseret på 2-vejs TLS, hvor klientens accesstoken er kryptografisk bundet til klientensTLS-klientcertifikatet (se [EHMI-SIK] for detaljer). I EAS deploymentsetup’ettermineres 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 indkommendeaccesstokensom 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’ KeycloakAuthorization 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. Tokenetsscopeclaimindeholder de fornødnescopes, som er ’EAS’ og ’system/Organization.rs’ 
6. Tokenets audience (’aud’ claimet) er sat til ’EAS’ 

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

Access- og audit-logning håndteres viaNSP 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:
Image Added

33257872

Sundhedsdatastyrelsen

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