Drug Orders: Order Templates modelling

Hi all following this talk post and other many conversations we had on TAC calls, hackathons and other forums we all think it’s time to move forward with backend support for Order Templates.

I’ve managed to make the order basket show some data (linked to the backend and the example JSON on esm-medication) as you can see on the image bellow:

For this to work I just had to change the UUID of the Drug Concept on the JSON to an existing drug UUID on the backend

As we can see, an Order Template is a combination of a dosageUnit , route, frequency and commonDosage

Looking forward to hear from you and to get this ball rolling. :wink:

cc: @grace @burke @mseaton @dkayiwa @mwaririm @alaboso @samuel34 @jdick @dagimm

1 Like

I think we still need to consider the relationship between a prescription and a dispensed drug. Tying the prescription to the pill strength is somewhat problematic unless you include frequency. So you can prescribe 2 250 mg Amoxacillin tablets or you could prescribe 1 500 mg tablet. If the template was called “Pneumonia - 500 mg Amox TID” you would either decouple the dose with the strength or save it as either two 250 mg tablets 3x per day or 1 500 mg tablet 3x per day.

Also, where are we storing this completed order (including things like the link to the drug table, the PRN text (patient instructions)? Will the instructions themselves be linked text (to be reused)?

Discussion today: We want to move forward with these additions to the data model (namely, adding support for dosageUnit , route , frequency and commonDosage)

@burke’s voiced concern: We don’t want to conflate Order Templates with the Formulary. So don’t want Order Template level details to be stored in the Formulary.

So - how do we move forward with getting this support for Order Templates in the OMRS data model?

Burke’s suggestion is that we design based on a fhir-based form. I guess this means we need a new table in the backend for Order Templates…?

Let’s discuss the data model / architecture here, and then we will confirm design decisions at next Monday’s TAC call.

I’m confused. Don’t we already support Order Templates via OrderSet / OrderSetMember ? @burke ?

From what I recall from a previous conversation, perhaps we discussed pulling Order Template off of Order Set Member, and allowing it to exist independently of an Order Set Member.

I think the approach looks good. There’s a distinction between the drug formulary and order templates:

  • Drug formulary (the OpenMRS drug table) is a list of available drug formulations (the inventory). This includes the name of the drug along with its form (capsule, tablet) and strength (81 mg, 243 mg, etc.). It does not specify administration instructions (like dose, frequency, or additional instructions)

  • Order template provides the details for the order form. For medications, this includes the instructions on how the medication should be given. In your examples, this is the “once daily – oral” which more explicitly is saying “Take one tablet by mouth once daily.”

While we want to bring these together into a seamless user experience, the information is often managed independently or drawn from different sources (e.g., pharmacy providing the formulary of available drugs & strengths and the order templates for how they should be given coming from a Ministry, or clinical advisory board within the institution and, in large enterprises, may be drawn from externally managed sources).

I don’t we want to loop through all possible combinations of choices (e.g., the combination matrix of dosages, frequencies, and routes) for several reasons, including:

  • Not all combinations make sense. For example, a drug with a maximum safe daily dosage of 100 mg might be safely given 50 mg daily, 25 mg twice daily, or 50 mg twice daily; however, a dose of 100 mg twice daily is harmful.
  • There are more components to orders beyond dose, route, and frequency. Even if we limit our scope to drug orders for now (ignoring other details that might be needed for other types of orders), even simple drug order templates would ideally allow for additional instructions, as needed conditions, etc.
  • We’ll eventually want to support templates with other dosage instruction types (combination doses, tapers, infusion, etc.) along with free text templates.

Rather than a JSON containing a list of possible or “common” options for each field, I would favor an order template format that provides a single set of details for one ordering option (i.e., default values for the fields within the order form). The initial compromises would be (1) we focus on generating templates for the common ways medications are ordered and uncommon usages would be ordered with a “blank” order form and (2) we don’t worry about providing choices for individual components (frequency, route, etc.) within order templates at this stage.

Following @mseaton’s advice, we could consider using the order_set_memberorder_tempalte and order_template_type – as a near-term workaround for introducing order templates. We could either use the existing data model and provide order template at the drug concept level OR we could add an optional drug_id attribute to the order_set_member table to optionally link a template to a specific drug formulation.

2 Likes

@ibacher @dkayiwa and @OHRI devs thank you for thank you for taking the time and meet today. Based on our discussion we decided to reuse the order_sets as suggested by @mseaton and here is how it will look like: Based on our “pharmaceutical” experience :see_no_evil:, we used paracetamol as an example:

Drug name: Paracetamol 500mg Oral Tablet (uuid: bbb) | Concept: Paracetamol (uuid: aaaa)

Template configuration:

Example 1

Order Set: {name: "Drug Order", ...}

Order Set Member

{ 
  concept_uuid:"aaaa",
  order_template_type: "Drug Order",
  order_template: {
     drug_uuid: "bbb", 
     dosageUnit: "Tablet", 
     route: "Oral", 
     frequency:"Once Daily", 
     commonDosages: [
         {dosage:"500mg", numberOfPills: 1}, 
         {dosage:"250mg", numberOfPills: 0.5}
      ]
  }
}

Example 1

Drug name: Paracetamol 250mg Oral Tablet (uuid: ccc) | Concept: Paracetamol (uuid: aaaa)

Order Set: {name: "Drug Order", ...}

Order Set Member

{ 
  concept_uuid:"aaaa",
  order_template_type: "Drug Order",
  order_template: {
     drug_uuid: "ccc", 
     dosageUnit: "Tablet", 
     route: "Oral", 
     frequency:"Twice Daily", 
     commonDosages: [
        {dosage:"250mg", numberOfPills: 1}
     ]
  }
}

This approach would also be used for labs since we would group the order sets by either “Drug Order” or " Lab Order" sets.

@ibacher we also talked about support for order_set and order_set_member domains needed for Iniz but I see this ticket and seems to be done, can we confirm this support is indeed available?

Hope this make sense.We are looking forward to hear from you and agreement that this is a long term solution and we won’t need to do any migration to a new structure in the near future (if that’s the case then let’s bang our heads on the table until we get to a final/stable solution)

cc: @burke @grace @akanter

3 Likes

Where does “numberofpills” show up? I think you need a dose quantity field to capture the number of x being prescribed at a frequency for a duration.

For example: either 500 mg by mouth three times a day for 10 days. or 2 x 250 mg Tablet by mouth three times a day for 10 days.

That ticket relates to the original implementation of OrderSet and OrderSetMember. It’s not got anything to do with Iniz (Iniz didn’t exist in 2014 when that ticket was completed).

@eudson, I’m sorry I didn’t know about the meeting yesterday. Thanks for the example. I would suggest some tweaks…

I would suggest we use URIs or URLs for order_template_type so we can include versioning and don’t have to manage a single namespace for all types. For example:

order_template_type: "org.openmrs.ordertemplatetype.drug/v1"

Dose and dose units should be separated. Ideally, we would evolve to use FHIR-compatible dosing (i.e., at least an approach that we can translate to/from FHIR). Until we’re ready to handle dose ranges, infusions, etc. and assuming we can infer dose unit terminology, I think this just means separating dose value and units. For example:

{ dose: "250", doseUnits: "mg" }

Where there are choices for an field, a template should be able to optionally specify which is default:

dose: [
  { dose: "250", doseUnits: "mg" },
  { dose: "500", doseUnits: "mg", default: true }
]

numberOfPills is not needed and doesn’t apply in many cases. When needed, “number of pills” can be calculated. For example, a dose of 250 mg for a drug that has a strength of 500 mg is dose/strength250/5000.5 pills. Number of pills also unnecessary or doesn’t make sense if the dose is “1 tablet” or the drug order is for eye drops. Also, I don’t believe it translates to FHIR’s dose syntax.

Templates should include all the information to complete the order form, where order form schema varies by order type and (in the future) could be orderable-specific. For drug order forms, this would mean including dosage instruction type (simple dosing, free text, taper, etc.), which would determine the values for dosing instruction. Simple dosing would provide dose, route, frequency, prn+condition, additional instructions, while free text would just include instructions.

Simple Dosing example
{ 
  concept_uuid:"aaaa",
  order_template_type: "org.openmrs.ordertemplatetype.drug/v1",
  order_template: {
    drug_uuid: "bbb", 
    dosingInstructionsType: "org.openmrs.SimpleDosingInstructions",
    dosingInstructions: {
      dose: [
          { dose: "500", doseUnits: "mg" default: true }, 
          { dose: "250", doseUnits: "mg" }
       ],
      route: "Oral", 
      frequency: "Once Daily", 
      additionalInstructions: "Take with full cup of water.",
      asNeeded: true,
      asNeededCondition: "pain"
    }
  }
}
Free text dosing example
{ 
  concept_uuid:"aaaa",
  order_template_type: "org.openmrs.ordertemplatetype.drug/v1",
  order_template: {
    drug_uuid: "bbb",
    dosingInstructionsType: "org.openmrs.FreeTextDosingInstructions",
    dosingInstructions: {
      instructions: [
        { text: "Take 2 tablets by mouth once daily on odd numbered days", default: true },
        { text: "Take 2 tablets by mouth once daily on even numbered days" }
      ]
    ]
  }
}

In these examples, we’re presuming that all of the literal (and human-friendly) strings for codified elements (route, frequency, units) are unambiguous exact matches to names of corresponding concepts. It feels hacky to leave the application to infer whether a string is a UUID or a name (e.g., “Tablet” vs. “1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB”), especially since many of CIEL’s UUIDs don’t adhere to the UUID specification. We don’t want “1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB” to show up as a dose unit option because the application because someone accidentally left off a “B”. :slight_smile: Perhaps a simple string could be assumed to be a name lookup and UUID require an object. For example, the following three references would be equivalent (assuming there’s only dose unit with the exact name “Tablet”):

doseUnits: "Tablet"
doseUnits: { uuid: "1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB" }
doseUnits: {
  name: "Tablet",
  uuid: "1765BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"
}

Note, I’m also assuming we can easily discriminate between array & object when parsing JSON, so we can use the same property for both single & multiple choices:

dose: { dose: "500", doseUnits: "mg" }
dose: [
  { dose: "500", doseUnits: "mg" },
  { dose: "250", doseUnits: "mg" }
]

BTW, linking a template to a specific drug formulation (i.e., drug_uuid) could be optional. A template linked to a concept without naming a specific drug formulation would apply to any formulation(s) of that drug for which there aren’t any templates (effectively, a way of defining a default template for a drug by concept without having to assign it to each formulation).

3 Likes

That one’s on me. From a quick look at DrugOrder I thought it would require a Drug, but if that’s not the case, that’s even better!

While it’s common practice to require a drug formulation to be ordered, requiring a drug formulation at the time of ordering is an implementation detail, since the formulation can often be inferred. For example, if the person filling the prescription (e.g., the pharmacist) knows the concept (amoxicillin) and the desired dosage instructions (500 mg twice daily), she can figure out what drug formulation (either one 500 mg tablet or two 250 mg tablets) to dispense.

But also, these are order templates (not drug orders). Even if we make providers order by drug formulation, if the are fives forms (e.g., five strengths) of a medication that are all typically ordered as “1 tab by mouth once daily”, a single template linked to the underlying concept could be used as the default template without having to manage five templates to accomplish the same thing.

My preferred option would be to have drug concepts that are Drug+Strength Clotrimazole 10mg/ml and leave the provider to decide the formulation, dose and duration. Option two is to have drug+strength+formulation which will require more variables to be created for each formulation clotrimazole 10 MG/ML Topical Cream clotrimazole 10 MG/ML Topical Foam clotrimazole 10 MG/ML Topical Lotion etc Secondly trying to tie a drug with a dose can be tricky, Paediatric doses are calculated according to body weight ,trying to define the doses is difficult and i would again let the provider select that for themselves. Something like the option below would be move versatile to meet the initial prescribing need and later on tie neatly with dispensing.

@wamz, when you say “drug concepts” do you mean “Concepts of class Drug” or entries in our drug table? I’m assuming you mean the latter.

One of the key reasons for designing the drug table around formulations (drug + strength + formulation) is because all combinations are commonly not available. For example, consider the forms of clotrimazole:

  • 10 mg lozenge
  • 1% cream
  • 2% cream
  • 1% ointment

If you were to choose drug & strength (e.g., clotrimazole 10 mg), then it wouldn’t make any sense to chose a form other than lozenge. Likewise, if you chose the strength 2%, then you shouldn’t be allowed to chose between lozenge, cream, or ointment for a form, since only cream makes sense.

Clinically, it’s okay to have additional choices based on form, since different forms are typically used for different purposes (e.g., one form may be better for hair/scalp while another form is used on skin).

You’re correct that weight-based dosing can be tricky. This is common in pediatric drugs, but not limited to pediatrics. Ideally, the system would know the strength of the drug being ordered (e.g., 10 mg/mL) and the recommended weight-based dosing (e.g., 0.5 mg/kg). When the patient’s weight is available, the system could suggest a dose (e.g., 0.5 mg/kg * 40 kg = 20 mg; 20 mg ÷ 10 mg/mL = 2 mL), but these calculations are tricky, because they need to be rounded based on dosing options (e.g., it’s not helpful to recommend 3.72 mL daily for a medication given by a 5 mL teaspoon or a 2 mL dropper). When strength, weight-based dose, weight, and dosing forms are available in structured form a computer can understand, it’s possible to calculate & recommend reasonable weight-based dosing… but it’s not a trivial problem to solve.

A reasonable near-term approach would be to allow templates to include weight-based dosing recommendations, provide weight information when available (e.g., “Weight 40 kg recorded 5 days ago”), perhaps include some tooling to help providers do the calculations (or even show the calculations as tips like “42 kg ✕ 5 mg/kg = 210 mg” so providers don’t have to manually perform the calculations and only translate those to an appropriate dose), and ideally leverage min or max daily dosage limits to help catch mistakes.

I would suggest putting dispensing information (i.e., quantity & quantity units) toward the end of the instructions (i.e., don’t start with dispensing information), since the quantity can often be calculated (or entry simplified) once the instructions are known.

@burke and @wamz your last comments are suggesting that we fall back to not use templates. Since we will have each possible combination of drug prescription as a record on the drug table which imply that adding a template would be redundant. Is my understanding correct?

Sorry, if I implied this, it was not intended. Order templates would provide the default and/or preferred values for dose, dose unit, route, frequency, as needed flag, as needed condition, (as in my examples above) and even dispensing information.

I believe @wamz was suggesting the form (tablet, pill, lotion, etc.) come from the template as well; however, I think the form needs to be part of the formulation (i.e., drug table entry, including concept, strength, and form) for the reasons I mentioned in my last comment.

@burke @eudson @grace here are a few drugs to start with Prescription Template - Google Sheets how do we model the templates for them.

@wamz, could you make your Prescription Template spreadsheet viewable by anyone with the link?

@burke, @wamz has made the temple link public. Can we now model the order template (the first class citizen as agreed on the call with @jdick)?

Thanks for sharing the spreadsheet, @wamz. I would suggest we target a few drug orders that can demonstrate the range of basic features we want to support up front. For example:

Drug Example prescription(s) Feature(s)
abacavir 300 mg mg by mouth twice daily
600 mg by mouth once daily
Multiple templates for the same drug
abacavir / dolutegravir / lamivudine 1 tablet by mouth daily Combination drug
levonorgestrel One tablet by mouth as soon as possible within 72 hours of unprotected sexual intercourse or suspected contraceptive failure Free text dosing instructions
paracetamol 500 mg every 6 hours as needed for pain As needed dosing

Assuming we have these data:

Concept table

Drug table

  • Abacavir 300 mg tablet
  • Abacavir/dolutegravir/lamivudine 600/50/300 tablet
  • Levonorgestrel 1.5 mg tablet
  • Paracetamol 500 mg tablet

Values for simple dosing instructions

Order Templates

An openmrs-module-ordertemplates module could introduce an order_template table with properties like:

  • order_template_id (int)
  • name (varchar 255)
  • description (text)
  • concept_id (concept)
  • drug_id (drug), optional
  • template (text)
  • … other columns for OpenmrsMetadata

Data within the order template table would look something like this:

concept drug template
Abacavir Abacavir 300 mg tablet
{
  dosingType: "org.openmrs.SimpleDosingInstructions",
  instructions: {
    dose: 300,
    doseUnits: "161553AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* mg */
    route: "160240AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* oral */
    frequency: "160858AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* twice daily */
  }
Abacavir Abacavir 300 mg tablet
{
  dosingType: "org.openmrs.SimpleDosingInstructions",
  instructions: {
    dose: 600,
    doseUnits: "161553AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* mg */
    route: "160240AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* oral */
    frequency: "160862AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* once daily */
  }
}
Abacavir / dolutegravir / lamivudine Abacavir/dolutegravir/lamivudine 600/50/300 tablet
{
  dosingType: "org.openmrs.SimpleDosingInstructions",
  instructions: {
    dose: 1,
    doseUnits: "1513AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* tablet */
    route: "160240AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* oral */
    frequency: "160862AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* once daily */
  }
}
Levonorgestrel Levonorgestrel 1.5 mg tablet
{
  dosingType: "org.openmrs.FreeTextDosingInstructions",
  instructions: {
    text: "One tablet by mouth as soon as possible within 72 hours of unprotected sexual intercourse or suspected contraceptive failure"
  }
}
Paracetamol Paracetamol 500 mg tablet
{
  dosingType: "org.openmrs.SimpleDosingInstructions",
  instructions: {
    dose: 500,
    doseUnits: "161553AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* mg */
    route: "160240AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* oral */
    frequency: "162249AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", /* every 6 hours */
    asNeeded: true,
    asNeededCondition: "pain"
  }
}

The ordertemplate module would introduce an OrderTemplate service. We can discuss further on specific API methods. Since order templates would be a new first class resource for OpenMRS, I think we would want to break our typical module conventions and treat this as a core module – i.e., other modules should not have to depend on this module; rather, order templates should be assumed to be part of the core API.

/cc @mseaton @dkayiwa @ibacher

1 Like

@eudson i have the drugs on dev, let us do the proof of concept as i populate the rest of the drugs with a default dose, doseUnits, route and frequency. ideally for users to maintain and generate their drug templates we should have a way to manage this from the front end so that i can go in and create, updated and correct new and existing templates

1 Like