informatiestandaarden - Gebruikersbijdragen [nl]

bgz:V2.0-beta.3 Technical IG BgZ MSZ

2025-12-04T12:22:02Z

Gabriel Hopmans:

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0-beta.3}}
__TOC__

=Introduction=

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

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

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

== Known issues ==
This version of the information standard has known issues. Please find them in the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Known_issues | functional design page]].

= Boundaries and relationships =

== Boundaries ==

Please note that this version of the BgZ-MSZ describes the exchange of all BgZ chapters. This version does not use the MBH identifier from medication process, however systems are encouraged to use the <code>.identifier</code> as stated in the [[FHIR:V1.0_FHIR_IG_STU3#When_is_.identifier_expected.3F|general FHIR STU3 Implementation Guide]].

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 ==

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. Please note that every FHIR profile makes use of mappings towards the baseclass HCIM BasicElements, this is relevant since some parts within a FHIR profile are not mapped in the associated HCIM profile (e.g. effectiveDateTime in livingSituation). The HCIM BasicElements are used primarily for lastn queries that depend on the effectiveDateTime element.

* The Metadata building block is made independently of the nl-core profiles. Metadata contains data that relates to the registration process rather than the medical content. Exchange of metadata for the BgZ-MSZ is designed via a query add-on: BgZ-MSZ sections can be queried with or without metadata. When data with a specific section are exchanged, there may be metadata about the registration process that refer to instances within such a section. In the future, when more information standards will use the Provenance resource to exchange registration data, it is planned to create an nl-core-MetaData profile that will replace the current bgz-MetaData profile.

== Relations between building blocks ==

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand: ChaptersAndRelationsBgZ2 v1.png|800px]]
</div>
<small><b>Figure 1.</b> Relations between building blocks.</small>

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

== 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|111222333.

Table 4 defines the FHIR queries for all BgZ chapters. These queries apply for both use cases: "Exchange BgZ for Referral" and "Retrieval of BgZ from previous practitioner".
All search parameters used in this table SHALL be supported for processing by servers and MAY be supported by clients.

= Transactions =

== Exchange BgZ for Referral ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Referring (Sending) Medical Specialist
| Medical specialist who sends a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-client-bgz2017.json CapabilityStatement: Client]
| FHIR Client requirements
|-
| Receiving Medical Specialist
| Medical specialist receives a BgZ along with a referral
| EHR
| Electronic health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/package/capabilitystatement-server-bgz2017.json CapabilityStatement: Server]
| FHIR Server requirements
|}
<small><b>Table 1.</b> Actors in the BgZ exchange for referral.</small>

FHIR instances for the BgZ summary are made available at the sending system using the profiles (table 3), the definition of the ART-DÉCOR publication (see functional specification), and the FHIR query specification (table 4). The FHIR instances will remain available unchanged for as long as the task period is valid.

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

When generating the notification message the restriction.period, during which the data will be available, is set by the sending system. This period is identical to the duration of the referral. Working agreements describe how long queries are valid.

=== Exchange without Notified Pull Transaction ===

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.

== Retrieval of BgZ from previous practitioner ==

{| class="wikitable"
! colspan="2" style="text-align:left;" | Person
! colspan="2" style="text-align:left;" | System
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Requesting Medical Specialist
| Medical specialist who queries for a BgZ
| EHR
| Electronic health record
|}
<small><b>Table 2.</b> Actors in the retrieval of the BgZ from a previous practitioner.</small>

In the "Retrieval of BgZ from previous practitioner" use case, the current healthcare provider (Requesting Medical Specialist) takes the initiative to retrieve the BgZ from the previous care institution.
The Requesting Medical Specialist can retrieve the BgZ (at a suitable time) using the Pull Message and the search/ read queries defined in table 4.

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

= Materials =
{{NoteBox|BgZ-MSZ uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2 nictiz.fhir.nl.stu3.bgz, version 2.0.3-beta.2]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}
==FHIR Profiles ==

{| class="wikitable" style="horizontal-align: right"
!style="text-align:left; background-color: #E3E3E3 width:10px" | Chapter
!style="text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="text-align:left; background-color: #E3E3E3 width:100px" | Resource
!style="text-align:left; background-color: #E3E3E3 width:400px" | Profile
|-
| rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| rowspan="3" | 2
| Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.InsuranceCompany
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Payer.PayerPerson
| Patient
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 3
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 4
| ContactPerson
| Patient.contact
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 5
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 6
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Problem|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 7
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 8
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 9
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="5" | 10
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicationUse2
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| PharmaceuticalProduct
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| InstructionsForUse
| Dosage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 11
| MedicalDevice
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| MedicalDevice.Product
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="2" | 12
| Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Vaccination.PreferedDateForRevaccination
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="3" | 13
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 14
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 15
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| 16
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| 17
| PlannedCareActivity.Procedure
| ProcedureRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| rowspan="4" | 18
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.Specialty
| PractitionerRole
| | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| HealthProfessional.HealthProfessionalRole
| 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}}}}
|-
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|
| Metadata
| 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><b>Table 3.</b> FHIR Profiles used to exchange BgZ MSZ sections. The reader should take note of the [https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_IG_STU3#Relating_FHIR_profiles_with_their_functional_definitions 'Relating FHIR profiles with their functional definitions'] in the FHIR STU3 Implementation Guide.</small>

=== Future changes in FHIR BgZ related profiles ===
Certain BgZ related FHIR profiles are derived from zib and nl-core profiles. In future versions of the standard, BgZ profiles will possibly be replaced by their predaopt zib2020 counterparts.

==FHIR Query Specification==
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
All living situations available in the source system are exchanged as FHIR Observation instances that conform to the zib-LivingSituation profile.
* The Observation.code is fixed to ‘Residence and accommodation circumstances - finding’ (code = ' 365508006' in codeSystem 'SNOMED CT').
* The HouseType cardinality is 1..1R and must be exchanged accordingly.
|-
! colspan="2" style="text-align: left;" | 7.2 Drug Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
All drug use available in the source system is exchanged as a FHIR Observation instances that conform to the zib-DrugUse profile.
* The Observation.code is fixed to ‘Finding relating to drug misuse behavior’ (code = '228366006' in codeSystem 'SNOMED CT').
* The target system may be configured to optimize the use of this information. For example, grouping data according to a specific DrugOrMedicationType.
|-
! 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.code is fixed to ‘Finding relating to alcohol drinking behavior’ (code = '228273003' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
All known Tobacco Use, available in the source system, is exchanged as FHIR Observation instances that conform to the zib-TobaccoUse profile.
* The Observation.code is fixed to ‘Finding of tobacco use and exposure’ (code = ' 365980008' in codeSystem 'SNOMED CT').
|-
! colspan="2" style="text-align: left;" | 7.5 Nutrition Advice
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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 procedures are exchanged via an instance with the Procedure.category fixed to ‘Surgical procedure’ (code = ‘387713003’ in CodeSystem ‘SNOMED CT’).
* Image-guided procedures are exchanged via an instance where the procedure category is fixed to ‘Imaging guidance’ (code = ‘258174001’ in CodeSystem ‘SNOMED CT’).
Procedure instances with any other category than the two specified above are not exchanged. The default category for the BgZ MSZ is ‘procedure’ (code = ‘71388002’ in CodeSystem ‘SNOMED CT’).
|-
! 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
see Encounter.serviceProvider
</pre>
|
Providers are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Healthcare Providers.
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>

{| class="wikitable"
! colspan="3" style="text-align: left;" | Meta data
|-
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
! scope="col" style="text-align: left;" | Example
|-
| <pre>GET [base]/[FHIR resource]?_revinclude=Provenance:target</pre>
| When metadata may be required, provenance data available in the source system for a specific BgZ summary should be exchanged according to the BgZ-metadata profile as FHIR Provenance instances.
| 14.1 Laboratory test result incl. meta data
<pre>GET [base]/Observation/$lastn?_revinclude=Provenance:target&category=http://snomed.info/sct|49581000146104&_include=Observation:related-target</pre>
|-
|}
<small><b>Table 5.</b> The FHIR query and explanation to retrieve metadata.</small>

==Notified Pull Query Specification==
The following table provides the overview of codings needed to retrieve all the BgZ MSZ sections.
The coding column defines codedConcepts that identify the BgZ MSZ section (HCIM) to retrieve.

{| class="wikitable" width="100%" style="horizontal-align: right"
! style="text-align:left; background-color: #E3E3E3 width:200px" | Chapter
! style="text-align:left; background-color: #E3E3E3 width:200px" | Section
! style="text-align:left; background-color: #E3E3E3 width:200px" | Notified Pull coding
|-
| rowspan="2" | 1 Demographics and identification
| 1.1 Patient
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/79191-3</span>
|-
| 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>
|-
| rowspan="2" | 3 Treatment restrictions
| 3.1 Treatment instructions
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/11291000146105</span>
|-
| 3.2 Advance directive
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/11341000146107</span>
|-
| 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>
|-
| 6 Complaints and diagnoses
| 6.1 Problem
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/11450-4</span>
|-
| rowspan="5" | 7 Social history
| 7.1 Living Situation
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/365508006</span>
|-
| 7.2 Drug Use
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/228366006</span>
|-
| 7.3 Alcohol Use
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/228273003</span>
|-
| 7.4 Tobacco Use
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/365980008</span>
|-
| 7.5 Nutrition Advice
| <span STYLE="font-family:'Courier New'; font-weight:700">http://snomed.info/sct/11816003</span>
|-
| 8 Alerts
| 8.1 Alert
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/75310-3</span>
|-
| 9 Allergies
| 9.1 Allergy Intolerance
| <span STYLE="font-family:'Courier New'; font-weight:700">http://loinc.org/48765-2</span>
|-
| rowspan="3" | 10 Medication
| 10.1 Medication Agreement
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/422979000</span>
|-
| 10.2 Administration Agreement
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/422037009</span>
|-
| 10.3 Medication Use
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/16076005</span>
|-
| 11 Medical devices
| 11.1 Medical device
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/46264-8</span>
|-
| 12 Vaccinations
| 12.1 Vaccination
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/11369-6</span>
|-
| 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>
|-
| 13.2 Body weight
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/29463-7</span>
|-
| 13.3 Body height
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/8302-2</span>
|-
| 14 Results
| 14.1 Laboratory test result
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/15220000</span>
|-
| 15 Procedures
| 15.1 Procedure
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/47519-4</span>
|-
| 16 Encounters
| 16.1 Encounter
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/46240-8</span>
|-
| 17 Planned care activity
| 17.1 Procedure
| <span STYLE="font-family:'Courier'; font-weight:700">http://loinc.org/18776-5</span>
|-
| rowspan="2" | 18 Care Setting
| 18.1 Health professional
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/229774002</span>
|-
| 18.2 Healthcare provider
| <span STYLE="font-family:'Courier'; font-weight:700">Data are exchanges as part of other BgZ components.</span>
|-
| Meta data
| Meta data
| <span STYLE="font-family:'Courier'; font-weight:700">http://snomed.info/sct/257733005</span>
|-
|}
<small><b>Table 6.</b> FHIR Task.input Query Specification.</small>

==Glossary==
{| class="wikitable"
|-
! Term !! Description
|-
| 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.
|-
|}
<small><b>Table 7.</b> Glossary.</small>

= Release notes =
Please find the release notes on the [[Bgz:V2.0-beta.3_Ontwerp_BgZ_MSZ#Release_notes | functional design page]].

{{MedMij:Sjabloon_Support}}

bgz:V2.0-beta.3 Kwalificatiescript BgZ MSZ

2025-12-03T09:43:11Z

Gabriel Hopmans: 2.6 Herkwalificatiebeleid toegevoegd

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-12-03T09:27:23Z

Gabriel Hopmans: MSZ-297 Verduidelijking betreft metagevens in kwalificaties

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare administratiegegevens van de huisarts worden uitgewisseld. Concreet kunnen deze gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.
Dit is gewenst gedrag, maar hier wordt niet op getoetst c.q. kwalificaties voor.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
|[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
| BgZ-MSZ package FHIR-profiel mappings
||
#Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem.
|| [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode. Helderheid scheppen uit te wisselen Interpretatievlag code.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|[https://nictiz.atlassian.net/browse/MSZ-175 MSZ-175]
|-
| Medische termen ||
# Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.
||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem ||
#{{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />
||
|-
| Test- en kwalificatiemateriaal ||
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Zorgsetting/Careteam ||
# In de FHIR testberichten ontbreekt de Zorgverlenersrol, zoals hoofdbehandelaar. Het zou te vinden moeten zijn in CareTeam.participant.role.coding:healthProfessionalRole.
|| [https://nictiz.atlassian.net/browse/MSZ-341 MSZ-341]
|-
| Vaccinatie ||
# In de FHIR testberichten is meer informatie te vinden dan in de functionele testpatienten.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

[https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Release Candidate 0.1==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-237 MSZ-237: Verzoek wijziging documentatie mbt Touchstone - ConformanceLab]

[https://nictiz.atlassian.net/browse/MSZ-251 MSZ-251: Queries o.b.v. met een fixed value category voor de resultaten lijkt tegenstrijdig]

[https://nictiz.atlassian.net/browse/MSZ-254 MSZ-254: "Huisartsgegevens" is ambigu]

[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269: "Burgerlijke staat niet in voorbeeldberichten"]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-338 MSZ-338: "Bevinding Testmateriaal Testpatient C Health professional" heeft geleidt tot aanscherping FO functionele eis aanpassing op zorgsetting.zorgverlener.]

[https://nictiz.atlassian.net/browse/MSZ-182 MSZ-338: "Verrichting.categorie in msz dataset en kwalificatie/testmaterialen opnemen"]

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-12-03T09:17:21Z

Gabriel Hopmans: /* 2.0 Beta.3 release */ hernoemen naar RC.01

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare administratiegegevens van de huisarts worden uitgewisseld. Concreet kunnen deze gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
|[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
| BgZ-MSZ package FHIR-profiel mappings
||
#Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem.
|| [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode. Helderheid scheppen uit te wisselen Interpretatievlag code.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|[https://nictiz.atlassian.net/browse/MSZ-175 MSZ-175]
|-
| Medische termen ||
# Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.
||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem ||
#{{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />
||
|-
| Test- en kwalificatiemateriaal ||
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Zorgsetting/Careteam ||
# In de FHIR testberichten ontbreekt de Zorgverlenersrol, zoals hoofdbehandelaar. Het zou te vinden moeten zijn in CareTeam.participant.role.coding:healthProfessionalRole.
|| [https://nictiz.atlassian.net/browse/MSZ-341 MSZ-341]
|-
| Vaccinatie ||
# In de FHIR testberichten is meer informatie te vinden dan in de functionele testpatienten.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

[https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Release Candidate 0.1==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-237 MSZ-237: Verzoek wijziging documentatie mbt Touchstone - ConformanceLab]

[https://nictiz.atlassian.net/browse/MSZ-251 MSZ-251: Queries o.b.v. met een fixed value category voor de resultaten lijkt tegenstrijdig]

[https://nictiz.atlassian.net/browse/MSZ-254 MSZ-254: "Huisartsgegevens" is ambigu]

[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269: "Burgerlijke staat niet in voorbeeldberichten"]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-338 MSZ-338: "Bevinding Testmateriaal Testpatient C Health professional" heeft geleidt tot aanscherping FO functionele eis aanpassing op zorgsetting.zorgverlener.]

[https://nictiz.atlassian.net/browse/MSZ-182 MSZ-338: "Verrichting.categorie in msz dataset en kwalificatie/testmaterialen opnemen"]

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-12-02T08:36:53Z

Gabriel Hopmans: /* 2.0 Beta.1 release */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare administratiegegevens van de huisarts worden uitgewisseld. Concreet kunnen deze gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
|[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
| BgZ-MSZ package FHIR-profiel mappings
||
#Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem.
|| [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode. Helderheid scheppen uit te wisselen Interpretatievlag code.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|[https://nictiz.atlassian.net/browse/MSZ-175 MSZ-175]
|-
| Medische termen ||
# Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.
||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem ||
#{{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />
||
|-
| Test- en kwalificatiemateriaal ||
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Zorgsetting/Careteam ||
# In de FHIR testberichten ontbreekt de Zorgverlenersrol, zoals hoofdbehandelaar. Het zou te vinden moeten zijn in CareTeam.participant.role.coding:healthProfessionalRole.
|| [https://nictiz.atlassian.net/browse/MSZ-341 MSZ-341]
|-
| Vaccinatie ||
# In de FHIR testberichten is meer informatie te vinden dan in de functionele testpatienten.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

[https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-237 MSZ-237: Verzoek wijziging documentatie mbt Touchstone - ConformanceLab]

[https://nictiz.atlassian.net/browse/MSZ-251 MSZ-251: Queries o.b.v. met een fixed value category voor de resultaten lijkt tegenstrijdig]

[https://nictiz.atlassian.net/browse/MSZ-254 MSZ-254: "Huisartsgegevens" is ambigu]

[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269: "Burgerlijke staat niet in voorbeeldberichten"]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-338 MSZ-338: "Bevinding Testmateriaal Testpatient C Health professional" heeft geleidt tot aanscherping FO functionele eis aanpassing op zorgsetting.zorgverlener.]

[https://nictiz.atlassian.net/browse/MSZ-182 MSZ-338: "Verrichting.categorie in msz dataset en kwalificatie/testmaterialen opnemen"]

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-11-03T15:11:23Z

Gabriel Hopmans: /* 2.0 Beta.3 release */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare administratiegegevens van de huisarts worden uitgewisseld. Concreet kunnen deze gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
|[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
| BgZ-MSZ package FHIR-profiel mappings
||
#Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem.
|| [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode. Helderheid scheppen uit te wisselen Interpretatievlag code.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|[https://nictiz.atlassian.net/browse/MSZ-175 MSZ-175]
|-
| Medische termen ||
# Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.
||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem ||
#{{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />
||
|-
| Test- en kwalificatiemateriaal ||
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Zorgsetting/Careteam ||
# In de FHIR testberichten ontbreekt de Zorgverlenersrol, zoals hoofdbehandelaar. Het zou te vinden moeten zijn in CareTeam.participant.role.coding:healthProfessionalRole.
|| [https://nictiz.atlassian.net/browse/MSZ-341 MSZ-341]
|-
| Vaccinatie ||
# In de FHIR testberichten is meer informatie te vinden dan in de functionele testpatienten.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-237 MSZ-237: Verzoek wijziging documentatie mbt Touchstone - ConformanceLab]

[https://nictiz.atlassian.net/browse/MSZ-251 MSZ-251: Queries o.b.v. met een fixed value category voor de resultaten lijkt tegenstrijdig]

[https://nictiz.atlassian.net/browse/MSZ-254 MSZ-254: "Huisartsgegevens" is ambigu]

[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269: "Burgerlijke staat niet in voorbeeldberichten"]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-338 MSZ-338: "Bevinding Testmateriaal Testpatient C Health professional" heeft geleidt tot aanscherping FO functionele eis aanpassing op zorgsetting.zorgverlener.]

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-11-03T15:10:22Z

Gabriel Hopmans: /* 2.0 Beta.3 release */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare administratiegegevens van de huisarts worden uitgewisseld. Concreet kunnen deze gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
|[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
| BgZ-MSZ package FHIR-profiel mappings
||
#Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem.
|| [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode. Helderheid scheppen uit te wisselen Interpretatievlag code.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|[https://nictiz.atlassian.net/browse/MSZ-175 MSZ-175]
|-
| Medische termen ||
# Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.
||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem ||
#{{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />
||
|-
| Test- en kwalificatiemateriaal ||
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Zorgsetting/Careteam ||
# In de FHIR testberichten ontbreekt de Zorgverlenersrol, zoals hoofdbehandelaar. Het zou te vinden moeten zijn in CareTeam.participant.role.coding:healthProfessionalRole.
|| [https://nictiz.atlassian.net/browse/MSZ-341 MSZ-341]
|-
| Vaccinatie ||
# In de FHIR testberichten is meer informatie te vinden dan in de functionele testpatienten.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-237 MSZ-237: Verzoek wijziging documentatie mbt Touchstone - ConformanceLab}

[https://nictiz.atlassian.net/browse/MSZ-251 MSZ-251: Queries o.b.v. met een fixed value category voor de resultaten lijkt tegenstrijdig]

[https://nictiz.atlassian.net/browse/MSZ-254 MSZ-254: "Huisartsgegevens" is ambigu]

[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269: "Burgerlijke staat niet in voorbeeldberichten"]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-338 MSZ-338: "Bevinding Testmateriaal Testpatient C Health professional" heeft geleidt tot aanscherping FO functionele eis aanpassing op zorgsetting.zorgverlener.]

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-11-03T15:01:14Z

Gabriel Hopmans: /* 2.0 Beta.3 release */ MSZ-237 toegevoegd

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare administratiegegevens van de huisarts worden uitgewisseld. Concreet kunnen deze gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
|[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
| BgZ-MSZ package FHIR-profiel mappings
||
#Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem.
|| [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode. Helderheid scheppen uit te wisselen Interpretatievlag code.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|[https://nictiz.atlassian.net/browse/MSZ-175 MSZ-175]
|-
| Medische termen ||
# Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.
||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem ||
#{{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />
||
|-
| Test- en kwalificatiemateriaal ||
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Zorgsetting/Careteam ||
# In de FHIR testberichten ontbreekt de Zorgverlenersrol, zoals hoofdbehandelaar. Het zou te vinden moeten zijn in CareTeam.participant.role.coding:healthProfessionalRole.
|| [https://nictiz.atlassian.net/browse/MSZ-341 MSZ-341]
|-
| Vaccinatie ||
# In de FHIR testberichten is meer informatie te vinden dan in de functionele testpatienten.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-237 MSZ-237: Verzoek wijziging documentatie mbt Touchstone - ConformanceLab

[https://nictiz.atlassian.net/browse/MSZ-251 MSZ-251: Queries o.b.v. met een fixed value category voor de resultaten lijkt tegenstrijdig]

[https://nictiz.atlassian.net/browse/MSZ-254 MSZ-254: "Huisartsgegevens" is ambigu]

[https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269: "Burgerlijke staat niet in voorbeeldberichten"]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-338 MSZ-338: "Bevinding Testmateriaal Testpatient C Health professional" heeft geleidt tot aanscherping FO functionele eis aanpassing op zorgsetting.zorgverlener.]

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-28T15:59:14Z

Gabriel Hopmans: /* 2.0 Beta.3 release */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| BgZ-MSZ package FHIR-profiel mappings || Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-65 MSZ-65 : AllergieIntolerantie WijzeVanBlootstelling code corrigeren]

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-28T15:39:40Z

Gabriel Hopmans: /* 2.0 Beta.3 release */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| BgZ-MSZ package FHIR-profiel mappings || Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-271 MSZ-271: Adressoort bij patient C leeg maken.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-28T12:52:01Z

Gabriel Hopmans: /* 2.0 Beta.3 release */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| BgZ-MSZ package FHIR-profiel mappings || Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-195 MSZ-195: Dubbele toelichting bij lichaamsgewicht patient D.]

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-28T12:30:46Z

Gabriel Hopmans: /* Algemeen */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het Quality Assurance Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| BgZ-MSZ package FHIR-profiel mappings || Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-28T12:29:56Z

Gabriel Hopmans: /* Algemeen */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het volgende QA Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"]</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| BgZ-MSZ package FHIR-profiel mappings || Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-28T12:28:16Z

Gabriel Hopmans: /* Algemeen */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek. Binnen Nictiz wordt het volgende QA Proces <ref name="QA proces">[https://informatiestandaarden.nictiz.nl/wiki/qa:Hoofdproces "QA proces"</ref> gevolgd

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i> in het element ProbleemNaamSpecifiek. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20251022T104225/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# AllergyIntolerance test heeft een Terminologie error op {{fhir|orale route}} doordat de code en de display omgekeerd zijn ingevuld.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| BgZ-MSZ package FHIR-profiel mappings || Enkele FHIR mappings van de BgZ-MSZ package profielen verwijzen naar de NL-core profielen i.p.v. verwijzingen binnen BgZ-MSZ package. Bijvoorbeeld, het BgZ-Procedure-profiel verwijst naar zib-Problem in plaats van naar BgZ-Problem. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
# In FHIR-mapping ontbreekt de InterpretatieMethode.
# Onvoldoende uitgelegd hoe het verschil te identificeren is tussen LabUitslagen en LabTesten in HCIM LaboratoryTestResult Observation.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patiënt in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activiteit en Zorgteam.
# De testdata van patiënten C en D bevatten T-data zonder tijdspecificatie voor metadata, waardoor de FHIR instanties niet voldoen aan FHIR datatype {{fhir|instant}}, wat een precisie van seconden nodig heeft.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patiënt B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
# De testdata van patiënten A en B bevatten T-data zonder tijdspecificatie voor ToedieningsAfspraak, waardoor ToedieningsAfspraak.toedientijd niet goed wordt ingevuld.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
|-
| Specialisme/PractitionerRole ||
#PractitionerRole test mist in FHIR-testscripts.
||
|-
| Verrichting ||
# FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.
# ProcedureRequest kan in FHIR STU3 niet meer dan 1 performer (Verrichting.uitvoerder) aan.
# ProcedureRequest werkt niet doordat de status niet wordt verwerkt in de zib.
# Vanuit de ZIBS is {{fhir|Verrichting.VerrichtingMethode 0..*}} niet haalbaar in [https://simplifier.net/packages/nictiz.fhir.nl.stu3.bgz/2.0.3-beta.2/files/2828058 FHIR STU3 profielen]. Het element {{fhir|HCIM ProcedureMethod}} in het FHIR-profiel {{fhir|HCIM Procedure}} is beperkt tot {{fhir|0..1}}. Wij raden daarom aan om de belangrijkste methode op te sturen.
|| [https://nictiz.atlassian.net/browse/MSZ-270 MSZ-270]
|-
| Voedingsadvies ||
# De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.
#Voor STU3 meer richting geven hoe zendende systemen om kunnen gaan met tonen verschillende consistencies in voedingadvies.
|| [https://nictiz.atlassian.net/browse/MSZ-176 MSZ-176]
|}

=Referenties=
<references />

=Release notes=

== 2.0 Alpha ==

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

== 2.0 Beta.1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

== 2.0 Beta.2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-211 MSZ-211: Data absent reason verplicht unknown is onlogisch en onwenselijk]

[https://nictiz.atlassian.net/browse/MSZ-214 MSZ-214: Inconsistentie tussen functioneel en technisch ontwerp rond provenance]

[https://nictiz.atlassian.net/browse/MSZ-216 MSZ-216: Specificatie notified pull tasks lijkt onnodig en is onjuist]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

== 2.0 Beta.3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Patiënt heeft weer kardinaliteit 1..1 i.p.v 0..1.

Verbeterslagen in het testen op ConformanceLab.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

[https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274: Een aantal wijzigingen staan nog beschreven in known issue. Wel opgelost is beschrijving uitgebreid van probleem model over ProbleemNaamSpecifiek.]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-21T07:24:08Z

Gabriel Hopmans: /* Richtlijn en proces */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek.

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case; (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i>. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20250506T091718/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Patient || De Patient is voor een geldige BgZ-MSZ essentieel. Echter, in de huidige versie is de kardinaliteit van patient 0..1 R i.p.v. 1..1 M in verband met beperekende factoren in tooling om testmateriaal te genereren.||
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
# In het TO wordt VerificationStatus verplicht gesteld. Dit concept ontbreekt in het FO.
# De test- en kwalificatie berichten van FHIR voldoen niet aan de ait-1 contraint van de elementen AllergyIntolerance.clinicalStatus en AllergyIntolerance.verificationStatus in het FHIR profiel. Bijvoorbeeld: dat de ClinicalStatus niet aanwezig is wanneer de Verificationstatus niet op “entered-in-error” staat.
# In de narrative van de FHIR-berichten ontbreekt informatie bij de Reactie: Specifieke stof en wijze van blootstelling.
||
|-
|-
| FHIR-profielen || Enkele FHIR mappings naar de dataset ontbreken of zijn incorrect. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag ||
# FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.
# In de FHIR voorbeeldberichten ontbreekt de aanvragende Zorgverlener.
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) ||
# De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.
# Bij de maximale patient in de test- en kwalificatiescripts zijn niet alle metagegevens ingevuld.
# In het functioneel ontwerp ontbreken referenties vanuit metagegevens naar de elementen: Betaler, LaboratoriumUitslag, Geplande zorg activeit en Zorgteam.
||
[https://nictiz.atlassian.net/browse/MSZ-347 MSZ-347]
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
# De narrative van de FHIR-berichten bevatten afwijkende naamgeving met de functionele concepten.
# Patient B bevat bij Geplande zorg activiteit.Anatomischelocatie een SNOMED-code van een verrichtingtype. Bij deze verrichting is de verrichtingtype leeg.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
# -
# -
|-
| Verrichting || FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.||
|-
| Voedingsadvies || De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.||
|}

=Referenties=
<references />

=Release notes=

==Beta 1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

==Beta 2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

==Beta 3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

Allergieintolerantie is nu conform de zib 2017. Hiervoor is passend test- en kwalificatie materiaal voor ontwikkeld. Hiermee is het known issue uit beta.2 verholpen dat allergieintolleratie niet conform zibs is.

[https://nictiz.atlassian.net/browse/MSZ-332 MSZ-332: Burgelijke staat toegevoegd aan de FHIR voorbeeld-berichten.]

[https://nictiz.atlassian.net/browse/MSZ-123 MSZ-123: CapabilityStatement verwijzing opnemen in het TO]

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Testscript BgZ MSZ

2025-10-20T08:31:41Z

Gabriel Hopmans: /* Testomgeving en Kwalificatieproces */

bgz:V2.0-beta.3 Kwalificatiescript BgZ MSZ

2025-10-20T08:29:45Z

Gabriel Hopmans: /* Testomgeving en Kwalificatieproces */ verwijzing naar conformancelab

bgz:V2.0-beta.3 Testscript BgZ MSZ

2025-10-16T14:13:04Z

Gabriel Hopmans: /* Doel en verwacht resultaat */

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-13T13:35:52Z

Gabriel Hopmans: /* Known issues */

{{IssueBox|'''<big>This page is under construction.</big>'''}}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek.

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en (b) Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case, (b); (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i>. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20250506T091718/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
* De elementen Agens(veroorzakendeStof) en Status zijn op het TO verplicht maar op het FO optioneel.
||
|-
|-
| FHIR-profielen || Enkele FHIR mappings naar de dataset ontbreken of zijn incorrect. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag || FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.||
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) || De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.||
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft, bijvoorbeeld "Burgerlijke Staat" mist.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
# -
# -
|-
| Verrichting || FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.||
|-
| Voedingsadvies || De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.||
|}

=Referenties=
<references />

=Release notes=

==Beta 1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

==Beta 2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

==Beta 3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-13T13:31:36Z

Gabriel Hopmans: /* Known issues */

{{IssueBox|'''<big>This page is under construction.</big>'''}}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek.

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en (b) Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case, (b); (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i>. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20250506T091718/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
* De elementen Agens en Status zijn op het FO optioneel, maar op het TO verplicht.
||
|-
|-
| FHIR-profielen || Enkele FHIR mappings naar de dataset ontbreken of zijn incorrect. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag || FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.||
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) || De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.||
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft, bijvoorbeeld "Burgerlijke Staat" mist.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
# -
# -
|-
| Verrichting || FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.||
|-
| Voedingsadvies || De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.||
|}

=Referenties=
<references />

=Release notes=

==Beta 1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

==Beta 2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

==Beta 3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-10-13T13:25:48Z

Gabriel Hopmans: NICTIZ-35054 punten bij AllergieIntolerantie gewijzigd

{{IssueBox|'''<big>This page is under construction.</big>'''}}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek.

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en (b) Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case, (b); (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i>. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20250506T091718/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
* De elementen Agens en Status zijn op het FO optioneel, maar op het TO verplicht.
|| ]
|-
|-
| FHIR-profielen || Enkele FHIR mappings naar de dataset ontbreken of zijn incorrect. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag || FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.||
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) || De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.||
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft, bijvoorbeeld "Burgerlijke Staat" mist.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
# -
# -
|-
| Verrichting || FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.||
|-
| Voedingsadvies || De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.||
|}

=Referenties=
<references />

=Release notes=

==Beta 1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

==Beta 2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

==Beta 3 release==



Zorgteam naamgeving aangepast conform zib2020.

Validatie-stap is beschreven op de nieuwe Validatie pagina.

=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

bgz:V2.0-beta.3 Ontwerp BgZ MSZ

2025-08-11T12:12:59Z

Gabriel Hopmans: /* Release notes */

{{IssueBox|'''<big>This page is under construction.</big>'''}}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


{{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg 2.0.0-beta.3|noreplace}}

Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
__NUMBEREDHEADINGS__
=Inleiding=

==Algemeen==

Dit document beschrijft het Functioneel Ontwerp (FO) voor de Informatiestandaard “BgZ-uitwisseling voor de medisch-specialistische zorg”.
De "Kwaliteitstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend"<ref name="Kwaliteitsstandaard">[https://www.zorginzicht.nl/kwaliteitsinstrumenten/uitwisseling-basisgegevensset-zorg-tussen-instellingen-waar-medisch-specialistische-zorg-wordt-verleend "Kwaliteitsstandaard Uitwisseling Basisgegevensset Zorg tussen instellingen waar medisch-specialistische zorg wordt verleend", versie juli 2024]</ref> beschrijft de afspraken voor de uitwisseling van gegevens bij overdracht van patiënten tussen instellingen die medisch-specialistische zorg (MSZ) verlenen. De “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën”<ref name="Handreiking adequate registratie">[https://amigo.nictiz.nl/handreiking-adequate-registratie “Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) Klachten en diagnoses, behandelaanwijzingen en allergieën” Registratie aan de bron, 24-03-2022, Versie 1.1]</ref>, beschrijft afspraken over welke informatie er minimaal in het zorgproces moet worden geregistreerd. De NEN 7540<ref name="NEN 7540">[https://www.nen.nl/nen-7540-2024-nl-319920 “NEN 7540 BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg.", maart 2024]</ref> stelt eisen voor taal en techniek.

Deze versie van de informatiestandaard is gebaseerd op de zib Publicatie 2017(NL)<ref name="zib Publicatie 2017(NL)">[https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) "publicatieversie 2017 van de zorginformatiebouwstenen", Nictiz, 20-01-2018]</ref> en uitwisseling via HL7 FHIR v3. Tevens zijn in dit FO enkele verduidelijkingen, aanvullingen, en restricties op de inhoudelijke afspraken in de kwaliteitstandaard en handreiking opgenomen.

Het FO beschrijft voor alle uitwisselscenario's, in dit document use cases genoemd, uit de informatiestandaard de transacties, transactiegroepen, systemen, systeemrollen en bedrijfsrollen van zorgverleners of patiënten. Hiervoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 zijn per use case de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [http://nictiz.nl/standaarden/informatiestandaarden/ Nictiz webpagina voor informatiestandaarden]. Voor de verklaring van de begrippen die voorkomen in het FO wordt verwezen naar de [https://nictiz.nl/standaarden/begrippen/ Nictiz webpagina met een begrippenoverzicht].

==Doelgroep==

De doelgroepen van dit FO zijn
* productmanagers, architecten, ontwerpers en testers van ICT-leveranciers, regio-organisaties en Nictiz en
* vertegenwoordigers van zorgverleners.

==Kaders en uitgangspunten==

===Richtlijn en proces===

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:FO_Figuur1_Sturen_Ontvangen.png|700px|Figuur 1]]
</div>

<b>Figuur 1</b>: Gegevensuitwisseling in het MSZ proces. De BgZ-MSZ (t) is een samenvatting van gegevens van een bronsysteem (XIS) (s).

De overdracht van gegevens tussen zorgverleners in de MSZ zijn in twee use cases beschreven: (a) Uitwisseling BgZ bij verwijzing of overdracht, en (b) Opvraging BgZ bij eerdere behandelaar.
In dit proces zijn de bedrijfsrollen van de betrokken partijen :
* Verwijzende zorgverlener bij eerste use case (g); (PUSH)
** Sturende zorgverlener, (h);
** Ontvangende zorgverlener, (j);
* Opvragende zorgverlener bij tweede use case, (b); (PULL) LET OP! Deze use case is momenteel nog niet volledig uitgewerkt omdat het communicatiepatroon nog niet beschikbaar is.
** Raadplegende zorgverlener;
** Beschikbaarstellende zorgverlener;

===Reikwijdte informatiestandaard===

De informatiestandaard specificeert voor de eerste vier lagen van het vijflagenmodel, welke informatie moet worden vastgelegd en gedeeld bij de overdrachtsmomenten in zorgprocessen. Deze laag bestaat uit (1) een functionele specificatie van het zorgproces en (2) een specificatie van de informatie die uitgewisseld wordt via een dataset, gegevensmodel, en terminologie.

==Testen==

Voor deze informatiestandaard zijn testscripts beschikbaar die gebaseerd zijn op fictieve patiëntdossiers. De scripts zijn inhoudelijk afgestemd op realistische zorgsituaties en klinisch gevalideerd door medisch specialisten. Hiermee wordt geborgd dat het beoogde gebruik van de informatiestandaard correct en eenduidig kan worden getoetst. De testscripts ondersteunen leveranciers en zorginstellingen bij het testen en valideren van implementaties. De testscripts zijn beschikbaar via [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ].

==Kwalificatie==

Op basis van dit FO en de daarbij behorende dataset zijn kwalificatiescripts opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/ websitepagina over Nictiz kwalificaties]. De test- en kwalificatiescripts zijn te vinden op
[https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_BgZ#Kwalificatiescript_BgZ_medisch-specialistische_zorg de Landingspagina BgZ]

==Begrippenkader==
{| class="wikitable"
|-
| Zorgverlener || Een natuurlijke persoon die beroepsmatig zorg verleent (Wkkgz artikel 1). In dit FO wordt zorgverlener gebruikt voor het identificeren van de verantwoordelijke rol, waarbij een gedelegeerde ook aangeduid wordt als zorgverlener.
|}

=Use cases=

Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij de uitwisseling van informatie voor een concrete situatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties. Een transactie beschrijft welke informatie wanneer wordt uitgewisseld. Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Elke use case koppelt met een scenario in ART-DECOR.

==Algemeen==

Het doel van de implementatie van deze informatiestandaard is het waarborgen van de continuïteit van de zorg, het voorkomen dat patiënten hun verhaal steeds opnieuw moeten vertellen, het verminderen van de registratielast en het verminderen van fouten.

===Specificatie van uitgewisselde BgZ componenten===

In onderstaande tabel is een specificatie opgenomen van uit te wisselen BgZ-componenten voor EPD naar EPD uitwisselingen in de MSZ.

De structuur van de BgZ-MSZ 2.0 secties is gebaseerd op de "BgZ Specificatie gebaseerd op zibs release 2017" <ref name="BgZ op zibs 2017">[https://nictiz.nl/app/uploads/2022/07/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ Specificatie gebaseerd op zibs release 2017, 19-04-2018, Versie 1.1]</ref>. Deze definitie is aangevuld met componenten relevant voor de BgZ-MSZ, zoals bijvoorbeeld metagegevens, zorgsetting, zorgaanbieders, en zorgverleners.

De specificatie van uit te wisselen gegevens in de MSZ, zoals de kardinaliteiten, conformance, en condities, is op basis van bronnen zoals de kwaliteitstandaard<ref name="Kwaliteitsstandaard" />, de handreiking adequate registratie<ref name="Handreiking adequate registratie" />, en het programma van eisen voor de BgZ-MSZ <ref name="Programma van Eisen">[https://nationalebibliotheek.nictiz.nl/assets/uploads/2024/06/Programma-van-Eisen-BgZ-MSZ-usecase-inzien-hergebruik-22-okt-24.pdf "Programma van Eisen – BgZ-MSZ - usecase inzien & hergebruik", 22 okt 2024]</ref>. Deze specificatie wordt in het technisch ontwerp toegepast in specifieke FHIR queries voor ontvangende en raadplegende partijen. Voor specifiek de sturende en ontvangende partijen wordt de TA-NP toegepast zoals beschreven in het technisch ontwerp. Houd er bij het toepassen van de TA-NP rekening mee dat de FHIR queries zoals beschreven in het TA-NP document alleen als voorbeeld kunnen worden gebruikt. De beschreven voorbeelden zijn niet samengesteld op basis van dit FO.

In toekomstige versies zal de BgZ 2.0 definitie en structuur van secties verder worden aangevuld voor aanvullende use cases in de MSZ, internationale uitwisselingen, en use cases buiten de MSZ. Waar mogelijk zal deze informatiestandaard in de toekomst gaan verwijzen naar andere standaarden.

{| class="wikitable" width="100%" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ 2.0 Hoofdstuk
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Sectie
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Specificatie
|-
| rowspan="2" | 1 Demografie en identificatie
| 1.1 Patiëntgegevens
|
NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt en overlijdensinformatie worden uitgewisseld.
|-
| 1.2 Burgerlijke staat
|
Laatst bekende burgerlijke staat
|-
| 2 Financiële informatie
| 2.1 Verzekeringsgegevens
|
De verzekeringsgegevens van de patiënt
|-
| rowspan="2" | 3 Behandelrestricties
| 3.1 Behandelaanwijzingen
|
Alle beschikbare behandelaanwijzingen worden uitgewisseld.
* Er kunnen meerdere behandelaanwijzingen worden vastgelegd die op hetzelfde moment ingaan.
* Het moet mogelijk zijn behandelaanwijzingen in te zien. Het is niet mogelijk behandelaanwijzingen ongewijzigd over te nemen. Tijdens het inzien van gegevens kan software faciliteren met het groeperen en ordenen op basis van een datum indien beschikbaar.
|-
| 3.2 Wilsverklaring
|
Alle beschikbare wilsverklaringen worden uitgewisseld.
|-
| 4 Contactpersoon
| 4.1 Contactpersoon
|
De gegevens van de eerste relatie/ contactpersoon worden, indien beschikbaar, uitgewisseld.
|-
| 5 Functionele status
| 5.1 Functionele/ mentale status
|
Alle beschikbare functionele en mentale statussen worden uitgewisseld. <ref name=alle functionele en mentale statussen> In de kwaliteitsstandaard worden de laatste statussen benoemd. Normaal wordt dan gewerkt in een query met $lastn operator maar dat is niet mogelijk: Statusdatum is optioneel, Provenance met datum is ook optioneel en dus werkt de $lastn functie niet in alle gevallen goed. Er zullen naar verwachting ook niet heel veel statussen in het dossier te vinden zijn en dus is de beste optie gewoon alle statussen op te vragen.</ref>
* Dit concept is uitgebreid met een categorie. Mogelijke waarden kunnen zijn: functioneel en/of mentaal.
* Software kan faciliteren bij het groeperen naar functies die met SNOMED CT codes zijn vastgelegd.
|-
| 6 Klachten en diagnoses
| 6.1 Problemen (incl. diagnoses)
|
Alle bekende problemen van alle probleemtypen worden uitgewisseld. In deze versie 2.0 van de informatiestandaard worden niet alleen de toegestane coderingen van ‘ProbleemNaam’ uitgewisseld. Het kan voorkomen dat er voor elementen in de probleemlijst geen codering beschikbaar is. Deze worden wel uitgewisseld vanwege patiëntveiligheid. Tevens is de uitwisseling niet beperkt tot één codering voor dezelfde diagnose. Zo kan <i>contacteczeem</i> ook aanvullend getypeerd worden door <i>contacteczeem door dichromaat</i>. Of bijvoorbeeld een <i>enkelfractuur</i> die aanvullend getypeerd wordt door een <i>crurisfractuur</i>, zonder de noodzaak een tweede probleemlijstelement uit te wisselen en te verwerken.
|-
| rowspan="5" | 7 Sociale anamnese <ref name=alle waardes versus laatst bekende> In de kwaliteitsstandaard wordt bij de "Sociale Anamnese" sectie-zibs de laatste bekende waarde benoemd. Normaal wordt dan gewerkt in een query met $lastn operator, maar in de specificatie van deze zibs, zijn de data-velden optioneel of ontbreken en in dat geval werkt de $lastn functie niet in alle gevallen juist.</ref>
| 7.1 Woonsituatie
|
Alle beschikbare woonsituaties worden uitgewisseld.
* Er kunnen meerdere woonsituaties relevant zijn bij het plannen van een ontslag.
* Software kan faciliteren in het ordenen van de woonsituaties indien er tijdstempelinformatie beschikbaar is. In deze versie 2.0 van de informatiestandaard moet een WoningType worden uitgewisseld indien beschikbaar.
|-
| 7.2 Drugsgebruik
|
Al het bekende drugsgebruik wordt uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende drugsgebruik of laatst bekende drugsgebruik per drugs of geneesmiddelsoort is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. In de praktijk zal een eindgebruiker voor bijvoorbeeld methadon of GHB het laatst bekende gebruik willen zien en mogelijk secundair de eerdere doseringen van bijvoorbeeld methadon. Daarnaast is de startdatum van het middelengebruik optioneel en niet geschikt voor het bepalen van het laatst bekende middelengebruik.
|-
| 7.3 Alcoholgebruik
| Al het bekende alcoholgebruik wordt uitgewisseld.
|-
| 7.4 Tabakgebruik
| Al het bekende tabakgebruik wordt uitgewisseld.
|-
| 7.5 Voedingsadviezen
|
Alle bekende voedingsadviezen worden uitgewisseld.
* Een specifieke uitwisseling van het laatst bekende voedingsadvies of laatst bekende voedingsadvies per dieetType is zowel complex als beperkend en voorkomen in versie 2.0 van de BgZ-MSZ. Het kan ook voorkomen dat er alleen een advies over de consistentie van voedsel wordt vastgelegd.
|-
| 8 Waarschuwingen
| 8.1 Alerts
| Alle bekende alerts worden uitgewisseld.
|-
| 9 Allergieën
| 9.1 Allergie-intoleranties
| Alle bekende allergieën worden uitgewisseld.
|-
| rowspan="4" | 10 Medicatie
| Algemeen
|
Alle medicatieafspraken, toedieningsafspraken en medicatiegebruik die bekend zijn in een XIS worden uitgewisseld.

* Deze informatiestandaard bevat uitsluitend de bouwstenen uit de dataset van MP 9.0.7 en is geen volledige implementatie van de standaard Medicatieproces 9 (MP9). Deze informatiestandaard vereist geen implementatie van de informatiestandaard Medicatieproces 9 (MP9) en bevat geen verwijzing naar een specifieke versie van het de informatiestandaard MP9.

* Voor toekomstige versies van deze informatiestandaard is het de verwachting dat wordt verwezen naar de informatiestandaard Medicatieproces 9 (zie voor de actuele versie [https://informatiestandaarden.nictiz.nl/wiki/Landingspagina_Medicatieproces Medicatieproces landingspagina]). Daarnaast is het de verwachting dat in een doorontwikkeling van de BgZ-MSZ informatiestandaard verdere harmonisatie met de EU-Patient Summary (EU-PS) plaatsvindt. In deze ontwikkeling wordt ook rekening gehouden met de bouwstenen van MP9.

* De uitwisseling van medicatiegegevens kan niet gebruikt worden voor een Actueel Medicatie Overzicht (AMO). De gegevens kunnen op verschillende manieren en verschillende momenten zijn ontstaan in een XIS. Denk bijvoorbeeld aan een intakegesprek waarbij gegevens vanuit een papieren AMO zijn ingevoerd. Ook de medicatie die tijdens interventies gebruikt zijn, kunnen in de uitgewisselde gegevens opgenomen worden. Deze gegevens hebben niet altijd de benodigde elementen om een actueel medicatieoverzicht samen te stellen zoals een MBH-id (zie par 1.3.3 in [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling FO MP 9.0.7 ]) en om de relaties tussen medicatiebouwstenen te kunnen leggen. Voor het kunnen opstellen van een AMO is een implementatie van MP9 nodig.
|-
| 10.1 Medicatieafspraken
| Alle bekende medicatieafspraken worden uitgewisseld.
|-
| 10.2 Toedieningsafspraken
| Alle bekende toedieningsafspraken worden uitgewisseld
|-
| 10.3 Medicatiegebruik
| Al het bekende medicatiegebruik wordt uitgewisseld
|-
| 11 Medische hulpmiddelen
| 11.1 Medische hulpmiddelen
| Alle bekende medische hulpmiddelen worden uitgewisseld
|-
| 12 Vaccinaties
| 12.1 Vaccinaties
| Alle bekende vaccinaties worden uitgewisseld
|-
| rowspan="3" | 13 Vitale functies en metingen
| 13.1 Bloeddruk
| De laatst bekende bloeddruk wordt uitgewisseld.
|-
| 13.2 Lichaamsgewicht
| Het laatst bekende lichaamsgewicht wordt uitgewisseld.
|-
| 13.3 Lichaamslengte
| De laatst bekende lichaamslengte wordt uitgewisseld.
|-
| 14 Uitslagen
| 14.1 Laboratoriumuitslagen
|
Indien beschikbaar wordt van elk type onderzoek (panel) de laatst bekende uitslag uitgewisseld binnen het domein van de klinische chemie en medische microbiologie. Per panel worden alle testuitslagen uitgewisseld. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie). Dit is een uitbreiding en nadere specificatie van de definitie zoals in de kwaliteitstandaard<ref name="Kwaliteitsstandaard" /> staat.
* Specifiek worden de laatst bekende gegevens uitgewisseld voor elk type onderzoek of panel (zie zib LaboratoriumUitslag en het veld Onderzoek). Per laatst bekend onderzoek (panel) worden gegevens zoals de toelichting en alle onderliggende bepalingen uitgewisseld. De bepalingen omvatten alle categorieën (zie zib LaboratoriumUitslag en het veld ResultaatType) zoals endocrinologie, microbiologie, hematologie. Er wordt niet op specifieke categorieën gefilterd bij de uitwisseling van gegevens voor de MSZ.
* Op het moment van het samenstellen van de BgZ-MSZ 2.0 informatiestandaard is er in Nederland nog geen consensus over de categorisering van een specifieke bepaling in een categorie zoals bijvoorbeeld hematologie.
* Voor de MSZ worden de laatst bekende bepalingen uitgewisseld onafhankelijk van het resultaattype. Voor zorgverlener naar patiënt toepassingen kunnen specifieke resultaattypen relevant zijn zoals het niet uitwisselen van voorlopige bepalingen.
* Het is ook mogelijk om een losse bepaling uit te wisselen, zonder panel. Dit kan gerealiseerd worden door de code bij onderzoek (NLCM13.1.4) leeg te laten.
|-
| 15 Verrichtingen
| 15.1 Verrichtingen
|
Alle bekende chirurgische verrichtingen of verrichtingen onder geleide van beeldvormende techniek die de patiënt heeft ondergaan, worden uitgewisseld.
* De informatiestandaard beweegt mee met de trend van chirurgische ingrepen naar beeldgeleide interventies. Uitsluitend de 'bekende operatieve verrichtingen' uitwisselen is tegenwoordig te beperkend.
* De BgZ-MSZ 2.0 sluit aan bij de Internationale Patient Summary die ook de beeldgeleide interventies includeert.
* De categorie informatie wordt uitsluitend toegevoegd aan uitgewisselde verrichtingen ten behoeve van filtering, groepering, of visualisatie en hoeft niet zib compliant te worden opgeslagen in een XIS. In de praktijk kan deze categorie volgen uit de organisatie van de lijsten waarin verrichtingen worden beheerd.
* Deze categorie kan niet op basis van de SNOMED terminologie worden afgeleid uit het VerrichtingType via de SNOMED-taxonomie die aan verandering onderhevig is (zie zib verrichting). In een technische uitwerking is het aanbevolen de categorie code toe te passen in een categorie gebaseerde query, zonder aannames te doen over waardelijsten of de SNOMED taxonomie via een code gebaseerde query.
|-
| 16 Contacten
| 16.1 Contacten
|
Alle bekende contacten met zorgverleners worden uitgewisseld.
* Voor de medisch specialistische zorg is het van belang dat de patiëntsamenvatting ten minste de klinische contacten, de SEH, en een overzicht van de poliklinieken waar de patiënt bekend is, bevat. Uitsluitend het uitwisselen van de bekende ziekenhuisopnames (niet poliklinische contacten), is te beperkend.
* Concreet worden alle contacten uitgewisseld. In de technische implementatie vervallen de filters op de contacten zoals in de voorgaande versie van de informatiestandaard. In een technische uitwerking kunnen filters op het 'ContactType' (zie zib contact) toegepast worden in een ontvangend systeem.
* Een ontvangend systeem kan op basis van de BgZ-MSZ-samenvatting naast een overzicht van de poliklinieken waar de patiënt bekend is per polikliniek een lijst van contacten tonen
|-
| rowspan="1" |17 GeplandeZorgActiviteit (Zorgplan) <ref name=GeplandeZorgActiviteit> De https://zibs.nl/wiki/OverdrachtGeplandeZorgActiviteit-v3.1(2017NL) zib wordt in toekomstige publicaties niet meer opgenomen, o.a. omdat het deel met VerpleegkundigeInterventie niet juist is en de zibs MedicatieToediening2, MedischHulpmiddel en Vaccinatie al verder in de BgZ-MSZ staat opgenomen.</ref>
| 17.1 Verrichting
| Alle toekomstig geplande verrichtingen worden uitgewisseld.
|-
| rowspan="3" | 18 Zorgsetting
| 18.1 Huisartsgegevens
|De beschikbare huisartsgegevens worden uitgewisseld. Concreet kunnen de gegevens van meerdere huisartsen als onderdeel van de patiëntgegevens worden uitgewisseld.
|-
| 18.2 Zorgverleners
|
* De beschikbare gegevens van alle zorgverleners met een actuele behandelrelatie worden uitgewisseld.
* In deze informatiestandaard worden ook gegevens uitgewisseld van zorgverlevers waarvan geen status informatie bekend is of een andere statuswaarde bekend is dan inactief.
* Een patiënt kan worden behandeld door meerdere multidisciplinaire zorgteams. Via de informatiestandaard worden de zorgverleners uitgewisseld inclusief de zorgteam-relatie.
|-
| 18.3 Zorgaanbieders
| De beschikbare gegevens van zorgaanbieders die verantwoordelijk zijn voor de careteam samenstelling.
|}
<small><b>Tabel 1</b> Definitie van de BgZ-MSZ samenvatting.</small>

====Metagegevens====
Metagegevens kunnen bij alle bovengenoemde secties gebruikt worden. Alle beschikbare metagegevens over het ontstaan en muteren van gegevens in een dossier worden uitgewisseld.
* Metagegevens faciliteren bij rijkere visualisaties, handmatig ontdubbelen, reconciliëren, en inzicht in wanneer gegevens in een dossier zijn ontstaan en geactualiseerd . Deze gegevens zijn in de BgZ-MSZ 2.0 geen deel van de zibs, maar een op zichzelf staande categorie.
* Concreet, voegt de BgZ-MSZ 2.0 de mogelijkheid toe om informatie over de activiteit uit te wisselen die heeft geresulteerd in het ontstaan of actualiseren van gegevens.
* De uitwisseling van een unieke objectidentificatie per BgZ element voor automatische ontdubbeling is geen onderdeel van deze versie van de BgZ-MSZ en onderdeel van een doorontwikkeling van deze informatiestandaard.
* Bij het vastleggen van informatie in een XIS worden ook metagegevens vastgelegd over het moment van ontstaan van gegevens.
* Bij het geheel of gedeeltelijk overnemen van gegevens tijdens reconciliatie in een XIS worden ten eerste metagegevens vastgelegd over het muteren van bestaande gegevens en ten tweede metagegevens vastgelegd over het ontstaan van nieuwe gegevens.

==Uitwisseling BgZ bij verwijzing of overdracht==

Deze use case komt overeen met use case (a) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige overdracht bij een verwijzing van een sturende MSZ instelling (c) naar een ontvangende MSZ instelling (d).

Een voorbeeld van het uitwisselen van gegevens bij een verwijzing
# Een patiënt is onder behandeling van een cardioloog in een regionaal ziekenhuis.
# Een vernauwing in een kransslagader is vastgesteld in het regionaal ziekenhuis.
# Vanuit het regionale ziekenhuis wordt aan een topklinisch ziekenhuis voorgelegd of de patiënt in aanmerking komt voor een stent.
# Een zorgmedewerker in het topklinische ziekenhuis bestudeert de gegevens van de patiënt inclusief de BgZ om te beoordelen of het plaatsen van een stent de juiste therapie is voor deze patiënt.
# Er wordt een afspraak gemaakt en de patiënt wordt tijdelijk opgenomen in het topklinische ziekenhuis voor het plaatsen van een stent.

===Proces en context===

====Proces====

Voor het uitwisselen van de BgZ bij verwijzing van een verwijzende zorgverlener (g) zijn de volgende stappen relevant:

# Een sturende zorgverlener (h) in een sturende msz instelling kan de BgZ zo snel als vereist is voor de continuïteit van zorg na de verwijzing van de patiënt naar de ontvangende instelling sturen. Dit is binnen 24 uur (hoofdstuk 3).
# De ontvangende zorgverlener (j) in een ontvangende msz instelling (d) kan de BgZ die is samengesteld en gestuurd ten tijde van de verwijzing overnemen in het eigen XIS (v) zolang er een behandelrelatie is.

===Bedrijfsrollen en UML activity diagram===

{| class="wikitable"
! Rol
! Toelichting
|-
| Verwijzende zorgverlener
| De zorgverlener die de patiënt verwijst van het ene centrum naar het andere ((a) en (g) in figuur).
|-
| Sturende zorgverlener
| De zorgverlener of gedelegeerde die na verwijzing de BgZ van de patiënt naar de ontvangende instelling stuurt (h).
|-
| Ontvangende zorgverlener
| Bij overdracht van de medische gegevens van de patiënt tussen instellingen waar msz wordt verleend wordt de BgZ als geheel overgedragen en door de ontvanger geheel of in delen overgenomen. De ontvangende zorgverlener controleert de relevante gegevens en autoriseert deze voor overname in het eigen dossier (j).
|}

Tabel 1: Bedrijfsrollen betrokken bij de eerste use case.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png|600px|Figuur 2]]
</div>

<b>Figuur 2</b>: Activiteit van de bedrijfsrollen in de eerste use case.

===Informatieoverdracht===

====Systemen & systeemrollen====

De sturende en ontvangende zorgmedewerkers maken ieder gebruik van een bronsysteem (XIS) in een sturende en ontvangende zorginstelling.
Het XIS vervult de systeemrollen:
# Medisch Specialistische Zorg Proces – BgZ - Sturend [MSZ-XIS-S] systeem
# Medisch Specialistische Zorg Proces – BgZ – Ontvangend [MSZ-XIS-O] systeem

====Transacties & transactiegroepen====

{| class="wikitable"
! Usecase
! Transactie
! Systeemrol
! Systeemrolcode
! Systemen
! Bedrijfsrol
! ART-DECOR
|-
|style=" rowspan="2"| Uitwisseling BgZ bij verwijzing of overdracht
|style=" rowspan="2"| Sturen BgZ-MSZ (PUSH)
| Sturend systeem
| MSZ-BZS-2.0-FHIR
| XIS
| Sturende msz zorgverlener
|style=" rowspan="2"| [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20250506T091718/tr-2.16.840.1.113883.2.4.3.11.60.42.4.42-2024-03-27T165734.html Sturen]
|-
| Ontvangend systeem
| MSZ-BZO-2.0-FHIR
| XIS
| Ontvangende msz zorgverlener
|}

<b>Tabel 2</b>: ART-DECOR publicatie bij de transacties betrokken bij de use case: Uitwisseling BgZ bij verwijzing of overdracht (PUSH).

====Samenhang bedrijfsrollen, activiteiten, transacties, systeemrollen en transactiegroepen====

Onderstaande afbeelding toont de samenhang tussen de processen, bedrijfsrollen, systemen, systeemrollen, transacties en transactiegroep die onderdeel maken van het uitwisselen bij verwijzing.

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;">
[[Bestand:2024 05 23 BgZ msz Systeemrollen UseCase1.png|600px|Figuur 3]]
</div>

<b>Figuur 3</b>:Systeemrollen betrokken bij het uitwisselen van de BgZ-MSZ bij verwijzing of overdracht (PUSH).

==Opvraging BgZ bij eerdere behandelaar==

Deze use case komt overeen met use case (b) in figuur 1.

===Doel en relevantie===

Het doel is een veilige en zorgvuldige uitwisseling van gegevens bij opvraging van de BgZ bij een eerdere behandelaar (e) en (f) in figuur 1.

Een voorbeeld van het opvraging van gegevens bij een eerdere behandelaar

# Een patiënt is na een wachtlijst van één maand onder behandeling van een cardioloog in een topklinisch ziekenhuis voor het plaatsen van een stent.
# Voor het plannen van de behandeling vraagt de cardioloog van het topklinische ziekenhuis de actuele BgZ gegevens op bij het regionale ziekenhuis.
# Een zorgmedewerker in het regionale ziekenhuis stelt de actuele BgZ beschikbaar.
# Een zorgmedewerker bestudeert de BgZ zoals gestuurd bij de verwijzing om inzicht in de patiëntencontext te krijgen ten tijde van de verwijzing en de actuele BgZ om de behandeling en nazorg optimaal te kunnen plannen.

Deze use case is nog niet verder uitgewerkt in deze informatiestandaard.
Technische afspraken over het communicatiepatroon "Gericht bevragen" (pull) zijn nog niet beproefd en nog niet beschikbaar voor implementatie.

=Aanvullende afspraken=

Dit hoofdstuk bevat aanvullende afspraken en verduidelijkingen die bijdragen aan een veilige en zorgvuldige overdracht met eenduidig te interpreteren afspraken. Deze kunnen in een (door)ontwikkeling van de kwaliteitsstandaard en/of richtlijn worden verwerkt.

==Uitwisselen bij verwijzing en overdracht zonder informatieverlies==

Voor een veilige en zorgvuldige overdracht van een MSZ instelling A naar een MSZ instelling B moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Tijdens de uitwisseling moet altijd duidelijk zijn om welke gestructureerde informatie-elementen het gaat.
* De naamgeving van een data-element mag niet zodanig zijn dat het op enig moment in het proces misverstand is over de semantiek.
* De precisie van data moet behouden blijven. De waarde “3,0” met één decimaal achter de komma mag tijdens het uitwisselen bijvoorbeeld geen “3” worden. Ook mag voor een datum die is gedefinieerd als een jaartal nergens in het proces een maand of dag worden verondersteld of toegevoegd.

==Laatst bekende waarde==

Voor een veilige en zorgvuldige overdracht van een eerste msz-instelling naar een tweede msz-instelling moet de uitwisseling van patiëntgegevens plaatsvinden zonder verlies van informatie. Dit is ook van toepassing op registratiegegevens. De datum van eerste registratie en de mutatiedatum van een gegevenselement moet ongewijzigd worden overgenomen door een tweede msz instelling, zodat bij het sturen en beschikbaarstellen van gegevens door deze tweede msz instelling nog steeds de laatst bekende waarde kan worden gestuurd indien relevant. Voor registratiegegevens gelden de volgende afspraken:

* Bij het sturen en beschikbaarstellen van gegevens die voor het eerst zijn geregistreerd in een bronsysteem en niet zijn gewijzigd, zijn de mutatiedatum en registratiedatum gelijk.
* Na het sturen van gegevens die ongewijzigd zijn overgenomen door een tweede bronsysteem, is de mutatiedatum en de datum van eerste registratie niet aangepast.

Zo heeft een zorgverlener altijd inzicht in wanneer gegevens zijn vastgelegd en wanneer deze voor het laatst zijn geactualiseerd. Ook kan een zorgverlener bij gegevens uit meerdere bronnen inzicht krijgen in wat de laatst bekende waarde is van een gegevenselement.

==Beschikbaarheid van BgZ elementen==

Voor een veilige en zorgvuldige overdracht moet het duidelijk zijn of een bronsysteem een element van de BgZ niet kan sturen of wel kan sturen. Als het systeem gegevens voor een specifiek gegevenselement wel kan sturen, moet het duidelijk zijn dat er wel of niet gegevens beschikbaar zijn over dit specifieke element van de BgZ. Als het systeem gegevens voor een specifiek gegevenselement niet kan sturen, heeft de zorgverlener de informatie om weloverwogen te beslissen welke vervolgstappen te ondernemen.

BgZ elementen moeten binnen 24 uur na verwijzing beschikbaar zijn voor het sturen naar de ontvangende zorgverlener. Tevens moeten BgZ elementen binnen 24 uur na opvragen bij een eerdere behandelaar beschikbaargesteld zijn.

=Aanvullende informatie=

==Binding van waardenlijsten==

De BgZ-MSZ 2.0 is samengesteld uit zibs uit de zib Publicatie 2017<ref name="zib Publicatie 2017(NL)" />. Deze bevat geen specificaties voor de sterkte van de bindings van de waardenlijsten. Voor de BgZ-MSZ 2.0 gelden de specificaties zoals ze zijn opgenomen in de FHIR-profielen waarmee de BgZ 2.0 is geïmplementeerd (zie Technisch Ontwerp).

==Codering van informatie==

Tijdens het gehele uitwisselingsproces worden eenheden uitgewisseld via de hoofdlettergevoelige expressiesyntaxis van UCUM. De accolades maken deel uit van de UCUM-standaard. Het gaat hierbij om een beschrijvende aantekening in plaats van een eenheidsnaam zoals bijvoorbeeld in {Cells}/uL.

De BgZ kan worden uitgewisseld met verouderde codes, zoals verouderde SNOMED codes. De ontvangende partij dient deze gegevens zonder verlies van informatie te kunnen tonen. Het omzetten van verouderde codes naar actuele codes tijdens de uitwisseling kan leiden tot veranderd gedrag van systemen en moet daarom niet plaatsvinden.

<p id="Bekende_problemen"></p>
=Known issues=
{| class="wikitable"
! Onderwerp !! Omschrijving !! MSZ issue
|-
| Adresgegevens || Testpatiënt C bevat alleen informatie voor de verplichte en conditionele velden. Daarom is van adresgegevens alleen {{fhir|AdresSoort}}(1…1R) aanwezig.||
|-
| AllergieIntolerantie ||
* De AllergieIntolerantie in de BgZ-MSZ voldoet niet aan de zib. In deze is de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD) gevolgd.<ref name="Handreiking adequate registratie" />
* Het element {{fhir|AllergyIntolerance.clinicalStatus}} ontbreekt in de FHIR berichten.
||[https://nictiz.atlassian.net/browse/MSZ-272 MSZ-272]
|-
|-
| FHIR-profielen || Enkele FHIR mappings naar de dataset ontbreken of zijn incorrect. || [https://nictiz.atlassian.net/browse/MSZ-274 MSZ-274]
|-
| LaboratoriumUitslag || FHIR output voor {{fhir|LaboratoriumUitslag.DatumTijd}} is afwijkend van de test patiënten op de wiki.||
|-
| Medische termen || Alle displayValues voor medische termen worden in FHIR voorbeelden met een hoofdletter geschreven.||
|-
| Metadata (Provenance) || De Metadata informatie in het TO staat niet in dezelfde vorm beschreven als in het FO.||
|-
| Probleem || {{fhir|Probleem.ProbleemBeginDatum}} en {{fhir|Probleem.ProbleemEinddatum}} zijn nog niet uitgebreid met de optie “Onbekend” zoals voorgeschreven in de Handreiking adequate registratie in het Elektronisch Patiënten Dossier (EPD).<ref name="Handreiking adequate registratie" />||
|-
| Test- en kwalificatiemateriaal ||
# Alle test patiënten in FHIR bevatten minder informatie dan het FHIR profiel voorschrijft, bijvoorbeeld "Burgerlijke Staat" mist.
# Test patiënten C en D bevatten niet overal realistische datum en tijd waarden.
# In het testscript ontbreekt een specificatie voor het testen van de Notified Pull in het kader van de BgZ-MSZ.
||
# [https://nictiz.atlassian.net/browse/MSZ-269 MSZ-269]
# -
# -
|-
| Verrichting || FHIR output voor {{fhir|Procedure.status}} is in zowel test- als kwalificatiescripts afwijkend van de definitie. De FHIR profiel mapping voor {{fhir|Procedure.category}} is in ontwikkeling en is gekoppeld aan {{fhir|Verrichting.VerrichtingCategorie}} uit de zib.||
|-
| Voedingsadvies || De FHIR output voor {{fhir|zib-NutritionAdvice.status}} is altijd {{fhir|active}} zonder dat er voor Voedingsadvies status een definitie in de dataset is.||
|}

=Referenties=
<references />

=Release notes=

==Beta 1 release==

https://nictiz.atlassian.net/browse/MSZ-39 MSZ-39 Aanpassing kwalificatiemateriaal bij Lab: verwijderen monster, onderzoek]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-75 MSZ-75:Toevoegen zib ZorgAanbieder elementen in BgZ - msz 2.0]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-186 MSZ-186:Verrichting.Categorie is toegevoegd]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-153 MSZ-153:Feedback Functioneel Design BgZ - Medisch Specialistische Zorg]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-147 MSZ-147:Term "verwerken" onhandig]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-146 MSZ-146:Figuur van andere use case vermeld]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-144 MSZ-144:Opvragende zorgverlener i.p.v. zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-143 MSZ-143:Onjuiste verwijzing]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-142 MSZ-142:Onjuist gebruik zorgverlener en zorgmedewerker]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-141 MSZ-141:Tegenstrijdigheid m.b.t. status use cases]

[https://nictiz.atlassian.net/jira/software/c/projects/MSZ/issues/MSZ-140 MSZ-140:Norm bevat geen afspraken maar eisen]

==Beta 2 release==
Referentie naar de gepubliceerde kwaliteitsstandaard is opgenomen.

[https://nictiz.atlassian.net/browse/MSZ-197 MSZ-197:Paragraaf 3.2 Laatst bekende gegevens op FO verwijderen]

[https://nictiz.atlassian.net/browse/MSZ-198 MSZ-198 Eenheid van taal vergt gedragsverandering en niet slechts een onhaalbare eis in een informatiestandaard]

[https://nictiz.atlassian.net/issues/MSZ-203 MSZ-203 Inleiding kwalificatiescript mist achternaam patiënt]

[https://nictiz.atlassian.net/browse/MSZ-206 MSZ-206 Ontbrekende contactpersoon in testscript bij patiënt C]

[https://nictiz.atlassian.net/browse/MSZ-209 MSZ-209 Testscript refereert aan screenshots]

[https://nictiz.atlassian.net/browse/MSZ-210 MSZ-210 Impact momentopname naast on-demand BgZ te groot]

[https://nictiz.atlassian.net/browse/MSZ-223 MSZ-223 Uitwisseling geplande verrichtingen tegenstrijdig gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-224 MSZ-224 Uitwisseling contra-indicaties onduidelijk gespecificeerd]

[https://nictiz.atlassian.net/browse/MSZ-225 MSZ-225: Alle i.p.v. laatst bekende functionele/mentale status(sen) mist onderbouwing]

[https://nictiz.atlassian.net/browse/MSZ-227 MSZ-227: Informatiestandaard raakt niet alleen derde laag 'vijflagenmodel']

[https://nictiz.atlassian.net/browse/MSZ-228 MSZ-228: Verschil opvragen en raadplegen onduidelijk in Figuur 1]

==Beta 3 release==



=Wiki-paginahistorie=
Eerste versie van 2.0 beta 24 september 2024

Tweede versie 2.0 beta 2 datum 14 april 2025

{{MedMij:Sjabloon_Ondersteuning}}

qa:Template TO

2025-07-10T11:28:45Z

Gabriel Hopmans: /* Search parameters */ removed todo

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for STANDARDNAME [[Landingspagina_IS| see IS main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:Title of current standard}
__TOC__

{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



{{FaqBox |
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.
<br/><br/>

'''Change the document title to:''' Technical Design <IS name> <IS version><br/>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.
}}

== Introduction ==
{{ReminderBox|
'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers. <br/>
Boundaries should define how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links.
}}
'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Boundaries ===
'''Standard text:''' This standard may overlap with other information standards related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication. For more information, see <link to FO>.

{{IssueBox| Dit moet ook in het FO template gezet worden!}}

=== Known issues ===
'''Standard text:''' The IS is actively maintained and continuously improved. However, limitations to the current version may exist. The known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

{{IssueBox| Dit moet ook in het FO template gezet worden!}}

=== Prerequisite knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* The FO [link] accompanying this TO.
* This standard uses the data exchange pattern <your pattern here>, which you can find here: <link>

'''Example BgZ-MSZ 2.0:'''
This TO assumes that the reader is familiar with the following:
* FHIR STU3
* FO link
* Technical Agreement - Notified Pull (TA-NP)

== Components ==
{{ReminderBox|
'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently this template supports is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>
The artifacts section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).
}}

=== HL7 FHIR <version> ===
'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:''' [<span style="color:navy" class="mw-customtoggle-packagingExample">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-packagingExample">
{{NoteBox|
eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.
}}</div>

==== Artifacts ====
'''Standard text:'''
Link to the FO. A link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Transactions ==
{{ReminderBox|
'''Goal:'''
In this chapter, the transaction groups of the functional design are supplemented with invocations, such as FHIR queries and search parameters.<br>
To give an overview of the actors relevant in this IS, A table should be used to list the relevant actors, their systems, and if possible, FHIR CapabilityStatements.
}}

=== <Transaction group 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| System role code
! style="text-align:left;"| FHIR CapabilityStatement
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <Actor 1>
|style="vertical-align:top;"| <System role code 1>
|style="vertical-align:top;"| <FHIR CapabilityStatement 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <Actor 2>
|style="vertical-align:top;"| <System role code 2>
|style="vertical-align:top;"| <FHIR CapabilityStatement 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''System role'''
! style="text-align:left;"| '''FHIR CapabilityStatement'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.139-2022-06-30T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.375_20220630000000 Medication data (PUSH)]
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.376-2022-06-30T000000.html Sending medication data]
|style="background-color: white;vertical-align:top;"|Client
|style="background-color: white;vertical-align:top;"|MP-MGS
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationData.SendReceive|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}|title=CapabilityStatement Send/receive medication data}}
|-
|style="background-color: white;vertical-align:top;"|Receiving medication data
|style="background-color: white;vertical-align:top;"|Server
|style="background-color: white;vertical-align:top;"|MP-MGO
|}

==== Invocations ====
'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource 1>?_include=<FHIR resource 1>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <Functional data element 2>
|-
| <pre> see <FHIR resource 1 data element> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

'''Example MP9:'''<br/>
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Functional data element
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | Example
|-
| PatientIdentificationNumber
| Search on patient.
| {{fhir|patient.identifier}} <ref name="patient-searchparameter">This search parameter only needs to be supported when patient identification requires the use of search parameters, see [[#Patient_identification|section 2.4]].</ref>
{{fhir|subject:Patient.identifier}} <ref name="patient-searchparameter"/>
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves all MedicationRequest resources of a patient with a fictional BSN of 11122233.
<pre>GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre>
|-
| Identification
| Search on identifier.
| {{fhir|identifier}}
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves a MedicationRequest resource with a specific identifier.
<pre>GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448</pre>
|-
| Identification
| Search on the pharmaceutical treatment identifier.
Note: retrieval of all medication resources belonging to one pharmaceutical treatment requires to search on all medication resource types.
| {{fhir|pharmaceutical-treatment-identifier}} <ref name="custom-searchparameter">The search parameter consists of a custom FHIR search parameter not represented in the FHIR specification. Note that for {{fhir|MedicationRequest.category}} and {{fhir|MedicationStatement.category}} a core search parameter is available, hence no custom one is needed in those cases.</ref>
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier.
<pre>GET [base]/MedicationRequest?pharmaceutical-treatment-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|1247848</pre>
|}

=== <Transaction group 2> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| System role code
! style="text-align:left;"| FHIR CapabilityStatement
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <Actor 1>
|style="vertical-align:top;"| <System role code 1>
|style="vertical-align:top;"| <FHIR CapabilityStatement 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <Actor 2>
|style="vertical-align:top;"| <System role code 2>
|style="vertical-align:top;"| <FHIR CapabilityStatement 2>
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the transaction.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource 1>?_include=<FHIR resource 1>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <Functional data element 2>
|-
| <pre> see <FHIR resource 1 data element> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

==== Search parameters ====

== Optional elements (not part of template chapters) ==
''''Goal:''' The contents of these chapters are dependent on the needs of your IS; fill them in at your own discretion.

''Workflow''<br>
If absolutely necessary (e.g., your IS uses a workflow with a unique technical implementation), an additional chapter called "Workflow" may be added after the Introduction.
[]

''Relationships''<br>
You may want to show the relationships between the various data elements in your IS using a diagram. If so, add an additional chapter called "Relationships" after the Introduction (or Workflow, if used).

''Footnotes''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added as the final chapter. In there, a footnote may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-10T08:33:55Z

Gabriel Hopmans:

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for STANDARDNAME [[Landingspagina_IS| see IS main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:Title of current standard}
__TOC__

{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



{{FaqBox |
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.
<br/><br/>

'''Change the document title to:''' Technical Design <IS name> <IS version><br/>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.
}}

== Introduction ==
{{ReminderBox|
'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers. <br/>
Boundaries should define how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links.
}}
'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Boundaries ===
'''Standard text:''' This standard may overlap with other information standards related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication. For more information, see <link to FO>.

{{IssueBox| Dit moet ook in het FO template gezet worden!}}

=== Known issues ===
'''Standard text:''' The IS is actively maintained and continuously improved. However, limitations to the current version may exist. The known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

{{IssueBox| Dit moet ook in het FO template gezet worden!}}

=== Prerequisite knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* The FO [link] accompanying this TO.

== Components ==
{{ReminderBox|
'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>
The artifacts section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).
}}

=== HL7 FHIR <version> ===
'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:''' [<span style="color:navy" class="mw-customtoggle-packagingExample">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-packagingExample">
{{NoteBox|
eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.
}}</div>

==== Artifacts ====
'''Standard text:'''
Link to the FO. A link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Transactions ==
{{ReminderBox|
'''Goal:'''
In this chapter, the transaction groups of the functional design are supplemented with invocations, such as FHIR queries and search parameters.<br>
To give an overview of the actors relevant in this IS, A table should be used to list the relevant actors, their systems, and if possible, FHIR CapabilityStatements.
}}

=== <Transaction group 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| System role code
! style="text-align:left;"| FHIR CapabilityStatement
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <Actor 1>
|style="vertical-align:top;"| <System role code 1>
|style="vertical-align:top;"| <FHIR CapabilityStatement 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <Actor 2>
|style="vertical-align:top;"| <System role code 2>
|style="vertical-align:top;"| <FHIR CapabilityStatement 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''System role'''
! style="text-align:left;"| '''FHIR CapabilityStatement'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.139-2022-06-30T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.375_20220630000000 Medication data (PUSH)]
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.376-2022-06-30T000000.html Sending medication data]
|style="background-color: white;vertical-align:top;"|Client
|style="background-color: white;vertical-align:top;"|MP-MGS
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationData.SendReceive|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}|title=CapabilityStatement Send/receive medication data}}
|-
|style="background-color: white;vertical-align:top;"|Receiving medication data
|style="background-color: white;vertical-align:top;"|Server
|style="background-color: white;vertical-align:top;"|MP-MGO
|}

==== Invocations ====
'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource 1>?_include=<FHIR resource 1>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <Functional data element 2>
|-
| <pre> see <FHIR resource 1 data element> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

TODO: Voorstel Gabriel

Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

'''Example MP9:'''<br/>
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Functional data element
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | Example
|-
| PatientIdentificationNumber
| Search on patient.
| {{fhir|patient.identifier}} <ref name="patient-searchparameter">This search parameter only needs to be supported when patient identification requires the use of search parameters, see [[#Patient_identification|section 2.4]].</ref>
{{fhir|subject:Patient.identifier}} <ref name="patient-searchparameter"/>
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves all MedicationRequest resources of a patient with a fictional BSN of 11122233.
<pre>GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre>
|-
| Identification
| Search on identifier.
| {{fhir|identifier}}
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves a MedicationRequest resource with a specific identifier.
<pre>GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448</pre>
|-
| Identification
| Search on the pharmaceutical treatment identifier.
Note: retrieval of all medication resources belonging to one pharmaceutical treatment requires to search on all medication resource types.
| {{fhir|pharmaceutical-treatment-identifier}} <ref name="custom-searchparameter">The search parameter consists of a custom FHIR search parameter not represented in the FHIR specification. Note that for {{fhir|MedicationRequest.category}} and {{fhir|MedicationStatement.category}} a core search parameter is available, hence no custom one is needed in those cases.</ref>
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier.
<pre>GET [base]/MedicationRequest?pharmaceutical-treatment-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|1247848</pre>
|}

=== <Transaction group 2> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| System role code
! style="text-align:left;"| FHIR CapabilityStatement
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <Actor 1>
|style="vertical-align:top;"| <System role code 1>
|style="vertical-align:top;"| <FHIR CapabilityStatement 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <Actor 2>
|style="vertical-align:top;"| <System role code 2>
|style="vertical-align:top;"| <FHIR CapabilityStatement 2>
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the transaction.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource 1>?_include=<FHIR resource 1>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <Functional data element 2>
|-
| <pre> see <FHIR resource 1 data element> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

==== Search parameters ====

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''Workflow''<br>
If absolutely necessary (e.g., your IS uses a workflow with a unique technical implementation), an additional chapter called "Workflow" may be added after the Introduction.

''Relationships''<br>
You may want to show the relationships between the various data elements in your IS using a diagram. If so, add an additional chapter called "Relationships" after the Introduction (or Workflow, if used).

''Footnotes''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added as the final chapter. In there, a footnote may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-10T08:27:03Z

Gabriel Hopmans:

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

For an overview of all current documentation for BgZ-MSZ [[Landingspagina_BgZ| see BgZ main page]]
__NUMBEREDHEADINGS__
__NOINDEX__
{{DISPLAYTITLE:BgZ MSZ FHIR Implementation Guide 2.0.0-beta.2}}
__TOC__

{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



{{FaqBox |
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.
<br/><br/>

'''Change the document title to:''' Technical Design <IS name> <IS version><br/>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.
}}

== Introduction ==
{{ReminderBox|
'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers. <br/>
Boundaries should define how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links.
}}
'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Boundaries ===
'''Standard text:''' This standard may overlap with other information standards related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication. For more information, see <link to FO>.

{{IssueBox| Dit moet ook in het FO template gezet worden!}}

=== Known issues ===
'''Standard text:''' The IS is actively maintained and continuously improved. However, limitations to the current version may exist. The known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

{{IssueBox| Dit moet ook in het FO template gezet worden!}}

=== Prerequisite knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* The FO [link] accompanying this TO.

== Components ==
{{ReminderBox|
'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>
The artifacts section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).
}}

=== HL7 FHIR <version> ===
'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:''' [<span style="color:navy" class="mw-customtoggle-packagingExample">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-packagingExample">
{{NoteBox|
eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.
}}</div>

==== Artifacts ====
'''Standard text:'''
Link to the FO. A link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Transactions ==
{{ReminderBox|
'''Goal:'''
In this chapter, the transaction groups of the functional design are supplemented with invocations, such as FHIR queries and search parameters.<br>
To give an overview of the actors relevant in this IS, A table should be used to list the relevant actors, their systems, and if possible, FHIR CapabilityStatements.
}}

=== <Transaction group 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| System role code
! style="text-align:left;"| FHIR CapabilityStatement
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <Actor 1>
|style="vertical-align:top;"| <System role code 1>
|style="vertical-align:top;"| <FHIR CapabilityStatement 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <Actor 2>
|style="vertical-align:top;"| <System role code 2>
|style="vertical-align:top;"| <FHIR CapabilityStatement 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''System role'''
! style="text-align:left;"| '''FHIR CapabilityStatement'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.139-2022-06-30T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.375_20220630000000 Medication data (PUSH)]
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20250522T132618/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.376-2022-06-30T000000.html Sending medication data]
|style="background-color: white;vertical-align:top;"|Client
|style="background-color: white;vertical-align:top;"|MP-MGS
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationData.SendReceive|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion={{VersieInfo|nictiz.fhir.nl.r4.medicationprocess9|release=V3.0.0}}|title=CapabilityStatement Send/receive medication data}}
|-
|style="background-color: white;vertical-align:top;"|Receiving medication data
|style="background-color: white;vertical-align:top;"|Server
|style="background-color: white;vertical-align:top;"|MP-MGO
|}

==== Invocations ====
'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource 1>?_include=<FHIR resource 1>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <Functional data element 2>
|-
| <pre> see <FHIR resource 1 data element> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

TODO: Voorstel Gabriel

Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

'''Example MP9:'''<br/>
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Functional data element
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | Example
|-
| PatientIdentificationNumber
| Search on patient.
| {{fhir|patient.identifier}} <ref name="patient-searchparameter">This search parameter only needs to be supported when patient identification requires the use of search parameters, see [[#Patient_identification|section 2.4]].</ref>
{{fhir|subject:Patient.identifier}} <ref name="patient-searchparameter"/>
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves all MedicationRequest resources of a patient with a fictional BSN of 11122233.
<pre>GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre>
|-
| Identification
| Search on identifier.
| {{fhir|identifier}}
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves a MedicationRequest resource with a specific identifier.
<pre>GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448</pre>
|-
| Identification
| Search on the pharmaceutical treatment identifier.
Note: retrieval of all medication resources belonging to one pharmaceutical treatment requires to search on all medication resource types.
| {{fhir|pharmaceutical-treatment-identifier}} <ref name="custom-searchparameter">The search parameter consists of a custom FHIR search parameter not represented in the FHIR specification. Note that for {{fhir|MedicationRequest.category}} and {{fhir|MedicationStatement.category}} a core search parameter is available, hence no custom one is needed in those cases.</ref>
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
| Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier.
<pre>GET [base]/MedicationRequest?pharmaceutical-treatment-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|1247848</pre>
|}

=== <Transaction group 2> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| System role code
! style="text-align:left;"| FHIR CapabilityStatement
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <Actor 1>
|style="vertical-align:top;"| <System role code 1>
|style="vertical-align:top;"| <FHIR CapabilityStatement 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <Actor 2>
|style="vertical-align:top;"| <System role code 2>
|style="vertical-align:top;"| <FHIR CapabilityStatement 2>
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the transaction.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource 1>?_include=<FHIR resource 1>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <Functional data element 2>
|-
| <pre> see <FHIR resource 1 data element> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or Functional segment)>
|-
! colspan="2" style="text-align: left;" | <Functional data element 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

==== Search parameters ====

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''Workflow''<br>
If absolutely necessary (e.g., your IS uses a workflow with a unique technical implementation), an additional chapter called "Workflow" may be added after the Introduction.

''Relationships''<br>
You may want to show the relationships between the various data elements in your IS using a diagram. If so, add an additional chapter called "Relationships" after the Introduction (or Workflow, if used).

''Footnotes''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added as the final chapter. In there, a footnote may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-03T11:37:57Z

Gabriel Hopmans: /* Search parameters */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.<br>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations

{=> A transaction is based upon one transaction-dataset.}

(e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

TODO: Voorstel Gabriel

Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Information Standard search parameter
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | Example
|}

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== NP (if applicable) ==

[table with terminology mapping so that NP can be applied]

== Selection criteria ==
Goal: definition of selection criteria that can be used.

Example of slection criterium

FunctionalOrMentalStatus.category is used to select (a) a function status or (b) a mental status

[tabel]

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).<br>
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?''<br>
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-03T11:32:38Z

Gabriel Hopmans: /* Search parameters */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.<br>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations

{=> A transaction is based upon one transaction-dataset.}

(e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

TODO: Voorstel Gabriel/afgekeken bij CIO

Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Information Standard search parameter
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | Example
|}

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== NP (if applicable) ==

[table with terminology mapping so that NP can be applied]

== Selection criteria ==
Goal: definition of selection criteria that can be used.

Example of slection criterium

FunctionalOrMentalStatus.category is used to select (a) a function status or (b) a mental status

[tabel]

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).<br>
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?''<br>
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-03T11:29:33Z

Gabriel Hopmans: /* Search parameters */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.<br>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations

{=> A transaction is based upon one transaction-dataset.}

(e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====
Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Information Standard search parameter
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
! style="font-weight: bold;text-align:left;" | Example
|}

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== NP (if applicable) ==

[table with terminology mapping so that NP can be applied]

== Selection criteria ==
Goal: definition of selection criteria that can be used.

Example of slection criterium

FunctionalOrMentalStatus.category is used to select (a) a function status or (b) a mental status

[tabel]

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).<br>
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?''<br>
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-03T11:22:45Z

Gabriel Hopmans: /* Search parameters */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.<br>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations

{=> A transaction is based upon one transaction-dataset.}

(e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====
Search parameters are used in the URL to filter the results of a FHIR query. Clients can use defined parameters and may also use custom parameters, while servers can choose to support or ignore them, and must indicate which parameters were used in the response.

Provide a table listing all search parameters that SHALL or MAY be supported for processing by servers and SHALL/MAY be supported by clients. Include the corresponding Information Standard search parameter, Description, FHIR search parameter, FHIR resources, Descriptions and examples. Mention also custom search parameters that may be defined for transactions of the particular information standard.

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== NP (if applicable) ==

[table with terminology mapping so that NP can be applied]

== Selection criteria ==
Goal: definition of selection criteria that can be used.

Example of slection criterium

FunctionalOrMentalStatus.category is used to select (a) a function status or (b) a mental status

[tabel]

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).<br>
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?''<br>
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-03T11:15:16Z

Gabriel Hopmans: /* Introduction */

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.<br>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>. The standard we use is: CDA/FHIR STU3/R4/

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [reference to current FO].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations

{=> A transaction is based upon one transaction-dataset.}

(e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== NP (if applicable) ==

[table with terminology mapping so that NP can be applied]

== Selection criteria ==
Goal: definition of selection criteria that can be used.

Example of slection criterium

FunctionalOrMentalStatus.category is used to select (a) a function status or (b) a mental status

[tabel]

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).<br>
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Optional elements (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?''<br>
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

qa:Template TO

2025-07-02T07:23:13Z

Gabriel Hopmans: /* Boundaries & relationships */ In this chapter defines -> This chapter defines

__NOINDEX__
{{underconstruction}}

{| class="wikitable"
|-
! | Processen: | [https://informatiestandaarden.nictiz.nl/wiki/qa:Verkennen Verkennen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Ontwikkelen_en_Testen Ontwikkelen & Testen] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Publiceren#Procesactiviteiten Publiceren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Beheren Beheren] | [https://informatiestandaarden.nictiz.nl/wiki/qa:Kwalificeren Kwalificeren]
|}


<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


[[Bestand:00_Iconen_QA.png|150px|150px|link=QA:Hoofdproces|Hoofdproces]]

__NUMBEREDHEADINGS__

{{DISPLAYTITLE:Quality Assurance - Template - Technisch Ontwerp {{VersieInfo|xprocesx}}}}
<span class="toclimit-3">__TOC__</span>
<span class="toclimit-3">__TOC__</span>



[[Bestand:Icoon_Nictiz_Cirkel_Ontwikkelen.svg|75px|75px|link=QA:Proceskaart_Ontwikkelen|Proceskaart Ontwikkelen]]

[[Bestand:Icoon_Nictiz_Cirkel_Testen.svg|75px|75px|link=QA:Proceskaart_Testen|Proceskaart Testen]]



== Introduction ==
An Information Standard (IS) has both a functional and a technical design, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.<br>
The template uses the following annotation:

* '''Goal:''' What the goal of the section is and what information it should include.
* '''Standard text:''' Standard sentences to include if appropriate.
* '''Examples:''' These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
* '''Placeholders:''' "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

----

'''Goal:''' The Introduction is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

'''Standard text:''' This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>.

'''Example BgZ-MSZ 2.0 FHIR STU3:'''<br>
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: [[Landingspagina_BgZ| see BgZ main page]].

In addition, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3|general FHIR STU3 Implementation Guide]] apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles|use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR packages]].

=== Support ===
'''Standard text:''' For questions, feedback, or change requests, please contact our support team at [https://nictiz.atlassian.net/servicedesk/customer/portal/4 Nictiz Servicemanagement].

=== Known issues ===
'''Standard text:''' The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [<Link-to-FO#known-issues> | FO (in Dutch)].

=== Assumed knowledge ===
'''Standard text:''' This TO assumes that the reader is familiar with the following:
* <your data exchange standard (e.g., FHIR, CDA, XSD, XCA, etc.)>.
* This TO is accompanied by the <IS> FO.

== Boundaries & relationships ==

'''Goal:''' This chapter defines how organizations and their relationships are structured and exchanged across systems. It supports interoperability by standardizing hierarchical and functional links. This standard overlaps with others related to identification, roles, and geographic classifications, requiring careful alignment to ensure consistency and avoid duplication.

== Actors involved ==
'''Goal:''' To give an overview of the actors relevant to the transaction. A table should be used to list the relevant actors, their systems, and, if possible, FHIR CapabilityStatements.

'''Standard text:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| <Actor 1>
| <Actor description 1>
| <System role 1>
| <System role description 1>
| <CapabilityStatement link 1>
| <CapabilityStatement description 1>
|-
| <Actor 2>
| <Actor description 2>
| <System role 2>
| <System role description 2>
| <CapabilityStatement link 2>
| <CapabilityStatement description 2>
|}

'''Example eOverdracht 4.0.5 STU3:'''
{| class="wikitable"
! colspan="2" | Actors
! colspan="2" | Systems
! colspan="2" | FHIR Capability Statements
|-
! Name
! Description
! Name
! Description
! Name
! Description
|-
| Sending organization
| The organization or health care professional(?) at the organization that wants to transfer the care of a patient
| Sending XIS
| Healthcare information system of the sending organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-clientcapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Sending XIS}}
| FHIR requirements for sending XIS
|-
| Receiving organization
| The organization or health care professional(?) at the organization that the sending organization wants to transfer the care of a patient to
| Receiving XIS
| Healthcare information system of the receiving organization
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eOverdracht-servercapabilities|nictiz.fhir.nl.stu3.eoverdracht|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}|title=CapabilityStatement: Receiving XIS}}
| FHIR requirements for receiving XIS
|}

== Transactions ==

'''Goal:'''
In this chapter, the use cases of an IS are elaborated through transactions. A transaction is an HCIM-based dataset (applicable to multiple use cases). A transaction should include information about the (earlier specified) involved actors. It should also include information regarding the available invocations (e.g., FHIR queries).

=== <Transaction 1> ===
==== Involved actors ====
'''Standard text:'''
{| class="wikitable"
! style="text-align:left;"| Transaction group
! style="text-align:left;"| Transaction
! style="text-align:left;"| Actor
! style="text-align:left;"| Role
|-
|style="vertical-align:top;" rowspan="2"|<Transaction group name>
|style="vertical-align:top;"| <Transaction 1>
|style="vertical-align:top;"| <System role 1>
|style="vertical-align:top;"| <Role explanation 1>
|-
|style="vertical-align:top;"| <Transaction 2>
|style="vertical-align:top;"| <System role 2>
|style="vertical-align:top;"| <Role explanation 2>
|}

'''Example MedMij LaboratoryResults 2.0.42 FHIR STU3:'''
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="vertical-align:top;" rowspan="2"|Retrieve Laboratory Results(PULL)
|style="vertical-align:top;"|Retrieve laboratory results request
|style="vertical-align:top;"|Patient (using a PHR)
|style="vertical-align:top;"|Request laboratory results from the XIS
|-
|style="vertical-align:top;"|Retrieve laboratory results response
|style="vertical-align:top;"|Healthcare professional (using a XIS)
|style="vertical-align:top;"|Serves laboratory results to the PHR
|}

==== Invocations ====
'''Goal:''' To give an overview of the invocations used to query FHIR servers in the use case.

'''Standard text:'''
{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | <sorting variable 1 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 1>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <HCIM 2>
|-
| <pre> see Patient.maritalStatus </pre>
| <Description of queried data>
|-
! colspan="2" style="text-align: left;" | <sorting variable 2 (e.g., FHIR resource or FO chapter)>
|-
! colspan="2" style="text-align: left;" | <HCIM 3>
|-
| <pre> <HTTP Method> [base]/<FHIR resource>?_include=<FHIR resource>:<Search parameters> </pre>
| <Description of queried data>
|}

'''Example BgZ-MSZ 2.0 STU3:''' [<span style="color:navy" class="mw-customtoggle-invocation-first-example">expand/collapse</span>]:
<div class="mw-collapsible mw-collapsed" id="mw-customcollapsible-invocation-first-example">
=====FHIR Query Specification=====
The table below provides an overview of the FHIR queries to exchange all BgZ-MSZ sections.

{| class="wikitable"
! scope="col" style="text-align: left;" | Query
! scope="col" style="text-align: left;" | Description
|-
! colspan="2" style="text-align: left;" | 1 Demographics and identification
|-
! colspan="2" style="text-align: left;" | 1.1 Patient
|-
| <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 last known marital status available in the source system is exchanged using the patient.maritalStatus field.
* If available in the source system, the general practitioner (GP) is exchanged (a) as a FHIR Practitioner instance conforming to the nl-core-practitioner profile, where the Practitioner.identifier indicates a GP, and/or (b) as a FHIR Organization instance conforming to the nl-core-organization profile. The specified referenced resources are returned in full.
* Information regarding the primary partner/contact available in the source system is exchanged using elements of the patient instance. It is not exchanged using the RelatedPerson resource.
|-
! 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
|-
| <pre>
GET [base]/Coverage?
_include=Coverage:payor
</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 3 Treatment restrictions
|-
! colspan="2" style="text-align: left;" | 3.1 Treatment instructions
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11291000146105</pre>
|
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
|-
| <pre>GET [base]/Consent?
category=http://snomed.info/sct|11341000146107</pre>
|
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
|-
! colspan="2" style="text-align: left;" | 5.1 Functional or mental status
|-
| <pre>GET [base]/Observation?
category=http://snomed.info/sct|118228005,
http://snomed.info/sct|384821006</pre>
|
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
|-
| <pre>GET [base]/Condition</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 7 Social history
|-
! colspan="2" style="text-align: left;" | 7.1 Living Situation
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365508006</pre>
|
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
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|228366006</pre>
|
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').
|-
! colspan="2" style="text-align: left;" | 7.4 Tobacco Use
|-
| <pre>GET [base]/Observation?
code=http://snomed.info/sct|365980008</pre>
|
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
|-
| <pre>GET [base]/NutritionOrder</pre>
|
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
|-
| <pre>GET [base]/Flag</pre>
|
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
|-
| <pre>GET [base]/AllergyIntolerance</pre>
|
All allergies and intolerances available in the source system are exchanged as a FHIR AllergyIntolerance instances that conform to the zib-AllergyIntolerance profile.
* According to the BgZ-MSZ transactions, the AllergyIntolerance.Reaction.Symptom must be exchanged if available. In cases where for legacy data there is no Symptom recorded, then the Reaction.manifestation field MUST be populated with a value from the Valueset-data-absent-reason.
<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:medication</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:medication</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
|-
| <pre>GET [base]/MedicationStatement?
category=
urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&
_include=MedicationStatement:medication</pre>
|
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.
|-
! scope="row" colspan="2" style="text-align: left;" | 11 Medical devices
|-
! colspan="2" style="text-align: left;" | 11.1 Medical device
|-
| <pre>GET [base]/DeviceUseStatement?
_include=DeviceUseStatement:device</pre>
|
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
|-
| <pre>GET [base]/Immunization?
status=completed</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|85354-9</pre>
|
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
|-
| <pre>GET [base]/Observation/$lastn?
code=http://loinc.org|29463-7</pre>
|
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
see Encounter.serviceProvider
</pre>
|
Providers, are exchanged as part of the BgZ information elements according to the nl-core-organization profile. There is no specific query to retrieve Health Providers.
|-
! colspan="2" style="text-align: left;" | Meta data
|-
! colspan="2" style="text-align: left;" | 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.
|-
|}
<small><b>Table 4.</b> FHIR queries used to retrieve BgZ MSZ components.</small>
</div>

==== Search parameters ====

=== <Transaction 2> ===
==== Involved actors ====
==== Search parameters ====
==== Invocations ====

== Data exchange standard ==

'''Goal:'''
This chapter should show how the data exchange standard was used to accommodate the Dutch Health Care Information Models (HCIMs) used in the IS. The contents of this chapter change based on the chosen data exchange standard. Currently supported is HL7 FHIR. HL7v3(including CDA), HL7v2, IHE XDS, IHE XCA and others are not supported yet.<br>

=== HL7 FHIR ===
'''Goal:'''
Every implementation of the standard will require the availability of the information presented here.

'''Standard text:'''
{{NoteBox|<IS> uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [<link to package 1>]
* [<link to package 2>]
* [<link to package 3>]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

'''Example eOverdracht 4.0.5 STU3:'''
{{NoteBox|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages|FHIR Packaging mechanism]]. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo|nictiz.fhir.nl.stu3.eoverdracht|release=V4.0}}]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo|nictiz.fhir.nl.stu3.zib2020-preadopt|release=V4.0}}]

'''Note''': packages use [https://semver.org/ Semantic Versioning]. Other versions can be used at will as long as they have the same ''major.minor'' number or a ''minor'' number higher than the stated version.}}

==== Artifacts ====
'''Goal:'''
This section shows the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).<br>
For example, the link to the BgZ-MSZ 2.0 FO would be: [[https://informatiestandaarden.nictiz.nl/wiki/BgZ:V2.0.0-beta.2_Ontwerp_BgZ_MSZ#Specificatie_van_uitgewisselde_BgZ_componenten|BgZ-MSZ 2.0 Chapter 2.1.1]]
In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

# Chapter - The relevant chapter from the FO.
# HCIM - The name of the HCIM to be exchanged.
# Target - The FHIR resource or data element used to exchange the specified HCIM.
# Profile - The FHIR profile used in this information standard. Use [[Sjabloon:Simplifier|Sjabloon Simplifier]].

'''Example BgZ-MSZ 2.0 FHIR STU3:'''
{| class="wikitable" style="horizontal-align: right"
|+ style="text-align:left;" | Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
|-
!style="text-align:right; | Chapter
!style="text-align:left; | HCIM
!style="text-align:left; | Target
!style="text-align:left; | Profile
|-
| style="text-align:right;" rowspan="2" | 1
| Patient
| Patient
| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| MaritalStatus
| Patient.maritalStatus
|-
| style="text-align:right;" rowspan="3" | 2
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" rowspan="2" | 3
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 4
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure|nictiz.fhir.nl.stu3.bgz|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.bgz|release=V2.0|namespace=BgZ}}}}
|-
| style="text-align:right;" | 5
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017|pkgVersion={{VersieInfo|nictiz.fhir.nl.stu3.zib2017|release=V2.0|namespace=BgZ}}}}
|-
|}

==== Examples of FHIR instances ====

'''Standard text:''' A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included.

'''Example BgZ-MSZ 2.0 STU3:''' [https://github.com/Nictiz/Nictiz-testscripts/blob/main/src/BgZ-MSZ-2-0/|Github Nictiz-testscripts (BgZ-MSZ 2.0)]

== Frequently asked questions (not part of template chapters) ==
Here we will answer questions you may have about this template:

''What if my IS uses workflow with a unique technical implementation?''<br>
If absolutely necessary, an additional chapter called "Workflow" may be added after the "Boundries & relationships" chapter.

''What if want to add footnotes?''<br>
If absolutely necessary, an additional chapter called "Footnotes" may be added after the "Transactions" chapter. In there, a footnotes may be added using <nowiki> <ref> and ‎<references /></nowiki> tags.

== Release notes (not part of the template) ==
'''Goal:''' Release notes are not a part of the TO template because this information about the information standard should already be available in the FO. This is described in the [https://nictiznl.sharepoint.com/sites/KHSI/Kwaliteitshandboek%20Standaardisatie/Stappenplan%20patchrelease.aspx | Kwaliteitshandboek Standaardisatie - Stappenplan patchrelease]. Moreover, release notes for technical implementation are already published in the [https://simplifier.net/organization/nictiz/~packages | Nictiz Simplifier packages] and [https://github.com/Nictiz | GitHub] pages.

In onderstaande tabel staan alle wijzigingen met betrekking tot dit Quality Assurance (QA) Proces, vanaf versie 3.0.0.
{| class="wikitable"
|-
!Versie
!Datum
!Release notes
|-
|
|
|
|-
|}

Landingspagina BgZ

2024-11-26T14:23:33Z

Gabriel Hopmans: /* In ontwikkeling */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>

__NUMBEREDHEADINGS__
=Inleiding=

Deze pagina geeft een overzicht van publicaties rondom de BgZ informatiestandaarden.
Algemene informatie over de BgZ vindt u via [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ de BgZ website van Nictiz].

=MedMij=
Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor de MedMij informatiestandaarden.

Daar vindt u ook informatie over de informatiestandaard voor de uitwisseling van de BgZ via een persoonlijke gezondheidsomgeving (PGO).

*[[MedMij:V2020.01/OntwerpBGZ_2017|Functioneel Ontwerp BgZ MedMij]]
*[[MedMij:V2020.01/FHIR_BGZ_2017|FHIR Implementation Guide BgZ MedMij]]

=BgZ Medisch-specialistische zorg (BgZ-MSZ)=
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch-specialistische zorg.

==Actueel==
*[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ msz v1.1]]
*[[BgZ:V1.1_BgZ_2017_Technical_IG|Implementation Guide BgZ msz v1.1]]
*[[BgZ:V1.2.3_Testscripts|Testscripts BgZ msz v1.2.3]] (per 12 september 2024)
*[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ msz zorg 2017 v1.2.2]] (per 12 september 2024)

==In ontwikkeling==
*[[BgZ:V2.0_Ontwerp_Beta_BgZ_MSZ|Functioneel ontwerp BgZ MSZ 2.0.0-beta.1]]
*[[BgZ:V2.0_Beta_2_BgZ_2017_Technical_IG|Implementation Guide BgZ MSZ 2.0.0-beta.1]]
*[[BgZ:V2.0_TestScript_beta|Testscripts BgZ MSZ 2.0.0-beta.1]]
*[[BgZ:V2.0_Kwalificatie_beta|Kwalificatie BgZ MSZ 2.0.0-beta.1]]

==Historie==
*[[BgZ:Archief|BgZ MSZ Archief]]

Bestand:2024 09 25 BgZ msz Activity Diagram UseCase2.png

2024-09-25T08:43:14Z

Gabriel Hopmans:

Bestand:2024 09 25 BgZ msz Activity Diagram UseCase1.png

2024-09-25T08:41:50Z

Gabriel Hopmans:

Bestand:900px-2024 09 25 BgZ msz Activity Diagram UseCase2.png

2024-09-25T08:20:10Z

Gabriel Hopmans: MSZ-174 in de activity diagram use case 2 is de term "verwerken" vervangen door "overnemen"

== Beschrijving ==
MSZ-174 in de activity diagram use case 2 is de term "verwerken" vervangen door "overnemen"

Bestand:900px-2024 09 25 BgZ msz Activity Diagram UseCase1.png

2024-09-25T08:18:16Z

Gabriel Hopmans: /* Beschrijving */

== Beschrijving ==
MSZ-174 in de 2 activity diagrams use cases is de term "verwerken" vervangen door "overnemen"

Bestand:900px-2024 09 25 BgZ msz Activity Diagram UseCase1.png

2024-09-25T08:17:26Z

Gabriel Hopmans: MSZ-174 in de 2 activity diagrams use cases is de term verwerken vervangen door ontvangen

== Beschrijving ==
MSZ-174 in de 2 activity diagrams use cases is de term verwerken vervangen door ontvangen

Landingspagina BgZ

2024-09-12T12:27:10Z

Gabriel Hopmans: Toevoeging Bgz msz testscripts 2.0

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.3_Testscripts|Testscripts BgZ msz 1.2.3]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

====In ontwikkeling====

[[BgZ:V2.0_Testscripts|Testscripts BgZ msz 2.0]] (per 12 september 2024)

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.2]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

====In ontwikkeling====

[[BgZ:V2.0_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 2.0]] (per 12 september 2024)

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-09-12T12:23:39Z

Gabriel Hopmans: /* In ontwikkeling */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.3_Testscripts|Testscripts BgZ msz 1.2.3]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.2]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

====In ontwikkeling====

[[BgZ:V2.0_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 2.0]] (per 12 september 2024)

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-09-12T12:23:24Z

Gabriel Hopmans: Nieuw kwalificatiescript voor 2.0

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.3_Testscripts|Testscripts BgZ msz 1.2.3]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.2]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

====In ontwikkeling====

[[BgZ:V2.0_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 2.0]] (per 12 september 2024)
https://informatiestandaarden.nictiz.nl/index.php?title=BgZ:V2.0_Kwalificatie

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-09-12T12:20:39Z

Gabriel Hopmans: /* Testscripts BgZ medisch-specialistische zorg */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.3_Testscripts|Testscripts BgZ msz 1.2.3]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.2]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-09-12T12:08:35Z

Gabriel Hopmans: MSZ-179 kwalificatiescript : Aanpassingen test- en kwalificatie-script tbv nieuwe fictieve BSN's en nieuwe links op landingspagina plaatsen

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====

[[BgZ:V1.2.3_Testscripts|Testscripts BgZ msz 1.2.3]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.2]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-09-12T11:49:27Z

Gabriel Hopmans: https://nictiz.atlassian.net/browse/MSZ-179 kwalificatiescript : Aanpassingen test- en kwalificatie-script tbv nieuwe fictieve BSN's en nieuwe links op landingspagina plaatsen

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.2_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.2]] (per 12 september 2024)

Eerdere versies zijn te vinden onder archief.

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-07-11T09:55:38Z

Gabriel Hopmans: /* In ontwikkeling */ TO verwijzing naar 2.0

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-07-11T09:37:16Z

Gabriel Hopmans:

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

===Archief===

Oude versies

[[BgZ:Archief|Bgz msz Archief]]

Landingspagina BgZ

2024-07-11T09:35:30Z

Gabriel Hopmans: Onder actueel de 1.1 versie opgenomen en 1.0 naar archief

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.1]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.1_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.1]]

====In ontwikkeling====
[[BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

===Archief===

Oude versies

[[BgZ:Archief]]

Landingspagina BgZ

2024-07-08T13:22:43Z

Gabriel Hopmans:

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.0]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.0]]
new https://informatiestandaarden.nictiz.nl/wiki/BgZ:V1.1_BgZ_2017_Technical_IG

====In ontwikkeling====
[[BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====

Work in progress:
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

===Archief===

Oude versies

[[BgZ:Archief]]

Landingspagina BgZ

2024-07-08T06:34:22Z

Gabriel Hopmans: /* Archief */

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.0]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.0]]

====In ontwikkeling====
[[BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====

Work in progress:
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

===Archief===

Oude versies

[[BgZ:Archief]]

Landingspagina BgZ

2024-07-08T06:33:54Z

Gabriel Hopmans:

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.0]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.0]]

====In ontwikkeling====
[[BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====

Work in progress:
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

===Archief===

Oude versies
[[BgZ:Archief]]

Landingspagina BgZ

2024-07-08T06:33:12Z

Gabriel Hopmans: back to top functionaliteit en hoofdstuk Archief

<span id="BackToTop"></span>
<div class="noprint" style="background-color:#FAFAFA; position:fixed; bottom:2%; right:0.5%; padding:0; margin:0;">
[[#BackToTop|Back to Top]]
</div>


__NUMBEREDHEADINGS__
==Basisgegevensset zorg==
Deze pagina biedt een overzicht van de diverse publicaties rond de BgZ.

Zie voor meer informatie over de BgZ: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset zorg]

==MedMij==
In MedMij wordt de BgZ gebruikt om het mogelijk te maken het raadplegen van de Basisgegevensset Zorg in een persoonlijke gezondheidsomgeving mogelijk te maken.

Zie de [[MedMij:Landingspagina_MedMij|Landingspagina MedMij]] voor details over de BgZ in MedMij.

===Functioneel ontwerp BgZ MedMij===
* [[MedMij:V2020.01/OntwerpBGZ_2017|MedMij Functioneel Ontwerp BgZ]]

===Technisch ontwerp BgZ MedMij===
* [[MedMij:V2020.01/FHIR_BGZ_2017|MedMij FHIR Implementation Guide BgZ]]

==Medisch specialistische zorg==
De informatiestandaard voor de uitwisseling tussen zorgverleners in de medisch specialistische zorg.

===Functioneel ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_MSZ_Informatiestandaard|Functioneel ontwerp BgZ medisch-specialistische zorg 1.0]]

====In ontwikkeling====
[[BgZ:V2.0_Ontwerp_BgZ_MSZ|Functioneel ontwerp BgZ medisch-specialistische zorg 2.0 alpha]]

===Technisch ontwerp BgZ medisch-specialistische zorg===

====Actueel====
[[BgZ:V1.0_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 1.0]]

====In ontwikkeling====
[[BgZ:Vissue-NICTIZ-14348_BgZ_2017_Technical_IG|BgZ medisch-specialistische zorg Technical Implementation Guide 2.0 alpha]]

===Testscripts BgZ medisch-specialistische zorg===

====Actuele testscripts====

Work in progress:
[[BgZ:V1.2.2_Testscripts|Testscripts BgZ msz 1.2.2 ]]

===Kwalificatiescripts BgZ medisch-specialistische zorg===

====Actueel====

[[BgZ:V1.2.1_Kwalificatie|Kwalificatie BgZ medisch-specialistische zorg 2017 1.2.1]]

====Archief====

Oude versies
[[BgZ:Archief]]