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: Logical Models

These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.

BeClinicalObservation Model

Clinical Observation logical model
BodySite Model

Body site model

Structures: Resource Profiles

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

BeAppointment

Placeholder profile for contextualising the FHIR resource
BeCarePlan

Placeholder profile for contextualising the FHIR resource
BeClinicalImpression

Placeholder profile for contextualising the FHIR resource
BeClinicalObservation

Belgian federal profile for a clinical observation.
BeEncounter

Placeholder profile for contextualising the FHIR resource
BeGoal

Placeholder profile for contextualising the FHIR resource
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.
BeProcedure

Placeholder profile for contextualising the FHIR resource
BeQuestionnaireResponse

Placeholder profile for contextualising the FHIR resource
BeScoreResult

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

Placeholder profile for contextualising the FHIR resource

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.

BeExtBodyTopography

Describes the location or relative position on the body, such as superior/inferior, medial/lateral or internal/external.
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.

BeVSBodyTopography

Body topography value set - describes the location or relative position on the body (e.g., superior/inferior, medial/lateral, internal/external)
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