BgZ:V1.0 BgZ 2017 Technical IG: verschil tussen versies
| Regel 38: | Regel 38: | ||
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). | 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). | ||
====Subject==== | ====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 stored, though exchange formats (certainly FHIR) may require the Patient resource to be part of exchanged data. | + | 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. |
| + | |||
====Author and Information Source==== | ====Author and Information Source==== | ||
For almost all records either author or information source, or both, are 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, an Author is more relevant. 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 Author AND Information Source, or that the Patient is Author AND Information Source of an Alcohol Use statement. Since the underlying exchange standards do not always clearly distinguish Author and Information Source (FHIR Observations have a single 'performer' which can be a Patient or a Professional) the distinction may not always be relevant. | For almost all records either author or information source, or both, are 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, an Author is more relevant. 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 Author AND Information Source, or that the Patient is Author AND Information Source of an Alcohol Use statement. Since the underlying exchange standards do not always clearly distinguish Author and Information Source (FHIR Observations have a single 'performer' which can be a Patient or a Professional) the distinction may not always be relevant. | ||
Versie van 4 dec 2021 11:19
|
|
This version is not final yet. Do not use. |
1 Introduction
TODO
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 Use cases
4 Metadata
The functional description requires metadata for the BgZ. This chapter outlines the technical implementation of those metadata.
4.1 Document metadata
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
For almost all records either author or information source, or both, are 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, an Author is more relevant. 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 Author AND Information Source, or that the Patient is Author AND Information Source of an Alcohol Use statement. Since the underlying exchange standards do not always clearly distinguish Author and Information Source (FHIR Observations have a single 'performer' which can be a Patient or a Professional) the distinction may not always be relevant.
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.
| Required |
|
|---|---|
| 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. |
| 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 | Patient OR patient's authorized representative | Patient | Patient OR patient's authorized representative |
| NL-CM:7.15.1 | Wilsverklaring | AdvanceDirective | Required | LivingWillDate | Patient OR patient's authorized representative | 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 | Required | Patient | ? |
| NL-CM:5.1.1 | Probleem | Problem | Required | ProblemStartDate | Required | Patient | Optional |
| NL-CM:7.8.1 | Woonsituatie | LivingSituation | Optional | Not Relevant | Not Relevant | Patient | Not Relevant |
| NL-CM:7.4.1 | DrugsGebruik | DrugUse | Required | StartDate | empty OR equal to Source | Patient | Required |
| NL-CM:7.3.1 | AlcoholGebruik | AlcoholUse | Required | StartDate | empty OR equal to Source | Patient | Required |
| NL-CM:7.2.1 | TabakGebruik | TobaccoUse | Required | StartDate | empty OR equal to Source | 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 | Prescriber::HealthProfessional | Patient | Optional |
| NL-CM:9.8.20132 | Toedieningsafspraak | AdministrationAgreement | Required | AdministrationAgreementDateTime | Supplier::HealthProfessional | Patient | Optional |
| NL-CM:9.11.21338 | MedicatieGebruik | MedicationUse2 | Required | MedicationUseDateTime | Prescriber::HealthProfessional | Patient | Required |
| NL-CM:10.1.1 | MedischHulpmiddel | MedicalDevice | ProductID | StartDate | HealthProfessional | Patient | Optional |
| NL-CM:11.1.1 | Vaccinatie | Vaccination | ProductCode+VaccinationDate | VaccinationDate | Administrator::Healthprofessional | Patient | Optional |
| NL-CM:12.4.1 | Bloeddruk | BloodPressure | BloodPressureDateTime | BloodPressureDateTime | Required | Patient | Optional |
| NL-CM:12.1.1 | Lichaamsgewicht | BodyWeight | WeightDateTime | WeightDateTime | Required | Patient | Optional |
| NL-CM:12.2.1 | Lichaamslengte | BodyHeight | HeightValue OR HeightDateTime | HeightDateTime | Required | Patient | Optional |
| NL-CM:14.1.1 | Verrichting | Procedure | Required | ProcedureStartDate | Performer::HealthProfessional | Patient | Requireduired when performer is not known |
| NL-CM:15.1.1 | Contact | Encounter | ContactType + StartDateTime | StartDateTime | ContactWith::HealthProfessional | Patient | Not Relevant |
| NL-CM:17.1.1 | Zorgverlener | HealthProfessional | HealthProfessionalIdentificationNumber | Not Relevant | Not Relevant | HealthProfessional | Not Relevant |
4.3 Persistent identifiers
5 FHIR profiles
The FHIR profiles defined for MedMij are also used for the BgZ.
6 CDA templates
The following CDA templates are used for the BgZ.