Plans for integrated prescribing/dispensing workflow

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

@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?

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

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.

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

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>?

@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

Or a FHIR API. The same thing could be done in FHIR as:


The FHIR2 module should be able to handle OMODs adding new resources and operations, although the closest thing on documentation for how to do so is at the bottom of this post.

1 Like

Ah, great @ibacher … and that’s “a generally okay” practice? ie adding lots of business logic via adding custom FHIR resources?

Yes, definitely. The usual idea is to try to stick to things defined in the spec or an implementation guide, but this is one of the ways that FHIR is built to be extensible.

I agree that the business logic should be in the backend.

1 Like

@burke @ibacher @mseaton @ddesimone @grace and others… I’ve started to write up a proposed plan forward here:

I would be interested in others thoughts when you get a chance, especially on the questions I’ve asked.

The API page (Medication Dispense API - Projects - OpenMRS Wiki) is still rather light on content, pending better clarification of the use cases and screen designs, but I got fairly details with the data model (Medication Dispense Data Model - Projects - OpenMRS Wiki), basing it around the existing FHIR module. I’m hoping we might be able to get going on that even before we have all the use cases fleshed out.

Take care! Mark

1 Like
  • Better name for the module? Should it be called “Pharmacy” or “Dispensing” (would have to to deprecate the existing “Dispensing” module)

It depends on your goal for the module. Are you aiming to start with dispensing and eventually evolve the module to handle other aspects of pharmacy workflow (e.g., inventory, packaging, prescription labeling, refill requests, refill reminders, supplier & manufacturer information, expiry management, point of sale, medication returns, etc.)

  • Or do we want to consider building this in OpenMRS Core directly?

The ability to record and recall recorded dispensing events could go in core; however, you probably want to iterate on it faster than our current pace of annual Platform releases.

But dispensing management software (part of a pharmacy system) doesn’t belong in OpenMRS core. OpenMRS is an electronic medical record, not a pharmacy management system, lab information system. radiology information system, etc.

  • Should we build out RESTful API in OpenMRS REST or FHIR (or some combination)

FHIR has several advantages:

  • Our goal is to evolve toward FHIR and reduce bespoke APIs over time.
  • Using a standard like FHIR instead of making up another bespoke OpenMRS approach increases interoperability, reducing future integration work. This seems especially relevant for medication dispensing information that implementation may want to gather from regional pharmacies.
  • Do have a means/pattern for deploying a MFE via a Module? Do we even want this? If not, how do we “bundle” the MFE with the OpenMRS module? Or is it okay (or even beter) to keep these two things separate?

ESMs (ECMAScript Modules, the standard for frontend – i.e., browser-based – modules) will be packaged separately, in part because ESMs – at least for now – must be incorporated at build-time. We’ll have a Talk post very soon to discuss the proposal for OpenMRS Packages.

All sounds good, thanks @burke !

I would think we should strongly consider building on / evolving the existing dispensing module at openmrs/openmrs-module-dispensing, even if that means a new major version that is a complete rewrite.

Makes sense @mseaton … it gets a little confusing if we have to keep some of the old stuff around at the same time (I think we might be running both at the same time for a while) but it’s probably worth it vs starting a whole new module… I can take a closer look.

fyi, I’ve finally gotten back to this and started a new thread here:

Hi. I am new to OpenMRS and want to begin by contributing to this project. Can I have the GitHub repo’s link and JIRA board/project plan ? Also, on other project’s pages, I see a link to slack and weekly meetings, but I was unable to find it on Thank you.

This is currently in design. There is no code or Jira issues yet.

Thank you. I will have a look at the design and stay updated with the project :grinning: