Medication Dispense: Row-per-Order/Medication Request vs "Row-Per-Prescription"

Development
, ,
1

Hello all,

(Sorry for all the separate threads about Medications, but for clarity it seems best to have a separate thread for each discussion).

We are still working through our Medication Dispense designs, but the current design (as designed with input from pharmacists) seems to be based around the idea of a “prescription” potentially containing orders for multiple drugs, ie all the drugs a clinician may prescribe for a patient the end of a visit.

In OpenMRS an Order contains only one order, and in FHIR, a MedicationRequest can only contain an order for one drug.

I’ve been researching how FHIR supports “groupings” of MedicationRequests and found the following:

https://fhir-ru.github.io/request.html#compound

The “RequestGroup” seems to map towards the OpenMRS idea of an OrderGroup, but, from my understanding this doesn’t quite fit our use case and may over-complicate it, as from the description is designed for the “assertion of complex timing and other dependencies between a collection of request”.

Our use case seems more in line with the “requestionId” model, which “generally by the same practitioner at the same time for the same subject. The “requisitionId” represents the identifier of the prescription, lab requisition or other form that was shared by all items.” (emphasis mine)

It seems like this this practically done via a “groupIdentifier” stored on the Request object, and I’m wondering if we’d want to consider adding “groupIdentifier” as a property of OpenMRS Order to mimic this functoinality.

Another option would be just to group the orders on encounter, but I hestitate a bit as my instinct is to keep grouping functionality as explicit as possible, and keep the Medication Dispense functionality in the Request/Dispense domain as much as possible to avoid potential API bloat.

As a (somewhat) practical example, consider the initially table/list displayed in the Medication Dispense model (note that although most rows have only 1 drug, the design allows for multiple drugs):

2022-03-24_12-44_1
2022-03-24_12-44_11106×504 93.7 KB

What would be the proper endpoint to fetch this? MedicationRequest elements, grouped by groupIdentifier? Grouped by encounter?

Or should we rethink the design to a stricter “row-per-Medication Request/Order” model?

fyi @mseaton @pauladams @grace @bistenes @ddesimone @burke @mksrom @mksd

Thanks and take care! Mark

2 Likes
2

In our discussions so far I have assumed that Encounter is the logical grouping that would equate to this, so that’s my uneducated view. Interested in hearing from others like @burke and @ibacher and @jteich on their experience.

1 Like
3

Yeah, I would think encounters are the right way to do this.

In purely FHIR terms, I wouldn’t expect to see a RequestGroup here; if you really needed to group MedicationRequests together you’d probably just have a List resource, but I’m not sure how useful that is.

1 Like
4

Yeah, I’d definitely be reluctant to go with RequestGroup, but was more thinking we may want to explicitly tie orders together with a groupIdentifier. But maybe encounter is the way to go.

If we did go with using encounter to group, @ibacher thoughts on the FHIR request we’d use to fetch the data to populate the above list? I

The key element is that in the preferred workflow there are 1 to n MedicationRequests per row in the above table. Would we handle that at the request time (preferred, I think?) or rely on the client-side code to do the grouping? Would we do this in the single request or multiple requests? Would we make a very specific endpoint to get us what we need? (Further complicating matters, we need the MedicationDispense details associated with the orders to correctly populate the “Last Dispenser” and the “Status” columns, though that could potentially be “Phase 2”).

For example, is it:

  • Fetch all Encounters that have at least one MedicationRequest object; include all the MedicationRequest objects associated with that encounter, fully resolved

  • Fetch all MedicationRequests, but group them by encounter

  • Fetch all MedicationRequests as a single list and the client-side app is responsible for grouping

  • Some totally custom-named endpoint we design? (That potentially returned a List, or List of Lists?) (And, if so, where would this endpoint “live”)?

Beyond the pseudo-code, what would the request look like?

Maybe I’m overthinking, but using FHIR for the first time I’m just trying to better understand how this would work/look in practice, and want to make sure we do it right (or as close to “right” as possible!)

Thanks and take care! Mark

also, fyi @bistenes

1 Like
5

There are options here depending on exactly how we decide to go. One problem is that FHIR doesn’t really have a great mechanism for grouping things natively, so if grouping on the backend is a requirement, we should be a custom operation. This isn’t hard… custom operations are basically FHIR’s equivalent of a named, parametrisable query.

The FHIR search mechanism does allow us to get the requisite data and potentially in a few different ways.

Probably the most straight-forward version of the query is this:

/ws/fhir2/R4/MedicationRequest/?_include=MedicationRequest:encounter,MedicationRequest:patient&_sort=-date&_summary=data

This would give you a FHIR search result bundle of all medication requests as well as the encounter and patient objects associated with them. You’d probably want some additional query parameters, but that would give you all the medication requests and the associated encounter and patient objects. The frontend would need to do the grouping in this model. (We also need to ticket supporting sorting by date for MedicationRequest as that doesn’t seem to be implemented).

As I indicated above, we could also design a FHIR operation that would do anything from returning something like the above bundle in a more sensible format (e.g., so the encounter and patient are “near” their first occurrence) to returning an entirely custom response. This, of course, means more work implementing things on the backend but could potentially make implementing things on the frontend a bit easier.

Or, of course, we could always try to implement GraphQL for FHIR, though that’s a pretty massive undertaking…

Edit

Just realised to populate the full thing, we also need any associated MedicationDispenses. Since, in FHIR, the relationship between dispenses → requests is on the dispense side, we’d need to change the above query to:

/ws/fhir2/R4/MedicationRequest/?_include=MedicationRequest:encounter,MedicationRequest:patient&_revinclude=MedicationDispense:prescription&_sort=-date&_summary=data

And, of course, implement the logic to load the dispense events.

2 Likes
6

Awesome, thanks for the detailed advice @ibacher … I do agree that considering a custom backend operation seems a definite possibility, but would also be cool if we didn’t have to set up a backend module just to provide custom FHIR resources for the Medication Dispense UI, but it may be inevitable.

I’m not going to get a chance to dig into this again for the next couple days, so you’ll get a break from questions from me, but hope to get back to it mid-week next week… :slight_smile:

Have a great weekend! Mark

1 Like
7

I’d be happy to put a custom operation like that in the FHIR2 module, really. The only real limitation I have is that I don’t want the FHIR2 module to have to depend on anything other than core :slight_smile:.

1 Like
8

Thanks… I will move for with the idea of grouping by encounter, but would also like @burke 's thoughts when he has a chance to weigh in.

From talking with @pauladams and @ddesimone on Slack it seems clear that on, from the business rules/UI side, the idea of “prescription”, which can contain 1 to n orders, will be a “first class” data type. See the discussion on the #dispensing channel on Slack.

Take care, Mark

9

Hmmm… it would be good to have some clarification on this point.

If the “prescription” is for multiple medications prescribed together (to draw from the designs: Lamivudine + Zidovudine), this should be a single order for the “drug” Lamivudine + Zidovudine with (potentially) two ingredients rather than two orders, one for Lamivudine and one for Zidovudine. This is consistent with, e.g., how things are modelled in the WHO EML where we have Lamivudine, Zidovudine and Lamivudine + Zidovudine separated out.

This is, I think, different from ordering, say Lamivudine (for HIV) and Ethambutol (for TB), in which case we have two “prescriptions” and two orders potentially linked by one encounter.

10

Agreed, thanks @ibacher !

In the above case (two different, unrelated medications for the two different diseases), my uneducated thought would be that these are separate “prescriptions”, but I think from what I’m getting from Paul in the pharmacist mental module this would be one “prescription”? Or maybe the terminology we are using is wrong?

I think it’s important to properly define what this logical grouping is and what it’s called. Is it simply “all the orders placed within an encounter”, or do we need some sort of other, deliberate grouping. My hunch may they are thinking of it as “all orders placed on a single (paper) prescription form”?

This was where I originally got the idea of using the FHIR “requisition id” which, in the FHIR specs says (emphasis mine):""The Request.requisitionId element allows multiple requests to be linked as having been created as part of the same “event” - generally by the same practitioner at the same time for the same subject. The “requisitionId” represents the identifier of the prescription, lab requisition or other form that was shared by all items."

Thoughts @pauladams @ddesimone @mseaton @bistenes @grace ?

2 Likes
11

Just posting @pauladams comment from Slack for reference: ‘We had a fairly thorough process of design iteration and feedback around this so I’m a little hesitant to change it on the fly. I think the concept of a prescription, which may contain one or more medications seemed to align with the Pharmacists mental model.’

12

I just want to make sure this concept is clearly stated. In the table that @mogoodrich posted at the top of this thread, every line requests exactly one drug. 3TC + AZT is a single prescription for a single combination drug (trade name: Combivir, among others) that happens to contains two active ingredients – or two medications, if you will. But it’s still one prescription for one particular pill. In any normal record-keeping, the combination would be treated as one drug and listed on one row of the patient’s medication list, prescriptions list, etc. @ibacher also noted this above, I just wanted to re-state it.

The point is that, as far as I know both from clinical and informatics experience, a prescription is for one drug. 99.9% of written prescriptions are for one drug (although some might be combination drugs, like Combivir or Bactrim / Septra or many others; Americans will know many combination drugs such as Nyquil or Excedrin – each of these counts as a single drug). If you write or print prescriptions for multiple drugs you use multiple prescriptions; and the pharmacist would certainly enter them separately even if a sloppy doctor wrote more than one prescription on one form. The idea that the pharmacist would take unrelated orders, like Lamivudine and Ethambutol, and consider them to be one prescription doesn’t jive with my experience.

So I would have expected that a prescription would always be for one order. And I expect the phrase “prescription, which could contain one or more medications” may be casual use of language thinking about a prescription for a single (combination) drug.

BTW, I agree that grouping by Encounter makes the most sense.

1 Like
13

Hi everyone. @jteich, thank you for your reply and clarity.

To be very clear, the row in the Dispensing design represents an ‘Order’ in OMRS at the prescribers side. The use of ‘prescription’ in the Dispensing screens arose from feedback that an Order to a Pharmacist would be the act of them ordering stock for the Pharmacy.

We captured a requirement that this may include more than one medication - by that, it was understood to mean separate medications, not only a combination of drugs as a single drug, as mentioned above and indeed shown in the design. To that end, the designs show multiple ‘Medications - or items’ as a possibility, as well as when one Medication has been filled but another has refills remaining and our user testing aligned around this idea.

I’m happy to reconnect with some of the Pharmacists around this if you all feel like it would be useful? I know the use of language here is key and that it may differ depending on in or outpatient settings?

14

Thanks @jteich and @pauladams …

@jteich what you said was what I originally assumed, and makes the most sense to me as a layperson. But from talking with Paul it seemed clear (as as he clarified above) that the intent was for a “prescription” to contain what would be (to me) 1 to n separate “prescriptions”. Although it’s not clear, I think the highlighted row in the display above does contain orders for two separate drugs, “3TC + AZT” and something that starts with “Generic D…”

Yes, @pauladams it would be great to go back to the pharmacists around this. Note that I’m not necessarily opposed to having multiple drug-orders-per-row, but we should be clear about the expectation/rules on how they are grouped together and the naming conventions. And since this seems like a fundamental element of the UI it worth at least considering having some explicit modelling on the back end rather than “all the orders within an encounter by the same provider”.

@grace this seems like a key element to resolve to moving the UI forward. Would make a good TAC discussion, but unfortunately I’m likely going to have to miss the TAC next week.

Take care, Mark

1 Like
15

Here’s another screen shot for reference … note the ability to add additional drugs when filling a paper prescription…

fill paper prescription
fill paper prescription1199×760 138 KB

16

Yes @pauladams it would be great if you are able to get thoughts from pharmacists, and I have a question in to the PIH Pharmacy Director. Because, I think the question now isn’t “what is a prescription?” as much as “what’s the best UI experience for the pharmacists”.

I’ve been thinking all along that would be one-row-per encounter, but let’s see.

17

From my perspective, it’s worth re-checking with the pharmacists just because this is very different from the pharmacist viewpoint I’ve inferred from my various past projects working with them. If they reiterate the multiple-drugs-per-prescription policy, I have no further concern.

I have, rarely, seen a doctor write for two forms of insulin on a single paper prescription (but not in an electronic ordering system) since many patients take two forms; but in the pharmacy system that was broken down into two records. I assumed the doctor knew that and was just trying to save time.

18

Workflows can certainly be defined that make it convenient to prescribe more than one medication at once. A common example would be a single piece of paper that table for prescriptions, allowing providers to write one prescription per row. Another would be a piece of paper with a list of predefined prescriptions on which the provider simply ticks the ones she wants to prescribe +/- minor edits.

In any case, a pharmacist might see a collection of prescriptions coming through on a single piece of paper. While they might, in some cases, refer to that set of prescriptions as a “prescription”, like @jteich, I wouldn’t get caught up in trying to use the term “prescription” to describe 1-to-n medication orders. I would stick with the widespread understanding that a “prescription” is a single medication request and its okay for a piece of paper to include multiple prescriptions.

As for grouping, there are a few options:

  • Order sets and order groups. Order sets are meant to define a set of orders (not just medications) that belong together for convenience or a specific purpose (e.g., a drug regimen, a predefined list of common orders from which a provider selects those to be done, etc.). Order groups are meant to persist the knowledge of which orders were ordered together (from a set), so we could know these meds were ordered together as a regimen or those orders were all selected from the “Fever Workup” order set.
  • Encounter. An encounter is meant to represent the clinical transaction between patient and provider/healthcare system.
  • Technical transaction. This doesn’t exist in OpenMRS (yet?), but we’ve previously run into situations where we want to capture the fact that a set of data were generated together at a technical level (e.g., a provider just added this allergy and changes these two medications and submitted them) that doesn’t always align 1:1 with the clinical transaction.

I would imagine for the medication dispensing, the encounter would be the most natural & quickest solution for logical grouping of prescriptions that belong together. If there are cases where you want to record groupings of prescriptions that don’t align 1:1 with the clinical encounter, then we could use order groups +/- investigate if this is a need for introducing the technical transaction data.

19

Thanks @burke … I was reluctant a bit about grouping by encounter, but from what I’m hearing from here and from talking with @mseaton and others offline, it does seem like using encounter as the grouping element seems to be the consensus.

@pauladams does this seem like the proper description of what a row in table should represent (stealing a bit from Burke’s description):

“All medication orders placed within a single clinical transaction between patient and provider/healthcare system.”

Take care, Mark

20

Getting back to the details of implementing, I went ahead and started a ticket for this:

https://issues.openmrs.org/projects/FM2/issues/FM2-466

A few thoughts:

  • I wrote it up as a custom endpoint, with the grouping by encounter happening on the server side; this seemed better to me and as you said would likely make building the UI easier. Also, it abstracts out the logic of how to group the requests from the UI, in case we need to tweak that logic in the future
  • I just noticed as well that there was no date as it’s not currently implemented on MedicationRequest; looking into it, I think the encounter datetime of the underlying encounter is what we’d like to use as the date; orders need to be related on an encounter so we should be a to count on that date being present

Would be great if you could review the ticket when you get a chance @ibacher (I don’t think it’s a huge hurry, I think we are a few weeks out on working on this as minium) and let us know your thoughts. If there are any examples of existing custom responses in the FHIR module could you add a link to them on the ticket as a reference?

Thanks so much!

Take care, Mark