An electronic health record (EHR) is a lot like a swimming pool. The chart notes and other entries are analogous to the water in the pool. If every entry was complete, accurate and timely, it would be as if the pool had been filled with pure spring water. In reality, not every entry is pristine; these are the ones that constitute the pollution.
"We don't swim in your toilet. Please don't pee in our pool," read the sign in my uncle Al's dressing room. It got me thinking. How many people peeing in the pool simultaneously would it take to keep me out of the water? Probably not just one, that happens all the time and people still swim. What about 10 or 100? Is it simply the thought of the pee or must the water actually become discolored? It depends on a person's degree of fastidiousness.
One's perception of the risk has no relationship to the actual risk. Pee is not actually toxic but pesticides, dioxins and PCBs (polychlorobiphenyls) and other poisons are - and in relatively small quantities yet people have a visceral reaction to pee in the pool and may over-react to the thought of it . The reaction to other pollutants is more cerebral and one may under-react, perhaps from ignorance or because the threat seems remote.
An electronic health record (EHR) is a lot like a swimming pool. The chart notes and other entries are analogous to the water in the pool. If every entry was complete, accurate and timely, it would be as if the pool had been filled with pure spring water. In reality, not every entry is pristine; these are the ones that constitute the pollution. As in the pool, the hazard created by the polluted entries can easily go unrecognized and under-appreciated.
Some EHR products are more likely than others to get polluted.
• Form-based systems with lots of entry fields and strict "edit checks" interfere with clinicians' accurate recording of actual events; they resort to entering something, anything, that the system will "accept," or they simply skip a recalcitrant field if they can.
• Template-based systems characteristically begin with the "boilerplate" of a typical problem-focused encounter but the average patient presents with 3.5 problems. The clinician is expected to delete what is not applicable or not done, add additional material as appropriate and update elements that have changed. Everyone remembers "dry labbing" from college. When in a rush, or if someone is not the compulsive type, it's too easy (and common) to accept a template without making the needed edits.
• EHRs may incorporate rules that are configured to complain about items that are clinically acceptable at a given facility or in a particular specialty. As in the story of "the boy who cried wolf," when a large proportion of the alerts are considered to be irrelevant or hectoring, clinicians quickly develop the habit of ignoring all alerts, even the occasional important one.
• A good EHR should make it easy and satisfying to create an accurate record. Unfortunately the number of ways in which an application can impede the process are apparently limitless.
What degree of pollution of an EHR will cause the practitioners to conclude that none of the entries can be trusted? I don't know of any studies that address this question; I suspect that a modest level of pollution would be more than sufficient. Physicians do not like to get "burned" and won't put up with it happening more than a couple of times. Spending a lot on an EHR only to have the clinicians lose confidence in it would be a terrible waste of monetary and human resources. The propensity of a particular EHR product to generate chart pollution should be carefully evaluated as part of any purchase decision.
Daniel Essin, MA, MD, FAAP, FCCP, is 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.