FDA releases revised draft guidance on CDS software, final guidelines on ‘device’ definitions for software such as wellness apps

This morning the FDA released two guidance documents relating to the regulation of various digital health software devices.

The first is a draft guidance outlining categories of clinical decision support (CDS) products that would or would not require direct regulatory oversight from the agency. This is an update to a CDS draft guidance released in 2017, with the noteworthy addition of a risk-based categorization approach for determining enforcement over these tools.

“The agency received feedback from many stakeholders advising us on improvements that could be made to better clarify the agency’s oversight of CDS products,” Principal Deputy Commissioner Dr. Amy Abernethy wrote in a statement announcing the new documentation. “We heard you and worked to incorporate that important feedback.”

The second is a final guidance that brings several existing medical software policies from the agency into accordance with provisions outlined in 2016’s 21st Century Cures Act. In particular, the document describes certain types of software products that will no longer fall within the agency’s definition of a medical device. These include software for health care facility administration, electronic paper records and, notably for digital health, apps designed to encourage health and wellness.

“We’re making clear that certain digital health technologies — such as mobile apps that are intended only for maintaining or encouraging a healthy lifestyle — generally fall outside the scope of the FDA’s regulation,” Abernethy wrote. “Such technologies tend to pose a low risk to patients, but can provide great value to consumers and the healthcare system.”

“Clinical Decision Support Software”

CDS software is broadly described by the FDA and ONC as software products that provide professionals and patients “with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care.” When the agency took its first crack at regulating these tools two years ago, it did so on the basis of human involvement — in short, whether or not a physician is capable of independently verifying the software’s decision-making process.

This approach caught some heat from the industry, which generally pushed for an approach where the potential risk to a patient would determine whether the CDS software would require regulatory oversight.

Bradley Merrill Thompson, a member of the firm at Epstein Becker & Green and the head of an industry group called the Clinical Decision Support Coalition, said that the new guidance’s decision to adopt this strategy is an unexpected but welcome shift from the FDA’s prior stance.

“While naturally I hoped the agency would respond positively to our concerns, well over a year ago in a meeting with FDA it seemed most unlikely they would. Orally the agency flat out rejected our request,” Thompson told MobiHealthNews today in an email statement. “But times have apparently changed, and I am grateful to FDA for reconsidering its position. And the agency should be congratulated for keeping an open mind.” 

Alongside a breakdown of enforcement criteria, the documentation provides a broad variety of hypothetical CDS products that would or would not fall under its purview (based on the agency’s current understanding of risk), as well example-specific explanations.

For example, software that identifies patients with signs of opioid addiction based on patient-specific data and patterns, but does not explain exactly how, would be considered an oversight-worthy device CDS product, in part because it is “intended to inform clinical management for a critical situation or condition.” Meanwhile, software for providers that analyzes and surfaces ideal over-the-counter drugs for seasonal allergies, while again not explaining its inputs, would not fall under mandatory enforcement “because it provides treatment options for a non-serious situation or condition.”

“Since the potential for patient harm is significant, FDA regulation plays an important role in evaluating the software’s safety and effectiveness,” the agency wrote. “We believe our proposed approach for regulating CDS not only fulfills the provisions of the Cures Act, but also strikes the right balance between ensuring patient safety and promoting innovation by clarifying which products would be the focus of FDA’s oversight and which would not.”

Thompson initially described the guidance as a small, but important step forward for the agency, but still had some reservations in the FDA’s application of its risk-based approach. For starters, he wished that the agency did not limit its enforcement discretion to “software that provides information that merely informs clinical management of a non-serious disease or condition,” and instead included two other slightly higher risk subcategories suggested by his organization: “software that provides information to drive clinical management of a non-serious disease or condition” and “software that provides information that merely informs clinical management of a serious disease or condition.”

“The first of those especially is disappointing, because we are talking about nonserious diseases or conditions,” he wrote. “FDA wants to review CDS used to support recommendations to healthcare professionals on non-serious disease or conditions. It makes no sense to impose FDA regulatory obstacles on those categories of software.”

However, more alarming to Thompson was what he views as an ambiguous and “legally wrong” delineation between software intended “to guide” clinical management versus CDS tools that according to the document are “simply supporting or providing a recommendation about prevention, diagnosis or treatment of a disease or condition.” While the draft bases its distinction by referencing language in the 21st Century Cures Act, Thompson said that the definitions are far too similar intertwined to place into separate regulatory buckets.

Essentially FDA is saying that ‘to guide’ clinical decision-making — which is the definition of ‘driving clinical management’ — is somehow fundamentally different than to ‘provide recommendations’ for clinical decision-making,” he wrote in a follow-up email. “That’s a distinction without substance. ‘Guiding’ clinical decision-making and ‘providing recommendations’ for clinical decision-making are the same. FDA is way in left field here, and they are trying to keep software companies from escaping FDA regulation by being transparent. This will not stand legal scrutiny. And in this sense, the new draft guidance is much worse than the old one.”

As a draft guidance, this CDS documentation will again be up for comment until December 26, 2019.

“Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act”

Today’s second guidance acts as the final word on another less controversial draft document released in 2017, one which outlined software categories that the agency would not consider to be a medical device and, therefore, not be subject to mandatory oversight. These updates are based on the definitions outlined by the 2016 law, and as such will amend certain policies laid out under four other previously issued FDA final guidances on mobile medical applications; low-risk devices for general wellness; off-the-shelf medical device software; and medical device data systems, medical image storage and medical image communications devices.

By and large, the new final guidance describes four broad categories of software products no longer considered medical devices, as well as examples of each. These include:

Software function intended for maintaining or encouraging a healthy lifestyle — this category describes non-hardware digital products focused on healthy behavior and wellness, such as workout logging apps, relaxation apps and food-logging apps.

Of note, the guidance describes such products under two sub-categories: those focused on general wellness for overall health; and those focused on general wellness to reduce risk or impact for chronic diseases, for which general healthy lifestyles are known to help. For the latter, the document notes that software related diagnosis, cure, mitigation, prevention or treatment for these conditions is still a device.

Software function intended for administrative support of a health care facility — these would consist of products handling financial records, appointment schedules, business analytics, information about patient populations, admissions, practice management, laboratory workflow, health benefit eligibility determination and other administrative tasks.

Software function intended to serve as electronic patient records — software functions in this category must be created or handled by health care professionals, fall under ONC IT certification and not be intended for interpretation or analysis of patient records. This would include software designed to transfer, store, convert or display electronic records equivalent to those found on a paper medical chart, and applies to EHR systems as well as mobile apps designed for patients to track their personal health information.

Software function intended for transferring, storing, converting formats, displaying data and results — this applies to medical device data systems, medical image storage devices, and medical image communications devices.

“Regulatory uncertainty stifles innovation either by discouraging innovators from entering a field where the regulatory uncertainty creates an unnecessary barrier to entry or by delaying commercialization as innovators seek clarification regarding the regulatory status of their software,” Kyle Y. Faget, special counsel and business lawyer with Foley & Lardner LLP, told MobiHealthNews in an email. “Now that these guidances are available and in final form, digital health developers will have to get to work operationalizing the principles articulated in the guidances.

MobiHealthNews has reached out to additional regulatory experts for comment on both guidances, and will update this story with their response.

 

Source: Read Full Article