HL7 FHIR Implementation Guide: Transversal Clinical Core
1.0.1 - STU1 Belgium flag

HL7 FHIR Implementation Guide: Transversal Clinical Core, 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/core-clinical/ and changes regularly. See the Directory of published versions

Artifacts Summary

Contents:

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

BeObservation

Belgian federal profile for an observation. Initially based on the functional description of the NIHDI. As Observation is used in many instances in FHIR, please refer to the HL7 specs of the base resource for guidance around expression of actual values using UCUM, methods, location on body etc.

Special remarks for KMEHR users: The FHIR Observation resource captures many things that are in a KMEHR message structured as an ‘item’. This includes things like ‘vital signs such as body weight, blood pressure, and temperature […], personal characteristics such as eye-color […] social history like tobacco use, family support, or cognitive status […]’ ( https://www.hl7.org/fhir/R4/observation.html ) For some of these things, HL7 already has worked out profiles and they SHALL be used when such a use case is needed. Specifically, projects SHALL take note of the existing profiles described on https://www.hl7.org/fhir/R4/observation-vitalsigns.html
BeProblem

Belgian federal profile. Initially based on the functional description of the NIHDI. Defines a patient’s known problem, a diagnostic or antecedent that deserves attention.
BeScoreResult

To support the standard exchange of scores such as pain assessment scores, or risk score, etc

Structures: Data Type Profiles

These define constraints on FHIR data types for systems conforming to this implementation guide.

BeObservationCodeableConcept

This is a supporting profile, only to give guidelines how to express a few of the typical coding systems. In general, it shall be noted SNOMED-CT is the preferred national terminology. Other coding systems remain allowed or MAY be preferred in specific flows (e.g. the use of LOINC codes to express a laboratory test.)

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

BeExtLaterality

An explicit statement of laterality of a lesion, or a treatment, etc.
BeExtProblemOriginType

The type of event that triggers the problem to be evaluated - whether the problem was reported from a referring GP, etc…

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

Body Site

Body Site
Laterality

Laterality
Problem Category

Problem Category
Problem Code

Problem Code. No Belgian standardized valueset is yet defined, this is expected for a future iteration. Implementers are encouraged to use a codification system of their choosing.
Problem Origin Type

Problem Origin Type
Reaction Manifestation Code

Reaction Manifestation Code (Allergy - Immunization)
Score Category Value Set

Score Category Value Set
Score Value Set

Codes as defined by the NIHDI. Dutch translations are expected for a next release.

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

Body Site CodeSystem

Body Site CodeSystem
Problem Category

Problem Category
Problem Origin Type

Problem Origin Type
Score Category

Score Category
Score Code System

Codes as defined initially by the NIHDI. Dutch translations were not yet defined but are planned for a next release.

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

terminology-expansion