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

Logical Models

The common Belgian Logical Models - these can be mapped to KMEHR and FHIR

Logical Model Care Team	Care Team logical model
Logical Model Communication	Communication / Diary Note logical model

Data Types

Specific Belgian data types

Belgian Address	Belgian Address
String wih max 320 characters	String wih max 320 characters

Core Profiles

Core resources to be reused in other resources

BE Patient profile	Core Belgian Patient profile
BE Practitioner Role profile	Core Belgian Practitioner Role profile
BE Practitioner profile	Core Belgian Practitioner profile
Organization core BE profile	The Core BE profile for Organization

Communication

Communication and Care Coordination

Communication Profile	Communication / Diary Note profile
Care Plan profile	Care Plan profile
Care Team profile	Care Plan profile

Conditions

Resource profiles defined for conditions

Allergy Intolerance core BE profile

The Core BE profile for Allergy Intolerance

Terminology

Terminology resources - ValueSets and CodeSystems

ValueSet - CommunicationTopic	The values for communication topic
CodeSystem - CommunicationTopic	The values for communication topic
ValueSet - Contact Person	The values for Contact Person type
CodeSystem - Contact Person	The values for Contact Person type
ValueSet - Causative Agent	The list of causative agents
ValueSet - Risk Manifestation	The values for Risk Manifestation
ValueSet - Civil State	The values for Civil State
CodeSystem - Civil State	The official values for Civil State
CodeSystem - Healthcare Party	The values for healthcare party types

Capability Statements

Capability Statements

Communication Apps	Capability Statement (requirements) for systems implementing the Communication client
Communication Server	Capability Statement (requirements) for servers implementing the Communication features

Other Examples

Examples of resources defined elsewhere

Dina	Dina
Condition - Pia diabetes	Patient Pia has diabetes
Condition - Pia loneliness	Patient Pia feels lonely
Condition - Pia's surgery recovery	Patient Pia had a surgery and needs to recover
Condition - Pia depression	Patient Pia has a depression

Structures: Resource Profiles

These define constraints on FHIR resources that need to be complied with by conformant implementations

StructureDefinition/be-observation

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

StructureDefinition/be-provenance

Belgian federal profile for a provenance. Note this profile does not introduce any changes from the base profile but has been created to mark its importance, specifically when FHIR is used in a non-document approach. General use case remarks: 'Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource.' (cfr. the HL7 base specifications) According to the FHIR specifications, the provenance resource SHALL only be provided when no other resource already plays this role: for a Patient it SHOULD be its managing organization, provenance of an Observation SHOULD be its performer, provenance of an AllergyIntolerance SHOULD be its recorder. 'Many other FHIR resources contain some elements that represent information about how the resource was obtained, and therefore they overlap with the functionality of the Provenance.' Special remarks for KMEHR users: The FHIR Provenance resource in general refers to an entity that had something to do with the creation or updating of something else. In a KMEHR context, this is somewhat different – as it is ‘XML document’ based, each KMEHR message has an 'author' element that is responsible.

Structures: Data Type Profiles

These define constraints on FHIR data types that need to be complied with by conformant implementations

StructureDefinition/be-observationcodeableconcept

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 that need to be complied with by conformant implementations

StructureDefinition/iso21090-ADXP-houseNumber	The number of a building, house or lot alongside the street. Also known as "primary street number". This does not number the street but rather the building.
StructureDefinition/iso21090-ADXP-postBox	A numbered box located in a post station.
StructureDefinition/iso21090-ADXP-streetName	streetName.
Human Language of the item	The Human Language of the item.
Birth Place	The registered place of birth of the patient. A sytem may use the address.text if they don't store the birthPlace address in discrete elements.
Birth Time	The time of day that the Patient was born. This includes the date to ensure that the timezone information can be communicated effectively.
nationality	The nationality of the patient.

Terminology: Value Sets

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

ValueSet/be-allergyintolerancecode	Codes as communicated by NIHDI and the FOD Terminology Center differentiating types of allergy intolerance codes. This valueset supports the Belgian federal FHIR profiling effort.
ValueSet/be-exposureroute	Codes to illustrate differentiating types of exposure route. This valueset supports the Belgian federal FHIR profiling effort.
ValueSet/be-noallergy	Codes as communicated by the FOD Terminology Center differentiating types of no allergies. This valueset supports the Belgian federal FHIR profiling effort.

Terminology: Code Systems

These define new code systems used by systems conforming with this implementation guide

CivilState	Civil state in Belgium.
ContactPerson	Contact person in Belgium.
FedCountry	FHIR code system definition for country codes as they are described on https://www.ehealth.fgov.be/standards/kmehr/en/tables/fedict-country-codes

Terminology: Naming Systems

These define identifier and/or code system identities used by systems conforming with this implementation guide

NamingSystem/be-cbe	BCE/KBO
NamingSystem/be-ehp	EHP
NamingSystem/be-nihdi	RIZIV/INAMI
NamingSystem/be-ssin	NISS/INSZ

Example: Example Instances

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

Patient Pia	Patient Pia
Dr. Dragon	Dr. Dragon
Dr. David	Dr. David
Christa	Christa
Nurse Nathalie	Nurse Nathalie
Nurse	Role - Nurse in Gent
Diensten Gent	Diensten Gent
DZOP	DZOP
Communication example 1	New message from DZOP to nurse
Communication example 2	Long message - part 1
Communication example 3	Long message - part 2
Communication example 4	Long message - part 3
Communication example 5	Send notice / question
Communication example 6	Reply to question
Communication example 7	Send notification
Communication example 8	Send reminder
Communication example 9	Send attachment
Communication example 10	Forward existing attachment
Communication example 11	High-priority notification
Care Team Pia	The proposed Care Team for Pia
Care Team Pia	The Care Team assigned to patient Pia
Care Team Pia - doctors only	Care Team assigned to Pia - physicians sub-team
Care Team Pia - nurses only	Care Team assigned to Pia - Nurses sub-team
Care Plan Pia - initial nurse visit	The Care Team created by the physician as a placeholder for the nurse appointment
Care Plan Pia - details planned by nurse	The Care Team created by the system with the details for the nurse appointment
Care Plan Pia - details scheduled	The Care Team created by the nurse with the detailed activities for diabetes, loneliness and depression
Appointment suggested by the GP	Appointment request to see the nurse for planning, during the week
Appointment scheduled	Appointment scheduled between nurse and patient
Photo	Photo