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