Boundaries and Relationships

Laboratory examination is an essential part of healthcare. Laboratory results serve a variety of goals, such as determining diseases and correct medication administration doses. Information standards describe how laboratory results can be exchanged safely and unambiguously between the relevant stakeholders. This implementation guide aims to establish this within the research domain of Sciensano. It has essential relationships and differences with other (international) standards that may concern the implementer. Therefore, the following sections identify related standards and try to give a high-level overview of similarities and differences with this implementation guide.

Belgium

In Belgium, the HL7 BE Laboratory WG IG, published by eHealth Platform, defines the Belgian laboratory report. This overview is based on the latest version at the time of writing: 1.0.0 - STU. It concerns the construction of a laboratory report pertaining to a patient in the Belgian context. For many elements, the HL7 BE profiles are compatible with the CBB profiles defined in this guide, especially regarding guidance on referencing and (ReTaM) codes and values in the Observation resource. There are, however, noteworthy differences:

• HL7 BE defines a mandatory report based on a DiagnosticReport, which functions as the 'organizer' of the report.
• Narratives must be set 'empty,' thereby encouraging (or trying to enforce) all information exchange to be structured. This IG uses the FHIR rules for narrative, namely they SHOULD be present.
• Performer information is (mainly) handled through the DiagnosticReport, while for the CBB profiles this is through the Observation.
  • A mandatory results interpreter (biologist) is defined that is not defined in the LaboratoryTestResult CBB.
  • The use of the PractitionerRole is not defined or encouraged. This resource is essential to fully communicate the CBB HealthProfessional information. Although this may not be a concern for the lab use case as there may not be a need to communicate roles and specialists of laboratory Healthprofessionals.
• The HL7 BE IG does not contain an explicit logical data model documenting the information requirements yet.

To conform to this IG from a HL7 BE laboratory report document viewpoint, at least the following needs adjusting:

• Replace the DiagnosticReport reference in Composition.entry with a reference to the main LaboratoryTestResult Observations.
• Move mapping from DiagnosticReport.perfomer to Observation.performer.
• Add a (fixed) Observation.category because this is mandatory by the CBB profile.
• Add the givenOrInitial in HumanName.given. The CBB requires the extension to determine if the .givencontains a given name or an initial.

Netherlands

Nictiz maintains the information standard 'Labuitwisseling'. This overview is based on the latest version at the time of writing: 3.0.0-beta. It specifies four domains, namely the exchange of LaboratoryTestResults between a laboratory organization and:

• another laboratory organization,
• a research center,
• a healthcare organization,
• the patient.

In the Netherlands, LaboratoryTestResult exchange happens primarily using HL7v2 and HL7v3. The development of FHIR implementation starts with the domains of the patient and healthcare organization.

• Exchange with patients was the first described in FHIR and is wholly based on zibs. It is being used and implemented within the MedMij framework. The described scenario is based on a search/retrieve principle by the patient.
• Exchange with healthcare organizations in FHIR is in active development. Although the functional design and zib-based data model have been published, the technical design based on FHIR is still in draft status. It defines both a scenario for sending and searching/retrieval of LaboratoryTestResults.

These 'Labuitwisseling' standards align well with this implementation guide, starting with the zibs as the base data model. The respective CBB and CBB-profile changelog describes the precise changes. Also, just like this implementation guide the focus is solely LaboratoryTestResults, and no DiagnosticReport is defined.

Germany

The German Medizininformatik Initiative has published the 'Modul Laborbefund Implementation Guide'. This overview is based on the latest version at the time of writing: 1.0.6. It contains an extensive logical information model which is also represented in FHIR. No exchange paradigm is defined yet. The language is German. Some noteworthy observations and differences:

• A DiagnosticReport is defined.
• Specimen information is not defined in FHIR on this level but may be described in use-case guides.
• Observation.value[x] supports only datatypes Quantity (using mandatory UCUM) and CodeableConcept.
• A ServiceRequest is defined but does not contain guidance for exchanging requester information.
• Observation.performer is not specified. Instead, a mandatory Observation.identifier of a particular type needs to be present that contains a reference to the identifier assigning organization.
• MustSupport flags are set.
• Refers to International Patient Summary IG (IPS) for must-support definition and LOINC codes.

Other initiatives

Other (international) initiatives that use LaboratoryTestResults in some way. This list is far from extensive and may be enriched at a later moment.

• US Core Laboratory Result Observation Profile
• Order Catalog Implementation Guide
• Clinical Research Sponsor Laboratory Semantics in FHIR Implementation Guide

Diagram of functional layering

The below diagram offers an overview of the layering of CBBs. A description of the diagram and it's three used colors:

• The blue box represent the project that form the basis for this implementation guide. More information is given in the general guidance page of the CBB implementation guide.
• The green box indicates this implementation guide that contains all the definitions for exchanging LaboratoryTestResult.
• All the grey box represent projects and use cases based the LaboratoryTestResult specs.