informatiestandaarden - Gebruikersbijdragen [nl]

bgz:V2.0 Technical IG BgZ MSZ

2026-05-20T11:25:46Z

Ashwin Djorai: MSZ-395: added guidance for LastN combination with revinclude

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ, [[Landingspagina_BgZ| see BgZ-MSZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ-MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ|see BgZ-MSZ main page]].

In addition, the guidelines as specified in the [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g., how to handle empty responses, etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them listed in the [[bgz:Vprepub-2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ-MSZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from Medication Process 9; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ-MSZ, it is expected that implementation guides will be modularized and that for subsets of the BgZ-MSZ, references will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ-MSZ is defined in building blocks based on the Dutch zib2017 models.
Table 3 contains an overview of all building blocks and their related FHIR profiles, including custom (BgZ-MSZ-related) FHIR profiles. Please note that every FHIR profile contains mappings towards the zib BasicElements. This is relevant since some parts of the FHIR profiles are not mapped to their associated zib (e.g., effectiveDateTime in livingSituation). The data elements of zib BasicElement are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independent of the zibs. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either zib mappings are used (e.g., NL-CM:17.2.1) or BgZ-MSZ-specific mappings are used with the prefix "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block except for MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example, a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible; see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system can make a connection to the right server that contains the patient's information. It does not provide information on finding the right server, nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
<nowiki>GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</nowiki>.

Table 4 defines the FHIR queries for all BgZ-MSZ chapters. These queries apply for both use cases: "Exchange BgZ-MSZ for Referral" and "Retrieval of BgZ-MSZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ-MSZ at Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| The medical specialist who sends BgZ-MSZ at referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-clientcapabilities|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=CapabilityStatement: Client}}
| FHIR Client requirements
|-
| Receiving Medical Specialist
| The medical specialist who receives BgZ-MSZ at referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=CapabilityStatement: Server}}
| FHIR Server requirements
|}
Table 1. Actors in the BgZ-MSZ exchange at referral.

FHIR instances for the BgZ-MSZ summary are made available at the sending system through the Notified Pull mechanism using the FHIR profiles (table 3), the definition of the ART-DECOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange using Notified Pull transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ-MSZ section is defined in Table 6.

When generating the notification message, the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange using Push transaction ===

The sending system pushes a FHIR document with the BgZ-MSZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR, where the CDA-based BgZ-MSZ is replaced by a FHIR Composition.

== Retrieval of BgZ-MSZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ-MSZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ-MSZ from a previous practitioner.

In the "Retrieval of BgZ-MSZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ-MSZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ-MSZ (at a suitable time) using the Pull Message and the search/read queries defined in table 4.

It is assumed that the Requesting Medical Specialist, as person who uses the BgZ-MSZ sharing infrastructure, is signed on, authenticated, and has authorization & consent to access the necessary (patient) information stored in the BgZ-MSZ sharing infrastructure (in other words, an authenticated healthcare professional who has an active treatment relationship with the patient).

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material, and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3 nictiz.fhir.nl.stu3.bgz, version 2.0.3]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==
The following profiles have been modified compared to zib2017. A distinction has been made between profiles with new functional additions and those with documentation additions

'''Profiles with functional additions:'''

* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Problem}}: This profile has received an addition to the data element code. This allows for the inclusion of a more specific code through specificProblemName in addition to the regular ProblemName.

'''Documentation profiles:'''

* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Patient}}: Based on nl-core-patient, with the addition that the data element generalPractitioner has a broader cardinality (0..*). If the system does not allow for the exchange of multiple general practitioners, we recommend using the {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=nl-core-patient}} profile. In the future, we will explore whether the zib2017 nl-core-patient profile can be expanded on the generalPractitioner data element.
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-FunctionalOrMentalStatus}}: The profile clarifies when the category data element “Functional Finding” or “Mental Finding” should be used. It includes a mapping for the BgZ-MSZ. It is recommended to use the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-functionalormentalstatus|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=zib-functionalormentalstatus}} profile for this purpose.
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Procedure}}: This profile clarifies how the category data element should be populated; it has been linked to a value set. It is recommended to use the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-procedure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=zib-procedure}} profile, since the category element has no binding.

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure.basedOn
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ-MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the metadata (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide metadata and the receiving system wants to receive metadata, provenance data available in the source system for a specific BgZ-MSZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{{NoteBox|Some queries using $lastN with provenance included are built with the sort and count parameters. This approach is necessary because the FHIR specification states that _revinclude is not compatible with the $lastN operation. As a result, provenance resources cannot be directly retrieved through $lastN, requiring an alternative query construction to include the related provenance information.

For example bloodpressure with the resource observation:

<pre>GET [base]Observation?code=http://loinc.org|85354-9&_sort=-date&_count=1&_revinclude=Provenance:target</pre>}}

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior, and/or psychosocial function finding’ (code = '384821006' in codeSystem 'SNOMED CT').
* please note that, as defined in the BgZ-MSZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility, and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. For legacy data, in cases where there is no Problem.ProblemStatus recorded in the source system, the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g., diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional, more specific problemName, which is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = '365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = '365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. For legacy data, in cases where there is no Symptom recorded, the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ-MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

ProcedureRequests accompanying finished Procedure resources may be included through the ‘_include=Procedure:based-on’ query. These are included to add information regarding the person or organization who requested the procedure.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ-MSZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ-MSZ components. Everything between curly braces ({}) is considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ-MSZ sections.
The coding column defines codedConcepts that identify the BgZ-MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanged as part of other BgZ-MSZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[bgz:Vprepub-2.0_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:Vprepub-2.0 Technical IG BgZ MSZ

2026-05-20T11:25:46Z

Ashwin Djorai: MSZ-395: added guidance for LastN combination with revinclude

bgz:Vissue-MSZ-395 Technical IG BgZ MSZ

2026-05-20T11:17:23Z

Ashwin Djorai: MSZ-395: added guidance for LastN combination with revinclude

{{IssuePaginaWaarschuwing|MSZ-395|bgz:V2.0_Technical_IG_BgZ_MSZ}}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ, [[Landingspagina_BgZ| see BgZ-MSZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ-MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ|see BgZ-MSZ main page]].

In addition, the guidelines as specified in the [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g., how to handle empty responses, etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them listed in the [[bgz:Vprepub-2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ-MSZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from Medication Process 9; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ-MSZ, it is expected that implementation guides will be modularized and that for subsets of the BgZ-MSZ, references will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ-MSZ is defined in building blocks based on the Dutch zib2017 models.
Table 3 contains an overview of all building blocks and their related FHIR profiles, including custom (BgZ-MSZ-related) FHIR profiles. Please note that every FHIR profile contains mappings towards the zib BasicElements. This is relevant since some parts of the FHIR profiles are not mapped to their associated zib (e.g., effectiveDateTime in livingSituation). The data elements of zib BasicElement are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independent of the zibs. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either zib mappings are used (e.g., NL-CM:17.2.1) or BgZ-MSZ-specific mappings are used with the prefix "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block except for MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example, a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible; see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system can make a connection to the right server that contains the patient's information. It does not provide information on finding the right server, nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
<nowiki>GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</nowiki>.

Table 4 defines the FHIR queries for all BgZ-MSZ chapters. These queries apply for both use cases: "Exchange BgZ-MSZ for Referral" and "Retrieval of BgZ-MSZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ-MSZ at Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| The medical specialist who sends BgZ-MSZ at referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-clientcapabilities|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=CapabilityStatement: Client}}
| FHIR Client requirements
|-
| Receiving Medical Specialist
| The medical specialist who receives BgZ-MSZ at referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=CapabilityStatement: Server}}
| FHIR Server requirements
|}
Table 1. Actors in the BgZ-MSZ exchange at referral.

FHIR instances for the BgZ-MSZ summary are made available at the sending system through the Notified Pull mechanism using the FHIR profiles (table 3), the definition of the ART-DECOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange using Notified Pull transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ-MSZ section is defined in Table 6.

When generating the notification message, the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange using Push transaction ===

The sending system pushes a FHIR document with the BgZ-MSZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR, where the CDA-based BgZ-MSZ is replaced by a FHIR Composition.

== Retrieval of BgZ-MSZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ-MSZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ-MSZ from a previous practitioner.

In the "Retrieval of BgZ-MSZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ-MSZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ-MSZ (at a suitable time) using the Pull Message and the search/read queries defined in table 4.

It is assumed that the Requesting Medical Specialist, as person who uses the BgZ-MSZ sharing infrastructure, is signed on, authenticated, and has authorization & consent to access the necessary (patient) information stored in the BgZ-MSZ sharing infrastructure (in other words, an authenticated healthcare professional who has an active treatment relationship with the patient).

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material, and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3 nictiz.fhir.nl.stu3.bgz, version 2.0.3]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==
The following profiles have been modified compared to zib2017. A distinction has been made between profiles with new functional additions and those with documentation additions

'''Profiles with functional additions:'''

* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Problem}}: This profile has received an addition to the data element code. This allows for the inclusion of a more specific code through specificProblemName in addition to the regular ProblemName.

'''Documentation profiles:'''

* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Patient}}: Based on nl-core-patient, with the addition that the data element generalPractitioner has a broader cardinality (0..*). If the system does not allow for the exchange of multiple general practitioners, we recommend using the {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=nl-core-patient}} profile. In the future, we will explore whether the zib2017 nl-core-patient profile can be expanded on the generalPractitioner data element.
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-FunctionalOrMentalStatus}}: The profile clarifies when the category data element “Functional Finding” or “Mental Finding” should be used. It includes a mapping for the BgZ-MSZ. It is recommended to use the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-functionalormentalstatus|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=zib-functionalormentalstatus}} profile for this purpose.
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Procedure}}: This profile clarifies how the category data element should be populated; it has been linked to a value set. It is recommended to use the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-procedure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=zib-procedure}} profile, since the category element has no binding.

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure.basedOn
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ-MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the metadata (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide metadata and the receiving system wants to receive metadata, provenance data available in the source system for a specific BgZ-MSZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{{NoteBox|Some queries using $lastN with provenance included are built with the sort and count parameters. This approach is necessary because the FHIR specification states that _revinclude is not compatible with the $lastN operation. As a result, provenance resources cannot be directly retrieved through $lastN, requiring an alternative query construction to include the related provenance information.

For example bloodpressure with the resource observation:

<pre>GET [base]Observation?code=http://loinc.org|85354-9&_sort=-date&_count=1&_revinclude=Provenance:target</pre>}}

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior, and/or psychosocial function finding’ (code = '384821006' in codeSystem 'SNOMED CT').
* please note that, as defined in the BgZ-MSZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility, and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. For legacy data, in cases where there is no Problem.ProblemStatus recorded in the source system, the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g., diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional, more specific problemName, which is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = '365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = '365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. For legacy data, in cases where there is no Symptom recorded, the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ-MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

ProcedureRequests accompanying finished Procedure resources may be included through the ‘_include=Procedure:based-on’ query. These are included to add information regarding the person or organization who requested the procedure.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ-MSZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ-MSZ components. Everything between curly braces ({}) is considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ-MSZ sections.
The coding column defines codedConcepts that identify the BgZ-MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanged as part of other BgZ-MSZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[bgz:Vprepub-2.0_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:Vissue-MSZ-395 Technical IG BgZ MSZ

2026-05-20T10:33:40Z

Ashwin Djorai: Clone of V2.0 production page for issue MSZ-395

{{IssuePaginaWaarschuwing|MSZ-395|bgz:V2.0_Technical_IG_BgZ_MSZ}}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ, [[Landingspagina_BgZ| see BgZ-MSZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ-MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ|see BgZ-MSZ main page]].

In addition, the guidelines as specified in the [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g., how to handle empty responses, etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them listed in the [[bgz:Vprepub-2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ-MSZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from Medication Process 9; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ-MSZ, it is expected that implementation guides will be modularized and that for subsets of the BgZ-MSZ, references will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ-MSZ is defined in building blocks based on the Dutch zib2017 models.
Table 3 contains an overview of all building blocks and their related FHIR profiles, including custom (BgZ-MSZ-related) FHIR profiles. Please note that every FHIR profile contains mappings towards the zib BasicElements. This is relevant since some parts of the FHIR profiles are not mapped to their associated zib (e.g., effectiveDateTime in livingSituation). The data elements of zib BasicElement are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independent of the zibs. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either zib mappings are used (e.g., NL-CM:17.2.1) or BgZ-MSZ-specific mappings are used with the prefix "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block except for MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example, a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible; see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system can make a connection to the right server that contains the patient's information. It does not provide information on finding the right server, nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
<nowiki>GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</nowiki>.

Table 4 defines the FHIR queries for all BgZ-MSZ chapters. These queries apply for both use cases: "Exchange BgZ-MSZ for Referral" and "Retrieval of BgZ-MSZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ-MSZ at Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| The medical specialist who sends BgZ-MSZ at referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-clientcapabilities|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=CapabilityStatement: Client}}
| FHIR Client requirements
|-
| Receiving Medical Specialist
| The medical specialist who receives BgZ-MSZ at referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=CapabilityStatement: Server}}
| FHIR Server requirements
|}
Table 1. Actors in the BgZ-MSZ exchange at referral.

FHIR instances for the BgZ-MSZ summary are made available at the sending system through the Notified Pull mechanism using the FHIR profiles (table 3), the definition of the ART-DECOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange using Notified Pull transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ-MSZ section is defined in Table 6.

When generating the notification message, the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange using Push transaction ===

The sending system pushes a FHIR document with the BgZ-MSZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR, where the CDA-based BgZ-MSZ is replaced by a FHIR Composition.

== Retrieval of BgZ-MSZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ-MSZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ-MSZ from a previous practitioner.

In the "Retrieval of BgZ-MSZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ-MSZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ-MSZ (at a suitable time) using the Pull Message and the search/read queries defined in table 4.

It is assumed that the Requesting Medical Specialist, as person who uses the BgZ-MSZ sharing infrastructure, is signed on, authenticated, and has authorization & consent to access the necessary (patient) information stored in the BgZ-MSZ sharing infrastructure (in other words, an authenticated healthcare professional who has an active treatment relationship with the patient).

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material, and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3 nictiz.fhir.nl.stu3.bgz, version 2.0.3]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==
The following profiles have been modified compared to zib2017. A distinction has been made between profiles with new functional additions and those with documentation additions

'''Profiles with functional additions:'''

* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Problem}}: This profile has received an addition to the data element code. This allows for the inclusion of a more specific code through specificProblemName in addition to the regular ProblemName.

'''Documentation profiles:'''

* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Patient}}: Based on nl-core-patient, with the addition that the data element generalPractitioner has a broader cardinality (0..*). If the system does not allow for the exchange of multiple general practitioners, we recommend using the {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=nl-core-patient}} profile. In the future, we will explore whether the zib2017 nl-core-patient profile can be expanded on the generalPractitioner data element.
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-FunctionalOrMentalStatus}}: The profile clarifies when the category data element “Functional Finding” or “Mental Finding” should be used. It includes a mapping for the BgZ-MSZ. It is recommended to use the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-functionalormentalstatus|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=zib-functionalormentalstatus}} profile for this purpose.
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}|title=BgZ-Procedure}}: This profile clarifies how the category data element should be populated; it has been linked to a value set. It is recommended to use the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-procedure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}|title=zib-procedure}} profile, since the category element has no binding.

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure.basedOn
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ-MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the metadata (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide metadata and the receiving system wants to receive metadata, provenance data available in the source system for a specific BgZ-MSZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior, and/or psychosocial function finding’ (code = '384821006' in codeSystem 'SNOMED CT').
* please note that, as defined in the BgZ-MSZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility, and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. For legacy data, in cases where there is no Problem.ProblemStatus recorded in the source system, the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g., diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional, more specific problemName, which is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = '365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = '365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. For legacy data, in cases where there is no Symptom recorded, the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ-MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

ProcedureRequests accompanying finished Procedure resources may be included through the ‘_include=Procedure:based-on’ query. These are included to add information regarding the person or organization who requested the procedure.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ-MSZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ-MSZ components. Everything between curly braces ({}) is considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ-MSZ sections.
The coding column defines codedConcepts that identify the BgZ-MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanged as part of other BgZ-MSZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[bgz:Vprepub-2.0_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:V2.0 Technical IG BgZ MSZ

2026-04-14T14:45:21Z

Ashwin Djorai: Added element for procedure.basedOn

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them in the [[bgz:V2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from medication process; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ it is expected that implementation guides will be modularized and that, for subsets of the BgZ-references, will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models).
Table 3 contains an overview of all FHIR building blocks, including custom building blocks. Please note that every FHIR profile makes use of mappings towards the baseclass HCIM BasicElements, this is relevant since some parts within a FHIR profile are not mapped in the associated HCIM profile (e.g. effectiveDateTime in livingSituation). The HCIM BasicElements are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either HCIM mappings are used (e.g., NL-CM:17.2.1) or BgZ specific mappings are used with prefix: "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block with the exception of MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333.

Table 4 defines the FHIR queries for all BgZ chapters. These queries apply for both use cases: "Exchange BgZ for Referral" and "Retrieval of BgZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ for Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| Medical specialist who sends a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-client-bgz2017.json CapabilityStatement: Client]
| FHIR Client requirements
|-
| Receiving Medical Specialist
| Medical specialist receives a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-server-bgz2017.json CapabilityStatement: Server]
| FHIR Server requirements
|}
Table 1. Actors in the BgZ exchange for referral.

FHIR instances for the BgZ summary are made available at the sending system using the profiles (table 3), the definition of the ART-DÉCOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange Using Notified Pull Transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ section is defined in Table 6.

When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange without Notified Pull Transaction ===

The sending system pushes a FHIR document with the BgZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

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.

== Retrieval of BgZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ from a previous practitioner.

In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message and the search/ read queries defined in table 4.

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

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2 nictiz.fhir.nl.stu3.bgz, version 2.0.3-beta.2]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure.basedOn
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

=== Future changes in FHIR BgZ related profiles ===
Certain BgZ related FHIR profiles are derived from zib and nl-core profiles. In future versions of the standard, BgZ profiles will possibly be replaced by their predaopt zib2020 counterparts.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the Meta Data (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide meta data and the receiving system wants to receive meta data, provenance data available in the source system for a specific BgZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

PlannedCareActivities are included through the ‘_include=Procedure:based-on’ query.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components. Everything between curly braces ({}) are considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections.
The coding column defines codedConcepts that identify the BgZ MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanges as part of other BgZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:Vprepub-2.0 Technical IG BgZ MSZ

2026-04-14T14:45:21Z

Ashwin Djorai: Added element for procedure.basedOn

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them in the [[bgz:V2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from medication process; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ it is expected that implementation guides will be modularized and that, for subsets of the BgZ-references, will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models).
Table 3 contains an overview of all FHIR building blocks, including custom building blocks. Please note that every FHIR profile makes use of mappings towards the baseclass HCIM BasicElements, this is relevant since some parts within a FHIR profile are not mapped in the associated HCIM profile (e.g. effectiveDateTime in livingSituation). The HCIM BasicElements are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either HCIM mappings are used (e.g., NL-CM:17.2.1) or BgZ specific mappings are used with prefix: "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block with the exception of MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333.

Table 4 defines the FHIR queries for all BgZ chapters. These queries apply for both use cases: "Exchange BgZ for Referral" and "Retrieval of BgZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ for Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| Medical specialist who sends a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-client-bgz2017.json CapabilityStatement: Client]
| FHIR Client requirements
|-
| Receiving Medical Specialist
| Medical specialist receives a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-server-bgz2017.json CapabilityStatement: Server]
| FHIR Server requirements
|}
Table 1. Actors in the BgZ exchange for referral.

FHIR instances for the BgZ summary are made available at the sending system using the profiles (table 3), the definition of the ART-DÉCOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange Using Notified Pull Transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ section is defined in Table 6.

When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange without Notified Pull Transaction ===

The sending system pushes a FHIR document with the BgZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

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.

== Retrieval of BgZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ from a previous practitioner.

In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message and the search/ read queries defined in table 4.

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

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2 nictiz.fhir.nl.stu3.bgz, version 2.0.3-beta.2]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure.basedOn
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

=== Future changes in FHIR BgZ related profiles ===
Certain BgZ related FHIR profiles are derived from zib and nl-core profiles. In future versions of the standard, BgZ profiles will possibly be replaced by their predaopt zib2020 counterparts.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the Meta Data (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide meta data and the receiving system wants to receive meta data, provenance data available in the source system for a specific BgZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

PlannedCareActivities are included through the ‘_include=Procedure:based-on’ query.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components. Everything between curly braces ({}) are considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections.
The coding column defines codedConcepts that identify the BgZ MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanges as part of other BgZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:V2.0 Technical IG BgZ MSZ

2026-04-14T14:07:33Z

Ashwin Djorai: Changed the canonical URL for problem, functionalormentalstatus and procedure. Added procedureRequest profile under the section of procedure.

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them in the [[bgz:V2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from medication process; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ it is expected that implementation guides will be modularized and that, for subsets of the BgZ-references, will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models).
Table 3 contains an overview of all FHIR building blocks, including custom building blocks. Please note that every FHIR profile makes use of mappings towards the baseclass HCIM BasicElements, this is relevant since some parts within a FHIR profile are not mapped in the associated HCIM profile (e.g. effectiveDateTime in livingSituation). The HCIM BasicElements are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either HCIM mappings are used (e.g., NL-CM:17.2.1) or BgZ specific mappings are used with prefix: "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block with the exception of MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333.

Table 4 defines the FHIR queries for all BgZ chapters. These queries apply for both use cases: "Exchange BgZ for Referral" and "Retrieval of BgZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ for Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| Medical specialist who sends a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-client-bgz2017.json CapabilityStatement: Client]
| FHIR Client requirements
|-
| Receiving Medical Specialist
| Medical specialist receives a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-server-bgz2017.json CapabilityStatement: Server]
| FHIR Server requirements
|}
Table 1. Actors in the BgZ exchange for referral.

FHIR instances for the BgZ summary are made available at the sending system using the profiles (table 3), the definition of the ART-DÉCOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange Using Notified Pull Transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ section is defined in Table 6.

When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange without Notified Pull Transaction ===

The sending system pushes a FHIR document with the BgZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

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.

== Retrieval of BgZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ from a previous practitioner.

In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message and the search/ read queries defined in table 4.

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

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2 nictiz.fhir.nl.stu3.bgz, version 2.0.3-beta.2]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

=== Future changes in FHIR BgZ related profiles ===
Certain BgZ related FHIR profiles are derived from zib and nl-core profiles. In future versions of the standard, BgZ profiles will possibly be replaced by their predaopt zib2020 counterparts.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the Meta Data (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide meta data and the receiving system wants to receive meta data, provenance data available in the source system for a specific BgZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

PlannedCareActivities are included through the ‘_include=Procedure:based-on’ query.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components. Everything between curly braces ({}) are considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections.
The coding column defines codedConcepts that identify the BgZ MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanges as part of other BgZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:Vprepub-2.0 Technical IG BgZ MSZ

2026-04-14T14:07:33Z

Ashwin Djorai: Changed the canonical URL for problem, functionalormentalstatus and procedure. Added procedureRequest profile under the section of procedure.

<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0}}
__TOC__

=Introduction=

This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

Furthermore, this IG requires the reader to understand and use the [https://www.twiin.nl/tanp Technical Agreement Notified Pull (TA-NP) specification].

First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.

== Known issues ==
This version of the information standard has known issues. Please find them in the [[bgz:V2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

This version of the BgZ-MSZ describes the exchange of all BgZ chapters. This includes medication-related zibs, though this version does not use the [[mp:V3.0.0_Ontwerp_medicatieproces_9#Medicamenteuze_behandeling|MBH-identifier]] from medication process; however, systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

In future versions of the BgZ it is expected that implementation guides will be modularized and that, for subsets of the BgZ-references, will be made to other information standards such as Medication Process and Lab.

In future versions the gap to the European patient summary will be addressed.

== Building blocks and FHIR profiles ==

Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models).
Table 3 contains an overview of all FHIR building blocks, including custom building blocks. Please note that every FHIR profile makes use of mappings towards the baseclass HCIM BasicElements, this is relevant since some parts within a FHIR profile are not mapped in the associated HCIM profile (e.g. effectiveDateTime in livingSituation). The HCIM BasicElements are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
Figure 1. Relations between building blocks.

== Mapping between profiles and dataset ==

Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either HCIM mappings are used (e.g., NL-CM:17.2.1) or BgZ specific mappings are used with prefix: "bgz2017-dataelement-".

Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block with the exception of MetaData, Patient, HealthProvider.

FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.

== Patient identification ==

This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333:
GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333.

Table 4 defines the FHIR queries for all BgZ chapters. These queries apply for both use cases: "Exchange BgZ for Referral" and "Retrieval of BgZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ for Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| Medical specialist who sends a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-client-bgz2017.json CapabilityStatement: Client]
| FHIR Client requirements
|-
| Receiving Medical Specialist
| Medical specialist receives a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-server-bgz2017.json CapabilityStatement: Server]
| FHIR Server requirements
|}
Table 1. Actors in the BgZ exchange for referral.

FHIR instances for the BgZ summary are made available at the sending system using the profiles (table 3), the definition of the ART-DÉCOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

=== Exchange Using Notified Pull Transaction ===

The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ section is defined in Table 6.

When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange without Notified Pull Transaction ===

The sending system pushes a FHIR document with the BgZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.

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.

== Retrieval of BgZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ
| EHR
| Electronic health record
|}
Table 2. Actors in the retrieval of the BgZ from a previous practitioner.

In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message and the search/ read queries defined in table 4.

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

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2 nictiz.fhir.nl.stu3.bgz, version 2.0.3-beta.2]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan = "2"| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion=
{{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| CareTeam
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| Provenance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|}
Table 3. FHIR Profiles used to exchange BgZ MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.

=== Future changes in FHIR BgZ related profiles ===
Certain BgZ related FHIR profiles are derived from zib and nl-core profiles. In future versions of the standard, BgZ profiles will possibly be replaced by their predaopt zib2020 counterparts.

==FHIR Query Specification==
Table 4 provides an overview of all the FHIR queries to exchange BgZ-MSZ sections with. According to the TA-NP, these will be drafted by a sending system to propose to the receiving system. If the sending system decides to, they may include the Meta Data (Provenance) by adding the parameter of the query specified in table 4. When the sending system chooses to provide meta data and the receiving system wants to receive meta data, provenance data available in the source system for a specific BgZ summary shall be exchanged according to the BgZ-metadata profile as FHIR Provenance instances. This shall be done by appending ''{_revinclude=Provenance:target}'' to the query.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>see Patient.maritalStatus</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition{?_revinclude=Provenance:target}</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder{?_revinclude=Provenance:target}</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag{?_revinclude=Provenance:target}</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication{&_revinclude=Provenance:target}</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}</pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}</pre>
|
All operative and image-guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

PlannedCareActivities are included through the ‘_include=Procedure:based-on’ query.
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter{?_revinclude=Provenance:target}</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
| <pre>GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
| <pre>GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
| <pre>see Procedure.performer
see Encounter.serviceProvider</pre>
|
Providers are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components. Everything between curly braces ({}) are considered optional.

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections.
The coding column defines codedConcepts that identify the BgZ MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| http://loinc.org/79191-3
|-
| 1.2 Marital status
| Data are exchanged as part of the patient.
|-
| 2 Financial information
| 2.1 Payer
| http://loinc.org/48768-6
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| http://snomed.info/sct/11291000146105
|-
| 3.2 Advance directive
| http://snomed.info/sct/11341000146107
|-
| 4 Contact persons
| 4.1 Contact
| Data are exchanged as part of the patient.
|-
| 5 Functional/mental status
| 5.1 Functional or mental status
| http://loinc.org/47420-5
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| http://loinc.org/11450-4
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| http://snomed.info/sct/365508006
|-
| 7.2 Drug Use
| http://snomed.info/sct/228366006
|-
| 7.3 Alcohol Use
| http://snomed.info/sct/228273003
|-
| 7.4 Tobacco Use
| http://snomed.info/sct/365980008
|-
| 7.5 Nutrition Advice
| http://snomed.info/sct/11816003
|-
| 8 Alerts
| 8.1 Alert
| http://loinc.org/75310-3
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| http://loinc.org/48765-2
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| http://snomed.info/sct/16076005
|-
| 10.2 Administration Agreement
| http://snomed.info/sct/422037009
|-
| 10.3 Medication Use
| http://snomed.info/sct/422979000
|-
| 11 Medical devices
| 11.1 Medical device
| http://loinc.org/46264-8
|-
| 12 Vaccinations
| 12.1 Vaccination
| http://loinc.org/11369-6
|-
| rowspan="3" | 13 vital signs and measurements
| 13.1 Blood pressure
| http://loinc.org/85354-9
|-
| 13.2 Body weight
| http://loinc.org/29463-7
|-
| 13.3 Body height
| http://loinc.org/8302-2
|-
| 14 Results
| 14.1 Laboratory test result
| http://snomed.info/sct/15220000
|-
| 15 Procedures
| 15.1 Procedure
| http://loinc.org/47519-4
|-
| 16 Encounters
| 16.1 Encounter
| http://loinc.org/46240-8
|-
| 17 Planned care activity
| 17.1 Procedure
| http://loinc.org/18776-5
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| http://snomed.info/sct/229774002
|-
| 18.2 Healthcare provider
| Data are exchanges as part of other BgZ components.
|-
| Meta data
| Meta data
| http://snomed.info/sct/257733005
|-
|}
Table 5. FHIR Task.input Query Specification.

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| HCIM || Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIM]) or Zorginformatiebouwstenen ([https://zibs.nl/wiki/Hoofdpagina ZIB]'s) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
|-
|}
Table 6. Glossary.

= Release notes =
Please find the release notes on the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

qa:Template TO

2025-07-02T08:28:05Z

Ashwin Djorai: /* Frequently asked questions (not part of template chapters) */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO. 
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>.

'''Example BgZ-MSZ 2.0 FHIR STU3:''' 
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations (e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [expand/collapse]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>
GET [base]/Patient?
_include=Patient:general-practitioner
</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>
see Patient.maritalStatus
</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.category is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.category is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228273003</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.category is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.category is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?
category=http://snomed.info/sct|16076005&
_include=MedicationRequest:medication</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?
category=http://snomed.info/sct|422037009&
_include=MedicationDispense:medication</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|8302-2,
http://loinc.org|8306-3,
http://loinc.org|8308-9 </pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?
category=http://snomed.info/sct|49581000146104
&_include=Observation:related-target</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?
category=http://snomed.info/sct|387713003,
http://snomed.info/sct|258174001</pre>
|
All operative and image guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedure are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image guided procedures are exchanged via an instance where the Procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category that the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
|
<pre>
GET [base]/ProcedureRequest?status=active
</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
|
<pre>
GET [base]/CareTeam?status=active&_include=CareTeam:participant
</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
|
<pre>
see Procedure.performer
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | Meta data
|-
| <pre>GET [base]/Provenance</pre>
|
All provenance data available in the source system for a specific BgZ summary is exchanged as FHIR provenance instances according to the BgZ-metadata profile.
|-
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components.
</div>

==== Search parameters ====

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet. 

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO). 
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?'' 
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?'' 
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-06-26T10:36:34Z

Ashwin Djorai: /* Boundaries & relationships */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical specification, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO. 
The template is annotated by the following:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

'''Goal:''' The Guidance chapter is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>.

'''Example BgZ-MSZ 2.0 FHIR STU3:''' 
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [Link-to-FO | FO (in Dutch)].

== Boundaries & relationships ==

'''Goal:''' In this chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Workflows & transactions ==

'''Goal:'''
To show the reader which special workflows they should implement. Most of the information regarding workflows should be available in the FO. The only information relevant here are regarding special implementations of these workflows such as the Notified Pull. This should also include a diagram of the workflow for specific actors.

<div class="mw-collapsible mw-collapsed">
'''Long example eOverdracht, FHIR STU3 (click to expand):'''
<div class="mw-collapsible-content">
===Workflow and message structure===

====Overview====
Although the eOverdracht is currently limited to the transfer of the nursing handoff, the ultimate vision is to have a workflow which may include the negotiation of the transfer of the patient. For this reason, a Task resource is used as the entry point for all data exchanges (see [[#Use of the Composition resource]]).

====Task====
=====Task requirements=====
The requirements for the Task resource in the eOverdracht context are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=eOverdracht-Task}} profile. This profile SHALL be used for the eOverdracht workflow.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task (see [[#Notifications]]), but the receiving XIS could use a polling mechanism as well.

For each combination of sending and receiving XIS, a dedicated instance of the Task resource SHALL be used for each transfer situation.

=====Task invocations=====
The receiving XIS can query the Task at the sending XIS by using the {{fhir|Task.id}} which is communicated in the [[#Notifications|notification]]:
GET base/Task/[Task.id]

'''Note''': It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:

PUT base/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with a HTTP 422 status code and an OperationOutcome detailing the problem.

=====Notifications=====
It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the {{fhir|Task.id}} to the receiving XIS.

A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request combined with an authorization header on a pre-determined endpoint at the party that should be notified, with the {{fhir|Task.id}} appended as path component:
POST [base]/[Task.id]

The notified party is expected to respond with HTTP status code ''202 Accepted'' to inform the notifying party that the notification was successfully received.

====Use of the Composition resource====

The nursing handoff (Overdrachtsbericht) is mainly built up of individual FHIR resources, selected by the sending organization to form a coherent set of information relevant to the receiving organization. The bulk of these resources are not referenced directly from [[#Task|the Task]]. Instead, the Task references a Composition resource which in turn assembles the references to all individual FHIR resources. For this purpose, the Composition profiles described in [[#FHIR profiles]] SHALL be used.

=====Composition invocations=====
The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.
; As a Document: The receiving XIS uses the {{fhir|$document}} operation to retrieve both the Composition ''and'' all referenced resources as a single document Bundle. <pre>GET [base]/Composition/[Composition.id]/$document</pre>''Note:'' the Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.
; Individual requests: The receiving XIS first retrieves the Composition resource <pre>GET [base]/Compositon/[Composition.id]</pre>Then the necessary other resources referenced can be fetched using a <code>GET</code> interaction.

The sending XIS SHALL support both mechanisms.

=====Exchanging data as unstructured text=====

The information standard requires that all information described is exchanged in a structured way, according to the FHIR profiles described on this page. However, some systems are not able to support the full extent of the standard yet and may need to send part of the data as formatted text. The following implementation advice provides guidance on how systems with such a need may accomplish this exchange.

* All unstructured (textual data) is collected in one single PDF/A document.
* This document is added to the Composition resource representing the nursing handoff, in the following way:
** An additional {{fhir|Composition.section}} is created, with {{fhir|.section.code}} set to SNOMED CT/{{term|703852005}} (Narrative comment section).
** In this section, there is a single {{fhir|.section.entry}}, and it refers to a [http://hl7.org/fhir/stu3/documentreference.html DocumentReference] resource.
** This DocumentReference resource references the PDF/A document containing the unstructured text.

The use of the DocumentReference resource allows the sender to specify additional metadata about the document, if needed. It also prevents that the PDF/A is directly included when the Composition is requested using the {{fhir|$document}} operation, which could lead to unexpected large data volumes.

====Using Task to manage the workflow====
The Task is the main entry point for the eOverdracht transactions. The eOverdracht workflow starts with the retrieval of a new Task instance by the receiving XIS, and all subsequent steps in the workflow are mediated by updates to this Task instance.

The eOverdracht transactions are mapped to FHIR in the following way:

{| class="wikitable"
! colspan=2 | eOverdracht transaction
! Task
|-
| colspan="2" | Confirm transfer
|
* sending XIS updates Task:
** {{fhir|Task.status}} = {{term|in-progress}}
* (sending XIS sends notification to receiving XIS)
|-
| colspan=2 | Send nursing handoff
|
* Sending XIS creates nursing handoff Composition
* Sending XIS updates Task:
** {{fhir|Task.input:nursingHandoff}} contains reference to the nursing handoff Composition resource
* (sending XIS sends notification to receiving XIS)
|-
| colspan=2 | Send confirmation of nursing handoff
|
* Recieving XIS updates Task:
** {{fhir|Task.status}} = {{term|completed}}
|}
The following sequence diagrams illustrate the relevant exchanges and state transitions:
{| class="wikitable"
!Normal flow
|- style="vertical-align: top;"
| [[Bestand:2024-04-12-eOverdracht-TransferPhase.svg|none|top]]
|}
The initial eOverdracht 4.0 version has to be carried out without the negotiation phase, the sending XIS will create the Task instance with {{fhir|Task.status}} already set to {{term|in-progress}} and {{fhir|Task.input:nursingHandoff}} populated. The full eOverdracht Task workflow will be supported but is out of scope for the 4.0 version.

=====Brokers=====
The use of a broker to find an available healthcare provider for the patient transfer fall outside the scope of the eOverdracht information standard. However, it is possible to start the workflow without knowing the receiving organization, which allows for the use of a broker. In this situation, for the sending XIS the broker acts as a receiving XIS, and for the receiving XIS the broker acts as a sending XIS.

When {{fhir|Task.input:nursingHandoff}} is populated with the nursing handoff Composition, {{fhir|Task.owner}} MUST be populated with the receiving organization.
</div></div>

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
|
|
|
|
|
|
|}

'''Example LaboratoryResults 2.0.42:'''
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

== Use cases ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is a full data exchange message (applicable to multiple use cases). A use case should include information about the (earlier specified) involved actors. It should also include information regarding the specific transaction and the available invocations (e.g., FHIR queries).

=== <Use case 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|-
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

<div class="mw-collapsible mw-collapsed">
'''Example BgZ-MSZ 2.0 STU3: (click to expand):'''
<div class="mw-collapsible-content">
==FHIR Query Specification==
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>
GET [base]/Patient?
_include=Patient:general-practitioner
</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>
see Patient.maritalStatus
</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.category is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.category is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228273003</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.category is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.category is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?
category=http://snomed.info/sct|16076005&
_include=MedicationRequest:medication</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?
category=http://snomed.info/sct|422037009&
_include=MedicationDispense:medication</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|8302-2,
http://loinc.org|8306-3,
http://loinc.org|8308-9 </pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?
category=http://snomed.info/sct|49581000146104
&_include=Observation:related-target</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?
category=http://snomed.info/sct|387713003,
http://snomed.info/sct|258174001</pre>
|
All operative and image guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedure are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image guided procedures are exchanged via an instance where the Procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category that the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
|
<pre>
GET [base]/ProcedureRequest?status=active
</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
|
<pre>
GET [base]/CareTeam?status=active&_include=CareTeam:participant
</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
|
<pre>
see Procedure.performer
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | Meta data
|-
| <pre>GET [base]/Provenance</pre>
|
All provenance data available in the source system for a specific BgZ summary is exchanged as FHIR provenance instances according to the BgZ-metadata profile.
|-
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components.
</div></div>

=== <Use case 2> ===
==== Involved actors ====
==== Invocations ====

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA) and HL7v2 are not supported yet. 

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO). 
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included. BgZ-MSZ 2.0 example: [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Release notes (Not part of the template) ==
Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-06-26T10:36:12Z

Ashwin Djorai: /* Boundaries & relationships */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}



<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
__TOC__
__TOC__



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical specification, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO. 
The template is annotated by the following:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

'''Goal:''' The Guidance chapter is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>.

'''Example BgZ-MSZ 2.0 FHIR STU3:''' 
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [Link-to-FO | FO (in Dutch)].

== Boundaries & relationships ==

Goal: In this chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Workflows & transactions ==

'''Goal:'''
To show the reader which special workflows they should implement. Most of the information regarding workflows should be available in the FO. The only information relevant here are regarding special implementations of these workflows such as the Notified Pull. This should also include a diagram of the workflow for specific actors.

<div class="mw-collapsible mw-collapsed">
'''Long example eOverdracht, FHIR STU3 (click to expand):'''
<div class="mw-collapsible-content">
===Workflow and message structure===

====Overview====
Although the eOverdracht is currently limited to the transfer of the nursing handoff, the ultimate vision is to have a workflow which may include the negotiation of the transfer of the patient. For this reason, a Task resource is used as the entry point for all data exchanges (see [[#Use of the Composition resource]]).

====Task====
=====Task requirements=====
The requirements for the Task resource in the eOverdracht context are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=eOverdracht-Task}} profile. This profile SHALL be used for the eOverdracht workflow.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task (see [[#Notifications]]), but the receiving XIS could use a polling mechanism as well.

For each combination of sending and receiving XIS, a dedicated instance of the Task resource SHALL be used for each transfer situation.

=====Task invocations=====
The receiving XIS can query the Task at the sending XIS by using the {{fhir|Task.id}} which is communicated in the [[#Notifications|notification]]:
GET base/Task/[Task.id]

'''Note''': It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:

PUT base/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with a HTTP 422 status code and an OperationOutcome detailing the problem.

=====Notifications=====
It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the {{fhir|Task.id}} to the receiving XIS.

A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request combined with an authorization header on a pre-determined endpoint at the party that should be notified, with the {{fhir|Task.id}} appended as path component:
POST [base]/[Task.id]

The notified party is expected to respond with HTTP status code ''202 Accepted'' to inform the notifying party that the notification was successfully received.

====Use of the Composition resource====

The nursing handoff (Overdrachtsbericht) is mainly built up of individual FHIR resources, selected by the sending organization to form a coherent set of information relevant to the receiving organization. The bulk of these resources are not referenced directly from [[#Task|the Task]]. Instead, the Task references a Composition resource which in turn assembles the references to all individual FHIR resources. For this purpose, the Composition profiles described in [[#FHIR profiles]] SHALL be used.

=====Composition invocations=====
The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.
; As a Document: The receiving XIS uses the {{fhir|$document}} operation to retrieve both the Composition ''and'' all referenced resources as a single document Bundle. <pre>GET [base]/Composition/[Composition.id]/$document</pre>''Note:'' the Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.
; Individual requests: The receiving XIS first retrieves the Composition resource <pre>GET [base]/Compositon/[Composition.id]</pre>Then the necessary other resources referenced can be fetched using a <code>GET</code> interaction.

The sending XIS SHALL support both mechanisms.

=====Exchanging data as unstructured text=====

The information standard requires that all information described is exchanged in a structured way, according to the FHIR profiles described on this page. However, some systems are not able to support the full extent of the standard yet and may need to send part of the data as formatted text. The following implementation advice provides guidance on how systems with such a need may accomplish this exchange.

* All unstructured (textual data) is collected in one single PDF/A document.
* This document is added to the Composition resource representing the nursing handoff, in the following way:
** An additional {{fhir|Composition.section}} is created, with {{fhir|.section.code}} set to SNOMED CT/{{term|703852005}} (Narrative comment section).
** In this section, there is a single {{fhir|.section.entry}}, and it refers to a [http://hl7.org/fhir/stu3/documentreference.html DocumentReference] resource.
** This DocumentReference resource references the PDF/A document containing the unstructured text.

The use of the DocumentReference resource allows the sender to specify additional metadata about the document, if needed. It also prevents that the PDF/A is directly included when the Composition is requested using the {{fhir|$document}} operation, which could lead to unexpected large data volumes.

====Using Task to manage the workflow====
The Task is the main entry point for the eOverdracht transactions. The eOverdracht workflow starts with the retrieval of a new Task instance by the receiving XIS, and all subsequent steps in the workflow are mediated by updates to this Task instance.

The eOverdracht transactions are mapped to FHIR in the following way:

{| class="wikitable"
! colspan=2 | eOverdracht transaction
! Task
|-
| colspan="2" | Confirm transfer
|
* sending XIS updates Task:
** {{fhir|Task.status}} = {{term|in-progress}}
* (sending XIS sends notification to receiving XIS)
|-
| colspan=2 | Send nursing handoff
|
* Sending XIS creates nursing handoff Composition
* Sending XIS updates Task:
** {{fhir|Task.input:nursingHandoff}} contains reference to the nursing handoff Composition resource
* (sending XIS sends notification to receiving XIS)
|-
| colspan=2 | Send confirmation of nursing handoff
|
* Recieving XIS updates Task:
** {{fhir|Task.status}} = {{term|completed}}
|}
The following sequence diagrams illustrate the relevant exchanges and state transitions:
{| class="wikitable"
!Normal flow
|- style="vertical-align: top;"
| [[Bestand:2024-04-12-eOverdracht-TransferPhase.svg|none|top]]
|}
The initial eOverdracht 4.0 version has to be carried out without the negotiation phase, the sending XIS will create the Task instance with {{fhir|Task.status}} already set to {{term|in-progress}} and {{fhir|Task.input:nursingHandoff}} populated. The full eOverdracht Task workflow will be supported but is out of scope for the 4.0 version.

=====Brokers=====
The use of a broker to find an available healthcare provider for the patient transfer fall outside the scope of the eOverdracht information standard. However, it is possible to start the workflow without knowing the receiving organization, which allows for the use of a broker. In this situation, for the sending XIS the broker acts as a receiving XIS, and for the receiving XIS the broker acts as a sending XIS.

When {{fhir|Task.input:nursingHandoff}} is populated with the nursing handoff Composition, {{fhir|Task.owner}} MUST be populated with the receiving organization.
</div></div>

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
|
|
|
|
|
|
|}

'''Example LaboratoryResults 2.0.42:'''
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-clientcapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

== Use cases ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is a full data exchange message (applicable to multiple use cases). A use case should include information about the (earlier specified) involved actors. It should also include information regarding the specific transaction and the available invocations (e.g., FHIR queries).

=== <Use case 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|-
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|style="vertical-align:top;"|
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

<div class="mw-collapsible mw-collapsed">
'''Example BgZ-MSZ 2.0 STU3: (click to expand):'''
<div class="mw-collapsible-content">
==FHIR Query Specification==
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <pre>
GET [base]/Patient?
_include=Patient:general-practitioner
</pre>
|
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! colspan="2" style="text-align: left;" | 1.2 Marital status
|-
|
<pre>
see Patient.maritalStatus
</pre>
|
Marital status data are exchanged via the patient resource (see 1.1).
|-
! colspan="2" style="text-align: left;" | 2 Financial information
|-
! colspan="2" style="text-align: left;" | 2.1 Payer
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 3.2 Advance directive
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
* the document is only exchanged via a pdf.
|-
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
|-
! colspan="2" style="text-align: left;" | 4.1 Contact
|-
| <pre>Patient.contact</pre>
|
Primary partner/contact data are exchanged via the patient resource (see 1.1).
|-
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
|-
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
|-
! colspan="2" style="text-align: left;" | 6.1 Problem
|-
| <pre>GET [base]/Condition</pre>
|
All problems available in the source system are returned as zib-Problem instances.
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.category is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.category is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! colspan="2" style="text-align: left;" | 7.3 Alcohol Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228273003</pre>
|
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
* The Observation.category is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.category is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder</pre>
|
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
|-
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
|-
! colspan="2" style="text-align: left;" | 8.1 Alert
|-
| <pre>GET [base]/Flag</pre>
|
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
|-
! colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<pre>
"manifestation":{
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}]
},
</pre>
|-
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
|-
! colspan="2" style="text-align: left;" | 10.1 Medication Agreement
|-
| <pre>GET [base]/MedicationRequest?
category=http://snomed.info/sct|16076005&
_include=MedicationRequest:medication</pre>
|
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.2 Administration Agreement
|-
| <pre>GET [base]/MedicationDispense?
category=http://snomed.info/sct|422037009&
_include=MedicationDispense:medication</pre>
|
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! colspan="2" style="text-align: left;" | 10.3 Medication Use
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
|-
! colspan="2" style="text-align: left;" | 12.1 Vaccination
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
|-
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
|-
! colspan="2" style="text-align: left;" | 13.1 Blood pressure
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.2 Body weight
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! colspan="2" style="text-align: left;" | 13.3 Body height
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|8302-2,
http://loinc.org|8306-3,
http://loinc.org|8308-9 </pre>
|
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
* The Observation.effectiveDateTime is used to determine the last known Observation.
|-
! scope="row" colspan="2" style="text-align: left;" | 14 Results
|-
! colspan="2" style="text-align: left;" | 14.1 Laboratory test result
|-
| <pre>GET [base]/Observation/$lastn?
category=http://snomed.info/sct|49581000146104
&_include=Observation:related-target</pre>
|
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
* The optional ResultType is not used when selecting Laboratory results for exchange.
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
|-
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
|-
! colspan="2" style="text-align: left;" | 15.1 Procedure
|-
| <pre>GET [base]/Procedure?
category=http://snomed.info/sct|387713003,
http://snomed.info/sct|258174001</pre>
|
All operative and image guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
* Surgical procedure are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image guided procedures are exchanged via an instance where the Procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category that the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).
|-
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
|-
! colspan="2" style="text-align: left;" | 16.1 Encounter
|-
| <pre>GET [base]/Encounter</pre>
|
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
|-
! colspan="2" style="text-align: left;" | 17.1 Procedure
|-
|
<pre>
GET [base]/ProcedureRequest?status=active
</pre>
|
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
|-
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
|-
! colspan="2" style="text-align: left;" | 18.1 Health professional
|-
|
<pre>
GET [base]/CareTeam?status=active&_include=CareTeam:participant
</pre>
|
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
|-
! colspan="2" style="text-align: left;" | 18.2 Healthcare provider
|-
|
<pre>
see Procedure.performer
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | Meta data
|-
| <pre>GET [base]/Provenance</pre>
|
All provenance data available in the source system for a specific BgZ summary is exchanged as FHIR provenance instances according to the BgZ-metadata profile.
|-
|}
Table 4. FHIR queries used to retrieve BgZ MSZ components.
</div></div>

=== <Use case 2> ===
==== Involved actors ====
==== Invocations ====

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA) and HL7v2 are not supported yet. 

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO). 
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included. BgZ-MSZ 2.0 example: [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Release notes (Not part of the template) ==
Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-06-20T08:46:10Z

Ashwin Djorai: /* FHIR artifacts */

qa:Template TO

2025-06-20T08:40:08Z

Ashwin Djorai: /* FHIR artifacts */

vpk:V4.1 FHIR eOverdracht

2025-06-04T12:33:15Z

Ashwin Djorai: NICTIZ-31752: Added AbilityToGroome profile link in the table

__NOINDEX__
{{DISPLAYTITLE:eOverdracht {{VersieInfo|eOverdracht|release=V4.1}} FHIR Implementation Guide}}
__NUMBEREDHEADINGS__
=Introduction=

This is the implementation guide for the information standard eOverdracht, version 4.1. This standard is described in [[vpk:V4.1_Ontwerp eOverdracht|this functional specification]] and implemented here using [https://www.hl7.org/fhir/stu3/ FHIR(STU3) HL7 FHIR, STU3]. This implementation guide assumes that the reader is familiar with this FHIR version.

Apart from this document, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|Use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=Actors involved=
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.1}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.1}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

=Workflow and message structure=

==Overview==
Although the eOverdracht is currently limited to the transfer of the nursing handoff, the ultimate vision is to have a workflow which may include the negotiation of the transfer of the patient. For this reason, a Task resource is used as the entry point for all data exchanges (see [[#Use of the Composition resource]]).

==Task==
===Task requirements===
The requirements for the Task resource in the eOverdracht context are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task|nictiz.fhir.nl.stu3.eOverdracht|eOverdracht-Task|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.1}}}} profile. This profile SHALL be used for the eOverdracht workflow.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task (see [[#Notifications]]), but the receiving XIS could use a polling mechanism as well.

For each combination of sending and receiving XIS, a dedicated instance of the Task resource SHALL be used for each transfer situation.

===Task invocations===
The receiving XIS can query the Task at the sending XIS by using the {{fhir|Task.id}} which is communicated in the [[#Notifications|notification]]:
GET base/Task/[Task.id]

'''Note''': It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:

PUT base/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with a HTTP 422 status code and an OperationOutcome detailing the problem.

===Notifications===
It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the {{fhir|Task.id}} to the receiving XIS.

A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request combined with an authorization header on a pre-determined endpoint at the party that should be notified, with the {{fhir|Task.id}} appended as path component:
POST [base]/[Task.id]

The notified party is expected to respond with HTTP status code ''202 Accepted'' to inform the notifying party that the notification was successfully received.

==Use of the Composition resource==

The nursing handoff (Overdrachtsbericht) is mainly built up of individual FHIR resources, selected by the sending organization to form a coherent set of information relevant to the receiving organization. The bulk of these resources are not referenced directly from [[#Task|the Task]]. Instead, the Task references a Composition resource which in turn assembles the references to all individual FHIR resources. For this purpose, the Composition profiles described in [[#FHIR profiles]] SHALL be used.

===Composition invocations===
The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.
; As a Document: The receiving XIS uses the {{fhir|$document}} operation to retrieve both the Composition ''and'' all referenced resources as a single document Bundle. <pre>GET [base]/Composition/[Composition.id]/$document</pre>''Note:'' the Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.
; Individual requests: The receiving XIS first retrieves the Composition resource <pre>GET [base]/Compositon/[Composition.id]</pre>Then the necessary other resources referenced can be fetched using a <code>GET</code> interaction.

The sending XIS SHALL support both mechanisms.

===Exchanging data as unstructured text===

The information standard requires that all information described is exchanged in a structured way, according to the FHIR profiles described on this page. However, some systems are not able to support the full extent of the standard yet and may need to send part of the data as formatted text. The following implementation advice provides guidance on how systems with such a need may accomplish this exchange.

* All unstructured (textual data) is collected in one single PDF/A document.
* This document is added to the Composition resource representing the nursing handoff, in the following way:
** An additional {{fhir|Composition.section}} is created, with {{fhir|.section.code}} set to SNOMED CT/{{term|703852005}} (Narrative comment section).
** In this section, there is a single {{fhir|.section.entry}}, and it refers to a [http://hl7.org/fhir/stu3/documentreference.html DocumentReference] resource.
** This DocumentReference resource references the PDF/A document containing the unstructured text.

The use of the DocumentReference resource allows the sender to specify additional metadata about the document, if needed. It also prevents that the PDF/A is directly included when the Composition is requested using the {{fhir|$document}} operation, which could lead to unexpected large data volumes.

==Using Task to manage the workflow==
The Task is the main entry point for the eOverdracht transactions. The eOverdracht workflow starts with the retrieval of a new Task instance by the receiving XIS, and all subsequent steps in the workflow are mediated by updates to this Task instance.

The eOverdracht transactions are mapped to FHIR in the following way:

{| class="wikitable"
! colspan=2 | eOverdracht transaction
! Task
|-
| colspan="2" | Confirm transfer
|
* sending XIS updates Task:
** {{fhir|Task.status}} = {{term|in-progress}}
* (sending XIS sends notification to receiving XIS)
|-
| colspan=2 | Send nursing handoff
|
* Sending XIS creates nursing handoff Composition
* Sending XIS updates Task:
** {{fhir|Task.input:nursingHandoff}} contains reference to the nursing handoff Composition resource
* (sending XIS sends notification to receiving XIS)
|-
| colspan=2 | Send confirmation of nursing handoff
|
* Recieving XIS updates Task:
** {{fhir|Task.status}} = {{term|completed}}
|}
The following sequence diagrams illustrate the relevant exchanges and state transitions:
{| class="wikitable"
!Normal flow
|- style="vertical-align: top;"
| [[Bestand:2024-04-12-eOverdracht-TransferPhase.svg|none|top]]
|}
The initial eOverdracht 4.1 version has to be carried out without the negotiation phase, the sending XIS will create the Task instance with {{fhir|Task.status}} already set to {{term|in-progress}} and {{fhir|Task.input:nursingHandoff}} populated. The full eOverdracht Task workflow will be supported but is out of scope for the 4.1 version.

===Brokers===
The use of a broker to find an available healthcare provider for the patient transfer fall outside the scope of the eOverdracht information standard. However, it is possible to start the workflow without knowing the receiving organization, which allows for the use of a broker. In this situation, for the sending XIS the broker acts as a receiving XIS, and for the receiving XIS the broker acts as a sending XIS.

When {{fhir|Task.input:nursingHandoff}} is populated with the nursing handoff Composition, {{fhir|Task.owner}} MUST be populated with the receiving organization.

=FHIR profiles=
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.1}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==Example resources==
Examples for the profiles above can be found in the FHIR packages [[#FHIR profiles|defined above]]. Additionally, instances for the [[vpk:V4.1_Testen|test scenarios]] can be found on [https://github.com/Nictiz/Nictiz-testscripts/tree/main/src/eOverdracht-4-1/Test/_reference/resources Github].

==Infrastructure profiles==
The following table lists the FHIR profiles that should be used for the infrastructural parts of the eOverdracht information standard. The mapping to the functional data elements is given using the mapping within these profiles.
{| class="wikitable"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | HCIM Name
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | FHIR profile
|-
| eOverdracht Task
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.1}}}}
|-
| Composition for nursing handoff adults (Overdrachtsbericht volwassenen)
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Adults|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.1}}}}
|}

==HCIM profiles==
The following table lists the FHIR profiles that implement the HCIMs used within eOverdracht.
{| class="wikitable"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | HCIM Name
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | FHIR profile
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | Remark
|-
| Alert
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Betaler
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Bloeddruk
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Contactpersoon
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-relatedperson|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Datum overplaatsing
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-TransferDate|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Gezinssituatie
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FamilySituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Lichaamsgewicht
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Lichaamslengte
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Probleem
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Voedingsadvies
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| VermogenTotUiterlijkeVerzorging
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AbilityToGroome|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Wilsverklaring
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Woonsituatie
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| Zorgaanbieder
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|
|-
| rowspan="2" | Zorgverlener
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
| rowspan="2" |
|-
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V4.1}}}}
|}

vpk:Vprepub-4.1 FHIR eOverdracht

2025-06-04T12:33:15Z

Ashwin Djorai: NICTIZ-31752: Added AbilityToGroome profile link in the table

MedMij:V6/FHIR Patient Corrections

2023-10-23T07:52:36Z

Ashwin Djorai: MM-4961: The hyperlink in section 4.1 has been updated to chapter 5 FHIR profiles.

__NOINDEX__

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide: Patient Corrections {{VersieInfo|Dossierwijzigingsverzoek|release=V6}}}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]

=Introduction=
This page describes the process of filing correction requests on medical records. A correction request is initiated by a patient on an existing medical record and received by a healthcare provider.

This information standard is inspired by the international [https://build.fhir.org/ig/HL7/fhir-patient-correction/index.html HL7 Patient Corrections IG]. However, the first version of this information standard is more restricted than Patient Corrections; specifically, the possibility of doing follow-up on a correction request is omitted. Also, contrary to most other use cases for MedMij, no specific HCIM model has been identified for exchanging communication between patient (PHR) and practitioner (XIS).

This IG is a technical representation of the [[MedMij:Vprepub-6/OntwerpDossierwijzigingsverzoek|functional design]] and follows the principles of the general [[MedMij:IG:V1/FHIR_IG|MedMij FHIR IG]].

=Actors involved=
The table shows the relevant actors, systems and FHIR CapabilityStatements. The CapabilityStatements demonstrate the minimum conformance requirements for the described use cases.

{| class="wikitable"
! colspan="2" style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | Actors
! colspan="2" style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | FHIR CapabilityStatements
|-
! style="text-align:left; |Name
! style="text-align:left; |Description
! style="text-align:left; |Name
! style="text-align:left; |Description
! style="text-align:left; |Name
! style="text-align:left; |Description
|-
| Patient
| The user of a personal healthcare environment
| PHR
| Personal health record
* sends a PatientCorrectionsCommunication
* receives a confirmation of receipt (OperationOutcome)
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/dwv-SendReceive|nictiz.fhir.nl.r4.patientcorrections|title=CapabilityStatement: Send Receive}}
| rowspan="2" | FHIR client/server requirements
|-
| Healthcare provider
| The user of a XIS
| XIS
| Healthcare information system
* receives a PatientCorrectionsCommunication
* returns a confirmation of receipt (OperationOutcome)
|}

=Boundaries and relationships=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

This FHIR implementation guide assumes that the PHR system is able to make a connection with the XIS and create resources. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the [https://www.medmij.nl/afsprakenstelsel/ 'MedMij Afsprakenstelsel'].

The MedMij use case for Patient Corrections overlaps partially with the uses cases described in the [https://build.fhir.org/ig/HL7/fhir-patient-correction/index.html HL7 Patient Corrections IG]. Therefore, this IG tries to align as closely as possible to the HL7 Patient Corrections IG. However, there are key differences that prevent the verbatim use:
* The current use case is more restricted.
* The profiles for the MedMij use case reference HCIM based profiles for common resources like Patient, Practitioner, PractitionerRole and Organization.
* This IG uses the OperationOutcome resource as a confirmation of receipt.
* The use case specific FHIR profiles (like Communication) are not derived but copied in order for them to align with other FHIR materials in the Dutch realm.
* {{fhir|mustSupport}} flags are not used in this IG.
* {{fhir|Bundle.type}}={{term|transaction}} and {{term|transaction-response}} are used instead of {{fhir|Bundle.type}}={{term|collection}}.

=Use case: send correction request on medical record=
This use case covers the process of sending a correction request on an existing medical record. Other use cases might be added in the future.

==Client sends PatientCorrectionsCommunication - PHR==
Because sending a correction request can consist of (one or more) Communication resource(s) along with supporting resources, a [https://www.hl7.org/fhir/http.html#transaction {{fhir|transaction}} interaction] is used. This allows for creating a set of resources in a single interaction and makes it possible to [[MedMij:IG:V1/FHIR_IG#Including_.22secondary.22_resources_when_sending_information|include referenced secondary resources]] if needed. Querying resources on the server before submitting the transaction Bundle (for instance: to be able to reference a Patient resource on the server) is not part of this FHIR IG, nor is it required that a client is able to reuse previously requested resources from use cases outside this IG.

A {{fhir|transaction}} interaction is performed by an HTTP POST command as shown:

<pre>POST [base]</pre>

The body of the POST submission is a Bundle with {{fhir|Bundle.type}}={{term|transaction}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the transaction of what to do for the entry. (Note: {{fhir|Bundle.request}} is optional in FHIR, but SHALL be present, even for the resources which aren't Communications. See [[MedMij:IG:V1/FHIR_IG#Including_.22secondary.22_resources_when_sending_information|the overarching principles]] for more information.)

In order for the server to return each created resource in its entire form, the client SHOULD include the following [https://www.hl7.org/fhir/http.html#ops HTTP Prefer header]: {{fhir|<nowiki>Prefer: return=representation</nowiki>}}.

The resources included in the bundle SHALL conform to the profiles listed in the [[#FHIR_profiles|table below]].

Examples:
{{Collapse top|Bundle containing one Communication resource}}
<syntaxhighlight lang="xml" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction"/>
<entry>
<fullUrl value="urn:uuid:0bd97f28-a942-4cd4-a929-dd8391cbc83f"/>
<resource>
<Communication xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
</meta>
<identifier>
<system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.130.1.40"/>
<value value="4c6a73b0-bf86-43f4-bd98-2eed52d7161e"/>
</identifier>
<status value="completed"/>
<category>
<coding>
<system value="https://hl7.org/fhir/uv/fhir-patient-correction/CodeSystem/PatientCorrectionCommunicationTypes"/>
<code value="medRecCxReq"/>
<display value="Correction request by the Patient or RelatedPerson"/>
</coding>
</category>
<subject>
<reference value="Patient/..."/>
...
</subject>
<topic>
<text value="Wijzigingsverzoek: telefoonnummer"/>
</topic>
<sent value="2022-03-29T09:41:00Z"/>
<recipient>
<reference value="Organization/..."/>
...
</recipient>
<sender>
<reference value="Patient/..."/>
...
</sender>
<payload>
<contentString value="Het telefoonnummer van mijn eerste contactpersoon klopt niet. Jaap Stiekema heeft het nummer 06-12345678."/>
</payload>
</Communication>
</resource>
<request>
<method value="POST"/>
<url value="Communication"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>
{{Collapse bottom}}
{{Collapse top|Bundle containing multiple Communication resources and secondary resources}}
<syntaxhighlight lang="xml" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction"/>
<entry>
<fullUrl value="urn:uuid:f8384e4e-6549-492a-b82a-b8f6101876b3"/>
<resource>
<Communication xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
</meta>
<identifier>
<system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.130.1.40"/>
<value value="0287d8e7-d47b-4465-9cff-fab15bb3dfd2"/>
</identifier>
<status value="completed"/>
<category>
<coding>
<system value="https://hl7.org/fhir/uv/fhir-patient-correction/CodeSystem/PatientCorrectionCommunicationTypes"/>
<code value="medRecCxReq"/>
<display value="Correction request by the Patient or RelatedPerson"/>
</coding>
</category>
<subject>
<reference value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<type value="Patient"/>
<display value="Willemijn Wijziger"/>
</subject>
<topic>
<text value="Allergie niet juist"/>
</topic>
<sent value="2022-03-29T09:41:00Z"/>
<recipient>
<reference value="urn:uuid:a846de6b-a709-42e8-9a49-eaa359e666a5"/>
<type value="Organization"/>
<display value="Erasmus Medisch Centrum"/>
</recipient>
<sender>
<reference value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<type value="Patient"/>
<display value="Willemijn Wijziger"/>
</sender>
<payload>
<contentString value="In mijn dossier staat dat ik allergisch ben voor bijengif, dit is niet juist. Kunt u dit verwijderen?"/>
</payload>
</Communication>
</resource>
<request>
<method value="POST"/>
<url value="Communication"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:6c2f1861-76bb-48fb-8a76-a80adfd2243f"/>
<resource>
<Communication xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
</meta>
<identifier>
<system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.130.1.40"/>
<value value="7c9e1076-4e13-4010-a166-7ca3fe6618fc"/>
</identifier>
<status value="completed"/>
<category>
<coding>
<system value="https://hl7.org/fhir/uv/fhir-patient-correction/CodeSystem/PatientCorrectionCommunicationTypes"/>
<code value="medRecCxReq"/>
<display value="Correction request by the Patient or RelatedPerson"/>
</coding>
</category>
<subject>
<reference value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<type value="Patient"/>
<display value="Willemijn Wijziger"/>
</subject>
<topic>
<text value="Mijn gewicht is fout"/>
</topic>
<sent value="2021-03-29T09:41:00Z"/>
<recipient>
<reference value="urn:uuid:a846de6b-a709-42e8-9a49-eaa359e666a5"/>
<type value="Organization"/>
<display value="Erasmus Medisch Centrum"/>
</recipient>
<sender>
<reference value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<type value="Patient"/>
<display value="Willemijn Wijziger"/>
</sender>
<payload>
<contentString value="Op 14 februari 2022 woog ik 72 kg en er staat dat ik 74 kg weeg, dit is fout."/>
</payload>
</Communication>
</resource>
<request>
<method value="POST"/>
<url value="Communication"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:287837d4-ae09-49b8-a4dd-07efac1e81fa"/>
<resource>
<Communication xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
</meta>
<identifier>
<system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.130.1.40"/>
<value value="3bb12830-8b93-4484-a595-97653a68f17c"/>
</identifier>
<status value="completed"/>
<category>
<coding>
<system value="https://hl7.org/fhir/uv/fhir-patient-correction/CodeSystem/PatientCorrectionCommunicationTypes"/>
<code value="medRecCxReq"/>
<display value="Correction request by the Patient or RelatedPerson"/>
</coding>
</category>
<subject>
<reference value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<type value="Patient"/>
<display value="Willemijn Wijziger"/>
</subject>
<topic>
<text value="Tijdelijk adres aanpassen"/>
</topic>
<sent value="2021-03-29T09:41:00Z"/>
<recipient>
<reference value="urn:uuid:a846de6b-a709-42e8-9a49-eaa359e666a5"/>
<type value="Organization"/>
<display value="Erasmus Medisch Centrum"/>
</recipient>
<sender>
<reference value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<type value="Patient"/>
<display value="Willemijn Wijziger"/>
</sender>
<payload>
<contentString value="Wij gaan tijdelijk op een ander adres wonen in verband met een verbouwing, kunt u mijn adres aanpassen naar: Knolweg 1000, 9999 XA Stitswerd."/>
</payload>
</Communication>
</resource>
<request>
<method value="POST"/>
<url value="Communication"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:c4e8dce5-0f69-42b2-b10b-f480cc377cd2"/>
<resource>
<Patient xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient"/>
</meta>
<identifier>
<system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.130.1.135"/>
<value value="123456789"/>
</identifier>
<name>
<use value="official" />
<text value="Willemijn Wijziger" />
<family value="Wijziger">
<extension url="http://hl7.org/fhir/StructureDefinition/humanname-own-name">
<valueString value="Wijziger" />
</extension>
</family>
<given value="Willemijn">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
<valueCode value="BR" />
</extension>
</given>
</name>
</Patient>
</resource>
<request>
<method value="POST"/>
<url value="Patient"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:a846de6b-a709-42e8-9a49-eaa359e666a5"/>
<resource>
<Organization xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization"/>
</meta>
<identifier>
<system value="http://fhir.nl/fhir/NamingSystem/agb-z"/>
<value value="06020806"/>
</identifier>
<name value="Erasmus Medisch Centrum"/>
</Organization>
</resource>
<request>
<method value="POST"/>
<url value="Organization"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>
{{Collapse bottom}}
===Guidance on resource contents===
On top of the guidance in the [[MedMij:Vprepub-6/OntwerpDossierwijzigingsverzoek#Informatie-elementen|functional design]] and the descriptions in the relevant FHIR profiles, the list below provides direction on how to use the elements in the resources used in this information standard.

Examples of the resources can be found in the FHIR package. See [[#FHIR profiles|the section on FHIR profiles]] for more information.

====PatientCorrectionsCommunication====
Every instance of PatientCorrectionsCommunication (Communication) SHALL contain at least the following elements upon initial creation:
* {{fhir|identifier}}: [[MedMij:IG:V1/FHIR_IG#Usage_of_the_.id.2C_.identifier_and_.fullUrl_elements_in_FHIR_instances|unique identifier]] for the purpose of data deduplication
* {{fhir|status}}: with fixed value {{term|completed}}
* {{fhir|category}}: with fixed value {{term|medRecCxReq}}
* {{fhir|subject}}: the patient that the correction request applies to
* {{fhir|topic}}: subject line, like the subject of an email
* {{fhir|sent}}: the date and time the correction request was sent
* {{fhir|recipient}}: the recipient of the correction request, healthcare provider and optionally (if known) the health professional
* {{fhir|sender}}: a reference to the sender of the correction request
* {{fhir|payload}}: the actual correction request message as a string

====Patient====
The Patient instance SHOULD contain at least the following elements:
* {{fhir|name}}: the patient's birth name

It is encouraged to include an internal hospital patient number using the {{fhir|identifier}} element, if known.

====HealthcareProvider====
The HealthcareProvider (Organization) instance SHOULD contain at least the following elements:
* {{fhir|name}}: the name of the healthcare provider, in MedMij context this name can be derived from the entry in the ZAL (healthcare providers list, Dutch: Zorgaanbiederslijst)

It is encouraged to include the organization's unique identifier like AGB or URA using the {{fhir|identifier}} element, if known.

====HealthProfessional====
The HealthProfessional (Practitioner/PractitionerRole) instance SHOULD contain at least the following elements:
* {{fhir|name}}: the name of the practitioner

It is encouraged to include a practitioner's unique identifier like AGB or BIG using the {{fhir|identifier}} element, if known.

==Server response - XIS==
The server returns an [[MedMij:IG:V1/FHIR_IG|HTTP Status code]] appropriate to the processing outcome and returns a Bundle, with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Because the client request contains the HTTP Prefer header {{fhir|<nowiki>Prefer: return=representation</nowiki>}}, the server SHOULD return a full version of all created resources.

{{ReminderBox|It is conceivable that future versions of this information standard will provide more detailed information on further processing and workflow using the Task resource, thus follow the international [https://build.fhir.org/ig/HL7/fhir-patient-correction/index.html HL7 Patient Corrections IG]. At this point in time, it is not expected that a XIS spawns a Task and creates a reference to this Task in {{fhir|Communication.about}}, nor is it expected that a PHR can resolve and process this Task reference.}}

Example:
<syntaxhighlight lang="xml" highlight="6,12">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>
<entry>
<resource>
<Communication xmlns="http://hl7.org/fhir">
<id value="a9f7a826-fd3f-444a-9457-0d444ee7a966"/>
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
</meta>
<identifier>
<system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.130.1.40"/>
<value value="4c6a73b0-bf86-43f4-bd98-2eed52d7161e"/>
</identifier>
...
</Communication>
</resource>
...
</Bundle>
</syntaxhighlight>

A server SHOULD provide additional information (an acknowledgment of receipt) on the received correction request(s) by adding an OperationOutcome to the response with {{fhir|OperationOutcome.severity}}={{term|information}}, {{fhir|OperationOutcome.code}}={{term|informational}} and the actual message on the {{fhir|OperationOutcome.details.text}} element.

{{ReminderBox|This IG does not cover the actual contents of the text in the OperationOutcome, as this text can be subject to agreements made in programmes like MedMij, VIPP 5 or between healthcare providers. This also applies to support for multiple languages (localization).}}

Example:
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<language value="nl-NL"/>
<issue>
<severity value="information"/>
<code value="informational"/>
<details>
<text value="Uw wijzigingsverzoek is ontvangen, neem voor meer informatie contact op met uw zorgaanbieder. Bij levensbedreigende situaties belt u 112."/>
</details>
</issue>
</OperationOutcome>
</syntaxhighlight>

==RESTful interactions==
┌───┐ ┌───┐
│PHR│ │XIS│
└─┬─┘ └─┬─┘
╔═══════════════════════════════╗│ │
║Send a new correction request ░║│ │
╚═══════════════════════════════╝│ │
│ Create (POST) Bundle containing Communication(s) │
│────────────────────────────────────────────────────────────────>│
│ │
│Return Bundle with created Communication(s) and OperationOutcome │
│<─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
┌─┴─┐ ┌─┴─┐
│PHR│ │XIS│
└───┘ └───┘

=FHIR profiles=

{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.r4.patientcorrections|v1Min=1.0.0|p2=nictiz.fhir.nl.r4.nl-core|v2Min=0.6.0-beta.2}}

{| class="wikitable"
! style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | Profile name
! style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | FHIR Resource
! style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | HCIM EN
! style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | Canonical URL
|-
| dwv-PatientCorrectionsCommunication
| Communication
| n/a
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication|nictiz.fhir.nl.r4.patientcorrections}}
|-
| nl core Patient
| Patient
| [https://zibs.nl/wiki/Patient-v3.2(2020EN) Patient]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core}}
|-
| nl core HealthcareProvider
| Organization
| [https://zibs.nl/wiki/HealthcareProvider-v3.4(2020EN) HealthcareProvider]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core}}
|-
| nl core HealthProfessional Practitioner
| Practitioner
| rowspan="2" | [https://zibs.nl/wiki/HealthProfessional-v3.5(2020EN) HealthProfessional]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core}}
|-
| nl core HealthProfessional PractitionerRole
| PractitionerRole
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core}}
|-
|}

=Release notes=
Release notes can be found on the [[MedMij:Vprepub-6/OntwerpDossierwijzigingsverzoek#Release_notes| functional design page]].

{{#lsth:MedMij:Sjabloon_Support}}

MedMij:Vprepub-6/FHIR Patient Corrections

2023-10-23T07:52:36Z

Ashwin Djorai: MM-4961: The hyperlink in section 4.1 has been updated to chapter 5 FHIR profiles.

Landingspagina BgZ

2023-10-10T11:42:08Z

Ashwin Djorai: The title of Hyperlinks has been corrected

__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017#Use_case_1:_Raadplegen_Basisgegevensset_Zorg_in_persoonlijke_gezondheidsomgeving|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===
====Actueel====
[[BgZ:V1.0_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.0]]
====In ontwikkeling====
[[BgZ:V1.1.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]
====Vorige versie(s)====
(nog geen vorige versies)
===Technisch ontwerp BgZ medisch-specialistische zorg===
====Actueel====
[[BgZ:V1.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.0]]

====In ontwikkeling====
[[BgZ:V1.1.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====Vorige versie(s)====
(nog geen vorige versies)

===Kwalificatiescript BgZ medisch-specialistische zorg===
====Actueel====
[[BgZ:V1.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.1]]

====In ontwikkeling====
[[BgZ:V1.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2]]
====Vorige versie(s)====

[[BgZ:V1.0_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.0]]

FHIR:Vprepub-1.0 FHIR IG STU3

2022-04-13T13:26:59Z

Ashwin Djorai: MM-3096: OperationOutcome.code changes to OperationOutcome.issue.code conform the FHIR specs

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR STU3 Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 HTTP specification (section 3.7.1)] defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/STU3/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. To aid receiving systems that cannot handle the extension, the sending system SHOULD give as much information as possible in the main element. In the case of the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/practitionerrole-reference|nictiz.fhir.nl.stu3.zib2017|title=PractitionerRole reference extension}}, this means that the sending system SHOULD populate the main element with the reference to the Practitioner resource. In most other cases, the sender SHOULD repeat the {{fhir|.display}} used in the extension in the main element.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. A profile is a statement about the rules that this resource was created against. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.
* A receiving system MAY use the stated value of {{fhir|meta.profile}} for validation, documentation or other purposes.
* A receiving system MAY use other profiles than stated in {{fhir|meta.profile}}, e.g. when it has derived, more constrained profiles based on the stated meta.profile. Reasons for additional validation may include protecting the integrity of the receiving system or determination of internal process flow.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHOULD provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}}, {{fhir|.identifier}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

=== When is {{fhir|.identifier}} expected? ===
Systems that use an (internal) stable identifier to track information are encouraged to assign it to the {{fhir|.identifier}} element of FHIR instances when sending the resource, using a custom identifier {{fhir|.system}} (e.g. an URL or OID that is under control of the sending organization). Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the {{fhir|.system}} should preferably be an OID to accommodate compatibility in transformations from FHIR. Especially for resources that are used in information standards that have a HL7v3 (CDA) component, such as the BgZ, GP data and Medication process.

The presence of this element helps receiving systems with re-identification and deduplication of resources, especially when the sender system does not natively support logical ids.

Specific requirements for the usage of {{fhir|.identifier}} will be dictated on a use case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===
As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response. ''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated. ''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.detail}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in the table below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 401 Unauthorized - authorization is required for the interaction that was attempted (usually emitted by the authorization server)
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure (usually emitted by the resource server)
* 404 Not Found - resource type not supported, or not an FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"
|-
! Interaction
! Error
! Expected action
! Example
|-
| rowspan=3 |All
| Not authorized, absent or expired access token
|
* HTTP 401 Unauthorized
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:V1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
|-
| Invalid authorization, scope of the access token is not sufficient for the request
|
* HTTP 403 Forbidden
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:V1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
|-
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}
| [[FHIR:V1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|-
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|-
| Syntactically incorrect parameter
|
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|-
| read
| Read request with unknown id
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}
| [[FHIR:V1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|-
| update
| No or incorrect Resource id
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}
| [[FHIR:V1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|-
| create/update
| Resource syntax or data is incorrect, invalid or unsupported
|
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:V1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

==CapabilityStatements==
Information standards may have a [https://www.hl7.org/fhir/stu3/capabilitystatement.html CapabilityStatement] that is informative in nature and does not represent the minimum or maximum set of capabilities the client or server should support. Nictiz will strive to provide CapabilityStatements that are as complete as possible, however for the exact set of capabilities the implementation guide of the corresponding information standard should be consulted.

==Referring other resources when sending information==
When the client creates/updates a resource on a server, it often needs to reference "secondary" resources which are not the primary focus of the interaction -- e.g. an Observation must indicate its subject using a reference to a Patient resource. The client may refer to existing resources on the server for this, but this is not always possible (for example, the client doesn't know about the existing resource or the server doesn't support the {{fhir|read}} operation for it). In this case, the client needs to send the secondary resources along with the primary resource in a Bundle, and the server should align these new resources with the ones it already has.

A data conflict may arise if these secondary resources carry details that are not of interest within the particular context of the information standard. For example, the client posts an Observation and sends along a Patient resource containing a different telephone number than the one that is on record at the server side. This change in telephone number is not relevant in this particular context, since the interaction is about creating the Observation.

Unless more specific guidance is given by the information standard, the following guidance applies:
* Sending secondary resources SHALL only be done when the information standard specifies that a {{fhir|batch}} or {{fhir|transaction}} operation is to be used.
* If so, the client MAY send a bare-bones instance as the secondary resource containing just minimal information, but this SHOULD include the information necessary for the server to match its own copy. The information standard MAY specify which information is minimally needed for such a secondary resource and MAY also restrict the information that is sent in the secondary resource.
* The client MUST include a {{fhir|Bundle.entry.request}} for each of the resources in the Bundle, including the secondary resources that are only there for referencing purposes<ref>Although {{fhir|Bundle.entry.request}} is not formally required in FHIR STU3, it is made clear in FHIR R4 that the expected behavior actually is to include it.</ref>. {{fhir|.request}} SHOULD be a <code>POST</code> to the appropriate endpoint. As an alternative, <code>PUT</code> MAY be used, but is strongly discouraged; if the client has knowledge on the id of the resource on the server, an absolute URL is strongly preferred.
* If the server can unequivocally de-duplicate this secondary resource (for example, because the patient is already known from the security context or the healthcare provider is recognized by the UZI number), it MAY choose to ignore the differences of this resource or it MAY incorporate them (see the [https://www.hl7.org/fhir/stu3/http.html#transactional-integrity the section on transactional integity] in the FHIR specification). Please note that absence of information should not result in deletion of information on the server, as the client could send a bare-bones instance.
** If a {{fhir|transaction}} operation is used and the server chooses to ignore the differences, it SHOULD do so silently by responding with a 200 OK status code for the corresponding {{fhir|Bundle.entry.response.status}} in the response Bundle.
** If a {{fhir|batch}} operation is used and the server chooses to ignore the differences, it SHOULD do so either silently using the mechanism described above, or explicitly by responding with a 422 Unprocessable Entity status code {{fhir|Bundle.entry.response.status}} to indicate that a business rule prevented the resource from being created (in combination with an OperationOutcome resource).
* The server SHALL rewrite the references in the primary resource to the resource it already has.

=FHIR Packages=
The information standards maintained by Nictiz adopt the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR packages]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|It is '''not''' required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.}}
<section end=FHIRPackages />

FHIR:V1.0 FHIR IG STU3

2022-04-13T13:26:59Z

Ashwin Djorai: MM-3096: OperationOutcome.code changes to OperationOutcome.issue.code conform the FHIR specs

FHIR:Vprepub-1.0 FHIR Error handling examples

2022-04-13T13:26:19Z

Ashwin Djorai: MM-3096: .code changes to issue.code conform the FHIR specs

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR IG Error handling examples}}
=Error handling examples=
This page provides guidance on how a server could handle errors. Examples are provided in XML format but could have been in JSON format as well. Please note: these examples are not considered to be part of the normative content of the implementation guide.

==All interactions==
===Not authorized===
{| class="wikitable"
|-
| '''Scenario'''
| Not authorized.
|-
| '''Request'''
| <pre> GET [base]/Practitioner/86475712701</pre>
|-
| '''Response'''
|
* HTTP 401 Unauthorized
* OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|security}} or if applicable a more specific child code.
|}
{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="01464674-b4b6-11eb-8529-0242ac130003" />
<text>
...
</text>
<issue>
<severity value="error"/>
<code value="security"/>
<details>
<text value="Not authorized to access this resource"/>
</details>
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}
===Invalid authorization===
{| class="wikitable"
|-
| '''Scenario'''
| Invalid authorization.
|-
| '''Request'''
| <pre> GET [base]/Patient/20118482245</pre>
|-
| '''Response'''
|
* HTTP 403 Forbidden
* OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|security}} or if applicable a more specific child code.
|}
{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="131sasdffa-ds32-2380-2343-131s12334234" />
<text>
...
</text>
<issue>
<severity value="error"/>
<code value="security"/>
<details>
<text value="Read access forbidden"/>
</details>
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}

===Resource is not supported===
{| class="wikitable"
|-
| '''Scenario'''
| The Resource is not supported by the resource server.
|-
| '''Request'''
| <pre>GET [base]/Questionnaire</pre>
|-
| '''Response'''
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|not-supported}}
|}

{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="3f3f6d70-823f-4c6f-92e9-8693c50723ac" />
<text>
...
</text>
<issue>
<severity value="error" />
<code value="not-supported" />
<details>
<text value="Request for not-supported ResourceType(s) Questionnaire" />
</details>
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}

==Search==
===Unkown or unsupported search parameter value===
{| class="wikitable"
|-
| '''Scenario'''
|
Unknown or unsupported search parameter value. In this example scenario, the Consent endpoint is supported. Although a system has implemented support for the HCIM TreatmentDirective (<code><nowiki>category=http://snomed.info/sct|11291000146105</nowiki></code>) it has not implemented the HCIM AdvanceDirective (<code><nowiki>category=http://snomed.info/sct|11341000146107</nowiki></code>).
|-
| '''Request'''
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107</pre>
|-
| '''Response'''
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}
* OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|not-found}} and {{fhir|OperationOutcome.severity}} not set to {{term|fatal}} or {{term|error}}
|}
{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<Bundle xmlns="http://hl7.org/fhir">
<id value="bundle-search-warning"/>
<meta>
<lastUpdated value="2020-03-14T08:23:30+11:00"/>
</meta>
<type value="searchset"/>
<total value="0"/>
<link>
<relation value="self"/>
<url value="https://example.org/fhir/Consent?category=http://snomed.info/sct|11341000146107"/>
</link>
<entry>
<resource>
<OperationOutcome>
<id value="131sadfa-ds32-2380-2343-131sadfa34234" />
<text>
...
</text>
<issue>
<severity value="warning"/>
<code value="not-found"/>
<details>
<text value="Request for not-supported Consent of category HCIM AdvanceDirective" />
</details>
</issue>
</OperationOutcome>
</resource>
<search>
<mode value="outcome"/>
</search>
</entry>
</Bundle>
</syntaxhighlight>
{{Collapse bottom}}

===Syntactically incorrect parameter===
{| class="wikitable"
|-
| '''Scenario'''
| Syntactically incorrect parameter in the search request.
|-
| '''Request'''
| <pre> GET [base]/Procedure?patient:john</pre>
|-
| '''Response'''
| * HTTP Status code 404 Not Found * OperationOutcome
|}
{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="1317cae1-ds32-4e80-2343-4fe6sdfsaxzxfdfs" />
<text>
...
</text>
<issue>
<severity value="error" />
<code value="invalid" />
<details>
<text value="Argument lacks the name/value separator '=' or has no value" />
</details>
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}

==Read==
===Request on an unknown id===
{| class="wikitable"
|-
| '''Scenario'''
| The id is not known by the server
|-
| '''Request'''
| <pre>GET [base]/Patient/wrong-id</pre>
|-
| '''Response'''
| * HTTP Status code 404 Not Found * OperationOutcome
|}
{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="1317cae1-ds32-4e80-2340-4fe6sdfae321xf" />
<text>
...
</text>
<issue>
<severity value="error"/>
<code value="not-found"/>
<diagnostics value="Resource Id "Patient/wrong-id" does not exist"/>
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}

==Create/Update==
===No or incorrect Resource id===
{| class="wikitable"
|-
| '''Scenario'''
| Update an existing Patient resource, using a wrong id in the Resource.
|-
| '''Request'''
| <pre> PUT [base]/Patient/34235234</pre>
|-
| '''Response'''
|
* HTTP 400 Bad Request
OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|invalid}}
|}

{{Collapse top|XML contents - request}}
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<Patient xmlns="http://hl7.org/fhir">
<id value="wrong-id"/>
<name>
<use value="official"/>
<family value="Case"/>
<given value="Justin"/>
</name>
</Patient>
</syntaxhighlight>
{{Collapse bottom}}

{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="1317cae1-ds32-4e80-aaf0-4fe687fsdfsdf" />
<text>
...
</text>
<issue>
<severity value="error" />
<code value="invalid" />
<details>
<text value="Id in request (34235234) and in resource (wrong-id) must match." />
</details>
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}
===Resource syntax or data is incorrect, invalid or unsupported===
{| class="wikitable"
|-
| '''Scenario'''
| Resource syntax or data is incorrect, invalid or unsupported.
|-
| '''Request'''
| <pre> POST [base]/Patient</pre>
|-
| '''Response'''
|
* HTTP 400 Bad Request or HTTP 422 Uprocessable Entity
* OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|invalid}} or a more specific child code.
|}
{{Collapse top|XML contents - request}}
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<Patient xmlns="http://hl7.org/fhir">
<id value="example"/>
<name>
<use value="official"/>
<family value="Case"/>
<given value="Justin"/>
</name>
<telecom>
<value value="061234567"/>
<use value="mobile"/>
<rank value="2"/>
</telecom>
</Patient>
</syntaxhighlight>
{{Collapse bottom}}

{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="1317cae1-2ee2-4e80-aaf0-4fe687ffd5f9" />
<text>
...
</text>
<issue>
<severity value="error" />
<code value="invariant" />
<details>
<text value="Instance failed constraint cpt-2 "A system is required if a value is provided."" />
</details>
<diagnostics value="value.empty() or system.exists()" />
<location value="Patient.telecom[0]" />
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}

{| class="wikitable"
|-
| '''Scenario'''
| Resource syntax or data is incorrect, invalid or unsupported.
|-
| '''Request'''
| <pre> POST [base]/Observation</pre>
|-
| '''Response'''
|
* HTTP 400 Bad Request or HTTP 422 Uprocessable Entity
* OperationOutcome with {{fhir|OperationOutcome.issue.code}} set to {{term|invalid}} or a more specific child code.
|}
{{Collapse top|XML contents - request}}
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<Observation xmlns="http://hl7.org/fhir">
<id value="example"/>
...
<category>
<coding>
<system value="http://hl7.org/fhir/observation-category"/>
<code value="vital-signs"/>
<display value="Vital Signs"/>
</coding>
</category>
<code>
<coding>
<system value="http://loinc.org"/>
<code value="39156-5"/>
<display value="Body mass index (BMI)"/>
</coding>
</code>
...
</Observation>
</syntaxhighlight>
{{Collapse bottom}}

{{Collapse top|XML contents - response}}
<syntaxhighlight lang="xml">
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="c8bc9de0-5141-40dd-9a06-7134109d8ce0" />
<text>
...
</text>
<issue>
<severity value="error" />
<code value="not-supported" />
<details>
<text value="Unsupported code value" />
</details>
<location value="Observation.code[0]" />
</issue>
</OperationOutcome>
</syntaxhighlight>
{{Collapse bottom}}

FHIR:V1.0 FHIR Error handling examples

2022-04-13T13:26:19Z

Ashwin Djorai: MM-3096: .code changes to issue.code conform the FHIR specs