bgz:V1.1 BgZ 2017 Technical IG - Bewerkingsoverzicht

imported>Taco Spitters: Link naar landingspagina toegevoegd.

2025-05-07T12:34:00Z

Link naar landingspagina toegevoegd.

imported>Gabriel Hopmans: NICTIZ-28149 Ontbrekende FHIR queries in TO

2025-03-17T09:24:56Z

NICTIZ-28149 Ontbrekende FHIR queries in TO

imported>Gabriel Hopmans: /* Implementation technologies */

2025-03-17T09:21:33Z

‎Implementation technologies

imported>Gabriel Hopmans op 11 jul 2024 om 09:36

2024-07-11T09:36:15Z

imported>Iwo Serlie: /* Infrastructure */

2024-06-27T07:51:34Z

‎Infrastructure

imported>Iwo Serlie: /* Metadata table */

2024-06-27T07:47:36Z

‎Metadata table

imported>Iwo Serlie: /* IdentificationNumber */

2024-06-27T07:43:38Z

‎IdentificationNumber

imported>Iwo Serlie: /* Re-identification */

2024-06-27T07:40:52Z

‎Re-identification

imported>Iwo Serlie: /* Author and Information Source */

2024-06-27T07:37:53Z

‎Author and Information Source

imported>Iwo Serlie: /* Systems and system roles */

2024-06-27T07:37:34Z

‎Systems and system roles

← Oudere versie		Versie van 7 mei 2025 om 12:34
Regel 1:		Regel 1:
		+	Voor een overzicht van relevante wiki-pagina's voor BgZ-MSZ zie [[Landingspagina_BgZ]]
	__NUMBEREDHEADINGS__		__NUMBEREDHEADINGS__
	__NOINDEX__		__NOINDEX__

@@ Regel 549: / Regel 549: @@
 == FHIR Queries ==
-[https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017#PHR:_request_message FHIR Queries]
+The [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017#PHR:_request_message MedMij FHIR Queries] are also used for BgZ MSZ.
 =Infrastructure=

@@ Regel 547: / Regel 547: @@
 | {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 |}
 =Infrastructure=

@@ Regel 1: / Regel 1: @@
 __NUMBEREDHEADINGS__
 __NOINDEX__
-{{DISPLAYTITLE:BgZ medisch-specialistische zorg Technical Implementation Guide 1.1 in development}}
+{{DISPLAYTITLE:BgZ medisch-specialistische zorg Technical Implementation Guide 1.1}}
 __TOC__
 =Introduction=

← Oudere versie		Versie van 27 jun 2024 om 07:51
Regel 551:		Regel 551:
	This standard does not mandate a particular infrastructure, and therefore does not specify details for such an infrastructure.		This standard does not mandate a particular infrastructure, and therefore does not specify details for such an infrastructure.

−	~~Useful materials from other parties can be found on:~~
−	* [https://taskforce-samen-vooruit.nl/downloads/ Taskforce Samen Vooruit]
	=Release notes=		=Release notes=

@@ Regel 239: / Regel 239: @@
 | Patient
 | Required
 |-
 | '''NL-CM:10.1.1'''

@@ Regel 41: / Regel 41: @@
 The 2017 HCIM all have the following implicit Basic Elements which provide metadata:
 ====IdentificationNumber====
-Identification is usually required for deduplication and unambiguous identification of data. Most HCIMs do not provide identification, so Problems, Procedures, Medication etc. need an IdentificationNumber. Some HCIM (such as Patient) already have an IdentificationNumber, and need no additional metadata. For some (Contact Persons) use of BSN is not permitted, and providing another non-unique id is not desirable (How could one keep that consistent over organizations?) Identification only makes sense when data has a single clear origin. In some other cases, identification is of little added value. I.e. for Body Weight, the datetime when it was recorded should suffice. To provide an additional "Body Weight id" to deduplicate Body Weight records is of little added value.
+Identification is usually required for deduplication and unambiguous identification of data. Most HCIMs do not provide identification, so Problems, Procedures, Medication etc. need an IdentificationNumber. Some HCIM (such as Patient) already have an IdentificationNumber, and need no additional metadata. For some HCIMs (e.g., Contact Persons) use of BSN is not permitted. Identification only makes sense when data has a single clear origin. In some other cases, identification is of little added value. I.e. for Body Weight, the datetime when it was recorded should suffice. To provide an additional "Body Weight id" to deduplicate Body Weight records is of little added value.
 ====DateTime====
 Quite often HCIMs already have some DateTime. The relevant datetime usually is that of the event itself (say a surgery or medication administration), not of the recording of the event. For the BgZ, all relevant datetimes are already part of the HCIM. The others do not have to be provided (i.e., a Patients Contact Person carries no relevant datetime).

@@ Regel 363: / Regel 363: @@
 * MUST assign its own professional and/or organization as Information Source
 {{NoteBox|Example: a Patient is diagnosed at Hospital A by doctor X as having a Problem: Fracture of wrist, with a start date. The Patient is transferred to another hospital, and the BgZ is sent along. The Problem is there stored in the EHR with the original identifier, and doctor X from hospital A as Information Source. The Patient is treated, and the fracture is healed. Doctor Y changes the Problem to 'inactive', and adds an end date. The system in hospital B must now supply its own identifier, and record doctor Y from hospital B as Information Source. Doctor B, and hospital B are responsible for the entire new record.}}
-As of yet, HCIMs and the BgZ do not provide a reliable mechanism to record and exchange shared responsibility and treatment across organizations, and there is no way to record different individuals are responsible for different steps in the lifecycle of an HCIM. This should therefore not be attempted.
+As of yet, HCIMs and the BgZ do not provide a reliable mechanism to record and exchange shared responsibility and treatment across organizations.
 ==Provenance==

@@ Regel 51: / Regel 51: @@
 * Information Source: The person who provided the information and ensures the correctness of it. The source of information does not have to be the author of the information, who in that case is only instrumental in capturing the information.
 * Author: The person who has recorded the information.
-In the context of the BgZ, when the information source is an healthcare professional (or organization), the person who actually entered or recorded the information (data enterer, capturer) etc. is never relevant. A healthcare professional as information source is is responsible for the medical data, and the organization is responsible for the proper recording and exchange: this should never be an individuals responsibility. The only case where author can be relevant is when the patient is the source of information. In such cases, optionally, the "Patient as author" is provided, and responsible healthcare professional as Information Source.
+In the context of the BgZ, when the information source is an healthcare professional (or organization), the person who actually entered or recorded the information (data enterer, capturer) etc. is never relevant. A healthcare professional as information source is responsible for the medical data, and the organization is responsible for the proper recording and exchange: this should never be an individuals responsibility. The only case where author can be relevant is when the patient is the source of information. In such cases, optionally, the "Patient as author" is provided, and responsible healthcare professional as Information Source.
 FHIR does not always clearly distinguish Author and Information Source. FHIR Observations, for instance,  have a single 'performer' which can be a Patient or a Professional. It is often not be possible (nor needed) to exchange both Information Source and Author in FHIR. Usually the correct reading of the 'responsible person' present in FHIR is Information Source.

@@ Regel 29: / Regel 29: @@
 System roles are further defined through the Healthcare Information Exchange model of "Registratie aan de Bron" ("Register at the source").
 [[Bestand:Healthcare Information Exchange model v1.0.png|Healthcare Information Exchange model v1.0.png]]
-BgZ-compliant systems should use HCIMs with appropriate metadata, not only in exchange but also when recording and processing data. Since HCIMs do not have many mandatory items, a sparsely filled BgZ woudl easily be compliant for exchange. The need however is to be able to record, exchange and process the full HCIMs. Therefore, it is a requirement for a Storing System to register the full HCIMs, for an Exchanging System to provide the full HCIMs and for a Processing System to process the entire zib.
+BgZ-compliant systems should use HCIMs with appropriate metadata, not only in exchange but also when recording and processing data. Since HCIMs do not have many mandatory items, a sparsely filled BgZ would easily be compliant for exchange. The need however is to be able to record, exchange and process the full HCIMs. Therefore, it is a requirement for a Storing System to register the full HCIMs, for an Exchanging System to provide the full HCIMs and for a Processing System to process the entire zib.
 Further requirements are specified in: