Santa Rosa Consulting has a great series of webinars on medical device connectivity and related issues, and I've been tapped for the October webinar. My topic revolves around the likely regulation of EMRs by the FDA and the potential impacts such a change might have on providers and manufacturers.
The following is my first take on the topic, and serves as a description of webinar. Any suggestions, points of view and links to relevant content on the Web (news stories, blog posts, regulations, etc.) is welcome.
Register for this webinar here, to be held on October 27, 2010 from noon to 1pm EST.
The Case for Regulating EMRs
From a quarter century point of view, it seems inevitable that the HIT industry will be regulated by the FDA. Look past all the hand waving and hyperventilating caused by this suggestion, and one sees that the HIT industry is already regulated by the FDA. For examples, look no further than blood bank software and PACS. The Center for Biologics Evaluation and Research (CBER) started regulating blood bank software via the premarket submission process in 1996. From their inception, the FDA considered PACS as accessories to diagnostic imaging modalities, and thus regulated. (Many PACS components have since been reclassified in recognition of their independence from imaging modalities.)
These examples aside, the HIT industry has pretty much avoided FDA scrutiny by claiming they're just automating administrative tasks and paperwork (i.e., workflow around the paper chart).With the advent of decision support systems tied to CPOE and other applications, "administrative" HIT systems have come to be increasingly recognized as a source of patient safety risk. See Margalit Gur-Arie's post at the KevinMD blog.Perhaps the story that's created the most buzz about the danger of EMRs is this Huffington Post piece from April, 2010.
On February 25, 2010, at a HHS panel meeting, Jeff Shuren reported:
The Food & Drug Administration has received 260 reports of health IT-related malfunctions with the potential for patient harm in the past two years, including 44 reported injuries and six reported deaths, said Dr. Jeffrey Shuren, director of FDA’s Center of Devices and Radiological Health.
Vendors, patients, clinicians and facilities voluntarily reported the problems but, because of that, “they may represent only the tip of the iceberg in terms of the HIT-related problems that exist,” he said at a Feb. 25 hearing of the Health IT Policy Committee’s adoption and certification work group, a Health and Human Services Department advisory panel.
Because there is no legal requirement for providers or manufacturers to report patient deaths or injury (or "near misses") due to EMR and related software, many believe these numbers represent the tip of the iceberg.
All of this has generated a growing call for the FDA regulation of EMRs. As HIT system architect Shahid Shah observed:
Yikes. We see all this focus on “meaningful use” but almost no discussion on safety critical systems and how the government will ensure that software being built is being built right and with high quality. Without stricter regulations like we have on medical devices, I’m afraid we won’t get the safety attention we need to bring to bear.
Regulators at the FDA and manufacturers have been grappling with how best to regulate software since the mid 1990s and before. With the advent of the iPhone, the topic of the potential regulation of smart phones is heard with increasingly frequency.Many of the issues here are related or similar to those revolving around EMR regulation.
The FDA's been spending some quality time thinking about all this. As evidence, there's this interesting analysis of HIT adverse events into 4 categories. Of course, the optimal solution to these patient safety issues continues to be debated by HHS and FDA -- who both want to claim the mantle of "EMR regulator."
Impact on Manufacturers
Three words: Quality, System, Regulation. In some cases, software buyers don't want to know how the sausage gets made. It is common practice for HIT vendors to:
- Write software without documented and complete requirements
- Have little or no traceability between requirements and testing
- Provide little or no post market surveillance of installed products
That's not to say that all HIT vendors, or all EMRs represent egregious examples of these product quality shortcomings -- they don't. But vendors will likely have to implement some sort of basic quality system to improve software quality. Meaningful post market surveillance is a no-brainer. And should regulators be more aggressive, there could be requirements for human factors engineering to optimize usability.
All of these changes will impact how products are delivered and costs. There will be no more quick and inexpensive product customization to win a sale. And the time between product releases will increase in an effort to wring as many latent software defects out of the code as possible. A mechanism for product recalls is also likely. And all of these potential changes will somehow roll downhill on to providers.
Impact on Providers
The safety and effectiveness of an EMR extends beyond writing code or even the initial implementation and configuration, as implied by this quote from the Huff Post piece:
Justin Starren, a physician who oversees technology at the Marshfield Clinic in Wisconsin, lays out the dilemma starkly: “Computers are strong medicine. Done well, they are wonderful; done poorly they can kill people,” he said.
How an EMR is used, managed and supported by the customer has a significant impact on patient safety. This will impact both costs and operations (which again, impacts costs). Here's my summary list of provider impacts:
- Higher purchase price from HIT vendors (but probably not a lot, due to competition).
- Much higher operating costs, though providers should be able to leverage some IEC 80001 investments.
- Providers will be challenged when it comes to modifying purchased EMRs if they are a regulated medical device.
- Risk management will need to be beefed up considerably - better governance, better documentation, deeper more substantial risk management focus.
- Change control will also need to be brought up a few notches in many organizations, and expect to be driven by product recalls and other post market surveillance results.
- Interoperability and connectivity between 1) similar systems in other provider organizations, 2) between information systems in the enterprise, and 3) between EMRs and medical device systems all add complexity and risk to broader HIT systems.
- Test, test, test! The system of systems (#6 above) installed in any one location is unique and has never been tested by any one manufacturer - just manufacturers testing their own bits and pieces.
- The slow trickle of IT people currently leaving hospitals for banks, big box retailers and other IT-intensive and low-risk employers will grow considerably.
All this begs the question of what providers (and HIT vendors) should do in anticipation of the inevitable? These are substantive changes impacting strategic plans, purchase plans and daily operations. I'll be recommending best practices for providers in the webinar.
Let me leave you with another question: When EMRs are regulated medical devices, does that mean that IT will report to Biomed?
There will be much more in the webinar on October 27, 2010. Hope to see you then!
UPDATE: Here's the link to the webinar on Santa Rosa Consulting's site. This topic has proven of such interest that I've written a more in-depth story for Patient Safety & Quality Healthcare magazine. I'll post a link when it goes up some time in February.
UPDATE: Here's the link to the story I wrote for PSQH magazine on FDA regulation of EMRs, titled The Case For Regulating EMRs.
Tim,
I was asked by the FDA to moderate a session in the late 90’s on this topic. Coming from the world of PACS and software GMP, It seemed appropriate to me that at least GMP should be part of the broader HIT requirements. But I can tell you that I barely escaped the session with my head attached. There was so much drama from the IT vendors present who vociferously contended that they were merely doing “library functions”.
To the PACS community, regulation seemed to be a pain in the early days, but actually, having a more robust software process actually saved Merge money and resulted in more satisfied customers.
I agree with you that some level of regulation will likely forward the interoperability goal beyond PACS into the larger HIT community. There is the same level of FUD in the larger community that was concurred in PACS in the late 90’s.
Why do these things in medical take sooo… many years to accomplish?
Tim,
Great to see back at your blog!
Interesting post - from the provider perspective I would add that it will be more difficult, especially with larger providers with many specialties to satisfy, to implement an EHR system. There are few vendors out there who can offer the soup to nuts (ambulatory to critical care EHR/EMR coverage) and many of the specialties are holding out due to their specific requirements. The customization helped the administration to meet their specialists’ demands. If the customization becomes less of an option, it’s going to be difficult to meet some of the other demands (MU, IEC, etc) pushing on the providers from many directions to ‘go electronic.’
And yes, you are correct - device interop may take a hit as it is usually not highest on the functionality list (and is listed only a medical device interop for MU in 2015 with no specificity).
Then there’s the mHealth market….. 🙂