A Primer on
Understanding Variations in EHR Approaches to Basic Medical Records Functional
Rules
By: Reed
D. Gelzer, MD, MPH, CHCC
Let me begin with a disclaimer: I will mention, from time
to time, various products as examples of particular functions or means to handle
certain tasks. Please do not take these as endorsements, nor anything but
illustrations. There are many well-designed systems out there that I have never
seen. There are others I am more familiar with simply by virtue of requests from
clients to test or evaluate in specific settings.
One major area of variation among EHRs is how they handle the requirement of
authenticating that the information you see is accurate and unaltered. In most
systems, this is handled in the background, not directly visible to the user.
Some older systems do, though handle this in a more visible way. While possibly
off-putting, it actually is a perfectly reasonable way to assure truthfulness.
It is not unlike the paper record, which must show alterations, additions, or
deletions to a record in a very obvious way, in the main (and possibly only)
output record view whether on screen or printed.
Alternatively, if these protective functions are recorded
in the background, in the form of an “audit” or “event trail”, the protections
will not be seen by the person performing the documentation directly. This
information will be recording in the system elsewhere, as supporting data about
the data the User actually looks at. This “data about data” is referred to as
metadata. Some systems save a great deal of detailed information about the
actual stepwise events that users take in the course of assembling the record of
an encounter, including the use of the keyboard to enter free text, or the use
of drop-down lists, forms, or other documentation tools within an EHR’s
“toolbox” for authoring a medical record. This is a significant functional
discriminator between existing EHRs; the degree and sufficiency of information
the system creates and preserves about events and the tools a user employs in
the course of documenting an encounter.
One reason these functions are critical relates to the
absolute requirement that the system properly show alterations in a medical
record whenever they may occur. Amendments and corrections to medical records
occur for legitimate reasons all the time so the system must be able to save
these changes and show them. While some older systems show all the before and
after versions or changes in one and only one available User view or printout,
some do the opposite. These latter take the metadata and render it more or less
available on demand. However, some systems may bury it too far to be useful or,
worse, do not save any at all. Some systems require a skilled (expensive)
database manager to extract information that an auditor would need to
authenticate changes in a record and, in the process, make available the “guts”
of the system in a manner that endangers the security and therefore the
integrity of all the information in the system.
If you get a chance, look at three different approaches to the
integrity/metadata problem of changes to medical records (these observations are
from assessments in early 2005 or before):
1. MediNotes Chart Power. To some extent, the User can set up different primary
views with varying degrees of information in that view (errors, corrections,
task transfers, etc.). The supporting information is very readily available if
it is needed, no special programming or vendor support is needed for auditing
but what the User actually looks at as the primary view is a very clean note
presentation. The info needed by an auditor is just a different set of screen
views and you need not bother with them in your clinical use of the system.
2. CyraMed (formerly XocDoc-glad they changed it...) This behaves like an
analogue of a form in some respects, (but with the advantage of structured data
capture capability). If changes are made, you get a new view. The changes are
preserved in a series of iterations of the same document but that is invisible
to the user. What the User sees is a final and clean view, with all the metadata
in the background and recoverable by paging back thru the different iterations
if needed. Again, most clinicians will never need that but it is there for
auditing, security, integrity support, etc.
3. EPIC (and other systems with MEDCIN embedded like Allscripts, CHCS II aka
AHLTA) With successive changes in a document as it passes from user to user, a
series of iterations are saved (when the User understands the necessity of doing
things in a particular way...) but in the same user view. What you end up with
is a (potentially) long chain of iterations of the same documentation but, again
when used appropriately, each is a partial version of the cumulative activity
thru the encounter. At first, it looks like heck when printed but you quickly
learn that what is pertinent is the last presentation, which is the entire final
note, more or less "clean". In the user view, it is actually the first view you
come to when scrolling down, with prior iterations in a string below it if you
continue to scroll down. If you do not need all the iterations, you simply use
the first view you arrive at when looking at the note.
Again, these are three different ways of handling the requirement of the
preservation of iterations directly or through metadata, either in a system
behavior or as a data set. Each has advantages, disadvantages I suppose and each
system has its other strengths and weaknesses. I offer them only as examples of
designs that do not cause what some HER users describe as a “low signal to noise
ratio”, with notes filled with administrative clutter. Remember, though, that
“noise” in one setting is signal in another (like in court).
This is exactly the sort of topical area that really helps people evaluate the
functional capabilities of EHRs. I hope to point people in the direction of
products they can get their hands on to see that similar problems can be handled
differently but nonetheless well.
Remember, none of the above is an endorsement of any given product or means of
address of a given functional requirement. Until product certification is
available, only you, the person who takes responsibility for the veracity of
your medical record can decide whether a given system meets your requirements.
If you are unsure, engage someone who can support this vital due diligence need.
RDGelzer
Advocates for Documentation
Integrity and Compliance
