Post date: Dec 7, 2010 3:13:13 PM
Phyicians Practice has a somewhat graphic view of electronic health record (EHR) data quality in EHR Data Pollution: Danger Below The Surface. They point to a number of ways that EHR data gets 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."
Clinicians resort to workarounds or dirty data leads to unintended errors from e-iatrogenesis. Do clinicians have the time or will to address data quality problems? Lee's (2003) research suggests an information discourse is used to find the context of data before using context-reflective mode of problem solving. Quoting the abstract: "These practitioners break old rules and revise actionable dominant logic embedded in work routines as a strategy for crafting rules in data quality problem solving." Can this actually be done in a clinical setting especially when many EHR's are hardwired?
Reference:
Lee, YW 2003, 'Crafting Rules: Context-Reflective Data Quality Problem Solving', Journal of management information systems, Vol. 20, no. 3, pp. 93-119.