Going Beyond ‘Orders’ and How EHRs Should Aid the Process

April 18, 2011

Everything was referred to as an order because it was written on an "order" sheet and because, in those days, doctors issued orders and nurses followed them. This is a new era. We all work as a team for the benefit of the patient.

I recently listened to a webinar on deploying Computerized Physician Order Entry (CPOE.) The gist of the discussion was that it was hard to teach new tricks to old dogs. Therefore it was important to make CPOE available on many different types of devices, minimize the number of annoying alerts and generally make it as efficient as possible. It was also suggested that you recruit the most respected members of the medical staff to set an example. Excellent advice like this has been dispensed by consultants and EHR proponents for years; the sort that has not yet led to wide-spread adoption of CPOE. As I listened, I was struck by the following disconnect.

You land in Egypt before the locals discovered motor vehicles or air travel. If you asked for instructions on how to get to Suez, you would get suggestions involving horses and camels but none will involve travel by motor vehicle or air. New modes of transportation tend to replace the old. Horses and camels eventually become nostalgic solutions to artificial problems, e.g. taking a camel ride while visiting the pyramids.

CPOE is a "solution" to an artificial problem that was created when the last big federal intrusion into healthcare (aka Medicare) forced hospitals to install "charge capture" systems so they could meet Medicare's billing requirements.

The real task at hand has always been to get the patient what they needed, when they needed it, and without making any serious mistakes. The old way of initiating this process was to leave written requests and instructions. Everything was referred to as an order because it was written on an "order" sheet and because, in those days, doctors issued orders and nurses followed them. This is a new era. We all work as a team for the benefit of the patient.

If we were to start over, we would begin by re-defining "ordering" in a more comprehensive way. Then we would build entirely different software and embed the process so deeply in the clinical workflow that there would be no distinct "ordering" phase at all, simply well and contemporaneously documented patient care. What follows is a portion of my attempt at re-definition that appeared as an abstract in one of the AMIA proceedings about 15 years ago.

I suggest thinking, not in terms of orders but of requests. An order is a request that entered the execution phase, will consume organizational resources, and/or cannot be interrupted. Prior to the commit point there are only requests. This differs from the fiscal view that an order is anything that would be billable if it were completed. The difference matters because a system designed to keep track of money will have a different emphasis than one designed to coordinated care and facilitate decision making.

There are several basic types of requests:
1) Request that a message be transmitted with/without acknowledgment to one or many recipients;
2) Request to have a notation made that a state change has occurred (patient is placed in isolation, Dr. Smith is covering for Dr. Jones); and
3) Request that another entity comment, suggest, recommend, decide, act or perform a service, etc.

Each type of request has certain properties that control how it will be processed:
1) Delegation - how much authority is granted to the requestee to initiate collateral actions;
2) Urgency - when can/must the action begin;
3) Contravertability - under what circumstances can the request be modified or canceled by others;
4) Pre-conditions - what must happen before the request can be carried out (e.g. temp > 102°, requires countersignature by attending, check for ad-verse interactions);
5) In-process dependencies - what conditions must be fulfilled for the action to continue once started;
6) Post-conditions - what actions should be requested/initiated upon completion;
7) Temporal pattern - what is the anticipated duration and/or timing and scheduling constraints; 8) End-point - what determines that the request is complete;
9) Abort-conditions - what situations should cause the immediate termination of the action; and
10) Rollback - incomplete components of compound actions are canceled and any actions necessary to return the patient to a stable state are initiated, and a few others.

The question should not be how to teach an old dog a new trick. It should be: Why would we want to teach any dog, old or new, an old trick? We will not realize the potential of computers to improve the health of the patient and the work experience of the physician if we spend our effort and resources trying to emulate processes that were never effective or efficient to start with.