Keeping Your Eye On The Ball With EHRs

Definition of a camel: A horse that was designed by a committee. The EHR the feds want you to buy is a camel - a computer system designed by a committee. The temptation is strong to address every requirement you can imagine right now. The chance may not come again. Say that you have a "simple" project in mind, then requirements creep sets in. We shouldn't do all this work and not repaint. Now the plumbing fixtures look kind of dowdy. New curtains?

Sound familiar?

A good medical record should be a simple project. It only needs to be legible, complete and individualized describing what was going on with the patient, what the practitioner thought about it and what was planned. What happened as a result of the plan?

In spite of being simple, good medical records have been hard to achieve with paper. Legibility can be a major problem. Some practitioners are stingy with their words. There may be problems with filing and retrieval. Someone else (like billing) may have the chart when you need it.

You think, "I'll bet a computer could help!" Legibility won't be an issue, nor will be getting access to the chart whenever and wherever we need it!

It sounds simple but it's actually a major undertaking. Everyone has to learn new habits; the work flow in the office changes. Practitioners who never documented enough before have to change their ways. These are not easy tasks, and not all software is created equal. Choose poorly and it may be worse than nothing. Getting a benefit takes time and motivation.

Then your requirements begin to creep. We really should automate the billing. Shouldn't the system do the E&M coding? … And order entry and prescription writing and track PSAs and PAPs and remind us when stuff is overdue and interface to the lab, and, and, and....

When you get done with all the "ands," the medical record part - the part that's really important - often gets short shrift. It's relegated to the background (as if it was simple or merely a given) while everyone's attention is absorbed getting all these other modules and functions to work.

Experience tells me that the 80/20 rule applies here. Eight percent of the benefit to patient care comes from the actual chart, but 80 percent of the cost and effort will go into implementing the other 20 percent. The federal incentives give the charting function no special pride of place. It's just another item in a laundry list of features that they say you need. Whether you need them or not is your problem.

Of course, you don't get the money unless you buy something that has been anointed as being "complete" and actually use it in specified ways. If complying with these requirements causes chaos in your office, well, it's just the "cost of doing business."

Daniel Essin, MA, MD, FAAP, FCCP, will be a regular contributor to the Practice Notes Blog. He has been a programmer since 1967 and earned his MD in 1974. He has worked at the Los Angeles County and USC Medical Center where he developed a number of internal systems, chaired the Medical Records Committee, and served as the director of medical informatics. His main research interests are electronic medical records, systems architecture, software engineering, database theory and inferential methods of achieving security and confidentiality in healthcare systems.