RIZIV-INAMI Patient Record
0.1.0 - CI Build
RIZIV-INAMI Patient Record
0.1.0 - CI Build
RIZIV-INAMI Patient Record, published by RIZIV-INAMI. This is not an authorized publication; it is the continuous build for version 0.1.0). This version is based on the current content of https://github.com/hl7-be/riziv-inami/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
Allergy / Intolerance resources. These artefacts define the constraints and vocabulary necessary to record allergies and intolerances, suspected or confirmed. A few example resources and scenario demonstrate the use of these resources.
| AllergyIntolerance |
Allergy Intolerance profile |
| Example Practitioner - Dr Durant (GP) |
Dr. Paul Durant (GP) |
| Example practitioner - Dr Lenoir |
Lr François Lenoir |
| Example Patient - Noel Joyeux |
Patient Noel Joyeux |
| Example - Suspected Allergy |
Suspected Allergy to Penicillin |
| Example - Refuted Allergy |
Allergy has been refuted - confirmed as non-existent |
| Example - Allergy 1 - peanut allergy |
Allergy to peanut |
| Example - Allergy 2 - Pollen allergy |
Allergy to pollen |
| ExampleScenario - Suspected Allergy |
Suspected Allergy, then refuted |
Patient Will profile and vocabulary. The Patient Will captures a patient’s expressed preferences related to care provision. The Logical Data Model defines the functional data needs. An example demonstrates the use of the profile.
| Logical Model Patient Will |
Patient Will logical model |
| Patient Will core BE profile |
The Core BE profile for Patient Will |
| Patient Will Categories |
Patient Will Category code system |
| Patient Will Categories |
Patient Will Category value set |
| Patient Will codes |
Patient Will directive code system |
| Patient Will directives |
Patient Will directive value set |
| Example - Patient Will |
Patient Will |
The profile for Addiction, intended to capture known or suspected substance or other addictions. The Logical Data Model defines the functional data needs. An example demonstrates the use of the profile.
| Logical Model Addiction |
Addiction record logical model |
| Addiction BE profile |
Belgian Profile to capture Addictions (on substances or others) |
| Addiction Quantifier extension |
Belgian Extension to allow quantification of addictions (on substances or others) - for example 10 packs per week, 1 bottle per day |
| Example - Patient Smoking addiction |
Patient Smoking addiction |
| Addiction Categories |
Addiction Category value set |
| Addiction Codes |
Addiction Code value set |
Vaccination related resources. These artefacts define the constraints and vocabulary necessary to record the administration of vaccine administrations, including the reference to a vaccination schema or protocol, and eventual immediate reactions. The Logical Data Model defines the functional data needs. The vocabulary resources help ensure conformity and data consistency. The profile and extensions define the technical specifications. A set of examples demonstrates the use of the profile.
| Logical Model Vaccination |
Vaccination logical model |
| Vaccination core BE profile |
The Core BE profile for Vaccination (event) |
| Location of the vaccination event |
Location of the vaccination event |
| CodeSystem - Care location |
The location of the care event |
| CodeSystem - vaccination confirmation status |
The list of vaccination confirmation status |
| CodeSystem - vaccination status-reason |
The list of vaccination status reason |
| CodeSystem - Vaccine Administration Route |
The list of administration routes for vaccines |
| ValueSet - Care location |
The list of Care locations |
| ValueSet - Vaccine Administration Route |
The list of administration routes for vaccines |
| ValueSet - vaccination confirmation status |
The list of vaccination confirmation status |
| ValueSet - vaccination status reason |
The list of vaccination status reason |
| Extension - Administered Product |
Administered Product |
| Extension - Vaccination original order |
Vaccination original order (e.g. prescription) |
| Extension - Vaccination recorder |
Vaccination recorder |
| Extension - Vaccination confirmation status |
Vaccination confirmation status |
| NamingSystem |
Naming System - CNK Product Codes |
| BeNSNIHDIOrganization |
NamingSystem - NIHDI Organization numbers |
| BeNSNIHDIProfessional |
NamingSystem - NIHDI Professional numbers |
| BeNSONEVaccination |
NamingSystem for ONE vaccination |
| BeNSNIHDIProductManufacturer |
NamingSystem - Product Manufacturer |
| Toto - First hexavalent vaccination |
Toto - First hexavalent vaccination |
| Toto - 2nd hexavalent vaccination |
Toto - 2nd hexavalent vaccination |
| Toto - 3rd hexavalent vaccination |
Toto - 3rd hexavalent vaccination |
| Toto - 4th hexavalent vaccination - skipped (fever) |
Toto - 4th hexavalent vaccination - skipped (fever) |
| Toto - 4th hexavalent vaccination |
Toto - 4th hexavalent vaccination |
| Juan - 1st hexa (reported) |
Juan - 1st hexa (reported) |
| Juan - 2nd hexa (hospital) |
Juan - 2nd hexa (hospital) |
| Juan - 3rd hexa (not done) |
Juan - 3rd hexa (not done) |
| Juan - 3rd hexa (effective) |
Juan - 3rd hexa (effective) |
| Eva - HPV 1st dose |
Eva - HPV 1st dose |
| Eva - HPV 2nd dose |
Eva - HPV 2nd dose |
| Julia - refuse HPV |
Julia - refuse HPV |
| Gabriel - Flu vaccine prescription |
Gabriel - flu vacccine prescription |
| Simon - HPV vaccine prescription |
Simon - HPV vacccine prescription |
| Toto reaction - erythema |
Toto - example of reaction (erythema) |
| Toto finding - fever |
Toto - example of finding that prevents vaccination (fever) |
| Simon HPV - work |
Simon HPV - work |
| Aymeric - rotavirus prescription |
Aymeric - rotavirus prescription |
| Aymeric - rotavirus 1st dose |
Aymeric - rotavirus 1st dose |
| Aymeric - rotavirus 2nd dose |
Aymeric - rotavirus 2nd dose |
| Aymeric - rotavirus 3rd dose |
Aymeric - rotavirus 3rd dose |
| Gabriel - influenza vaccine |
Gabriel - influenza vaccine |
| Observation - swelling reaction |
Observation - swelling reaction |
The Problem resources are intended to capture a short description of a patient’s clinical condition. The Logical Data Model defines the functional data needs. The vocabulary resources help ensure conformity and data consistency. The profile and extensions define the technical specifications. A set of examples demonstrates the use of the profile.
| Logical Model Problem |
Problem logical model |
| Problem core BE profile |
The Core BE profile for Problem |
| Laterality extension |
Laterality |
| Extension - Problem origin type |
Extension for Problem origin type |
| ValueSet - Problem origin type |
Set of values for problem origin type |
| CodeSystem - Problem origin type |
Codes for Problem origin type |
| Code System Problem Category |
Code System Problem Category |
| Value Set Problem Category |
Value Set Problem Category |
| Problem Codes Value Set |
Problem Code Value Set |
| Value Set Laterality |
Value Set Laterality |
| Code System Body Site |
Code System Body Site |
| Value Set Body Site |
Value Set Body Site |
The Score Results resource captures an overal assessment score about a health indicator associated with a patient. The vocabulary resources help ensure conformity and data consistency. The profile defines the technical specifications. A set of examples demonstrates the use of the profile.
| Score Result Logical Model |
Score Result Logical Model |
| Score Result Profile |
Score Result Observation profile |
| Example - FINDRISC score result |
FIDNRISC score result example, obtained from a QuestionnaireResponse |
| Score Result Code system |
Score Result codes |
| Score Result Category Code system |
Score Result Category |
| Score Result Value Set |
Score Result value set |
| Score Category Value Set |
Score Category value set |
These define constraints on FHIR resources for systems conforming to this implementation guide
| StructureDefinition/be-patient |
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.) |
| BePractitioner | |
| BePractitionerRole | |
| BeOrganization |
These define constraints on FHIR data types for systems conforming to this implementation guide
| Address core BE profile |
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. |
These define constraints on FHIR data types for systems conforming to this implementation guide
| StructureDefinition/exposure-risk |
Exposure Risk |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like
These are resources that are used within this implementation guide that do not fit into one of the other categories
| AllergyIntolerance/allergyintolerance-encounterReference-contained |
| AllergyIntolerance/allergyintolerance-encounterReference |
| Encounter/example-encounter-uzgent |
IG © 2019+ RIZIV-INAMI. Package hl7.fhir.be.riziv#0.1.0 based on FHIR 4.0.1. Generated 2021-01-10
Links: Table of Contents |
QA Report |
Issues |
Version History |
|
Version History |
|