Order Entry UX - First principles: Knowledge + Order
This is post 4 in a series on Order Entry UX. Previous posts looked at General order entry requirements / Examples of EHR Order Entry & Order Sentences / Difference of Order Selection vs Order Customization.
Summary
This post steps explains
Why orders exist - to turn knowledge into action
The different types of order tools to do this
The huge gap between order entry based on these first principles, and how it actually is done today
Listen the the post on YouTube, or on your podcast app under: Gregory Schmidt
PART 1:
Why do Orders exist?
In healthcare orders make things happen.
Orders turn knowledge into action.
A patient seeks a physician to consult their expertise. The physician will assess the problem, and order the next step. Such as a test, medication, or referal to another clinician.
The formal tool that transforms their knowledge into action is, an order.
I think it is important to consider the concept of order as something that overlaps the concepts of knowledge and of action.
This is in contrast to another way to think of orders, which is to view orders as a dumb messenger service that links knowledge to action - but doesn’t overlap them.
Let us look at why orders overlap knowledge.
note: this article uses the term ‘physician’ as the person ordering stuff. I’d prefer to use the term ‘clinician’ because I think far more health professionals should be order things. But this idea begins to freak people out, and this article already has enough heresies in it. Listen to my Stanford MedicineX talk, Breaking the Medical Cartel if interested in greater non-physicians involvement in healthcare.
Knowledge & Orders
In order to place an order, two large types of knowledge are required
Knowledge of what is wrong
Knowledge of the next step.
1. Knowledge of what is wrong
In theory, if healthcare was operated entirely by a benevolent artificial intelligence system, the computer would have complete knowledge of the problem and knowledge of the solution. It could handle the entire process.
This would be very helpful for the computer to know what is wrong. The system can alert the clinician to lab findings or results they may have not seen.
But, for simplicity, let us assume that in these examples the knowledge of what is wrong is still operated by the human.
2. Knowledge of the next step
It is very important to understand that there is always a wide spectrum between the knowledge a physician has about the next step, and the final order. Some examples.
A physician may understand exactly what needs to be ordered, and needs a tool that allows them to enter this a quickly as possible. Perfect knowledge. Perfect accuracy. (Unfortunately. We are human. So this is likely the exception than the norm)
A physician may think they know exactly which antibiotic should be ordered. But the one they have in their mind actually contradicts the patient’s allergy history. The dose they were going to prescribe does not fit the patient’s renal function. And the medication itself is ineffective because the patient is known to be resistant to that drug. Alleged complete knowledge, that is unknowingly incorrect.
The physician knows that an ‘antibiotic’ should be ordered. But they may not know which drug, its dose, or its dosing interval. Partial knowledge of the next step.
The physician may know that blood pressure pills should be added. But they may not know which is the best one to add based on national guidelines. Partial knowledge of the next step.
The physician in training knows the potassium is too high (because the nurse told them). But they have no idea how best to bring it down. Very partial knowledge of the next step.
The physician may at times outsource the specific details of the next step.
Such as the titration of a patient’s blood thinner dosage (warfarin) related to their blood coagulation (INR). This may be outsourced to another clinician (such as a nurse) to manage. In this case the physician doesn’t know directly what the next step is, but knows the parameters & range they would like the steps to normalize to. Knowledge of the parameters, with details outsourced.
Such as the titration of a patient’s insulin dosing. But in this case, instead of outsourcing the specific management of this to another clinician they outsource this to a computer algorithm.
The physician doesn’t realize that the patient’s antibiotics should be stopped. Or that the diuretics should be held. The system alerts the clinician to this. This is actually an error of the first category - lack of knowledge of what is wrong.
In each of the cases listed above there is a gap between the physician’s knowledge and the ability to write a detailed complete order. The gap may be from lack of knowledge, mistaken knowledge, or outsourced knowledge. Each of these is a normal part of day-to-day healthcare.
Traditionally, a physician would have to ‘look up’ the answer in a book or on a website to help fill in the gap in their knowledge. Such as reread the hypertension guidelines, or review an antibiotic treatment book.
However, as Example 2 shows, even if the physician thinks they ‘know’ entirely what the next step is. They may be very wrong. This highlights the need for the order entry process to in real-time double check the order.
With the advent of ‘order sentences’, it is easier for clinicians to type in a few words and for possible ‘orders’ to appear. On multiple occasions I have been told by people that, “they don’t know which order to select, so they just pick one, and know that the pharmacy will call them back and correct it”. (This is 100% true. Heard on multiple occasions. A highly risky and dangerous practice). No knowledge of the next step, but orders something anyway.
Conclusion on knowledge & orders
As you can see, the actual order itself must always be understood in its relationship to the knowledge required if it is correct. This applies to both
Helping guide the orderer what to order. Such as when they may not know which drug or which dose to use.
Helping continuously check an order in real time to ensure the clinician’s requested is reasonable.
Unfortunately today, in most electronic health records, the order entry tool functions more as a dumb messaging service. Not assisting clinicians in what they should order, and not validating in real time the appropriateness of the order. (Yes, there are some ‘drug interaction’ flags but this is more alert fatigue than useful information').
Given the tight connection of knowledge and the order selection process, there are many different types of order selection tools that could be invented to help with this process. Let us look at three examples.
PART 2:
Types of order selection tools
Rational antibiotic selection tool
As discussed above, a tool that helps guide a clinician through the process of selecting the right antibiotic. Taking into consideration of the patient’s source of infection, past allergies, the patient’s past microbiological resistance pattern, the hospital and region’s antibiotic resistance patterns, preference for dosing intervals, recent or current medications, the patient’s level of sickness, availability of stock in the hospital, cost.
An alternative way the antibiotic selection tool may work, is that if a clinician tries to directly enter an antibiotic it could verify what was entered.
Type of tool: guidance in selection, verification of selection
Automated Warfarin dosing tool. Automated Insulin dosing tool
As discussed above, a clinician’s order may be to outsource future orders for that issue to another person - or tool. It is easy to imagine a physicin entering the parameters for what a patient’s target blood thinner should be, or what their target insulin dose should be, and then the computer takes care of the rest. The algorithm can take into consideration the patient’s previous values, medication compliance, diet, etc.
I have seen several papers showing the ability of computers to exceed clinicians in being able to anticipate the appropriate dosing for patients in-hospital insulin. Such a tool at the start may ask the clinician to ‘sign-off’ 'and ‘confirm’ each order. [again, another type of order selection tool]. Over time it is easy to imagine the system only requesting the clinician to verify those orders that the algorithm has less certainty over.
Ultimately, such a tool over time when it works well, can leave the confines of the electronic health record designed for clinicians, and be available directly to patients.
Type of tool: outsourced orders, automated orders, order suggestions
Diuresis dosing tool
The patient is in hospital. They are having their diuretics managed on a daily basis. Multiple measurements are taken into consideration: patient’s physical exam, the lab work, their comorbidities. These metrics help assess if the patient’s diuretics should be increased, decreased, or remain the same.
A diuretic dosing tool could be activated for such a patient, and propose on a daily basis the next step for the diuretics. In such a case, the clinician would like to be able to verify the suggestion themselves. Therefore, such a tool not only needs to show the order ‘increase furosemide to 80mg PO BID’ but show on screen the trends of all the above information, and the anticipated trend lines of why the system believes an increase is important (and the anticipated effects on the patient’s other system function etc).
It may be best to embed such a tool directly into the clinical note. So the above trends can be recorded automatically as part of the documentation.
Type of tool: automated order suggestions, visualization summaries, automated documentation
Context Aware
In many ways, the placement of orders in to the system needs to be context aware. Some systems have some of these capabilities. But many do not.
who is the patient: a child? and adult? a pregnant lady? each has different permitted drugs and dosages
who is placing the order: when ordering a beta blocker a cardiologist more likely wants the drug for heart rate, and the ophthalmologist wants the drug for eyes. Is the user limited to the amount of types of drugs they can order?
what routes are available for the drug? can it only be taken IV?
what routes does the patient have available for medications? If the patient is NPO (not able to take anything by mouth) what is their preferred drug route? nasal-gastric? PEG? intravenous? Drug orders should automatically default to this
what doses are permitted: based on why the drug is being ordered, what are the standard starting doses and dose increments? what dose is the patient already on, and which would be the next dose?
patient physiology: what is the patient’s renal function? liver function? this can influence dosing suggestions
Placement of order selection tools
In the previous post, Order Selection vs Order Customization, we discussed that order selection tools will vary greatly given both the different types of tools required (discussed in detail above), as well as the different locations in the electronic health record these will be placed.
The order connects knowledge to action. Therefore the tool should be placed in the EHR at the place where the clinician requires closing the gap between their knowledge and action. Or when they want to turn their knowledge into action.
Many different tools may exist, and these may be placed on different parts of the screen. For instance
A clinician is completing a simple hypertension assessment form. At the end of the form it is decided the patient should start treatment. The form has built into the final pages several buttons that contain the complete order for them to choose from. These buttons are based on the two medications the dispensary has available.
The patient returns to the same clinic, and the follow up form is complete. This form now shows as the end of the form the next medication increment to titrate the dose to use.
The order selection tool suggests that a medication should be stopped. This suggestion may take the place as an ‘urgent-to-do’ item in their to-do-list.
A clinician opens the medical record for an inpatient, and wants to immediately order something. They launch an ‘order entry tool’
A clinician is reviewing a patient’s bloodwork. They notice repeat bloodwork is required. This order is placed via the bloodwork review panel.
A clinician messages another clinician directly for advice. Within the chat window, the clinician has the ability to formally convert the message into an ‘order for a referal’.
New possibilities
These were three examples, but you could imagine many more. Each tool could be of varying complexity.
From simple tools, that recognize you are documenting about the patient’s blood pressure, and therefore rank blood pressure pills at the top of the order entry box.
To advanced algorithms taking into consideration multiple patient’s comorbidities and provide levels of clinical assistance not yet dreamed of.
Ultimately such tools will help deliver healthcare at scale via non-physicians. By providing nurses and community health workers in rural developing nations the tools they need to function at a much higher clinical level than their book training.
PART 3:
The gap between order entry first principles vs order entry today
There is a wide gap between how order entry is done today, versus how order entry could be done based on the above discussion.
Contemporary order selection tools do not
Provide sufficient assistance in closing the knowledge gap of what the next steps is.
Verify in real time if the order makes sense.
This is because in general, today’s order entry tools remain a dumb messenger service. They adopt the second view of orders, as simply a messenger between knowledge and action.
Today, order entry is often contained within a single ‘order tool’ in the EHR. The tool does not integrate closely into the workflow, or conform itself to the EHR’s context and surrounding (eg. lab review, vs patient note on diabetes, vs note on hypertension).
To close the gape between knowledge and order, some small simple phone applications exist for looking up drugs. There are also reference texts and guidelines available to help. But these are not tightly integrated into the clinical ordering process. They are time consuming to review. Not precise enough. And don’t notice when we make a mistake. They keep the knowledge part of order separate from the order itself, and this is a problem, because as we identified at the start - there is often a gap between knowledge of the next step and what to order (even if someone doesn’t realizes this).
In some ways, today’s order entry tools that are disconnected from the knowledge step, are made up for by having smart pharmacists. Smart attentive pharmacists are able to verify if drug dosing is rational. However, many hospitals and clinics do not have full time pharmacy staff. There are also very few pharmacists in developing nations. It is also a huge inefficiency for pharmacists to have to review in great detail all of a physicians orders, re-verify their logic, and then contact physicians because the physician ordered the wrong drugs and wrong dosing. (Fortunately some pharmacists do this for those physicians they know are not very good).
The modular future
There is an exciting opportunity for innovation in the area of order selection tools. Tools that help guide clinicians to the right order, quickly. Tools that help clinicians at whichever step they may have become stuck at (perhaps they know the drug, but are just confused on the best way to convert the medication from oral dosing to IV dosing).
Such tools could be created by competing third party vendors, such as universities, startups, and legacy companies. The development of such tools will require expert physicians and expert pharmacists to create.
Tool could be certified based on national and international safety standards. They could be rated based on their efficacy. They should ‘plug-in’ seamlessly into the EHR. And a variety of different business models could exist to repay their creators for their usage.
Next Post:
Orders & Action
This post discussed Knowledge & Orders. The second half - Orders & Action - will be reviewed in a later post - “Why EHR Inboxes are dangerous”.
That post will review why disconnecting the process of ordering, and the process of receiving the action from that order is a huge problem. The order must always be considered a step within a workflow. Not an isolated, event, in an isolated series of isolated steps (aka, medicine today).
