Guidance

As mentioned supra, the Belgian federal profiling effort considers all published rules or constraints defined by HL7 on the FHIR resources strictly as an integral part of the standard and as such, they SHALL be followed unless otherwise defined.

Any guidance presented in this guide is not meant as an exhaustive description of the FHIR standard. Rather, the guidelines presented here list some specific points of attention.

Unless stated otherwise, we consider the mapping between KMEHR elements and the corresponding elements in FHIR resources to be overall self-evident. Any mapping initiative SHOULD consider the fact the approach of information in a KMEHR element as part of an XML document is fundamentally different from a modular FHIR resource.

Some particularities in this context are described in the definitions or comments within the artefacts published in this guide when deemed necessary. Note the direction in this is how to functionally express that what is in KMEHR in FHIR, not the other way around. Attention points that could not directly be incorporated in the seperate artefacts follow here.

As the FHIR specification is very developer friendly, there will be no public delivery of FHIR validation or visualisation tools by the eHealth Platform. Developers are encouraged to enjoy the speed and abundance of the existing FHIR eco system, which existence is indeed one of the rationales behind the choice for FHIR.

As a general principle for implementers, please note Postel's Law is quoted on the HL7 FHIR pages.

Use of extensions

“Note that, unlike in many other specifications, there can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core simplicity for everyone.”

The FHIR standard has a strict way to define extensions in resources.This is the only way to define extensions. An implementer SHALL take extra note of the rules concerning modifier extension.

When going beyond the profiles in this guide, a project SHALL at least try to express its data using the bare FHIR standard and adapt its business rules accordingly.

When an extension is needed and there is already an extension: this existing extension SHALL be used. In general, Belgian profiling on resources will endeavour to – when needed – only use the extensions already defined by HL7. In the Belgian profiling documentation, some available standard HL7 extensions of certain resources are recommended.

Valuesets binding

The concept of valueset binding is extremely important in the FHIR specification. The FHIR standard defines different levels of recommendation/ obligation towards the use of valuesets. They are defined on the pages of HL7 but are partly copied here for easy reference.

Almost all the elements that have a coded data type are bound to a value set. The bindings are associated with various degrees of flexibility as to how closely the value set SHALL be followed:

Important note: there can be differences concerning the precise conformance of ‘required’ and ‘extensible’ depending to which datatype they are applied. Consult the HL7 pages for extensive information.

SNOMED-CT usage

As SNOMED-CT is the preferred coding in the Belgian context and supported by the FPS Health, it SHALL be clear there are some strict rules concerning its usage in a FHIR context as defined by the FHIR specifications and they can be found on the HL7 pages.

This page does not aim to be exhaustive concerning the use of SNOMED-CT in FHIR but only lists some attention points that are in those specifications.

• Only SNOMED-CT Concept ID’s and SNOMED-CT expressions are valid in FHIR.
• The HL7 datatypes description contains some examples of SNOMED-CT expressions and how to use it in combination with other coding systems.
• Besides the pages describing specific SNOMED-CT usage, implementers SHALL also take note of the recommendations concerning SNOMED-CT use in the Observation resource, in particular, the different patterns that are described.

Period

Period is a FHIR field and datatype that is often used in FHIR to describe the period of validity of something. Depending on the information available, the period can include a start dateTime and/or an end dateTime.

Mostly the period is an optional item but in general, it is good practice, RECOMMENDED to add it when available.

Where it is specifically of interest to add it, it will be mentioned in the be- documentation.

Canonical Identifiers

FHIR resources often contain canonical identifiers. This datatype uses an URI to refer to the used system. Note when these take the form of a URL they are not by definition resolvable. Specific URIs to use in Belgian profiles are explained in the profiles and a general overview can be found here: oid-overview.

Example:
To refer to a number of the national registry:
<identifier>
<use value="official"/>
<system value="https://www.ehealth.fgov.be/standards/fhir/NamingSystem/ssin"/>
<value value="7031966696"/>
</identifier>

Special Remarks for KMEHR users:
Note there is no S=’LOCAL’ way in FHIR. A local system will be identified by its own unique URI.

Textual and parts/structured information

A narrative SHOULD be included in resource instances. When doing so, the guidelines of the HL7 FHIR specification SHALL be followed strictly.

ContactPoint

Notably used in the Patient and Practioner resource.

Special remarks for KMEHR users:
This information is typically retrieved in the KMEHR element <telecom>. That element uses both KMEHR tables CD-TELECOM (in its version 1.0) and CD-ADDRESS (in its version 1.1) to describe the actual telecom value.

Please take extra note of the accepted range of FHIR values in the ‘system’ and ‘use’ fields as FHIR uses its own tables to express this content. Further information about the functional meanings concerning the FHIR valueset can be found on its official page.

Take extra note of the way a mobile phone is expressed in KMEHR vs. FHIR.

HumanName

Special remarks for KMEHR users:
In a KMEHR message, a human name is typically composed of one or more <firstname> elements and one <familyname> element. In the FHIR datatype HumanName, it is possible to map this using corresponding elements ‘given’ and ‘family’.

Developers SHOULD take notice typical applications used to send information in a KMEHR context are centered around the approach of one familyname and one or more given names

When needed, the more elaborate possibilities available in the HumanName can be leveraged. Note the HumanName.use is a required element. Typically the name that was used in KMEHR would be ‘official’. At least a HumanName with official use SHOULD be provided.

Address

When needed in bilingual settings, an address MAY repeat using the standard HL7 extension for language.Note the HL7 specification points to the ‘text’ element as the most important element ‘to define what is printed on the envelope.For this purpose, as it is of the FHIR datatype ‘string’, it may contain some special characters like a carriage return.

It is RECOMMENDED to also use the available elements to model the address in a structured way. (These are available in the BeAddress profile in this guide as also already used in the Patient resource and others.)

Note: if it is needed to express the same address in different languages: the entire Address element SHALL repeat with each time the language extension on its highest level within Address. This is primarily meant for use cases that actually involve addresses that exist in multiple languages (e.g. in the bilingual environment of Brussels-Capital Region) (also available in the BeAddress profile)

Special remarks for KMEHR users:
Note when Address.use and Address.type are used they SHALL use the FHIR defined valuesets as per their required binding level in the FHIR specification. In a KMEHR address, the use was defined by CD-ADDRESS but those values can be found in the FHIR valueset. Cfr. table infra.

Note there is not a specific FHIR value for care address – it might be defined in a future iteration or the FHIR ‘temp’ value can be used. In KMEHR, an address might be expressed using free text or a totally structured approach where the streetname and housenumber are put in separate fields. The structural approach is RECOMMENDED in FHIR using the streetname/number/box HL7 extensions defined in BeAddress.

Note the FHIR address also allows to optionally define whether the address is a physical, postal or ‘both’ address using the Address.type field.

Country codes

Concerning the codification of the country, the FHIR specification defines its country field as a string and suggests using a ISO 3166 2 or 3 letter codes.

As that 2-letter format is also the standard in a KMEHR address, it is hence RECOMMENDED to codify the country in the same way as in KMEHR.

CodeableConcept

Clinical information is typically expressed using some form of coded content and very often the FHIR datatype ‘CodeableConcept’ is used for this. “It is one of the most common patterns in healthcare data. A typical use of CodeableConcept is to send the local code that the concept was coded with, and also one or more translations to publicly defined code systems such as LOINC or SNOMED CT. Sending local codes is useful and important for the purposes of debugging and integrity auditing.” Equally important in this way, it is RECOMMENDED to add display values when sending codes.

Using UserSelected Boolean, it is possible to clarify which code was actually chosen by the user when multiple codes are sent. It is RECOMMENDED to use this Boolean.

Please note that although in some profiles only ‘0..1’ ‘CodeableConcept’ is mentioned in the structure, this datatype actually contains possibilities to use more codes to define one concept. Refer to the official HL7 specification for further examples.

Special remarks for KMEHR users:
In many KMEHR messages there is the need to describe one concept with multiple coding systems. In KMEHR this is done by using multiple <cd> elements. In a FHIR profile, it will be very common to find the datatype to use for this is the Codeable Concept.

Note there is no S=’LOCAL’ way in FHIR. A local system will be identified by its own unique URI.