A look at what’s new in two recent legislative efforts to define FDA oversight of software.

Bradley Merrill Thompson

MEDTECH Act

The Medical Electronic Data Technology Enhancement for Consumers’ Health (MEDTECH) Act took a big step forward on April 27. In reintroducing the bill, Senators Michael Bennet (D–CO) and Orrin Hatch (R–UT) significantly improved the language.

The MEDTECH Act is intended to implement the recommendations of the Food and Drug Administration Safety Innovation Act Workgroup, which Senators Hatch and Bennet requested in the 2012 FDASIA legislation. That working group, which took the form of a federal advisory committee comprised of patients, consumers, health care providers, startup companies, health plans or other third-party payers, venture capital investors, and information technology vendors, spent the summer of 2013 developing the recommendations that led to this legislation.

Now you might think I’m suggesting that the bill became more industry friendly, since I represent industry and I am praising the changes. But actually the bill became a bit less industry friendly, not more. I am pleased not because the changes help industry, but rather because I recognize the changes reflect input from FDA and other stakeholders.

As much as we all like to complain about Congress and the legislation it produces, for any legislation to get serious consideration it needs to be the product of input from all stakeholders, reflecting sensible compromise. So revising the language based on input from FDA makes it far more likely that the MEDTECH Act will receive the broad support it needs for enactment.

The new language is certainly more complicated, and frankly not nearly as much fun to read. I’m guessing with the help of a lot of lawyers, the sponsors have tightened up each section greatly to avoid unintended consequences. That's good. If you read the bill yourself, you will see that in several places the language starts with an exception to the exception. Double negatives make my head hurt. You have to read it carefully to understand whether it’s talking about something that is or is not regulated.

Let’s look at some of the changes:

1.The sponsors expanded the bill a bit to expressly include software used for things like business analytics and communication. FDA never intended to regulate those things, but it certainly doesn't hurt to explicitly exclude them.

2.The sponsors added a new section for wellness software. They were probably trying to codify FDA’s January draft guidance on wellness. The legislative language is pretty cryptic, so the draft guidance will remain important.

3.Throughout, I suppose at the instigation of FDA, the drafters have now carefully left under FDA regulation most software having to do with medical image data. That makes sense. I think most people agree that stuff is higher risk.

4.The section on electronic health records is more precisely stated, and I think it's fine. A nice change is that no longer do EHR developers have to use some ill-defined validation of the kind expected by FDA in a premarket submission, but rather they must comply with the Office of the National Coordinator for Health Information Technology (ONC’s) voluntary certification process. That seems much more sensible and clear.

5.The laboratory information system section is tightened up to allow for the deregulation of software used to generate reports or move laboratory data around, but does not exempt from FDA regulation software used to interpret or analyze clinical laboratory data. That has been a sensitive topic with FDA.

6.In my opinion, one of the most important sections of the bill addresses clinical decision support software (CDS). And while the language is certainly tightened up, I think the bill does a nice job of striking the balance where software that a) analyzes medical information b) to help a doctor, but c) presents the information in a way that does not force the doctor to rely on the software, would be unregulated by FDA. That’s the right approach.

7.There is a new section that would seem to grant FDA the authority to assure that electronic health records, CDS, and lab information systems are “consistent with appropriate quality principles and standards for software development and validation.” It's cryptic, and I'm not entirely sure what they have in mind. I understand the desire to have some basic standards that apply to these categories of software. Even so, I think we’re going to need to know a little bit more about what they have in mind. You will notice that the language does not, for example, specifically require a FDA 21 CFR Part 820 quality system. So what are “appropriate quality principles and standards for software development and validation”?

8.The legislation includes a new section asking FDA to classify accessories separately from the devices they accessorize. I think that's hugely positive. Of course it will take FDA resources in order to be able to do that, but I assume that's a second part to the conversation.

SOFTWARE Act

On April 29, 2015, just 2 days after the MEDTECH Act was reintroduced, a group of Energy and Commerce Committee leaders released a new discussion draft of the 21st Century Cures legislation. That legislation includes the Sensible Oversight for Technology which Advances Regulatory Efficiency (SOFTWARE) Act, covering much of the same ground as the MEDTECH Act.

Like the MEDTECH Act, it appears that the sponsors of the legislation have been working hard with various stakeholders, including those with qualms about deregulating health-related software. As I observed earlier, I appreciate that because any legislation needs to be tightened up to ensure that it does not lead to unintended consequences. In the end, that’s healthy for the legislation.

My concern is that some of the new language introduced in this draft is difficult to interpret and may accidentally introduce more uncertainty into the process. For example, in the January 2015 draft of the SOFTWARE Act, CDS would not be regulated so long as the software offered “the opportunity for additional interpretation or an independent confirmation” of the recommendations the software makes. That seemed pretty clear and easy to interpret. Software developers would be called upon to determine whether their software is FDA regulated or not.

In the new draft of the SOFTWARE Act, now FDA is given discretion to determine whether a particular category of CDS would pose significant risk to patient safety based on a whole litany of factors including whether a medical professional can “review the means by which the analysis was performed” and whether there exists “a means to independently evaluate and verify the accuracy of the analysis.” Those are two among six factors that FDA gets to assess in its discretion, before deciding whether to regulate a given category of CDS. The new process gives FDA quite a bit of latitude to decide what to regulate. The original purpose of this legislation, however, was to more clearly define the dividing line between regulated and unregulated software. I fear we are moving away from that objective.

Personally, I’m very pleased that the sponsors of the SOFTWARE Act have obviously been working with a very broad group of stakeholders to get input on this legislation. At the same time, I would like to see the sponsors adopt language that more clearly differentiates regulated from unregulated CDS, rather than simply kicking the ball back to FDA.

Bradley Merrill Thompson, a shareholder in the Washington DC law firm of Epstein Becker & Green, represents the CDS Coalition. Mr. Thompson served as cochair of the Regulations Subgroup of the FDASIA Working Group, whose recommendations formed the basis for the MEDTECH Act. The opinions expressed in this post are Mr. Thompson’s alone.

[Image courtesy of STUART MILES/FREEDIGITALPHOTOS.NET]