BgZ:V2.0 BgZ 2017 Technical IG

1 Note on this Implementation Guide - alpha status

This alpha version of the Implementation Guide (TO) is not technically complete, but even so, it is being published in order to start obtaining feedback from the stakeholders. The current version provides an early indication of the contents being proposed.

The following items require further investigation, discussion and review amongst all stakeholders.

1. Generic description of the Notified Pull communication pattern - this is being developed by Team Radar (Generic) within Nictiz at the moment and will be referred to from this TO. The intention is to avoid duplicating information at all costs.
2. FHIR Notification and Workflow Task profiles - the first versions of these have been developed locally and now need to be published via Simplifier so that a reference can be made to them from this TO.
3. FHIR GET (read/search) request strings - these need to be reviewed once the Referenced BgZ Resource profiles are complete.
4. FHIR Referenced BgZ Resource profiles - the FO defines two new data elements that enrich the BgZ items - EersteRegistratieDatumTijd (FirstRegistrationDateTime) and MutatieDatumTijd (ContentModificationDateTime). These two fields need to be added to the corresponding BgZ FHIR resources and the mechanism for doing this is under discussion at the moment. The FHIR Provenance Resource is being considered. As soon as there is some clarity on best practices then the FHIR resource profiles will be updated and references adjusted in this TO.

The intention is to finalize agreements on these issues for the beta version of the TO. This alpha version will be updated, towards a beta version, as issues are resolved.

2 Introduction

2.1 Background

The BgZ MSZ Information Standard describes the exchange of the BgZ information between healthcare providers. The BgZ information is the minimum collection of patient data that is relevant across specialty, syndrome and profession and is important for the continuity of care. This data collection can be exchanged between care institutions. The information standard focuses on the exchange between healthcare providers of specialist medical care.

This BgZ MSZ implementation guide defines the BgZ information exchanges, in terms of use cases, based on the Zib2017 and FHIR(STU3) HL7 FHIR, STU3. HL7 CDA is no longer supported for BgZ MSZ exchange. This implementation guide assumes that the reader is familiar with this FHIR version.

Apart from this document, the guidelines as specified in general FHIR Implementation Guide apply. The guide defines methods on how to proceed with implementing FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the Use case overarching principles and the use of FHIR packages.

2.2 About this document

This BgZ MSZ implementation guide is a technical document defining the BgZ information exchanges in terms of use cases. It should be used together with the BgZ MSZ Functional Design (FO) - see Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha.

The following documents also provide important background information:

• "Kwaliteitsstandaard - Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend" (which translates as “Exchange of BgZ between institutions where specialist medical care is provided”) [1]
• "NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg" (which translates as “Exchange of BgZ between institutions for specialist medical care”) [2]
• "Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism" [3]

This document assumes reader familiarity with these references.

This implementation guide is intended to provide information for implementation/deployment needs in the Netherlands. This document is part of an evolving strategy, features will likely be added, adjusted and/or removed in future versions.

2.3 Glossary

Term	Description
Basisgegevensset Zorg - medisch-specialistische zorg (BgZ MSZ)	Minimum collection of patient data that is relevant across specialty, clinical picture and profession and is important for the continuity of care.
BSN	The citizen service number (BSN) is a unique 9-digit personal number allocated to everyone registered in the Personal Records Database (BRP). Everyone who registers with the BRP is automatically given a BSN.
FHIR	Fast Healthcare Interoperability Resources
IHE	Integrating the Healthcare Enterprise
HCIM	Health and Care Information models (HCIM) or Zorginformatiebouwstenen (ZIB's) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
MedMij	MedMij is an initiative of the Dutch Patient Federation and was embraced as one of the five focus programs in 2015. The Healthcare Information Council then opted for the MedMij program. To make healthcare better, more affordable and more accessible, the Information Council is working on a sustainable information system for healthcare, in which healthcare data is exchanged securely and reliably. To this end, agreements, standards, and facilities are made, together with the participants of the Information Council.
VZVZ	Vereniging van Zorgaanbieders voor Zorgcommunicatie: Dutch Association for Health Providers
Zib	A Zib (Zorginformatiebouwstenen) defines a clinical concept in such a way that it can be used as a building block in various healthcare situations and information systems. ZIBs form the basis for the standardization of healthcare information.

Table 2.1 Glossary

3 Boundaries and Relationships

This is the first version of the BgZ MSZ information standard in which the Notified Pull communication pattern is used to implement the "Exchange BgZ for Referral" use case. A generic description of the Notified Pull communication pattern is available (add link the Nictiz Team Radar/Generic NP description). The generic description is supplemented in this Implementation Guide by specific details defining:

1. The Notification and Workflow Tasks in terms of their FHIR profiles.
2. The GET request strings required to read/search for the BgZ MSZ items, defined as Input parameters in the Notification/Workflow tasks, from the Sending System by the Receiving System.
3. The referenced FHIR resource profiles corresponding to the BgZ MSZ items.

4 Use Cases

Two use cases are defined in the FO as follows:

• Exchange BgZ for Referral ("Uitwisseling BgZ bij Verwijzing") from a referring (sending) healthcare provider to a receiving healthcare provider in the event of a planned referral or transfer between their two care institutions.
• Retrieval of BgZ from previous practitioner ("Opvraging BgZ bij eerdere behandelaar") by a requesting healthcare provider to his/her care institution from a different care institution.

The difference between the two use cases is mainly down to which healthcare provider takes the initiative to start the exchange of the BgZ.

4.1 Exchange BgZ for Referral

In the "Exchange BgZ for Referral" use case, the current healthcare provider (Referring (Sending) Medical Specialist) takes the initiative for a referral or transfer. In doing so, information is shared, including the BgZ (and, for example, a referral letter, additional images or reports). When the patient then attends the new care institution as a result of the referral, or transfer, the Receiving Medical Specialist can (re)use the information from the BgZ.

4.1.1 Actors

Persons		Systems
Name	Description	Name	Description
Referring (Sending) Medical Specialist	Medical specialist who sends a BgZ along with a referral	EHR	Electronic health record
Receiving Medical Specialist	Medical specialist receives a BgZ along with a referral	EHR	Electronic health record

It is assumed that the Referring (Sending) Medical Specialist and Receiving Medical Specialist, as persons who use the BgZ sharing infrastructure, are signed on, authenticated and have authorization & consent to access the necessary (patient) information stored in the BgZ sharing infrastructure (or in other words, an authenticated healthcare professional who has an active treatment relationship with the patient). The way in which the persons achieve this state is beyond the scope of this implementation guide but is expected to be facilitated by use of the generic infrastructure.

4.1.2 Transactions

The "Exchange BgZ for Referral" use case can be implemented using two types of transactions:

• Notified Pull (preferred)
• Push

4.1.2.1 Exchange BgZ for Referral using Notified Pull Transaction

The Notified Pull communication pattern is based on the description in [3]. The Referring (Sending) Medical Specialist notifies the Receiving Medical Specialist about the referral or transfer by sending a Notification Message. The Receiving Medical Specialist can then retrieve the BgZ (at a suitable time) using the Pull Message(s) which is(are) defined as a part of the Notification Message.

This two stage approach separates the notification phase from the actual BgZ retrieval phase allowing the Receiving Medical Specialist to decide if, and when, to retrieve the BgZ.

TODO: Linked to be added to the generic description of the Notified Pull communication pattern...

The Workflow Task message is optional in the BgZ MSZ exchange and no statement about it's inclusion is made by this Implementation Guide. However, in terms of system support the following rules apply:

1. The Sending System can support either a standalone Notification Task message or the combined use of the Notification Task and Workflow Task messages. If the Notified Pull is part of a workflow managed by the Sending System, then the Sending System will create a Workflow Task locally and indicate its use in the Notification Task message sent to the Receiving System.
2. The Receiving System must support both the use of a standalone Notification Task message and the combined Notification / Workflow Tasks messages, depending on which option is indicated for use in the Notification Task message. When a Workflow Task is indicated then the Receiving System must retrieve the Worklow Task message from the Sending System using a separate GET operation.

The FHIR profiles describing the Notification Task message, the Workflow Task message and the retrieved BgZ item resources are defined in the FHIR Profiles section.

The FHIR search/read queries used to retrieve the BgZ item resources are defined in the FHIR Task.input Query Specification section.

NOTE: The Notified Pull, as described in [3], identifies two additional transactions based on the Notification Task:

1. Notification Update
2. Notification Cancellation

Both of these transactions are out of scope for this version of the Implementation Guide.

4.1.2.2 Exchange BgZ for Referral using Push Transaction

The Referring (Sending) Medical Specialist pushes the BgZ to the Receiving Medical Specialist at the time of referral or transfer and not necessarily at the time when the Receiving Medical Specialist requires the BgZ (if it is required at all).

The Push method always transfers the BgZ to the Receiving Medical Specialist even when it might not be wanted or needed.

The FHIR profiles describing the BgZ item resources are defined in the FHIR Profiles section.

Note: The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR where the CDA based BgZ is replaced by a FHIR Composition and pushed between sending and receiving systems.

4.2 Retrieval of BgZ from previous practitioner (out of scope V2.0)

In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) is aware that the patient has had some previous treatment (through, for example, information provided by the patient) and takes the initiative to retrieve the details of this previous treatment from the previous care institution.

4.2.1 Actors

Persons		Systems
Name	Description	Name	Description
Requesting Medical Specialist	Medical specialist who queries for a BgZ	EHR	Electronic health record

It is assumed that the Requesting Medical Specialist, as person who uses the BgZ sharing infrastructure, is signed on, authenticated and has authorization & consent to access the necessary (patient) information stored in the BgZ sharing infrastructure (or in other words, an authenticated healthcare professional who has an active treatment relationship with the patient). The way in which the person achieves this state is beyond the scope of this implementation guide but is expected to be facilitated by use of the generic infrastructure.

4.2.2 Transactions

4.2.2.1 Retrieval of BgZ from previous practitioner using Pull Transaction

The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message.

The FHIR profiles describing the retrieved BgZ item resources are defined in the FHIR Profiles section.

The FHIR search/read queries used to retrieve the BgZ item resources are defined in the FHIR Task.input Query Specification section. The Task.input.value[x] definitions define the query search/read values to use.

5 FHIR Profiles

Note: These FHIR Profiles are under review and will be finalized by the beta version of the TO.

5.1 FHIR Notification Task

A BgZ MSZ Notification Task instance is created in the Receiving System by the Sending System issuing an HTTP POST operation to the Receiving System.

The following table identifies the location of the Notification Task FHIR profile.

FHIR Resource	FHIR Profile
(Notification) Task	http://fhir.nl/fhir/StructureDefinition/bgz-msz-notification-task-location-to-be-added

5.2 FHIR Workflow Task

If the Sending System supports the management of the BgZ MSZ information exchange, it will create a Workflow Task instance locally, and include details of the Workflow Task in the Notification Task exchanged with the Receiving System. The Recieving System can retrieve the Workflow Task by issuing an HTTP GET operation to the Sending System.

The following table identifies the location of the Workflow Task FHIR profile.

FHIR Resource	FHIR Profile
(Workflow) Task	http://fhir.nl/fhir/StructureDefinition/bgz-msz-workflow-task-location-to-be-added

5.3 FHIR Task Patient Identification

Although a patient is formally identified by their BSN in the BgZ MSZ information standard, this patient identifier is never exchanged as part of either the Notification Task or Workflow Task content. Instead, an "authorization base" token is exchanged, which only gives access by the Receiving System to specific data of a single patient managed by the Sending System.

The authorization base token is exchanged as one of the Task.input parameters in the Notification Task with a format as shown in the table below.

FHIR Task.input.type	FHIR Task.input.value[x] as valueString
codeSystem: http://fhir.nl/fhir/NamingSystem/TaskParameter code: authorization-base	authorization base token value (encrypted)

5.4 FHIR Task.input Query Specification

The following table provides the overview of the FHIR query (read/search) operations needed to retrieve all the BgZ MSZ items. These queries will be specified as Task.input (type and value[x]) parameters.

The Type column defines the type of query:

• Read - query for a single referenced FHIR resource instances where value[x] is a valueReference.
• Search - query for one or more FHIR resource instances where value[x] is a valueString representing the search string.

The Code (FHIR Task.input.type) column defines codedConcepts that identify the BgZ MSZ item (HCIM) to retrieve. Each codedConcept is defined in terms of the codeSystem, code and display name. NOTE: All codedConcepts/identifiers are defined by the Terminology Association in each HCIM - see ART DECOR BgZ MSZ Dataset The values are copied into this table for completeness/readability purposes.

The Value (FHIR Task.input.value[x]) column defines the query performed to retrieve the identified BgZ MSZ item.

The same Task.input parameters are applicable to the Notification Task or the Workflow Task depending on which is used to specify the BgZ MSZ retrieval operation.

NOTE to information standard reviewers: This is table defines the core BgZ MSZ Notified Pull contents and must be reviewed, accepted and adopted by all stakeholders. Please review very carefully.

BgZ Section	HCIM	Type	Code (FHIR Task.input.type)	Value (FHIR Task.input.value[x])	Description
1 Patient information	Patient	Search	http://snomed.info/sct 116154003 "Patient" or http://loinc.org 79191-3 "Patient demographics panel"	GET [base]/Patient? _include=Patient:general-practitioner	The Receiving System gets the patient identification, birth date, gender, deceased indicator, contact details, last known marital status, and general practitioner (practitioner or organization) that has been registered in the Sending System. Condition: Last Known Marital Status Cardinality: 0..1
2 Payment details	Payer	Search	http://loinc.org 48768-6 "Payment sources document"	GET [base]/Coverage? _include=Coverage:payor:Patient& _include=Coverage:payor:Organization	The Receiving System gets the patient's insurance information that has been that has been registered in the Sending System.
3 Treatment directives	Treatment Directive	Search	http://snomed.info/sct 11291000146105 "Treatment instructions"	GET [base]/Consent? category=http://snomed.info/sct|11291000146105	The Receiving System gets the most recent version of all Treatment Directives that have been registered in the Sending System.
	Advance Directive	Search	http://snomed.info/sct 11341000146107 "Living will and advance directive record"	GET [base]/Consent? category=http://snomed.info/sct|11341000146107	The Receiving System gets the most recent version of all Advance Directives that have been registered in the Sending System.
4 Contact persons	Contact Person	Search	http://snomed.info/sct 70862002 "Contact person"	see Patient	The Receiving System gets the most recent version of the primary partner/contact that was last registered in the Sending System. Condition: Primary partner/contact Cardinality: 0..1
5 Functional or Mental status	Functional Or Mental Status	Search	http://loinc.org 47420-5 "Functional status assessment note"	GET [base]/Observation/$lastn? category=http://snomed.info/sct|118228005, http://snomed.info/sct|384821006	The Receiving System gets, per StatusName, the most recent version of the FunctionalOrMentalStatus that was last registered in the Sending System. Specifically, if available, these are the last known status of the functions: mental, hearing, vision, mobility and language skills. Condition: Last known status of a function Cardinality: 0..*
6 Problems	Problem	Read	http://loinc.org 11450-4 "Problem list - Reported"	GET [base]/Condition	The Receiving System gets the most recent version of all issues that have been registered in the Sending System.
7 Social history	Living Situation	Search	http://snomed.info/sct 365508006 "Finding of residence and accommodation circumstances"	GET [base]/Observation/$lastn? code=http://snomed.info/sct|365508006	The Receiving System gets the most recent version of the living situation that was last registered in the Sending System. This does not have to be the Living Situation that has been updated most recently. Condition: If available, the last known living situation. Cardinality: 0..1
	Drug Use	Search	http://snomed.info/sct 228366006 "Finding relating to drug misuse behavior"	GET [base]/Observation? code=http://snomed.info/sct|228366006	The Receiving System gets, for each Drug Or Drug Type, the most recent version of the Drug Use that was last registered in the Sending System. This does not have to be the Drug Use that has been updated most recently. Condition: If available, the last known drug use for each Drug Or Drug Type. Cardinality: 0..*
	Alcohol Use	Search	http://snomed.info/sct 228273003 "Finding relating to alcohol drinking behavior"	GET [base]/Observation? code=http://snomed.info/sct|228273003	The Receiving System gets the most recent version of the Alcohol Consumption that was last registered in the Sending System. This does not have to be the Alcohol Consumption that has been updated most recently. Condition: If available, last known alcohol consumption. Cardinality: 0..1
	Tobacco Use	Search	http://snomed.info/sct 365980008 "Finding of tobacco use and exposure"	GET [base]/Observation? code=http://snomed.info/sct|365980008	The Receiving System gets the most recent version of the Tobacco Use that was last registered in the Sending System. This does not have to be the Tobacco Use that has been updated most recently. Condition: If available, last known tobacco use. Cardinality: 0..1
	Nutrition Advice	Search	http://snomed.info/sct 11816003 "Dietary advice"	GET [base]/Observation? code=http://snomed.info/sct|300893006 NOTE: Query 1.x is: GET [base]/NutritionOrder	The Receiving System gets, for each Diet Type, the most recent version of the Nutritional Advice that was last registered in the Sending System. This does not have to be the Nutritional Advice that has been updated most recently for each Diet Type.
8 Alerts	Alert	Read	http://loinc.org 75310-3 "Health concerns document"	GET [base]/Flag	The Receiving System gets the most recent version of all Alerts registered in the Sending System.
9 Allergies	Allergy Intolerance	Read	http://loinc.org 48765-2 "Allergies and adverse reactions document"	GET [base]/AllergyIntolerance	The Receiving System gets the most recent version of all allergies registered in the Sending System.
10 Medication	Medication Use2	Search	http://snomed.info/sct 422979000 "Medication regimen behavior finding"	GET [base]/MedicationStatement? category= urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6& _include=MedicationStatement:medication	Known medication use
	Administration Agreement	Search	http://snomed.info/sct 422037009 "Provider medication administration instructions"	GET [base]/MedicationDispense? category=http://snomed.info/sct|422037009& _include=MedicationDispense:medication	Known administration agreements
	Medication Agreement	Search	http://snomed.info/sct 16076005 "Prescription"	GET [base]/MedicationRequest? category=http://snomed.info/sct|16076005& _include=MedicationRequest:medication	Known medication agreements
11 Medical aids	Medical Device	Read	http://snomed.info/sct 49062001 "Device (physical object)" or http://loinc.org 46264-8 "Known medical aids"	GET [base]/DeviceUseStatement? _include=DeviceUseStatement:device	The Receiving System gets the most recent version of all medical aids (devices) registered in the Sending System.
12 Vaccinations	Vaccination	Read	http://loinc.org 11369-6 "History of Immunization Narrative"	GET [base]/Immunization? status=completed	The Receiving System gets the most recent version of all vaccinations registered in the Sending System.
13 Vital signs	Blood Pressure	Search	http://loinc.org 85354-9 "Blood pressure"	GET [base]/Observation/$lastn? code=http://loinc.org|85354-9	The Receiving System gets the most recent version of the blood pressure that was last registered in the Sending System. Condition: Last known blood pressure. Cardinality: 0..1
	Body Weight	Search	http://loinc.org 29463-7 "Body weight"	GET [base]/Observation/$lastn? code=http://loinc.org|29463-7	The Receiving System gets the most recent version of the body weight that was last registered in the Sending System. Condition: Last known body weight. Cardinality: 0..1
	Body Height	Search	http://loinc.org 8302-2 "Body height"	GET [base]/Observation/$lastn? code=http://loinc.org|8302-2, http://loinc.org|8306-3, http://loinc.org|8308-9	The Receiving System gets the most recent version of the body height that was last registered in the Sending System. Condition: Last known body height. Cardinality: 0..1
14 Results	Laboratory Test Result	Search	http://snomed.info/sct 15220000 "Laboratory test"	GET [base]/Observation/$lastn? category=http://snomed.info/sct|118246004& _include=Observation:related-target& _include=Observation:specimen NOTE: Query 1.x is: GET [base]/Observation/$lastn? category=http://snomed.info/sct%7C275711006& _include=Observation:related-target& _include=Observation:specimen	The Receiving System gets the most recent version of the Laboratory Test last registered for all "Laboratory" observations, per Laboratory Test Code in the Sending System. The selected laboratory tests are grouped via the Laboratory Result. The optional result Type of the Laboratory Result is not used for filtering, only the LOINC Test Code. The result Type will be sent along with the data if available. Condition: Last known test for all results. Cardinality: 0..1
15 Procedures	Procedure	Search	http://snomed.info/sct 71388002 "Procedure" or http://loinc.org 47519-4 "History of Procedures"	GET [base]/Procedure? category=http://snomed.info/sct|50731006 NOTE: Query 1.x is: GET [base]/Procedure? category=http://snomed.info/sct%7C387713003	The Receiving System gets the most recent version of all procedures registered in the Sending System. This includes all operative and diagnostic procedures, including outpatient surgeries/operations.
16 Encounters	Encounter	Search	http://loinc.org 46240-8 "History of Hospitalizations+Outpatient visits Narrative"	GET [base]/Encounter? class=http://snomed.info/sct|308335008 NOTE: Query 1.x is: GET [base]/Encounter? class=http://hl7.org/fhir/v3/ActCode%7CIMP, http://hl7.org/fhir/v3/ActCode%7CACUTE, http://hl7.org/fhir/v3/ActCode%7CNONAC	The Receiving System gets the most recent version of all contacts registered in the Sending System. This also includes outpatient contacts where the reason for the contact is an outpatient operation, such as the removal of osteosynthesis material after a bone fracture. All hospital admissions and contacts with a reference to a transaction or a problem are included. Origin and destination are not exchanged.
17 Care Setting	Healthcare Provider	Read	http://snomed.info/sct 229774002 "Caregiver"	GET [base]/CareTeam? _include=CareTeam:participant	The Receiving System gets the most recent version of all available caregivers registered in the Sending System. This includes at least the care providers with a current treatment relationship and, if available, care providers who are appointed in the contacts and operations that are controlled with the BgZ.
	Healthcare Location	Read	http://snomed.info/sct 43741000 "Site of care"	GET [base]/?????	The Receiving System gets the most recent version of all available healthcare providers registered in the Sending System. This includes at least the care providers who are appointed in the contacts and transactions that are sent with the BgZ.

Table 5.1 FHIR Task.input Query Specification

5.5 Referenced BgZ FHIR Resources

The profiles represent their entire respective HCIM, to make them applicable in a broader context than the exchange of BgZ or a MedMij context. An example of reuse of existing profiles is those of the patient administration resources and vital signs.

Section	Zib NL	HCIM EN	FHIR Resource	FHIR Profile
1	Patient	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
	BurgerlijkeStaat	MaritalStatus	Patient.maritalStatus
2	Betaler	Payer	Coverage	http://nictiz.nl/fhir/StructureDefinition/zib-Payer
			Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
			Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
3	BehandelAanwijzing	TreatmentDirective	Consent	http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective
	Wilsverklaring	AdvanceDirective	Consent	http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective
4	Contactpersoon	ContactPerson	Patient.contact	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
5	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus
6	Probleem	Problem	Condition	http://nictiz.nl/fhir/StructureDefinition/zib-Problem
7	Woonsituatie	LivingSituation	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation
	DrugsGebruik	DrugUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse
	AlcoholGebruik	AlcoholUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse
	TabakGebruik	TobaccoUse	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse
	Voedingsadvies	NutritionAdvice	NutritionOrder	http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice
8	Alert	Alert	Flag	http://nictiz.nl/fhir/StructureDefinition/zib-Alert
9	AllergieIntolerantie	AllergyIntolerance	AllergyIntolerance	http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance
10	MedicatieGebruik2	MedicationUse2	MedicationStatement	http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse
	Medicatieafspraak	MedicationAgreement	MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement
	Toedieningsafspraak	AdministrationAgreement	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement
11	MedischHulpmiddel	MedicalDevice	Device	http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct
			DeviceUseStatement	http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice
12	Vaccinatie	Vaccination	Immunization	http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination
			ImmunizationRecommendation	http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation
13	Bloeddruk	BloodPressure	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure
	LichaamsGewicht	BodyWeight	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight
	LichaamsLengte	BodyHeight	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight
14	LaboratoriumUitslag	LaboratoryTestResult	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation
			Specimen	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen
15	Verrichting	Procedure	Procedure	http://nictiz.nl/fhir/StructureDefinition/zib-Procedure
16	Contact	Encounter	Encounter	http://nictiz.nl/fhir/StructureDefinition/zib-Encounter
17	Zorgverlener	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
			PractitionerRole	http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
	Zorgaanbieder	HealthcareProvider	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
			CareTeam	http://fhir.nl/fhir/StructureDefinition/nl-core-careteam

Table 5.2 Referenced BgZ FHIR Resources

6 Infrastructure

6.1 Generic Infrastructure

The implementation guideline assumes that a generic infrastructure is available to provide for services like:

• Identification [NEN-7518] (of client and provider - who are you?)
• Authentication [NEN-7518] (establish that you really are who you say)
• Localization [NEN-7519] (where/what information known about the client and provider?)
• Consent [NEN-7517] (from the patient for the sharing of medical information)
• Authorization (what information are you allowed to access?)
• Addressing (digital address of provider or organization)
• Logging [NEN-7513] (audit trail - who did what, where, when and why?)

6.2 Expiration Time (exp) Claim

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

The value of the expiration time used in this Implementation Guide is (to be filled in).

7 References

Reference	Document Title	Date, Version, Source
[1]	Kwaliteitsstandaard - Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend Translates as “Exchange of BgZ between institutions where specialist medical care is provided”	Commentaarfase februari 2023
[2]	NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg Translates as “Exchange of BgZ between institutions for specialist medical care”	ICS 11.020.01;35.240.80 maart 2024
[3]	Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism	Version: 1.0.0 06-03-24

8 Release Notes

Changes compared to previous release.

BITS ticket	Short description
NICTIZ-14769	Ontwikkelen/schrijven van de TO in de wiki
NICTIZ-18044	BgZ-MSZ TO - review commentaren Gabriel/Iwo bijwerken
NICTIZ-18045	BgZ-MSZ TO - aanpassing ivm "Notified Pull – Hoe toe te passen in een informatiestandaard"
MSZ-139	BgZ-MSZ alpha 2.0 Technical Design Feedback