We are reviving our efforts to integrate order entry into our implementation. We are running OpenMRS platform 2.12.
In the backend, I can see there are tables for order_set and order_group but I having a hard time finding documentation on what these refer to (and how to interact via REST). Any guidance would be much appreciated.
One important feature we are looking for are order templates. So for example, we have clinicians in our hypertension clinic who generally order the same hypertension drugs. It would be great to design a set of the these common prescriptions that could inform the UI (i.e. show common orders) to make it a little easier to order the drug of choice. Can we use order_set for this?
We are still looking for guidance though on whether it’s appropriate to use the order groups/sets as templates in the way described above. It seems this was an intended use case based on this post here: https://wiki.openmrs.org/pages/viewpage.action?pageId=34146504. Though it is quite old. @burke, does it still apply? Is there more recent documentation?
The wiki mentions that “order sets can contain 0-to-n members; each member can be a reference to an orderable concept, an order template (pre-defined order), or another order set.”
However, it’s not obvious to me from the data model how one creates an “order template (pre-defined order)”. Does anyone have any insight on how to do this? Are there any docs one could point us to for using the rest api to create an order set with an order template?
@jdick, this makes sense to me. We started trying to use the new order set and order group constructs for Oncology - chemotherapy regimens - in a project several months back. There is likely much we can learn and/or draw from that experience, which is still very much in an unfinished state. Will try to dig up an summarize where things currently stand around this.
@mseaton , out of curiosity, when you created your order entry module, did you uncouple backend from frontend? By any chance, did you create an OWA that we could potentially install/update ourselves?
Per Burke, the functionality for order templates has been modeled but not yet implemented. @mseaton, is there any chance you guys started work on this? We have two junior devs who we’d like to assign a task like this to if there is still need.
@akanter, do you know of a standard or freely available database of order templates (e.g., source metadata for dosages within FHIR 4’s notion of a MedicationKnowledge resource)?
Even if we can’t find a database of pre-canned order templates, it would be good to structure what we make to converge with FHIR’s approach to modeling the information.
Unfortunately, I’ll be on holiday the week of 18 March, which means I will miss 18th or 20th of March.
FYI – the Wednesday design call is an hour earlier than indicated on the Doodle poll (i.e., 2pm EDT or 6pm UTC). I don’t know if this would allow @akanter to participate on 27 March.
We just noticed a small potential gap in the drug_order table. If you choose to NOT include a drug_inventory_id (which is optional), and instead provide the extra fields required (about dosing), there is no way to specify the formulation in the drug_order table. It doesn’t have a column to represent this. If one were to submit to drug orders, say for a capsule and a tablet, for the same medication, and did not use the drug_inventory_id, there would be no way to distinguish one from the other.
In this case, we wouldn’t be using the drug table to reference the drug, we would be manually inserting. We’re trying to avoid the constraint of placing orders in a quantity of a specific formulation. Our pharmacies do not use OpenMRS to manage their formulary so it doesn’t make sense to put orders using strengths based in the formulary. For example, we’d rather have the order by for amlodipine 10 mg, regardless of the various formulations available in the drug table (say there is only amlodipine 5 mg there) .
In general, given that OpenMRS doesn’t really have a pharmacy component, it seems overly burdensome to constrain orders in terms of what’s available in the drug table. Would be nice to either uncouple this or build out components necessary to support the needs of a pharmacy.
