RIVO-Noord Zorgviewer MVP2 Implementation Guide
0.17.0 - sprint20 Netherlands flag

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 zorgaanbiederZorgverlenerZorgviewer HostAuthenticatieZorgviewer1start EPD2inloggen met lokale identiteit3selecteer patient4start Zorgviewer5start met context dmv SMART-on-FHIRhttps://app-tst.zorgviewer.nl/application/launch6SMART-on-FHIR handshakezorgviewer-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>"... }7opvragen gebruiker gegevens<zorgviewer-host-base>/Practitioner/<practitioner_fhir_id>8Practitioner9toon gebruiker gegevens10opvragen patient gegevens<zorgviewer-host-base>/Patient/<patient_fhir_id>11Patient(onder andere BSN voor verdere raadplegingen)12toon patient gegevens13ga naar de Bepalen zorgaanbieders sequence

Bepalen zorgaanbieders

Bepalen zorgaanbieders en endpoints zonder toestemming check

ZorgverlenerZorgviewerAdressering1vervolg opstarten zorgviewer2Organizations opvragen<adressering-base>/OrganizationAlle geregistreerde Organizations3Bundle metOrganizationloop[voor iedere organisatie]4Endpoints opvragen adhv Organization<adressering-base>/Endpoint?organization=Organization/<Organization.name>Endpoint opvragen bij Organization5Bundle metEndpoint

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
ZorgverlenerZorgviewer~MITZ UitwisselsysteemToestemming~MITZAdressering1vervolg opstarten zorgviewer2Opvragen ontvankelijke zorgaanbieders (Open autorisatievraag adhv BSN)<toestemming-base>/Consent?patient:Patient.identifier=<BSN>Afhankelijk van toestemming van patientvoor "delen met de zorgverlener".3Lijst ontvankelijke zorgaanbieders (Organization)Bundle metToestemmingConsentloop[voor iedere zorgaanbieder]4Endpoints opvragen adhv Organization<adressering-base>/Endpoint?organization=<Consent.organization.reference>Consent.organization: e.g. UMCGEndpoint opvragen bij Organization5Bundle metEndpoint

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 zorgaanbiederZorgverlenerZorgviewerLoggingBehandelplanBronsysteem ontsluitingBronsysteem1vervolg bepalen zorgaanbieders2log gebeurtenis, zieAuditEvent3Bepalen minimale dataset<behandelplan-base>/PlanDefinition?name=BgZ2017Eerst hard-coded "BgZ2017" behandelplan.Later obv (hoofd)diagnose(zorgpad) of rol/specialisme gebruiker.4BehandelplanPlanDefinitionloop[voor iedere zorgaanbieder]5Bronsysteem ontsluiting endpoint6verkrijgpatient_fhir_idadhv BSN<bronsysteem-ontsluiting-base>/Patient?identifier=<BSN>7verkrijgen access token (na discovery)inclusief zorgviewer user organisatie tbv loggingauth_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",... }8Patient request9log request10Patient resource11Patientloop[gegevensverzoeken]12formuleren gegevensverzoek(request) adhv Behandelplan Data RequirementsPlanDefinition.action[0].output[].typeenPlanDefinition.action[0].output[].codeFilter13gegevensverzoek<bronsysteem-ontsluiting-base>/<resource>?patient=<patient_fhir_id>&<filter>opt[als token verlopen]14verkrijgen access token (dmv backend account)15gegevensverzoek (per zib) met access token16log request17fhir resources (Bundle) bij de zib18Toevoegen meta-tag voor deze bronadhv Patient.managingOrganization of geconfigureerd adhvbronsysteem-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"} ]}19fhir resources (Bundle) bij de zib20TOEKOMST: ontdubbelen en conflicten detectieZorgviewer invulling vanBgZ paragrafen 3.2.9.1 Ontdubbelen en 3.2.9.2 Duplicaatdetectie21toon gegevens22 

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" 
}

Toevoegen X-Request-Id HTTP Header

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.

In de toekomst kijken we naar de W3C Recommendation Trace Context. Niet in scope MVP2.

Bevragen bronsystemen zorgaanbieders documenten

Van toepassing zijnde standaarden en documentatie:

Andere zorgaanbiederZorgverlenerZorgviewerBronsysteem ontsluitingBronsysteemZorgviewerDirectory1vervolg bevragen bronsystemen zorgaanbiedersloop2voor iedere zorgaanbieder (Bronsysteem ontsluiting endpoint)3formuleren documenten gegevensverzoek(request)4gegevensverzoek<bronsysteem-ontsluiting-base>/DocumentReference?patient=<patient_fhir_id>opt[als token verlopen]5verkrijgen access token (dmv backend account)6gegevensverzoek met access token7log request8fhir resources (DocumentReference Bundle)9Bundle metDocumentReferenceTOEKOMST: specialisme bij documenten loop10GET <bronsysteem-ontsluiting-base>/Practitioner/<practitioner_fhir_id>11Practitioner12GET <zorgverlener-directory-base>/PractitionerRole/?identifier=<AGB/BIG>13Bundle metPractitionerRole14samenvoegen15toon documenten lijst16 wacht op gebruikers actie17selecteer document18gegevensverzoek<bronsysteem-ontsluiting-base>/Binary/<binary-id>url komt uit DocumentReference.content.attachement.urlStuurAccept Headerapplication/fhir+xml of application/fhir+jsonopt[als token verlopen]19verkrijgen access token (dmv backend account)20gegevensverzoek met access token21log request22Binary23Binary24toon document25