Chemotherapy Ordering Data Design

Development
, ,
1

Hi all,

I’m working on the IBM team that is building Chemotherapy Ordering. We’ve been working on identifying necessary data points for our solution that aren’t clearly represented in the current data model, and brainstorming where those points could fit, or how we might extend the model to fit those points.

For background, here is how we are planning to model the regimen templates and the chemotherapy orders in the data model:

RegimenModel
RegimenModel1806×1006 44.8 KB
DoctorWorkflow
DoctorWorkflow3988×1006 80.2 KB

The missing data points for our use case are:

  • OrderSet
    • Category (Chemotherapy, HIV, etc)
    • Number of cycles typical in the regimen
    • Length of cycles typical in the regimen
  • OrderGroup
    • Cycle number
    • Category (Chemotherapy, HIV, etc)
    • Number of cycles in the regimen
    • Length of the cycles in the regimen
    • Prior Order Group
  • DrugOrder
    • Dosing reduction
    • Chemotherapy administration group (Premedication, Chemotherapy, Post Medication)
  • Maximum Lifetime Dose
  • Drug
    • Units for the maximumDailyDose

For OrderSet, we feel that extending the model via attributes makes the most sense. However, Category might be generally useful for indicating what the OrderSet is typically used to treat, so it might make more sense on the OrderSet object.

We also want to extend OrderGroup via attributes. Again, Category might make more sense on the object, but the rest of the fields would be associated via attributes. Our intent behind a Prior Order Group attribute is to link cycles of a regimen together - so Cycle 2 of a patient’s current chemotherapy regimen would link to Cycle 1 of that chemotherapy regimen.

For DrugOrder, we have considered subclassing DrugOrder to create a ChemoOrder class to hold the dosing reduction and chemo administration group information. However, there does seem to be logical fields in the existing data model for the missing info. The chemotherapy administration group could simply be in the orderReason field, but we are not certain if this field is needed for another use. Dosing reduction is a very important data point for chemotherapy ordering. In chemo ordering in Haiti (which is our main focus), when a doctor orders the chemo medication, they don’t calculate the dosage - the dosage calculation is done by the nurse right before administration. However, the doctor may recommend that whatever the calculated dosage, it should be reduced at administration time by a certain percent. The nurse will then calculate the dosage, and after calculation apply the dosing reduction. The concept of a dosing reduction has been explained as specific to the chemotherapy ordering process, and a vital metric to capture and display to the nurse and doctor and possibly use in future orders and calculations. According to this wiki page, dosing reduction seems like it could be serialized in the dosingInstructions field in DrugOrder.

Maximum lifetime dose is being discussed here - Maximum lifetime dose of a particular drug or class of drugs

A design call is being held this afternoon to discuss these decisions, but any guidance is appreciated here as well!

FYI: @mseaton @ddesimone @burke @darius @ilewis

2 Likes
2

I am struggling a bit about capturing the order group as a separate tracked item rather than just the actual medications. In a typical EHR, the medications themselves would be tracked within the medication history. Order groups are primarily short cuts to ordering several medications at once. For Oncology, don’t we want to keep track of things like which cycle of chemo has been provided, total dose for the round/lifetime, etc.? Wouldn’t these be just a concept construct with Round #, Cycle #, other attributes… rather than persisting the “order group” as separate ordered/tracked order object?

Not sure I fully understand what you are trying to do, so please ignore if this doesn’t make sense :slight_smile:

3

The medications themselves are still an Order, so they still exist within the patient’s medication history, and an OrderGroup isn’t actually an Order object, but just a way of grouping Orders. From our understanding of the data model, OrderSets are the object that should hold the idea of the regimen’s template of medications. Then, when a doctor actually selects the regimen and orders it for a patient, we would use the information from the OrderSet and the modifications the doctor may have made to create an OrderGroup associated with the Patient. The OrderGroup would hold all of the medications as they were ordered for a current cycle - so we’re using it as a way to group the Orders/medications so the doctor understands that these medications were all ordered together as a patient’s chemo cycle. Therefore the cycle number would exist within the OrderGroup - with our suggestion, as an attribute on an OrderGroup. The reason I have number of cycles and length of regimen cycles on the OrderGroup as well is to hold the information for that patient’s specific regimen. The OrderSet would hold the default number of cycles for a regimen, but if the doctor chooses to vary from the default when actually ordering the regimen for a patient, that would be stored in the OrderGroup.

4

So what be helpful is a workflow diagram showing the original content-related pieces and where there is a patient-specific derivation occurring. Something like template produces a standard set of order members, user selects from or modifies x number of those members, creating an order group (which is just the instantiated and modified template) which then produces individual order members etc, (as you described above). Some objects are knowledge or content, and others are instantiated patient data. My reflection above was that the patient grouping of the orders and the meta data around cycle completed, etc. could be in OBS.

5

FYI – Discussed on the 2018-07-25 design forum.

6

Regarding dosing reduction, I would probably approach this as a new dosing_type. The design of drug orders includes a dosing_type and dosing_instructions, where the assumption is the content of dosing_instructions should be understandable by any code that understands the dosing_type. In effect, dosing_type is like a media type (aka MIME type) and dosing_instructions is the payload. The intent is to allow for a variety of dosing instructions that go beyond “take this pill once a day”, including tapers, IV fluids, etc. A dosing reduction instruction could be one of these dosing types. Alternatively, you could build in the dosing reduction into the application (although, I’m assuming dose reduction of chemotherapy might be more tricky than a simple algorithm could handle).

7

CIEL currently has Chemotherapy Regimen concepts mapped to SNOMED codes for each of the ingredient drugs. They are not “sets” mapped to other CIEL concepts with those SNOMED codes. Would it make sense to make them sets to create Concept-drug Concept relationships? The CHOP regimen concept would be mapped to the four drug concepts: Cyclophosphamide / Hydroxydaunorubicin / Oncovin / Prednisone? One issue is that there are often more than one CIEL concept for an ingredient… for example different forms of Doxorubicin (specific salt, liposomal, etc.) Which gets included?

8

Update: Thanks everyone for your thoughts on the call yesterday! It was very helpful.

Our plan is to proceed mostly as discussed, with a few tweaks. Summary -

OrderSets - we will add a Category field, which is a Concept, to the OrderSet table to contain the general category the OrderSet is usually used for. If the OrderSet can be multiple categories, the Category Concept could be a Concept of class ConvSet with multiple Concepts in the ConvSet to represent the OrderSet’s more complicated Category. We will also extend OrderSets with attributes to associate the OrderSet’s number of cycles and length of the cycles typical for the regimen.

OrderGroup - we will add a field called orderGroupReason, a Concept, to denote why the Group was “ordered”. We will also add the fields previousOrderGroup and parentOrderGroup, linking to other OrderGroups, to maintain linkages between groups and support group nesting. We will use group nesting to support the idea of Premedication, Chemotherapy, and Post Medication groups within a cycle. OrderGroups will also be extended via attributes to associate cycle number, the total number of cycles in the regimen, and the length of the regimen cycles.

We will be implementing a new DosingInstructions class, called DosingReductionInstructions, which will capture if the dosage for the DrugOrder has been reduced, and if the reduction is temporary or should be applied to future DrugOrders derived from this DrugOrder (in our case, future cycles will derive information from the previous cycle, including this reduction when appropriate).

We will add a doseLimitUnits field to Drug, which will represent the units of the existing fields of maximumDailyDose and minimumDailyDose.

To capture the concentration of a Drug, we will serialize the concentration value and units in the strength field of the Drug, and our oncology module will assume this serialization when necessary.

We also would appreciate any thoughts on the talk post here which discusses the maximumLifetimeDose of a drug.

9

Hey Andy, hopefully the recording of the design call answered your questions around this, but if you are still confused just let me know and I can explain further in the comments here!

10

It all sounds good except for this bit:

I would rather say order sets can only have one category for now. If you want to later support multiple categories (which is fine), then make the methods/properties for category a list that will happen to only have one element for now. If we want to support multiple categories, then a many-to-many relationship defining all chemotherapy order sets as “any order set mapped to the chemotherapy concept” would be far more straightforward than defining all chemotherapy order sets as “any order set with a category of ‘chemotherapy’ or with a category with a specific concept type that represents a set and maps to a concept_set.concept_id that is chemotherapy.”

11

We don’t see any use cases for having multiple categories - unless there are any objections, we’ll say order sets can only have one category.

12

@burke @akanter or anyone familiar with DrugOrder + DosingInstructions usage/implementations: I think I have a pretty good understanding of how DosingInstructions are used in OpenMRS, except for one particular method called get/set AutoExpireDate()… can someone share reason that is not part of DrugOrder/Order class as opposed to DosingInstructions which has a more a specialized (reduced) scope…? Thank you for any insight anyone can share.

1 Like
13

The idea is that we would like to set an auto expire date on drug orders whenever possible, without the user having to manually select it. for example if the order says to give the drug for 7 days we would want to set the expire date for 7 days from now.

The logic for how to calculate this has to be part of the dosing instructions class, because the order or Service couldn’t calculate it since they don’t know how to interpret the data without the dosing instructions helper class.

if this isn’t clearly documented in the javadoc for dosing instructions interface, we should make sure to improve that documentation.

1 Like
14

One other field we’d like to add - when a doctor creates the regimen for the patient based on the OrderSet template, we’d like to give them the ability to change the “name” of the regimen. For example, a doctor might use the CHOP template to create the chemotherapy regimen for a patient, but remove a medication due to the patient’s allergy, and want to call the regimen “CHOP minus Prednisone” on the patient’s dashboard. We are planning on adding another OrderGroupAttributeType for this field, but aren’t sure if “name” is the proper field, or if it makes sense as a new field on the OrderGroup object instead of just as an AttributeType. Does anyone have any thoughts?

15

I’m curious about the requirement for providers to be able to rename order sets they’ve ordered. There seems to be several assumptions in this requirement. Where/when are users going to see an order group name? I’ve assumed that order grouping data are primarily collected for analysis and not to drive the user experience – i.e., order sets help get the correct orders placed, but once orders are placed the user interacts with the individual orders. In other words, an orders summary on the dashboard would show active orders (not order sets/groups).

From the request, I’m guessing that you expect a provider to be able order an order set and then see that order set on the patient’s dashboard. I could see that driving the desire to change the name if the orders in the order set were altered. But it gets even trickier down that path. When does an order set leave the dashboard? How does this apply to an order set for “First line HIV regimen” or “Cholecystitis Admission Orders”? Would the provider be allowed to act at the order set level (e.g., discontinue it)? If so, then I have a bunch more questions. :slight_smile:

16

Ok, that clarifies it a bit better. We are just absorbing so much in 3 weeks that is hard to process it all real-time. :slight_smile: Thanks!

17

Thanks for your contribution, is there any link to follow up this tickect. j would like to follow up with the issue of adding doseLimitsUnit fiels to drugs

18

Hi Sharif, take a look at this repo branch:

The complete project codebase is documented here:

Thanks

19

Thanks Mr.@dearmasm , j will take a follow up for further contributing and devolopment

20

@dearmasm I have Persistently faced


> `Caused by: org.hibernate.PropertyNotFoundException: Could not locate getter method for property [org.openmrs.OrderGroup#voided]`

See Full Log Here

When Implementing OrderGroupAttribute

See PR Here

I Checked all the .hbm.xml files , and changesets all configured correctly (Except one which i later altered ) but the error seems to persist recursively.