Drug dispense and administration in OrderEntryUi

Development
,
#12

[quote=“arbaughj, post:11, topic:4212”] The drugs are a separate download from the CIEL dropbox. [/quote] I didn’t know that. Thanks. We’ll download it.

That is a clear and detailed report. Thanks :slightly_smiling:

On first thought:

1/ [quote=“arbaughj, post:11, topic:4212”] If it’s put into Transifex it can get translated [/quote] How to do that ? Would you have an example in other modules ?

2/ Seems doable 3/ Can do too. 4/ Could you tell us more about the “regimen” ? What is it exactly ? 5/ Need to check how the drugs are recorded. 6/ Good idea. 7/ Essential. The thing is to get to link the drug allergy with the drug prescribed. Need to look into that, but as a first step, at least add a little “Drug allergy summary” somewhere on the screen. 8/ Yes 9/ That was something we wanted to do from the beginning since our client do have a pharmacy to dispense drugs. 10/ Not sure to understand what it is. Could you explain me more this point ? 11/ OK, we could try to add a little code to automatically complete (or suggest to complete) the appropriate fields based on what’s in the name.

We will have a round of feedback end of this week, with better client requirements. In the mean time, I’ll investigate in more details the points above.

Thank you Romain

#13

Thanks @mksrom for your feedback.

Concerning 1 - Transifex Translations - Most all of the Reference Application UI related modules (Like Registration) are setup in Transifex. Find more info here… https://wiki.openmrs.org/display/docs/Maintaining+OpenMRS+Module+Translations+via+Transifex

Concerning 4 - Standard Regimens - This is usually specific for HIV or TB where you put a person on a group of medications and expect them to continue taking the meds until you tell them to stop. See how it worked in the legacy UI at… https://wiki.openmrs.org/pages/viewpage.action?pageId=42041389 and https://wiki.openmrs.org/display/docs/Administering+Drug+Regimens

Concerning 10 - Rx/Prophy - My guess is that Rx would mean it’s meant to treat something, and Prophy would mean it’s to prevent something. I’ll need to look for more info on what this means on our existing form.

Thanks so much for your work on this.

#14

Ok we showed orderentryui to our client and we have some feedback! What you will find below is a wish list, that is pretty much settled as our requirements with them.

So @darius (and others), please step in now if you find that the requirements are getting out of line as per what should happen in your opinion. Your comments/critics will be most welcome.

1. Workflow

The workflow should plug to the visits workflow and encounters of various types should thus be generated:
  • Prescription encounters
  • Dispense encounters
  • Administration encounters
  • …

This means that nothing could be done if there is no active visit, even for an outpatient. It also means that the current page should be provided both patientId and visitId parameters. When loading the medication orders for an ended visit, then the page would become read-only.

1.1 Several, grouped, order lines make a prescription order

Each prescription order is made of several order lines (one per drug basically), that is what we are seeing right now when lines are added to the prescription. In OpenMRS terms it seems that each order line is in fact a 'drug order'. Therefore each prescription order (which is a concept/object yet to come or to be pinpointed) is a group of drug orders.

Additionally there should be a way to create several prescription orders during one visit.

1.2 (Oupatient) The dispense occurs later, and is made by someone else

This has been noted by @arbaughj already and we have the same requirement. The basic idea if the following:
  1. A physician creates a prescription order at some point.
  2. A pharmacist dispenses it at a later point.

Two users with different privileges will thus access the page to perform a different set of actions.

1.3 (Oupatient) The order info may stick after the visit has ended

Even though the visit during which the order was made has ended, order lines that are still active should remain visible until the dispense period is over. Example: A visit happens on a Monday and paracetamol is ordered during the visit to be taken until the next Friday, so for 5 days. Well even though the outpatient visit is ended on the day (Monday), and the paracetamol was dispensed before that, the order line should remain active, and visible where applicable, until Friday.

1.4 (Inpatient) Administration screen

We are not yet settled at all about how to put together the administration table/page/screen/fragment/... But what we know already is that each administration event is in fact a double event since it has to be double checked. Example: Say that an inpatient prescription order states that 2ml of some drug should be administrated every 30 min for 6 hours. A nurse administers it through an 'administration encounter' each time, but then another double check event must take place: a physician will sign that the administration occurred as expected. So those (yet to come) administration lines will have several states, at least 3:
  1. Nothing done yet.
  2. Administration done.
  3. Final signature given.

2. Visual & user interface

2.1 'Active' vs 'Past' --> 'Active' vs 'Discontinued'

Active order lines should be clearly visible at the top, as they currently are already. However the below section should only show *discontinued* order lines: those that have been hit with the cross (x) button.

2.2 Order line revisions should be accessible from the order line, but hidden by default

Rather than having past revisions always visible at the bottom, they should not be visible at first. However an order line with revisions should provide some sort of link or mechanism to see the stream of past revisions. Maybe a popup? So Angular wise, we would need to design an 'order line widget', that carries its current data as well as its revisions's data. This widget would be added either to the top area when the order line is active, or to the bottom area when the line has been discontinued.

2.3 The page is made of prescription orders

There would be the need for a 'prescription order widget', with a top section for active order lines, and a bottom section for discontinued order lines, as said in the previous point. The page would then be made of a list of prescription order widgets.

2.4 'Reason' not visible, and other messages

At the moment, when discontinuing an order line, a reason must be provided. However that reason is not visible anywhere after that. This should be corrected and links us back to the need of an order line widget that should know when some additional message would have to be displayed. It could be a discontinuation reason, or any reason that led to a revision (when looking at the revision of an order line).

2.5 Concept Drugs's defaults should be filled in

'Dosage Form', 'Strength' and 'Route' should be picked up from the Concept Drug's definition and filled in upon loading the drug.
#15

@mksd, I am excited to see the overlap of needs between your work and mine.

Would it be possible to integrate regimens (groups of drugs commonly prescribed together) and default doses (fields pre-populated for number of pills, times / day, etc) into what you’re doing?

I hope @darius and others will be able to give you valuable feedback so you can keep moving this forward to ensure best practices and be most beneficial to the community.

#16

Great!

I wonder if that is not what is behind ‘order sets’ in OpenMRS. If yes then I suspect that another module should be brought in: openmrs-module-orderextension See more about it and the ideas behind it on

This is not currently a requirement for us but we shall keep in mind, while developing, that some mechanism will have to plug in there to fill prescription orders at once based on order set definitions. Something along those lines, if my understanding is correct.

You mean as in what is set when defining the Concept Drug? If yes then indeed we want that too and I will edit my post to reflect this…

#17

Thanks @mksd! Thanks for the useful links. Order Set and Order Template sound like exactly what we’re needing to do.

order set – an order set represents a pre-defined list of order templates to be used in certain situations (e.g., pre-defined drug regimens, a set of common orders for treating viral gastroenteritis, etc.) order template – an order template represents a single, pre-defined order, which may include choices and/or defaults for the various components of the order. Templates allow providers to generate structured orders quickly by picking a template from a list or changing only one or two components without having to manually complete every component of the order.

Keep up the good work!

#18

@mksd, sorry for the slow reply; pretty busy these days.

It would also be good to discuss this on a design call with @burke and @jteich soon.

Some thoughts:

I’m not sure about your usage of “prescription order”. Yes, each “order line” is a single (Drug) Order in the data model (or you might think of the line as a sequence of an order+revisions). The data model doesn’t support this yet, but you should be able to choose an Order Set and thus place several related orders together in one Order Group.

You may place multiple orders in a single encounter, and I’d think this is approximately the same as what you are calling a “prescription order”. In the UI as I had written it, this is represented by clicking the Sign And Save button a single time after writing 1+ orders.

However I think “prescription order” would be confusing terminology, because it sounds like a synonym of a “drug order”. You might call it just a “prescription” if it corresponds to everything that was ordered together in one order session, and either printed together on one sheet, or sent off to an external system in one transaction.

@jteich has described to me the idea of an “order sheet” (which lists all the orders placed in a particular encounter), and maybe this is equivalent.

Yes

Yes

I don’t have a lot to say about this. Perhaps @jteich can comment on how the med administration screen typically flows in a US/European EMR system.

I don’t understand why you would only want to display discontinued orders and not expired ones.

It makes sense that the initial view should only show the latest version of an order-line-with-revisions. I think “expand/contract” would work better than a popup.

I don’t like this (at least, not as I’m understanding it). It sounds like you’re saying that drug orders should be grouped/sorted based on being ordered together, and thus if you read the page from top to bottom you might see some active orders, then some discontinues ones, then more active ones, then more discontinued ones. This sounds completely wrong to me. I think the primary view should have all active orders on top, above anything else. There can be secondary views to show you what was ordered together.

Take a look at how we grouped/displayed orders in the Ebola system we built (see om.rs/ebolademo and feel free to write some prescriptions and see how it behaves; some code here). @jteich and I put a good amount of analysis into grouping by generic (i.e. order.drug.concept) and then sorting based on most recent activity on the order.

Another thing worth looking at is the “Order Sheet” that I was building for PIH last year. Here is the angular directive.

I agree that it should be possible to see all the data. IIRC we did a better job of this in the Ebola system, where we actually grouped orders by their orderable.

As much as possible, choosing a drug should automatically select default values for fields. But keep in mind this isn’t 100%. An ampule usually means IV or IM, but could also be given orally, or nebulized. A drug that is a “500mg tablet” can be equivalently ordered as “1g” or “2 tablets”.

The code includes the beginnings of the ability to do this. See inferFields which assumes your concepts have mappings to SNOMED CT codes.

#19

Hi @darius,

(@mksd I hope you don’t mind if I reply, I know you are pretty busy in the next coming days)

Could you explain me more the Order Set / Order Group and how you would see it fit here ? Or wouldn’t it be lighter to add a new field in the data model ? Something like a ‘revision_order_id’ in the ‘orders’ table (containing a reference to the ‘order_id’ that is revised).

OK. Now looking at the code in Order Entry UI, I see that it already creates an encounter when click on Save & Sign, which is great (we have less to do !).

        // HACK
        EncounterType drugOrderEncounterType = encounterService.getAllEncounterTypes(false).get(0);

I guess we just have to replace this to get the right Encounter Type.

That sounds perfect to be used as a ‘Prescription’ document.

I recall that another reason we had in mind for using an encounter to group all orders, is to keep the orders associated with a VisitId. What do you think on that point ?

Well, I think we didn’t know/think about the expired ones yet. :confused: So I guess there would be 2 sections within the ‘Past Orders’ section: expired ones and discontinued ones.

There is a lot of interesting stuff here ! And I see IV fluids as well. But unfortunately I can’t create new prescriptions. I get a blank screen when I click on any pen button (any widget):

Screenshot from 2016-01-25_01.png1238×169 28.2 KB
Any idea why ? Is it because of Tablet vs Laptop UI or something ?

Again, thanks for showing us that. That will come usefull later I think because we may need to display orders by encounter in some medication dashboard or report.

In the OrderEntryUI module, how is the dispense event saved and how is it linked to the drug order ? And in the Ebola distro ? What would you suggest here ?

Definitly. When would be a suitable time for you ?

Thanks again. Romain

#20

You can ignore what I wrote there, as long as you’re okay with the concept that what you’re calling a “prescription” is “all the orders in one encounter”.

I agree with the spirit behind this (i.e. you only place an Order for a patient who is present).

In the underlying API, every Order must belong to an Encounter, but not every Encounter must belong to a Visit, so it doesn’t technically work as you say, and the UI code shouldn’t assume this. But if you also set up other workflows so that in your implementation all encounters have visits, then things will work like this.

I think I understand our miscommunication. IIRC I wrote that UI to show all past orders, but you are right, it should probably be done in such a way that only a single row is shown for the entire “thread” of a past order. E.g. if an order was placed, then revised, then discontinued, this should be just one row (probably expandable). I would keep expired and discontinued together in the same place, as having multiple tables doesn’t make clinical sense AFAIK.

However, it may be better to take a completely different approach, which is what @jteich had me do in the Ebola application that we built after the orderentryui module you’re looking at. Instead of dividing “active” vs “past”, instead it’s a single list where each list item is a group of everything that ever happened for one Drug. Internally, each group is sorted by “most recent thing to happen” at the top. The groups are sorted relative to each other based on “most recent change for any drug order for the group’s drug”.

This is what Jonathan asked me for:

And my implementation looked like this:

Pasted image737×301 49.4 KB
(this is specifically showing that the most recent thing to happen was that Albendazole 400mg expired, so it is shown at the top, even though there are other drugs still active below it (but their “activity” is less recent).

If you want more details about this approach, contact me by email and I will forward you a long email chain where we discussed this and sent screenshots back and forth.

(Sorry, the tablet UI of the Ebola demo seems to be broken, with some Angular error. I have no idea why, and no time to debug now.)

The OrderEntryUI module doesn’t do dispensing or administration at all. See my message earlier on this thread (message 2) about dispensing in a PIH module and administration in the Ebola system.

@jthomas, can you please work with @mksrom to get this on a Design call? (Ideally @burke and @jteich will both join too; we can probably live with having just one of them if scheduling is difficult.)

#21

Sorry to be slow in responding - traveling and battling a cold. There’s a lot of good points here and a few things to clarify. Hoping to respond in depth tomorrow.

Jonathan

Design Foum 2016-02-01: Order Entry UI
#22

Sorry to be late to the party. Great ideas throughout this thread; I’m also hoping for consistency among the growing number of drug ordering apps being built on OpenMRS. Some of the comments here have consistency as their goal, some are to reflect most common or most useful clinical functionality.

First, some definitions and terms that I hope will be adopted for consistency (after any necessary debate or tweaking):

  1. Prescription – means a single drug order, and should not be used to mean a group of orders or a session’s worth of orders; that will confuse any clinically-oriented person.

  2. Collections of orders: a. Order session = The collection of all orders for a patient that are signed/finalized at one time. b. Order set = A pre-written collection of orders, initially not attached to any one patient. The set is stored, named/indexed, and can be “played back” later by any clinician to become live orders for any patient. Order sets are widely used to store standard regimens – for example, one order set may contain five antibiotics that are normally ordered together for treatment of tuberculosis; another may contain three or four medications to be used after surgery. The orders in an order set are usually selectable – that is, when the doctor selects (“plays back”) the order set with a specific patient in mind, the doctor does not have to order everything in the set, but rather could select one, some, or all of the available orders. c. @darius, I don’t recall using the term “order sheet” as you have described it, although I could be wrong.

  3.  Dispensing vs. administration

a. Dispensing = taking drugs out of the primary storehouse (usually the pharmacy) and delivering them – to the patient for self-administration or to a nurse for administration in a hospital. b. Administration = Putting drugs into the patient’s body – which could mean a patient taking a pill, a nurse giving the patient a pill, or the nurse giving the patient a drug as a shot, infusion, patch, suppository, etc. Administration by a nurse is always done in response to an active order from the physician [or nurse practitioner, or midwife, etc., depending on local laws].

  1.  (re the comment about ‘prescribed’ vs. ‘prophy’):

a. Prescribed: a drug order that is intended to be dispensed and administered b. Documented: a drug “order” (using the same form) that is simply documenting a drug that someone else has already prescribed or that the patient takes on their own, such as vitamins – for the purpose of making the patient’s medication list complete and correct. c. Prophy: As I understand the thread, this is the same as “PRN” (“SOS” in some countries) drugs, which are prescribed but not given on a regular basis – rather they are given in response to some other event. Example: “Paracetamol 325mg tablets every 4 hours PRN headache” – only administer the drug if the patient has a headache, and in any event don’t give it more frequently than every 4 hours.

Now – to some comments about functionality, roughly in order of when the relevant item appeared in this thread:

  1.  Separate outpatient and inpatient tabs – an advanced concept, but a useful one if you are dealing with both inpatient and outpatient care.  The outpatient meds are what you use most of the time; when the patient is admitted to a hospital as an inpatient, the outpatient list freezes, the inpatient list is reset, and the inpatient list is where new drug orders go until the patient is discharged.

a. Doing this automatically based on most recent admit/discharge events may not be 100% right, as you may write (inpatient) admit orders before the patient actually is admitted and you may write (outpatient) discharge orders before the patient is actually discharged. You could probably presume one or the other based on the admit/discharge events, but you must make it possible for the user to change to the other mode.

  1.  Default doses = standard fills for dose, frequency,

etc. – this is a good idea, but it needs some care to be clear to the ordering physician. Usually it depends on what you choose from the search results. Typically, when I search for a drug – say, “amoxicillin” – one of the returned search results is always the drug alone, usually with strength and form (amoxicillin 500mg capules); if this is selected, the physician fills in the dose, frequency, etc., fields in the ordering form – they are initially blank. Other search results, optionally, can be more fully filled templates that include any or all of: dose, frequency, duration, PRN information (amoxicillin 500mg capsules, 1 capsule 3x/day for 10 days). In that case the relevant fields are all pre-filled, although the physician could still make changes before pressing Ok to add the drug order to the current session.

  1. Ordering vs. dispensing – the pharmacist who is dispensing (and also the nurse that is administering) should be able to see all the fields that the physician entered in any given prescription. However, the pharmacist will have different fields to edit, such as # of pills or amount of liquid dispensed, type of formulation and strength actually dispensed (sometimes the pharmacy doesn’t have the pill strength the doctor ordered, so they give the patient twenty 100mg pills instead of ten 200mg pills and change the instructions on the bottle). a. Where technology permits, the order form options could include: print prescription, send electronically to pharmacy, fax to pharmacy, document only.

  2.  Under ‘double entry’ you noted that the physician needs to sign off on all administration events.   I have never seen that done and suspect it would be unwieldy as well as requiring the physician to be present every time the nurse gives the patient a pill, infusion or shot.  I strongly suggest that this is not necessary or valuable – would be interested to hear if this is indeed the required workflow.

  3.  Active drug orders do indeed remain active until discontinued, changed, or they end, i.e., reach the end of their duration (not ‘expire’, which means the drugs have lost their potency). Many orders do not run out ever, such as taking a drug every day without cease to control your high blood pressure. Such prescriptions never have to change, although they usually need to be renewed periodically depending on

local laws (every year in the US).

  1.  As Darius has shown, I prefer a single display of drugs, which is either active medications or all prescriptions:

a. Active prescriptions – listed in reverse chronological order (this is the default display). Usually called “active medications” in the actual UI. b. All prescriptions (this display is available with a click of a button labeled “show inactives”) showing all orders, whether active or discontinued/changed/ended. It doesn’t make much clinical sense to a user to only show the inactive drugs, especially when other drugs have been added in the middle of the sequence which happen to be still active. As Darius shows, we have favored showing these in reverse chronological order, with the inactive drugs shaded or otherwise visually distinct.
c. Also as Darius shows, one way we think has worked well is to roll up earlier prescriptions for the same drug underneath the most recent prescription (possibly indented), and to sort all of the drugs in reverse chronological order by most recent positive event (new prescription or change).
d. A drug being discontinued or running to the end of its duration does not affect the sort order of the drug in this list. e. When a drug finishes its course, you can change its status to inactive but you don’t have to post any new event at all.

  1.  Yes, it is good to propagate the medication form (capsules, pills, liquid, etc.) and route (oral, IV) directly from the drug concept into the ordering form.  There must be flexibility, though: a drug which comes in a 500mg capsule can be dosed as “2 capsules” or as “1000 mg”, and a medication for children (especially for liquids) could also be weight-based – the same drug could be dosed as “50 mg”, “4mg/kg”, “5 mL”, or “1 teaspoon”.   There are also alternative routes: a capsule or pill will normally be given by the Oral route, but could also be given per NGT (through a nasogastric tube) or a feeding tube.  More commonly, a drug supplied as an infusion is often given IV, but could also be given intramuscularly (IM), subcutaneously (SC), and a few other variants.  You even have to be careful with the default: IV is right for many medications, but insulin is most often given SC. There are standard “route groups” such as these which can be assigned for any medication form.
2 Likes
#23

To All, We will discuss Order Entry UI on the design call Monday, February 1 @4-5pm UTC. @mksrom @darius @burke @jteich

#24

This may have already been discussed in this long thread, but I want to point out, from an architectural standpoint, these would be independent features:

  • Prescribing (e.g., Order Entry Service)
  • Dispensing (e.g., a Pharmacy Module)
  • Administration (e.g., a Medication Administration Module)

In other words, each of these can benefit from the existence of the others, but we should avoid bundling these into one service/module or creating dependencies between them.

Some examples of common use cases in which OpenMRS is or will be used and can be supported if prescriptions, dispensing, and administration are independent:

  • Electronic prescriptions (order entry), paper-based dispensing, no tracking of administration
  • Paper-based prescriptions, electronic dispensing, paper-based administration
  • Electronic prescriptions, dispensing, and administration all within OpenMRS + modules
  • Electronic prescriptions in OpenMRS, a separate commercial pharmacy system used for dispensing, a separate commercial MAR (medication administration record) system used for administration

It’s probably safe to assume that order entry, if done electronically, would be done within OpenMRS. Just as with lab systems, those implementations doing electronic dispensing & administration might start with OpenMRS modules, but could easily evolve to replace those modules with enterprise level systems over time, so would migrate from doing these in OpenMRS to integration OpenMRS with external systems for these functions that would be out of scope for an EMR (see below).

Cheers,

-Burke

2 Likes
Medication Tab for Pharmacist needs
#25

Thanks everyone for the design call the other day. That helped me clarify a lot of things: As suggested by @jteich, I’ve looked at existing modules:

That brought me to the following conclusion:

Taking @burke advice to keep things clearly separate, what we need is:

  • Prescribing - exists already (Order Entry UI)
  • Dispensing - exists already (‘dispensing module’ or any module that saves dispenses as ‘observations’)
  • Administration - does not exist yet (to create in a later stage)

Each of these modules would NOT depend on each other and just be used to create/edit/view their respective objects.

Then we would create another module that assembles the 3 functions above by providing the appropriate UI elements. That “Medication Management UI” module would add the kind of elements described earlier in the post:

  • orders in reverse chronological order
  • sorted by CareSetting
  • with statuses
  • revisions
  • and so on and so forth.

Plus some other elements such as dashboard widgets.

What do you guys think ?

1 Like
#26

can you share omod file of orderentrymodule.

#27

Answered here.

#28

Just wanted to point out that, the system domain should also support “MedicationStatement”.

MAR(Medication Administration Record) functionality in OpenMRS
#29

We would like to show a summary of recent dispensed meds on the patient dashboard along with a link to a list of all dispensed medication. Has anyone tackled that?

  • A new dashboard widget is needed which shows all obsgroups for an encounter, not just one obsgroup per encounter (obsAcrossEncounters) (see image below).
  • Add a link to a new page from the clinician-facing dashboard which has the full list over time with all the fields (drug name, frequency, instructions, location, etc) for that patient.

dispensed-meds

We continue to use the Dispensing module. We will eventually move to using orders instead of obs, but our users would appreciate this feature now :wink: And this design would be needed with orders too.

1 Like
#30

@ball, who is making use of this information? Is this for the pharmacy, as opposed to the clinician? If the pharmacy refills an existing prescription, would that be a new and separate event in the dispensed-meds table, compared to the original dispensing of the original prescription? I ask because I would like to ensure that the dispensed-meds list is not confused with the prescribed-meds list. Doctors and nurses are (until you tell me otherwise) used to seeing a prescribed-meds list as the “med list” – with each prescription listed once even through many refills, etc. I can see the value of having a list of dispense events – I just wanted a bit of clarification in order to think more clearly about the elements of a dispensed-meds list.

#31

@jteich - We want to show what was dispensed by the pharmacist on the clinician-facing patient dashboard.

This is what we currently have in the PIH EMR / RefApp-style:

  • Dispensing: The pharmacist enters the medication dispensed into OpenMRS – drug name, dose, form, route, instructions, etc. The patient arrives at the pharmacy with a paper prescription. The pharmacist tries to fill that item, and might need to make adjustments to the formulary.
  • Prescription: The clinician enters the plan for patient’s meds into OpenMRS – drug name, dose, form, route, instructions. The clinician writes paper Rx which is handed to the patient.

Of course we want to use OpenMRS drug orders, connect dispensing with prescription, replace the paper Rx with electronic, provide simple reordering, but we’re not there yet. When this is all connected than 1 med list would be ideal and show what meds were ordered/filled/reordered.

For now, the clinicians would like to start with the simple list of meds dispensed. It’s a good first step.