UI design feedback for Drug Order Entry & Order Sets

Implementing
1

Hello All, I am working on the wire-frames for a Drug Order Entry module. I aim to include the features to order one or multiple drug orders at a time and also implement Order Sets - allowing the user to order a predefined set of medicines to treat one single disease with a single click.

Here are the snapshots of what I have planned. I would like to join any discussion which pertains to the same/similar requirements. The first screen displays a basic drug order form also displaying the list of active and in-active orders.

Question: Is there any discussion open with regard to how to provide an alert to the drug ordering physician if the patient happens to be allergic to the drug? I understand that a allergy causing drug list is maintained. I need some clarification on how to implement that.

My second screen shows the UI to select from an existing medication plan where the user clicks on a link corresponding to the name of a disease and all the required drugs along with their compositions get loaded into the form. The user can modify the entries and then submit the form to place the order.

Is it the physician who will enter and store standard medication plans in the system or admin?

Please take a look and provide your suggestions/comments and provide me the link to other similar discussions.

1 Like
2

We have already implemented Order Sets. It recently gotten merged to OpenMRS. The documentation is in progress but you can find the Feature Guide here.

The order sets are traditionally authored by Admin after a committee in the hospital approves an order set to be used in the facility.

Regarding alerts if a patient happens to be allergic to drugs, we have this on our roadmap but its not on priority for the next quarter. But if you wish to implement this then you would need to maintain a list of drugs which cause allergic reactions and you also need to capture the information if a patient is allergic to certain drugs or drug classes. This can be either a person attribute or you can capture that in a condition list (condition list is preferred). You can run a query when the doctor selects a drug (trigger point) and check against the allergies of the patient and pop an alert.

We can talk about this in detail if you wish.

1 Like
3

Hi Akhil, Thanks for the clarification. Yes, implementing a pop-up if a patient is allergic to a drug is on my priority list. I would like to discuss that.

4

Hi Harini,

There have been discussions on condition list over some of the OpenMRS design calls. These can be found on the design page here.

5

I cannot understand how to implement the condition list to maintain a list of drugs the patient is allergic to. The discussions in that link seem to be pertaining to different symptoms or problems identified during a particular encounter. Could you please help me with more clarifications on this?

6

I am advocating for condition list because

  1. Allergy is a condition a patient is suffering from. It can be a food allergy or a drug allergy. E.g. - A patient comes to the hospital and is diagnosed that he is allergic to Penicillins. So “Allergic to Penicillins” will be added as a condition in the patient’s condition list. We can maintain a concept set of drugs which are known allergens in the drug dictionary itself. Next time, while ordering medications, if the doctor selects Penicillin or a known allergen drug, that acts as a trigger point to check if the patient has the condition “Allergic to Penicillins” in his condition list. If yes, an alert is generated.

  2. It brings Clinical Homogeneity. Condition list becomes one place to store all the information about a patient’s chronic diseases, allergies or other relevant diagnosis(past and present) which need to be considered in making medical decisions for the patient.

Was discussing this thread with @jteich, he was of the opinion of maintaining allergies as a long time patient attribute separate from the condition list. It has been traditionally done that way.

We can discuss the granular details of implementation going forward.

7

Thanks @hariniparth for your work on this. I have a few suggestions
 1.) I really like the drug sets capability, and being able to select them by disease is a great idea. After selecting the disease, there should be a sub-group of regimens that are specific to that disease. For example, there are multiple drug sets that are used to treat HIV. 2.) OpenMRS Reference Application already has built-in support for allergies, including drug allergies. See Allergy API and Allergy UI modules. Allergies end up being stored in the ‘allergy’ table. So, the Drug Order Entry module should look at the ‘allergy’ table to check for potential allergies. They are not stored in a “condition list”. 3.) It would be great if there were drug interaction warning messages too. Please keep this on the radar even if it’s beyond the scope of your current work.

Keep up the good work!

8

+1 to this. The Reference Application has a nicely-designed implementation of Allergies (and these are being included in openmrs-core in version 2.0). This data model should be the basis of allergy-checking for order entry.

9

Regarding alerts: modal popup windows (i.e., popup alerts) is the most commonly chosen approach to alerting and one of the worst approaches to alerting. Some alternative approaches:

  • Anticipatory Alerts: show an allergy lozenge next to any drug(s) to which the patient has an allergy in the choice list as the provider searches for drugs. This way, the doctor can recognize & avoid allergens before she actually selects them. Why should the doctor need to select a drug before finding out the patient is allergic to it?

  • Inline Alerts: Instead of a modal popup, the alert can be shown as a warning box on the drug order form. For severe reactions, you can require the user to acknowledge the warning (e.g., check a box) before the order form is enabled; however, in most cases, a prominent inline warning box is sufficient.

We already have allergies in the platform, but we do not yet have allergy checking (i.e., an API call to check a given drug against allergies). Designing these methods is currently in progress.

1 Like
10

Hi All, I have been re-working the UI. Here is the updated wireframes for the proposed UI.

When the user clicks on the “Add” button, the form to create a new prescription is displayed. This form consists of fields to enter the name of the drug and the start date which is populated by the current date by default.

If the drug is an allergic drug, a notification is provided and the user has to enter comments for ordering it

The user clicks on the next button to fill in the drug composition details and instructions for the patient and the pharmacist

The user is redirected to the summary page where they can review the order and then submit it.

1 Like
11

I want to start working on the data model now. Could you please advice me on where to get started.

12

13

@hariniparth, your data model appears to be extending drug orders with Care Plan and with pharmacy functions. We would model Care Plan separately from order entry and any link to orders would be to the base orders and not directly to medication orders. The pharmacy functionality (i’m assuming this is what you intend by “pharma_order”) would be in a separate module focused on pharmacy-specific needs (filling, dispensing, inventory management, etc.). Perhaps this is your intent. Building all of these features into a single drug order entry module could be done to meet local needs quickly, but in return will limit the module’s ability to be used widely.