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):

...

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. 

Figur 2: Forretningslogik

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

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

Image ModifiedFigur 5: Sekvensdiagram for use case 3 (Get possiblepossible 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å 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 

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