Request: Can we agree on a way forward for modelling how drugs are configured and represented in O3 drug orders? 3 options available; described below. Need a preliminary decision asap.
- Urgency: UCSF devs this week are going to work on connecting the O3 Drug Orders feature to the Drug Concept admin / iniz drug csv (partly in response to my own suggestion). Ticket details here: [O3-1185] ConnectOrder Basket Medication List to Concept Drug list - OpenMRS Issues
- The concern: OMRS data model currently supports a typical formulary-based ordering approach, not a prescribing/physician-mindset-approach. O3 Drug Ordering was partly UX-designed with the prescribing workflow in mind.
- Options: Based on conversations with @ibacher and @jdick, I see 3 ways forward:
Option #1: Apply the legacy OMRS formulary-based data model, as an MVP (My Preference)
Rationale: this will accelerate us actually completing the feature, so we can get real-world feedback. Based on that, sure, we can further improve the data model and the feature. I just don’t want to see prescription-perfection cause unnecessary delays, especially because many resource-limited sites have clinicians thinking in formulary terms anyway (e.g. giving patient ARTs directly from a supply on the physician’s desk), and because in many RefApp 2.x applications it seems to me like the formulary mindset is already being used. (@mogoodrich am I wrong?)
Option #2: Learn from Bahmni’s approach; adapting the current model to still work with prescribing (@ibacher’s strong recommendation). Apparently Bahmni already worked around this exact situation with some creativity. See for example @angshuonline’s explanation here:
- Bahmni stores dosage as a JSON. and there is an associated processing class that handles this.
- One good thing to do would be to store a typical FHIR “Dosage” datatype in the JSON. So that everyone speaks the same standard atleast.
(@ibacher is this what you had in mind? Or was it this FHIRMedicationOrderMapper, or something in the treatment config here?)
Option 3: We roll up sleeves and spec-out the Data Model & Backend needs for full Prescribing.
I do not believe this is the most efficient or effective use of time and resources - I’d rather hear explicit requests for this from the field areas where OMRS is used. If someone knows this is a resounding request, please speak up!
To be clear, I’m in favor of all of these options; I just believe we should start with Option #1. I’d like our technical folks to either reassure me this is the right direction, or to convince me otherwise.
CC @burke @mseaton @dkayiwa @mksrom @dkibet @dkigen @bistenes @ssmusoke @eudson @pmanko
Was this going to be on the agenda for tomorrow, or was this for a future discussion? I know there was a request to have a presentation from INTEROPen-OpenEHR?
Alas, I’m travelling and will miss th e TAC tomorrow, but will try to get myself up to speed on the discussion and weigh in soon…
Thanks @mogoodrich - do you have any preference (based on the dispensing work/modelling you’ve already been doing) about using the existing formulary model?
@grace and all. The assumption I have always worked under is that the drug table (formulary) should always form the initial basis of what can be ordered. This doesn’t have to mean that clinicians need to place orders for specific meds in the formulary, but it should mean that the drugs that are in the formulary represent the range of possible things that can be ordered at the concept level. In the work I did to bring drug order entry into htmlformentry, this typically meant first a clinician would choose the “concept” to order (and this would be constrained by those concepts associated with drugs in the formulary). Then, they could optionally specify an actual drug formulation (limited to those drugs linked to that concept), a free-text formulation, or no formulation. This is also what I understand to be consistent with the OpenMRS API and validation rules.
The additional JSON configuration that was added to the medication ESM is, from what I understand, based on Ampath’s application and how it was designed. I had assumed that this was additive to the above, just providing additional metadata around these possible orderables to provide a set of typical values, to allow for users to easily access and order the most common combinations of dose/frequency/route for a given drug. I don’t think it should be completely disconnected from the above.
That said, one weakness/limitation of the formulary-based approach is that there is no way to indicate a history of the formulary (eg. these drugs used to be in the formulary, but are not currently in the formulary) without retiring the drugs. This can lead to issues, particularly with retrospective data entry, and it might be useful to think about other ways to handle this situation.
Happy to discuss at our TAC today or in another forum.
Yep, I was going to say that @mseaton has a deeper understanding than me and will likely weigh, it, which he has. +100 to what he says.
To highlight a few points:
In the Medication Prescribing/Dispensing workflow, I was working the assumption that drug orders would be modelling using the current OpenMRS Drug Order object/table (which as @mseaton says means linking to both an OpenMRS Concept and OpenMRS Drug). This is how we do ordering in the PIH EMR via the HTML Form Entry tag, and I’m pretty sure that’s how the Ref App 2.x order UI works. If the O3 ordering only creates a Order, not a Drug Order this seems both inconsistent and incorrect to me
When building the Prescribing/Dispensing I didn’t have any custom configuration for any medication ESM on my radar; I strongly believe, at least in the mid-to-long term, we shouldn’t be relying on configuration logic build only on the O3 side, which is sounds like is what the ESM order might do… as Mike said, it should not be disconnected from the Drug modelling in OpenMRS Core
Like Mike said, one thing that is lacking in the current model is a way to distinguish what Drugs are currently available for ordering (or available in the current context)… we need a way to configure which subsets of Drugs in the drug table are available at any certain time, but this seems like a separate issue that can we handled without a whole new configuration mechanism
So, if I understand it correctly, my vote would be to go with Option #1, but if we do find it lacking, pursue Option #3… ie improve the data model to do what we need to do. Don’t work around it (which I think might be what Option #2 is suggesting).
In reading through the INTEROPen document, I opened a link to the NHS order/prescribing link and this interesting wiki came up: FHIR Dose Syntax Implementation Guidance | Dose Syntax Implementation for FHIR
I have not reviewed their IGs, but thought it relevant model for comparing a dose method and a product method for prescribing.
To summarize from our 2022-03-30 TAC call, we reviewed these aspects of drug orders:
||Active ingredient (the drug the provider wants the patient to get)
||amoxicillin 500 mg capsule
||The form of the drug available (e.g., stock item)
||amoxicillin [250 mg,500 mg] [by mouth,by feeding tube] [three times daily,four times daily]
|How the drug can be (or is typically) ordered.
amoxicillin 500 mg by mouth three times daily
amoxicillin 1000 mg by mouth three times daily
|Predefining a set of orders appropriate for a specific use case (multiple drug regimens, treating specific conditions, etc.)
We decided that we need to introduce order templates as a first class citizen within OpenMRS. We’d like to model these aligned with FHIR’s model. A workaround for existing/previous versions might be to introduce these order templates within one catch-all order set (since order set member does have a space for order template), but we ultimately want order template to be a first class citizen that can be associated with a drug outside of order sets.
Our near term goal will be to create a new Talk thread to start modeling order templates.
As far as the opportunity to make urgent progress with UCSF and drug ordering for OpenMRS 3.x, any work to pull drug formulation information from the drug table (instead of frontend JSON config files) would be a step in the right direction.
FWIW, here’s the recording from 2022-03-30 TAC call:
Following up our TAC Call from yesterday 2022-06-06. I agree with @burke’s comment and that’s exactly what is missing for the work done on the frontend to be completed. I will create a new post so we can start modelling