FDASIA Report on Regulating HIT

The workgroup that has been meeting is not charged with developing the framework - FDA, ONC and FCC will do that - they're making recommendations. As you will see when you review the draft report, much of what the workgroup has done is to suggest a foundation for the framework.

The workgroup's final report was presented on September 4th, 2013. InsideHealthPolicy reported (subscription required) that few changes from the draft report were expected in the final report, and that was indeed the case.

Recommendations

The recommendations are documented in this PDF file containing the work group's presentation, and this Word file containing explanatory notes for specific slides. The basic recommendations are not a big surprise because they mostly follow the existing legislatively enabled regulatory framework across FDA, ONC and FCC.

The workgroup recommends that HIT be regulated based on whether the use of the products represent any risk to patients or users (a risk-based approach). HIT would be assigned to one of two categories: HIT products subject to risk-based regulatory framework, and those products not subject to risk-based regulatory framework. Making the distinction between those software products that are to be regulated and those that are not is the issue - where does one draw the line?

The workgroup came up with a list of 8 characteristics when considering a product to be HIT or not, and whether it should be regulated. These characteristics are:

1. Intended use (a bedrock concept in FDA regulations)
2. Conditions of use
3. User type
4. Developer type (what FDA currently refers to as "manufacturer")
5. Distribution model
6. Phase of product life cycle
7. Product categories
8. Other

The recommended objective is for FDA to develop defining characteristics that 1) unambiguously indicate whether a product is to be regulated or not, and 2) is sufficiently conceptual to meet future undefined needs. Ideally, a conceptual model would provide an accurate indication of whether some new HIT technology or application would or would not be regulated. Making the regulated/unregulated distinction clear, robust and conceptual will allow software "manufacturers" to rationally decide whether they want to become a regulated company. This clarification will also remove uncertainty regarding specific features, claims, etc., that would have to be removed from a prospective product to avoid regulation. Such determinations are made now, but the actual acceptance or rejection by FDA is unproven until some sort of review.

The report includes interesting examples (slides 16-19) of applying various HIT applications to a basic risk analysis that might serve as a foundation for an analysis aimed at justifying a specific HIT application as either regulated or unregulated. It also serves as a reminder that all HIT vendors should include a risk analysis when they develop, modify or update any HIT software products.

The workgroup included numerous recommendations for the ONC regarding the definition of features required in certain products and how that can create substantial barriers to innovation.

Where the recommendations are most helpful is in calling out the areas where existing regulations and/or empowering legislation is either ambiguous or broken. Pertaining to the FDA, the workgroup came up with the following issues (topic numbers added):

1. FDA needs to explain how to discern disease related claims from wellness, and needs to deregulate low risk disease related claims. "FDA has jurisdiction over disease-related claims, but not wellness related claims. Unfortunately, simple rules in this space sometimes lead to overregulation. For example, a very simple approach would be to say that if any advertising or labeling mentions a disease, as defined in some authoritative compendium of diseases, the product would be regulated. But the mere mention of a disease such as obesity would likely cause very low risk software used to manage weight as FDA regulated. Further, there are many different types of claims and some might make veiled references to the diseases, but not specific [references]. In which such circumstances would FDA regulate the associated HIT? "
2. FDA needs to explain its position on which IT elements are regulated when connected to a medical device, and deregulate or down-regulate those that are low risk. "FDA’s had a long-standing rule which says that anything intended to be used as an accessory to a medical device is itself a medical device and regulated to the same level as the device it accessorizes. But there are many generic accessories that are very low risk that should not take on the regulatory classification of a product it is intended to accessorize. More specifically, we need new accessory classifications that down classify these accessories in much the same manner that FDA created the MDDS classification."
3. FDA needs to explain which forms of clinical decision support software it regulates. "FDA has long regulated certain forms of clinical decision support software, such as computer-assisted diagnosis software used with medical imaging. Unfortunately, FDA has never been very clear on the contours of its regulation for this broad category of software. Much of it is low risk, and indeed much of it is used in a manner that makes it highly unlikely that the patient could ever be hurt. FDA needs to clarify the scope of CDS regulation."
4. FDA needs to specify its rules for deciding the regulatory status of software modules either incorporated into a medical device, or accessed by a medical device. "The development of software involves a high degree of incorporating existing modules into larger software programs that might have a medical purpose. But many of the individual modules are very generic and not particularly intended for medical software. Does FDA regulate the modules? What about for medical device software that is used on a platform where it incorporates other existing modules already available on that platform. Are any of those incorporated modules also regulated?"
5. FDA needs to explain how the Quality System requirements and facility registration apply to manufacturing of standalone software. "The vast majority of devices subject to FDA jurisdiction must meet the requirements of the quality system. Unfortunately, though, understanding how to meet those requirements can be very difficult for standalone software. The regulation was written with physical products in mind. While the basic regulation is written broadly and can be interpreted, industry needs official guidance from FDA on how it should be interpreted for standalone software. Private standards groups such as AAMI are working on this issue and so this might be as simple as FDA officially recognizing that work."
6. FDA needs to adopt a paradigm for reviewing software that is intended to be part of a larger, but unspecified, network. Could build on efforts of a working group of companies, academics, and hospitals that developed and submitted pre-IDE regulatory submission to help define the FDA clearance process. "Typically, when a medical device manufacturer goes to FDA seeking clearance, they are presenting a device with a very defined intended use typically as a solo product. If, instead, the manufacturer goes to FDA with what is essentially a component of the future, unspecified network of devices, the agency is uncertain how to gauge risk and what kind of data to expect. We simply need FDA to come up with a paradigm that informs developers of these network components how to demonstrate their claim of substantial equivalence."
7. Responsibilities for reporting adverse events and conducting corrective actions can be clarified, but also likely need a new approach that reflects shared responsibility across users, producers, and across regulatory agencies. "When something goes wrong with a network of medical devices, it is often unclear where the problem resides. Indeed, the problem may in fact reside between two devices at their interface, as opposed to being the responsibility of one single component. But the laws that enable FDA's regulatory powers were written with accountability in mind, so there are post-market obligations such as adverse event reporting and field corrective actions that are written as though it should be clear whose responsibility it is."

Of the issues described above by the workgroup, items 1, 2, 3 and 5 are relatively straight forward policy issues that look to fall under existing enabling legislation. The resulting frameworks and definitions and will likely be published in one or more guidance documents. FDASIA imposes a deadline of January 9th, 2014 for the FDA to propose strategy and recommendations on a risk-based health information technology framework, including mobile medical applications [already published], that “promotes innovation, protects patient safety, and avoids regulatory duplication.”

Issue 4 concerns software modularization. Software development long ago evolved from writing every application from scratch to dividing software functionality into modules and reusing modules in an effort to improve productivity and reliability (the idea being that reused software modules eventually get all the bugs worked out of them). Issue 4 entails the recommendation that medical device software be divided between software modules that are regulated medical devices and those that aren't. And that software modules that aren't medical devices should not be regulated. This issue also suggests that software modularization would allow for varying degrees of regulation based on the risks posed by individual software modules. FDA currently regulates medical devices as one thing with one risk assessment, be it an embedded system medical device like a blood gas analyzer or a system made up of many components like a patient monitoring network. I believe that much of what is apparently being sought by this issue is already possible under the FDA's current regulatory framework. Comments making a better case for issue 4 are encouraged.

The stickiest wicket in the above 7 issues the workgroup has with FDA is number 6. To create truly interoperable medical device systems that are vendor independent (i.e., the ability to plug and play a variety of medical devices and systems, regardless of manufacturer, and have them all work together) means that the various components are designed to serve a particular function, but the manufacturer cannot anticipate exactly every device it might be used with or the various combinations in which it might be used. Current FDA regulations don't deal with this kind of ambiguity; FDA reviewers want these kinds of variables nailed down, with specific test cases for each one and objective evidence that everything works as specified. As alluded to in the presentation, the workgroup referenced a project that did address this issue and proposed some very specific solutions. This work was submitted to FDA on February 12, 2012 for their review. What FDA does with this issue and how they respond by January 2014 will be most interesting.

The last item, issue 7, deals with two issues. One is a rather weak legislative mandate to require post market reporting (i.e., reports on problems with products after they've been sold and while they're in use). The second issue is an increasing divergence between FDA's mandate to hold individual medical device manufacturers accountable for the reporting and problems associated with their products (one would assume to avoid finger pointing) and the modularization of medical device systems where multiple devices or products from one or more manufacturers are combined and configured to accomplish certain tasks (e.g., an alarm notification system that includes a variety of medical devices, messaging software, mobile communications devices and integration with HIT systems). It would be nice if FDA could strengthen their reporting requirements beyond events where patients are actually injured or killed. As it is, there are many more events where death or injury was luckily avoided. These "near misses" are an important part of how other safety critical industries, like aviation, have constantly improved their safety record. Once certain HIT apps are designated medical devices, both users and manufacturers will be required to report adverse events. Only a legislative change will enable FDA to mandate the reporting of "near misses." The second issue of systems being made up of multiple products from multiple vendors is less certain. Systems of this type are often made up of regulated and unregulated products. Who might compel unregulated vendor's participation remains an open issue. With multiple manufacturers involved in a system, there needs to be a coordinating entity that encompasses all the system components and either does the root cause analysis, or coordinates its successful conclusion. This coordinating entity could be a systems integrator, the customer or one of the multiple manufacturers. Time will tell if FDA can fashion a policy solution under existing law, and what the final product might look like.

Expected Outcomes

The Specific Recommendations presented by the workgroup (slides 35 and 36) are a great reference for describing the expected outcomes from this FDASIA effort. There are 6 high level recommendations:

1. HIT should not be subject to FDA premarket requirements (i.e., regulated as Class II medical devices requiring a 510k or as Class III requiring a PMA), except: A) as accessories to medical devices, B) certain forms of clinical decision support systems, and C) higher risk software.
2. Vendors should be required to list products that are considered to represent at least some risk if a non-burdensome approach can be identified for doing so.
3. Develop better post-market surveillance of HIT
4. Due to the substantive changes proposed, resulting policy and regulations would be provisional and re-examined periodically (and one would assume, revised as appropriate).
5. Adoption of existing standards and creation adoption of needed new standards addressing areas such as interoperability.
6. A public process for customer rating of HIT to enhance transparency.

So let's take each recommendation individually and prognosticate the end result and some potential impacts for developers, sellers, service providers and buyers.

Recommendation 1

HIT will be regulated by FDA using the existing medical device regulatory framework. Many HIT applications will be regulated as Class I medical devices and developers will be subject to implementing a basic quality system (the FDA's Quality System regulation or QSR). Select applications that represent significant patient safety risk, like some clinical decision support systems, will be regulated as Class II medical devices and require the QSR and premarket clearance (a 510k). While I can't think of any examples right now, it is conceivable that some software apps could be regulated as Class III high risk medical devices, requiring the QSR, clinical trials and a PMA. Some software, essentially electronic record keeping applications (e.g., claims processing, benefits eligibility software, billing, scheduling, etc.) will be completely unregulated.

AAMI recommended practice SW87 provides recommendations on implementing the FDA Quality System for software developers of MDDS. Titled, "Application of Quality Management System concepts to Medical Device Data Systems (MDDS)," and largely authored by John Murray, Software Compliance Expert at FDA, this recommended practices document is a great place for any software developer looking to make the transition to a regulated medical device manufacturer.

HIT vendors will become regulated medical device manufacturers. The first thing they should be doing - if they've not already done it - is a gap analysis of existing policy and procedures compared with the FDA's QSR. Determining which products are most likely to be regulated is the very next step.

Recommendation 2

Vendors are going to have to do a risk analysis on their product portfolios as part of an assessment of which products FDA will want to regulate. Any product that's regulated has to have a risk analysis anyway, and the risk analysis for low risk or no risk products will likely be quick and easy (relatively).

Recommendation 3

There will be much broader post market reporting requirements that encompasses newly regulated HIT. Since all HIT vendors with broad product portfolios will be regulated, post market reporting requirements will only require small incremental effort. Getting hospitals and manufacturers to report near misses will be a challenge.

These reporting changes will likely result in a shift in HIT user liabilities and uncertainty about how best to manage risk. Additional reporting could substantially add to providers risk and they may lobby for some sort of shield law to facilitate reporting without increasing their liability.

Providers have always had an effective shield against liability, "best practice" management, policy and procedure over the area of liability. Consequently, let me suggest that the best shield against HIT liability is sufficiently rigorous HIT governance to minimize patient safety risk. That's the good news - that there is a reasonable liability shield available to providers for HIT risk. The bad news is that current IT governance best practice is insufficient to shield providers from HIT patient safety liability. Hospitals and other large provider organizations will have to up their game considerably in this area.

Recommendation 4

Sadly, FDA does not have a tradition of "trying things out" and then adjusting them down the road. Part of that is due to their desire to regulate in a responsible manner and not shifting the playing field unnecessarily. That said, some flexibility could be realized through the normal guidance process where they come out with a draft, which is basically used in trial mode, and then a final version is issued with refinements. Another approach is to shift regulations away from specifics to more of a conceptual framework that would accommodate new and unanticipated technologies and solutions that inevitably come to market.

Recommendation 5

The reasons for the lack of commercially available interoperable medical devices are numerous. There are certain regulatory barriers referred to by the workgroup (e.g., issue 6), and it would indeed be a great thing if those barriers were removed. However, there would remain many additional barriers to interoperability. Mandating standards is a partial solution at best. And none of the agencies who received the workgroups recommendations (the ONC, FCC and FDA) have the power to mandate standards, let alone require they, you know, be adopted and built into products. Interoperability is an important capability, critical to advancing medical device systems safety and effectiveness. But I do not see a short term solution to this problem coming out of work mandated by FDASIA.

Recommendation 6

Customer rating of HIT refers to hospitals, physician groups and other provider organizations who purchase and use HIT. Certainly, FCC and FDA do not have the regulatory levers available to make this happen. The principal barrier to consumer reporting now is the non disclosure agreements that EMR vendors insist their customer sign before they will sell them their software. Perhaps the ONC could make this a requirement of HITECH reimbursement, where EMR vendors would modify or drop their NDAs so their customers can get government payments for EMR adoption. Someone also has to serve as the clearing house for this rating information. Perhaps ONC could provide this clearing house function initially and then transition it to some other entity. If hospitals really wanted to report things precluded by their EMR vendor's NDA, they could sue. Not happened. I don't think hospitals are that interested in consumer ratings at this point. Also, one must consider existing mechanisms like KLAS and HIMSS Analytics.

Elephants in the Room

There is one group of stakeholders who are mentioned by the workgroup a number of times indirectly:  the implementers and users of HIT apps. The draft report acknowledges that HIT applications are:

• Subject to extensive site specific (and customer specified) configuration at installation (and at any time post installation),
• That HIT buyers often modify the source code of the software products that are purchased, modifying adding or removing features, and
• That health care providers sometimes write their own HIT applications that meet the legal definition of a medical device.

Taking the above actions places health care providers in the role of medical device manufacturer. FDA already regulates a number of provider organizations as manufacturers, and may chose to regulate providers who modify or create their own HIT medical devices.

In many ways, the regulation of HIT vendors is the easy, if rather big, problem. However, bringing hundreds or thousands of hospital IT departments under FDA regulation would be quite a task. Likewise, FDA may come up with a policy that treats providers as quasi-manufacturers and only applies a portion of regulations (although it is not clear what regulatory requirements could be cut for providers that would not impact patient safety).

Another player in the mix are systems integrators. The role of systems integrator is well established in safety critical industries like aviation/aerospace and defense. In health care there is no group of vendors who call themselves health care systems integrators. Yet the role played by three distinct groups of companies meets the definition of systems integrators. These groups are:

1. Network value added resellers who sell lots of different kinds of IT equipment besides networks that they install, configure and get to work together into one coherent IT infrastructure;
2. HIT consulting firms that install, configure, interface and modify HIT applications into one or more systems; and
3. Medical device system dealers and resellers who sell and work with products like nurse call systems, messaging middleware, RTLS, point of care computing devices, etc.

Any company that fits any of the above categories, and either sells or services a regulated medical device (soon to include HIT), will likely be regulated as a medical device manufacturer. One wrinkle in this is that FDA currently doesn't formally acknowledge those that modify medical devices, so it is not clear exactly how FDA will deal with this situation (you can read more about modifying medical devices here). You can be assured that FDA will not just "look the other way" while folks modify a regulated product - especially a Class II medical device.

A potential third group impacted by the regulation of HIT is HIT outsourcing providers who staff, manage and operate hospital IT departments on a turnkey basis for hospitals.  Much like hospital IT departments will have to up their game from a governance perspective, so must HIT outsourcing service providers.

Another potential influence on providers and the regulation of HIT could be the plaintiff's bar. In the event of patient injury or death resulting from HIT both the vendor and provider could face legal action. Providers who do not have sufficient IT governance in alignment with patient risk, could be found to be negligent. The resulting awards would most likely have a rapid impact on how providers address HIT patient safety risks. On a parallel track to the workgroup's efforts, in July of 2013, the ONC released its 47-page Health Information Technology Patient Safety Action and Surveillance Plan (pdf).