BgZ:V2.0 Beta BgZ 2017 Technical IG: verschil tussen versies

Uit informatiestandaarden
Ga naar: navigatie, zoeken
k (→‎FHIR Query Specification)
 
(163 tussenliggende versies door 3 gebruikers niet weergegeven)
Regel 9: Regel 9:
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
 
__NOINDEX__
 
__NOINDEX__
−
{{DISPLAYTITLE:BgZ Medisch-Specialistische Zorg Technical Implementation Guide 2.0 - Beta}}
+
{{DISPLAYTITLE:BgZ msz FHIR Implementation Guide v2.0 - Beta, under construction}}
 
__TOC__
 
__TOC__
−
=Note on this Implementation Guide - beta status - in ontwikkeling=
 
−
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=
Regel 29: Regel 18:
 
This data collection can be exchanged between care institutions. The information standard focuses on the exchange between healthcare providers of specialist medical 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 [https://www.hl7.org/fhir/stu3/ FHIR(STU3) HL7 FHIR, STU3]. HL7 CDA is no longer supported for BgZ MSZ exchange. This implementation guide assumes that the reader is familiar with this FHIR version.
+
This BgZ MSZ implementation guide defines the BgZ information exchanges, in terms of use cases, based on the Zib2017 and [https://www.hl7.org/fhir/stu3/ FHIR(STU3) HL7 FHIR, STU3].  
 +
 
 +
HL7 CDA is no longer supported for BgZ MSZ exchange. This implementation guide assumes that the reader is familiar with this FHIR version.
  
 
Apart from this document, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR Implementation Guide]] apply. The guide defines methods on how to proceed with implementing FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|Use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].
 
Apart from this document, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR Implementation Guide]] apply. The guide defines methods on how to proceed with implementing FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|Use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].
Regel 36: Regel 27:
 
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]].
 
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:  
+
The following document provides 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]
+
* "Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism" [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 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==
 
==Glossary==
Regel 59: Regel 46:
 
|-
 
|-
 
| 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.
 
| 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
 
| 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.
 
 
|-
 
|-
 
|}
 
|}
Regel 109: Regel 92:
 
* Push
 
* Push
 
====Exchange BgZ for Referral using Notified Pull Transaction====
 
====Exchange BgZ for Referral using Notified Pull Transaction====
−
The Notified Pull communication pattern is based on the description in [3]. The Referring (Sending) Medical Specialist notifies the Receiving Medical Specialist about the referral or transfer by sending a Notification Message. The Receiving Medical Specialist can then retrieve the BgZ (at a suitable time) using the Pull Message(s) which is(are) defined as a part of the Notification Message.
+
The Notified Pull communication pattern is based on the description in [1]. 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.
  
 
[[Image:UC Notified Pull-2.jpg|Use Case - Notified Pull]]
 
[[Image:UC Notified Pull-2.jpg|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.
 
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:
 
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:
Regel 125: Regel 106:
 
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 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.
  
−
'''NOTE:''' The Notified Pull, as described in [3], identifies two additional transactions based on the Notification Task:
+
'''NOTE:''' The Notified Pull, as described in [1], identifies two additional transactions based on the Notification Task:
 
# Notification Update
 
# Notification Update
 
# Notification Cancellation
 
# Notification Cancellation
Regel 141: Regel 122:
 
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.
 
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)==
+
==Retrieval of BgZ from previous practitioner==
 
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.
 
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===
 
===Actors===
Regel 158: Regel 139:
 
| Electronic health record
 
| 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.
+
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).
  
 
===Transactions===
 
===Transactions===
Regel 171: Regel 152:
  
 
=FHIR Profiles=
 
=FHIR Profiles=
−
Note: These FHIR Profiles are under review and will be finalized by the beta version of the TO.
 
  
 
==FHIR Notification Task==
 
==FHIR Notification Task==
Regel 183: Regel 163:
 
|-  
 
|-  
 
| (Notification) Task
 
| (Notification) Task
−
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/bgz-msz-notification-task-location-to-be-added}}
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-NotificationTask|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
 
|}
 
|}
  
Regel 196: Regel 176:
 
|-  
 
|-  
 
| (Workflow) Task
 
| (Workflow) Task
−
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/bgz-msz-workflow-task-location-to-be-added}}
+
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-WorkflowTask|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
 
|}
 
|}
  
Regel 214: Regel 194:
 
|}
 
|}
  
−
==FHIR Task.input Query Specification==
+
==FHIR 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 table below provides an overview of the FHIR queries to exchange all BgZ-msz elements.
  
−
The '''Type''' column defines the type of query:
+
{| class="wikitable"
−
* '''Read''' - query for a single referenced FHIR resource instances where value[x] is a '''valueReference'''.
+
! scope="col" style="text-align: left;" | Query
−
* '''Search''' - query for one or more FHIR resource instances where value[x] is a '''valueString''' representing the search string.
+
! scope="col" style="text-align: left;" | Description
−
 
+
|-
−
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.
+
! colspan="2" style="text-align: left;" | 1 Demographics and identification
−
'''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.
+
! colspan="2" style="text-align: left;" | 1.1 Patient
−
 
 
−
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.'''
 
−
 
 
−
{| 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" | BgZ Section
 
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:200px" | HCIM
 
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | Type
 
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:200px" | Code
 
−
(FHIR Task.input.type)
 
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left;  background-color: #E3E3E3 width:200px" | Value
 
−
(FHIR Task.input.value[x])
 
−
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:200px" | Description
 
 
|-
 
|-
−
| 1 Patient information
 
−
| Patient
 
−
| Search
 
 
| <pre>
 
| <pre>
−
http://loinc.org
+
GET [base]/Patient?
−
79191-3
+
_include=Patient:general-practitioner
−
"Patient demographics panel"</pre>
+
</pre>
−
| <pre>GET [base]/Patient?
+
|
−
_include=Patient:general-practitioner</pre>
+
The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.
−
| The 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.
+
* The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
 +
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
 +
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 1.2 Marital status
 +
|-
 +
|
 +
<pre>
 +
see Patient.maritalStatus
 +
</pre>
 +
|
 +
Marital status data are exchanged via the patient resource (see 1.1).
 +
|-
 +
!  colspan="2" style="text-align: left;" | 2 Financial information
 +
|-
 +
!  colspan="2" style="text-align: left;" | 2.1 Payer
 
|-
 
|-
−
| 2 Payment details
 
−
| Payer
 
−
| Search
 
 
| <pre>
 
| <pre>
−
http://loinc.org
+
GET [base]/Coverage?
−
48768-6
+
_include=Coverage:payor
−
"Payment sources document"</pre>
+
</pre>
−
| <pre>GET [base]/Coverage?
+
|  
−
_include=Coverage:payor:Patient&
+
The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.
−
_include=Coverage:payor:Organization&
+
* The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
−
_include=Coverage:payor:RelatedPerson</pre>
+
|-
−
| The Receiving System gets the patient's insurance information that has been that has been registered in the Sending System.
+
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
 +
|-
 +
!  colspan="2" style="text-align: left;" | 3.1 Treatment instructions
 
|-
 
|-
−
| rowspan="2" | 3 Treatment directives
 
−
| Treatment Directive
 
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
11291000146105
 
−
"Treatment instructions"</pre>
 
 
| <pre>GET [base]/Consent?
 
| <pre>GET [base]/Consent?
 
category=http://snomed.info/sct|11291000146105</pre>
 
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.
+
|  
 +
All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.
 +
* The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
 +
|-
 +
!  colspan="2" style="text-align: left;" | 3.2 Advance directive
 
|-
 
|-
−
| Advance Directive
 
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
11341000146107
 
−
"Living will and advance directive record"</pre>
 
 
| <pre>GET [base]/Consent?
 
| <pre>GET [base]/Consent?
 
category=http://snomed.info/sct|11341000146107</pre>
 
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.
+
|  
 +
All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.
 +
* The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
 +
* the document is only exchanged via a pdf.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 4 Contact persons
 +
|-
 +
!  colspan="2" style="text-align: left;" | 4.1 Contact
 +
|-
 +
| <pre>Patient.contact</pre>
 +
|
 +
Primary partner/contact data are exchanged via the patient resource (see 1.1).
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 5 Functional/mental status
 
|-
 
|-
−
| 4 Contact persons
+
!  colspan="2" style="text-align: left;" | 5.1 Functional or mental status
−
| Contact Person
 
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
70862002
 
−
"Contact person"</pre>
 
−
| <pre style="font-style: italic;">see the Patient.contact element</pre>
 
−
| The Receiving System gets the most recent version of the primary partner/contact that was last registered in the Sending System.
 
 
|-
 
|-
−
| 5 Functional or Mental status
+
| <pre>GET [base]/Observation?
−
| Functional Or Mental Status
 
−
| Search
 
−
| <pre>
 
−
http://loinc.org
 
−
47420-5
 
−
"Functional status assessment note"</pre>
 
−
| <pre>GET [base]/Observation/$lastn?
 
 
category=http://snomed.info/sct|118228005,
 
category=http://snomed.info/sct|118228005,
 
http://snomed.info/sct|384821006</pre>
 
http://snomed.info/sct|384821006</pre>
−
| The Receiving System gets, per StatusName (Observation code), the most recent version of the FunctionalOrMentalStatus that was available in the Sending System.
+
|  
−
Specifically, not limited by, these are the last known status of the functions: mental, hearing, vision, mobility and language skills.
+
All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.
 +
* Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
 +
* Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
 +
* please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
 +
* The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 6 Complaints and diagnoses
 +
|-
 +
!  colspan="2" style="text-align: left;" | 6.1 Problem
 
|-
 
|-
−
| 6 Problems
 
−
| Problem
 
−
| Read
 
−
| <pre>
 
−
http://loinc.org
 
−
11450-4
 
−
"Problem list - Reported"</pre>
 
 
| <pre>GET [base]/Condition</pre>
 
| <pre>GET [base]/Condition</pre>
−
| The Receiving System gets the most recent version of all problems that are available in the Sending System.
+
|  
 +
All problems available in the source system are returned as zib-Problem instances.
 +
* The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
 +
* Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
 +
* Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
 
|-
 
|-
−
| rowspan="5" | 7 Social history
+
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
−
| Living Situation
+
|-
−
| Search
+
!  colspan="2" style="text-align: left;" | 7.1 Living Situation
−
| <pre>
+
|-
−
http://snomed.info/sct
+
| <pre>GET [base]/Observation?
−
365508006
 
−
"Finding of residence and accommodation circumstances"</pre>
 
−
| <pre>GET [base]/Observation/$lastn?
 
 
code=http://snomed.info/sct|365508006</pre>
 
code=http://snomed.info/sct|365508006</pre>
−
| The Receiving System gets the last known living situation that is available in the Sending System.
+
|  
 +
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
 +
* The Observation.category is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
 +
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 7.2 Drug Use
 
|-
 
|-
−
| Drug Use
 
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
228366006
 
−
"Finding relating to drug misuse behavior"</pre>
 
 
| <pre>GET [base]/Observation?
 
| <pre>GET [base]/Observation?
 
code=http://snomed.info/sct|228366006</pre>
 
code=http://snomed.info/sct|228366006</pre>
−
| The Receiving System gets all Drug use that are available in the Sending System. To present the last known Drug use according to the guideline (kwaliteitsstandaard) the Receiving System should filter the data.
+
|
 +
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
 +
* The Observation.category is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
 +
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 7.3 Alcohol Use
 +
|-
 +
| <pre>GET [base]/Observation?
 +
code=http://snomed.info/sct|228273003</pre>
 +
|
 +
All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.
 +
* The Observation.category is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
 
|-
 
|-
−
| Alcohol Use
+
!  colspan="2" style="text-align: left;" | 7.4 Tobacco Use
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
228273003
 
−
"Finding relating to alcohol drinking behavior"</pre>
 
−
| <pre>GET [base]/Observation/$lastn?code=http://snomed.info/sct|228273003</pre>
 
−
| The Receiving System gets the last known Alcohol Consumption that is available in the Sending System.
 
−
This does not have to be the Alcohol Consumption that has been updated most recently.
 
 
|-
 
|-
−
| Tobacco Use
+
| <pre>GET [base]/Observation?
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
365980008
 
−
"Finding of tobacco use and exposure"</pre>
 
−
| <pre>GET [base]/Observation/$lastn?
 
 
code=http://snomed.info/sct|365980008</pre>
 
code=http://snomed.info/sct|365980008</pre>
−
| The Receiving System gets all Tobacco use that are available in the Sending System. To present the last known Tobacco use according to the guideline (kwaliteitsstandaard) the Receiving System should filter the data.
+
|  
 +
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
 +
* The Observation.category is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
 +
|-
 +
!  colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
 
|-
 
|-
−
| Nutrition Advice
 
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
11816003
 
−
"Dietary advice"</pre>
 
 
| <pre>GET [base]/NutritionOrder</pre>
 
| <pre>GET [base]/NutritionOrder</pre>
−
| The Receiving System gets all Nutrition Advice that is available in the Sending System. To present the last known Nutrition Advice, for each Diet Type, according to the guideline (kwaliteitsstandaard) the Receiving System should filter the data.
+
|
 +
All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.
 +
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 8 Alerts
 +
|-
 +
!  colspan="2" style="text-align: left;" | 8.1 Alert
 
|-
 
|-
−
| 8 Alerts
 
−
| Alert
 
−
| Read
 
−
| <pre>
 
−
http://loinc.org
 
−
75310-3
 
−
"Health concerns document"</pre>
 
 
| <pre>GET [base]/Flag</pre>
 
| <pre>GET [base]/Flag</pre>
−
| The Receiving System gets all Alerts available in the Sending System.
+
|  
 +
All alerts available in the source system are exchanged as a FHIR Flag instances that conform to the zib-Alert profile.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 9 Allergies
 +
|-
 +
!  colspan="2" style="text-align: left;" | 9.1 Allergy Intolerance
 
|-
 
|-
−
| 9 Allergies
 
−
| Allergy Intolerance
 
−
| Read
 
−
| <pre>
 
−
http://loinc.org
 
−
48765-2
 
−
"Allergies and adverse reactions document"</pre>
 
 
| <pre>GET [base]/AllergyIntolerance</pre>
 
| <pre>GET [base]/AllergyIntolerance</pre>
−
| The Receiving System gets all known allergies available in the Sending System. By default the AllergyStatus (VerificationStatus) is exchanged as "Active" unless otherwise specified differently.
+
|  
 +
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
 +
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with the ‘unknown’ data-absent-reason.
 +
<pre>
 +
"manifestation":{
 +
  "extension": [{
 +
      "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
 +
      "valueCode": "unknown"
 +
    }]
 +
  },
 +
</pre>
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 10 Medication
 +
|-
 +
!  colspan="2" style="text-align: left;" | 10.1 Medication Agreement
 +
|-
 +
| <pre>GET [base]/MedicationRequest?
 +
category=http://snomed.info/sct|16076005&
 +
_include=MedicationRequest:medicationReference</pre>
 +
|
 +
All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.
 +
* The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
 +
* The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 10.2 Administration Agreement
 +
|-
 +
| <pre>GET [base]/MedicationDispense?
 +
category=http://snomed.info/sct|422037009&
 +
_include=MedicationDispense:medicationReference</pre>
 +
|
 +
All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.
 +
* The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
 +
* The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 10.3 Medication Use
 
|-
 
|-
−
| rowspan="3" | 10 Medication
 
−
| Medication Use2
 
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
422979000
 
−
"Medication regimen behavior finding"</pre>
 
 
| <pre>GET [base]/MedicationStatement?
 
| <pre>GET [base]/MedicationStatement?
 
category=
 
category=
 
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
 
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
−
_include=MedicationStatement:medication</pre>
+
_include=MedicationStatement:medicationReference</pre>
−
| Known medication use
+
|  
 +
All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.
 +
* The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
 +
* The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
 
|-
 
|-
−
| Administration Agreement
+
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
422037009
 
−
"Provider medication administration instructions"</pre>
 
−
| <pre>GET [base]/MedicationDispense?
 
−
category=http://snomed.info/sct|422037009&
 
−
_include=MedicationDispense:medication</pre>
 
−
| Known administration agreements
 
 
|-
 
|-
−
| Medication Agreement
+
!  colspan="2" style="text-align: left;" | 11.1 Medical device
−
| Search
 
−
| <pre>
 
−
http://snomed.info/sct
 
−
16076005
 
−
"Prescription"</pre>
 
−
| <pre>GET [base]/MedicationRequest?
 
−
category=http://snomed.info/sct|16076005&
 
−
_include=MedicationRequest:medication</pre>
 
−
| Known medication agreements
 
 
|-
 
|-
−
| 11 Medical aids
 
−
| Medical Device
 
−
| Read
 
−
| <pre>
 
−
http://loinc.org
 
−
46264-8
 
−
"Known medical aids"</pre>
 
 
| <pre>GET [base]/DeviceUseStatement?
 
| <pre>GET [base]/DeviceUseStatement?
 
_include=DeviceUseStatement:device</pre>
 
_include=DeviceUseStatement:device</pre>
−
| The Receiving System gets all medical devices available in the Sending System.
+
|  
 +
All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.
 +
* The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 12 Vaccinations
 +
|-
 +
!  colspan="2" style="text-align: left;" | 12.1 Vaccination
 
|-
 
|-
−
| 12 Vaccinations
 
−
| Vaccination
 
−
| Read
 
−
| <pre>
 
−
http://loinc.org
 
−
11369-6
 
−
"History of Immunization Narrative"</pre>
 
 
| <pre>GET [base]/Immunization?
 
| <pre>GET [base]/Immunization?
 
status=completed</pre>
 
status=completed</pre>
−
| The Receiving System gets all completed vaccinations registered in the Sending System. By default the Vaccination status is exchanged as "Completed" unless otherwise specified differently.
+
|  
 +
All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.
 +
* Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 13 vital signs and measurements
 +
|-
 +
!  colspan="2" style="text-align: left;" | 13.1 Blood pressure
 
|-
 
|-
−
| rowspan="3" | 13 Vital signs
 
−
| Blood Pressure
 
−
| Search
 
−
| <pre>
 
−
http://loinc.org
 
−
85354-9
 
−
"Blood pressure"</pre>
 
 
| <pre>GET [base]/Observation/$lastn?
 
| <pre>GET [base]/Observation/$lastn?
 
code=http://loinc.org|85354-9</pre>
 
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.
+
|  
 +
The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.
 +
* The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
 +
* The Observation.effectiveDateTime is used to determine the last known Observation.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 13.2 Body weight
 
|-
 
|-
−
| Body Weight
 
−
| Search
 
−
| <pre>
 
−
http://loinc.org
 
−
29463-7
 
−
"Body weight"</pre>
 
 
| <pre>GET [base]/Observation/$lastn?
 
| <pre>GET [base]/Observation/$lastn?
 
code=http://loinc.org|29463-7</pre>
 
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.
+
|  
 +
The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.
 +
* The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
 +
* The Observation.effectiveDateTime is used to determine the last known Observation.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 13.3 Body height
 +
|-
 +
| <pre>GET [base]/Observation/$lastn?
 +
code=http://loinc.org|8302-2,
 +
http://loinc.org|8306-3,
 +
http://loinc.org|8308-9 </pre>
 +
|
 +
The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.
 +
* By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
 +
* If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
 +
* The Observation.effectiveDateTime is used to determine the last known Observation.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 14 Results
 +
|-
 +
!  colspan="2" style="text-align: left;" | 14.1 Laboratory test result
 +
|-
 +
| <pre>GET [base]/Observation/$lastn?
 +
category=http://snomed.info/sct|49581000146104
 +
&_include=Observation:related-target</pre>
 +
|
 +
All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.
 +
* Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
 +
* The optional ResultType is not used when selecting Laboratory results for exchange.
 +
* The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 15 Procedures
 +
|-
 +
!  colspan="2" style="text-align: left;" | 15.1 Procedure
 +
|-
 +
| <pre>GET [base]/Procedure?
 +
category=http://snomed.info/sct|387713003,
 +
http://snomed.info/sct|258174001</pre>
 +
|
 +
All operative and image guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.
 +
* Surgical procedure are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
 +
* Image guided procedures are exchanged via an instance where the Procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
 +
Procedure instances with any other category that the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 16 Encounters
 +
|-
 +
!  colspan="2" style="text-align: left;" | 16.1 Encounter
 +
|-
 +
| <pre>GET [base]/Encounter</pre>
 +
|
 +
All Encounters available in the source system are exchanged as FHIR Encounter instances that conform to the zib-Encounter profile.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 17 Planned care activity
 +
|-
 +
!  colspan="2" style="text-align: left;" | 17.1 Procedure
 +
|-
 +
|
 +
<pre>
 +
GET [base]/ProcedureRequest?status=active
 +
</pre>
 +
|
 +
All planned procedures available in the source system are exchanged as FHIR ProcedureRequest instances according to the zib-ProcedureRequest profile.
 +
|-
 +
! scope="row" colspan="2" style="text-align: left;" | 18 Care Setting
 +
|-
 +
!  colspan="2" style="text-align: left;" | 18.1 Health professional
 +
|-
 +
|
 +
<pre>
 +
GET [base]/CareTeam?status=active&_include=CareTeam:participant
 +
</pre>
 +
|
 +
All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.
 +
* Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
 +
|-
 +
!  colspan="2" style="text-align: left;" | 18.2 Healthcare provider
 +
|-
 +
|
 +
<pre>
 +
see Procedure.performer (nl-code-organization)
 +
see Encounter.serviceProvider (nl-code-organization)
 +
</pre>
 +
|
 +
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
 +
|-
 +
! colspan="2" style="text-align: left;" | 19  Meta data
 +
|-
 +
! colspan="2" style="text-align: left;" | 19.1 Meta data
 +
|-
 +
| <pre>GET [base]/Provenance</pre>
 +
|
 +
All provenance data available in the source system for a specific BgZ summary is exchanged as FHIR provenance instances according to the BgZ-metadata profile.
 +
|-
 +
|}
 +
 
 +
==FHIR Task.input Query Specification==
 +
The following table provides the overview of codings needed to retrieve all the BgZ MSZ items. The '''FHIR Task.input.type.coding''' column defines codedConcepts that identify the BgZ MSZ item (HCIM) to retrieve. Each codedConcept is defined in terms of the codeSystem, code.
 +
 
 +
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.
 +
 
 +
{| class="wikitable" width="100%" style="horizontal-align: right"
 +
! style="text-align:left;  background-color: #E3E3E3 width:200px" | Section
 +
! style="text-align:left;  background-color: #E3E3E3 width:200px" | Component
 +
! style="text-align:left;  background-color: #E3E3E3 width:200px" | FHIR Task.input.type.coding
 +
! style="text-align:left;  background-color: #E3E3E3 width:200px" | Name
 +
|-
 +
| rowspan="2" | 1 Demographics and identification
 +
| 1.1 Patient
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/79191-3</span>
 +
| Patient demographics panel
 +
|-
 +
| 1.2 Marital status
 +
| <span STYLE="font-family:'Courier'; font-weight:700">Data are exchanged as part of the patient.</span>
 +
|-
 +
| 2 Financial information
 +
| 2.1 Payer
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/48768-6</span>
 +
| Payment sources Document
 +
|-
 +
| rowspan="2" | 3 Treatment restrictions
 +
| 3.1 Treatment instructions
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/11291000146105</span>
 +
| Treatment instructions
 +
|-
 +
| 3.2 Advance directive
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/11341000146107</span>
 +
 
 +
9421000146109 Advance directives (record artifact)
 +
 
 +
| Living will and advance directive record
 +
|-
 +
| 4 Contact persons
 +
| 4.1 Contact
 +
| <span STYLE="font-family:'Courier'; font-weight:700">Data are exchanged as part of the patient.</span>
 +
|-
 +
| 5 Functional/mental status
 +
| 5.1 Functional or mental status
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/47420-5</span>
 +
| Functional status assessment note
 +
|-
 +
| 6 Complaints and diagnoses
 +
| 6.1 Problem
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/11450-4</span>
 +
| Problem list - Reported
 +
|-
 +
| rowspan="5" | 7 Social history
 +
| 7.1 Living Situation
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/365508006</span>
 +
| Residence and accommodation circumstances - finding
 +
|-
 +
| 7.2 Drug Use
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/228366006</span>
 +
| Finding relating to drug misuse behavior
 +
|-
 +
| 7.3 Alcohol Use
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/228273003</span>
 +
| Finding relating to alcohol drinking behavior
 +
|-
 +
| 7.4 Tobacco Use
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/365980008</span>
 +
| Tobacco use and exposure - finding
 +
|-
 +
| 7.5 Nutrition Advice
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/11816003</span>
 +
| Diet education
 +
|-
 +
| 8 Alerts
 +
| 8.1 Alert
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/75310-3</span>
 +
| Health concerns Document
 +
|-
 +
| 9 Allergies
 +
| 9.1 Allergy Intolerance
 +
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/48765-2</span>
 +
| Allergies and adverse reactions Document
 +
|-
 +
| rowspan="3" | 10 Medication
 +
| 10.1 Medication Agreement
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/422979000</span>
 +
| Known medication use
 +
|-
 +
| 10.2 Administration Agreement
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/422037009</span>
 +
| Known administration agreements
 +
|-
 +
| 10.3 Medication Use
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/16076005</span>
 +
| Known medication agreements
 +
|-
 +
| 11 Medical devices
 +
| 11.1 Medical device
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/46264-8</span>
 +
| Known medical aids
 +
|-
 +
| 12 Vaccinations
 +
| 12.1 Vaccination
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/11369-6</span>
 +
| History of Immunization Narrative
 +
|-
 +
| rowspan="3" | 13 vital signs and measurements
 +
| 13.1 Blood pressure
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/85354-9</span>
 +
| Blood pressure
 +
|-
 +
| 13.2 Body weight
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/29463-7</span>
 +
| Body weight
 
|-
 
|-
−
| Body Height
+
| 13.3 Body height
−
| Search
+
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/8302-2</span>
−
| <pre>
+
| Body height
−
http://loinc.org
 
−
8302-2
 
−
"Body height"</pre>
 
−
|For last height value:
 
−
<pre>GET [base]/Observation/$lastn?
 
−
code=http://loinc.org|8302-2, http://loinc.org|8306-3, http://loinc.org|8308-9 </pre>
 
 
|-
 
|-
 
| 14 Results
 
| 14 Results
−
| Laboratory Test Result
+
| 14.1 Laboratory test result
−
| Search
+
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/15220000</span>
−
| <pre>
+
 
−
http://snomed.info/sct
+
422680004 Battery entry (record artifact)
−
15220000
+
 
−
"Laboratory test"</pre>
+
| Laboratory test
−
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|49581000146104&_include=Observation:related-target</pre>
 
−
| The Receiving System gets the most recent version of the Laboratory Test last registered for all "Laboratory" observations, per Laboratory PanelOrBattery in the Sending System. The optional result Type of the Laboratory Result is not used for filtering. The result Type will be sent along with the data if available.
 
 
|-
 
|-
 
| 15 Procedures
 
| 15 Procedures
−
| Procedure
+
| 15.1 Procedure
−
| Search
+
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/47519-4</span>
−
| <pre>
+
| History of Procedures
−
http://snomed.info/sct
 
−
71388002
 
−
"Procedure"</pre>
 
−
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003,http://snomed.info/sct|258174001</pre>
 
−
| The Receiving System gets all operative and diagnostic procedures available in the Sending System.
 
 
|-
 
|-
 
| 16 Encounters
 
| 16 Encounters
−
| Encounter
+
| 16.1 Encounter
−
| Search
+
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/46240-8</span>
−
| <pre>
+
| History of Hospitalizations+Outpatient visits Narrative
−
http://loinc.org
+
|-
−
46240-8
+
| 17 Planned care activity
−
"History of Hospitalizations+Outpatient visits Narrative"</pre>
+
| 17.1 Procedure
−
| <pre>GET [base]/Encounter?_include=Encounter:serviceProvider</pre>
+
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/18776-5</span>
−
| The Receiving System gets all contacts registered in the Sending System.  
+
| Plan of care note
 +
|-
 +
| rowspan="2" | 18 Care Setting
 +
| 18.1 Health professional
 +
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/229774002</span>
 +
| Healthcare professional (occupation)
 +
|-
 +
| 18.2 Healthcare provider
 +
| <span STYLE="font-family:'Courier'; font-weight:700">Data are exchanges as part of other BgZ components.</span>
 
|-
 
|-
−
| 17 Care Setting
+
| 19 Meta data
−
| Healthcare Provider
+
| 19.1 Meta data
−
| Read
+
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/257733005</span>
−
| <pre>
+
| Activity (the Provenance resource tracks information about the activity that created a version of a resource)
−
http://snomed.info/sct
 
−
229774002
 
−
"Caregiver"</pre>
 
−
| <pre>GET [base]/CareTeam?status=active&
 
−
_include=CareTeam:participant</pre>
 
−
<small>NOTE: .status needs to be present in the resource to get current relationships and practitioners</small>
 
−
| 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.
 
 
|-
 
|-
 
|}
 
|}
Regel 523: Regel 675:
  
 
==Referenced BgZ FHIR Resources==
 
==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.
 
−
 
 
Each FHIR profile contains a 'mappings' tab that reflects the identifiers, found at [https://zibs.nl/wiki/HCIM_Release_2017(EN) release 2017 zibs/HCIMs]. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] regarding mappings in FHIR.  
 
Each FHIR profile contains a 'mappings' tab that reflects the identifiers, found at [https://zibs.nl/wiki/HCIM_Release_2017(EN) release 2017 zibs/HCIMs]. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] regarding mappings in FHIR.  
  
Regel 710: Regel 860:
 
| CareTeam
 
| CareTeam
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-careteam|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
 +
|-
 +
| 16
 +
| Metadata
 +
| Provenance
 +
| Provenance
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/bgz-metadata|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
 
|}
 
|}
 
<small>''Table 5.2 Referenced BgZ FHIR Resources''</small>
 
<small>''Table 5.2 Referenced BgZ FHIR Resources''</small>
 +
 
=Infrastructure=
 
=Infrastructure=
 
==Generic Infrastructure==
 
==Generic Infrastructure==
 
The implementation guideline assumes that a generic infrastructure is available to provide for services like:
 
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?)
+
* Identification [NEN-7518]  
−
* Authentication [NEN-7518] (establish that you really are who you say)
+
* Authentication [NEN-7518]  
−
* Localization [NEN-7519]  (where/what information known about the client and provider?)
+
* Localization [NEN-7519]   
−
* Consent [NEN-7517] (from the patient for the sharing of medical information)
+
* Consent [NEN-7517]  
−
* Authorization (what information are you allowed to access?)
+
* Authorization  
−
* Addressing (digital address of provider or organization)
+
* Addressing
−
* Logging [NEN-7513] (audit trail - who did what, where, when and why?)
+
* Logging [NEN-7513]
  
−
==Expiration Time (exp) Claim==
+
==Expiration Time (exp)==
−
The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.
+
The "exp" (expiration time) is configured at time of creating the notication by the notification party. It is assumed that the party who is referring the patient is aware of the expiration time.
−
 
 
−
The value of the expiration time used in this Implementation Guide is (to be filled in).
 
  
 
=References=
 
=References=
Regel 736: Regel 891:
 
|-
 
|-
 
| | [1]
 
| | [1]
−
| | 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
 
−
|-
 
−
| | [2]
 
−
| | NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg
 
−
<small>''Translates as “Exchange of BgZ between institutions for specialist medical care”''</small>
 
−
| | ICS 11.020.01;35.240.80 maart 2024
 
−
|-
 
−
| | [3]
 
 
| | Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism
 
| | Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism
 
| | Version: 1.0.0 06-03-24
 
| | Version: 1.0.0 06-03-24
Regel 756: Regel 901:
 
! style="font-weight: bold;text-align:left;" | BITS ticket
 
! style="font-weight: bold;text-align:left;" | BITS ticket
 
! style="font-weight: bold;text-align:left;" | Short description
 
! style="font-weight: bold;text-align:left;" | 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"
 
 
|-  
 
|-  
 
| [https://bits.nictiz.nl/browse/MSZ-139 MSZ-139]
 
| [https://bits.nictiz.nl/browse/MSZ-139 MSZ-139]

Huidige versie van 6 nov 2024 om 21:48

Back to Top

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 Introduction

1.1 Background

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

This BgZ MSZ implementation guide defines the BgZ information exchanges, in terms of use cases, based on the Zib2017 and FHIR(STU3) HL7 FHIR, STU3.

HL7 CDA is no longer supported for BgZ MSZ exchange. This implementation guide assumes that the reader is familiar with this FHIR version.

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

1.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 document provides background information:

  • "Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism" [1]

This implementation guide is intended to provide information for implementation/deployment needs in the Netherlands.

1.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.
VZVZ Vereniging van Zorgaanbieders voor Zorgcommunicatie: Dutch Association for Health Providers

Table 2.1 Glossary

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

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

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

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

3.1.2 Transactions

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

  • Notified Pull (preferred)
  • Push

3.1.2.1 Exchange BgZ for Referral using Notified Pull Transaction

The Notified Pull communication pattern is based on the description in [1]. 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.

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

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

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

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

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

  1. Notification Update
  2. Notification Cancellation

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

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

3.2 Retrieval of BgZ from previous practitioner

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.

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

3.2.2 Transactions

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

4 FHIR Profiles

4.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://nictiz.nl/fhir/StructureDefinition/BgZ-NotificationTask

4.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://nictiz.nl/fhir/StructureDefinition/BgZ-WorkflowTask

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

4.4 FHIR Query Specification

The table below provides an overview of the FHIR queries to exchange all BgZ-msz elements.

Query Description
1 Demographics and identification
1.1 Patient 
GET [base]/Patient?
_include=Patient:general-practitioner

The patient information available in the source system is exchanged as a FHIR patient instance that conforms to the nl-core-patient profile.

  • The last known marital status available in the source system is exchanged using the patient.maritalStatus field.
  • If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
  • Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
1.2 Marital status 
see Patient.maritalStatus

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

2 Financial information
2.1 Payer 
GET [base]/Coverage?
_include=Coverage:payor

The payer data available in the source system is exchanged as a FHIR coverage instance that conforms to the zib-Payer profile.

  • The specified referenced payor resource instances, that may be of type nl-core-organization, nl-core-patient, or nl-core-relatedperson, are returned in full.
3 Treatment restrictions
3.1 Treatment instructions 
GET [base]/Consent?
category=http://snomed.info/sct|11291000146105

All treatmentDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-TreatmentDirective profile.

  • The consent.category is fixed to ‘treatment instructions’ (code = '11291000146105' in codeSystem 'SNOMED CT').
3.2 Advance directive 
GET [base]/Consent?
category=http://snomed.info/sct|11341000146107

All AdvanceDirectives available in the source system are exchanged as FHIR consent instances, which conform to the zib-AdvanceDirective profile.

  • The consent.category is fixed to ‘levenstestament en wilsverklaring in dossier’ (code = '11341000146107' in codeSystem 'SNOMED CT').
  • the document is only exchanged via a pdf.
4 Contact persons
4.1 Contact 
Patient.contact

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

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

All functional or mental status information available in the source system is exchanged as FHIR observation data that conforms to the zib-FunctionalOrMentalStatus profile.

  • Functional status data are exchanged with the observation.category fixed to ‘Functional finding’ (code = '118228005' in codeSystem 'SNOMED CT').
  • Mental status data are exchanged with the observation.category fixed to ‘Mental state, behavior and/or psychosocial function finding’ (code = '384821006 ' in codeSystem 'SNOMED CT').
  • please note that as defined in the BgZ dataset, the category may be both a functional and a mental status.
  • The target system may be configured to optimize the use of this information. For example, it may be configured to group and categorize according to StatusName regarding mental, hearing, vision, mobility and language skills.
6 Complaints and diagnoses
6.1 Problem 
GET [base]/Condition

All problems available in the source system are returned as zib-Problem instances.

  • The condition.ProblemStatus must be populated when exchanging data. In cases where for legacy data there is no Problem.ProblemStatus recorded in the source system then the Condition.clinicalStatus field must be populated with an assumed state such as “active” if there is no problemEndDate defined. It is a known problem that the data-absent-reason cannot be used. This aspect is under investigation.
  • Note that no Condition.category (e.g. diagnosis or symptom) may be assumed while exchanging data if the condition.category is not known.
  • Note that the condition.code can exchange multiple encodings for the same problem. In the transaction it is defined that a problem may contain an additional more specific problemName that is exchanged using a second condition.code.coding.
7 Social history
7.1 Living Situation 
GET [base]/Observation?
code=http://snomed.info/sct|365508006

All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.

  • The Observation.category is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
  • The HouseType cardinality is 1..1R and must be exchanged accordingly.
7.2 Drug Use 
GET [base]/Observation?
code=http://snomed.info/sct|228366006

All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.

  • The Observation.category is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
  • The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
7.3 Alcohol Use 
GET [base]/Observation?
code=http://snomed.info/sct|228273003

All known alcohol use, available in the source system, is exchanged as FHIR Observations that conform to the zib-AlcoholUse profile.

  • The Observation.category is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
7.4 Tobacco Use 
GET [base]/Observation?
code=http://snomed.info/sct|365980008

All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.

  • The Observation.category is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
7.5 Nutrition Advice 
GET [base]/NutritionOrder

All Nutrition Advice available in the source system is exchanged as a FHIR NutritionOrder instances that conform to the zib-NutritionAdvice profile.

  • The target system may be configured to optimize the use of this information. For example, grouping data according to a specific NutritionOrder.oralDiet.type.
8 Alerts
8.1 Alert 
GET [base]/Flag

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

9 Allergies
9.1 Allergy Intolerance 
GET [base]/AllergyIntolerance

All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.

  • According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with the ‘unknown’ data-absent-reason.
"manifestation":{
   "extension": [{
      "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
      "valueCode": "unknown"
    }]
  },
10 Medication
10.1 Medication Agreement 
GET [base]/MedicationRequest?
category=http://snomed.info/sct|16076005&
_include=MedicationRequest:medicationReference

All medication agreements available in the source system are exchanged FHIR MedicationRequest instances that conform to the zib-MedicationAgreement profile.

  • The MedicationRequest.category is fixed to ‘Prescription’ (code = '16076005' in codeSystem 'SNOMED CT')
  • The PharmaceuticalProduct agreed upon to be used is returned in full as FHIR Medication instance according to the zib-Product profile.
10.2 Administration Agreement 
GET [base]/MedicationDispense?
category=http://snomed.info/sct|422037009&
_include=MedicationDispense:medicationReference

All administration agreements available in the source system are exchanged FHIR MedicationDispense instances that conform to the zib-AdministrationAgreement profile.

  • The MedicationDispense.category is fixed to ‘Provider medication administration instructions’ (code = '422037009' in codeSystem 'SNOMED CT')
  • The PharmaceuticalProduct in the agreement is returned in full as FHIR Medication instance according to the zib-Product profile.
10.3 Medication Use 
GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medicationReference

All medication use available in the source system are exchanged FHIR MedicationStatement instances that conform to the zib-MedicationUse profile.

  • The MedicationStatement.category is fixed to ‘Medicatiegebruik’ (code = '6' in codeSystem ' 2.16.840.1.113883.2.4.3.11.60.20.77.5.3')
  • The PharmaceuticalProduct that is used is returned in full as FHIR Medication instance according to the zib-Product profile.
11 Medical devices
11.1 Medical device 
GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device

All device use statements available in the source system are exchanged as FHIR DeviceUseStatement instances that conform to the zib-MedicalDevice profile.

  • The actual medical device products are returned in full as FHIR Device instances that conform to the zib-MedicalDevice profile.
12 Vaccinations
12.1 Vaccination 
GET [base]/Immunization?
status=completed

All administered vaccinations available in the source system are exchanged as FHIR Immunization instances conforming to the zib-Vaccination profile.

  • Only vaccinations that have been administered are exchanged. Effectively, the Immunization.status is always fixed to ‘completed’.
13 vital signs and measurements
13.1 Blood pressure 
GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9

The last known Blood pressure available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BloodPressure profile.

  • The Observation.category is fixed to ‘Blood pressure panel with all children optional’ (code = '85354-9' in codeSystem 'LOINC').
  • The Observation.effectiveDateTime is used to determine the last known Observation.
13.2 Body weight 
GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7

The last known Body Weight available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyWeight profile.

  • The Observation.category is fixed to ‘Body weight’ (code = ' 29463-7' in codeSystem 'LOINC').
  • The Observation.effectiveDateTime is used to determine the last known Observation.
13.3 Body height 
GET [base]/Observation/$lastn?
code=http://loinc.org|8302-2, 
http://loinc.org|8306-3, 
http://loinc.org|8308-9

The last known Body Height available in the source system is exchanged as a FHIR Observation instance that conforms to the zib-BodyHeight profile.

  • By default, the Observation.category is fixed to ‘Body height’ (code = ' 29463-7' in codeSystem 'LOINC').
  • If it is recorded that a measurement is taken while the patient is lying or standing, ‘Body height --lying’ (code = ‘8306-3’ in CodeSystem ‘LOINC’) or ‘Body height --standing’ (code = ‘8308-9’ in CodeSystem ‘LOINC’) are used.
  • The Observation.effectiveDateTime is used to determine the last known Observation.
14 Results
14.1 Laboratory test result 
GET [base]/Observation/$lastn?
category=http://snomed.info/sct|49581000146104
&_include=Observation:related-target

All last known Laboratory results, with the most recent test result for each PanelOrBattery, are exchanged as FHIR observations conforming to the zib-LaboratoryTestResult-Observation profile.

  • Per PanelOrBattery, all known laboratory tests are exchanged, regardless of their TestDateTime. They are exchanged as related observations with the PanelOrBattery-observation.
  • The optional ResultType is not used when selecting Laboratory results for exchange.
  • The resultStatus cardinality is 1..1R in contract to the zib and must be exchanged accordingly. The LaboratoryTestResult has a DateTime property that is used by the lastn algorithm.
15 Procedures
15.1 Procedure 
GET [base]/Procedure?
category=http://snomed.info/sct|387713003,
http://snomed.info/sct|258174001

All operative and image guided procedures available in the source system are exchanged as FHIR Procedure instances that conform to the zib-Procedure profile.

  • Surgical procedure are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
  • Image guided procedures are exchanged via an instance where the Procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).

Procedure instances with any other category that the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).

16 Encounters
16.1 Encounter 
GET [base]/Encounter

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

17 Planned care activity
17.1 Procedure 
GET [base]/ProcedureRequest?status=active

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

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

All health professionals available in the source system are exchanged as part of a CareTeam instance according to the nl-core-careteam profile.

  • Practitioners are returned in full as FHIR Practitioner instances according to the nl-core-practitioner profile.
18.2 Healthcare provider 
see Procedure.performer (nl-code-organization)
see Encounter.serviceProvider (nl-code-organization)

Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.

19 Meta data
19.1 Meta data 
GET [base]/Provenance

All provenance data available in the source system for a specific BgZ summary is exchanged as FHIR provenance instances according to the BgZ-metadata profile.

4.5 FHIR Task.input Query Specification

The following table provides the overview of codings needed to retrieve all the BgZ MSZ items. The FHIR Task.input.type.coding column defines codedConcepts that identify the BgZ MSZ item (HCIM) to retrieve. Each codedConcept is defined in terms of the codeSystem, code.

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.

Section Component FHIR Task.input.type.coding Name
1 Demographics and identification 1.1 Patient http://loinc.org/79191-3 Patient demographics panel
1.2 Marital status Data are exchanged as part of the patient.
2 Financial information 2.1 Payer http://loinc.org/48768-6 Payment sources Document
3 Treatment restrictions 3.1 Treatment instructions http://snomed.info/sct/11291000146105 Treatment instructions
3.2 Advance directive http://snomed.info/sct/11341000146107

9421000146109 Advance directives (record artifact)

Living will and advance directive record
4 Contact persons 4.1 Contact Data are exchanged as part of the patient.
5 Functional/mental status 5.1 Functional or mental status http://loinc.org/47420-5 Functional status assessment note
6 Complaints and diagnoses 6.1 Problem http://loinc.org/11450-4 Problem list - Reported
7 Social history 7.1 Living Situation http://snomed.info/sct/365508006 Residence and accommodation circumstances - finding
7.2 Drug Use http://snomed.info/sct/228366006 Finding relating to drug misuse behavior
7.3 Alcohol Use http://snomed.info/sct/228273003 Finding relating to alcohol drinking behavior
7.4 Tobacco Use http://snomed.info/sct/365980008 Tobacco use and exposure - finding
7.5 Nutrition Advice http://snomed.info/sct/11816003 Diet education
8 Alerts 8.1 Alert http://loinc.org/75310-3 Health concerns Document
9 Allergies 9.1 Allergy Intolerance http://loinc.org/48765-2 Allergies and adverse reactions Document
10 Medication 10.1 Medication Agreement http://snomed.info/sct/422979000 Known medication use
10.2 Administration Agreement http://snomed.info/sct/422037009 Known administration agreements
10.3 Medication Use http://snomed.info/sct/16076005 Known medication agreements
11 Medical devices 11.1 Medical device http://loinc.org/46264-8 Known medical aids
12 Vaccinations 12.1 Vaccination http://loinc.org/11369-6 History of Immunization Narrative
13 vital signs and measurements 13.1 Blood pressure http://loinc.org/85354-9 Blood pressure
13.2 Body weight http://loinc.org/29463-7 Body weight
13.3 Body height http://loinc.org/8302-2 Body height
14 Results 14.1 Laboratory test result http://snomed.info/sct/15220000

422680004 Battery entry (record artifact)

Laboratory test
15 Procedures 15.1 Procedure http://loinc.org/47519-4 History of Procedures
16 Encounters 16.1 Encounter http://loinc.org/46240-8 History of Hospitalizations+Outpatient visits Narrative
17 Planned care activity 17.1 Procedure http://loinc.org/18776-5 Plan of care note
18 Care Setting 18.1 Health professional http://snomed.info/sct/229774002 Healthcare professional (occupation)
18.2 Healthcare provider Data are exchanges as part of other BgZ components.
19 Meta data 19.1 Meta data http://snomed.info/sct/257733005 Activity (the Provenance resource tracks information about the activity that created a version of a resource)

Table 5.1 FHIR Task.input Query Specification

4.6 Referenced BgZ FHIR Resources

Each FHIR profile contains a 'mappings' tab that reflects the identifiers, found at release 2017 zibs/HCIMs. The reader should take note of the 'Relating FHIR profiles with their functional definitions' regarding mappings in FHIR.

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
16 Metadata Provenance Provenance http://nictiz.nl/fhir/StructureDefinition/bgz-metadata

Table 5.2 Referenced BgZ FHIR Resources

5 Infrastructure

5.1 Generic Infrastructure

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

  • Identification [NEN-7518]
  • Authentication [NEN-7518]
  • Localization [NEN-7519]
  • Consent [NEN-7517]
  • Authorization
  • Addressing
  • Logging [NEN-7513]

5.2 Expiration Time (exp)

The "exp" (expiration time) is configured at time of creating the notication by the notification party. It is assumed that the party who is referring the patient is aware of the expiration time.

6 References

Reference Document Title Date, Version, Source
[1] Technical Agreement - Exchanging FHIR Data using a generic Notified Pull mechanism Version: 1.0.0 06-03-24

7 Release Notes

Changes compared to previous release.

BITS ticket Short description
MSZ-139 BgZ-MSZ alpha 2.0 Technical Design Feedback
Overgenomen van "https://informatiestandaarden.nictiz.nl/index.php?title=BgZ:V2.0_Beta_BgZ_2017_Technical_IG&oldid=231742"