Plans for integrated prescribing/dispensing workflow

Implementing
, ,
1

Hi,

At PIH, one of our EMR priorities has become integrating prescribing and dispensing functionality as our users have expressed a need for a paperless workflow there. We are currently doing requirements and use case collection. Our high level needs are tools for:

  • pharmacy staff to view all medications prescribed
  • pharmacy staff to be able to indicate what/how much of medications are dispensed (at point of dispensing)
  • clinicians to be able to view what was prescribed/dispensed in a convenient, consolidated place

Would be interesting to:

  • hear from implementations that have successfully done this (e.g. Uganda and Nigeria have done this in OpenMRS 2.0 I think?). How has it been working?
  • discuss the best approach for this that are aligned with the OpenMRS roadmap.

Should also mention that we are aware that some of this functionality exists in certain third-party supply chain/ERP systems. This is probably not an option for us as we use OpenBoxes for this at most of our sites, which has limited functionality in this area. We can discuss extending OpenBoxes for use as the pharmacy UI, but so far we have been thinking of building/configuring OpenMRS for this.

Would be great to kickoff the discussion here and continue it at next week’s Technical Action Committee meeting.

fyi @mogoodrich, @grace , @burke , @jteich , @jdick , @mksd , @ball, @ssmusoke , @samuel34 , @ggomez etc…

Thanks, Dave

3 Likes
2

Thanks @ddesimone for bringing this up.

If we assume a situation where everything happens within OpenMRS, so a situation where there is one system used by clinicians to prescribe medications and pharmacists to dispense medications; then how fundamentally different are those two points?

3

@mksd , you are right in that if pharmacy staff indicate on OpenMRS that a prescription was dispensed, that order will be updated and available to be viewed by the clinician. But we don’t currently have a consolidated medications view in our distributions, so we will need to build (or collaborate on) one.

4

Thanks for all the discussion around this on Talk and on TAC calls.

I know that there was some concerns from @burke and others about not building a full-fledged pharmacy system within OpenMRS, so people may want to talk me down from this one, but at a high-level (still a lot of weeds to work out) what do people thing about:

  • Building stand-alone “Pharmacist app” in OpenMRS 3.0 framework. @ddesimone can provide the full use cases for this, but, generally, pharmacists would be able to bring up recent orders based on date and/or patient and then dispense medications based on those orders

  • (The likely more controversial part) To support this, in OpenMRS Core/REST WS, add support for a new domain object, “Drug Dispensed” (or better name?) to track medication dispensed to patient. This would roughly be modelled after Order and Drug Order domain objects, likely having fields like:

drug_dispensed_id
order_id - links to the order that led to this dispensing event (allowed to be null)
dispenser - links to user table
date_dispensed
concept_id - links to the concept reflecting the drug dispensed
drug_inventory_id - links to the drug dispensed
drug_non_coded
frequency
quantity
quantity_units
duration
duration_units
dose
dosing_type
dose_units
dispenser_notes - (free text)
Base metadata: creator, date_created, date_updated, date_changed, etc…

The alternative to doing this would be to module drugs dispensed as obs and obs groups (which is what we are doing now in the Dispensing module) but then the Pharmacist app would have to be built around these concepts, which can get ugly pretty quickly.

Thoughts? Again this is very rough, I can try to spec out things in more detail, but wanted to get a gut reaction to this approach. @dkayiwa @ibacher @mseaton @mksd @burke

I think the general idea would be we’d track patient-level drug information within OpenMRS using a first-class domain object. This seems like a valuable and key thing for OpenMRS to support. Inventory management and aggregrate drug and drug availability would be something that’d we’d defer to an inventory management software.

Thoughts?

Take care, Mark

1 Like
5

Instead of putting this in openmrs core, i would do it in a module for more flexible release cycles and iterations. Once stable, it can be a candidate for moving into core. And this transition is easier when the class and package names in the module are exactly as they will be in core.

I do not like this alternative because it looks hacky. :slight_smile:

This approach makes a lot of sense to me. We shall always have implementations which do not have what it takes to manage more than one system. So having whatever we can, within OpenMRS, will always have real world simple use cases. Then we leave the complicated integrations to those who have the advanced use cases and the required resources.

And just incase we can pick some lessons from here: OpenHMIS Pharmacy Module - Projects - OpenMRS Wiki

6

Thanks @mogoodrich for sharing this. I tend to feel quite strongly about the separation of concerns, and specifically about not modelling in a system (EMR) what pertains to another one (pharmacy + drug inventory).

This is not to say that it should not be done at all, but it should be challenged until it can’t anymore IMO. Does that mean that you guys have ruled out using a third-party pharmacy system?

I remember the conversation about developing a dispensing UI for OpenBoxes. Out of curiosity, if you would be willing to go all the way to do that in O3, why not simply in OpenBoxes then?

7

So, actually, I’m quite in favour of this. My mental model is that there are four things related to medicaitons that an EMR should track:

  1. The medications a patient is on (sometimes called the medication list). This can include both medications the patient is on due to an EMR process (like ordering a drug) and medications reported by other sources (including patient self-reports).
  2. The medications that were ordered by a provider for a patient. This is what OMRS does pretty well in the form of the DrugOrder.
  3. Medications that were administered to the patient. This is most relevant to inpatient care, but is useful for tracking exactly when a given medicaiton was given, in what form, for how long, etc.
  4. Medications as they were dispensed to patients, usually as a result of an order. From an EMR perspective, the important things to track are: when the medication was dispensed and any variations between what was ordered and what was actually given to the patient.

Adding first class domains to track those different but related things is something I’m all in favour of.

Some points on the rough model offered here:

  • Dispenser should probably be a provider rather than just a user. (This might vary depending on local details, but I’d imagine that the dispensing is done by either a pharmacist or someone acting as a pharmacist and a pharmacist has most of the other characteristics associated with providers, i.e., it should be possible to record encounters with a pharmacist where the pharmacist is the encounter provider).
  • drug_inventory_id I’m a little bit hesitant on. If this is something like the accession_number field on order, which is used to reference an identifier in an external system, I think that’s fine, but if it’s linked to an actual table, then implementing this domain model requires that the actual drug inventory be tracked in the EMR and I don’t think that’s a requirement we should be enforcing (i.e., this data model should be useable both by installations that are tracking pharmacy inventory through external systems and those that might use a module to add inventory tracking to OMRS).
  • duration is also a little iffy to me. To me, the relevant concept in the drug order table corresponds to something that would be captured by a “DrugAdministration” domain rather than a “DrugDispense” domain. The equivalent FHIR resource (MedicationDispense) does have a daysSupply field, but that’s roughly equivalent to quantity.
  • It’s probably relevant to track two dates (or, even better, date times) for dispenses: the time the medication dispense was prepared and the time is was actually handed over to the patient.

Yeah, that sounds like a mess.

As is probably clear from the remarks above, I’m more hesistant on the idea that a “Pharmacist app” in the EMR is something we want core support for. My main concern is that the existance of such an app seems to require that pharmacists do double-entry (i.e., take the order from the EMR, log the relevant details in the inventory management system, update the inventory management system to indicate the supplies withdrawn, update the EMR with the med dispense information) and having computer systems designed for this kind of double-entry is only marginally better than trying to maintain both paper and electronic records. In other words, its a pattern that might work well for local circumstances, but probably not how we want to encourage people to design things.

8

Thanks all for the thoughts! To response to them:

Implementing in OpenMRS Core vs a Module

@dkayiwa yeah, I’m of two minds on this. Generally the practice we follow, as you said, is to implement in a module and then migrate to core, but a lot of times it is because we (PIH) are always a few Core release cycles behind… in this case, we are running 2.3.x now so it might not be too much work to get us to Core 2.5.0-SNAPSHOT, and, if we can do that, would it be valuable to build it into Core directly? From the PIH side, it would actually be easier to build it into a module and then leave it to someone else to move to Core. I guess it depends on how much of a consensus there is from the start about the design. If there’s pretty good consensus, and it’s easy enough to get the PIH EMR up to 2.5.0-SNAPSHOT might make sense to build it into the Core directly.

Implementating In OpenBoxes vs OpenMRS

@mksd we have not ruled out using a third-party pharmacy system, but there hasn’t been much response on the thread about that, so not sure what there is out there. @jdick @burke would be good to get Ampath’s thoughts Maisha Meds. It looks mainly like an Android app?

Building the functionality I describe into OpenBoxes would certainly be possible, but assuming we don’t use a Pharmacy system, the information I’m suggesting storing in OpenMRS seems clearly more appropriate in an EMR than a supply chain/inventory management system. OpenBoxes doesn’t track anything at patient-level, and adding patient-level data to OpenBoxes seems like a bigger case of not separating concerns (and a patient data security concern) than adding patient-level dispensing information to OpenMRS.

Note that in the proposal I’m not talking about doing any inventory tracking in OpenMRS… that would be something we’d want to track in OpenBoxes. There has been an ask for a doctor to be able to know what drugs are available at order time, but this would be a future phase feature, and I would think that we’d probably just want a flag on the OpenMRS drug table as to whether or not a drug is available, but I would not want to start tracking quantities on hand, etc, in OpenMRS. I could foresee a the future when a drug_dispensed record is saved in OpenMRS, it sends a quantity-dispensed message to OpenBoxes, and then OpenBoxes reports back if there is now a stock-out, but that’s way down the road.

Modelling

Thanks @ibacher … might be worth probing a little deeper into medications administered vs medications dispensed. We are talking more about a medications dispensed right now, but would be interesting to discuss whether we think medications administered would be a complete separate domain objects, or “administered” would be an extension of dispensed (since every drug administered is assumedly also dispensed)?

To your smaller points:

  • Good catch, dispenser should definitely be a provider
  • drug_inventory_id is just drug_id, ie the key to the drug table in OpenMRS. I just pulled this from the drug_order table in OpenMRS, and for some reason it’s called drug_inventory_id there. But there’s probably some historical, deprecated reason for that; but, no, I’m not in favor of tracking drug inventory in OpenMRS
  • Agree that duration is questionable, and more a property of the order than the dispensing event. Worth probing that a little more with our team.
  • Having two datetimes seems like something we might want, but maybe a little overkill until we have a real need? I think the key here would be to make sure the variable name we chose is flexible enough (“dispensed_datetime”?) to be clear if we want to add other dates to track other things (“preparation_date”, “administered_date”?)

Regarding the pharmacy app question: yeah, we want to avoid double-entry, but, assuming we don’t add a Pharmacy system and we only have two systems, EMR and supply chain/inventory management, it seems like EMR is the more appropriate for the Pharmacist to be using.

Thanks for all the insights everyone, let’s keep this discussion going, as there’s some pressure at PIH to move (relatively) quickly on the.

Take care, Mark

9

also flagging @grace

1 Like
10

Generally, this would be the ideal, because we do not have to look for more resources to migrate it into core, and then test the migration. :slight_smile:

1 Like
11

I agree with @ibacher’s comments.

Thing Relation to OpenMRS Notes
Active medications (medication list) Core aspect of an EMR Includes medication reconciliation (validating the list matches what patient is actually taking). Varies by Care Setting (e.g., outpatient, emergency room, inpatient)
Medication orders Critical for the EMR Part of order entry.
Medication Administration Module The most common use case is a MAR (medication administration record), which could be implemented as a module. But having a MAR module that’s widely useful to the community and part of our out-of-the-box system would be terrific.
Medication Dispensing Nice to have info available to EMR. Dispensing is out of scope for core. Knowing what was dispensed is useful for the EMR. Managing dispensing of medications is in the purview of a Pharmacy system, if one isn’t available, a module.

I would consider FHIR’s MedicationDispense resource, which includes a dispense status and status reason as well as separate timestamps for when the prescription was prepared vs. actually given to the patient. You’ll also want location to know which pharmacy dispensed the medication (whether done via an OpenMRS pharmacy module or received from an external system).

It’s fine to persist dispensing information in OpenMRS for reference, but I would not assume that OpenMRS will be managing medication dispensing. There are certainly scenarios where dispensing information would be coming from other systems. For example, here are a few likely real world scenarios:

  • Running a pharmacy module that directly populates this dispensing information in OpenMRS
  • Integrating with an external pharmacy system and using a module to pull or received pushed dispensing data from that external system to populate dispensing information in OpenMRS
  • Receiving dispensing information from dozens of regional pharmacy systems (either directly or through an HIE or other centralized service) and copying it into the dispensing information within OpenMRS.
  • Some combination of the above scenarios

Not necessarily true. We cannot assume dispensing will be done within the OpenMRS system and there’s not necessarily a typical dispensing event within inpatient settings (e.g., meds delivered to the nurse for administration not through the same processes for outpatient dispensation).

Agreed, but through a Pharmacy module. Pharmacist-facing functionality within an EMR is a workaround for the lack of a pharmacy system. It would be expected for systems that use a pharmacy module in the EMR to eventually evolve to using a separate pharmacy system, so nothing in the EMR (core of OpenMRS) should depend on the pharmacist working within the EMR. That’s the main reason for putting pharmacy-specific functionality into a module instead of baking it into the EMR.

12

Great discussion! I’m just catching up on this thread, but one question on this point from you @burke :

The question for me then becomes - how does this impact where we store this information in OpenMRS? One way or another, we need to persist dispensing information in OpenMRS, whether it is coming in from an external system or being collected directly. And if we are going to try to standardize on the modeling for this in OpenMRS (to help with sharing standards, reports, UI display widgets, etc) then we either need to come up with a shared model of nested Obs and Obs Groups (which is what PIH has been doing), or we need a dedicated table (which is what @mogoodrich seems to be proposing).

I’m gathering that your vote @burke would be to have a dedicated table, but for this to be owned and created by a module, because you don’t feel that medication dispensing is the purview of an EMR. But I’m not sure I quite agree - the presence of a structured table does not imply that OpenMRS is the primary “manager” of this data. For example, let’s say we were to make OpenMRS 4.0 built on top of a FHIR database. In this case, we would have dedicated resources in OpenMRS for “MedicationDispense”. This seems to me to be the same thing as a dedicated table in the current OpenMRS core data model.

I’m not necessarily advocating for this, I’m just trying to understand the positions from those involved in this discussion and make sure we are arguing the correct points.

Thoughts?

13

Thanks @ddesimone

14

Thanks everyone…

It seems like there’s a consensus around adding first-class modelling of “Medication Dispensed” to OpenMRS, trying to model it as much as possible around the FHIR modelling of “MedicationDispensed”. There seems to be a question of whether this belongs in Core or in a Module, but I think that is a detail we can continue to hash out. I will start a wiki page with a proposed design for it, and link to it from here.

As for the “Pharmacy App” overall, although we are still researching possibilities, it does seem like we are leaning toward building a “lightweight” Pharmacy “app” or “module” in OpenMRS that provides the functionality that @ddesimone mentioned above:

  • pharmacy staff to view all medications prescribed
  • pharmacy staff to be able to indicate what/how much of medications are dispensed (at point of dispensing)
  • clinicians to be able to view what was prescribed/dispensed in a convenient, consolidated place

Note that that a key thing making this “lightweight” will be our primary use case, where: 1) the pharmacy is “in-house”, ie in the facility where the orders are placed (and OpenMRS is running), and 2) the medications are free-of-charge (ie, the app doesn’t need any payment/receipt/customer/insurance/etc functionality)

There is desire, down the road, to integrate with our back-end supply-chain software, but this will not be a Phase 1 (nor likely Phase 2).

A high-level design question:

In the OpenMRS 1.0 or 2.0 world, a “Pharmacy Module” would likely be an OpenMRS Module with a capital “M”… ie a omod that bundles the new domain elements, business logic, and UI… but have we given thoughts on to how to would work in the 3.0 world?

I would assume that the new “MedicationDispensed” domain object would either be added to Core or added via an omod, and I would assume that the UI would be provided by a 3.0 MFE. But what about about any business logic? My initial instinct would be to incorporate that into the client-side app, but do we have any patterns for doing that, ie for splitting business logic from display logic within a MFE (I’ll take a look at some of the MFE ode)? Or do we still want provide a Java-based API via an omod? And if there are separate components, how would we bundle them all together to distribute?

Thoughts? Perhaps something to discuss at next week’s TAC? @dkayiwa @mseaton @bistenes @burke @ibacher @mksd @mksrom @florianrappl @grace others?

Take care, Mark

15

@mogoodrich my understanding has always been that the 3.0 MFE is about the user interface, which connects to the server side business logic via REST. Did i get this wrong?

16

Yeah, @dkayiwa … that would have been my initial thought as well, but, thinking it through, I wanted to review with others.

I think the general idea is that the MFE will ideally be working with FHIR representations (of, if not, OpenMRS REST representations). Do we think that the MFE should generally be only requesting “vanilla” FHIR representations and do manipulation on the client-side?

For instance, probably not an actual real use case, but seems like a good example for arguments sake: say that the Pharmacy app displays a list of Drug Orders and has a “quick dispense” button that creates a MedicationDispensed event from an order. Assumedly the Drug Orders will be sent RESTfully in FHIR or OpenMRS REST format to the MFE. But to create the “quick dispense” function, would the MFE create a “MedicationDispensed” object based on an Drug Order and send it back to the server, or, say, would we want a “quick dispense” endpoint set up in a OpenMRS module that takes in the uuid of a Drug Order and creates the MedicationDispensed object?

Take care, Mark

17

For this particular use-case, we’d probably want the logic handled on the backend since doing this in the front-end doesn’t add any value while doing this in the back-end might (we can skip validation of certain properties when we know that they are directly derived from the system rather than user-supplied data). However we’d likely still need the logic to move from a drug order to a “drug dispense” in the front-end since likely any usable front-end would want to prepopulate at least some fields from the underlying order (if any).

That is to say, I don’t think we have any hard-and-fast rules about where business logic belongs.

18

What would be the disadvantage of doing this from the backend and have the client just make calls for the prepopulated fields?

19

So assuming we have a drug order in the backend the client would make a call like:

/ws/rest/v1/DrugDispense?from=<drug order id>?

20

@ibacher @dkayiwa … thanks… I think this is a good example and probably is clearer than my original question, which I’ll try to rephrase: in the new 3.0 world, do still we foresee new business logic being provided by writing (Java) OpenMRS omods, but instead of the UI interacting via a OpenMRS Service API, the OpenMRS omod will expose it’s API via custom OpenMRS REST endpoints like what you mocked up above? (And if the answer is no, do we have a vision for what the new pattern should be)?

/ws/rest/v1/DrugDispense?from=<drug order id>?

This is generally the pattern we’ve used over the past few years with the OWAs we’ve written, and it something I’m certainly comfortable with, but was interested in others thoughts on it. In particular, I though at some point I hear it mentioned that “ideally in the long term the 3.0 UI would interact via FHIR resources, not OpenMRS REST resources”… maybe this isn’t the case, but if it is, I’m not sure how that long-term goal fits in with the above model.

fyi @burke

Take care, Mark