For all their promise, electronic health records sometimes suffer from design flaws that can lead to processes that are just plain nonsensical.

I’m a self-proclaimed health IT enthusiast. I applaud providers who ditch paper and embrace tablets. I always pick the portal over the telephone to schedule my appointments. I get a little giddy when I’m able to walk out of my doctor’s office, head to the pharmacy, and find my meds ready for pick-up, thanks to the miracle of e-prescribing.

But as much as I love health IT, I realize that our not-so-perfect systems have the potential to create some absurd workflows. Case in point: I recently I made a trip to the emergency room as patient. Despite my physical discomfort (all is well now), I did my typical perusal of all things health IT-related there, and paid particular attention to how the staff was using the EHR.

I noted that no one was documenting at the point-of-care; everyone not providing direct patient care was staring at a computer monitor. Staff jotted new notes either onto a paper copy of my (two) previous ER visits or on a paper intake form.

It was the intake form that particularly intrigued me because the staff seemed very set on following it precisely. Part of the conversation with my nurse went something like this:

Nurse: "Do you drink alcohol?"
Me: "Yes."
Nurse: "Do you drink once a day, socially, or more than three drinks a day?"
Me: "Once a day and socially."
Nurse: "No, no, no. You can only have one answer. It has to be either once a day or socially."

Really? The intake form – which was obviously based on the EHR’s format – apparently required users to provide a single, discrete answer for each question. Because of the EHR’s design, the staff was apparently unable to accurately record my practice of drinking a glass of wine a night and partaking in more than one serving while in a social setting.

Once I fully recovered from my ER visit, I got to thinking about other ways that EHR design and workflow are creating processes that don’t always make sense. I recalled a series of visits I had with my daughter when she was experiencing some foot pain. I took her to an orthopedic surgeon, who diagnosed her with plantar fasciitis. During the initial visit the medical assistant took her blood pressure, which seemed reasonable given that the doctor had never seen her before and wanted to ensure her general health was normal.

However, I did find it a little over the top when her blood pressure was taken for each of the two follow-up visits. After all, her case was pretty straightforward: she visited the doctor because her foot hurt; after a little physical therapy and KT tape she was back to normal. I understand that the blood pressure check was incorporated into the workflow to allow the practice to justify a higher level of billing, but does it make it any more logical?

And don’t get me started on the necessity of asking a 12-year-old about her smoking and drinking habits.

EHRs are often criticized for their poor design and lack of usability. While it’s convenient to blame EHR developers for awkward workflows and program limitations, meaningful use and other regulatory and reimbursement requirements have contributed to EHR usability issues and documentation requirements that are seemingly relevant, at least in certain care settings.

Interestingly, the Centers for Disease Control and Prevention just published a report that found EHR adoption in EDs had jumped from 46 percent in 2006 to 84 percent in 2011. While impressive, the CDC also pointed out that in 2011 86 percent of EDs had not implemented EHRs that could support at least nine of 14 Stage 1 meaningful use objectives.

James Augustine, MD, an American College of Emergency Physicians board member, suggested that one reason EDs had failed to implement all the core objectives was because the government “didn’t necessarily set the right targets for what’s necessary to support patient care in the ED.” In other words, some of the meaningful use criteria were irrelevant to the care setting.

Even if some of the objectives don’t seem relevant, vendors wishing to remain competitive must continuously add functionality to meet the latest regulatory and certification requirements. Providers wanting to play the meaningful use game or maximize their reimbursements must incorporate these functions into their workflows – even when the captured data doesn’t enhance patient care, or necessitates using a strict documentation format that is illogical or even absurd.

Sometimes you have to wonder who and what are driving the patient care process. It’s hard to blame the well-intentioned bureaucrats for pushing forward the EHR agenda, despite the sometimes illogical requirements. And it seems unfair to blame the EHR developers for sacrificing usability in order to get product out the door in time to meet the latest government and payor mandates.

I’m not sure who or what to blame – or, more importantly, how to fix these absurdities.

I do know, however, that if anyone suggests I change my drinking habits in order to conform to their EHR, I’ll be looking to blame all sorts of people.