A Bad Match: The Danger of Combining EMS Records and HIEs

Health information exchanges (HIEs) are delicate, complex, math-heavy technology—even more so when it comes to understanding the distinction between EMS and in-hospital data and why the two have had trouble interoperating. Clinicians, IT analysts, and regulators may not need to know the details behind HIEs, but they would be wise to understand the implications when it comes to supporting data quality and associated limitations on information sharing.

It’s an unfortunate trend that seems to be accelerating: Some governments and health information organizations (HIOs) want to link their HIEs and state EMS databases. The goal of saving money by consolidating systems is admirable, but linking EMS repositories and HIEs without a quality control stopgap is a public heath disaster waiting to happen. EMS data is generally subjected to more porous quality controls than personal health information (PHI) captured elsewhere along the care continuum. This is no one’s fault per se (though more efficient QA/CQI systems can reduce the sieve effect). Rather, it’s a function of the nature of emergency operations: Fire and EMS are the only participants in the healthcare system, anywhere in the world, that routinely engage unknown patients.

A patient who is unconscious, mentally unstable, etc., cannot validate his or her identity, so prehospital data collected, then submitted without a strong QA process or a PHI “filter” applied before the record(s) hit the HIE can contaminate the HIE. A PHI filter acts like a second validation layer, examining the quality of patient-related details beyond those managed by Schematron, the logic rules engine behind the National EMS Information System (NEMSIS). Schematron ensures the clinical and statistical quality of a record meets state and national expectations, but it does nothing to ensure that patient-specific data are current and correct. Schematron applied to ePCR data cannot, for example, deduce that two patients who reside at the same address—and have the same name but different ages—are different people. It cannot know if the crew accidentally left off Jr. or Sr. from the patient’s name, or if the age and address are wrong.

Thus, the inability to validate identity in the field can be clinically dangerous. Use my name as a real-world example: Schematron cannot know whether Jonathan Feit and Jonathon Feit are the same person with a misspelled first name or two different people. Turns out there is a lawyer in Charlotte named Jonathan Feit. If I am visiting that city and have a medical emergency, the Mecklenberg County EMS crew might ask a bystander for my name but spell it the common way. If they look me up the state’s HIE—but spell my name incorrectly, the common way—they will find the wrong person, without a way for EMS to know the difference. If they treat me correctly according to a different person’s medical chart, I could be seriously injured or worse.

The Root of the Problem

Other than the Departments of Defense and Veterans Affairs, the United States lacks a nationwide HIE. Because I have not authorized the use of my data in interchanges such as CommonWell or Care Equality, my PHI is not legally searchable outside the facilities where I visit clinicians. In fact, a persistent challenge faced by companies and HIEs that seek to bring patient data from central repositories into clinicians’ hands is that the contracts guiding such interchanges—which let them share data among disparate databases and across vendors—require proactive affirmation of permission: The patient must permit the PHI lookup. This restriction is the reason why my company became the first EMS-facing member of the CommonWell Health Alliance in September 2015 but ultimately backed out of it: Affirming permission to share data is a reasonable mandate when seeing a doctor in an office, but it fails in an ambulance because you cannot always get permission from the patient. Yet these organizations rendered no exception for prehospital lookups.¹ This hiccup persists in ET3, and it remains to be seen whether CMS or the Center for Medicare and Medicaid Innovation (CMMI) will realize that gaining permission to access PHI is not always possible in a prehospital context.

In some areas just a fraction of ePCRs are checked for quality before being sent into the state data repository. Since it is impossible ascertain the identity of John and Jane Does other than by using biometrics, how can a crew know it’s accessing the right patient’s data—then sending the right patient’s data into the repository for subsequent access? If the HIE links to the EMS repository without a filter, then the full range of possible errors—incorrect SSNs, birthdates, even one twin’s fraudulent use of a sibling’s ID to obtain medical benefits—will become unwittingly accessible by other downstream caregivers. By the time the errors are identified, how many times will the patient have been seen?

Preventing a data-driven disaster and the associated liability is the role of a PHI filter. Like carbon for data, a PHI filter will protect the HIE from unvalidated data so it cannot accidentally be used to populate “child” charts. Unwinding errors after an HIE has already been used to insert data into subsequent records quickly becomes a task so monumental that Keith Parker, CIO of Arizona’s statewide HIE, Health Current, described his team’s efforts during a conference discussion in August 2019:

“We started tracking overlays and matching and… what I saw is, OK, if you do the MRN [medical record number], now you make that authoritative…now you have an alias associated with that MRN inside the back end to track that code. Now I go to another hospital and have another event there—now that’s authoritative as well [the MRN at the second hospital]. You have two conflicting numbers with an alias in the back.

“I think overlays are more dangerous than duplicate records… You can unwind it, and it’s a pain in the ass… We’ve been working on that for quite a while, because how do you actually unwind it?… And that was only a little over 200,000 patients. Because 200,000 overlays equate to how many other records that came in? And you have to track all of the iterations, all of it, and then you have to be able to put a fence around them.”²

In North Carolina EMS data sharing to the state HIE, NC HealthConnex, is mandatory. Yet in May the state’s EMS data repository operator sent an e-mail that read: “Instead of the NC HIEA (Health Information Exchange Authority) partnering with nearly 500 EMS agencies across the state individually to submit data, the N.C. Office of EMS has been working with them to send the required data, since each agency already submits patient care data to our office (via PREMIS/Continuum and through third-party software vendors).”³ Security and legal questions remain: How will patients’ identities be reliably matched? Can a repository choose to share data with other organizations, or must each agency and even patients be offered a chance to opt out of sharing?

One widely distributed ePCR markets an interoperability tool that uses barcode scanning to start data sharing. According to a senior executive the product “will wait until we have received a HL7 message before we send the run sheet. The matching criteria is facility plus CSN [contact serial number]. You can make a decision whether the matching criteria is sufficient for your purposes and include or exclude data as you see fit.”⁴ If crews are challenged to ID their patients in the field, how can they possibly validate information provided to them by a hospital, which they have not themselves collected and have no way to confirm?

A Safer Alternative

Requiring prehospital care agencies to verify the accuracy of what they’re scanning as they hand off the patient to the hospital places intense liability risk on the transporting EMS agency. The risk of barcode scanning and similar processes to automate ID validation was decried by 33 organizations, including the American Medical Association, American Health Information Management Association, and Blue Cross Blue Shield Association, that wrote to members of the House and Senate Committees on Appropriations. These organizations, which represent thousands of clinicians and medical informaticists, noted that liability falls onto whoever acknowledges a patient’s identify to let information flow: “Patient identification errors often begin during the registration process and can initiate a cascade of errors, including wrong site surgery, delayed or lost diagnoses, and wrong patient orders, among others, the organizations explained…incorrect or ineffective patient matching can have ramifications well beyond a healthcare organization’s four walls.”⁵  

A safer alternative is to deploy a middleware intermediary between the EMS repository and the HIE, which will “ingest” EMS data and provide a break point that alerts all stakeholders about details like similarly named patients sharing an address but who have different birthdates, or high-risk records (e.g., cardiac, stroke, sepsis, etc.). It will allow exceptions to be confirmed (for example, it is possible that a parent and child can have the same name and birthday, but not the same birth year). Filtering EMS data intelligently before it touches the HIE will ensure it meets not only Schematron’s requirements but also a high enough quality threshold that it underscores the value of prehospital insights, instead of dumping one database’s “dirty data” into another.

Wrote health informaticist Enrico Coiera, et al., in the Yearbook of Medical Informatics: “The introduction of health information technology into clinical settings is associated with unintended negative consequences, some with the potential to lead to error and patient harm. As adoption rates soar, the impact of these hazards will increase… Numerous studies have described unintended consequences in different settings such as residential aged care homes, and with different HIT beyond EHRs, such as barcode medication administration, health information exchange, hands-free communication devices, and speech recognition… Complicating matters further, while some negative consequences cannot happen without the use of an electronic system (computer menu pick list errors), others [that] existed in the precomputer world (writing in the wrong patient’s notes)…might become more likely with automation.”⁶  

From an unconscious patient who cannot validate demographics to the natural results of documenting in a hectic environment (e.g., typos), agencies would be wise to resist the idea that crews have enough knowledge at the ready to independently verify information provided to them by a hospital. After all, how does the hospital know the correct spelling of a patient’s name that was verbally conveyed? The overriding quality question in EMS is whether ePCRs enforce sufficiently rigid validation rules that they can ascertain a patient ID and avoid a potentially lethal mismatch? In general, not yet. But we’re getting there.

References

1. Feit J. Beyond Lucid Technologies Becomes the First EMS-Facing Member of CommonWell Health Alliance. Medium, 2015 Sep 18; https://medium.com/beyond-lucid-technologies/beyond-lucid-technologies-becomes-the-first-ems-facing-member-of-commonwell-health-alliance-39aa4515c981.

2. Postpresentation discussion between Keith Parker and Jonathon Feit, Arizona Rural Health Conference, August 2019.

3. E-mail, May 15, 2019.

4. E-mail, April 5, 2018.

5. Snell E. Health Information Exchange Hindered by Patient Matching Issues. EHR Intelligence, 2018; https://ehrintelligence.com/news/health-information-exchange-hindered-by-patient-matching-issues.

6. Coiera E, Ash J, Berg M. The Unintended Consequences of Health Information Technology Revisited. Yearb Med Inform, 2016; 1: 163–9.

Jonathon S. Feit, MBA, MA, is cofounder and chief executive of Beyond Lucid Technologies, Inc.