Netherlands - Clientbeeld 360 Implementation Guide
1.0.0 - active Netherlands flag

Netherlands - Clientbeeld 360 Implementation Guide, published by Stichting Nuts. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/nuts-foundation/nl-360-ig/ and changes regularly. See the Directory of published versions

Volume 2b

Please see Volume 2b of the Zorginzage-specification for more details.

Registration at discovery service

Step 1 details

Use the following ServiceID: "VersneldVerbindenDiscoveryService"

Pull

This specification reuses the Pull sequence diagram as defined in the Zorginzage-specification and adds extra requests to retrieve a Data holder organsation's CapabilityStatement. For readability a complete new sequence is included below:

Data user organisation `A` Data holder organisation `B` XISNuts-nodeNuts-nodeNuts-nodeNuts-nodePEPPEPPEPFhirFhirFhirHealthcare professionalXISNuts-nodeNuts-nodePEPFhirHealthcare professionalXISNuts-nodeNuts-nodePEPFhirXISNuts-nodeNuts-nodeNuts-nodeNuts-nodePEPPEPPEPFhirFhirFhir1Log in2Create User session,User info needed for NutsEmployeeCredential (step 7)Later in User session3request information for Patient4Resolve Patient BSN, and array of data_holder_URA's for patient if it is knownArray of data_holder_URA's can be found via a (local) index (e.g. user-input and/or a CareTeam-resource)loop[For each data_holder_URA]get addresses of data holder organisation5Look up data holder organisation in discoveryGET /internal/discovery/v1/{serviceID}?organization_ura={URA}The 360 specification requires elements with id "organization_ura", "authorization_server_url" and one or two from "fhir_base_url_stu3" and "fhir_base_ur_r4" in the discovery-service-presentation-definitions6Found Organization B (authorization_server_url, and fhir_base_url_stu3 and/or fhir_base_url_r4)get access token7Get access tokenPOST /internal/auth/v2/{subjectID of Data user organisation}/request-service-access-token8nuts-nodes handle access token request, request is forwarded using value of "authorization_server_url" element in bodyuses X509Credential, HealthcareProviderRoleTypeCredential and NutsEmployeeCredential9Access tokenloop[for each found fhir endpoint (fhir_base_url_stu3 and/or fhir_base_url_r4)]get Patient resource including patient-id- POST-based Patient search on BSN- use access token received in step 910POST {fhir_base_url_stu3/r4}/Patient/_search11introspect access tokenPOST /internal/auth/v2/accesstoken/introspect12valid token + requesting_URA + USER{name,userRole,identifier}13Authorization(Legal basis to be determined by use case, e.g. patient consent and/or treatment relationship)14POST {internal_fhir_url_stu3/r4}/Patient?search15: Patient Fhir resource (with patient-id)16: Patient Fhir resource (with patient-id)alt[Patient is found]Retrieve capability statement of Data holder organisation- CapabilityStatemment can also be retrieved in a separate (periodic) process.- When the data holder organisation has already stored a current version of the CapabilityStatement it is not needed to retrieve it as part of the Pull-sequence.- Retrieve CapabilityStatement to be able to only send requests that the Data holder organisation supports- no access token needed17GET /CapabilityStatement18GET /CapabilityStatement19: CapabilityStatement Fhir resource20: CapabilityStatement Fhir resourceRetrieve other resources- Other resources are queried using the internal patient-id of Data holder organisation received in step 16- Queries MUST only contain the profiles that are part of the CapabilityStatement of the Data holder organisation- Queries use access token received in step 9loop[For each resource except Patient]21GET /fhir/{resource}?patient={patient-id}22introspect access tokenPOST /internal/auth/v2/accesstoken/introspect23valid token + requesting_URA + USER{name,userRole,identifier}24Authorization(Legal basis to be determined by use case, e.g. patient consent and/or treatment relationship)25GET /fhir/{resource}?patient={patient-id}26: Fhir resource27: Fhir resourceData user XIS displays data received from data holder(s)28Display external Patient information


Step 5 details

Use the following ServiceID: "VersneldVerbindenDiscoveryService"

Pull of CapabilityStatement

  • Data holder organisations MUST make the CapabilityStatement per FHIR-server accessible for data user organisations without the need for an access token.
  • Data user organisations MUST retrieve the CapabilityStatement of a data holder organisation's FHIR-server before sending resource queries other than Patient to that FHIR-server.
  • ​Data user organisations MUST retrieve CapabilityStatements as specified in the Pull-sequence OR in a separate (periodic) process.