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