Skip to content Skip to navigation

Medication Reconciliation—A Field of Onions (Part I)

November 4, 2011
by Joe Bormel
| Reprints
Peeling back the layers of MedRec's biggest challenges, with usability being chief among them

Last week, I attended the American Medical Informatics Association (AMIA) conference in Washington, DC. This conference is the largest U.S. gathering of practitioners, researchers, academics, and government/policy professionals working in informatics. The social networking alone is worth the price of admission. There are dozens upon dozens of published experts in every dimension of medical informatics, and nearly all of them have real world experience from one or more healthcare systems that have completed productive and innovative projects.

In this post I want to focus on a single topic from the conference medication reconciliation (MedRec). It is broadly recognized that medication reconciliation is a fundamental part of patient safety and has challenged commercial and noncommercial designers, developers, and implementers for years. Like working in a field of onions, you need to peel back the layers of several different onions to see what is really going on.

By necessity, this is a two-part blog so I can present the necessary details. MedRec is a topic of central importance to Meaningful Use and patient safety, and medication reconciliation in general is poorly understood, as you’ll see as you read on. In this, Part I, I’ve included some background and a series of MedRec assumptions. In Part II, I’ll present my thoughts on the way forward.

It's generally accepted that MedRec is at best challenging without electronic enablement. Although medication reconciliation was named by The Joint Commission as an accreditation requirement in 2006, the requirement was dropped (technically re-designated so that it was no longer scored) in 2009 in recognition of the lack of proven strategies for accomplishing it.

When technology is brought into the picture, there is tremendous potential to improve on safety, as well as possibly worsen it. Arguably, the biggest challenges are displaying available information and interacting with that display. These are popularly referred to as usability issues. Not surprisingly, they received a lot of treatment at AMIA, as were the related usability requirement definitions for Stage Two of Meaningful Use.

In my experience, a central recurring flaw is how the MedRec problem is defined and, therefore, what the requirements are for a solution. What follows is a list of assumptions that lie beneath the problem.


1. The "two list" assumption, i.e. reconciliation is all about one list before reconciliation and one list after completing a reconciliation. That's true at a very high level for ambulatory MedRec; however, that assumption rapidly breaks down in other areas. There are often effectively more than two “lists” and they are just as often likely to be wrong and incomplete.

2. Setting and context of care dramatically influence and/or change the problem. An example here is that sub-specialists in an ambulatory delivery setting do not feel trained or comfortable reconciling drugs outside of their practice area. So, for instance, it’s difficult for a non-rheumatologist to tell a patient to continue taking their dangerous rheumatic drugs. The non-rheumatologist will say to the patient, "Continue as you were directed," not knowing with confidence what those directions were!

3. The assumption that it is possible to separate reconciliation from ordering and ePrescribing is often made by non-clinical solution designers. The notion is that you start and complete the MedRec process after ordering and ePrescribing are complete is a potentially dangerous assumption. What happens if, during the reconciliation, you notice that a drug should have been continued but wasn’t? You order it (inpatient) or prescribe it (ambulatory). If the reconciliation software doesn’t support this, those medication list displays are blind to the changes being made. That’s very bad, because the reconciliation report won’t reflect what actually happened or accurately reflect which drugs the patient was told to take.

4. The wishful design assumption that the medication list display can contain only the list of medication names, and ignore the explicit reason, aka intent, behind the use of the medications:

- The therapeutic intent (indication) for each drug, e.g. Zoloft for panic attacks. The indication can impact dose and other prescribing details like frequency of use.

- The contextual intent, e.g. hold Coumadin before surgery and restart after follow-up per your surgeon.

- The experience-based intent, e.g. discontinued because of allergy, inadequate affect, side effects, etc. If a physician doesn’t know that another physician deliberately discontinued a medication and why, they will not be able to reason adequately on what to do for the patient.

- The unintended intent, e.g. stop taking the medication because I ran out of visit time, or forgot to consider asking the patient or myself whether to continue or discontinue it.

5. The assumption that our current practices around medication documentation prior to instituting medication reconciliation are adequate. Medication reconciliation often presupposes that a patient, doctor and nurse can pull together and write down what medications a patient is taking. This isn’t always the case. Patients and their families aren’t necessarily competent historians. I certainly don’t remember when I started and stopped medications in the past.




Dr Joe,
Great piece...can't wait for part two.
This is a great example and shows why we can't just throw together a system quickly and install it. The system's designer, particularly if they do not have a MD (or in this case a PharmD) degree has to uncover each layer then design and code accordingly. Then when he/she gets to thinking they got it 'done' somebody comes out with a new drug or protocol.

It also helps answer the age old question as to why there still are so many 'legacy' systems running today. Once the system builder figures out the Onion, gets it coded and working properly (usually takes about 3 yrs!) the last thing you want to do is start over again with a new tools set even though the Microsofts, Oracles and Googles will promise you it will let you code three times faster.

And what about the issue of medication conflicts, and we know there are MANY more Onions in other medical/ patient care disciplines.

My last thought is the Onion patch is enormous, and the variety of Onions is almost infinite, hence a perfect justification for best of breed solutions link together via sound interop tools. One happy farmer can't cover it all.

Doc Benjamin,
Thanks for the supportive comment.

You are quite correct. As suggested by the title, A field of onions, there are many layers to MedRec. One model of layers has "people" as the outer most layer. People is a code word incorporating clinicians behaviors, values, incentives, and abilities, which in turn, impact patients. There are a lot of issues there, including the important team work between physicians and nurses in the process.

Beneath that layer are knowledge, process, skills, application and platform layers. Each contributes to the viability and effectiveness of MedRec.

Here is a link ( ) to the monograph pictured in this comment.  It does a great job of addressing the issues that I think you're referring to.

Thanks again for your comment.


Thanks for the comments. It's only the observant and savvy outside audience that sees the entire orchestra and is aware of the orchestration.

I hope you enjoy part 2. The text and videos make it clear that it's well beyond a typical engineering challenge.

Dr. Bormel,
Very good points, both recognizable and valid. However, you appear to have skirted some important issues.

It's not simply a matter of getting the medication reconciliation application right. It's also a matter of handing off information between providers and helping make the process as close to fool-proof as possible for patients.

Doc Benjamin