BgZ:V2.0 Beta 2 BgZ 2017 Technical IG: verschil tussen versies
k (→Mapping between profiles and dataset) |
k |
||
| (20 tussenliggende versies door 2 gebruikers niet weergegeven) | |||
| Regel 6: | Regel 6: | ||
<!-- EINDE BACK TO TOP BUTTON --> | <!-- EINDE BACK TO TOP BUTTON --> | ||
| − | |||
__NUMBEREDHEADINGS__ | __NUMBEREDHEADINGS__ | ||
__NOINDEX__ | __NOINDEX__ | ||
| − | {{DISPLAYTITLE:BgZ | + | {{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0-beta.1}} |
__TOC__ | __TOC__ | ||
| Regel 25: | Regel 24: | ||
Please note that this version of the BgZ-MSZ describes the exchange of all BgZ chapters. | Please note that this version of the BgZ-MSZ describes the exchange of all BgZ chapters. | ||
| − | In future versions of the BgZ it is expected that implementation guides will be modularized and that for subsets of the BgZ | + | In future versions of the BgZ it is expected that implementation guides will be modularized and that for subsets of the BgZ references will be made to other information standards such as Medication Process, and Lab. |
| + | |||
| + | In future versions the gap to the European patient summary will be addressed. | ||
== Building blocks and FHIR profiles == | == Building blocks and FHIR profiles == | ||
| − | Data exchange of the BgZ is | + | Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models). |
| + | Table 3 contains an overview of all FHIR building blocks, including custom building blocks. | ||
| − | * The Metadata building block is made independently of the nl-core | + | * The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Metadata is designed as an add-on and is not part of any other BgZ section. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile. |
== Relations between building blocks == | == Relations between building blocks == | ||
<div class="center" style="width:auto; margin-left:auto; margin-right:auto;"> | <div class="center" style="width:auto; margin-left:auto; margin-right:auto;"> | ||
| − | [[Bestand: ChaptersAndRelationsBgZ2 v1.png| | + | [[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]] |
</div> | </div> | ||
<small><b>Figure 1.</b> Relations between building blocks.</small> | <small><b>Figure 1.</b> Relations between building blocks.</small> | ||
| Regel 53: | Regel 55: | ||
Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned. | Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned. | ||
| − | An example of a request that retrieves all Condition resources of a patient with a | + | An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333: |
GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333. | GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333. | ||
| Regel 91: | Regel 93: | ||
When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Typically, the referral to a second specialist medical care setting is completed within hours or days. | When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Typically, the referral to a second specialist medical care setting is completed within hours or days. | ||
| + | |||
| + | |||
| + | The Workflow Task message is optional in the BgZ MSZ exchange. In terms of system support the following rules apply: | ||
| + | |||
| + | # 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. | ||
| + | # 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 Notification Update and Notification Cancellation is out of scope for this version of the Implementation Guide. | ||
=== Exchange without Notified Pull Transaction === | === Exchange without Notified Pull Transaction === | ||
| Regel 303: | Regel 313: | ||
==FHIR Query Specification== | ==FHIR Query Specification== | ||
| − | The table below provides an overview of the FHIR queries to exchange all BgZ- | + | The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections. |
{| class="wikitable" | {| class="wikitable" | ||
| Regel 625: | Regel 635: | ||
|- | |- | ||
|} | |} | ||
| − | <small><b>Table 5.</b> | + | <small><b>Table 5.</b> FHIR queries used to retrieve BgZ MSZ components.</small> |
==FHIR Task.input Query Specification== | ==FHIR Task.input Query Specification== | ||
| Regel 760: | Regel 770: | ||
= Release notes = | = Release notes = | ||
| + | |||
| + | Compared to version 1.0 we made amongst others the following improvements: | ||
| + | * CDA is deprecated | ||
| + | * Metadata section is changed and improved, making use of international FHIR profile Provenance | ||
| + | * Notified Pull is included | ||
| + | * Planned Care Activity Section is improved | ||
| + | * Procedure.Category is included | ||
| + | * Medication zib's are included | ||
Huidige versie van 26 nov 2024 om 15:22
1 Introduction
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: see BgZ main page.
In addition, the guidelines as specified in general FHIR STU3 Implementation Guide apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the use case overarching principles and the use of FHIR packages.
First, this IG describes the boundaries and relationships that exist. Second, it describes the implementation per transaction.
2 Boundaries and relationships
2.1 Boundaries
Please note that this version of the BgZ-MSZ describes the exchange of all BgZ chapters. In future versions of the BgZ it is expected that implementation guides will be modularized and that for subsets of the BgZ references will be made to other information standards such as Medication Process, and Lab.
In future versions the gap to the European patient summary will be addressed.
2.2 Building blocks and FHIR profiles
Data exchange of the BgZ is based on the Dutch zibs 2017 (clinical information models). Table 3 contains an overview of all FHIR building blocks, including custom building blocks.
- The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Metadata is designed as an add-on and is not part of any other BgZ section. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.
2.3 Relations between building blocks
Figure 1. Relations between building blocks.
2.4 Mapping between profiles and dataset
Each FHIR profile maps to the functional definition in ART-DECOR. FHIR profiles contain mappings to all data elements that are present in the functional data set. Either HCIM mappings are used (e.g., NL-CM:17.2.1) or BgZ specific mappings are used with prefix: "bgz2017-dataelement-".
Each transaction must contain a Patient building block. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in .subject or .patient of each FHIR instance of each main building block with the exception of MetaData, Patient, HealthProvider.
FHIR instances, exchanged as part of a transaction, will contain references to other instances. For example a procedure may reference a problem list item. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.
2.5 Patient identification
This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification. Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.
An example of a request that retrieves all Condition resources of a patient with a fictional BSN of 111222333: GET [base]/Condition?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn%7C111222333.
Table 5.1 defines the FHIR queries for all BgZ chapters. These queries apply for both use cases: "Exchange BgZ for Referral" and "Retrieval of BgZ from previous practitioner". All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.
3 Transactions
3.1 Exchange BgZ for Referral
| Person | System | ||
|---|---|---|---|
| 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 |
Table 1. Actors in the BgZ exchange for referral.
FHIR instances for the BgZ summary are made available at the sending system using the profiles (table 3), the definition of the ART-DÉCOR publication (see functional specification), and the FHIR query specification (table 5). The FHIR instances will remain available unchanged for as long as the task period is valid.
3.1.1 Exchange Using Notified Pull Transaction
The BgZ-MSZ Notification task profile (table 5) is used by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ section is defined in Table 6. The type.coding for these sections is defined in table 7.
When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Typically, the referral to a second specialist medical care setting is completed within hours or days.
The Workflow Task message is optional in the BgZ MSZ exchange. In terms of system support the following rules apply:
- 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.
- 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 Notification Update and Notification Cancellation is out of scope for this version of the Implementation Guide.
3.1.2 Exchange without Notified Pull Transaction
The sending system pushes a FHIR document with the BgZ to a receiving system. To construct a document, a FHIR Composition resource is created that summarizes and references all the resources that need to be exchanged. This Composition resource is then placed together with all referenced resources in a Bundle with Bundle.type set to "document". The Composition resource SHALL be the first entry.
The Push use case can be used by systems transitioning from HL7 CDA to HL7 FHIR where the CDA based BgZ is replaced by a FHIR Composition.
3.2 Retrieval of BgZ from previous practitioner
| Person | System | ||
|---|---|---|---|
| Name | Description | Name | Description |
| Requesting Medical Specialist | Medical specialist who queries for a BgZ | EHR | Electronic health record |
Table 2. Actors in the retrieval of the BgZ from a previous practitioner.
In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ from the previous care institution. The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message and the search/ read queries defined in table 5.
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).
4 Materials
4.1 FHIR Profiles
Table 3. FHIR Profiles used to exchange BgZ MSZ sections. The reader should take note of the 'Relating FHIR profiles with their functional definitions' in the FHIR STU3 Implementation Guide.
| Resource | Profile |
|---|---|
| Task | http://nictiz.nl/fhir/StructureDefinition/BgZ-NotificationTask |
| Task | http://nictiz.nl/fhir/StructureDefinition/BgZ-WorkflowTask |
Table 4. BgZ-MSZ Notification task profile required by the sending system to invite the receiving system to perform one or more Pull interactions (FHIR requests). The task contains the FHIR-read and FHIR-search interactions that can be performed to retrieve the data that has been made available at the sending system. The valueReference or valueString for a BgZ section is defined in Table 5. The type.coding for these sections is defined in table 6.When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral itself. Typically, the referral to a second specialized care setting is completed within hours or days (top row). BgZ-MSZ Workflow task profile used to create the Task instance on the sending system if the NP is part of a managed workflow (bottom row).
4.2 FHIR Query Specification
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 6 Complaints and diagnoses | |
| 6.1 Problem | |
GET [base]/Condition |
All problems available in the source system are returned as zib-Problem instances.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
"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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
|
| 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.
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.
|
| 18.2 Healthcare provider | |
see Procedure.performer see Encounter.serviceProvider |
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. |
Table 5. FHIR queries used to retrieve BgZ MSZ components.
4.3 FHIR Task.input Query Specification
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections. The coding column defines codedConcepts that identify the BgZ MSZ section (HCIM) to retrieve. 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.
| Chapter | Section | FHIR Task type.coding |
|---|---|---|
| 1 Demographics and identification | 1.1 Patient | http://loinc.org/79191-3 |
| 1.2 Marital status | Data are exchanged as part of the patient. | |
| 2 Financial information | 2.1 Payer | http://loinc.org/48768-6 |
| 3 Treatment restrictions | 3.1 Treatment instructions | http://snomed.info/sct/11291000146105 |
| 3.2 Advance directive | http://snomed.info/sct/11341000146107 | |
| 4 Contact persons | 4.1 Contact | Data are exchanged as part of the patient. |
| 5 Functional/mental status | 5.1 Functional or mental status | http://loinc.org/47420-5 |
| 6 Complaints and diagnoses | 6.1 Problem | http://loinc.org/11450-4 |
| 7 Social history | 7.1 Living Situation | http://snomed.info/sct/365508006 |
| 7.2 Drug Use | http://snomed.info/sct/228366006 | |
| 7.3 Alcohol Use | http://snomed.info/sct/228273003 | |
| 7.4 Tobacco Use | http://snomed.info/sct/365980008 | |
| 7.5 Nutrition Advice | http://snomed.info/sct/11816003 | |
| 8 Alerts | 8.1 Alert | http://loinc.org/75310-3 |
| 9 Allergies | 9.1 Allergy Intolerance | http://loinc.org/48765-2 |
| 10 Medication | 10.1 Medication Agreement | http://snomed.info/sct/422979000 |
| 10.2 Administration Agreement | http://snomed.info/sct/422037009 | |
| 10.3 Medication Use | http://snomed.info/sct/16076005 | |
| 11 Medical devices | 11.1 Medical device | http://loinc.org/46264-8 |
| 12 Vaccinations | 12.1 Vaccination | http://loinc.org/11369-6 |
| 13 vital signs and measurements | 13.1 Blood pressure | http://loinc.org/85354-9 |
| 13.2 Body weight | http://loinc.org/29463-7 | |
| 13.3 Body height | http://loinc.org/8302-2 | |
| 14 Results | 14.1 Laboratory test result | http://snomed.info/sct/15220000 |
| 15 Procedures | 15.1 Procedure | http://loinc.org/47519-4 |
| 16 Encounters | 16.1 Encounter | http://loinc.org/46240-8 |
| 17 Planned care activity | 17.1 Procedure | http://loinc.org/18776-5 |
| 18 Care Setting | 18.1 Health professional | http://snomed.info/sct/229774002 |
| 18.2 Healthcare provider | Data are exchanges as part of other BgZ components. | |
| 19 Meta data | 19.1 Meta data | http://snomed.info/sct/257733005 |
Table 6. FHIR Task.input Query Specification.
4.4 Glossary
| Term | Description |
|---|---|
| HCIM | Health and Care Information models (HCIM) or Zorginformatiebouwstenen (ZIB's) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process. |
Table 7. Glossary.
5 Release notes
Compared to version 1.0 we made amongst others the following improvements:
- CDA is deprecated
- Metadata section is changed and improved, making use of international FHIR profile Provenance
- Notified Pull is included
- Planned Care Activity Section is improved
- Procedure.Category is included
- Medication zib's are included
