The Case for Regulating EMRs and the New FDA MDDS Rules

My friend Tim Gee has two great posts covering a couple of very important and timely topics. If you haven’t seen them, check out the following:

The Case for Regulating EMRs

In this article, Tim articulated the following:

My friend Tim Gee has two great posts covering a couple of very important and timely topics. If you haven’t seen them, check out the following:

The Case for Regulating EMRs

In this article, Tim articulated the following:

In testimony at the Health and Human Services’ Health Information Technology Policy Committee, Adoption/Certification Workshop held on February 25, 2010, CDRH Director, Jeffrey Shuren, gently articulated FDA’s intent to regulate EMR applications. He reiterated FDA’s legal and regulatory authority over medical device software, safety issues that have been reported to FDA regarding the safety of EMR software, and possible approaches the FDA could take to improve and ensure patient safety moving forward.

Most of us don’t believe that FDA regulation of EHRs is right around the corner but it certainly may not be that far off. The case that Tim makes in his article is pretty compelling and likely to be followed by FDA soon because patient safety is a legitimate concern in EHR. Given how much ONC is pushing EHRs (through Meaningful Use) EHR regulation will be put off a few years but as soon as we see EHRs more commonly used then we’ll see the FDA jumping in faster. Tim explains the current state of affairs pretty well:

Being unregulated, the HIT industry takes a somewhat casual approach to product development. It is common practice for software to be developed without fully documented or complete requirements. And there is often little or no traceability between requirements and testing of the final product. Post-market surveillance of HIT software rarely extends beyond tracking the average time required to close out a service request. These practices have considerable impact on software quality. The QSR specifies that requirements must be complete and fully documented prior to beginning the design phase. And every requirement must be linked to a specific verification test to ensure the design implements that requirement accurately and reliably. Corrective Actions and Preventive Actions (CAPA) are also a part of the QSR, and define a process for investigating customer complaints (i.e, customer calls for support to the vendor) in an effort to identify latent design defects.

FDA Signals Enforcement with Final Medical Device Data systems (MDDS) Rule.

Tim’s other posting is about the FDA’s new MDDS rule:

On February 14, 2011 the FDA published notice of the long awaited final rule for medical device data systems (MDDS). The real news behind the final MDDS rule is not the less-burdensome path to market trumpeted by many news stories, but the FDA’s stated intent to exercise “enforcement discretion” with regard to those who create MDDS. For the MDDS vendors who are already regulated (Capsule Tech, Cardiopulmonary Corp, Dawning Technologies  and others) this final rule is an easing of the regulatory burden. For those that aren’t (e.g., Bridge-Tech Medical, CareTrends, iSirona,  Cerner and others – I currently track 16 companies in the MDDS category) this final rule signals that FDA enforcement actions will be forthcoming for manufacturers that don’t meet FDA’s implementation deadlines (more on that later).

If you’re a heath IT vendor and not doing any device data integration today the ruling above is probably not very applicable to you; however, even if you’re not capturing such data today it’s possible you’ll be integrating with such devices in the future and you may want to perform analytics on or even provide MDDS features. Keep an eye on this rule.