BgZ:Vissue-NICTIZ-14348 BgZ 2017 Technical IG: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
(Clone of V1.0 production page for issue NICTIZ-14348)
 
(NICTIZ-18044 - BgZ-MSZ TO - review commentaren Gabriel/Iwo bijwerken en NICTIZ 18045 - BgZ-MSZ TO - aanpassing ivm "Notified Pull – Hoe toe te passen in een informatiestandaard" - doc Marc)
 
(124 tussenliggende versies door 3 gebruikers niet weergegeven)
Regel 1: Regel 1:
 +
<!-- BACK TO TOP BUTTON -->
 +
<span id="BackToTop"></span>
 +
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
 +
[[#BackToTop|Back to Top]]
 +
</div>
 +
<!-- EINDE BACK TO TOP BUTTON -->
 +
 
{{IssuePaginaWaarschuwing|NICTIZ-14348|BgZ:V1.0_BgZ_2017_Technical_IG}}
 
{{IssuePaginaWaarschuwing|NICTIZ-14348|BgZ:V1.0_BgZ_2017_Technical_IG}}
 +
{{underconstruction}}
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
 
__NOINDEX__
 
__NOINDEX__
−
{{DISPLAYTITLE:BgZ medisch-specialistische zorg Technical Implementation Guide 1.0}}
+
{{DISPLAYTITLE:BgZ Medisch-Specialistische Zorg Technical Implementation Guide 2.0}}
 
__TOC__
 
__TOC__
 +
=Note on this Implementation Guide - alpha status=
 +
This alpha version of the Implementation Guide (TO) is not technically complete, but even so, it is being published in order to start obtaining feedback from the stakeholders. The current version provides an early indication of the contents being proposed. 
 +
 +
The following items require further investigation, discussion and review amongst all stakeholders.
 +
 +
# Generic description of the Notified Pull communication pattern - this is being developed by Team Radar (Generic) within Nictiz at the moment and will be referred to from this TO. The intention is to avoid duplicating information at all costs.
 +
# FHIR Notification and Workflow Task profiles - the first versions of these have been developed locally and now need to be published via Simplifier so that a reference can be made to them from this TO.
 +
# FHIR GET (read/search) request strings - these need to be reviewed once the Referenced BgZ Resource profiles are complete.
 +
# FHIR Referenced BgZ Resource profiles - the FO defines two new data elements that enrich the BgZ items - EersteRegistratieDatumTijd (FirstRegistrationDateTime) and MutatieDatumTijd (ContentModificationDateTime). These two fields need to be added to the corresponding BgZ FHIR resources and the mechanism for doing this is under discussion at the moment. The FHIR Provenance Resource is being considered. As soon as there is some clarity on best practices then the FHIR resource profiles will be updated and references adjusted in this TO.
 +
 +
The intention is to finalize agreements on these issues for the beta version of the TO. This alpha version will be updated, towards a beta version, as issues are resolved.
 +
 
=Introduction=
 
=Introduction=
−
See the [[BgZ:Vprepub-1.0_BgZ_MSZ_Informatiestandaard|Functional specification]] for context.
+
==Background==
 +
The BgZ MSZ Information Standard describes the exchange of the BgZ information between healthcare providers.
 +
The BgZ information is the minimum collection of patient data that is relevant across specialty, syndrome and profession and is important for the continuity of care.
 +
This data collection can be exchanged between care institutions. The information standard focuses on the exchange between healthcare providers of specialist medical care.
 +
 
 +
This BgZ MSZ implementation guide defines the BgZ information exchanges, in terms of use cases, based on the Zib2017 and HL7 FHIR STU3 releases. HL7 CDA is no longer supported for BgZ MSZ exchange.
 +
 
 +
==About this document==
 +
This BgZ MSZ implementation guide is a technical document defining the BgZ information exchanges in terms of use cases. It should be used together with the BgZ MSZ Functional Design (FO) - see [[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]].
 +
 
 +
The following documents also provide important background information:
 +
* "Kwaliteitsstandaard - Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend" (which translates as “Exchange of BgZ between institutions where specialist medical care is provided”) [1]
 +
* "NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg" (which translates as “Exchange of BgZ between institutions for specialist medical care”) [2]
 +
* "Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism" [3]
 +
 
 +
This document assumes reader familiarity with these references.
 +
 
 +
This implementation guide is intended to provide information for implementation/deployment needs in the Netherlands. This document is part of an evolving strategy, features will likely be added, adjusted and/or removed in future versions.
 +
 
 +
==Glossary==
 +
{| class="wikitable"
 +
|-
 +
! Term !! Description
 +
|-
 +
|  Basisgegevensset Zorg - medisch-specialistische zorg (BgZ MSZ) || Minimum collection of patient data that is relevant across specialty, clinical picture and profession and is important for the continuity of care.
 +
|-
 +
| BSN || The citizen service number ([https://www.government.nl/topics/personal-data/citizen-service-number-bsn BSN]) is a unique 9-digit personal number allocated to everyone registered in the Personal Records Database ([https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/basisregistratie-personen-brp BRP]). Everyone who registers with the BRP is automatically given a BSN.
 +
|-
 +
| FHIR || Fast Healthcare Interoperability Resources
 +
|-
 +
| IHE || [https://profiles.ihe.net/index.html Integrating the Healthcare Enterprise]
 +
|-
 +
| 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.
 +
|-
 +
| MedMij || [https://medmij.nl/?mtm_campaign=branded&gclid=CjwKCAiAs6-sBhBmEiwA1Nl8s5DqLXY9-lS_hjiGuN-ClixzeGEYiNvVw0i0oq8TDajo60Gj-TnhShoCFZ0QAvD_BwE MedMij] is an initiative of the Dutch Patient Federation and was embraced as one of the five focus programs in 2015. The Healthcare Information Council then opted for the MedMij program. To make healthcare better, more affordable and more accessible, the Information Council is working on a sustainable information system for healthcare, in which healthcare data is exchanged securely and reliably. To this end, agreements, standards, and facilities are made, together with the participants of the Information Council.
 +
|-
 +
| VZVZ || [https://www.vzvz.nl/veelgestelde-vragen/wie-vzvz Vereniging van Zorgaanbieders voor Zorgcommunicatie]: Dutch Association for Health Providers
 +
|-
 +
| Zib || A Zib ([https://zibs.nl/wiki/HCIM_Mainpage Zorginformatiebouwstenen]) defines a clinical concept in such a way that it can be used as a building block in various healthcare situations and information systems. ZIBs form the basis for the standardization of healthcare information.  
 +
|-
 +
|}
 +
<small>''Table 2.1 Glossary''</small>
  
−
=Actors involved=
+
=Boundaries and Relationships=
 +
This is the first version of the BgZ MSZ information standard in which the Notified Pull communication pattern is used to implement the "Exchange BgZ for Referral" use case. A generic description of the Notified Pull communication pattern is available (add link the Nictiz Team Radar/Generic NP description). The generic description is supplemented in this Implementation Guide by specific details defining:
 +
# The Notification and Workflow Tasks in terms of their FHIR profiles.
 +
# The GET request strings required to read/search for the BgZ MSZ items, defined as Input parameters in the Notification/Workflow tasks, from the Sending System by the Receiving System.
 +
# The referenced FHIR resource profiles corresponding to the BgZ MSZ items.
 +
 
 +
=Use Cases=
 +
Two use cases are defined in the FO as follows:
 +
* Exchange BgZ for Referral ("Uitwisseling BgZ bij Verwijzing") from a referring (sending) healthcare provider to a receiving healthcare provider in the event of a planned referral or transfer between their two care institutions.
 +
* Retrieval of BgZ from previous practitioner ("Opvraging BgZ bij eerdere behandelaar") by a requesting healthcare provider to his/her care institution from a different care institution.
 +
The difference between the two use cases is mainly down to which healthcare provider takes the initiative to start the exchange of the BgZ.
 +
==Exchange BgZ for Referral==
 +
In the "Exchange BgZ for Referral" use case, the current healthcare provider (Referring (Sending) Medical Specialist) takes the initiative for a referral or transfer. In doing so, information is shared, including the BgZ (and, for example, a referral letter, additional images or reports). When the patient then attends the new care institution as a result of the referral, or transfer, the Receiving Medical Specialist can (re)use the information from the BgZ.
 +
===Actors===
 
{| class="wikitable"
 
{| class="wikitable"
 
! colspan="2" style="text-align:left;" | Persons
 
! colspan="2" style="text-align:left;" | Persons
Regel 17: Regel 91:
 
! style="text-align:left;" |Description
 
! style="text-align:left;" |Description
 
|-
 
|-
−
| Referring medical specialist
+
| Referring (Sending) Medical Specialist
 
| Medical specialist who sends a BgZ along with a referral
 
| Medical specialist who sends a BgZ along with a referral
 
| EHR
 
| EHR
 
| Electronic health record
 
| Electronic health record
 
|-
 
|-
−
| Receiving medical specialist
+
| Receiving Medical Specialist
 
| Medical specialist receives a BgZ along with a referral
 
| Medical specialist receives a BgZ along with a referral
 
| EHR
 
| EHR
 
| Electronic health record
 
| Electronic health record
 
|}
 
|}
−
=Systems and system roles=
+
It is assumed that the Referring (Sending) Medical Specialist and Receiving Medical Specialist, as persons who use the BgZ sharing infrastructure, are signed on, authenticated and have authorization & consent to access the necessary (patient) information stored in the BgZ sharing infrastructure (or in other words, an authenticated healthcare professional who has an active treatment relationship with the patient). The way in which the persons achieve this state is beyond the scope of this implementation guide but is expected to be facilitated by use of the generic infrastructure.
−
System roles are further defined through the Healthcare Information Exchange model of "Registratie aan de Bron" ("Register at the source").
 
−
[[Bestand:Healthcare Information Exchange model v1.0.png|Healthcare Information Exchange model v1.0.png]]
 
−
BgZ-compliant systems should use HCIMs with appropriate metadata, not only in exchange but also when recording and processing data. Since HCIMs do not have many mandatory items, a sparsely filled BgZ woudl easily be compliant for exchange. The need however is to be able to record, exchange and process the full HCIMs. Therefore, it is a requirement for a Storing System to register the full HCIMs, for an Exchanging System to provide the full HCIMs and for a Processing System to process the entire zib.
 
  
−
Further requirements are specified in:
+
===Transactions===
−
* the HCIM definitions and technical artefacts
+
The "Exchange BgZ for Referral" use case can be implemented using two types of transactions:
−
* the [[BgZ:Vprepub-1.0_Kwalificatie | Qualification Scenario's]]
+
* Notified Pull (preferred)
−
* in the [[#Metadata|Metadata]] section below.
+
* Push
 +
====Exchange BgZ for Referral using Notified Pull Transaction====
 +
The Notified Pull transaction is based on the description in [3]. The Referring (Sending) Medical Specialist notifies the Receiving Medical Specialist about the referral or transfer by sending a Notification Message. The Receiving Medical Specialist can then retrieve the BgZ (at a suitable time) using the Pull Message(s) which is(are) defined as a part of the Notification Message.
  
−
=Metadata=
+
[[Image:UC Notified Pull-2.jpg|Use Case - Notified Pull]]
−
The [[BgZ:Vprepub-1.0_BgZ_MSZ_Informatiestandaard#Metagegevens|functional description]] requires metadata for the BgZ. This chapter outlines the technical implementation of those metadata.
 
−
==Document metadata==
 
−
For CDA Documents, the following metadata are mandatory (i.e. must always be present in the BgZ).
 
−
* ClinicalDocument/id: the identifier of the entire BgZ document.
 
−
* ClinicalDocument/effectiveTime: the date and time the BgZ was generated.
 
−
* ClinicalDocument/recordTarget/patientRole/id: the id of the Patient who is subject of this BgZ.
 
−
* ClinicalDocument/author/assignedAuthor/representedOrganization/id: the BgZ will rarely have a human as author. Nevertheless, author is required in CDA. Multiple authors are allowed. One should be the same as the custodian for the BgZ.
 
−
* ClinicalDocument/custodian/assignedCustodian/representedCustodianOrganization/id: the organization who has generated this BgZ.
 
  
−
These items loosely correspond with the BasicElements:
+
This two stage approach separates the notification phase from the actual BgZ retrieval phase allowing the Receiving Medical Specialist to decide if, and when, to retrieve the BgZ.
−
* IdentificationNumber
 
−
* DateTime
 
−
* Subject
 
−
* Author
 
−
* Information Source
 
−
They are not the same, since the BasicElements are about HCIMs and not documents. When HCIM do not carry sufficient metadata (see: [[#Historical and Absent Metadata|Historical and Absent Metadata]] below), the document metadata can provide the necessary context.
 
  
−
==HCIM (zib) metadata==
+
TODO: Linked to be added to the generic description of the Notified Pull communication pattern...
−
===Basic Elements===
 
−
The 2017 HCIM all have the following implicit Basic Elements which provide metadata:
 
−
====IdentificationNumber====
 
−
Identification is usually required for deduplication and unambiguous identification of data. Most HCIMs do not provide identification, so Problems, Procedures, Medication etc. need an IdentificationNumber. Some HCIM (such as Patient) already have an IdentificationNumber, and need no additional metadata. For some (Contact Persons) use of BSN is not permitted, and providing another non-unique id is not desirable (How could one keep that consistent over organizations?) Identification only makes sense when data has a single clear origin. In some other cases, identification is of little added value. I.e. for Body Weight, the datetime when it was recorded should suffice. To provide an additional "Body Weight id" to deduplicate Body Weight records is of little added value.
 
−
====DateTime====
 
−
Quite often HCIMs already have some DateTime. The relevant datetime usually is that of the event itself (say a surgery or medication administration), not of the recording of the event. For the BgZ, all relevant datetimes are already part of the HCIM. The others do not have to be provided (i.e., a Patients Contact Person carries no relevant datetime).
 
−
====Subject====
 
−
Subject is always implicit in the BgZ. It is always the Patient itself, except for Contact Persons and Health Professionals/Organizations, where the entire HCIM relates to the Patient and the data items therein of course pertain to the Contact Persons and Health Professionals/Organizations in question. The subject thus does not have to be separately stored, assuming the data will be stored in a Patient Record anyway, though exchange formats (certainly FHIR) may require the Patient resource to be part of exchanged data.
 
  
−
====Author and Information Source====
+
The Workflow (Task) message is optional in the BgZ MSZ exchange and no statement about it's inclusion is made by this Implementation Guide. However, in terms of system support the following rules apply:
−
The basic elements state:
+
# The Sending System can support either a standalone Notification (Task) message or the combined use of the Notification (Task) and Workflow (Task) messages.
−
* Information Source: The person who provided the information and ensures the correctness of it. The source of information does not have to be the author of the information, who in that case is only instrumental in capturing the information.
+
# The Receiving System must support both the Notification (Task) and Workflow (Task) messages.
−
* Author: The person who has recorded the information.
 
−
In the context of the BgZ, when the information source is an healthcare professional (or organization), the person who actually entered or recorded the information (data enterer, capturer) etc. is never relevant. A healthcare professional as information source is is responsible for the medical data, and the organization is responsible for the proper recording and exchange: this should never be an individuals responsibility. The only case where author can be relevant is when the patient is the source of information. In such cases, optionally, the "Patient as author" is provided, and responsible healthcare professional as Information Source.
 
  
−
In CDA, there are the following header participants in a CDA Document:
+
The FHIR profiles describing the Notification (Task) message, the Workflow (Task) message and the retrieved BgZ item resources are defined in the [[#FHIR_Profiles| FHIR Profiles]] section.
−
* Author: A party that originates the Act and therefore has responsibility for the information given in the Act.
 
−
* DataEnterer: A person entering the data into the originating system.
 
−
Therefore, HCIM:Author corresponds more with CDA:dataEnterer and HCIM:InformationSource corresponds more with Author. Be aware of this collision of terminology!
 
  
−
FHIR does not always clearly distinguish Author and Information Source. FHIR Observations, for instance,  have a single 'performer' which can be a Patient or a Professional. It is often not be possible (nor needed) to exchange both Information Source and Author in FHIR. Usually the correct reading of the 'responsible person' present in FHIR is Information Source.
+
The FHIR search/read queries used to retrieve the BgZ item resources are defined in the [[#FHIR_Task.input_Query_Specification| FHIR Task.input Query Specification]] section.
  
−
For almost all records either is relevant. Some listed exceptions are Patient, Contact Person, Payer. In other cases information which typically originates with the Patient, and which is recorded in the anamnesis, the preferred Basic Element to store the fact that the data is provided by the Patient is Information Source. When the information typically originates from a Healthcare Professional, such as a diagnosis, that professional is the Information Source. It is never required to provide both an Author and an Information Source when both are the same, i.e. it is not necessary to state that a diagnosis has the same doctor as Information Source AND Author, or that the Patient is Information Source AND Author of an Alcohol Use statement.
+
====Exchange BgZ for Referral using Push Transaction====
 +
The Referring (Sending) Medical Specialist pushes the BgZ to the Receiving Medical Specialist at the time of referral or transfer and not necessarily at the time when the Receiving Medical Specialist requires the BgZ (if it is required at all).  
  
−
====System Requirements for Metadata====
+
[[Image:UC Push.jpg|Use Case - Push]]
 +
 
 +
The Push method always transfers the BgZ to the Receiving Medical Specialist even when it might not be wanted or needed.
 +
 
 +
The FHIR profiles describing the BgZ item resources are defined in the [[#FHIR_Profiles| FHIR Profiles]] section.
 +
 
 +
Note: The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR where the CDA based BgZ is replaced by a FHIR Composition and pushed between sending and receiving systems.
 +
 
 +
==Retrieval of BgZ from previous practitioner (out of scope V2.0)==
 +
In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) is aware that the patient has had some previous treatment (through, for example, information provided by the patient) and takes the initiative to retrieve the details of this previous treatment from the previous care institution.
 +
===Actors===
 
{| class="wikitable"
 
{| class="wikitable"
 +
! colspan="2" style="text-align:left;" | Persons
 +
! colspan="2" style="text-align:left;" | Systems
 
|-
 
|-
−
! Required
+
! style="text-align:left;" |Name
−
||
+
! style="text-align:left;" |Description
−
* A '''Storing System''' MUST be able to persistently store these metadata item when the data originates within the organization
+
! style="text-align:left;" |Name
−
* An '''Exchanging System''' MUST be able to provide the persistent metadata items in the BgZ
+
! style="text-align:left;" |Description
−
* A '''Processing System''' MUST be able to persistently store the received metadata items
 
−
* A '''Reusing System''' SHOULD only display medically relevant metadata to the healthcare professional (which excludes identifiers which are not meaningful to an end user)
 
 
|-
 
|-
−
! Optional
+
| Requesting Medical Specialist
−
|| This is for metadata items which are not crucial to interoperability. I.e. when a measurement already has an Author, the Information Source is not relevant.
+
| Medical specialist who queries for a BgZ
−
|-
+
| EHR
−
! Not relevant
+
| Electronic health record
−
|| For certain HCIMs the metadata items are not important. I.e. for the contact persons of a Patient, it is not relevant who or when recorded this.
+
|}
−
|-
+
It is assumed that the Requesting Medical Specialist, as person who uses the BgZ sharing infrastructure, is signed on, authenticated and has authorization & consent to access the necessary (patient) information stored in the BgZ sharing infrastructure (or in other words, an authenticated healthcare professional who has an active treatment relationship with the patient). The way in which the person achieves this state is beyond the scope of this implementation guide but is expected to be facilitated by use of the generic infrastructure.
−
! Named data elements
+
 
−
|| Often the metadata items from the Basic Elements are already present in the HCIM itself. In this case these data items double as metadata, i.e. there is no need for a separate metadata item. All those metadata items are considered '''Required'''.
+
===Transactions===
 +
====Retrieval of BgZ from previous practitioner using Pull Transaction====
 +
The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message.  
 +
 
 +
[[Image:UC Pull-1.jpg|Use Case - Pull]]
 +
 
 +
The FHIR profiles describing the retrieved BgZ item resources are defined in the [[#FHIR_Profiles| FHIR Profiles]] section.
 +
 
 +
The FHIR search/read queries used to retrieve the BgZ item resources are defined in the [[#FHIR_Task.input_Query_Specification| FHIR Task.input Query Specification]] section. The '''Task.input.value[x]''' definitions define the query search/read values to use.
 +
 
 +
=FHIR Profiles=
 +
Note: These FHIR Profiles are under review and will be finalized by the beta version of the TO.
 +
 
 +
==FHIR Notification Task==
 +
A BgZ MSZ Notification Task instance is created in the Receiving System by the Sending System issuing an HTTP POST operation to the Receiving System.
 +
 
 +
The following table identifies the location of the Notification Task FHIR profile.
 +
 
 +
{| class="wikitable" style="horizontal-align: right"
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | FHIR Resource
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:400px" | FHIR Profile
 +
|-
 +
| (Notification) Task
 +
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/bgz-msz-notification-task-location-to-be-added}}
 +
|}
 +
 
 +
==FHIR Workflow Task==
 +
If the Sending System supports the management of the BgZ MSZ information exchange, it will create a Workflow Task instance locally, and include details of the Workflow Task in the Notification Task exchanged with the Receiving System. The Recieving System can retrieve the Workflow Task by issuing an HTTP GET operation to the Sending System.
 +
 
 +
The following table identifies the location of the Workflow Task FHIR profile.
 +
 
 +
{| class="wikitable" style="horizontal-align: right"
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | FHIR Resource
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:400px" | FHIR Profile
 +
|-
 +
| (Workflow) Task
 +
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/bgz-msz-workflow-task-location-to-be-added}}
 +
|}
 +
 
 +
==FHIR Task Patient Identification==
 +
Although a patient is formally identified by their BSN in the BgZ MSZ information standard, this patient identifier is never exchanged as part of either the Notification Task or Workflow Task content. Instead, an "authorization base" token is exchanged, which only gives access by the Receiving System to specific data of a single patient managed by the Sending System.
 +
 
 +
The authorization base token is exchanged as one of the Task.input parameters in the Notification Task with a format as shown in the table below.
 +
 
 +
{| class="wikitable" width="100%" style="horizontal-align: right"
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | FHIR Task.input.type
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | FHIR Task.input.value[x] as valueString
 
|-
 
|-
−
! Other / textual
+
| <pre>
−
|| On other cases textual clarification is given in the table.
+
codeSystem: http://fhir.nl/fhir/NamingSystem/TaskParameter
 +
code: authorization-base</pre>
 +
| <pre>authorization base token value (encrypted)</pre>
 
|}
 
|}
  
−
{{NoteBox|Example '''Procedure'''
+
==FHIR Task.input Query Specification==
 +
The following table provides the overview of the FHIR query (read/search) operations needed to retrieve all the BgZ MSZ items. These queries will be specified as '''Task.input''' (type and value[x]) parameters.
  
−
For a Procedure which is recorded in a Storing System (i.e. which originates in the organization), the system:
+
The '''Type''' column defines the type of query:
−
* MUST generate and store an Identifier
+
* '''Read''' - query for a single referenced FHIR resource instances where value[x] is a '''valueReference'''.
−
* MUST record and store the ProcedureStartDate
+
* '''Search''' - query for one or more FHIR resource instances where value[x] is a '''valueString''' representing the search string.
−
* MUST record and store the Performer::HealthProfessional
 
−
* the Subject is implicit (this is the Patients record)
 
−
* the Author is optional.}}
 
  
−
{{NoteBox|Example '''LivingSituation'''  
+
The '''Code''' (FHIR Task.input.type) column defines codedConcepts that identify the BgZ MSZ item (HCIM) to retrieve. Each codedConcept is defined in terms of the codeSystem, code and display name.
 +
'''NOTE''': All codedConcepts/identifiers are defined by the Terminology Association in each HCIM - see ART DECOR [https://decor.nictiz.nl/ad/#/bgz2017-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.42.1.2/2024-03-19T12:04:40 BgZ MSZ Dataset]
 +
The values are copied into this table for completeness/readability purposes.
  
−
For a LivingSituation which is recorded in a Storing System (i.e. which originates in the organization), the system must:
+
The '''Value''' (FHIR Task.input.value[x]) column defines the query performed to retrieve the identified BgZ MSZ item.
−
* MAY generate and store an Identifier: but this will be of little use in deduplication, since the LivingSituation is a simply coded type (such as "FLATW") without start- and end-data, so deduplication can simply be done on content
 
−
* MAY record and store a date of registration - but this is not part of the exchanged data
 
−
* MAY record and store an Author or InformationSource, but this is optional for the exchanged data
 
−
* the Subject is implicit (this is the Patients record).}}
 
  
−
====Historical and Absent Metadata====
+
The same Task.input parameters are applicable to the Notification Task or the Workflow Task depending on which is used to specify the BgZ MSZ retrieval operation.
−
For historical data, the appropriate metadata may simply no be available. In those cases those metadata items MUST NOT be exchanged, unless they are also persisted in the source system. In cases where HCIMs are received from another organization, and metadata are absent or incomplete, the metadata SHOULD NOT be exchanged when sending to yet another organization (i.e. one should not invent identifiers when one is not the original source of the data).
 
  
−
===Metadata table===
+
'''NOTE to information standard reviewers: This is table defines the core BgZ MSZ Notified Pull contents and must be reviewed, accepted and adopted by all stakeholders. Please review very carefully.'''
−
Metadata are often already present in the HCIMs themselves: in that case there is no need to add them to the HCIM again. In other cases, the metadata is not relevant. The table below lists the various Basic Elements against the HCIMs.
 
  
−
{| class="wikitable" style="horizontal-align: right"  
+
{| class="wikitable" width="100%" style="horizontal-align: right"
−
! Id
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | BgZ Section
−
! Zib
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | HCIM
−
! HCIM
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | Type
−
! IdentificationNumber
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | Code
−
! DateTime
+
(FHIR Task.input.type)
−
! Author
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | Value
−
! Subject
+
(FHIR Task.input.value[x])
−
! InformationSource
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | Description
 
|-
 
|-
−
| '''NL-CM:0.1.1'''
+
| 1 Patient information
 
| Patient
 
| Patient
−
| Patient
+
| Search
−
| PatientIdentificationNumber
+
| <pre>
−
| DateOfBirth
+
http://snomed.info/sct
−
| Not Relevant
+
116154003
−
| Patient
+
"Patient"</pre>
−
| Not Relevant
+
or
 +
<pre>
 +
http://loinc.org
 +
79191-3
 +
"Patient demographics panel"</pre>
 +
| <pre>GET [base]/Patient?
 +
_include=Patient:general-practitioner</pre>
 +
| The Receiving System gets the patient identification, birth date, gender, deceased indicator, contact details, last known marital status, and general practitioner (practitioner or organization) that has been registered in the Sending System.
 +
* Condition: Last Known Marital Status
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:1.1.1'''
+
| 2 Payment details
−
| Betaler
 
 
| Payer
 
| Payer
−
| BankCode+AccountNumber OR IdentificationNumber+InsurantNumber
+
| Search
−
| StartDateTime+EndDateTime
+
| <pre>
−
| Not Relevant
+
http://loinc.org
−
| Patient
+
48768-6
−
| Not Relevant
+
"Payment sources document"</pre>
 +
| <pre>GET [base]/Coverage?
 +
_include=Coverage:payor:Patient&
 +
_include=Coverage:payor:Organization</pre>
 +
| The Receiving System gets the patient's insurance information that has been that has been registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:2.1.1'''
+
| rowspan="2" | 3 Treatment directives
−
| BehandelAanwijzing
+
| Treatment Directive
−
| TreatmentDirective
+
| Search
−
| Required
+
| <pre>
−
| VerificationDate
+
http://snomed.info/sct
−
| Optional
+
11291000146105
−
| Patient
+
"Treatment instructions"</pre>
−
| Patient OR patient's authorized representative
+
| <pre>GET [base]/Consent?
 +
category=http://snomed.info/sct|11291000146105</pre>
 +
| The Receiving System gets the most recent version of all Treatment Directives that have been registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:7.15.1'''
+
| Advance Directive
−
| Wilsverklaring
+
| Search
−
| AdvanceDirective
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| LivingWillDate
+
11341000146107
−
| Optional
+
"Living will and advance directive record"</pre>
−
| Patient
+
| <pre>GET [base]/Consent?
−
| Patient OR patient's authorized representative
+
category=http://snomed.info/sct|11341000146107</pre>
 +
| The Receiving System gets the most recent version of all Advance Directives that have been registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:3.1.1'''
+
| 4 Contact persons
−
| Contactpersoon
+
| Contact Person
−
| Contactperson
+
| Search
−
| Not Relevant
+
| <pre>
−
| Not Relevant
+
http://snomed.info/sct
−
| Not Relevant
+
70862002
−
| Contactpersoon
+
"Contact person"</pre>
−
| Not Relevant
+
| <pre style="font-style: italic;">see Patient</pre>
 +
| The Receiving System gets the most recent version of the primary partner/contact that was last registered in the Sending System.
 +
* Condition: Primary partner/contact
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:4.26.1'''
+
| 5 Functional or Mental status
−
| FunctioneleOfMentaleStatus
+
| Functional Or Mental Status
−
| FunctionalOrMentalStatus
+
| Search
−
| Required
+
| <pre>
−
| StatusDate
+
http://loinc.org
−
| Optional
+
47420-5
−
| Patient
+
"Functional status assessment note"</pre>
−
| Required
+
| <pre>GET [base]/Observation/$lastn?
 +
category=http://snomed.info/sct|118228005,
 +
http://snomed.info/sct|384821006</pre>
 +
| The Receiving System gets, per StatusName, the most recent version of the FunctionalOrMentalStatus that was last registered in the Sending System.
 +
Specifically, if available, these are the last known status of the functions: mental, hearing, vision, mobility and language skills.
 +
* Condition: Last known status of a function
 +
* Cardinality: 0..*
 
|-
 
|-
−
| '''NL-CM:5.1.1'''
+
| 6 Problems
−
| Probleem
 
 
| Problem
 
| Problem
−
| Required
+
| Read
−
| ProblemStartDate
+
| <pre>
−
| Optional
+
http://loinc.org
−
| Patient
+
11450-4
−
| Required
+
"Problem list - Reported"</pre>
 +
| <pre>GET [base]/Condition</pre>
 +
| The Receiving System gets the most recent version of all issues that have been registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:7.8.1'''
+
| rowspan="5" | 7 Social history
−
| Woonsituatie
+
| Living Situation
−
| LivingSituation
+
| Search
−
| Optional
+
| <pre>
−
| Not Relevant
+
http://snomed.info/sct
−
| Not Relevant
+
365508006
−
| Patient
+
"Finding of residence and accommodation circumstances"</pre>
−
| Optional
+
| <pre>GET [base]/Observation/$lastn?
 +
code=http://snomed.info/sct|365508006</pre>
 +
| The Receiving System gets the most recent version of the living situation that was last registered in the Sending System.
 +
This does not have to be the Living Situation that has been updated most recently.
 +
* Condition: If available, the last known living situation.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:7.4.1'''
+
| Drug Use
−
| DrugsGebruik
+
| Search
−
| DrugUse
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| StartDate
+
228366006
−
| Optional
+
"Finding relating to drug misuse behavior"</pre>
−
| Patient
+
| <pre>GET [base]/Observation?
−
| Required
+
code=http://snomed.info/sct|228366006</pre>
 +
| The Receiving System gets, for each Drug Or Drug Type, the most recent version of the Drug Use that was last registered in the Sending System.
 +
This does not have to be the Drug Use that has been updated most recently.
 +
* Condition: If available, the last known drug use for each Drug Or Drug Type.
 +
* Cardinality: 0..*
 
|-
 
|-
−
| '''NL-CM:7.3.1'''
+
| Alcohol Use
−
| AlcoholGebruik
+
| Search
−
| AlcoholUse
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| StartDate
+
228273003
−
| Optional
+
"Finding relating to alcohol drinking behavior"</pre>
−
| Patient
+
| <pre>GET [base]/Observation?
−
| Required
+
code=http://snomed.info/sct|228273003</pre>
 +
| The Receiving System gets the most recent version of the Alcohol Consumption that was last registered in the Sending System.
 +
This does not have to be the Alcohol Consumption that has been updated most recently.
 +
* Condition: If available, last known alcohol consumption.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:7.2.1'''
+
| Tobacco Use
−
| TabakGebruik
+
| Search
−
| TobaccoUse
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| StartDate
+
365980008
−
| Optional
+
"Finding of tobacco use and exposure"</pre>
−
| Patient
+
| <pre>GET [base]/Observation?
−
| Required
+
code=http://snomed.info/sct|365980008</pre>
 +
| The Receiving System gets the most recent version of the Tobacco Use that was last registered in the Sending System.
 +
This does not have to be the Tobacco Use that has been updated most recently.
 +
* Condition: If available, last known tobacco use.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:7.11.1'''
+
| Nutrition Advice
−
| Voedingsadvies
+
| Search
−
| NutritionAdvice
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| Not Relevant
+
11816003
−
| Optional
+
"Dietary advice"</pre>
−
| Patient
+
| <pre>GET [base]/Observation?
−
| Required
+
code=http://snomed.info/sct|300893006</pre>
 +
<small>NOTE: Query 1.x is: GET [base]/NutritionOrder</small>
 +
| The Receiving System gets, for each Diet Type, the most recent version of the Nutritional Advice that was last registered in the Sending System.
 +
This does not have to be the Nutritional Advice that has been updated most recently for each Diet Type.
 
|-
 
|-
−
| '''NL-CM:8.3.1'''
+
| 8 Alerts
 
| Alert
 
| Alert
−
| Alert
+
| Read
−
| Required
+
| <pre>
−
| StartDateTime
+
http://loinc.org
−
| empty OR equal to Source
+
75310-3
−
| Patient
+
"Health concerns document"</pre>
−
| Required
+
| <pre>GET [base]/Flag</pre>
 +
| The Receiving System gets the most recent version of all Alerts registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:8.2.1'''
+
| 9 Allergies
−
| AllergieIntolerantie
+
| Allergy Intolerance
−
| AllergyIntolerance
+
| Read
−
| Required
+
| <pre>
−
| StartDateTime
+
http://loinc.org
−
| empty OR equal to Source
+
48765-2
−
| Patient
+
"Allergies and adverse reactions document"</pre>
−
| Required
+
| <pre>GET [base]/AllergyIntolerance</pre>
 +
| The Receiving System gets the most recent version of all allergies registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:9.6.9580'''
+
| rowspan="3" | 10 Medication
−
| Medicatieafspraak
+
| Medication Use2
−
| MedicationAgreement
+
| Search
−
| Required
+
| <pre>
−
| MedicationAgreementDateTime
+
http://snomed.info/sct
−
| empty OR equal to Source
+
422979000
−
| Patient
+
"Medication regimen behavior finding"</pre>
−
| Prescriber::HealthProfessional
+
| <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>
 +
| Known medication use
 
|-
 
|-
−
| '''NL-CM:9.8.20132'''
+
| Administration Agreement
−
| Toedieningsafspraak
+
| Search
−
| AdministrationAgreement
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| AdministrationAgreementDateTime
+
422037009
−
| empty OR equal to Source
+
"Provider medication administration instructions"</pre>
−
| Patient
+
| <pre>GET [base]/MedicationDispense?
−
| Supplier::HealthProfessional
+
category=http://snomed.info/sct|422037009&
 +
_include=MedicationDispense:medication</pre>
 +
| Known administration agreements
 
|-
 
|-
−
| '''NL-CM:9.11.21338'''
+
| Medication Agreement
−
| MedicatieGebruik
+
| Search
−
| MedicationUse2
+
| <pre>
−
| Required
+
http://snomed.info/sct
−
| MedicationUseDateTime
+
16076005
−
| empty OR equal to Source
+
"Prescription"</pre>
−
| Patient
+
| <pre>GET [base]/MedicationRequest?
−
| Prescriber::HealthProfessional
+
category=http://snomed.info/sct|16076005&
 +
_include=MedicationRequest:medication</pre>
 +
| Known medication agreements
 
|-
 
|-
−
| '''NL-CM:10.1.1'''
+
| 11 Medical aids
−
| MedischHulpmiddel
+
| Medical Device
−
| MedicalDevice
+
| Read
−
| ProductID
+
| <pre>
−
| StartDate
+
http://snomed.info/sct
−
| empty OR equal to Source
+
49062001
−
| Patient
+
"Device (physical object)"</pre>
−
| HealthProfessional
+
or
 +
<pre>
 +
http://loinc.org
 +
46264-8
 +
"Known medical aids"</pre>
 +
| <pre>GET [base]/DeviceUseStatement?
 +
_include=DeviceUseStatement:device</pre>
 +
| The Receiving System gets the most recent version of all medical aids (devices) registered in the Sending System.
 
|-
 
|-
−
| '''NL-CM:11.1.1'''
+
| 12 Vaccinations
−
| Vaccinatie
 
 
| Vaccination
 
| Vaccination
−
| ProductCode+VaccinationDate
+
| Read
−
| VaccinationDate
+
| <pre>
−
| empty OR equal to Source
+
http://loinc.org
−
| Patient
+
11369-6
−
| Administrator::Healthprofessional
+
"History of Immunization Narrative"</pre>
 +
| <pre>GET [base]/Immunization?
 +
status=completed</pre>
 +
| The Receiving System gets the most recent version of all vaccinations registered in the Sending System.
 +
|-
 +
| rowspan="3" | 13 Vital signs
 +
| Blood Pressure
 +
| Search
 +
| <pre>
 +
http://loinc.org
 +
85354-9
 +
"Blood pressure"</pre>
 +
| <pre>GET [base]/Observation/$lastn?
 +
code=http://loinc.org|85354-9</pre>
 +
| The Receiving System gets the most recent version of the blood pressure that was last registered in the Sending System.
 +
* Condition: Last known blood pressure.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:12.4.1'''
+
| Body Weight
−
| Bloeddruk
+
| Search
−
| BloodPressure
+
| <pre>
−
| BloodPressureDateTime
+
http://loinc.org
−
| BloodPressureDateTime
+
29463-7
−
| empty OR equal to Source
+
"Body weight"</pre>
−
| Patient
+
| <pre>GET [base]/Observation/$lastn?
−
| Required
+
code=http://loinc.org|29463-7</pre>
 +
| The Receiving System gets the most recent version of the body weight that was last registered in the Sending System.
 +
* Condition: Last known body weight.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:12.1.1'''
+
| Body Height
−
| Lichaamsgewicht
+
| Search
−
| BodyWeight
+
| <pre>
−
| WeightDateTime
+
http://loinc.org
−
| WeightDateTime
+
8302-2
−
| empty OR equal to Source
+
"Body height"</pre>
−
| Patient
+
| <pre>GET [base]/Observation/$lastn?
−
| Required
+
code=http://loinc.org|8302-2,
 +
http://loinc.org|8306-3,
 +
http://loinc.org|8308-9</pre>
 +
| The Receiving System gets the most recent version of the body height that was last registered in the Sending System.
 +
* Condition: Last known body height.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:12.2.1'''
+
| 14 Results
−
| Lichaamslengte
+
| Laboratory Test Result
−
| BodyHeight
+
| Search
−
| HeightValue OR HeightDateTime
+
| <pre>
−
| HeightDateTime
+
http://snomed.info/sct
−
| empty OR equal to Source
+
15220000
−
| Patient
+
"Laboratory test"</pre>
−
| Required
+
| <pre>GET [base]/Observation/$lastn?
 +
category=http://snomed.info/sct|118246004&
 +
_include=Observation:related-target&
 +
_include=Observation:specimen</pre>
 +
<small>NOTE: Query 1.x is: GET [base]/Observation/$lastn?
 +
category=http://snomed.info/sct|275711006&
 +
_include=Observation:related-target&
 +
_include=Observation:specimen</small>
 +
| The Receiving System gets the most recent version of the Laboratory Test last registered for all "Laboratory" observations, per Laboratory Test Code in the Sending System. The selected laboratory tests are grouped via the Laboratory Result. The optional result Type of the Laboratory Result is not used for filtering, only the LOINC Test Code. The result Type will be sent along with the data if available.
 +
* Condition: Last known test for all results.
 +
* Cardinality: 0..1
 
|-
 
|-
−
| '''NL-CM:14.1.1'''
+
| 15 Procedures
−
| Verrichting
 
 
| Procedure
 
| Procedure
−
| Required
+
| Search
−
| ProcedureStartDate
+
| <pre>
−
| empty OR equal to Source
+
http://snomed.info/sct
−
| Patient
+
71388002
−
| Performer::HealthProfessional
+
"Procedure"</pre>
 +
or
 +
<pre>
 +
http://loinc.org
 +
47519-4
 +
"History of Procedures"</pre>
 +
| <pre>GET [base]/Procedure?
 +
category=http://snomed.info/sct|50731006</pre>
 +
<small>NOTE: Query 1.x is: GET [base]/Procedure?
 +
category=http://snomed.info/sct|387713003</small>
 +
| The Receiving System gets the most recent version of all procedures registered in the Sending System. This includes all operative and diagnostic procedures, including outpatient surgeries/operations.
 
|-
 
|-
−
| '''NL-CM:15.1.1'''
+
| 16 Encounters
−
| Contact
 
 
| Encounter
 
| Encounter
−
| ContactType + StartDateTime
+
| Search
−
| StartDateTime
+
| <pre>
−
| empty OR equal to Source
+
http://loinc.org
−
| Patient
+
46240-8
−
| ContactWith::HealthProfessional
+
"History of Hospitalizations+Outpatient visits Narrative"</pre>
 +
| <pre>GET [base]/Encounter?
 +
class=http://snomed.info/sct|308335008</pre>
 +
<small>NOTE: Query 1.x is: GET [base]/Encounter?
 +
class=http://hl7.org/fhir/v3/ActCode|IMP,
 +
http://hl7.org/fhir/v3/ActCode|ACUTE,
 +
http://hl7.org/fhir/v3/ActCode|NONAC</small>
 +
| The Receiving System gets the most recent version of all contacts registered in the Sending System. This also includes outpatient contacts where the reason for the contact is an outpatient operation, such as the removal of osteosynthesis material after a bone fracture. All hospital admissions and contacts with a reference to a transaction or a problem are included. Origin and destination are not exchanged.
 +
|-
 +
| rowspan="2" | 17 Care Setting
 +
| Healthcare Provider
 +
| Read
 +
| <pre>
 +
http://snomed.info/sct
 +
229774002
 +
"Caregiver"</pre>
 +
| <pre>GET [base]/CareTeam?
 +
_include=CareTeam:participant</pre>
 +
| The Receiving System gets the most recent version of all available caregivers registered in the Sending System. This includes at least the care providers with a current treatment relationship and, if available, care providers who are appointed in the contacts and operations that are controlled with the BgZ.
 
|-
 
|-
−
| '''NL-CM:17.1.1'''
+
| Healthcare Location
−
| Zorgverlener
+
| Read
−
| HealthProfessional
+
| <pre>
−
| HealthProfessionalIdentificationNumber
+
http://snomed.info/sct
−
| Not Relevant
+
43741000
−
| Not Relevant
+
"Site of care"</pre>
−
| HealthProfessional
+
| <pre>GET [base]/?????</pre>
−
| Not Relevant
+
| The Receiving System gets the most recent version of all available healthcare providers registered in the Sending System. This includes at least the care providers who are appointed in the contacts and transactions that are sent with the BgZ.
 
|}
 
|}
 +
<small>''Table 5.1 FHIR Task.input Query Specification''</small>
  
−
=Reconciliation=
+
==Referenced BgZ FHIR Resources==
−
Metadata provides the opportunity for reconciliation: combining patient data from multiple sources in a consistent and integrated way. This may involve:
+
The profiles represent their entire respective HCIM, to make them applicable in a broader context than the exchange of BgZ or a MedMij context. An example of reuse of existing profiles is those of the patient administration resources and vital signs.
−
* receiving information, such as a BgZ, from another source and integrating that in one's own EHR;
 
−
* retrieving information from multiple sources, and showing that in a consistent and unambiguous way.
 
−
 
 
−
Reconciliation involves the following.
 
−
* '''De-duplication''': data item X may be available from multiple sources, and should only be shown once. De-duplication is possible through '''consistent identifiers''' across data custodians.
 
−
* '''Semantic interpretation''': data items from multiple sources should be classified in a consistent way, which is interoperable across sources. Semantic interoperability is possible through the use of consistent '''classification and terminologies'''. The HCIMs themselves, along with "Eenheid van Taal" (Unity of Language) terminology services already provide the necessary level of semantic interoperability.
 
−
* '''Provenance''': it should be clear which data originates where, and the original source should be traceable and (where still possible) approachable. Provenance is achieved through '''authorship and information source'''.
 
−
* '''Attribution''': patient data is a statement: usually a fact that something is the matter about something or someone at some point in time. '''Subject and date/time''' information allow the data item to be related to the real world.
 
−
==Persistent identifiers==
 
−
CDA has identifiers of the following form, where root must be an oid and extension is some local string value.:
 
−
<nowiki>
 
−
  <id extension="1A2B3C" root="2.16.840.1.113883.2.4.3.46.20"/>
 
−
</nowiki>
 
−
 
 
−
FHIR has identifiers of the following form, where system is some uri and value is some local string value.:
 
−
<nowiki>
 
−
  <identifier>
 
−
    <system value="http://www.example.org" />
 
−
    <value value="1A2B3C" />
 
−
  </identifier>
 
−
</nowiki>
 
−
 
 
−
It is strongly recommended to use FHIR identifiers of the following form in the BgZ, where the oid is the same as the oid used in CDA-based exchanges. :
 
−
<nowiki>
 
−
  <identifier>
 
−
    <system value="urn:oid:2.16.840.1.113883.2.4.3.46.20" />
 
−
    <value value="1A2B3C" />
 
−
  </identifier>
 
−
</nowiki>
 
−
This greatly facilitates interoperability between FHIR and CDA.
 
−
{{NoteBox|When reconciling data from multiple sources, persistent identifiers MAY be used for the de-duplication of data. Systems may, however,  choose to display duplicate data.}}
 
−
{{NoteBox|When storing reconciled data from another source, persistent identifiers MUST be stored as well.}}
 
−
 
 
−
==Re-identification==
 
−
When a record is received from another organization, it should be persisted with the identifiers of the source. However, when the record is updated, the Storing System:
 
−
* MUST issue a new Identifier, following their own identification mechanisms
 
−
* MUST assign its own professional and/or organization as Information Source
 
−
{{NoteBox|Example: a Patient is diagnosed at Hospital A by doctor X as having a Problem: Fracture of wrist, with a start date. The Patient is transferred to another hospital, and the BgZ is sent along. The Problem is there stored in the EHR with the original identifier, and doctor X from hospital A as Information Source. The Patient is treated, and the fracture is healed. Doctor Y changes the Problem to 'inactive', and adds an end date. The system in hospital B must now supply its own identifier, and record doctor Y from hospital B as Information Source. Doctor B, and hospital B are responsible for the entire new record.}}
 
−
As of yet, HCIMs and the BgZ do not provide a reliable mechanism to record and exchange shared responsibility and treatment across organizations, and there is no way to record different individuals are responsible for different steps in the lifecycle of an HCIM. This should therefore not be attempted.
 
−
 
 
−
==Provenance==
 
−
Every data item is a statement, an assertion of a fact, recorded by someone somewhere. This original source should be retained when integrating data from multiple sources. The source can be:
 
−
# An individual as Information Source of the statement. This is the InformationSource from the zib. In CDA of FHIR this is the corresponding element when a person is populating this element. Examples:
 
−
#* a health professional makes a diagnosis
 
−
#* a patient reports alcohol and tobacco use
 
−
# An organization as Information Source of the statement. This is the InformationSource from the zib. In CDA of FHIR this is the corresponding element when an organization person is populating this element. Examples:
 
−
#* a lab reports certain chemical or biological measurements on a specimen
 
−
# A XIS as the information source. This is the custodian a CDA document, and the XIS from which the HCIM was retrieved in FHIR (possibly other elements are suitable, as in XDS based exchanges or FHIR Documents). in Examples:
 
−
#* a BgZ is received from a XIS, and the contact persons of the patient are listed without further author or source;
 
−
#* a record is retrieved from a XIS, and the historical problems in the problem list do not have further author or source;
 
−
#* lab results are retrieved from a XIS, but the lab where the measurements were made is not provided;
 
−
Certainly for historical data the original source of the statement often is not retained. The order above is the preferred order: i.e. when an individual is known as information source, provide that individual. In the case of an healthcare professional, provide the healthcare organization and professionals role as well. When no individual is known, use the organization. When no organization is known, use the originating XIS as source.
 
−
{{NoteBox|When displaying reconciled data from multiple sources, provenance metadata MUST be available to the person viewing that data.}}
 
−
{{NoteBox|When storing reconciled data from another source, provenance metadata MUST be stored as well, in the order:
 
−
# responsible individual, when known, preferably with organization;
 
−
# responsible organization, when no individual is known;
 
−
# originating XIS, when no more specific organization is known.}}
 
−
 
 
−
==De-duplication==
 
−
De-duplication is not always possible when receiving consecutive records with the same identifiers but different content. It may not always be obvious which of those records is the most recent one. This standard does not require specific mechanisms for de-deduplication, but suggests the following heuristics:
 
−
* when a record is received from A and B, and A is listed as the information source in both, assume the record from A to be the most recent one;
 
−
* when a record is received from A, stored, and retrieved again from A, assume the latter is most recent one;
 
−
* when a record is received from B and C, and A is listed as the information source in both, assume the most recently received record is most recent one.
 
−
A Processing System can flag such conflicting records. When in doubt, a medical professional should decide, possibly after consulting colleagues.
 
−
=Implementation technologies=
 
−
==FHIR profiles==
 
−
The [[MedMij:V2020.01/FHIR_BGZ_2017#List_of_profiles|FHIR profiles defined for MedMij]] are also used for the BgZ.
 
  
−
==CDA templates==
 
−
The entire publication can be found at [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/ Basisgegevensset Zorg 2017 (BgZ)]
 
−
 
−
The following CDA templates are used for the BgZ 2017.
 
 
{| class="wikitable" style="horizontal-align: right"  
 
{| class="wikitable" style="horizontal-align: right"  
 
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:10px"  | Section
 
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:10px"  | Section
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:100px" | Titel
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:100px" | Zib NL
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:100px" | Title
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:100px" | HCIM EN
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:400px" | CDA Template
+
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:100px" | FHIR Resource
 +
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:400px" | FHIR Profile
 
|-
 
|-
−
| 0
+
| rowspan="2" | 1
−
| colspan="2" | BgZ
+
| Patient
−
| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.1-2021-11-29T000000.html Template  CDA Basisgegevensset Zorg 2017 (BgZ)]
+
| Patient
 +
| Patient
 +
| rowspan="2" | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 1. Demografie en identificatie
+
| BurgerlijkeStaat
−
| Demographics and identification
+
| MaritalStatus
−
| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.3-2021-11-29T000000.html CDArecordTargetSDTC-NL]
+
| Patient.maritalStatus
 
|-
 
|-
−
|
+
| rowspan="3" | 2
−
| [https://zibs.nl/wiki/Patient-v3.1(2017NL) Patient]
+
| rowspan="3" | Betaler
−
| [https://zibs.nl/wiki/Patient-v3.1(2017EN) Patient]
+
| rowspan="3" | Payer
−
|
+
| Coverage
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 2. Financiële informatie
+
| Organization
−
| Financial information
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.19-2017-02-05T000000.html BgZ2017Betaler]
 
 
|-
 
|-
−
|  
+
| Patient
−
| [https://zibs.nl/wiki/Betaler-v3.1(2017NL) Betaler]
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
−
| [https://zibs.nl/wiki/Payer-v3.1(2017EN) Payer]
 
−
|
 
 
|-
 
|-
−
| colspan="2" | 3. Behandelrestricties
+
| rowspan="2" | 3  
−
| Treatment Directives
+
| BehandelAanwijzing
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.4-2017-10-24T000000.html BgZ2017TreatmentDirectives]
+
| TreatmentDirective
 +
| Consent
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| rowspan="2" |
+
| Wilsverklaring
−
| [https://zibs.nl/wiki/BehandelAanwijzing-v3.1(2017NL) BehandelAanwijzing]
+
| AdvanceDirective
−
| [https://zibs.nl/wiki/TreatmentDirective-v3.1(2017EN) TreatmentDirective]
+
| Consent
−
|
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/Wilsverklaring-v3.1(2017NL) Wilsverklaring]
+
| 4
−
| [https://zibs.nl/wiki/AdvanceDirective-v3.1(2017EN) AdvanceDirective]
+
| Contactpersoon
−
|
+
| ContactPerson
 +
| Patient.contact
 +
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 4. Contactpersonen
+
| 5
−
| Contact persons
+
| FunctioneleOfMentaleStatus
−
| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.3-2021-11-29T000000.html CDArecordTargetSDTC-NL]
+
| FunctionalOrMentalStatus
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
|  
+
| 6
−
| [https://zibs.nl/wiki/Contactpersoon-v3.1(2017NL) Contactpersoon]
+
| Probleem
−
| [https://zibs.nl/wiki/ContactPerson-v3.1(2017EN) ContactPerson]
+
| Problem
−
|
+
| Condition
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 5. Functionele status
+
| rowspan="5" | 7
−
| Functional Status
+
| Woonsituatie
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.5-2017-10-24T000000.html BgZ2017FunctionalStatus]
+
| LivingSituation
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
|  
+
| DrugsGebruik
−
| [https://zibs.nl/wiki/FunctioneleOfMentaleStatus-v3.1(2017NL) FunctioneleOfMentaleStatus]
+
| DrugUse
−
| [https://zibs.nl/wiki/FunctionalOrMentalStatus-v3.1(2017EN) FunctionalOrMentalStatus]
+
| Observation
−
|
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 6. Klachten en diagnoses
+
| AlcoholGebruik
−
| Complaints and diagnoses
+
| AlcoholUse
−
| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.18-2018-01-20T000000.html Voorgeschiedenis]
+
| Observation
−
[http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.6-2017-10-24T000000.html BgZ2017ComplaintsAndDiagnoses]
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
|  
+
| TabakGebruik
−
| [https://zibs.nl/wiki/Probleem-v4.1(2017NL) Probleem]
+
| TobaccoUse
−
| [https://zibs.nl/wiki/Problem-v4.1(2017EN) Problem]
+
| Observation
−
|
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 7. Sociale anamnese
+
| Voedingsadvies
−
| Social anamnesis
+
| NutritionAdvice
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.7-2017-10-24T000000.html BgZ2017SocialAnamesis]
+
| NutritionOrder
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| rowspan="5" |  
+
| 8
−
| [https://zibs.nl/wiki/Woonsituatie-v3.1(2017NL) Woonsituatie]
+
| Alert
−
| [https://zibs.nl/wiki/LivingSituation-v3.1(2017EN) LivingSituation]
+
| Alert
−
|
+
| Flag
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/DrugsGebruik-v3.2(2017NL) DrugsGebruik]
+
| 9
−
| [https://zibs.nl/wiki/DrugUse-v3.2(2017EN) DrugUse]
+
| AllergieIntolerantie
−
|
+
| AllergyIntolerance
 +
| AllergyIntolerance
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/AlcoholGebruik-v3.1(2017NL) AlcoholGebruik]
+
| rowspan="3" | 10
−
| [https://zibs.nl/wiki/AlcoholUse-v3.1(2017EN) AlcoholUse]
+
| MedicatieGebruik2
−
|
+
| MedicationUse2
 +
| MedicationStatement
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/TabakGebruik-v3.1(2017NL) TabakGebruik]
+
| Medicatieafspraak
−
| [https://zibs.nl/wiki/TobaccoUse-v3.1(2017EN) TobaccoUse]
+
| MedicationAgreement
−
|
+
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/Voedingsadvies-v3.1(2017NL) Voedingsadvies]
+
| Toedieningsafspraak
−
| [https://zibs.nl/wiki/NutritionAdvice-v3.1(2017EN) NutritionAdvice]
+
| AdministrationAgreement
−
|
+
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 8. Waarschuwingen
+
| rowspan="2" | 11
−
| Alerts
+
| rowspan="2" | MedischHulpmiddel
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.8-2017-10-24T000000.html BgZ2017Alerts]
+
| rowspan="2" | MedicalDevice
 +
| Device
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
|  
+
| DeviceUseStatement
−
| [https://zibs.nl/wiki/Alert-v3.2(2017NL) Alert]
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017}}
−
| [https://zibs.nl/wiki/Alert-v3.2(2017EN) Alert]
 
−
|
 
 
|-
 
|-
−
| colspan="2" | 9. Allergieën
+
| rowspan="2" | 12
−
| Allergies
+
| rowspan="2" | Vaccinatie
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.9-2017-10-24T000000.html BgZ2017Allergies]
+
| rowspan="2" | Vaccination
 +
| Immunization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
|  
+
| ImmunizationRecommendation
−
| [https://zibs.nl/wiki/AllergieIntolerantie-v3.2(2017NL) AllergieIntolerantie]
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017}}
−
| [https://zibs.nl/wiki/AllergyIntolerance-v3.2(2017EN) AllergyIntolerance]
 
−
|
 
 
|-
 
|-
−
| colspan="2" | 10. Medicatie
+
| rowspan="3" | 13
−
| Medication
+
| Bloeddruk
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.10-2017-10-24T000000.html BgZ2017Medication]
+
| BloodPressure
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| rowspan="3" |
+
| LichaamsGewicht
−
| [https://zibs.nl/wiki/MedicatieGebruik2-v1.0.1(2017NL) MedicatieGebruik2]
+
| BodyWeight
−
| [https://zibs.nl/wiki/MedicationUse2-v1.0.1(2017EN) MedicationUse2]
+
| Observation
−
|
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/Medicatieafspraak-v1.0.1(2017NL) Medicatieafspraak]
+
| LichaamsLengte
−
| [https://zibs.nl/wiki/MedicationAgreement-v1.0.1(2017EN) MedicationAgreement]
+
| BodyHeight
−
|
+
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/Toedieningsafspraak-v1.0.1(2017NL) Toedieningsafspraak]
+
| rowspan="2" | 14
−
| [https://zibs.nl/wiki/AdministrationAgreement-v1.0.1(2017EN) AdministrationAgreement]
+
| rowspan="2" | LaboratoriumUitslag
−
|
+
| rowspan="2" | LaboratoryTestResult
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 11. Medische hulpmiddelen
+
| Specimen
−
| Medical devices
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017}}
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.11-2017-10-24T000000.html BgZ2017MedicalDevices]
 
 
|-
 
|-
−
|  
+
| 15
−
| [https://zibs.nl/wiki/MedischHulpmiddel-v3.1(2017NL) MedischHulpmiddel]
+
| Verrichting
−
| [https://zibs.nl/wiki/MedicalDevice-v3.1(2017EN) MedicalDevice]
+
| Procedure
−
|
+
| Procedure
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 12. Vaccinaties
+
| 16
−
| Immunizations
+
| Contact
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.12-2021-10-28T000000.html BgZ2017Immunizations]
+
| Encounter
 +
| Encounter
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
|  
+
| rowspan="4" | 17
−
| [https://zibs.nl/wiki/Vaccinatie-v3.1(2017NL) Vaccinatie]
+
| rowspan="2" | Zorgverlener
−
| [https://zibs.nl/wiki/Vaccination-v3.1(2017EN) Vaccination]
+
| rowspan="2" | HealthProfessional
−
|
+
| Practitioner
 +
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| colspan="2" | 13. Vitale functies
+
| PractitionerRole
−
| Vital signs
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.13-2017-10-24T000000.html BgZ2017VitalSigns]
 
 
|-
 
|-
−
| rowspan="3" |  
+
| rowspan="2" | Zorgaanbieder
−
| [https://zibs.nl/wiki/Bloeddruk-v3.1(2017NL) Bloeddruk]
+
| rowspan="2" | HealthcareProvider
−
| [https://zibs.nl/wiki/BloodPressure-v3.1(2017EN) BloodPressure]
+
| Organization
−
|
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| [https://zibs.nl/wiki/Lichaamsgewicht-v3.1(2017NL) LichaamsGewicht]
+
| CareTeam
−
| [https://zibs.nl/wiki/BodyWeight-v3.1(2017EN) BodyWeight]
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017}}
−
|  
+
|}
 +
<small>''Table 5.2 Referenced BgZ FHIR Resources''</small>
 +
=Infrastructure=
 +
The implementation guideline assumes that a generic infrastructure is available to provide for services like:
 +
 
 +
* Identification [NEN-7518] (of client and provider - who are you?)
 +
* Authentication [NEN-7518] (establish that you really are who you say)
 +
* Localization [NEN-7519]  (where/what information known about the client and provider?)
 +
* Consent [NEN-7517] (from the patient for the sharing of medical information)
 +
* Authorization (what information are you allowed to access?)
 +
* Addressing (digital address of provider or organization)
 +
* Logging [NEN-7513] (audit trail - who did what, where, when and why?)
 +
 
 +
=References=
 +
{| class="wikitable"
 +
| | '''Reference'''
 +
| | '''Document Title'''
 +
| | '''Date, Version, Source'''
 
|-
 
|-
−
| [https://zibs.nl/wiki/Lichaamslengte-v3.1(2017NL) LichaamsLengte]
+
| | [1]
−
| [https://zibs.nl/wiki/BodyHeight-v3.1(2017EN) BodyHeight]
+
| | Kwaliteitsstandaard - Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend
−
|  
+
<small>''Translates as “Exchange of BgZ between institutions where specialist medical care is provided”''</small>
 +
| | Commentaarfase februari 2023
 
|-
 
|-
−
| colspan="2" | 14. Uitslagen
+
| | [2]
−
| Results
+
| | NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.25.10.52-2021-10-27T000000.html Laboratoryspecialtysection]
+
<small>''Translates as “Exchange of BgZ between institutions for specialist medical care”''</small>
 +
| | ICS 11.020.01;35.240.80 maart 2024
 
|-
 
|-
−
|
+
| | [3]
−
| [https://zibs.nl/wiki/LaboratoriumUitslag-v4.1(2017NL) LaboratoriumUitslag]
+
| | Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism
−
| [https://zibs.nl/wiki/LaboratoryTestResult-v4.1(2017EN) LaboratoryTestResult]
+
| | Version: 1.0.0 06-03-24
−
|  
+
|}
−
|-
+
 
−
| colspan="2" | 15. Verrichtingen
+
=Release Notes=
−
| Procedures
+
Changes compared to previous release.
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.15-2017-10-24T000000.html BgZ2017Procedures]
+
 
−
|-
+
{| class="wikitable"
−
|  
+
! style="font-weight: bold;text-align:left;" | BITS ticket
−
| [https://zibs.nl/wiki/Verrichting-v4.1(2017NL) Verrichting]
+
! style="font-weight: bold;text-align:left;" | Short description
−
| [https://zibs.nl/wiki/Procedure-v4.1(2017EN) Procedure]
 
−
|  
 
 
|-
 
|-
−
| colspan="2" | 16. Contacten
+
| [https://bits.nictiz.nl/browse/NICTIZ-14769 NICTIZ-14769]
−
| Encounters
+
| Ontwikkelen/schrijven van de TO in de wiki
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.16-2017-10-24T000000.html BgZ2017Encounters]
 
 
|-
 
|-
−
|
+
| [https://bits.nictiz.nl/browse/NICTIZ-18044 NICTIZ-18044]
−
| [https://zibs.nl/wiki/Contact-v3.1(2017NL) Contact]
+
| BgZ-MSZ TO - review commentaren Gabriel/Iwo bijwerken
−
| [https://zibs.nl/wiki/Encounter-v3.1(2017EN) Encounter]
 
−
|
 
 
|-
 
|-
−
| colspan="2" | 17. Zorgplan
+
| [https://bits.nictiz.nl/browse/NICTIZ-18045 NICTIZ-18045]
−
| Care plan
+
| BgZ-MSZ TO - aanpassing ivm "Notified Pull – Hoe toe te passen in een informatiestandaard" - doc Marc
−
| [http://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20220506T101050/tmp-2.16.840.1.113883.2.4.3.11.60.42.10.17-2021-07-09T172550.html BgZ2017CarePlan]
+
|-  
−
|-
 
−
| 
 
−
| [https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) OverdrachtGeplandeZorgActiviteit]
 
−
| [https://zibs.nl/wiki/PlannedCareActivityForTransfer-v3.1(2017EN) PlannedCareActivityForTransfer]
 
−
|-
 
−
| colspan="2" | 18. Zorgverleners
 
−
| Health professionals
 
−
|
 
−
|-
 
−
| rowspan="2" |
 
−
| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
 
−
| [https://zibs.nl/wiki/HealthProfessional-v3.2(2017EN) HealthProfessional]
 
−
|
 
−
|-
 
−
| [https://zibs.nl/wiki/Zorgaanbieder-v3.1.1(2017NL) Zorgaanbieder]
 
−
| [https://zibs.nl/wiki/HealthcareProvider-v3.1.1(2017EN) HealthcareProvider]
 
−
|
 
 
|}
 
|}
−
 
−
=Infrastructure=
 
−
This standard does not mandate a particular infrastructure, and therefore does not specify details for such an infrastructure.
 
−
 
−
Useful materials from other parties can be found on:
 
−
* [https://taskforce-samen-vooruit.nl/downloads/ Taskforce Samen Vooruit]
 
−
=Release notes=
 

Huidige versie van 10 jul 2024 om 15:22

Back to Top

Issue icon.png

Dit is een tijdelijke pagina met wijzigingen voor issue NICTIZ-14348. De gepubliceerde versie vind je hier.

Under construction icon-blue.png This article or section is in the middle of an expansion or major restructuring and is not yet ready for use.


1 Note on this Implementation Guide - alpha status

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

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

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

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

2 Introduction

2.1 Background

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

This BgZ MSZ implementation guide defines the BgZ information exchanges, in terms of use cases, based on the Zib2017 and HL7 FHIR STU3 releases. HL7 CDA is no longer supported for BgZ MSZ exchange.

2.2 About this document

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

The following documents also provide important background information:

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

This document assumes reader familiarity with these references.

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

2.3 Glossary

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

Table 2.1 Glossary

3 Boundaries and Relationships

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

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

4 Use Cases

Two use cases are defined in the FO as follows:

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

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

4.1 Exchange BgZ for Referral

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

4.1.1 Actors

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

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

4.1.2 Transactions

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

  • Notified Pull (preferred)
  • Push

4.1.2.1 Exchange BgZ for Referral using Notified Pull Transaction

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

Use Case - Notified Pull

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

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

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

  1. The Sending System can support either a standalone Notification (Task) message or the combined use of the Notification (Task) and Workflow (Task) messages.
  2. The Receiving System must support both the Notification (Task) and Workflow (Task) messages.

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

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

4.1.2.2 Exchange BgZ for Referral using Push Transaction

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

Use Case - Push

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

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

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

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

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

4.2.1 Actors

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

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

4.2.2 Transactions

4.2.2.1 Retrieval of BgZ from previous practitioner using Pull Transaction

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

Use Case - Pull

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

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

5 FHIR Profiles

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

5.1 FHIR Notification Task

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

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

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

5.2 FHIR Workflow Task

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

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

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

5.3 FHIR Task Patient Identification

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

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

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

5.4 FHIR Task.input Query Specification

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

The Type column defines the type of query:

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

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

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

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

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

BgZ Section HCIM Type Code

(FHIR Task.input.type)

Value

(FHIR Task.input.value[x])

Description
1 Patient information Patient Search 
http://snomed.info/sct
116154003
"Patient"

or 

http://loinc.org
79191-3
"Patient demographics panel"
 
GET [base]/Patient?
_include=Patient:general-practitioner
 The Receiving System gets the patient identification, birth date, gender, deceased indicator, contact details, last known marital status, and general practitioner (practitioner or organization) that has been registered in the Sending System.
  • Condition: Last Known Marital Status
  • Cardinality: 0..1
2 Payment details Payer Search 
http://loinc.org
48768-6
"Payment sources document"
 
GET [base]/Coverage?
_include=Coverage:payor:Patient&
_include=Coverage:payor:Organization
 The Receiving System gets the patient's insurance information that has been that has been registered in the Sending System.
3 Treatment directives Treatment Directive Search 
http://snomed.info/sct
11291000146105
"Treatment instructions"
 
GET [base]/Consent?
category=http://snomed.info/sct|11291000146105
 The Receiving System gets the most recent version of all Treatment Directives that have been registered in the Sending System.
Advance Directive Search 
http://snomed.info/sct
11341000146107
"Living will and advance directive record"
 
GET [base]/Consent?
category=http://snomed.info/sct|11341000146107
 The Receiving System gets the most recent version of all Advance Directives that have been registered in the Sending System.
4 Contact persons Contact Person Search 
http://snomed.info/sct
70862002
"Contact person"
 
see Patient
 The Receiving System gets the most recent version of the primary partner/contact that was last registered in the Sending System.
  • Condition: Primary partner/contact
  • Cardinality: 0..1
5 Functional or Mental status Functional Or Mental Status Search 
http://loinc.org
47420-5
"Functional status assessment note"
 
GET [base]/Observation/$lastn?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006
 The Receiving System gets, per StatusName, the most recent version of the FunctionalOrMentalStatus that was last registered in the Sending System.

Specifically, if available, these are the last known status of the functions: mental, hearing, vision, mobility and language skills.

  • Condition: Last known status of a function
  • Cardinality: 0..*
6 Problems Problem Read 
http://loinc.org
11450-4
"Problem list - Reported"
 
GET [base]/Condition
 The Receiving System gets the most recent version of all issues that have been registered in the Sending System.
7 Social history Living Situation Search 
http://snomed.info/sct
365508006
"Finding of residence and accommodation circumstances"
 
GET [base]/Observation/$lastn?
code=http://snomed.info/sct|365508006
 The Receiving System gets the most recent version of the living situation that was last registered in the Sending System.

This does not have to be the Living Situation that has been updated most recently.

  • Condition: If available, the last known living situation.
  • Cardinality: 0..1
Drug Use Search 
http://snomed.info/sct
228366006
"Finding relating to drug misuse behavior"
 
GET [base]/Observation?
code=http://snomed.info/sct|228366006
 The Receiving System gets, for each Drug Or Drug Type, the most recent version of the Drug Use that was last registered in the Sending System.

This does not have to be the Drug Use that has been updated most recently.

  • Condition: If available, the last known drug use for each Drug Or Drug Type.
  • Cardinality: 0..*
Alcohol Use Search 
http://snomed.info/sct
228273003
"Finding relating to alcohol drinking behavior"
 
GET [base]/Observation?
code=http://snomed.info/sct|228273003
 The Receiving System gets the most recent version of the Alcohol Consumption that was last registered in the Sending System.

This does not have to be the Alcohol Consumption that has been updated most recently.

  • Condition: If available, last known alcohol consumption.
  • Cardinality: 0..1
Tobacco Use Search 
http://snomed.info/sct
365980008
"Finding of tobacco use and exposure"
 
GET [base]/Observation?
code=http://snomed.info/sct|365980008
 The Receiving System gets the most recent version of the Tobacco Use that was last registered in the Sending System.

This does not have to be the Tobacco Use that has been updated most recently.

  • Condition: If available, last known tobacco use.
  • Cardinality: 0..1
Nutrition Advice Search 
http://snomed.info/sct
11816003
"Dietary advice"
 
GET [base]/Observation?
code=http://snomed.info/sct|300893006

NOTE: Query 1.x is: GET [base]/NutritionOrder

The Receiving System gets, for each Diet Type, the most recent version of the Nutritional Advice that was last registered in the Sending System.

This does not have to be the Nutritional Advice that has been updated most recently for each Diet Type.

8 Alerts Alert Read 
http://loinc.org
75310-3 
"Health concerns document"
 
GET [base]/Flag
 The Receiving System gets the most recent version of all Alerts registered in the Sending System.
9 Allergies Allergy Intolerance Read 
http://loinc.org
48765-2
"Allergies and adverse reactions document"
 
GET [base]/AllergyIntolerance
 The Receiving System gets the most recent version of all allergies registered in the Sending System.
10 Medication Medication Use2 Search 
http://snomed.info/sct
422979000
"Medication regimen behavior finding"
 
GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication
 Known medication use
Administration Agreement Search 
http://snomed.info/sct
422037009
"Provider medication administration instructions"
 
GET [base]/MedicationDispense?
category=http://snomed.info/sct|422037009&
_include=MedicationDispense:medication
 Known administration agreements
Medication Agreement Search 
http://snomed.info/sct
16076005
"Prescription"
 
GET [base]/MedicationRequest?
category=http://snomed.info/sct|16076005&
_include=MedicationRequest:medication
 Known medication agreements
11 Medical aids Medical Device Read 
http://snomed.info/sct
49062001
"Device (physical object)"

or 

http://loinc.org
46264-8
"Known medical aids"
 
GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device
 The Receiving System gets the most recent version of all medical aids (devices) registered in the Sending System.
12 Vaccinations Vaccination Read 
http://loinc.org
11369-6
"History of Immunization Narrative"
 
GET [base]/Immunization?
status=completed
 The Receiving System gets the most recent version of all vaccinations registered in the Sending System.
13 Vital signs Blood Pressure Search 
http://loinc.org
85354-9
"Blood pressure"
 
GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9
 The Receiving System gets the most recent version of the blood pressure that was last registered in the Sending System.
  • Condition: Last known blood pressure.
  • Cardinality: 0..1
Body Weight Search 
http://loinc.org
29463-7
"Body weight"
 
GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7
 The Receiving System gets the most recent version of the body weight that was last registered in the Sending System.
  • Condition: Last known body weight.
  • Cardinality: 0..1
Body Height Search 
http://loinc.org
8302-2
"Body height"
 
GET [base]/Observation/$lastn?
code=http://loinc.org|8302-2,
http://loinc.org|8306-3,
http://loinc.org|8308-9
 The Receiving System gets the most recent version of the body height that was last registered in the Sending System.
  • Condition: Last known body height.
  • Cardinality: 0..1
14 Results Laboratory Test Result Search 
http://snomed.info/sct
15220000
"Laboratory test"
 
GET [base]/Observation/$lastn?
category=http://snomed.info/sct|118246004&
_include=Observation:related-target&
_include=Observation:specimen

NOTE: Query 1.x is: GET [base]/Observation/$lastn? category=http://snomed.info/sct%7C275711006& _include=Observation:related-target& _include=Observation:specimen

The Receiving System gets the most recent version of the Laboratory Test last registered for all "Laboratory" observations, per Laboratory Test Code in the Sending System. The selected laboratory tests are grouped via the Laboratory Result. The optional result Type of the Laboratory Result is not used for filtering, only the LOINC Test Code. The result Type will be sent along with the data if available.
  • Condition: Last known test for all results.
  • Cardinality: 0..1
15 Procedures Procedure Search 
http://snomed.info/sct
71388002
"Procedure"

or 

http://loinc.org
47519-4
"History of Procedures"
 
GET [base]/Procedure?
category=http://snomed.info/sct|50731006

NOTE: Query 1.x is: GET [base]/Procedure? category=http://snomed.info/sct%7C387713003

The Receiving System gets the most recent version of all procedures registered in the Sending System. This includes all operative and diagnostic procedures, including outpatient surgeries/operations.
16 Encounters Encounter Search 
http://loinc.org
46240-8
"History of Hospitalizations+Outpatient visits Narrative"
 
GET [base]/Encounter?
class=http://snomed.info/sct|308335008

NOTE: Query 1.x is: GET [base]/Encounter? class=http://hl7.org/fhir/v3/ActCode%7CIMP, http://hl7.org/fhir/v3/ActCode%7CACUTE, http://hl7.org/fhir/v3/ActCode%7CNONAC

The Receiving System gets the most recent version of all contacts registered in the Sending System. This also includes outpatient contacts where the reason for the contact is an outpatient operation, such as the removal of osteosynthesis material after a bone fracture. All hospital admissions and contacts with a reference to a transaction or a problem are included. Origin and destination are not exchanged.
17 Care Setting Healthcare Provider Read 
http://snomed.info/sct
229774002
"Caregiver"
 
GET [base]/CareTeam?
_include=CareTeam:participant
 The Receiving System gets the most recent version of all available caregivers registered in the Sending System. This includes at least the care providers with a current treatment relationship and, if available, care providers who are appointed in the contacts and operations that are controlled with the BgZ.
Healthcare Location Read 
http://snomed.info/sct
43741000
"Site of care"
 
GET [base]/?????
 The Receiving System gets the most recent version of all available healthcare providers registered in the Sending System. This includes at least the care providers who are appointed in the contacts and transactions that are sent with the BgZ.

Table 5.1 FHIR Task.input Query Specification

5.5 Referenced BgZ FHIR Resources

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

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

Table 5.2 Referenced BgZ FHIR Resources

6 Infrastructure

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

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

7 References

Reference Document Title Date, Version, Source
[1] Kwaliteitsstandaard - Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend

Translates as “Exchange of BgZ between institutions where specialist medical care is provided”

Commentaarfase februari 2023
[2] NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg

Translates as “Exchange of BgZ between institutions for specialist medical care”

ICS 11.020.01;35.240.80 maart 2024
[3] Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism Version: 1.0.0 06-03-24

8 Release Notes

Changes compared to previous release.

BITS ticket Short description
NICTIZ-14769 Ontwikkelen/schrijven van de TO in de wiki
NICTIZ-18044 BgZ-MSZ TO - review commentaren Gabriel/Iwo bijwerken
NICTIZ-18045 BgZ-MSZ TO - aanpassing ivm "Notified Pull – Hoe toe te passen in een informatiestandaard" - doc Marc
Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG&oldid=219749"