0.1.0 - ci-build
RarecareFHIRIG - Local Development build (v0.1.0). See the Directory of published versions
This repository contains the FHIR resources for the “Een PGO voor iedereen” (“A personal healthcare environment for everyone”) project.
Note: All example content is example only! It is based on Shwachman Diamond Syndrome (SDS) data from rarecare.world, but for brevity it is much shorter than the actual data would be.
The Netherlands has a national effort, MedMij, to provide all Dutch citizens with a personal healthcare environment, web or mobile. However, persons with rare diseases have trouble seeing their condition properly represented. Due to the rare nature of their condition, vendors are hesitant to invest in small populations. Having a machine-readable Rare Condition profile would enable vendors to simply read the necessary data to provide those persons with customized dashboards, graphs and questionnaires to address their conditions properly. Moreover, healthcare professionals, patient organizations and researchers could all benefit from the structured collection of data.
The “PGO for everyone” project aims to provide such a machine-readable API for PGO’s. The definitions for specific rare conditions are published as FHIR resources. PGO’s can pull those in with an API, and use the definitions to provide disease-specific dashboards and questionnaires for those rare conditions.
The Rare Care models are maintained at https://rarecare.world
and (only partially complete yet) https://decor.nictiz.nl/art-decor/decor-datasets–zaz-
From those resources FHIR profiles are generated. The basis is a Data Model of Rare Conditions:
A Rare Condition IS_A Disease, but will also be composed of diseases: i.e. Shwachman-Diamond Syndrome is typically associated with Neutropenia, Pancreas Insufficiency etc. A Disease is associated with Symptoms, which may be abnormal lab values, represented by LOINC codes. Symptoms may also be HPO-coded phenotypical abnormalities. A Disease is associated with Medication, here represented with ATC coding. Diseases are also associated with ICF impairments in functioning (b.xxx codes) or activity and particapation (d.xxx codes).
The RareCare datamodel for Rare Conditions is implemented using FHIR. The FHIR profiles contain a mapping to the data model (see tab ‘Mapping’ in each profile).
There are 3 kinds of FHIR resources: Event, Request and Definition.
The Definition resources fit the RareCare Datamodel very nicely. The data model does not say anything about specific patients, only something about all (or most) patients with a particular Rare Condition.
The mapping from data model to FHIR resource types is as follows:
Data model | FHIR resource type | RareCare IG FHIR profile | Coding |
---|---|---|---|
Rare Condition | PlanDefinition | RareCarePlanDefinition | Orpha, Snomed CT, ICD-10 |
Disease | PlanDefinition | DiseasePlanDefinition | Snomed CT, ICD-10 |
Symptom (only lab tests now) | ActivityDefinition, ObservationDefinition | LabActivityDefinition, ObservationDefinition | LOINC |
Medication | ActivityDefinition with product | MedActivityDefinition | ATC |
Function, Participation | Questionnaire | FunctioningQuestionnaire, ParticipationQuestionnaire | ICF-b, ICF-d |
The FHIR profiles are under ‘Artifacts’. Under each profile are:
A PlanDefinition is a general disease management plan, i.e. not a plan for a particular patient, but a generic plan to be rolled out when a particular patient enters care. When that is the case, a CarePlan based on the generic PlanDefinition can be made.
We have two subtypes of PlanDefinition:
The RareCarePlanDefinition are the FHIR way to define actions to be taken for a particular rare disease. They contain references to:
The related DiseasePlanDefinitions contain references to:
An ActivityDefinition describes request resources such as ServiceRequest and MedicationRequest. So an ActivityDefinition may describe some lab test which can be performed or some medication which may be taken.
We have two subtypes of ActivityDefinition:
An ObservationDefinition describes an Observation in detail.
We have one two subtype of ObservationDefinition:
An Questionnaire describes a Questionnaire in detail.
We have one two subtypes of Questionnaire:
Of the FHIR Restful API we only use the read
interaction, which has this base syntax.
GET [base]/[type]/[id] {?_format=[mime-type]}
For our API, the base is https://rarecare.world/fhir
:
GET https://rarecare.world/fhir/[type]/[id]
[type] is one of:
[id] can be found in the references in the instances. For instance the PlanDefinition for SDS contains actions with a URI in definitionCanonical:
"action" : [
{
"title" : "Neutropenia",
"definitionCanonical" : "http://rarecare.world/fhir/PlanDefinition/neutropenia"
},
This contains the entire URI, the last part (neutropenia
) is the id. The id is arbitrary, it could just as well have been a UUID or random number, as long as the references are maintained.
The RareCarePlanDefinition (for the entire rare condition) can also be retrieved by ORPHA code:
GET https://rarecare.world/fhir/PlanDefinition?code=ORPHA:811
So, starting with
All retrievals except the first one are on [id].