also flagging @grace
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.
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.
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.
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?
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.
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.
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.
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
- 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.