Follow up patients with cystic fibrosis
Here I have collected some more information about the use-case we are modelling and developing for.
The following is written by a technical person and not reviewed by a clinican. It might contain information which is not medically correct or precises. The intention of the text is to give the reader an overall understanding of the application we are developing.
The application is developed toghether with a hospital in Norway. The purpose is to replace an existing paper based protocol for the follow up and treatment of patients with cystic fibrosis. The solution is developed using DIPS Arena low/no-code platform based on openEHR with forms and reusable AQL.
The scope is limited to only replace the paper based solution. There will not be a complete medication loop. The actual order and execeution in the medication system is not covered. The solution will focus on the multidiciplinary steps needed to make sure that every patient gets the right treatment at the right time.
Cystic fibrosis is a chronic disease which you are borned with. Todays treatment is good and many patients live long lives at home. Still it is a serious disease which requires life long treatment both on medication and other measures.
To define the population of active cystic fibrosis patients we deine a folder with attributes to define it as a CF patient. The folder/process is closed when the patient die or is transfered to some other healthcare provider.
A CF patient is followed up in cycles of 3 months. The patient is examined and potential new direction in the treatment are planned.
The overall activities are illustrated in the diagram below:
The control cycles contains multiple actions/activities. The diagram below illustrates this. The application is developed to support the state of the different activities.
Note that the hardest part for the application is to handle the transition between the different periods.
CF patients are exposed to pneumonia. The body fluids have dense mucus, and especially the lungs are prone to bacterial infections. This is why the antibiotic treatment is an important part of the control cycles.
Before each outpatient clinic samples from the lung are collected and analysed. The doctor evaluate the results and decides what decisions to do regarding the treatment. This is modeled in the diagram below:
Some patient has a chronic infection which has to be treated continously. This is called maintenance treatment. When some new agens are present they have to be handled. Then there will be a short and intensive medication treatment. This is ordered by the doctor.
It’s important to fight the disease fast and early. This is why the get a broad specter for antibiotics. The selected antibiotics are chosen based on the history of the patient and other reasons.
There will be one order to treat the discovered bacterial agens found. The whole treatment with different antibiotics will later be evaluated/reviewed as as whole. For the clinical modelling this means that we want to keep the information together both for the order and the follow up.
The clinical models
INSTRUCTION.medication_order.v2 for the medication order placed by the doctor. There will be a separate instance for the short and intensive cure and for the maintenance treatment . They have their own cycles.
We use one
ACTIVITY within the
INSTRUCTION. One order is the defined as one
ACTIVITY within the
INSTRUCTION. Since the doctor place one order for the cure we want to collect all the medication for that order within the same archetype instance. This is logical for the clinician and of course it makes later queries over the data simpler and even possible (IMHO).
We face a problem with the modelling when it comes to defining different antibiotics within the same order. The
CLUSTER.medication.v1 is used to to record details about a medication or component of a medication, including strength, form and details of any specific constituents. The
INSTRUCTION.medication_order.v2 has as slot for preparation details. This is described as structured details about the overall preparation including strength, form and constituent substances. We want to place one
CLUSTER.medication.v1 for each of the antibiotics given in this slot. Since the slot has cardinality
0..1 this is not possible.
The solution is straight forward. We put one
CLUSTER.medication.v1 in the slot and then add more
CLUSTER.medication.v1 as Constituent parts if this. This solves the problem, but it doesn’t feel right.