RIVO-Noord Zorgviewer MVP2 Implementation Guide - Local Development build (v0.17.0). See the Directory of published versions
Design
Deze pagina beschrijft de interacties tussen de systemen.
Dit is de startpagina voor het bouwteam.
Actors
Scope is Epic (UMCG, MCL), Chipsoft (Antonius Sneek, Tjongerschans, Wilhelmina, Martini, Nij Smellinge), en Topicus VIPlive (bij Dokter Drenthe aangesloten partijen).
System Actors
Note: (?) Probeer definities te hergebruiken uit IHE Actors , b.v. de IHE Mobile Profiles IHE_PCC_Suppl_QEDm
Clinical Data Consumer “Raadpleger” - Zorgviewer bouwblok
Clinical Data Source “Beschikbaar steller” - Ontsluiten Bronsysteem bouwblok
Authorization Client, Result Aggregator - Zorgviewer bouwblok
Authorization Server - Authenticatie bouwblok
Provider Information Directory - Zorgverlener Registry bouwblok
Sequence Diagrams
Opstarten zorgviewer
Eerst opstarten Zorgviewer Host, inloggen en patiënt selectie en vervolgens opstarten van de Zorgviewer.
Van toepassing zijnde standaarden en documentatie :
Eigen zorgaanbieder Zorgverlener Zorgviewer Host Authenticatie Zorgviewer 1 start EPD 2 inloggen met lokale identiteit 3 selecteer patient 4 start Zorgviewer 5 start met context dmv SMART-on-FHIR https://app-tst.zorgviewer.nl/application/launch 6 SMART-on-FHIR handshake zorgviewer-host-base from URL token: { "access_token": "...", "id_token": "<JWT>", "patient": "<patient_fhir_id>", ?"practitioner": "<practitioner_fhir_id>" ... } access_token decoded: { "sub": "<practitioner_fhir_id>" ... } 7 opvragen gebruiker gegevens <zorgviewer-host-base>/Practitioner/<practitioner_fhir_id> 8 Practitioner 9 toon gebruiker gegevens 10 opvragen patient gegevens <zorgviewer-host-base>/Patient/<patient_fhir_id> 11 Patient (onder andere BSN voor verdere raadplegingen) 12 toon patient gegevens 13 ga naar de Bepalen zorgaanbieders sequence
Bepalen zorgaanbieders
Bepalen zorgaanbieders en endpoints zonder toestemming check
Zorgverlener Zorgviewer Adressering 1 vervolg opstarten zorgviewer 2 Organizations opvragen <adressering-base>/Organization Alle geregistreerde Organizations 3 Bundle met Organization loop [voor iedere organisatie] 4 Endpoints opvragen adhv Organization <adressering-base>/Endpoint?organization=Organization/<Organization.name> Endpoint opvragen bij Organization 5 Bundle met Endpoint
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
Zorgverlener Zorgviewer ~MITZ Uitwisselsysteem Toestemming ~MITZ Adressering 1 vervolg opstarten zorgviewer 2 Opvragen ontvankelijke zorgaanbieders (Open autorisatievraag adhv BSN) <toestemming-base>/Consent?patient:Patient.identifier=<BSN> Afhankelijk van toestemming van patient voor "delen met de zorgverlener". 3 Lijst ontvankelijke zorgaanbieders (Organization) Bundle met ToestemmingConsent loop [voor iedere zorgaanbieder] 4 Endpoints opvragen adhv Organization <adressering-base>/Endpoint?organization=<Consent.organization.reference> Consent.organization: e.g. UMCG Endpoint opvragen bij Organization 5 Bundle met Endpoint
Bevragen terminologie
TODO
Opvragen CodeSystems en ValueSets voor gebruik in de Zorgviewer.
Van toepassing zijnde standaarden en documentatie :
Bevragen bronsystemen zorgaanbieders
Van toepassing zijnde standaarden en documentatie :
Andere zorgaanbieder Zorgverlener Zorgviewer Logging Behandelplan Bronsysteem ontsluiting Bronsysteem 1 vervolg bepalen zorgaanbieders 2 log gebeurtenis, zie AuditEvent 3 Bepalen minimale dataset <behandelplan-base>/PlanDefinition?name=BgZ2017 Eerst hard-coded "BgZ2017" behandelplan. Later obv (hoofd)diagnose(zorgpad) of rol/specialisme gebruiker. 4 Behandelplan PlanDefinition loop [voor iedere zorgaanbieder] 5 Bronsysteem ontsluiting endpoint 6 verkrijg patient_fhir_id adhv BSN <bronsysteem-ontsluiting-base>/Patient?identifier=<BSN> 7 verkrijgen access token (na discovery) inclusief zorgviewer user organisatie tbv logging auth_token bij access token request: { "iss": "...", "sub": "...", "exp": "...", ... (optioneel) "subject_organization": "UMCG", "subject_organization_id": "urn:oid:2.16.840.1.113883.2.4.3.8", ... } 8 Patient request 9 log request 10 Patient resource 11 Patient loop [gegevensverzoeken] 12 formuleren gegevensverzoek(request) adhv Behandelplan Data Requirements PlanDefinition.action[0].output[].type en PlanDefinition.action[0].output[].codeFilter 13 gegevensverzoek <bronsysteem-ontsluiting-base>/<resource>?patient=<patient_fhir_id>&<filter> opt [als token verlopen] 14 verkrijgen access token (dmv backend account) 15 gegevensverzoek (per zib) met access token 16 log request 17 fhir resources (Bundle) bij de zib 18 Toevoegen meta-tag voor deze bron adhv Patient.managingOrganization of geconfigureerd adhv bronsysteem-zorgaanbieder . "meta": { "extension": [ { "url": "http://hl7.org/fhir/R4/StructureDefinition/extension-Meta.source", "valueUri": "uri:oid:2.16.840.1.113883.2.4.3.8" } ] } 19 fhir resources (Bundle) bij de zib 20 TOEKOMST : ontdubbelen en conflicten detectie Zorgviewer invulling van BgZ paragrafen 3.2.9.1 Ontdubbelen en 3.2.9.2 Duplicaatdetectie 21 toon gegevens 22
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.
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"
}
Tbv het correleren van de Zorgviewer logging met de logging van een Bronsysteem dient een X-Request-Id
HTTP Header (zie Custom Headers to support logs/audit ) te worden toegevoegd aan ieder request aan het Bronsysteem. Deze kan dan door het Bronsysteem gelogd worden.
Bevragen bronsystemen zorgaanbieders documenten
Van toepassing zijnde standaarden en documentatie :
Andere zorgaanbieder Zorgverlener Zorgviewer Bronsysteem ontsluiting Bronsysteem Zorgviewer Directory 1 vervolg bevragen bronsystemen zorgaanbieders loop 2 voor iedere zorgaanbieder ( Bronsysteem ontsluiting endpoint ) 3 formuleren documenten gegevensverzoek(request) 4 gegevensverzoek <bronsysteem-ontsluiting-base>/DocumentReference?patient=<patient_fhir_id> opt [als token verlopen] 5 verkrijgen access token (dmv backend account) 6 gegevensverzoek met access token 7 log request 8 fhir resources (DocumentReference Bundle) 9 Bundle met DocumentReference TOEKOMST : specialisme bij documenten loop 10 GET <bronsysteem-ontsluiting-base>/Practitioner/<practitioner_fhir_id> 11 Practitioner 12 GET <zorgverlener-directory-base>/PractitionerRole/?identifier=<AGB/BIG> 13 Bundle met PractitionerRole 14 samenvoegen 15 toon documenten lijst 16 wacht op gebruikers actie 17 selecteer document 18 gegevensverzoek <bronsysteem-ontsluiting-base>/Binary/<binary-id> url komt uit DocumentReference.content.attachement.url Stuur Accept Header application/fhir+xml of application/fhir+json opt [als token verlopen] 19 verkrijgen access token (dmv backend account) 20 gegevensverzoek met access token 21 log request 22 Binary 23 Binary 24 toon document 25