HL7 BE Laboratory WG Implementation Guide
1.0.1 - STU
HL7 BE Laboratory WG Implementation Guide
1.0.1 - STU
HL7 BE Laboratory WG Implementation Guide, published by eHealth Platform. This guide is not an authorized publication; it is the continuous build for version 1.0.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-be/lab/ and changes regularly. See the Directory of published versions
Contents:
This Guidance page aims to clarify the definition of the Belgian laboratory result. It concerns the construction of a laboratory report in the HL7 FHIR format.
Examples are sometimes given in JSON or XML format but it SHALL be understood all structures can be expressed in both as per the FHIR standard.
The text here does not aim to explain the HL7 FHIR standard as such nor does this guide aim to explain all the possibilities of the HL7 FHIR standard. For any exhaustive overview of the FHIR standard, the pages by HL7 are considered sufficient.
Instead, the focus of this guide is to give as pragmatic and concise as possible some extra pointers needed to create a valid HL7 FHIR laboratory result concerning a human patient in the Belgian context. The reader of this text shall take note of the FHIR artefacts that are also included in this Implementation Guide. The pointers given on this page cannot be fully understood without them.
Parts of constructing the laboratory report that are considered self-evident when examining the FHIR resources are not repeated here.
Values are always expressed with the 'full stop' or point (.) as decimal mark. Commas SHALL NOT be used to make numbers easier to read. (e.g. ten thousand is always written as '10000' – never as '10,000' or '10.000')
The HL7 FHIR message is considered to be UTF-8. It is RECOMMENDED to declare the use of UTF-8 at the top when sending FHIR as XML.
The different bindings with codes SHALL be examined when implementing the laboratory report. Specifically the use of codes to express the observations as expressed on this page infra SHALL be strictly followed. As a general back-up rule, whenever the laboratory does use a propriety code (e.g. to express a bodysite), a .text element SHALL always be included explaining the code.
The marking of an element as 'mustSupport' might be a new concept when one is new to HL7 FHIR.
As expressed in the HL7 specifications, this marking actually is a functional concept more then it is used in a purely technical validation: "[…] mustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way."
That is indeed the way this marking SHALL be understood in the profiles in this guide: elements marked mustSupport might provide meaningful information when produced or consumed and these parties SHALL deal with it in a meaningful way. Note a mustSupport marking does not mean the element is mandatory – when that is the case, it is of course expressed in the cardinality.
A FHIR artefact to start the workflow with the order has also been created. As this builds on a base structure that is also proposed for other referral prescriptions in Belgium, it is currently published within a different Implementation Guide.
The ordering profile starts from the base FHIR resource 'serviceRequests'. More details:
The content of the report is described in detail in the profiles. This chapter highlights some general attention points in the structure.
The profile defines cardinalities, preferred codesystems etc. As usual in the FHIR standard, it is equally important to take note of the different descriptions explaining the elements in the profile. These descriptions contain information that would otherwise by typically found in a cookbook explaining a technical structure element by element.
The main FHIR resource to express the laboratory report is the DiagnosticReport. A Belgian profile has thus been created to use this resource in the intended fashion.
This DiagnosticReport is the 'organizer' of the report. It forms the high level structure around all the actual concrete information in the laboratory report e.g. the actual observations, the specimen, the patient etc.
The most important content within the DiagnosticReport is expressed using the FHIR resources Observation and Specimen. Both have a specific Belgian profile to use in the DiagnosticReport.
Unless the specimen is explicitly clear from the used LOINC code it SHALL be available in the report. This means the specimen type itself but also the other functionalities of the Specimen resource SHALL be leveraged when needed such as extra information about where the specimen was taken (e.g. taken from left or right elbow).
If the Observation is an observation executed by an external laboratory, or the observation is accredited, this MAY be expressed by an unstructered remark in Observation.note. This is information for the human reader of the report only.
If an Observation is expected to contain actual data (i.e. it is an observation that is not used to structure the report (e.g. title,...)), but the result is missing for some reason, the result SHALL never be empty. If there is no result, then the result SHALL contain a language specific text that indicates the reason of the missing result. e.g. result pending, sample not received. In addition, the .dataAbsentReason field can be used.
The type of the laboratory report is indicated on 2 levels: Diagnostic.report.coding and composition.type. Anatomical pathology results and laboratory results can be part of 1 lab report. On both levels, the LOINC code "Laboratory Report" 11502-2 will be used.
As FHIR provides different resources, the DiagnosticReport will reference many other FHIR resources such as Patient, Practitioner, Specimen etc.
FHIR allows for multiple ways to reference other resources. For example, these other resources can be referenced using a URL to a server or they can be added in a bundle together with the DiagnosticReport to have everything available in one JSON or XML.
On the high level of the diagnosticReport, there is the possibility to a .conclusion (primitive string FHIR datatype) and/or a .conclusionCode element (CodeableConcept FHIR datatype, when needed to express using a code)
In both the important Resources Observation and Specimen there is the possibility to use the .note element (also a free text format, following the Annotation FHIR datatype.)
Implementers SHALL explicitly take note of the rules around the narrative in FHIR as explained on the pages of HL7.
More specifically, the status of the narrative SHALL be 'empty'. The narrative SHALL NOT be used to display clinical information in an official context.
A structured Belgian laboratory report means all content SHALL BE available in the structured elements. As such, a narrative with narrative-status 'additional' SHALL NOT be used. Specifically, on the level of the individual Observation resources, that 'additional' status SHALL BE avoided.
In other words, in cases where a laboratory report cannot be expressed as a structured report, the narrative SHALL NOT be used as a fallback. In that case, it is preferred the element to present the report as PDF SHALL be used and the resulting report in that case is NOT considered to be a structured Belgian laboratory report.
Every specimen is expressed as a seperate Specimen resource in FHIR.
In the DiagnosticReport.specimen element, all the specimen are referenced.
The "patient status" during collection of the specimen: sitting, lying down, standing, sober, before/after vaccination, before 1st/2nd/3rd dialysis, is considered to be not clinically relevant, and stored in specimen.note.
The actual Observations refer to these Specimen.
Naturally, the Observation resource is heavily used in the laboratory report.
It SHALL be noted, the FHIR DiagnosticReport base standard resource takes a pragmatic approach to dealing with the multiple observations.
Basically, to fully understand the DiagnosticReport and the Observation resource it is key to understand a few basic distinct ways to group observations and how they cater to different use cases:
To summarize, including 0..* Observation in a report always happens by using the first method. These Observation resources might be (relatively) simple or have a complex structure leveraging the two other methods.
An important requirement is the ability to use subtitles in the structure of the laboratory report.
This can be done in the report by leveraging the third way to use observations grouping supra. When doing this with the goal of only adding a subtitle, the CodeableConcept datatype of the .code element in the parent Observation will minimally contain the .text element.
This chapter gives a quick overview of where to find the most important time elements in a laboratory report.
The time of the prescription lives in the original ServiceRequest resource that is referenced in the DiagnosticReport.basedOn element. The time of the prescription lives in the ServiceRequest.authoredOn element.
This can be expressed in the DiagnosticReport.effectiveDateTime or DiagnosticReport.effectivePeriod element. This is overruled when this is also expressed as part of the Specimen resource that is referenced from within the diagnostic report. The Specimen.collection.collected element gives the dateTime or period of the collection.
This is part of the Specimen resource that is referenced from within the diagnostic report. The Specimen.receivedTime element gives the dateTime of reception.
This is the DiagnosticReport.issued element.
It shall be noted the DiagnosticReport, Specimen and Observation resources all have .effective and .issued elements. There is an important difference between these.
The .effective element mostly points to the time of the specific procedure or specimen collection. The .issued element really is about when this was made available to providers, typically after review and/or verification. Please refer to the detailed descriptions in the FHIR standard for further information.
When sending the laboratory report as a 'FHIR document' - which is the case in the first iteration in production when sending laboratory reports to an eHealth box, please also carefully review the guidelines in the paragraph infra at the end of this page 'Technical implementation of the specification published here'
The base FHIR resource DiagnosticReport is of the FHIR type DomainResource and as such it inherits the base FHIR resource elements. In its root, it inherits the elements defined in the base Resource FHIR datatype. This includes the Resource Metadata.
The Resource Metadata contains in its .versionId the actual version of the DiagnosticReport.
The laboratory report SHALL also identify itself using a business identifier in the DiagnosticReport. The combination of system and identifier needs to be globally unique. Typically, the laboratory assigns an identifier that will remain the same during eventual different versions.
Some extra data concerning the status of the DiagnosticReport report can be found in its .status element. This element provides the possibility to add a status like 'corrected', 'final' etc. It is noted also the Observation resources that are part of the report have in their structure each also a .status element. Naturally, the different statuses should be logical.
As described supra, the report has a status. As such, a new version of the report might be a correction. A new version is however still the same report.
For example, as the vital element of a laboratory report, the Observation, also carries a distinct status (https://www.hl7.org/fhir/valueset-observation-status.html ) It is up to a receiving consumer, when it receives a new version of a report to correctly interpret any change in statuses on an Observation. When a diagnosticReport is solicited by a party, it should always receive the most up to date version and again, it is up to the consuming party to correctly interpret statuses.
The order (ServiceRequest resource) that is referenced from the DiagnosticReport via its .basedOn element contains the time when this order was placed as well as the original order number.
It is possible for one or more of the Observations to reference a different ServiceRequest by using the .basedOn element in the Observation. This can be used e.g. if needed to explicitely state an Observation was made via a sub order. It is noted the Observation also contains the element .performer to simply specify the Observation had a different performer from the main performer referenced from the DiagnosticReport resource.
If needed to also include the report as a PDF, that is possible using the element .presentedForm. Please refer to the FHIR complex datatype 'Attachment' for further instructions how to do include this.
Naturally, the sender of the report that adds a PDF representation SHALL ensure it remains clinically logical and safe with the way the data is otherwise structurally expressed in the resource. Any other attachments, that clarify the laboraty report SHALL be added in .media . The content type of .media is not limited to PDF.
The implementer SHALL adhere to the strategy to use in the .code element as described here
The codification to be used SHALL be LOINC as per the subset defined by the FPS Health, for the majority of commonly used lab measurements and demands. This subset is available on the website of the FPS Health.
It is allowed to use multiple codes within the FHIR CodeableConcept datatype. But the code given must follow the following rules.
"code":{
"coding":[
{
"system": "http://loinc.org",
"code": "30341-2",
"display": "Erythrocyte sedimentation rate"
}
]
}"code":{
"coding":[
{
"system": "https://www.ehealth.fgov.be/standards/fhir/lab/CodeSystem/albert",
"code": "26224",
"display": "Glucose (urine 24h)"
}
]
}"code":{
"coding":[
{
"system": "OWNSYSTEM",
"code": "OWNCODE",
"display": "DISPLAYOWNCODE"
}
],
"text": "TEXTEXPLAINING"
}"code":{
"text": "TEXTEXPLAINING"
}If needed, it is always possible to add extra translations in the display using the HL7 translation extension as such
"code":{
"coding": [
{
"system": "http://loinc.org",
"code": "18723-7",
"display": "Hematology studies (set)",
"_display": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/translation",
"extension": [
{
"url": "lang",
"valueCode": "nl-BE"
},
{
"url": "content",
"valueString": "HEMATOLOGIE"
}
]
}
]
}
}
]
}
When needed to clarify a certain observation is derived from other observations, that can be done by using the .derivedFrom element within an Observation. (e.g. an observation that gives the free testosterone level and when it is needed to refer to the observations that this is derived from.)
If the Observation can only be fully expressed in preformatted text, this is NOT RECOMMENDED but possible by only providing the mininal required elements in the Observation resource and using the 'pre' tag to include this in the narrative. As such, the Observation will not contain a structured .value and the narrative will normally be marked as ''additional.'
Some LOINC codes exist that define a specific timing interval as ‘XXX’. E.g.“LOINC 16904-5 GLUCOSE^1ST SPECIMEN POST XXX CHALLENGE” but without a timing interval. If the Code needs to be 'qualified' with a relative time: use the .component structure to do this.
{
"resourceType" : "Observation",
[...]
"code" : {
"coding" : [
{
"system" : "http://loinc.org",
"code" : "53093-1",
"display" : "Glucose^post XXX challenge"
}
]
},
[...]
"valueQuantity" : {
"value" : 9.1,
"unit" : "mmol/l",
"system" : "http://unitsofmeasure.org",
"code" : "mmol/l"
},
"component" : [
{
"code" : {
"coding" : [
{
"system" : "http://snomed.info/sct",
"code" : "118578006",
"display" : "Relative time"
}
]
},
"valueQuantity" : {
"value" : 240,
"unit" : "m",
"system" : "http://unitsofmeasure.org",
"code" : "m"
}
}
]
}
[...]
As described in the example supra concerning a relative time qualifier, other ways to qualify a code also exist. Refer to the different slicings available in the BeObservationLaboratory profile in this guide for further guidance.
Note, when it is needed to include a PDF representation, there exists a separate element for that cfr. supra
If there is a need to add images in general to the report, they can be referenced from the diagnosticReport resource itself via the .media element. A typical example would be to include a scatter diagram.
Such images SHALL be available in the exchanged message itself. (Meaning the Media resource contains the full Base64 and this resource is available as seperate resource in a FHIR Bundle or as a contained resource in the DiagnosticReport.)
Images are allowed both on the Report level and the Observation level.
Use of images SHALL be done with caution towards consumers concerning possible heavy payloads.
Many elements are available within the Media resource to further define, in the below example, minimal use is made of the Media resource to only highlight the bare essentials. This limited use of this resource in this guide was a very conscious choice as it appears the Media resource is abandoned in future FHIR versions in favor of the DocumentReference resource. The impact of that will however be minimal as both use the FHIR datatype Attachment to express the actual content.
"resource" : {
"resourceType" : "Media",
[...]
"status" : "completed",
"content" : {
[This element is of the FHIR datatype Attachment]
"contentType": "image/gif",
"data": "R0lGODlhfgCRAPcAAAAAAIAAAACAAI[...]"
}
}
The HL7 pages describe how to deal with more complex antibiogram structures. In these rules, examples are given how to deal with multiple levels to model the organisms and susceptibility panels.
The 'AntibiogramAsBundleCollection' example that can be found in this guide is based on the second structure described on that page
It basically leverages the third way as described supra how to group resources:
In order to obtain a visualization that is intuitive for practioners, we suggest that microbiology results be presented as a table.
An antibiotics result can have multiple values (RIS, MIC, ETEST, AGAR). Each result SHALL be expressed as a separate observations. Create an observation for MIC, ETEST and AGAR (when available) and use the RIS as an interpretation.
If an observation only contains the RIS value as a result, then it SHALL also be present in the interpretation field. However, for the visualization in systems for practitioners, we RECOMMEND that if the RIS value and the interpretation are identical, we only show the value, to avoid visual duplication.
Link these observations using the 'observation.derivedFrom'.
Finally, use dedicated LOINC codes for the MIC, ETEST and AGAR observations. For example:
Main observation
Derived observations
Organisms are preferably expressed in SNOMED-CT as such:
"coding" : [
{
"system" : "http://snomed.info/sct",
"code" : "243301005",
"display" : "Morganella morganii"
}
]
An .identifier (SSIN if possible) SHALL be given.
If the identifier is the only information to send concerning the patient, it is allowed to use a FHIR logical reference to refer to the patient. Thus avoiding the need to include a full Patient resource or a reference to a full Patient resource on a server. A logical reference will lead to such a structure:
<subject>
<identifier>
<system value="https://www.ehealth.fgov.be/standards/fhir/core/NamingSystem/ssin"/>
<value value="79121137740"/>
</identifier>
</subject>
Some additional minimal information concerning the subject (Patient resource), besides the identifier, SHOULD however be given if available:a .name, at least one .telecom, a .birthDate and a .address. In any Patient resource, the .gender SHALL be given (but could be 'unknown'.)
An .identifier (NIHDI if possible) SHALL be given.
If the identifier is the only information to send, it is allowed to use a FHIR logical reference to refer to the laboratory. Thus avoiding the need to include a full Organization resource or a reference to a full Organization resource on a server. A logical reference will lead to a structure similar to the one described in the subject example supra.
Some minimal information concerning the laboratory (Organization resource), besides the identifier SHOULD be given: a .name, at least one .telecom and a .address.
Any accreditions of the laboratory can be added as an .identifier. For the most common case of BELAC-accreditation, a namesystem is provided. If the BELAC accreditation is mentioned, it SHALL use this namesystem.
An .identifier (NIHDI if possible) SHALL be given.
If the identifier is the only information to send, it is allowed to use a FHIR logical reference to refer to the practitioner. Thus avoiding the need to include a full Practitioner resource or a reference to a full Practitioner resource on a server. A logical reference will lead to a structure similar to the one described in the subject example supra.
Some minimal information concerning the laboratory responsible (Practitioner resource), besides the identifier SHOULD be given: a .name, at least one .telecom and a .address
An .identifier (NIHDI if possible) SHALL be given.
If the identifier is the only information to send, it is allowed to use a FHIR logical reference to refer to the practitioner. Thus avoiding the need to include a full Practitioner resource or a reference to a full Practitioner resource on a server. A logical reference will lead to a structure similar to the one described in the subject example supra.
Some minimal information concerning the laboratory responsible (Practitioner resource), besides the identifier SHOULD be given: a .name, at least one .telecom and a .address
This guide uses the artefacts and guidance as they are defined in the official federal IG as published by eHealth Platform. Implementers SHALL take note of the guidelines defined in that IG. Please take note when you are technically validating against the IG described on this page you also need that IG for the base federal profiles.
As per the FHIR standard specifications, there are multiple ways in how the report can be exchanged or requested.
The Pilot phase for this project during 2021 is elaborating possibilities.
Current expectations (at publication date of this draft IG) for the first iteration of the laboratory flows are:
IG © 2021+ eHealth Platform. Package hl7.fhir.be.lab#1.0.1 based on FHIR 4.0.1. Generated 2024-12-13
Links: Table of Contents |
QA Report |
Issues |
Version History |
