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.

...

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

Adresseringsforretningslogik

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

...

• 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å figuren ovenfor (SOR-hierarki) vil det komplette hierarki være alle SOR-noderne (xx1, xx2, xx3, xx4, xx5, xx6 og xx7). 

...

1. EER (MedCom service) 

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. 

...

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 (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. 

...

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

Sikkerhedslogik 

Figur 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