We are looking at developing Decision Support feature in Bahmni and to start with we have chosen “Corollary Orders” e.g. If drug A is ordered, drug B needs to be ordered.
With Izoniazid, Pyridoxine has to be given
When Prednisolone given more than 5 mg per day, calcium has to be given.
When methotrexate given, folic acid has to be given.
In a typical decision support system, there will be a modal alert which is triggered by ordering drug A suggesting that drug B should be ordered but we are planning to use order sets as a solution to implement this. When the user starts to type a drug, the order set will be displayed as an auto-complete. If the user selects the order set, it will populate both the drugs in the treatments page and the user can edit the dosage as required. Attaching a screenshot for reference.
I would be interested in following this discussion. The CIEL dictionary is currently supporting drug information both in concept and formulation. I think it’s probably should be handled through standard drug identifiers. Let me know how I can be of assistance.
That module is useful to take inspiration from, but a large amount of the
code there is about dealing with extending the order data model without
touching openmrs-core.
In general, my recommendation is that we should add order sets to
openmrs-core, and release this as 1.12.x, and upgrade Bahmni to this
version.
I applaud you for avoiding modal alerts (one of the hallmarks of inadequate design).
I don’t understand how you can show ordersets in search results – i.e., during autocomplete, before the user has specified what they wish to order. In Regenstrief’s home-grown system, we’ve been able to add helpful support within initial search results (e.g., indicate interactions/allergies/formulary inline and promote popular items), but we don’t trigger order sets (corrolary orders, preferred orders, or blocking orders) until after they’ve chosen an order. For example, the user first selects what they want (e.g., isoniazid) and then we present them with the order set that makes it easy (actually, easiest) to order the pyridoxine as well.
The Order Extension Module is the best representation of order sets we have to date; however, I believe it was made primarily for oncology and, as a result, includes a few features that are specific to oncology (e.g., treatment cycles).
It would be great to introduce order sets more broadly and, as @darius suggests, either in core or supplied by a module en route to becoming part of core.
We have always thought that the dictionary should support not only concepts but groups of concepts (e.g., sets) to do different things. Reporting and ui sets like you want for orders are examples. Burke, I need to catch up on how the module uses sets and whether we wave sufficient metadata to do what we want.
We (Bahmni) plan to start implementing order sets very soon. It would be great to discuss this on the design call sometime. Please do let us know if there are any open slots.
Pre-defined order sets may be orderable (e.g., “Cholecystitis Order Menu”) or non-orderable sets linked to triggering events (e.g., order set to display when someone orders sildenafil or order set to display when asthma is added to the condition list). We could also use the order set model to create dynamic order sets (e.g., suggested orders).
We’ll certainly want to have concepts for orderable order sets; however, I’m not sure we’ll need concepts for all types of order sets.