BgZ:V1.0 BgZ 2017 Technical IG

1 Introduction

See the Functional specifcation for context.

2 Actors involved

Persons		Systems
Name	Description	Name	Description
Referring medical specialist	Medical specialist who sends a BgZ along with a referral	EHR	Electronic health record
Receiving medical specialist	Medical specialist receives a BgZ along with a referral	EHR	Electronic health record

3 Systems and system roles

System roles are further defined through the Healthcare Information Exchange model of "Registratie aan de Bron" ("Register at the source"). BgZ-compliant systems should use HCIMs with appropriate metadata, not only in exchange but also when recording and processing data. Since HCIMs do not have many mandatory items, a sparsely filled BgZ 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.

Further requirements are specified in:

• the HCIM definitions and technical artefacts
• the Qualification Scenario's
• in the Metadata section below.

4 Metadata

The functional description requires metadata for the BgZ. This chapter outlines the technical implementation of those metadata.

4.1 Document metadata

For CDA Documents, the following metadata are mandatory (i.e. must always be present in the BgZ).

• ClinicalDocument/id: the identifier of the entire BgZ document.
• ClinicalDocument/effectiveTime: the date and time the BgZ was generated.
• ClinicalDocument/recordTarget/patientRole/id: the id of the Patient who is subject of this BgZ.
• ClinicalDocument/author/assignedAuthor/representedOrganization/id: the BgZ will rarely have a human as author. Nevertheless, author is required in CDA. Multiple authors are allowed. One should be the same as the custodian for the BgZ.
• ClinicalDocument/custodian/assignedCustodian/representedCustodianOrganization/id: the organization who has generated this BgZ.

These items loosely correspond with the BasicElements:

• IdentificationNumber
• DateTime
• Subject
• Author
• Information Source

They are not the same, since the BasicElements are about HCIMs and not documents. When HCIM do not carry sufficient metadata (see: Historical and Absent Metadata below), the document metadata can provide the necessary context.

4.2 HCIM (zib) metadata

4.2.1 Basic Elements

The 2017 HCIM all have the following implicit Basic Elements which provide metadata:

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

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

4.2.1.3 Subject

Subject is always implicit in the BgZ. It is always the Patient itself, except for Contact Persons and Health Professionals/Organizations, where the entire HCIM relates to the Patient and the data items therein of course pertain to the Contact Persons and Health Professionals/Organizations in question. The subject thus does not have to be separately stored, assuming the data will be stored in a Patient Record anyway, though exchange formats (certainly FHIR) may require the Patient resource to be part of exchanged data.

4.2.1.4 Author and Information Source

The basic elements state:

• 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 CDA, there are the following header participants in a CDA Document:

• Author: A party that originates the Act and therefore has responsibility for the information given in the Act.
• DataEnterer: A person entering the data into the originating system.

Therefore, HCIM:Author corresponds more with CDA:dataEnterer and HCIM:InformationSource corresponds more with Author. Be aware of this collision of terminology!

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.

For almost all records either is relevant. Some listed exceptions are Patient, Contact Person, Payer. In other cases information which typically originates with the Patient, and which is recorded in the anamnesis, the preferred Basic Element to store the fact that the data is provided by the Patient is Information Source. When the information typically originates from a Healthcare Professional, such as a diagnosis, that professional is the Information Source. It is never required to provide both an Author and an Information Source when both are the same, i.e. it is not necessary to state that a diagnosis has the same doctor as Information Source AND Author, or that the Patient is Information Source AND Author of an Alcohol Use statement.

4.2.1.5 System Requirements for Metadata

Required	A Storing System MUST be able to persistently store these metadata item when the data originates within the organization An Exchanging System MUST be able to provide the persistent metadata items in the BgZ A Processing System MUST be able to persistently store the received metadata items A Reusing System SHOULD only display medically relevant metadata to the healthcare professional (which excludes identifiers which are not meaningful to an end user)
Optional	This is for metadata items which are not crucial to interoperability. I.e. when a measurement already has an Author, the Information Source is not relevant.
Not relevant	For certain HCIMs the metadata items are not important. I.e. for the contact persons of a Patient, it is not relevant who or when recorded this.
Named data elements	Often the metadata items from the Basic Elements are already present in the HCIM itself. In this case these data items double as metadata, i.e. there is no need for a separate metadata item. All those metadata items are considered Required.
Other / textual	On other cases textual clarification is given in the table.

4.2.1.6 Historical and Absent Metadata

For historical data, the appropriate metadata may simply no be available. In those cases those metadata items MUST NOT be exchanged, unless they are also persisted in the source system. In cases where HCIMs are received from another organization, and metadata are absent or incomplete, the metadata SHOULD NOT be exchanged when sending to yet another organization (i.e. one should not invent identifiers when one is not the original source of the data).

4.2.2 Metadata table

Metadata are often already present in the HCIMs themselves: in that case there is no need to add them to the HCIM again. In other cases, the metadata is not relevant. The table below lists the various Basic Elements against the HCIMs.

Id	Zib	HCIM	IdentificationNumber	DateTime	Author	Subject	InformationSource
NL-CM:0.1.1	Patient	Patient	PatientIdentificationNumber	DateOfBirth	Not Relevant	Patient	Not Relevant
NL-CM:1.1.1	Betaler	Payer	BankCode+AccountNumber OR IdentificationNumber+InsurantNumber	StartDateTime+EndDateTime	Not Relevant	Patient	Not Relevant
NL-CM:2.1.1	BehandelAanwijzing	TreatmentDirective	Required	VerificationDate	Optional	Patient	Patient OR patient's authorized representative
NL-CM:7.15.1	Wilsverklaring	AdvanceDirective	Required	LivingWillDate	Optional	Patient	Patient OR patient's authorized representative
NL-CM:3.1.1	Contactpersoon	Contactperson	Not Relevant	Not Relevant	Not Relevant	Contactpersoon	Not Relevant
NL-CM:4.26.1	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	Required	StatusDate	Optional	Patient	Required
NL-CM:5.1.1	Probleem	Problem	Required	ProblemStartDate	Optional	Patient	Required
NL-CM:7.8.1	Woonsituatie	LivingSituation	Optional	Not Relevant	Not Relevant	Patient	Optional
NL-CM:7.4.1	DrugsGebruik	DrugUse	Required	StartDate	Optional	Patient	Required
NL-CM:7.3.1	AlcoholGebruik	AlcoholUse	Required	StartDate	Optional	Patient	Required
NL-CM:7.2.1	TabakGebruik	TobaccoUse	Required	StartDate	Optional	Patient	Required
NL-CM:7.11.1	Voedingsadvies	NutritionAdvice	Required	Not Relevant	Optional	Patient	Required
NL-CM:8.3.1	Alert	Alert	Required	StartDateTime	empty OR equal to Source	Patient	Required
NL-CM:8.2.1	AllergieIntolerantie	AllergyIntolerance	Required	StartDateTime	empty OR equal to Source	Patient	Required
NL-CM:9.6.9580	Medicatieafspraak	MedicationAgreement	Required	MedicationAgreementDateTime	empty OR equal to Source	Patient	Prescriber::HealthProfessional
NL-CM:9.8.20132	Toedieningsafspraak	AdministrationAgreement	Required	AdministrationAgreementDateTime	empty OR equal to Source	Patient	Supplier::HealthProfessional
NL-CM:9.11.21338	MedicatieGebruik	MedicationUse2	Required	MedicationUseDateTime	empty OR equal to Source	Patient	Prescriber::HealthProfessional
NL-CM:10.1.1	MedischHulpmiddel	MedicalDevice	ProductID	StartDate	empty OR equal to Source	Patient	HealthProfessional
NL-CM:11.1.1	Vaccinatie	Vaccination	ProductCode+VaccinationDate	VaccinationDate	empty OR equal to Source	Patient	Administrator::Healthprofessional
NL-CM:12.4.1	Bloeddruk	BloodPressure	BloodPressureDateTime	BloodPressureDateTime	empty OR equal to Source	Patient	Required
NL-CM:12.1.1	Lichaamsgewicht	BodyWeight	WeightDateTime	WeightDateTime	empty OR equal to Source	Patient	Required
NL-CM:12.2.1	Lichaamslengte	BodyHeight	HeightValue OR HeightDateTime	HeightDateTime	empty OR equal to Source	Patient	Required
NL-CM:14.1.1	Verrichting	Procedure	Required	ProcedureStartDate	empty OR equal to Source	Patient	Performer::HealthProfessional
NL-CM:15.1.1	Contact	Encounter	ContactType + StartDateTime	StartDateTime	empty OR equal to Source	Patient	ContactWith::HealthProfessional
NL-CM:17.1.1	Zorgverlener	HealthProfessional	HealthProfessionalIdentificationNumber	Not Relevant	Not Relevant	HealthProfessional	Not Relevant

5 Reconciliation

Metadata provides the opportunity for reconciliation: combining patient data from multiple sources in a consistent and integrated way. This may involve:

• receiving information, such as a BgZ, from another source and integrating that in one's own EHR;
• retrieving information from multiple sources, and showing that in a consistent and unambiguous way.

Reconciliation involves the following.

• De-duplication: data item X may be available from multiple sources, and should only be shown once. De-duplication is possible through consistent identifiers across data custodians.
• Semantic interpretation: data items from multiple sources should be classified in a consistent way, which is interoperable across sources. Semantic interoperability is possible through the use of consistent classification and terminologies. The HCIMs themselves, along with "Eenheid van Taal" (Unity of Language) terminology services already provide the necessary level of semantic interoperability.
• Provenance: it should be clear which data originates where, and the original source should be traceable and (where still possible) approachable. Provenance is achieved through authorship and information source.
• Attribution: patient data is a statement: usually a fact that something is the matter about something or someone at some point in time. Subject and date/time information allow the data item to be related to the real world.

5.1 Persistent identifiers

CDA has identifiers of the following form, where root must be an oid and extension is some local string value.:

  <id extension="1A2B3C" root="2.16.840.1.113883.2.4.3.46.20"/>

FHIR has identifiers of the following form, where system is some uri and value is some local string value.:

  <identifier>
    <system value="http://www.example.org" />
    <value value="1A2B3C" />
  </identifier>

It is strongly recommended to use FHIR identifiers of the following form in the BgZ, where the oid is the same as the oid used in CDA-based exchanges. :

  <identifier>
    <system value="urn:oid:2.16.840.1.113883.2.4.3.46.20" />
    <value value="1A2B3C" />
  </identifier>

This greatly facilitates interoperability between FHIR and CDA.

5.2 Re-identification

When a record is received from another organization, it should be persisted with the identifiers of the source. However, when the record is updated, the Storing System:

• MUST issue a new Identifier, following their own identification mechanisms
• MUST assign its own professional and/or organization as Information Source

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.

5.3 Provenance

Every data item is a statement, an assertion of a fact, recorded by someone somewhere. This original source should be retained when integrating data from multiple sources. The source can be:

1. An individual as Information Source of the statement. This is the InformationSource from the zib. In CDA of FHIR this is the corresponding element when a person is populating this element. Examples:
   • a health professional makes a diagnosis
   • a patient reports alcohol and tobacco use
2. An organization as Information Source of the statement. This is the InformationSource from the zib. In CDA of FHIR this is the corresponding element when an organization person is populating this element. Examples:
   • a lab reports certain chemical or biological measurements on a specimen
3. A XIS as the information source. This is the custodian a CDA document, and the XIS from which the HCIM was retrieved in FHIR (possibly other elements are suitable, as in XDS based exchanges or FHIR Documents). in Examples:
   • a BgZ is received from a XIS, and the contact persons of the patient are listed without further author or source;
   • a record is retrieved from a XIS, and the historical problems in the problem list do not have further author or source;
   • lab results are retrieved from a XIS, but the lab where the measurements were made is not provided;

Certainly for historical data the original source of the statement often is not retained. The order above is the preferred order: i.e. when an individual is known as information source, provide that individual. In the case of an healthcare professional, provide the healthcare organization and professionals role as well. When no individual is known, use the organization. When no organization is known, use the originating XIS as source.

5.4 De-duplication

De-duplication is not always possible when receiving consecutive records with the same identifiers but different content. It may not always be obvious which of those records is the most recent one. This standard does not require specific mechanisms for de-deduplication, but suggests the following heuristics:

• when a record is received from A and B, and A is listed as the information source in both, assume the record from A to be the most recent one;
• when a record is received from A, stored, and retrieved again from A, assume the latter is most recent one;
• when a record is received from B and C, and A is listed as the information source in both, assume the most recently received record is most recent one.

A Processing System can flag such conflicting records. When in doubt, a medical professional should decide, possibly after consulting colleagues.

6 Implementation technologies

6.1 FHIR profiles

The FHIR profiles defined for MedMij are also used for the BgZ.

6.2 CDA templates

The entire publication can be found at Basisgegevensset Zorg 2017 (BgZ)

The following CDA templates are used for the BgZ 2017.

Section	Titel	Title	CDA Template
0	BgZ		Template CDA Basisgegevensset Zorg 2017 (BgZ)
1. Demografie en identificatie		Demographics and identification	CDArecordTargetSDTC-NL
	Patient	Patient
2. Financiële informatie		Financial information	BgZ2017Betaler
	Betaler	Payer
3. Behandelrestricties		Treatment Directives	BgZ2017TreatmentDirectives
	BehandelAanwijzing	TreatmentDirective
	Wilsverklaring	AdvanceDirective
4. Contactpersonen		Contact persons	CDArecordTargetSDTC-NL
	Contactpersoon	ContactPerson
5. Functionele status		Functional Status	BgZ2017FunctionalStatus
	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus
6. Klachten en diagnoses		Complaints and diagnoses	Voorgeschiedenis BgZ2017ComplaintsAndDiagnoses
	Probleem	Problem
7. Sociale anamnese		Social anamnesis	BgZ2017SocialAnamesis
	Woonsituatie	LivingSituation
	DrugsGebruik	DrugUse
	AlcoholGebruik	AlcoholUse
	TabakGebruik	TobaccoUse
	Voedingsadvies	NutritionAdvice
8. Waarschuwingen		Alerts	BgZ2017Alerts
	Alert	Alert
9. Allergieën		Allergies	BgZ2017Allergies
	AllergieIntolerantie	AllergyIntolerance
10. Medicatie		Medication	BgZ2017Medication
	MedicatieGebruik2	MedicationUse2
	Medicatieafspraak	MedicationAgreement
	Toedieningsafspraak	AdministrationAgreement
11. Medische hulpmiddelen		Medical devices	BgZ2017MedicalDevices
	MedischHulpmiddel	MedicalDevice
12. Vaccinaties		Immunizations	BgZ2017Immunizations
	Vaccinatie	Vaccination
13. Vitale functies		Vital signs	BgZ2017VitalSigns
	Bloeddruk	BloodPressure
	LichaamsGewicht	BodyWeight
	LichaamsLengte	BodyHeight
14. Uitslagen		Results	Laboratoryspecialtysection
	LaboratoriumUitslag	LaboratoryTestResult
15. Verrichtingen		Procedures	BgZ2017Procedures
	Verrichting	Procedure
16. Contacten		Encounters	BgZ2017Encounters
	Contact	Encounter
17. Zorgplan		Care plan	BgZ2017CarePlan
	OverdrachtGeplandeZorgActiviteit	PlannedCareActivityForTransfer
18. Zorgverleners		Health professionals
	Zorgverlener	HealthProfessional
	Zorgaanbieder	HealthcareProvider

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

• Taskforce Samen Vooruit