Medication order - preparation details

[bna (Bjørn Næss)]

We are using the medication order archetype for a use-case related to cystic fibrosis and the ordering of antibiotics. As part of this we are placing one order with a combination of one or more antibiotics. They are understood as one activity (order).

To model this we want to add multiple CLUSTER defining the different antibiotics. Then we found a problem since it’s not allowed to have more than one CLUSTER archetype in the SLOT at0143::Preparation details.

Question is: Why is this SLOT constrained to 0..1?
My suggestion is to have this SLOT unbounded.

Any comments on this?

[siljelb (Silje Ljosland Bakke)]

@bna

we are placing one order with a combination of one or more antibiotics. They are understood as one activity (order).

Wouldn’t this be one order set, and not one order?

[bna (Bjørn Næss)]

@siljelb

Wouldn’t this be one order set, and not one order?

Thanks for the reply. Not sure if I understand…

There is an order set containing a course for a new microbiological agens and there might be maintenance treatment for some chronic agens. For each medication treatment periode these are evaluated/reviewed by the doctor. There will be one composition for all the medication order. This is the order set.

For each of the treatment components (course or maintaince) there will be different components. These I want to add within the INSTRUCTION/ACITVIITY.

Take a look at this Template. It might (or might not ) demonstrate what I want to achieve. Archetype Designer

[joostholslag]

@bna

We are using the medication order archetype for a use-case related to cystic fibrosis and the ordering of antibiotics. As part of this we are placing one order with a combination of one or more antibiotics. They are understood as one activity (order).

Could could you please give a bit more clinical information? The way I understand it now: because a CF patients currently has that diagnosis, for preventive purposes, a combination of antibiotics regimes are prescribed for an indeterminate amount of time. Is this right?

If so I’d agree with Silje it’s an order set. I’m not very up to date on the advised modelling pattern for order sets. But it seems similar to chemotherapy regimes. They are (afaik) modelled as a single instruction made up of multiple activities (one for each antibiotic regimen in your case). The benefit, compared to using clusters, is the individual activities have their own state. You need this in case one of the antibiotics state is changed. E.g. due to side effects or forgotten or whatever.

[bna (Bjørn Næss)]

@joostholslag

Could could you please give a bit more clinical information? The way I understand it now: because a CF patients currently has that diagnosis, for preventive purposes, a combination of antibiotics regimes are prescribed for an indeterminate amount of time. Is this right?

I will take a look at some of the diagrams and descriptions, and try to find time to translate them to English.

You have understood it correctly.

I was thinking about one instruction with multiple activities. This use-case is in that direction. Still it’s not that structured in the clinic. Thus I didn’t want to introduce to much formalism.

And more importantly is that the order share the same indication which is in the activity description of the archetype.

[ian.mcnicoll]

As others have said, can you give a bit more info but I am guessing this is a bit like an H Pylori eradication regime - multiple different meds given in a particular sequence, not as a mixture.

The medication order is explicitly about a single medication ‘product’, even if that product as a mixture i.e a n IV solution. It is not intended to handle the orhestration of multiple orders (as per Sjile’s orderset suggestion).

I remember that we explicitly discussed whether ‘Preparation details’ should be multiple occurrence but the consensus was that the top-level Medication cluster should represent the whole ‘product’ / mixture’ that is intended to be administered to the patient, and that a the details of the mixture/infusion, would be carried one level down, as multiple Medication clusters.

So the single preparation details occurence is ‘by design’ and I agree this sounds much more like an orderset or the outcome of orderset, with multiple medication orders one for each antibiotic course.

[joostholslag]

@bna

Still it’s not that structured in the clinic. Thus I didn’t want to introduce to much formalism.

And more importantly is that the order share the same indication which is in the activity description of the archetype.

Probably I can understand an example without translation, medication and medical speak is usually pretty similar between Norwegian and Dutch.

I think you can solve most of the formalism in a tailored UI, and rules in templates can also be helpful (if your cdr supports it).

How about setting the indication.value for each activity of the antibiotic in the template?

[bna (Bjørn Næss)]

Follow up patients with cystic fibrosis

Here I have collected some more information about the use-case we are modelling and developing for.

Disclaimer

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.

Introduction

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

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.

Antibiotics

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

We use 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.

[joostholslag]

Impressive summary Bjørn. It largely supports my initial advice. I more detail:

@bna

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.

Nice description of the key modelling challenge.

@bna

We use 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.

Agree with your reasoning and the chosen design:D Both instructions can/should be part of a single composition, probably encounter of the control/ check-up, together with archetypes like reason for encounter, observations (story, vitals, lab), conclusion (clinical synopsis), potentially (differential) diagnosis (risk of) pneumonia) and then the instructions and a health eduction request. This way all information to understand the instruction is in the same composition.

@bna

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).

Here is why I would advocate for a different approach of multiple activities for the different antibiotics assuming they are usually prescribed as a set in a single order. e.g. multiple prescriptions on the same paper recipe note/ single item in a list of possible drugs to prescribe. This is still a single archetype instance.
If the relationship between the different antibiotics would be concluded to be very loose (e.g. different combinations every time, different clinical indications etc) you could also model as different instructions (and record links if needed).

I think it should be possible to explain this logic to a doctor with above average abstract thinking skills
I don’t see any issue in querying this data, but it appears you do, could you please help me understand?

This also prevents you from the cluster occurrence problem. Which is ‘misuse’ in my opinion, since the different antibiotics are not constituents of a single drug. (A use for this might be amoxicillin+clavulan acid where the two constituents are usually a single tablet and complement the others workings: beta lactam bactericide + bacterial defence’s beta lactamase blocker.)

Please be mindful my advice is limited since I have little practical experience modelling medication or instructions at all, my experience is mostly as a junior MD and medior clinical informatician/modeller:)

[ian.mcnicoll]

@bna

This solves the problem, but it doesn’t feel right.

It doesn’t feel right because it it isn’t right!!

You are mixing up an orderset with an individual medication order - an instruction to supply a medication for administration or dispensing. That original orderset will need to be translated into a set of medication orders - multiple activities is fine here, as they are tightly bound but, for the reasons Joost has laid out well, you should definitely not treat them as if this was a single medication with multiple components.

If nothing else this will almost certainly not translate into the national prescribing system/regulations.

An orderset often works at a a different level of abstraction, in any case. It will talk in terms of relative dates i.e give substance x for 3 days ,then substance Y for y days - it is an abstract recipe which needs to be turned into a set of concrete ‘orders’. I would probably strip the original ‘Supply Cystic fibrosis meds as per Protocol’ as a Service request instruction, let the app generate the individual orders and just tie them all together with an orderID of some sort though using activities is fine. Sub-components, is a bad idea!! It is explicitly NOT how the archetype is supposed to be used and will get in a real tangle in terms of most national prescribing systems.

We deliberately dodged the orderset bullet last time - perhaps this is our chance to re-think but for practical reasons , I think you are going to end up with a set of loosely linked medicaton orders at the end of the process, since these all have to play inside EPR prescribing systems and national prescription handling systems just like any other medication/

[bna (Bjørn Næss)]

@ian.mcnicoll

That original orderset will need to be translated into a set of medication orders - multiple activities is fine here, as they are tightly bound but, for the reasons Joost has laid out well, you should definitely not treat them as if this was a single medication with multiple components.

If I understand @ian.mcnicoll and @joostholslag correctly you recommend to repeat :

• Patient information
• Clinical indication
• Therapeutic intent
• Order details like start and stop

For each of the medication component in a treatment order. This feels like a lot of duplication and doesn’t feel right.

Where can I find an example of such a order set?

[bna (Bjørn Næss)]

@bna

This feels like a lot of duplication and doesn’t feel right.

But - I have to admit: There is a small change in the technical understanding of the use-case and the template modelling. It’s just about defining the granularity of an INSTRUCTION archetype. Based on your advice it should be used with a very low granularity. For me; the INSTRUCTION has a higher grade of granularity modelling the decision of the clinician. What I learn now is that the INSTRUCTION archetype for medication should be handled as low-level technical archetype. I might be fine with that when my had has turned around a few times

[joostholslag]

@bna

If I understand @ian.mcnicoll and @joostholslag correctly you recommend to repeat :

• Patient information
• Clinical indication
• Therapeutic intent
• Order details like start and stop

For each of the medication component in a treatment order. This feels like a lot of duplication and doesn’t feel right.

Yes, it is what we suggest. But I didn’t realise this is a bit much duplication and is not ideal indeed. I think it’s a limitation of the instruction RM model. There should be a possibility to set the clinical indication and the like at the instruction level (not the activity level). (We can use narrative off course, but that will loose structure and defeats the purpose of modelling:p)
But I don’t think it’s too big a problem to duplicate the info into each activity. I do think it’s still semantically better: since each individual medication regime actually should have these details individually and it may even be subtly different for each antibiotic/activity.

You could make a template on the medication order (or on CF checkup) for each order set and set default values for those four values. That way the clinician does not have to do all the typing. Or if default values don’t make sense because the information differs too much per patient, you can use expression language ‘rules’ to copy the information from the first activity to the others (or do this in your app).

Anyways, the cluster in cluster is not the solution:(

I don’t have an example of an openEHR order set. But maybe the specs help a bit, they describe the use of multiple activities for drugs: EHR Information Model

Please keep us updated. And maybe share an example of a CF clinical order set. And indeed it could be a nice moment to start working on order sets for the clinical group.

[joostholslag]

@bna

For me; the INSTRUCTION has a higher grade of granularity modelling the decision of the clinician. What I learn now is that the INSTRUCTION archetype for medication should be handled as low-level technical archetype.

hmm this is a tricky one. For me the main goal of INSTRUCTION is indeed to record the decision of the clinician (‘order’ is what I prefer, since decision also applies to what diagnosis or interpretation of observations is true). This could fit in just INSTRUCTION.narrative. But this decision can be further specified to more granularly express what that decision is exactly, operationalised is a nice work to describe this. This is what activities are for. And in case of medication orders the clinician is (even legally I think) required to add specifics to an order and can’t only record naar active of ‘start regular CF AB profylaxis’.

[bna (Bjørn Næss)]

I revisited my clinical model. I added the therapeutic intent and clinical indication as a recommendation:

The template is here: Archetype Designer

For the end-user it might look like the following:

PS! Don’t care about the stars in the codelists. I didn’t translate them. The clinical indications are microbiological agens defined with SNOMED-CT codes. The terapeutic intent is a local terminology.

Is this way of modelling more aligned with your way of thinking?

[bna (Bjørn Næss)]

@joostholslag

I think it’s a limitation of the instruction RM model. There should be a possibility to set the clinical indication and the like at the instruction level (not the activity level).

Yes!
I think the INSTRUCTION/ACTIVITY/ACTION model should be revisited. IMHO there is a need to be able to structure attributes on the total INSTRUCTION and not only for each ACTIVITY. This would make the RM more prepared to carry out order sets with multiple activities, and there wouldn’t be needed to duplicate information which is the same for all activities or is needed to understand the total intention by the clinician.

According to the specificaion of INSTRUCTION. The class is Not to be used for plan items which are only specified in general terms. What class should be used to represent such planning?

@joostholslag

I don’t have an example of an openEHR order set. But maybe the specs help a bit, they describe the use of multiple activities for drugs: EHR Information Model

I have read that many times over the years It is correct at the overall level. The hardest part is modelling the clinical use-cases for production use…

@joostholslag

For me the main goal of INSTRUCTION is indeed to record the decision of the clinician (‘order’ is what I prefer, since decision also applies to what diagnosis or interpretation of observations is true). This could fit in just INSTRUCTION.narrative. But this decision can be further specified to more granularly express what that decision is exactly, operationalised is a nice work to describe this.

I agree with you. Still the problem might be at the RM; where we sometimes need to structure information which is shared over the ACTIVITY level.

@joostholslag

Anyways, the cluster in cluster is not the solution:(

Still not convinced - but working on it

[joostholslag]

Yes, it’s more in line with what I’m suggesting. But I think the clinical indication and treatment intent should be filled at the individual activities.

This example nicely shows btw why they are indeed at the right level, since at least the clinical indication is probably different for each antibiotic(activity), they each have their own specific bacteria(group) they target. The combination is to target all of the bacteria. Maybe it helps you get convinced on the semantics.

But I also agree that it is fine to list the clinical indication for all activities combined, that should be possible on the instruction level, above individual activities. What do you think @ian.mcnicoll.
What I don’t understand btw is of what structure the individual ab orders are instances, from looking at your template they seem to be multiple orders in a single activity. But maybe I’m just not used to AD. I think multiple activities each with a single order would be more faithful, since each antibiotics regimen has its own state machine (you can stop one, continue another).

[joostholslag]

@bna

According to the specificaion of INSTRUCTION. The class is Not to be used for plan items which are only specified in general terms. What class should be used to represent such planning?

I think the answer would be evaluations. But I believe the text in the specs should be relaxed a bit. Stating it’s recommended for specific planable tasks. But I believe it’s fine to record more general plans e.g. “participate in group therapy” as INSTRUCTION. It has value for it can be marked completed, it can be operationalised into more specific activities, it’s sementically more close to an instruction than an evaluation and there’s value in treating them (in UI and queries) as specific tasks. And there’s little downside imho.

[bna (Bjørn Næss)]

Thanks for your reply. I have changed the model. Now I use one ACTIVITY for each antibiotics.
Since the microbiology findings are recorded for all the antibiotics in the course I store them under protocol using the archetype CLUSTER.clinical_evidence.v1 .

With this design I am aligned to the recommendations from @ian.mcnicoll and @joostholslag . Still I don’t duplicate data which by the clinicians are not intended to be duplicated. I understand it might be correct to bind the microbiological findings for each medication/antibiotics. Still this is too specific for the use-case at hand. The patient is given a broad specter of antibiotics at a specialized hospital to defeat an infection.

The template is located here: Archetype Designer

This time with much Norwegian words …

[joostholslag]

Thanks for sharing the template.
The ‘clinical indication’ is now listed under protocol of the instruction. It’s now clear that the information relates to all activities. And I understand you don’t want to duplicate it. And you don’t want the user to have to split it out per antibiotic. I think that is fair too. I think this is the best we can do for now, and probably miles ahead of most order set models:D
But there are two issues wich may not be a big problem for you currently but which I feel are important to share. Mainly for future reference.

1. The indication is not currently listed for each antibiotic in the usual place, this might be a problem for the receiving pharmacy, or some hardcoded interfaces. And it’s legally required (but not usually done:p) in my country. If you don’t want the user to copy paste the info, you could write some logic to do the duplication e.g. via rules section of the template. Or you could define, in the template, an activity for all possible antibiotics, and hardcode the clinical indication (value matches…) and let the user select the antiobiotic (occurrence of activity) e.g. from a dv_coded_text.

2. The protocol section is meant for a

“ Description of the method (i.e. how) the information in this entry was arrived at… For INSTRUCTIONs , how to execute the Instruction. This may take the form of references to guidelines, including manually followed and executable; knowledge references such as a paper in Medline; clinical reasons within a larger care process.”

The current information doesn’t fit this description. I think openEHR should support instruction sets. Something like a ‘cluster of activities’, with elements from the activities also available at the group/set level. This should be a CR for the spec imho. But first more research and discussion for alternative approaches.

And an clinical modelling editorial guideline on how to currently handle order sets would be very useful to get some interoperability for this kind of data. I assume other modellers will easily end up with totally different designs.
This has also shown me how hard it is to get interoperability right, if even three people very involved in openEHR come up with different designs. It intellectually challenging, and nice to collaborate so thank you for that:D