I’ve heard several times recently that there is a disconnect between how OpenMRS handles medications vs how Bahmni is handling medications - and that this keeps rearing its head when we want to work together.
@angshuonline @gsluthra Can you help us understand: What is this difference?
Why I’m asking: (1) to get this clearly documented somewhere, and (2) there is current work ongoing for backend support for Medication Dispensing, so likely a good time to be aware of this discrepancy.
FWIW we do have a backend ticket for addressing hard coded ids for order types (ticket: [TRUNK-5964] Hard-coded uuids for drug order type and test order type - OpenMRS Issues):
OpenMRS has hard-coded uuids in the API service to look up the order type for “Drug Order” and the order type for “Test Order”.
CC @burke @dkayiwa @ibacher @mogoodrich @mseaton @mksrom @n0man
Bahmni always had order entries (investigations/meds) etc, while ref app didnt. I am hoping O3 would have done some study and analysis of Bahmni’s features, so maybe they would be best to comment.
- OpenMRS models does not support “dosage” and “dispensing” information (there are other things as well, like reasons, substitutions, supportinginfo … but ignoring them for now)
- Bahmni stores dosage as a JSON. and there is an associated processing class that handles this.
- One good thing to do would be to store a typical FHIR “Dosage” datatype in the JSON. So that everyone speaks the same standard atleast. at the least same approach for dispensing? I would pref a different model for dispensing with ref to the original order
- OMRS also has no support for Medication Statement, - record of a medication that is being consumed by a patient! Storing them as obs - simply does not make sense!
- In terms of UI, I do not believe that one size fits all - in a mobile app, the interface may be different, in other contexts maybe 0-0-0 formats would be suitable. For chemotherapy calculations and dosing instructions would be different. imho, it doesn’t matter what the UI is, and I would leave it. to contexts to. define so, what we must absolutely agree on - common minimum standards - API, contracts and models!