EHRSelector Blog

What’s New on the EHRSelector Blog


Congress Getting Real About Interoperability Kills Paul Gag Rule

Note: This was originally posted on

Correction: Brian Ahier looked at this post and made a better search through the legislation. When I searched, I used the same words that had been in use since 1998, which mentioned HIPAA and a national ID. As you can see in his post, the new language does not. I did not use the health ID language. I apologize for the error and thank him for his correction.

Sometimes what Congress leaves out is as important as what it puts in. The CRomnibus Act has an example for HIT. In its hundreds of pages, Congress took three actions to promote HIT interoperability. Two have been widely reported: It ordered ONC to report on interoperability data blocking and to spell out other impediments.

The third action, which I haven’t seen reported, was an omission. Ron Paul’s patient ID gag rule is no more.

In 2000, then Representative Paul (R-TX) put a rider on HHS’ appropriation blocking HIPAA’s call for a unique, patient ID. It prohibited, “planning, testing, piloting, or developing a national identification card.” Given Paul’s statements, this meant no patient ID development. By making it impossible to even think about an ID, ONC could not assess the full range of interoperability options.

Each spending bill since 2000 has had the rider, until now. Noting remotely similar is in the bill. I’m still trying to find out who and when dropped this.

What’s clear, though, is that Congress is serious about interoperability and has given ONC a clear field to develop a real plan. A bad gag rule is gone.


Adverse Event Reporting and EHRs: The MEDTECH Act’s Effects

Note: This was originally posted on:

EHRs and Adverse Events

Medical systems generate adverse event (AE) reports to improve service delivery and public safety.

As I described in this note’s first part, these reports are both a record of what went wrong and a rich source for improving workflow, process and policy. They can nail responsibility not only for bad acts, but also bad actors and can help distinguish between the two. The FDA gathers AE reports to look for important health related patterns, and if needed to trigger recalls, modifications and public alerts.

EHRs generate AEs, but the FDA doesn’t require reporting them. Reporting is only for medical devices defined by the FDA and EHRs aren’t. However, users sometimes report EHR related AEs. Now, there’s proposed legislation that would preclude EHRs as medical devices and stop any consideration of EHR reports.

MEDTECH Act’s Impact

EHRs are benign software systems that need minimal oversight. At least that’s what MEDTECH Act’s congressional sponsors, Senators Orrin Hatch (R- Utah) and Michael Bennett (D- Colorado) think. If they have their way – and much of the EHR industry hopes so – the FDA can forget regulating EHRs and tracking any EHR related AEs.

EHRs and Adverse Events

Currently, if you ask MAUD, the FDA’s device, adverse event tracking system about EHRs, you don’t get much, as you might expect. Up to October, MAUD has 320,000 AEs. Of these about 30 mention an EHR in passing. (There may be many more, but you can’t search for phrases such as “electronic health,” etc.) While the FDA hasn’t defined EHRs as a device, vendors are afraid it may. Their fear is based on this part of the FDA’s device definition standard:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

…[I]ntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals…

I think this section clearly covers EHRs. They are intended for diagnostic, cure, mitigation, etc., of disease. Consistent public policy in general and a regard for protecting the public’s health, I think, augers for mandatory reporting of EHR caused AEs.

Why then aren’t EHRs devices that require AE reporting? In a word, politics. The FDA’s been under pressure from vendors who contend their products aren’t devices just software. They also don’t want their products subject to being criticized for failures, especially in instances where they have no control over the process. That may be understandable from a corporate point of view, but there are several reasons for rejecting that point of view. Consider what the FDA currently defines as a medical device.

Other Devices. The FDA captures AE reports on an incredible number of devices. A few examples:

  • Blood pressure computers
  • Crutches
  • Drug dose calculators
  • Ice bags
  • Lab gear – practically all
  • Robotic telemedicine devices, and many, many more.

ECRI on EHR Adverse Events

The respected patient safety NGO, the ECRI Institute, puts the issue squarely. Each year, it publishes its Top Ten Health Technology Hazards. Number one is inadequate alarm configuration policies and practices. Number two: “Incorrect or missing data in electronic health records and other health IT systems.” Its report says:

Many care decisions today are based on data in an electronic health record (EHR) or other IT-based system. When functioning well, these systems provide the information clinicians need for making appropriate treatment decisions. When faults or errors exist, however, incomplete, inaccurate, or out-of-date information can end up in a patient’s record, potentially leading to incorrect treatment decisions and patient harm. What makes this problem so troubling is that the integrity of the data in health IT (HIT) systems can be compromised in a number of ways, and once errors are introduced, they can be difficult to spot and correct. Examples of data integrity failures include the following:

  • Appearance of one patient’s data in another patient’s record (i.e., a patient/data mismatch)
  • Missing data or delayed data delivery (e.g., because of network limitations, configuration errors, or data entry delays)
  • Clock synchronization errors between different medical devices and systems
  • Default values being used by mistake, or fields being prepopulated with erroneous data
  • Inconsistencies in patient information when both paper and electronic records are used
  • Outdated information being copied and pasted into a new report Programs for reporting and reviewing HIT-related problems can help organizations identify and rectify breakdowns and failures.

ECRI spells out why AE reporting is so important for EHRs:

…[S]uch programs face some unique challenges. Chief among these is that the frontline caregivers and system users who report an event—as well as the staff who typically review the reports—may not understand the role that an HIT system played in an event…

The MEDTECH Act’s Effects

The move to curtail the FDA’s EHR jurisdiction is heating up. Senators Hatch and Bennett’s proposed act exempts EHRs from FDA jurisdiction by defining EHRs as passive data repositories.

Most industry chatter about the act has been its exempting EHRs and others from the ACA’s medical device tax. However, by removing FDA’s jurisdiction, it would also exempt EHRs from AE reports. Repealing a tax is always popular. Preventing AE reports may make vendors happy, but clinicians, patients and the public may not be as sanguine.

The act’s first two sections declare that any software whose main purpose is administrative or financial won’t come under device reporting.

Subsection (c) is the heart of the act, which exempts:

Electronic patient records created, stored, transferred, or reviewed by health care professionals or individuals working under supervision of such professionals that functionally represent a medical chart, including patient history records,

Subsection (d) says that software that conveys lab or other test results are exempt.

Subsection (e) exempts any software that makes recommendations for patient care.

There are several problems with this language. The first is that while it goes to lengths to say what is not a device, it is silent about what is. Where is the line drawn? If an EHR includes workflow, as all do, is it exempt because it also has a chart function? The bill doesn’t say

Subsection (d) on lab gear is also distressing. Currently, most lab gear are FDA devices. Now, if your blood chemistry report is fouled by the lab’s equipment ends up harming you, it’s reportable. Under MEDTECH, it may not be.

Then there’s the question of who’s going to decide what’s in and what’s out? Is it the FDA or ONC, or both? Who knows Most important, the bill’s negative approach fails to account for those AEs, as ECRI puts it when: “Default values being used by mistake, or fields being prepopulated with erroneous data.”

Contradictory Terms

The act has a fascinating proviso in subsection (c):

…[P]rovided that software designed for use in maintaining such patient records is validated prior to marketing, consistent with the standards for software validation relied upon by the Secretary in reviewing premarket submissions for devices.

This language refers to information that device manufacturers file with HHS prior to marketing. Oddly, it implies that EHRs are medical devices under the FDA’s strictest purview, though the rest of the act says they are not. Go figure.

What’s It Mean?

The loud applause for the MEDTECH act coming from the EHR industry, is due to its letting vendors off the medical device hook. I think the industry should be careful about what it’s wishing for. Without effective reporting, adverse events will still occur, but without corrective action. In that case, everything will seem to go swimmingly. Vendors will be happy. Congress can claim to being responsive. All will be well.

However, this legislative penny in the fuse box will prove that keeping the lights on, regardless of consequences, isn’t the best policy. When something goes terribly wrong, but isn’t reported then, patients will pay a heavy price. Don’t be surprised when some member of Congress demands to know why the FDA didn’t catch it.


Adverse Event Reporting: What Is It?

Note: This was originally posted on:
Eric Duncan’s Ebola death in Dallas was, to say the least, an adverse event (AE). Famously now, when he had a high fever, pronounced pain, etc., he went to Texas Health’s Presbyterian Hospital’s ER, and was sent home with antibiotics. Three days later much worse, he came back by ambulance.

In the aftermath of Duncan’s death, the hospital’s EHR, EPIC, came in for blame, though it was later cleared. Many questions have come from Duncan’s death including how our medical system handles such problems. Articles often use the term adverse event, but rarely mention reporting. I think it’s important to take a direct look at our adverse event reporting systems and where EHR and AEs are headed. This note looks at AE systems. The next looks at where EHRs fit in.

The FDA: Ground Zero for Adverse Event Reports

HHS’ Food and Drug Administration has prime, but not exclusive, jurisdiction over adverse reports breaking them into three classes:

  • Medicines
  • Medical Devices, and
  • Vaccines.

Four FDA systems cover these classes:

  • FAERS. This is FDA’s system for drug related adverse reports. It collects information for FDA’s post marketing for drug and biologic product surveillance. For example, if there’s a problem with Prozac, it’s reported here.
  • MAUDE. The Manufacturer and User Facility Device Experience reporting system. If an X-Ray machine malfunctions or lab equipment operates defectively, this is where the report goes.
  • VAERS. Vaccine adverse reports are collected here.
  • MEDSUN. This is voluntary, device reporting system gathers more detailed information than MAUD. It’s run by as a collaboration of the FDA and several hundred hospitals, clinics, etc. (Disclosure: My wife was MAUD project system developer.) MEDSUN captures details and incidents, such as close calls or events that may have had a potential for harm, but did not cause any. MEDSUN has two subsystems, HeartNet, which is for electrophysiology labs and KidNet for neonatal and pediatric ICUs.

MEDSUN Reporting Poster

State AV Reporting Systems

Several states require AV reporting in addition to FDA reports. Twenty-seven states and DC require AV reports, with varying coverage and reporting requirements. Some states, such as Pennsylvania, have an extensive, public system for reporting and analysis.

Patient Safety Organizations

Added to federal and state organizations are many patient safety organizations (PSOs) with an AV interest. Some are regional or state groups. Others, are national non profits, such as the ECR Institute.

The Safety Reporting Paradox

If you delve into an AV reporting systems, you’ll quickly see some institutions are more present than others. That doesn’t necessarily mean they are prone to bad events. In fact, these may be the most safety conscious who report more of their events than others. Moreover, high reporters often have policies that encourage AE reporting to find systemic problems without punitive consequences.

Many safety prevention systems work this way. Those in charge recognize it’s important to get all the facts out. They realize adopting a punitive approach drives behavior underground.

For example, the FAA has learned this the hard way. Recently on vacation, I met two air traffic controllers who contrasted the last Bush administration’s approach to now. Under Bush’s FAA errors were subject to public shaming. The result was that many systemic problems were hidden. Now, the FAA encourages reporting and separates individual behavior. The result is that incidents are more reported and more analyzed. If individual behavior is culpable, it’s addressed as needed.

In the next part, I’ll look at how EHRs fit into the current system and the congressional efforts to exempt them from reporting AEs, a move that I think is akin to putting pennies in a fuse box.

%d bloggers like this: