Active artifacts

Structures: Resource Profiles

BeAddiction A record of a patient's known, suspected or resolved addiction. This represents the addiction condition, not an addiction-related event or observation.
BeAllergyIntolerance Belgian federal profile for an allergy and/or an intolerance. Initially based on the functional description of the NIHDI.
BeCommunication This is the technical specification for the Communication resource, as it is used in Belgium. This specification is compatible with the current version of KMEHR Diary Note, namely the selection of attributes that are supported, and the maximum length of the payload (320 characters). It also relies on the foundation Belgium resources, for example the Belgian Patient, Practitioner and other resources.
BeHomecarePlan This is the profile for Care Plan in a home care setting. A Care Plan contains the activities planned and/or performed by a care team to deliver care for a particular patient, usually targeting a specific goal or condition - or a set thereof.
BeHomecareTeam This is the Belgian profile for home care team. A home care team defines the people and roles organized around a patient's care activities planned. It may also imply additional aspects such as access to information etc.
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.
BeOrganization Belgian federal profile for an organization. Initially based on the functional description of the NIHDI.
BePatient Belgian federal profile for a patient. Initially based on the functional description of the NIHDI. Special remarks for KMEHR users: following elements in KMEHR are not available in this FHIR resource. If needed, an extension can be defined in a future iteration of these specifications: the ‘deathlocation’ (location is not available but the death of the patient is expressed by either date or Boolean cfr. infra.), the ‘insurancystatus’ (covered in a seperate FHIR resource: Coverage), ‘insurancymembership’ (covered in a seperate FHIR resource: Coverage) and ‘profession’ (covered in a possible future FHIR resource: OccupationalData.)
BePatientWill Belgian federal profile for a patient will ONLY in the context of the patient will in the context of limitations to treatment, DNR etc. Initially based on the functional description of the NIHDI. This profile will in the future be also used to record agreement to participate in clinical trials etc. Any usecase around informed consent is out of scope for this profile.
BePractitioner Belgian federal profile for a practitioner. Initially based on the functional description of the NIHDI.
BePractitionerRole Belgian federal profile for a practitioner role. Initially based on the functional description of the NIHDI.
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.
BeProvenance 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.
BeScoreResult To support the standard exchange of scores such as pain assessment scores, or risk score, etc
BeVaccination Defines constraints and extensions on the immunization resource to represent an immunization event i.e. the administration of a vaccine.

Structures: Data Type Profiles

BeAddress Belgian federal profile on address, to provide the possibility in the ‘line’ element to provide a seperate streetname, housenumber and postal box. It is always RECOMMENDED to give these elements seperately.
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: Extensions

BeExtAddictionQuantifier The quantifier of the addiction - the quantity or frequency of the addiction.
BeExtAdministeredProduct The Product administered.
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...
BeExtRecorder The recorder of the information - note that this may not always be the same as the asserter - when a patient reports to a nurse and the nurse enters the data, the asserter is the patient, but the recorder is the nurse.
BeExtVaccinationConfirmationStatus How certain/reliable is the vaccination information.
BeExtVaccinationLocation Location (reference, code or text) of the vaccination.
BeExtVaccinationOriginalOrder A plan, proposal or order that is fulfilled in whole or in part by an event.

Terminology: Value Sets

BeVSAddictionCategory Addiction Category. 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.
BeVSAddictionCode Addiction 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.
BeVSAllergyIntoleranceCode 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.
BeVSBodySite Body Site Value Set.
BeVSCareLocation Care Location Value Set.
BeVSCausativeAgent Codes as communicated by NIHDI and the FPS Terminology Center differentiating types of causative agent. This valueset supports the Belgian federal FHIR profiling effort..
BeVSCivilState Codes supported by eHealth Platform differentiating types of civil state. This valueset supports the Belgian federal FHIR profiling effort. Whenever possible add a code from http://terminology.hl7.org/CodeSystem/v3-MaritalStatus for international interoperability but also use https://www.ehealth.fgov.be/standards/fhir/CodeSystem/CD-CIVILSTATE for the Belgian specific code.
BeVSContactPerson Maximum valuest to define category of a contact person, using the HL7 values and the Belgian CD-CONTACT-PERSON values.
BeVSDiaryTopic Codes supported by eHealth Platform differentiating types of communication topics.
BeVSExposureRoute Codes to illustrate differentiating types of exposure route. This valueset supports the Belgian federal FHIR profiling effort..
BeVSLaterality Laterality Value Set.
BeVSNoAllergy Codes as communicated by the FOD Terminology Center differentiating types of no allergies. This valueset supports the Belgian federal FHIR profiling effort.
BeVSPatientWillCategory Patient will category Value Set.
BeVSPatientWillCode Patient will code Value Set.
BeVSProblemCategory Problem Category Value Set.
BeVSProblemCode Problem Code Value Set. 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.
BeVSProblemOriginType Problem Origin Type Value Set.
BeVSRiskManifestation Codes as communicated by NIHDI and the FPS Terminology Center differentiating types of risk manifestation. This valueset supports the Belgian federal FHIR profiling effort.
BeVSScore Codes as defined by the NIHDI. Dutch translations are expected for a next release.
BeVSScoreCategory Score Category Value Set.
BeVSVaccinationConfirmationStatus Vaccination status Value Set.
BeVSVaccinationStatusReason Vaccination status reason Value Set - the reasons for an vaccination status - typically representing the reason why a vaccination is not performed.
BeVSVaccineAdministrationRoute Vaccine Administration Route Value Set.

Terminology: Code Systems

BeCSAlbert ALBERT Code System.
BeCSBodySite Body Site CodeSystem.
BeCSCareLocation Care Location Code System.
BeCSCivilState Civil state in Belgium Code System.
BeCSContactPerson Contact person Code System.
BeCSDiaryTopic Diary and Communication Topics Code System.
BeCSFedCountry FedICT country Code System.
BeCSHCParty Healthcare party in Belgium Code System.
BeCSPatientWillCategory Patient Will Category CodeSystem.
BeCSPatientWillCode Patient Will Directive CodeSystem. Codes as defined by the NIHDI.
BeCSProblemCategory Problem Category Code System.
BeCSProblemOriginType Problem Origin Type Code System.
BeCSScore Codes as defined initially by the NIHDI. Dutch translations were not yet defined but are planned for a next release.
BeCSScoreCategory Score Category Code System.
BeCSStatusReason Vaccination reason status Code System.
BeCSVaccinationConfirmationStatus Vaccination status Code System.
BeCSVaccineAdministrationRoute Vaccine Administration Route Code System.

Terminology: Naming Systems

BeNSCBE CBE Naming System.
BeNSCNK CNK Product Codes Naming System.
BeNSCTIExtended CTI Extended Codes Naming System.
BeNSEHP EHP Naming System.
BeNSManufacturers NProduct Manufacturers Naming System.
BeNSNIHDI NIHDI Naming System.
BeNSNIHDIOrganization Nihdi - Organization Naming System.
BeNSNIHDIProfessional Nihdi - Professional Naming System.
BeNSONEVaccinations ONE Vaccination Naming System.
BeNSSSIN SSIN Naming System.
BeNSUnadressedHealthMessageExchangePlatform UHMEP Naming System.

Example: Example Instances

Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.

Addiction 1 Addiction example based on Condition Resource
AllergyIntolerance 1 AllergyIntolerance example
AllergyIntolerance 2 AllergyIntolerance example
Bundle 1 Bundle example
CarePlan 1 The Care team created by the physician as a placeholder for the nurse appointment
CarePlan 2 The Care team created by the system with the details for the nurse appointment
CarePlan 3 The Care team created by the nurse with the detailed activities for diabetes, loneliness and depression
CareTeam 1 The proposed Care Team for Pia
CareTeam 2 The Care team assigned to patient Pia
CareTeam 3 The Care Team assigned to patient Pia
CareTeam 4 The Care team assigned to patient Pia - current
CareTeam 5 Care team assigned to Pia - physicians sub-team
CareTeam 6 Care team assigned to Pia - Nurses sub-team
Communication 1 New message from DZOP to nurse
Communication 2 Long message - part 1
Communication 3 Long message - part 2
Communication 4 Long message - part 3
Communication 5 Send notice / question
Communication 6 Reply to question
Communication 7 Send notification
Communication 8 Send reminder
Communication 9 Send attachment
Communication 10 Forward existing attachment
Communication 11 High-priority notification
Observation 1 Observation example
Observation 2 Observation example
Organization 1 Organization example
Patient 1 Patient example
Patient 2 Patient example
Patientwill 1 Patient Will example based on Consent Resource
Practitioner 1 Practitioner example
Practitioner role 1 Practitioner role example
Problem 1 Problem example based on Condition Resource
Provenance 1 Provenance example
Vaccination 1 Vaccination example based on Immunization Resource
Vaccination 2 Vaccination example based on Immunization Resource
Vaccination 3 Vaccination example based on Immunization Resource
Vaccination 4 Vaccination example based on Immunization Resource
Vaccination 5 Vaccination example based on Immunization Resource
Vaccination 6 Vaccination example based on Immunization Resource
Vaccination 7 Vaccination example based on Immunization Resource
Vaccination 8 Vaccination example based on Immunization Resource
Vaccination 9 Vaccination example based on Immunization Resource
Vaccination 10 Vaccination example based on Immunization Resource
Vaccination 11 Vaccination example based on Immunization Resource
Vaccination 12 Vaccination example based on Immunization Resource
Vaccination 13 Vaccination example based on Immunization Resource
Vaccination 14 Vaccination example based on Immunization Resource
Vaccination 15 Vaccination example based on Immunization Resource
Vaccination 16 Vaccination example based on Immunization Resource
Vaccination 17 Vaccination example based on Immunization Resource