BgZ Medisch-Specialistische Zorg Technical Implementation Guide 2.0
Dit is een tijdelijke pagina met wijzigingen voor issue NICTIZ-14348. De gepubliceerde versie vind je hier. |
This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. |
Inhoud
- 1 Introduction
- 2 Boundaries and Relationships
- 3 Systems and System Roles
- 4 Use Cases
- 5 BgZ Item Type Identification
- 6 FHIR Queries
- 7 FHIR Profiles
- 8 Infrastructure
- 9 References
- 10 Release Notes
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 HL7 FHIR STU3 releases. HL7 CDA is no longer supported for BgZ MSZ exchange.
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 link...
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.
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. |
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. |
2 Boundaries and Relationships
3 Systems and System Roles
System roles are further defined through the Healthcare Information Exchange model of "Registratie aan de Bron" ("Register at the source").
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 would 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:
- the HCIM definitions and technical artefacts
- the Qualification Scenario's
- in the Metadata see FO (add link)
4 Use Cases
Two use cases are defined in the "NEN 7540:2024 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg" [2] as follows:
- Send BgZ ("Verzenden BgZ") from a referring healthcare provider to a receiving healthcare provider in the event of a planned referral or transfer between their two care institutions.
- Retrieve BgZ ("Opvragen BgZ") by a 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 Send BgZ from Referring to Receiving Medical Specialist
In the "Send BgZ" use case, the current healthcare provider (Referring 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 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 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 "Send BgZ" use case can be implemented using two types of transactions:
- Notified Pull (preferred)
- Push
4.1.2.1 Send BgZ using Notified Pull Transaction
The Notified Pull transaction is based on the description in [3]. The Referring Medical Specialist notifies the Receiving Medical Specialist about the referral or transfer by sending a Notification Message. The Receiving Medical Specialist can then retrieve the BgZ (at a suitable time) using the Pull Message(s) which is(are) defined as a part of the Notification Message.
This two stage approach separates the notification phase from the actual BgZ retrieval phase allowing the Receiving Medical Specialist to decide if, and when, to retrieve the BgZ.
The FHIR profiles describing the Notification (Task) message, the optional 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 Queries section.
4.1.2.2 Send BgZ using Push Transaction
The Referring Medical Specialist pushes the BgZ to the Receiving Medical Specialist at the time of referral or transfer and not necessarily at the time when the Receiving Medical Specialist requires the BgZ (if it is required at all).
The Push method always transfers the BgZ to the Receiving Medical Specialist even when it might not be wanted or needed.
The FHIR profiles describing the BgZ item resources are defined in the FHIR Profiles section.
Note: The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR where the CDA based BgZ is replaced by a FHIR Composition and pushed between sending and receiving systems.
4.2 Retrieve BgZ by Querying Medical Specialist (out of scope V2.0)
In the "Retrieve BgZ" use case, the current healthcare provider (Querying 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 |
Querying Medical Specialist | Medical specialist who queries for a BgZ | EHR | Electronic health record |
It is assumed that the Querying 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 Retrieve BgZ using Pull Transaction
The Querying Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message.
The FHIR profiles describing the retrieved BgZ item resources are defined in the FHIR Profiles section.
The FHIR search/read queries used to retrieve the BgZ item resources are defined in the FHIR Queries section.
5 BgZ Item Type Identification
The BgZ item types are identified using codes taken from both LOINC and SNOMED-CT code sets as shown in the following table:
HCIM Name | Code | System |
---|---|---|
Patient MaritalStatus ContactPerson HealthProfessional |
79191-3 | http://loinc.org |
Payer | 48768-6 | http://loinc.org |
TreatmentDirective | 11291000146105 | http://snomed.info/sct |
AdvanceDirective | 11341000146107 | http://snomed.info/sct |
FunctionalOrMentalStatus | 47420-5 | http://loinc.org |
Problem | 11450-4 | http://loinc.org |
LivingSituation | 365508006 | http://snomed.info/sct |
DrugUse | 228366006 | http://snomed.info/sct |
AlcoholUse | 228273003 | http://snomed.info/sct |
TobaccoUse | 365980008 | http://snomed.info/sct |
NutritionAdvice | 11816003 | http://snomed.info/sct |
Alert | 75310-3 | http://loinc.org |
AllergyIntolerance | 48765-2 | http://loinc.org |
MedicationAgreement | 16076005 | http://snomed.info/sct |
AdministrationAgreement | 422037009 | http://snomed.info/sct |
MedicationUse2 | 422979000 | http://snomed.info/sct |
MedicalDevice | 46264-8 | http://loinc.org |
Vaccination | 11369-6 | http://loinc.org |
BloodPressure | 85354-9 | http://loinc.org |
BodyWeight | 29463-7 | http://loinc.org |
BodyHeight | 8302-2 | http://loinc.org |
LaboratoryTestResult | 15220000 | http://snomed.info/sct |
Procedure | 47519-4 | http://loinc.org |
Encounter | 46240-8 | http://loinc.org |
PlannedCareActivityForTransfer | 18776-5 | http://loinc.org |
6 FHIR Queries
The BgZ is retrieved using individual search interactions. The BgZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgZ, the client can use multiple individual search operations based on specified search queries. The interactions are performed by an HTTP GET as shown:
GET [base]/[type]{?[parameters]}
The table below shows in the first four columns the BgZ sections, the HCIMs that constitute those sections and the specific content of the BgZ. The last column shows the FHIR search queries to obtain the BgZ information. These queries and expected responses are based on profiles listed in the Referenced BgZ Resources section.
# | BgZ Section | HCIM EN | Content | Search URL[1] | ||||
---|---|---|---|---|---|---|---|---|
1 | Patient information | Patient | Identification, birth date, gender, deceased indicator, contact details, last known marital status, and general practitioner (practitioner or organization) | GET [base]/Patient?_include=Patient:general-practitioner | ||||
2 | Payment details | Payer | Insurance information | GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization | ||||
3 | Treatment directives | TreatmentDirective | Known treatment directives | GET [base]/Consent?category=http://snomed.info/sct|11291000146105 | ||||
AdvanceDirective | Known advance directives | GET [base]/Consent?category=http://snomed.info/sct|11341000146107 | ||||||
4 | Contact persons | ContactPerson | First relation/contact | see Patient | ||||
5 | Functional status | FunctionalOrMentalStatus | Last known functional / mental status | GET [base]/Observation/$lastn?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006
| ||||
6 | Problems | Concern | All known problems | GET [base]/Condition | ||||
7 | Social history | LivingSituation | Current living situation | GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006 | ||||
DrugUse | All known drug use | GET [base]/Observation?code=http://snomed.info/sct|228366006 | ||||||
AlcoholUse | All known alcohol use | GET [base]/Observation?code=http://snomed.info/sct|228273003 | ||||||
TobaccoUse | All known tobacco use | GET [base]/Observation?code=http://snomed.info/sct|365980008 | ||||||
NutritionAdvice | All known dietary recommendations | GET [base]/NutritionOrder | ||||||
8 | Alerts | Alert | All known alerts | GET [base]/Flag | ||||
9 | Allergies | AllergyIntolerance | All known information regarding allergies | GET [base]/AllergyIntolerance | ||||
10 | Medication | MedicationUse | Known medication use | todo ref MP9 | ||||
MedicationAgreement | Known medication agreements | todo ref MP9 | ||||||
AdministrationAgreement | Known administration agreements | todo ref MP9 | ||||||
11 | Medical aids | MedicalDevice | Known medical aids | GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device | ||||
12 | Vaccinations | Vaccination | Known vaccinations | GET [base]/Immunization?status=completed | ||||
13 | Vital signs | BloodPressure | Last known blood pressure | GET [base]/Observation/$lastn?code=http://loinc.org|85354-9 | ||||
BodyWeight | Last known body weight | GET [base]/Observation/$lastn?code=http://loinc.org|29463-7 | ||||||
BodyHeight | Last known body height | GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9 | ||||||
14 | Results | LaboratoryTestResult | Last known laboratory results per type | GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen | ||||
15 | Procedures | Procedure | Known surgical procedures | GET [base]/Procedure?category=http://snomed.info/sct|387713003 | ||||
16 | Encounters | Contact | Known hospital admissions (no outpatient contacts) | 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 | ||||
17 | Planned care | PlannedCareActivityForTransfer | Known planned care activities |
GET [base]/ProcedureRequest?status=active GET [base]/ImmunizationRecommendation GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&status=in-progress,preparation&_include=MedicationDispense:medication
GET [base]/DeviceRequest?status=active&_include=DeviceRequest:device GET [base]/Appointment?status=booked,pending,proposed | ||||
18 | Care setting | HealthProfessional | General Practitioner of the patient | todo query HealthProfessional |
||||
HealthProvider | Health provider of the patient | todo query HealthProvider |
7 FHIR Profiles
7.1 Notification Task
7.2 Workflow Task
7.3 Referenced BgZ 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.
8 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?)
9 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 |
10 Release Notes
Changes compared to previous release.
BITS ticket | Short description |
---|---|
NICTIZ-14769 | Ontwikkelen/schrijven van de TO in de wiki |
- ↑ See Search URLs and search parameters for the interpretation of these search URLs