It’s hard to find a business professional who would argue against the importance of data quality. Whether optimizing a manufacturing process or perfecting a consumer product roll out, decision makers naturally want to leverage the most accurate and relevant information at their disposal.
The inevitable trade off pits speed versus accuracy, however. When data isn’t timely, it quickly loses its value. Nowhere is this natural tension more acute than in a hospital trauma center, where accuracy is essential to proper (and safe) care, yet there’s no time to waste in speeding a patient through intake and into the critical process of medical attention.
This is where the use of what healthcare professionals have affectionately dubbed “bogus data” plays a vital role. “Bogus data” is comprised of one or many data values that are inserted into the patient record as placeholders when high quality correct data is either unknown or not yet available. These placeholder values act alone or in concert with other placeholder values to signal to health information management professionals (and to patient matching technologies) that a value must be updated with correct true data as soon as it becomes known or available, and that the placeholder values are meaningless for patient identity purposes. The key is to clearly identify and cordon off such data so that it can be dealt with downstream.
Data is All Over the Map
Consider a car accident victim arriving by ambulance at an emergency room. Such patients often arrive with no ID – it may have fallen out in the car, or been cut away with their clothes while being extricated from the vehicle. Intake staff in the emergency department often enter such patients into the system as Jane Doe, Joe Trauma or some similar name, so the necessary life-saving care can proceed.
On a less dramatic note, people experiencing homelessness often present for services in emergency departments, and yet virtually every healthcare-related intake system requires the entry of an address. Common options include “123 Transient Boulevard” or, more simply, the hospital’s own street address. Baby names are another common example – in this case, the information required to initiate a patient record may not even yet exist and may be further complicated for twins and other multiple births.
Legacy systems tend to be the least flexible, requiring that something – anything – be entered into a multitude of data fields before registration can proceed (non-healthcare professionals used to filling out web forms can certainly sympathize). This info can be as mundane as a date of birth – odds are good that most legacy systems house a disproportionate number of “01/01/1901” entries.
From a patient matching perspective, large groups of patient records containing the same values for various traits naturally “match” and are thus gathered in the same record set to determine if the records represent the same person. To prevent such groupings, organizations must be aware of all “bogus data” conventions utilized throughout their operations and have a unified plan to address them.
A Written Policy for Workarounds
In each of the above cases, the use of bogus data is essential to the provision of immediate and urgent care and to handling known unknowns. The trick comes in establishing procedures to ensure these entries are cleaned up promptly and as efficiently as possible.
Applying creativity to bogus data entries can inject a touch of levity into what otherwise can be a stressful and/or monotonous task. Unfortunately, it only takes one rogue data entry clerk to throw a wrench into the reconciliation process. Best practice calls for a written policy outlining the acceptable conventions for bogus data. This doesn’t mean that all entries need be identical (which could pose its own complications), but they should at least be recognizable.
It may be perfectly clear to a human reviewer that entries like “Joe Trauma” or “123 Transient Boulevard” are made-up placeholder data and need to be revisited. Databases aren’t nearly as savvy, however. By creating a standard set of boundaries, a healthcare organization can feed its data into an algorithm so that known exceptions can be flagged for resolution and, just as critically, so they are not factored into subsequent care decisions or grouped together during patient matching into one giant set of incomplete and/or false identities. After all, the same expedient data entry liberties that are essential to swift care in critical situations become liabilities if not actively and intentionally corrected once time permits.
