RIVO-Noord Zorgviewer MVP2 Implementation Guide - Local Development build (v0.24.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Design

Deze pagina beschrijft de interacties tussen de bouwblokken voor het opstarten van de zorgviewer en het ontsluiten van de bronsystemen. Dit is de startpagina voor het bouwteam.

Actors

Scope MVP2 is Epic (UMCG, MCL), Chipsoft (Antonius Sneek, Tjongerschans, Wilhelmina, Martini, Nij Smellinge), en Topicus VIPlive (bij Dokter Drenthe aangesloten partijen).

IHE System Actors

Note: Relatie tussen bouwblokken en definities uit IHE Actors, b.v. de IHE Mobile Profiles IHE_PCC_Suppl_QEDm

• Authorization Client, Result Aggregator - Zorgviewer bouwblok
• Authorization Server - Authenticatie bouwblok
• Provider Information Directory - Zorgverlener Registry bouwblok
• Clinical Data Consumer “Raadpleger” - Zorgviewer bouwblok
• Clinical Data Source “Beschikbaar steller” - Ontsluiten Bronsysteem bouwblok

Sequence Diagrams

Opstarten zorgviewer: Epic

Eerst opstarten Zorgviewer Host, inloggen en patiënt selectie en vervolgens opstarten van de Zorgviewer.

Van toepassing zijnde standaarden en documentatie:

• SMART-on-FHIR 1.0.0
• EHR Launch
• Epic SSO Launching

Token Attributes mapping op FHIR tabel:

Opstarten zorgviewer: Chipsoft HiX/Zorgplatform

Eerst opstarten Zorgviewer Host, inloggen en patiënt selectie en vervolgens opstarten van de Zorgviewer.

Van toepassing zijnde standaarden en documentatie:

• XACML SAML Profile Version 2.0
• Chipsoft Web Browser Single-Sign-On

SAML Attributes Assertions mapping op FHIR tabel:

Opstarten zorgviewer: VIPlive

Van toepassing zijnde standaarden en documentatie:

• XACML SAML Profile Version 2.0
• VIPLive Interconnect - IdP initiated SAML 2023-11-09 17:01:43 Versie 1.1

SAML Attributes Assertions op FHIR mapping tabel:

Opstarten zorgviewer: Summary Table

In onderstaande tabel hebben we voor alle methoden de verschillende definities van attributen naast elkaar gezet en waar ze te vinden zijn in de verschillende standaarden (SAML, SMART, FHIR).

Bepalen zorgaanbieders

Bepalen zorgaanbieders en endpoints zonder toestemming check

Bepalen zorgaanbieders adhv toestemming

Bepalen zorgaanbieders en endpoints waarvoor toestemming is gegeven door de patiënt.

Met de Zorgviewer MVP2 zullen we een toestemming realiseren volgens de afspraken tussen de RIVO-Noord instellingen. Zie het beleid hier. Deze zal zoveel mogelijk volgens de MITZ specificatie zijn. MITZ zal zich laten inspireren door de Zorgviewer specificaties.

Van toepassing zijnde standaarden en documentatie:

• MITZ Open autorisatie vraag gebruikt als lokalisatie vraag

Bevragen bronsystemen zorgaanbieders

Van toepassing zijnde standaarden en documentatie:

• Bulk Data Access Backend Authentication
• IHE Internet User Authorization (IUA)
• MedMij BgZ 2017 FHIR
• TA Notified Pull / TWIIN TTA FHIR
• Epic * Epic Backend Authentication * Epic Galaxy: Backend System Integrations * Epic FHIR
• Chipsoft * Chipsoft BgZ API * Chipsoft Service Authenticatie

Verkrijgen bronsysteem access token

N.B. Deze IG bouwt op SMART-on-FHIR 1.0.0 ivm FHIR STU3 en Scopes notatie. De bijbehorende backend authenticatie is gespecificeerd in Bulk Data Access FHIR specificaties. SMART-on-FHIR 2.0 brengt eea weer samen, maar upgrade ook de Scopes en de FHIR versie naar R4. Daarom blijven wij voor MVP2 bij de 1.0.0 versie.

N.B. Vanuit de WEGIZ wordt de TA Notified Pull een eis. De richting de toekomst zullen de verschillende bronsystemen hiernaartoe werken. Naast SMART-on-FHIR zal de TA Notified Pull de voorkeur standaard zijn. Tot die tijd moeten we meerdere vormen ondersteunen, zie de Summary Tables.

Hier passen we de request access token flow toe van de Bulk Data Access Backend authenticatie specificaties. Daarnaast ivm NEN 7513 logging requirement moet het bronsysteem de vragende organisatie weten. De vragende organisatie is de organisatie van de geauthenticeerde gebruiker van de Zorgviewer. De IHE IUA standaard beschrijft de attribuut naam die hiervoor gebruikt dient te worden in de authentication JWT die mee gaat naar de access token request. Dit is ook zoals LSP/VZVZ dit doet.

{ "iss": "...",
  "sub": "...",
  "exp": "...",
  (optioneel) "subject_organization": "UMCG",
  "subject_organization_id": "urn:oid:2.16.840.1.113883.2.4.3.8" 
}

Toevoegen Logging HTTP-Headers

Tbv het correleren van de Zorgviewer logging met de logging van een Bronsysteem dient een X-Correlation-Id HTTP Header (per sessie) en een X-Request-Id HTTP Header (per request) te worden toegevoegd aan ieder request aan het Bronsysteem. Deze kan dan door het Bronsysteem gelogd worden, zodat de logging in de Zorgviewer kan worden gekoppeld aan de logging in het Bronsysteem. Epic ondersteunt dit nu d.m.v. key-value pairs in de AORTA-ID HTTP-Header, zie Epic Nova. Voorbeeld voor Epic HTTP-Header van “L. Arts uit Tjongerschans”: AORTA-ID: rid:1b9d6bCd-bBf;cid:yA8UM8fHmhde;usr:larts;rol:62247001;org:2.16.528.1.1007.3.3.15123. N.B. maximale lengte is 128 characters. Voor de Request- en Correlation-ID’s kan de NaN0-1D-12 12 tekens gebruikt.

Voorbeeld van de headers:

GET /fhir/Patient/123456789 HTTP/1.1
...
X-Request-Id: 1b9d6bCd-bBf
X-Correlation-Id: H54f_8b9d6bC

Gebruiker en Organisatie HTTP-Headers

De overige velden worden op twee manieren meegestuurd: individueel als HTTP header en verpakt in een JWT, tevens als HTTP header. De JWT variant is de veiligere optie, omdat de JWT ondertekend is en de waarden daarmee niet aangepast kunnen worden. Het is echter niet perse gegarandeerd dat deze constructie door een bronsysteem ondersteund wordt. Daarom worden ze ook individueel als HTTP header meegestuurd. Voor de naamgeving is gekozen voor een prefix X-ZV- (Zorgviewer) gevolgd door de naam van het veld, die weer gebaseerd zijn op IHE IUA.

Voorbeeld van de headers per veld:

GET /fhir/Patient/123456789 HTTP/1.1
...
X-ZV-Subject-Organization-Id: 2.16.840.1.113883.2.4.3.8
X-ZV-Subject-Id: smart-Practitioner-71614502
X-ZV-Subject-role: 223366009

Voorbeeld van de JWT:

{
 "subject_organization_id": "2.16.840.1.113883.2.4.3.8",
 "subject_id": "smart-Practitioner-71614502",
 "subject_role": "223366009"
}

De JWT wordt ondertekend met de private key waarmee ook de JWT voor het request voor access tokens wordt ondertekend. Hiervoor is al een route ingericht om het publieke deel van de key op te vragen (JWKS). Vervolgens wordt de JWT in een custom HTTP header geplaatst:

GET /fhir/Patient/123456789 HTTP/1.1
...
X-ZV-Context:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWJqZWN0X29yZ2FuaXphdGlvbl9pZCI6I
jIuMTYuODQwLjEuMTEzODgzLjIuNC4zLjgiLCJzdWJqZWN0X2lkIjoic21hcnQtUHJhY3RpdGl
vbmVyLTcxNjE0NTAyIiwic3ViamVjdF9yb2xlIjoiMjIzMzY2MDA5In0.luhI3cpGGpoEIAtDi
8d-Bhf0h2wdEO1f_Jt1xHFe1Xc

Het ontvangende systeem kan nu de JWT decoden, valideren en de velden uitlezen.

Bevragen bronsysteem: Summary Table

In onderstaande tabel hebben we voor alle methoden de verschillende definities van attributen naast elkaar gezet en waar ze te vinden zijn in de verschillende standaarden (Zorgviewer, SAML, SMART-on-FHIR, TA Notified Pull).

Bevragen bronsystemen zorgaanbieders documenten

Van toepassing zijnde standaarden en documentatie:

• MedMij PDF/a
• Chipsoft Documenten API