RIVO-Noord Zorgviewer Implementation Guide
1.6.0 - CI build Netherlands flag

RIVO-Noord Zorgviewer Implementation Guide, published by RIVO-NN HL7NL. This guide is not an authorized publication; it is the continuous build for version 1.6.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/RIVO-Noord/zorgviewer-ig/ and changes regularly. 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.

Bouwblokken

Bouwblokken
Bouwblokken
   
Toestemming Inwoners van onze zorgregio geven op één keer, op één plek zorgverleners toestemming, dat zij hun zorggegevens mogen inzien van andere behandelaren en vanuit andere zorgorganisaties.
Authenticatie Klopt het dat jij als zorgverlener bent, wie je zegt dat je bent? Werk jij echt bij die zorgorganisatie? Door middel van twee factor authenticatie binnen je eigen informatieomgeving wordt jouw identiteit op twee manieren gecheckt. Met deze authenticatie heb je ook toegang tot de Zorgviewer.
Autorisatie Welke informatie van patiënten en cliënten is voor mij als zorgverlener beschikbaar? Mag je als apotheker bijvoorbeeld de volledige zorginformatie zien of heb je enkel inzag in labuitslagen en medicatie?
N.B. MVP2 heeft 1 autorisatie profiel, namelijk alle Zorgverleners die via de Authenticatie bouwblok toegang hebben tot de Zorgviewer hebben toegang tot de BgZ en Correspondentie van de patient.
Patiëntindex De patiëntindex maakt inzichtelijk bij welke zorgorganisaties de patiënt of cliënt bekend is. De zorgviewer bevraagt bij het inloggen door een zorgverlener enkel de informatiesystemen van deze zorgorganisaties.
Logging Wie logt wanneer en waar in? Het geautomatiseerde logboek houdt exact bij welke zorgverlener toegang heeft gevraagd en gekregen tot de zorginformatie van een patiënt of cliënt.
Behandelplan De stappen die je als patiënt of cliënt doorloopt in het zorgpad. In de zorgviewer zie je een digitale weergave van het -regionaal overeengekomen- zorgpad. Aan de gestructureerde stappen ‘hangen’ informatiecomponenten vast.
Ontsluiting bronsysteem Elk informatiesysteem communiceert in een eigen taal. Dit technische bouwblok is een koppeling, die ervoor zorgt, dat alle zorginformatie uit de verschillende bronsystemen in de zorgviewer in dezelfde taal beschikbaar is.
Overname TOEKOMST Is de zorginformatie -beschikbaar in de zorgviewer, afkomstig van een ander bronsysteem- voor jou als zorgverlener relevant, dan kan je deze selecteren en overnemen in de informatieomgeving van jouw zorgorganisatie.
Zorgviewer Alle bouwblokken samen vormen de zorgviewer. De zorgviewer combineert, ontdubbelt en filtert de informatie op basis van jouw behoefte als zorgverlener. De zorgviewer biedt zorgverleners een 360° beeld van de patiënt of cliënt. Opgebouwd uit alle beschikbare zorginformatie, waarvoor de patiënt of cliënt toestemming heeft gegeven.
Multi-inzetbaar: De bouwblokken zijn niet alleen bruikbaar voor de regionale zorgviewer, maar zijn ook bruikbaar en essentieel voor het delen van diagnostiek, multidisciplinair overleg, monitoring en e-Health en de Persoonlijke Gezondheidsomgeving (PGO).

Zorgviewer Services

Bouwblokken samenwerking

In onderstaande schema zie je de groepering en interacties (in globale volgorde) tussen de verschillende bouwblokken.

cloudEpic huisChipsoft of Topicus huis«future»Zorgviewer Host LosZorgviewer«future»Behandelplan«future»Toestemming«future»Adressering«future»ZorgverlenerDirectory«ZorgviewerHost»Hyperspace«Authenticatie»Epic Auth«Bronsysteemontsluiting»IRIS of Rhapsody«Bronsysteem& Logging»Epic«Zorgviewer Host& Logging& Bronsysteem»HiX of VIPLive«Authenticatie»Zorgplatform ofVIPLive Auth«Bronsysteemontsluiting»Zorgplatformof VIPLive«Zorgviewer Host»«future»ZV Los«Authenticatie»«future»ZV Los Auth1. opstart1. opstart1. opstart2. wie?2. wie?2. wie?3a. waar?3b. waar?4. filters5. bevragen5. bevragen(opt)5b. bevragen

Functionaliteiten

Hierna volgt een schema met functionaliteiten per bouwblok.

ZorgviewerZorgviewer HostBehandelplanToestemming & PatientindexPatientbannerWeergavegegevensSorterenConflictenattenderenOntdubbelengegevensFiltering obvBehandelplanOpstartZorgviewerSteltidentity vastControlebehandelrelatiePatientselectieZorgverlenergegevensZorgverlenerrollenBehandelplannenadhv diagnoseRelevante gegevensadhv zorgpadRelevante gegevensadhv rolToegestanebronsystemen patientBronsystemenendpoints

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:

Eigen zorgaanbiederZorgverlenerZorgviewer HostAuthenticatieZorgviewer1start EPD2inloggen met lokale identiteit3selecteer patient4start Zorgviewer5start met context dmv SMART-on-FHIRhttps://app-tst.zorgviewer.nl/application/launch6SMART-on-FHIR handshakeUit request: 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>"... }7opvragen gebruiker gegevens<zorgviewer-host-base>/Practitioner/<practitioner_fhir_id>8Practitioner9opvragen gebruiker rollen<zorgviewer-host-base>/PractitionerRole?practitioner=<practitioner_fhir_id>10PractitionerRoleopt:ConceptMapgebruiken voor PractitionerRole.codesubject_role zit in Practitioner.code[system=SNOMED CT]subject_organization_id zit in Practitioner.meta[extension=source]11toon gebruiker gegevens12opvragen patient gegevens<zorgviewer-host-base>/Patient/<patient_fhir_id>13Patient(onder andere BSN voor verdere raadplegingen)14toon patient gegevens15ga naar de Bepalen zorgaanbieders sequence

Token Attributes mapping op FHIR tabel:

Scope Name/Path Value FHIR Path
Practitioner FHIR ID practitioner ABCD.. Practitioner.id
Patient FHIR ID patient WXYZ.. Patient.id

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:

Eigen zorgaanbiederHiX / ZorgplatformZorgverlenerZorgviewer HostAuthenticatieZorgviewer1start EPD2inloggen met lokale identiteit3selecteer patient4start Zorgviewer5start met context6SAML handshakeAttributen1.BSN -> resource-id2.Role -> role... zie tabel7toon gebruiker gegevens8toon patient gegevens9ga naar de Bepalen zorgaanbieders sequence

SAML Attributes Assertions mapping op FHIR tabel:

Item Attribute Name/Path Value FHIR Path
Workflow ID http://sts.zorgplatform.online/ws/claims/2017/07/workflow/workflow-id a84f5229-c804-4627-8b80-489ae3ed6a51 nvt
Practitioner ID Subject/NameID larts@2.16.528.1.1007.3.3.15123 Practitioner.identifier
Practitioner Role urn:oasis:names:tc:xacml:2.0:subject:role SNOMED CT 62247001 huisarts Practitioner.qualification[system=sct]
Patient BSN urn:oasis:names:tc:xacml:1.0:resource:resource-id 999911120 Patient.identifier[system=bsn]

Opstarten zorgviewer: VIPlive

Van toepassing zijnde standaarden en documentatie:

Eigen zorgaanbiederVIPLiveZorgverlenerZorgviewer HostAuthenticatieZorgviewer1start EPD2inloggen met lokale identiteit3selecteer patient4start Zorgviewer5start met context6SAML handshakeSAML Attributes1.subject:role2.subject:organization-id... zie tabel7toon gebruiker gegevens8toon patient gegevens9ga naar de Bepalen zorgaanbieders sequence

SAML Attributes Assertions op FHIR mapping tabel:

Item Attribute Name/Path Value FHIR Path
Organization OID urn:oasis:names:tc:xspa:1.0:subject:organization-id 2.16.840.1.113883.2.4.3.164.2.1.2 Organization.identifier
Practitioner ID Subject/NameID 177578 Practitioner.identifier
Practitioner Role urn:oasis:names:tc:xacml:2.0:subject:role <Role code="62247001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED_CT" displayName="huisarts" xmlns="urn:hl7-org:v3"/> Practitioner.qualification[system=sct]
Practitioner Name professional.initials L. Practitioner.name.given[extension=IN]
Practitioner Name professional.family_name Arts Practitioner.name.family
Patient Name client.initials J. Patient.name.given[extension=IN]
Patient Name client.family_name Fictief Patient.name.family
Patient Birthdate client.birthdate 19700101 Patient.birthDate
Patient BSN client.bsn 999911120 Patient.identifier[system=bsn]

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

Item Chipsoft Zorgplaform (SAML) VIPLive (SAML) Epic (SMART-on-FHIR) Value FHIR Path
Workflow ID http://sts.zorgplatform.online/ws/claims/2017/07/workflow/workflow-id nvt nvt a84f5229-c804-4627-8b80-489ae3ed6a51 nvt
Practitioner ID Subject/NameID Subject/NameID Practitioner read adhv token.practitioner / zie FHIR Path 177578 Practitioner.identifier
Practitioner Role urn:oasis:names:tc:xacml:2.0:subject:role urn:oasis:names:tc:xacml:2.0:subject:role ^^ / zie FHIR Path code=62247001 display=huisarts system=SNOMED CT Practitioner.qualification[system=sct]
Practitioner Name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name professional.initials ^^ / zie FHIR Path L. Practitioner.name.given[extension=IN]
Practitioner Name http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name professional.family_name ^^ / zie FHIR Path Arts Practitioner.name.family
Organization OID urn:oasis:names:tc:xspa:1.0:subject:organization-id organization-id ^^ / zie FHIR Path 2.16.840.1.113883.2.4.3.8 Practitioner.meta[extension=source]
Patient BSN urn:oasis:names:tc:xacml:1.0:resource:resource-id client.bsn Patient read adhv token.patient / zie FHIR Path 999911120 Patient.identifier[system=bsn]
Patient FHIR ID patient-fhir-id uit Task.reference read adhv workflow-id   token.patient / zie FHIR Path 9819C39260647B5DE61609CDF1FA1C Patient.id
Patient Name ^^ / zie FHIR Path client.initials ^^ / zie FHIR Path J. Patient.name.given[extension=IN]
Patient Name ^^ / zie FHIR Path client.family_name ^^ / zie FHIR Path Fictief Patient.name.family
Patient Birthdate ^^ / zie FHIR Path client.birthdate ^^ / zie FHIR Path 19700101 Patient.birthDate

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 bronsystemen zorgaanbieders

Van toepassing zijnde standaarden en documentatie:

Andere zorgaanbiederZorgverlenerZorgviewerLoggingBehandelplanBronsysteem ontsluitingAuthenticatieBronsysteem1..vervolg bepalenzorgaanbieders..2log 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 tokenzie tabelauth_token bij access token request:{ ..."subject_name": "Int Arts","subject_role": [{"system": "2.16.840.1.113883.6.96","code": "309343006","display": "Arts"}],(optioneel) "subject_organization": "UMCG","subject_organization_id": "urn:oid:2.16.840.1.113883.2.4.3.8" }8Patient request9toestemming controleen log request10Patient resourceopt[als knooppunt voor meerdere bronnen]11Toevoegen bron metadataadhvbronsysteem-zorgaanbieder"meta": {"extension": [ {"url": "http://hl7.org/fhir/4.0/StructureDefinition/extension-Meta.source","valueUri": "uri:oid:2.16.840.1.113883.2.4.3.8"} ]}- of -via Patient.managingOrganization.identifier12Patientloop[gegevensverzoeken]13formuleren gegevensverzoek (request)adhv Behandelplan Data RequirementsPlanDefinition.action[0].output[].typeenPlanDefinition.action[0].output[].codeFilter14gegevensverzoek<bronsysteem-ontsluiting-base>/<resource>?patient=<patient_fhir_id>&<filter>opt[als token verlopen]15verkrijgen access token (zie stap #7)16gegevensverzoek (per zib)17toestemming controlelog request18fhir resources (Bundle) bij de zibopt[als knooppunt voor meerdere bronnen]19Toevoegen bron metadata (zie stap #11)20fhir resources (Bundle) bij de zibTOEKOMST21ontdubbelen en conflicten detectieZorgviewer invulling vanBgZ paragrafen 3.2.9.1 Ontdubbelen en 3.2.9.2 Duplicaatdetectie22toon gegevens23 

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

Item Generiek (HTTP-Header) TA Notified Pull Chipsoft Zorgplaform (SAML) VIPLive (SAML) Epic (SMART-on-FHIR) Value FHIR Path
PurposeOfUse   FHIR Task.code urn:oasis:names:tc:xspa:1.0:subject:purposeofuse nvt nvt TREATMENT nvt
Workflow ID   FHIR Task.identifier http://sts.zorgplatform.online/ws/claims/2017/07/workflow/workflow-id nvt nvt a84f5229-c804-4627-8b80-489ae3ed6a51 nvt
Patient BSN   auth_token.patient urn:oasis:names:tc:xacml:1.0:resource:resource-id client.bsn auth_token.patient 999911120 Patient.identifier[system=BSN]
Practitioner ID X-ZV-Subject-Id auth_token.user_id Subject/NameID Subject/NameID auth_token.subject_id en HTTP-Header AORTA-ID usr 177578 Practitioner.identifier
Practitioner Role X-ZV-Subject-Role auth_token.user_role urn:oasis:names:tc:xacml:2.0:subject:role urn:oasis:names:tc:xacml:2.0:subject:role auth_token.subject_role en HTTP-Header AORTA-ID rol code=62247001 display=huisarts system=SNOMED CT Practitioner.qualification[system=sct]
Practitioner Name     http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name professional.initials + professional.family_name auth_token.subject_name L. Arts Practitioner.name
Organization OID X-ZV-Subject-Organization-Id auth_token.sub urn:oasis:names:tc:xspa:1.0:subject:organization-id urn:oasis:names:tc:xspa:1.0:subject:organization-id auth_token.subject_organization_id en HTTP-Header AORTA-ID org 2.16.528.1.1007.3.3.15123 Practitioner.meta[extension=source]
Correlation ID X-Correlation-Id   ⇐ ⇐ HTTP-Header AORTA-ID cid NaN0-1D-12 H54f_8b9d6bC nvt
Request ID X-Request-Id   ⇐ ⇐ HTTP-Header AORTA-ID rid NaN0-1D-12 1b9d6bCd-bBf nvt
Context X-ZV-Context   ⇐ ⇐ ⇐ zie boven  

Bevragen bronsystemen zorgaanbieders documenten

Van toepassing zijnde standaarden en documentatie:

Andere zorgaanbiederZorgverlenerZorgviewerZorgverlenerDirectoryBronsysteem ontsluitingBronsysteem1vervolg 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 token6gegevensverzoek7toestemming checken log request8fhir resources (DocumentReference Bundle)opt[als knooppunt voor meerdere bronnen]9Toevoegen bron metadata10Bundle metDocumentReferenceTOEKOMST: specialisme bij documenten loop11GET <bronsysteem-ontsluiting-base>/Practitioner/<practitioner_fhir_id>12Practitioner13GET <zorgverlener-directory-base>/PractitionerRole/?identifier=<AGB/BIG>14Bundle metPractitionerRole15samenvoegen16toon documenten lijst17 wacht op gebruikers actie18selecteer document19gegevensverzoek<bronsysteem-ontsluiting-base>/Binary/<binary-id>url komt uit DocumentReference.content.attachement.urlStuurAccept Headerapplication/fhir+xml of application/fhir+jsonopt[als token verlopen]20verkrijgen access token21gegevensverzoek22toestemming checken log request23Binaryopt[als knooppunt voor meerdere bronnen]24Toevoegen bron metadata25Binary26toon document27