bgz:V2.0 Technical IG BgZ MSZ: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(Nieuwe pagina aangemaakt met ' <!-- BACK TO TOP BUTTON --> <span id="BackToTop"></span> <div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; ma...')
 
k
 
(29 tussenliggende versies door 5 gebruikers niet weergegeven)
Regel 6: Regel 6:
 
</div>
 
</div>
 
<!-- EINDE BACK TO TOP BUTTON -->
 
<!-- EINDE BACK TO TOP BUTTON -->
−
For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
+
For an overview of all current documentation for BgZ-MSZ, [[Landingspagina_BgZ| see BgZ-MSZ main page]]
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
−
__NOINDEX__
+
{{DISPLAYTITLE:BgZ-MSZ FHIR Implementation Guide {{VersieInfo|BgZ|release=V2.0}}}}  
−
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0-rc.1}}
 
 
__TOC__
 
__TOC__
  
 
=Introduction=
 
=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]].
+
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 [[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]].
+
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.
 
First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.
  
 
== Known issues ==
 
== Known issues ==
−
This version of the information standard has known issues. Please find them in the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].
+
This version of the information standard has known issues. Please find them listed in the [[bgz:V2.0_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].
  
 
= Boundaries and relationships =
 
= Boundaries and relationships =
Regel 27: Regel 28:
 
== Boundaries ==
 
== 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]].
+
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 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 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.
 
In future versions the gap to the European patient summary will be addressed.
Regel 35: Regel 36:
 
== Building blocks and FHIR profiles ==
 
== Building blocks and FHIR profiles ==
  
−
Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models).  
+
Data exchange of the BgZ-MSZ is defined in building blocks based on the Dutch zib2017 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.  
+
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 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.
+
* 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 ==
 
== Relations between building blocks ==
Regel 49: Regel 50:
 
== Mapping between profiles and dataset ==
 
== 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 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 with the exception of MetaData, Patient, HealthProvider.
+
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.
+
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 ==  
 
== 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.
+
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.
 
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:
 
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.
+
<nowiki>GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</nowiki>.
  
−
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".
+
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.
 
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.
  
 
= Transactions =
 
= Transactions =
  
−
== Exchange BgZ for Referral ==
+
== Exchange BgZ-MSZ at Referral ==
  
 
{| class="wikitable"
 
{| class="wikitable"
Regel 83: Regel 84:
 
|-
 
|-
 
| Referring (Sending) Medical Specialist
 
| Referring (Sending) Medical Specialist
−
| Medical specialist who sends a BgZ along with a referral
+
| The medical specialist who sends BgZ-MSZ at referral
 
| EHR
 
| EHR
 
| Electronic health record
 
| 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]
+
|[[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  
+
| FHIR Client requirements
 
|-
 
|-
 
| Receiving Medical Specialist
 
| Receiving Medical Specialist
−
| Medical specialist receives a BgZ along with a referral
+
| The medical specialist who receives BgZ-MSZ at referral
 
| EHR
 
| EHR
 
| Electronic health record
 
| 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]
+
|[[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  
+
| FHIR Server requirements
 
|}
 
|}
−
<small><b>Table 1.</b> Actors in the BgZ exchange for referral.</small>
+
<small><b>Table 1.</b> Actors in the BgZ-MSZ exchange at referral.</small>
  
−
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.
+
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 ===
+
=== 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.  
+
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.
+
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 ===
+
=== Exchange using Push 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 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 is replaced by a FHIR Composition.
+
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 from previous practitioner ==
+
== Retrieval of BgZ-MSZ from previous practitioner ==
  
 
{| class="wikitable"
 
{| class="wikitable"
Regel 124: Regel 125:
 
|-
 
|-
 
| Requesting Medical Specialist
 
| Requesting Medical Specialist
−
| Medical specialist who queries for a BgZ
+
| Medical specialist who queries for a BgZ-MSZ
 
| EHR
 
| EHR
 
| Electronic health record
 
| Electronic health record
 
|}
 
|}
−
<small><b>Table 2.</b> Actors in the retrieval of the BgZ from a previous practitioner.</small>
+
<small><b>Table 2.</b> Actors in the retrieval of the BgZ-MSZ from a previous practitioner.</small>
  
−
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.
+
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 (at a suitable time) using the Pull Message and the search/ read queries defined in table 4.
+
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 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).
+
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 =  
 
= 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:
+
{{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.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]
 
* [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.}}
 
'''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 ==
 
==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"  
 
{| class="wikitable" style="horizontal-align: right"  
Regel 152: Regel 164:
 
| Patient
 
| Patient
 
| 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}}}}
+
| 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
 
| MaritalStatus
Regel 168: Regel 180:
 
| Payer.PayerPerson
 
| Payer.PayerPerson
 
| Patient
 
| 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}}}}
+
| {{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  
 
| rowspan="2" | 3  
Regel 182: Regel 194:
 
| ContactPerson
 
| ContactPerson
 
| Patient.contact
 
| 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}}}}
+
| {{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
 
| 5
 
| FunctionalOrMentalStatus
 
| FunctionalOrMentalStatus
 
| Observation
 
| Observation
−
| {{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}}}}
+
| {{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
 
| 6
 
| Problem
 
| Problem
 
| Condition
 
| 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}}}}  
+
| {{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
 
| rowspan="5" | 7
Regel 282: Regel 294:
 
| {{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}}}}
 
| {{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}}}}
 
|-
 
|-
−
| 15  
+
| rowspan = "2"| 15  
 
| Procedure
 
| Procedure
 
| 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}}}}
+
| {{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  
 
| 16  
Regel 319: Regel 336:
 
| {{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}}}}
 
| {{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}}}}
 
|}
 
|}
−
<small><b>Table 3.</b> 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.</small>
+
<small><b>Table 3.</b> 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.</small>
 +
 
 +
==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.
  
−
=== Future changes in FHIR BgZ related profiles ===
+
For example bloodpressure with the resource observation:
−
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==
+
<pre>GET [base]Observation?code=http://loinc.org|85354-9&_sort=-date&_count=1&_revinclude=Provenance:target</pre>}}
−
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"
 
{| class="wikitable"
Regel 391: Regel 411:
 
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
 
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').
 
* 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').
+
* 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.
+
* 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.
+
* 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
 
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
Regel 402: Regel 422:
 
|  
 
|  
 
All problems available in the source system are returned as zib-Problem instances.
 
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.
+
* 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 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.
+
* 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
 
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
Regel 413: Regel 433:
 
|  
 
|  
 
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
 
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 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.
 
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
 
|-
 
|-
Regel 436: Regel 456:
 
|  
 
|  
 
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
 
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').
+
* 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
 
!  colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
Regel 460: Regel 480:
 
|  
 
|  
 
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
 
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.
+
* 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>
 
<pre>
 
"manifestation":{
 
"manifestation":{
Regel 556: Regel 576:
 
!  colspan="2" style="text-align: left;" | 15.1 Procedure
 
!  colspan="2" style="text-align: left;" | 15.1 Procedure
 
|-
 
|-
−
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001{&_revinclude=Provenance:target}</pre>
+
| <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.
 
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’).
 
* 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’).
 
* 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’).  
+
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
 
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
Regel 593: Regel 615:
 
see Encounter.serviceProvider</pre>
 
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.
+
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.
 
|}
 
|}
−
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components. Everything between curly braces ({}) are considered optional.</small>
+
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ-MSZ components. Everything between curly braces ({}) is considered optional.</small>
  
 
==Notified Pull Query Specification==
 
==Notified Pull Query Specification==
−
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections.  
+
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.   
+
The coding column defines codedConcepts that identify the BgZ-MSZ section (HCIM) to retrieve.   
  
 
{| class="wikitable" width="100%" style="horizontal-align: right"
 
{| class="wikitable" width="100%" style="horizontal-align: right"
Regel 709: Regel 731:
 
|-
 
|-
 
| 18.2 Healthcare provider
 
| 18.2 Healthcare provider
−
| <span STYLE="font-family:'Courier'; font-weight:700">Data are exchanges as part of other BgZ components.</span>
+
| <span STYLE="font-family:'Courier'; font-weight:700">Data are exchanged as part of other BgZ-MSZ components.</span>
 
|-
 
|-
 
| Meta data
 
| Meta data
Regel 729: Regel 751:
  
 
= Release notes =
 
= Release notes =
−
Please find the release notes on the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].
+
Please find the release notes on the [[bgz:V2.0_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].
  
 
{{MedMij:Sjabloon_Support}}
 
{{MedMij:Sjabloon_Support}}

Huidige versie van 26 mei 2026 om 16:48

Back to Top

For an overview of all current documentation for BgZ-MSZ, see BgZ-MSZ main page


1 Introduction

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

In addition, the guidelines as specified in the 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 use case overarching principles and the use of FHIR packages.

Furthermore, this IG requires the reader to understand and use the Technical Agreement Notified Pull (TA-NP) specification.

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

1.1 Known issues

This version of the information standard has known issues. Please find them listed in the functional design page.

2 Boundaries and relationships

2.1 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 MBH-identifier from Medication Process 9; however, systems are encouraged to use the .identifier as stated in the 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.

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

2.3 Relations between building blocks

ChaptersAndRelationsBgZ2 v1.png

Figure 1. Relations between building blocks.

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

2.5 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: GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333.

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.

3 Transactions

3.1 Exchange BgZ-MSZ at Referral

Actors Systems FHIR Capability Statements
Name Description Name Description Name Description
Referring (Sending) Medical Specialist The medical specialist who sends BgZ-MSZ at referral EHR Electronic health record Verwijzing.png CapabilityStatement: Client FHIR Client requirements
Receiving Medical Specialist The medical specialist who receives BgZ-MSZ at referral EHR Electronic health record Verwijzing.png 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.

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

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

3.2 Retrieval of BgZ-MSZ from previous practitioner

Person System
Name Description Name 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).

4 Materials

Em.png

BgZ-MSZ uses the 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:

Note: packages use 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.

4.1 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:

  • 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:

  • 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 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.
  • 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 zib-functionalormentalstatus profile for this purpose.
  • 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 zib-procedure profile, since the category element has no binding.
Chapter HCIM EN Resource Profile
1 Patient Patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient
MaritalStatus Patient.maritalStatus
2 Payer Coverage http://nictiz.nl/fhir/StructureDefinition/zib-Payer
Payer.InsuranceCompany Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Payer.PayerPerson Patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient
3 TreatmentDirective Consent http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective
AdvanceDirective Consent http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective
4 ContactPerson Patient.contact http://fhir.nl/fhir/StructureDefinition/nl-core-patient
5 FunctionalOrMentalStatus Observation http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus
6 Problem Condition http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem
7 LivingSituation Observation http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation
DrugUse Observation http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse
AlcoholUse Observation http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse
TobaccoUse Observation http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse
NutritionAdvice NutritionOrder http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice
8 Alert Flag http://nictiz.nl/fhir/StructureDefinition/zib-Alert
9 AllergyIntolerance AllergyIntolerance http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance
10 MedicationAgreement MedicationRequest http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement
AdministrationAgreement MedicationDispense http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement
MedicationUse2 MedicationStatement http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse
PharmaceuticalProduct Medication http://nictiz.nl/fhir/StructureDefinition/zib-Product
InstructionsForUse Dosage http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse
11 MedicalDevice DeviceUseStatement http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice
MedicalDevice.Product Device http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct
12 Vaccination Immunization http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination
Vaccination.PreferedDateForRevaccination ImmunizationRecommendation http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation
13 BloodPressure Observation http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure
BodyWeight Observation http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight
BodyHeight Observation http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight
14 LaboratoryTestResult Observation http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation
15 Procedure Procedure http://nictiz.nl/fhir/StructureDefinition/zib-Procedure
Procedure.basedOn ProcedureRequest http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest
16 Encounter Encounter http://nictiz.nl/fhir/StructureDefinition/zib-Encounter
17 PlannedCareActivity.Procedure ProcedureRequest http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest
18 HealthProfessional Practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
HealthProfessional.Specialty PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
HealthProfessional.HealthProfessionalRole CareTeam http://fhir.nl/fhir/StructureDefinition/nl-core-careteam
HealthcareProvider Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Metadata Provenance http://nictiz.nl/fhir/StructureDefinition/bgz-metadata

Table 3. FHIR Profiles used to exchange BgZ-MSZ sections. The reader should take note of the 'Relating FHIR profiles with their functional definitions' in the FHIR STU3 Implementation Guide.

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

Em.png

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: 

GET [base]Observation?code=http://loinc.org|85354-9&_sort=-date&_count=1&_revinclude=Provenance:target
Query Description
1 Demographics and identification
1.1 Patient 
GET [base]/Patient?_include=Patient:general-practitioner{&_revinclude=Provenance:target}

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.
1.2 Marital status 
see Patient.maritalStatus

Marital status data are exchanged via the patient resource (see 1.1).

2 Financial information
2.1 Payer 
GET [base]/Coverage?_include=Coverage:payor{&_revinclude=Provenance:target}

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.
3 Treatment restrictions
3.1 Treatment instructions 
GET [base]/Consent?category=http://snomed.info/sct|11291000146105{&_revinclude=Provenance:target}

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').
3.2 Advance directive 
GET [base]/Consent?category=http://snomed.info/sct|11341000146107{&_revinclude=Provenance:target}

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.
4 Contact persons
4.1 Contact 
Patient.contact

Primary partner/contact data are exchanged via the patient resource (see 1.1).

5 Functional/mental status
5.1 Functional or mental status 
GET [base]/Observation?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006{&_revinclude=Provenance:target}

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.
6 Complaints and diagnoses
6.1 Problem 
GET [base]/Condition{?_revinclude=Provenance:target}

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.
7 Social history
7.1 Living Situation 
GET [base]/Observation?code=http://snomed.info/sct|365508006{&_revinclude=Provenance:target}

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.
7.2 Drug Use 
GET [base]/Observation?code=http://snomed.info/sct|228366006{&_revinclude=Provenance:target}

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.
7.3 Alcohol Use 
GET [base]/Observation?code=http://snomed.info/sct|228273003{&_revinclude=Provenance:target}

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').
7.4 Tobacco Use 
GET [base]/Observation?code=http://snomed.info/sct|365980008{&_revinclude=Provenance:target}

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').
7.5 Nutrition Advice 
GET [base]/NutritionOrder{?_revinclude=Provenance:target}

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.
8 Alerts
8.1 Alert 
GET [base]/Flag{?_revinclude=Provenance:target}

All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.

9 Allergies
9.1 Allergy Intolerance 
GET [base]/AllergyIntolerance{?_revinclude=Provenance:target}

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.
"manifestation":{
   "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
      "valueCode": "unknown"
    }]
  },
10 Medication
10.1 Medication Agreement 
GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication{&_revinclude=Provenance:target}

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.
10.2 Administration Agreement 
GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication{&_revinclude=Provenance:target}

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.
10.3 Medication Use 
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}

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.
11 Medical devices
11.1 Medical device 
GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device{&_revinclude=Provenance:target}

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.
12 Vaccinations
12.1 Vaccination 
GET [base]/Immunization?status=completed{&_revinclude=Provenance:target}

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’.
13 vital signs and measurements
13.1 Blood pressure 
GET [base]/Observation/$lastn?code=http://loinc.org|85354-9{&_revinclude=Provenance:target}

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.
13.2 Body weight 
GET [base]/Observation/$lastn?code=http://loinc.org|29463-7{&_revinclude=Provenance:target}

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.
13.3 Body height 
GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9{&_revinclude=Provenance:target}

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.
14 Results
14.1 Laboratory test result 
GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target{&_revinclude=Provenance:target}

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.
15 Procedures
15.1 Procedure 
GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001&_include=Procedure:based-on{&_revinclude=Provenance:target}

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.

16 Encounters
16.1 Encounter 
GET [base]/Encounter{?_revinclude=Provenance:target}

All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.

17 Planned care activity
17.1 Procedure 
GET [base]/ProcedureRequest?status=active{&_revinclude=Provenance:target}

All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.

18 Care Setting
18.1 Health professional 
GET [base]/CareTeam?status=active&_include=CareTeam:participant{&_revinclude=Provenance:target}

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.
18.2 Healthcare provider 
see Procedure.performer
see Encounter.serviceProvider

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.

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

Chapter Section Notified Pull coding
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
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
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
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
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
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.

4.4 Glossary

Term Description
HCIM Health and Care Information models (HCIM) or Zorginformatiebouwstenen (ZIB's) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.

Table 6. Glossary.

5 Release notes

Please find the release notes on the functional design page.


6 Support

For questions and change requests regarding the information on this page, please create a ticket in Servicedesk Portal.

Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=bgz:V2.0_Technical_IG_BgZ_MSZ&oldid=313587"