Originally published by mobihealthnews.com.

FDA's exemption for EHRs seems headed the way of the dodo bird. Nobody planned it that way, but a combination of opposing trends-- the trend toward greater and greater functionality for EHRs and the trend toward greater FDA regulation of any software functionality that can impact patients -- means there may very well be little left of the traditional EHR exemption in the future. That second trend was really brought home this past week when FDA held a hearing on the scope of its planned oversight of clinical decision support software. More on that later.

Industry needs to start planning its response now. And when I say industry, I'm including not only traditional software vendors, but those users that potentially cross the line of FDA jurisdiction by modifying what they purchase. Industry's response can include a wide range of activities from advocacy to ensure the agency understands the importance of a light touch in some areas of software development where speed and agility are essential, to preparing for FDA regulation for those types of software that clearly and directly impact patient care.

Technology Trends

I'm a liberal arts guy, so I won't even pretend I can offer great insight into the direction of IT in hospitals. But here's my 100,000 foot summary of what I hear is going on.

A long time ago, the concept of EHRs started as a way merely to better record the health-related information the doctor wanted to preserve in a patient's file. Basically, early EHRs automated recordkeeping. That automation offered advantages in terms of tidying up unruly files, and at least conceptually offered a quicker route for retrieval as well as lower-cost for storage.

To state the obvious, the digitalization of healthcare, though, hardly stopped there. At least two enhancements were quickly identified:

  1. Instead of manually collecting information, some vendors and users decided to digitize the information generated by a medical device for easy import into the EHR.
  2. Once users had this enormous treasure trove of digital information, they only naturally began to identify algorithms and other ways to make better use of the digital information. Healthcare professionals wanted to use the information to improve individual patient diagnosis, medical research and the overall quality of care.

Those two technology trends are making FDA more and more interested in regulating at least certain aspects of EHRs and associated software.

FDA Regulatory Trends

Over the last couple years, FDA has had an internal task force working diligently to clarify its rules with regard to certain information technology, publishing new rules and guidance. There are at least two relevant areas where FDA is clarifying rules of interest to those involved in EHRs.

  1. On February 14, 2011, FDA published a final rule on Medical Device Data Systems (MDDS, as it has become affectionately known) that places such systems in class I of the FDA's three-tiered medical device regulatory scheme. That means MDDS are not required to be approved by FDA, but must be manufactured under a quality system that meets FDA requirements. The key to this discussion is that MDDS includes those software programs that acquire, transfer, store, convert or display data from medical devices. As reflected in the discussion of the technology trends, some EHRs would like to add functionality that allows for the automatic transfer and storage of data from medical devices. If that happens, that functionality may transform the traditional EHRs into FDA-regulated MDDS.
  2. On September 13, 2011, FDA held a hearing on so-called standalone clinical decision support software. Over the years, FDA has been regulating many software packages that perform decision support functions, but the precise rules have never been clear. Earlier this summer, in the widely read FDA proposed guidance on medical mobile apps, FDA mentioned its plans to develop new guidance on decision support software. At the hearing, FDA staffer Kristen Meier, PhD, offered a definition of clinical decision support software as software that "uses an individual's information from various sources (electronically or manually entered)", "converts this information into new information that is intended to support a clinical decision" whether in "a mobile application, web-based service or desktop application." That's a pretty big deal, especially for EHRs that aid in the individual diagnosis of patients beyond very basic retrieval of health records. That functionality potentially converts traditional EHRs into FDA-regulated decision support software.

The Squeeze

Those regulatory trends, together with the technology trends, means there is less and less substance to the EHR exemption from FDA regulation. I'm a visual person, so here's my attempt to summarize it in a picture.

>

As the FDA categories for MDDS and decision support software expand, and as EHRs take on functionality to transfer and storage medical device data and for diagnostic support, the traditional EHR exemption will get squeezed. In that case, we either need to start trying to reverse one or more of those trends, or we need to start planning for a future generation of EHRs where FDA is much more involved. To help start that discussion, I'd like to look at each of these issues a bit more closely.

Baseline Understanding

If you've been reading my posts on this blog, you actually already have a pretty complete understanding of the basic legal and regulatory framework that applies here. But in case you've forgotten any of it, I'll remind you of some important developments.

  • FDA says it has legal authority over EHRs. In my post on developments in Washington,1 I described in considerable detail some testimony offered by the chief device regulator in which he bluntly declares jurisdiction over EHRs. In doing so, he was only staking out his potential territory; he did not take the next step and lay out any specific regulatory requirements that such software must meet. Importantly, though, as you remember, the device chief was very focused on the reports of injury and death associated with malfunctioning EHRs.
  • FDA has authority over the manufacturers of EHRs, whether those manufactures are traditional vendors or traditional users such as hospitals that drift over into design and production of the software. I explained the actual legal basis for FDA to regulate hospitals and others that decide to make software in my post on healthcare providers,2 and since that time FDA has reaffirmed its right to regulate hospitals in the preamble to the final MDDS rule. In that notice, FDA explained that a purchaser of MDDS system could become a manufacturer if the purchaser "makes any modifications to the MDDS that are outside the parameters of the original manufacturer's specifications for the device." Further, the agency explained, if "a third-party company or hospital develops its own software protocols or interfaces that have an intended use consistent with an MDDS" or "create a system for multiple components of devices and uses it clinically for functions covered by the MDDS classification", it could also be a manufacturer.
  • There are some political pressures to regulate EHRs. As explained in my post on developments in Washington3 last spring, Sen. Charles Grassley seemed to be actively investigating the quality of EHRs, with an eye toward determining whether they were hurting people.
  • FDA has said on a couple of occasions, though, that they will not regulate traditional EHRs, although as I point out above traditional EHRs may be a dying breed. FDA made that declaration in the preamble to the final MDDS in February, and said it again in the draft guidance on mobile medical apps. That means it's terribly important to understand what software remains in that traditional EHR category, and what has now instead become part of the regulated MDDS or decision support software categories.

MDDS Category

I am not going to write much about this particular category, simply because so much has been written over the last six months that you're probably sick of hearing about it. Suffice it to say, given the definition of MDDS as including any software that is engaged in the transfer, storage, conversion or display of data collected from a medical device, the temptation is strong on the part of EHR manufactures to add that functionality into their software. With the IT technology commonly available, it's actually pretty easy for EHR manufactures to add that functionality. Further, from a customer standpoint, that functionality is highly valuable. So were it not for the consequences of FDA regulation, you would expect EHR manufactures to readily add that capability.

There is one wrinkle in this. With the publication of the recent draft guidance document on mobile medical apps, we are starting to see FDA move away from a focus on the manner in which medical device data is added to a software program. It used to be for many years that manually inputting data was a pretty solid defense against FDA jurisdiction. But in the draft guidance, FDA says "Mobile medical apps ... that analyze or interpret data (electronically collected or manually entered) from another medical device are considered an accessory to that medical device." Dr. Meier made much the same point in her presentation on clinical decision support software. In discussions with FDA, it seems that they're moving toward the principle of simply assessing risk where the manner of data input is only one factor among many considered. Times are changing.

Decision Support Software

Above I gave you the definition of decision support software contained in a presentation last week at the FDA hearing on clinical decision support software. Let's tease that definition out just a bit more. Dr. Meier was very clear that the data could be from virtually any source, and the fact that it was entered manually by a person made no difference. Further, the data could be simply environmental data such as pollen count ambient temperature and so forth, as well as demographic data. So the data sources are really wide open in FDA's mind. The conversion, according to Dr. Meier, could be by analysis using algorithms (either fixed or iterative), a formula, database lookups or comparisons or rules and associations. The bottom line is: does the software produce actionable information? That's pretty broad.

Beyond that definition, John Murray, the leading software expert in the FDA's device enforcement office, has given some practical examples in educational presentations. In that presentation, examples of decision support software include:

  • Treatment recommendation software
  • Stent selection software
  • Treatment support software for oncology
  • Online calculator software intended for use in the diagnosis or treatment of disease

Other examples offered by Dr. Meier included an Apgar score calculator, and software that trends for taking the next clinical action, determines radiation therapy or identifies anomalies in medical images.

The difficulty in nailing down this particular category is that it seems to cover such an incredibly broad range of functionalities. At the low end, FDA would seem to declare software that merely facilitates the collection and presentation of accepted clinical decision-making algorithms as potentially decision support software. At the high-end, the category would seem to include incredibly complex and sophisticated artificial intelligence that produces judgments that are very difficult to reverse engineer. At the hearing, the audience was all abuzz about the IBM Watson computer being engaged by health insurer Wellpoint to assist with diagnosis. Presumably, in its upcoming guidance, FDA plans to stratify the risk of such different systems for regulatory purposes, and make clear what types of clinical decision support software functions don't merit active FDA regulation.

Understanding FDA regulation of decision support software requires more than just understanding its functionality. We must also understand specifically how it is used. A piece of decision support software can find itself FDA-regulated through one of two avenues: (1) as an accessory to a medical device or (2) as a standalone piece of software.

Accessory software

For EHRs that play the decision support function, perhaps the greatest risk of FDA regulation comes through the accessory avenue. More and more vendors, including medical device manufacturers themselves, are producing software that functions like an EHR by providing decision support for specific medical devices. According to background materials FDA produced to facilitate a 1996 software policy workshop, FDA basically looks at two questions to determine whether a piece of software has become an accessory to a medical device:

  1. Is the software labeled or promoted or otherwise intended for use with a classified medical device?
  2. Does the software by design directly interface with a medical device for transfer of data to or from the device?

FDA suggests that if the answer to either of those questions is yes, the software is likely an accessory to the medical device. If that is the case, FDA regulates the software to the same extent as the parent medical device.

For example, when companies develop software applications for the management of diabetes that are promoted as compatible with a blood glucose meter, they probably have made the software an accessory to the meter and therefore regulated as a class II medical device, regardless of whether the software company is also the maker of the blood glucose meter.

Standalone software

Some folks in the IT industry are surprised to learn that FDA for decades has regulated certain software programs that do nothing more than run on a common PC, without in any way, shape or form directly interacting with a regulated medical device. Part of that surprise is certainly understandable: FDA has not been clear in its public guidance regarding the scope of its authority over standalone software.

At the risk of oversimplification, I break down the FDA's historical regulatory approach over standalone decision support software into three time periods. To understand how I characterize the dates, it's important to understand that FDA often likes to test drive new policy before letting the rest of us in on it. So policy changes often actually precede formal publication of draft guidance.

  1. The period from a few years before until a few years after 1989. During this period, the agency's approach to decision support software was found in a draft 1989 policy that explained: "Manufacturers of computer products (e.g., "expert" or "knowledge based" systems, artificial intelligence and other types of decision support systems) that are intended to involve competent human intervention before any impact on human health occurs, (e.g., where clinical judgment and experience can be used to check and interpret a system's output) will be exempt from Registration, Listing, Premarket Notification, and compliance with the MDR and GMP regulations." That approach was actually pretty simple, in that it put primary responsibility on doctors and other healthcare professionals to make their own decisions.
  2. The period from a few years before until a few years after 1996. Although the prior approach was simple, FDA grew not to like it. Among other things, FDA felt that companies were misinterpreting the position and concluding that software was exempt when in actuality it served as an accessory to a regulated medical device. Remember the accessory rule? If the software is an accessory, it is regulated regardless of any competent human intervention. Given what the agency felt was abuse, the agency started to move away from the concept of competent human intervention. In its 1996 workshop study guide, the agency explained:

    "The issue of what constitutes competent human intervention has also become increasingly complex and difficult to administer. For the relatively few standalone software devices that are not accessories, it is sometimes difficult to establish that there is competent human intervention. For software which simply automates a complex calculation, competent human intervention can be achieved by providing the algorithm to the user to allow for manual verification or challenge of the software results. Expert software which assists in disease diagnosis can provide decision criteria, Bayesian decision trees, or text references by which the decision support software reaches its recommendations. In general, to permit competent human intervention, the software decision process must be completely clear to the user, with a reasonable opportunity for challenging the results. There must also be adequate time available for reflection on the results. For example, surgery or intensive care may not be settings wherein there is adequate time to challenge the results of decision support software. Moreover, medical software is becoming increasingly complex, such that it is frequently questionable whether a practitioner can reasonably exercise competent human intervention. For example, neural networks provide no simple algorithms that can be examined and easily understood by the user. These and other factors are reasons to re-examine FDA's criteria for exemption of software from active regulation."
  3. Today. Currently, honestly, no one knows what the agency's rules are for decision support software. Indeed, I think it's fair to say that not even FDA knows, in the sense that the agency is a collection of individuals who haven't all yet come to consensus on what they should do. In a prior post on software,4 I laid out what I believe to be the seven risk factors for FDA enforcement based on my observations of the agency over the last 25 years. I also laid out eight suggestions for how the software industry could reduce the risk of agency enforcement.5 Importantly, Dr. Meier also laid out her own factors that influence her thinking about whether a piece of standalone software should be regulated. Her for considerations include: (a) the extent of a user's reliance on the software (presumably meaning that greater reliance increases the risk) (b) pervasiveness of the use of the software (c) general acceptance of the underlying methodology (d) and the complexity of the clinical decision-making. There was also a good bit of discussion around the transparency of the software, whether it was a black box that simply needed to be trusted or whether it was so transparent that the user could easily validate the output. In the end, though, these are all simply comments by individuals, and we will need to wait to get clarity from FDA.

In the preamble to its final MDDS rule, FDA talked about decision support software such as APACHE and Apgar scoring programs. The preamble also discussed CPOE systems that order tests, medications or procedures. Unfortunately, while FDA indicated that they were not covered by the MDDS rule, the agency offered no insight into whether they were covered by FDA regulation under any other classification.

On the approval side, companies continue to get products cleared by the agency as standalone clinical decision support systems, but knowing when such clearance or approval is required is the tough part.

The Concept of Modularity

The risk that MDDS and decision support functionality will be added to traditional EHRs raises the stakes on FDA's need to adopt recognized principles of software modularity. While I'm not an expert on it, let me explain at least at a high level what I mean by this term. The mHealth Regulatory Coalition is preparing a proposal for FDA to use when deciding when, for regulatory classification purposes, the agency can compartmentalize software packages into different modules that have varying regulatory classifications associated with them. As an intellectual foundation for its proposal, the coalition is borrowing a regulatory approach developed by the Federal Aviation Administration which regulates all manner of software used in a cockpit.

As already noted, FDA medical device regulation is built on the bedrock principle that medical devices should be stratified into three different classes depending on risk, and the regulatory requirements for a given device should be proportionate to the level of risk. If a given piece of software has multiple functions, and some of those functions should be placed in a higher class than others, right now the whole software package would get regulated at the highest classification. That's regulatory overkill, because anytime you want to update any particular elements of the software package, you need to follow the most burdensome regulatory requirements. Under modularization, FDA could be assured that the individual modules can be modified without significant risk of impacting the other modules, thus allowing for a much more tailored regulatory approach. All we have to do now is convince FDA of that.

Conclusion

FDA's plans to develop decision support software guidance portend a major change that could dramatically impact EHRs, and deserve attention. Perhaps even more so than MDDS, the future direction of FDA policy on decision support software will directly impact which future EHRs get regulated. It would appear that FDA is already in the process of developing this decision support software guidance, with an expected publication date perhaps a few months from now, but no one can really predict it. Rather than passively wait for FDA to decide what to do, if these issues are important for your business, you might want to speak up now.

I'd like to thank Sandy Weininger of FDA and Tim Gee of Medical Connectivity for their helpful comments on a draft of this post. But any mistakes you find are all my own.

Footnotes

1. Washington signals possible FDA regulation of mHealth

2. Will be FDA regulate them health care providers?

3. Washington signals possible FDA regulation of mHealth

4. how to get FDA to clear a mobile health app

5. will be FDA regulate and health providers?

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.