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

## Guidance

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.

### Conventions

#### Note on values and decimal mark

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')

#### UTF 8

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.

#### Use of codes

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.

#### mustSupport

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.

### The laboratory order

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:

- General guidance concerning the orders in Belgium and specific laboratory order guidance.
- Technical definition of the order for laboratory.
- An example for the order.

### The structure of the report: attention points

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.

#### Main FHIR resources of the report: the DiagnosticReport

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 Observation and the Specimen

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

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.

#### Referencing other FHIR resources

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.

#### General remarks on all the items

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

#### Role of the narrative in FHIR

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.

#### Specimen overview

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.

#### Grouping of observations using Observation resources

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:

1. Using the .result of the DiagnosticReport resource to reference 0..* Observation: that way multiple Observations are referenced in the root of the report. These will cater to reports that give back 0..* results without any complex structure between the results. These Observation resource might however leverage more complex structures by also following the strategy described in the following options.
2. The Observation itself may include 0..* .component elements. A component element within an Observation is a list of key/value pairs with optionally for each key/value pair a data absent reason and/or an interpretation code and/or a referenceRange. Such a list of key/value pairs is considered to be part of one Observation. A typical example is to include systolic and diastolic component observations for blood pressure measurement. "Components should only be used when there is only one method, one observation, one performer, one device, and one time."
3. The Observation may be part of a group of Observation resources. This is established by using the .hasMember in the Observation. This method is used for any parent/child relation, e.g. for a panel or battery where the panel code is given without a value in the parent Observation and the actual results are seperate Observation resources referenced from that parent Observation. Also titles and subtitles are handled this way.

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.

#### Using subtitles

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.

### How to indicate the performer

The performer of the tests (and related roles, such as the validator or the interpreter of the tests) can be indicated in several resources. This chapter deals with a clarification of these different fields.

#### The author of the composition

The mandatory BeLaboratoryReportComposition.author field SHALL contain a reference to the lab.

#### The performer of the report

The mandatory BeLaboratoryReport.performer field SHALL contain a reference to the lab.

#### The interpreter of the results in the report

The mandatory BeLaboratoryReport.resultsInterpreter field SHALL contain a reference to the biologist.

#### The performer of the observation

The BeObservation.performer field can contain a reference to an external lab, if the test was performed by a subcontracting lab.

### Important time elements

This chapter gives a quick overview of where to find the most important time elements in a laboratory report.

#### Time of the prescription

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.

#### Time of the specimen collection

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.

#### Time of the specimen reception

This is part of the Specimen resource that is referenced from within the diagnostic report. The Specimen.receivedTime element gives the dateTime of reception.

#### Time when the report is made available

This is the DiagnosticReport.issued element.

### Effective vs Issued

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.

### Versioning of reports

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.

### Relating reports (replacing, updating)

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.

### Referencing the (sub)order

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.

### Adding a PDF representation

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.

### Guidance for codes and values in the Observation resource

#### Use of Retam codes

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.

1. The actual observation is coded in LOINC (subset as defined by FPS Health)

   -     "code":{
         	"coding":[
         		{
         			"system": "http://loinc.org",
         			"code": "30341-2",
         			"display": "Erythrocyte sedimentation rate"
         		}
         		]
         	}

2. If above not possible , ALBERT codes are used (subset as defined by FPS Health)

   -     "code":{
         	"coding":[
         		{
         			"system": "https://www.ehealth.fgov.be/standards/fhir/lab/CodeSystem/albert",
         			"code": "26224",
         			"display": "Glucose (urine 24h)"
         		}
         		]
         	}

3. If above not possible,laboratory sends its own code plus obligatory a text element to further explain.

   -     "code":{
         	"coding":[
         		{
         			"system": "OWNSYSTEM",
         			"code": "OWNCODE",
         			"display": "DISPLAYOWNCODE"
         		}
         		],
         	"text": "TEXTEXPLAINING"
         	}

4. If above not possible the kind of observation is expressed only in text (allowed but not recommended)

   -     "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"
                          }
                        ]
                      }
                    ]
                  }
                }
              ]
            }

#### Derived observations

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

#### Expression of results

- Typically, values will be expressed using a certain unit. Units will be expressed using UCUM codes as per the specification. The KMEHR reference table CD-UNIT is not used. It remains technically possible to express units using a different way. However, as UCUM provides a standardized syntax to express in theory any type of exotic unit, it is HIGHLY RECOMMENDED to always use the UCUM way to express units.
- Implementers SHALL take note of the very flexible .value[x] element within the FHIR Observation resource. This allows multiple ways to express the result structurally. Each option has its own datatype. Typically, for measurements, .valueQuantity is expected to be used that leverages the FHIR Quantity datatype. For observation results that do not fall in any structured category, there is the option to use .valueString to express the result in text.
- If the FHIR datatype Quantity is used, the .code element SHALL be used. This element will also be shown by the visualizer, and not the .unit element.

#### Use of preformatted text

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

#### Relative time for challenge testing

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"
          }
        }
      ]
    }
    [...]

#### Substance amount qualifier and product name qualifier

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.

### Use of images

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.

#### Caution concerning the size of images

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[...]"
            }
          }

### Guidance for antibiogram structures

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:

- Any general Observation that is done is on the level of the report.
- If there are many cultures, you can add culture observations, which have organism observatons as members.
- For each organism there is an Observation on the level of the report, or on the level of the culture observation: the 'organism observation'
  - Every panel Observation on the organism is referenced via a .hasMember in that 'organism observation'

In order to obtain a visualization that is intuitive for practioners, we suggest that microbiology results be presented as a table.

#### Use of LOINC-codes in Antibiotic result values

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

- 18861-5 ( https://loinc.org/18861-5/ : Amoxicillin [Susceptibility] )

Derived observations

- 16-6 ( https://loinc.org/16-6/ : Amoxicillin [Susceptibility] by Minimum inhibitory concentration (MIC) )
- 6976-5 (https://loinc.org/6976-5/ : Amoxicillin [Susceptibility] by Gradient strip)
- 17-4 ( https://loinc.org/17-4/ : Amoxicillin [Susceptibility] by Disk diffusion (KB) )

#### Codification of organisms

Organisms are preferably expressed in SNOMED-CT as such:

     "coding" : [
                {
                  "system" : "http://snomed.info/sct",
                  "code" : "243301005",
                  "display" : "Morganella morganii"
                }
              ]

### Guidance for minimal information in supporting resources

#### Minimal information concerning the subject

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

#### Minimal information concerning the laboratory

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.

#### Accreditation of the laboratory

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.

#### Minimal information concerning the laboratory responsible

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

#### Minimal information concerning other healthcare parties

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

### FHIR technical implementation specifics

#### The federal IG

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.

#### Technical implementation of the specification published here

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:

- The laboratory result SHALL be send as the payload in an eHealthBox message. The message SHALL be accompanied by the custom meta data item: HC-FunctionalType='fhir-lab'. It can be accompanied by the custom meta data items: CM-GeneratingSoftware and CM-GeneratingSoftwareVersion. The payload SHALL be an immutable collection according to the 'FHIR Document' paradigm. The FHIR Document SHALL leverage the Composition profile that can be found on the artifact page in this IG. On that artifact page there is also an example of a report in this FHIR Document structure. The FHIR Document SHALL include all the referenced resources in the bundle.
- Following specific versioning guidelines SHALL be observed when leveraging the 'FHIR Document'. Implementers SHALL take note a certain status on a higher level in the bundle SHALL not logically conflict with any status given to resources in the bundle. Please also consult the document example in this guide.
  - The document identifier (mandatory). This is found in Bundle.identifier and is globally unique for this instance of the document, and is never re-used, including for other documents derived from the same composition
  - The Composition status (mandatory). This is found in Composition.status and can take the value 'preliminary', 'final', 'amended' or 'entered-in-error'. When using this for the laboratory document, this value SHALL be either 'final' or 'preliminary'.
  - The composition identifier (mandatory). This is found in Composition.identifier and is globally unique and SHALL be the same through the different versions of the document. This identifier is identical to the DiagnosticReport.identifier. These identifiers can be used for updates of the report. An example is the case where the patient of two versions of a DiagnosticReport is different. For two consecutive versions, this means that the results should be deleted from the first patient and added to the second.
    - please note it MAY be possible a FHIR document that was initially marked as 'final' is still followed up later by a new 'final' version. As such implementers SHALL take note whatever status a FHIR document has, it MAY always be replaced.
- Whenever needed to express the MIME type of a FHIR message, its formal MIME type SHALL be used which is:
  - XML: application/fhir+xml
  - JSON: application/fhir+json
- The laboratory prescription (expected for a future iteration) SHALL be send as a serviceRequest complying with the Belgian laboratory prescription profile