Netherlands - Clientbeeld 360 Implementation Guide - Local Development build (v1.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. 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` XIS Nuts-node Nuts-node Nuts-node Nuts-node PEP PEP PEP Fhir Fhir Fhir Healthcare professional XIS Nuts-node Nuts-node PEP Fhir Healthcare professional XIS Nuts-node Nuts-node PEP Fhir XIS Nuts-node Nuts-node Nuts-node Nuts-node PEP PEP PEP Fhir Fhir Fhir 1 Log in 2 Create User session, User info needed for NutsEmployeeCredential (step 7) Later in User session 3 request information for Patient 4 Resolve Patient BSN, and array of data_holder_URA's for patient if it is known Array 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 organisation 5 Look up data holder organisation in discovery GET /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-definitions 6 Found Organization B (authorization_server_url, and fhir_base_url_stu3 and/or fhir_base_url_r4) get access token 7 Get access token POST /internal/auth/v2/{subjectID of Data user organisation}/request-service-access-token 8 nuts-nodes handle access token request, request is forwarded using value of "authorization_server_url" element in body uses X509Credential, HealthcareProviderRoleTypeCredential and NutsEmployeeCredential 9 Access token loop [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 9 10 POST {fhir_base_url_stu3/r4}/Patient/_search 11 introspect access token POST /internal/auth/v2/accesstoken/introspect 12 valid token + requesting_URA + USER{name,userRole,identifier} 13 Authorization (Legal basis to be determined by use case, e.g. patient consent and/or treatment relationship) 14 POST {internal_fhir_url_stu3/r4}/Patient?search 15 : 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 needed 17 GET /CapabilityStatement 18 GET /CapabilityStatement 19 : CapabilityStatement Fhir resource 20 : CapabilityStatement Fhir resource Retrieve 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 9 loop [For each resource except Patient] 21 GET /fhir/{resource}?patient={patient-id} 22 introspect access token POST /internal/auth/v2/accesstoken/introspect 23 valid token + requesting_URA + USER{name,userRole,identifier} 24 Authorization (Legal basis to be determined by use case, e.g. patient consent and/or treatment relationship) 25 GET /fhir/{resource}?patient={patient-id} 26 : Fhir resource 27 : Fhir resource Data user XIS displays data received from data holder(s) 28 Display 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.
