By Shari Medina, MD

This month, the FDA issued long-awaited guidelines on the agency’s implementation of the 21st Century Cures Act in regards to Clinical Decision Support and the FDA’s intent to exercise enforcement discretion for many types of patient-facing software, mobile applications, and software which have not obtained ONC certification.

The FDA is soliciting public comment on two draft documents, “Clinical and Patient Decision Support Software” and “Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act.”  The FDA also issued the final version of  “Software as a Medical Device: Clinical Evaluation,” a collaborative effort from the International Medical Device Regulators Forum which the FDA has adopted as its risk-based framework for future regulatory initiatives.

Said FDA Commissioner Scott Gottlieb, “We know that consumers and health care providers are increasingly embracing digital health technologies to inform everyday decisions… We believe the FDA must, whenever possible, encourage the development of tools that can help people be more informed about their health.  And we recognize that our regulations play a crucial role in the efficient development of such technologies. Therefore, our approach to regulating these novel, swiftly evolving products must foster, not inhibit, innovation.”

Clinical and Patient Decision Support Software

Of great interest to EHR developers are the draft guidelines on Clinical and Patient Decision Support Software (CDS).  While the 13-page document does a good job of explaining the language in the 21st Century Cures Act that requires FDA to issue this guidance, the actual guidance falls short in providing clarity on the agency’s thinking on evolving technologies, such as machine learning and artificial intelligence.

The FDA has appropriately deemed as non-regulated all CDS that is based on published clinical guidelines and generally accepted clinical practice. However, there is potentially problematic ambiguity in establishing what constitutes “generally accepted clinical practice.”  The examples of “CDS Functions that are Not Devices” are helpful but ultimately result in more questions than answers. The examples of “CDS Functions that Remain Devices” are almost exclusively imaging- and/or hardware-based; the only purely software-based examples rely solely on transparency of the algorithm to determine regulatory status, rather than risk to the patient.

All of the device examples given are intuitive and have high-risk patient safety implications, leading developers to wonder: What is the FDA position on regulating software which may lack transparency of the underlying algorithm, but which has minimal patient safety risk?

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

The FDA’s intent to no longer designate Medical Device Data System (MDDS), medical image storage software and medical image communications software as regulated medical devices is consistent with the statutory language of 21st Century Cures and will be welcomed by the healthcare industry.

The proposed Changes to Existing Medical Software Policies further clarifies that the FDA intends to focus on regulation of “software functions intended to generate alarms or alerts or prioritize multi-patient displays if they are intended to alert a caregiver to take an immediate clinical action.”  The agency also proposes that “software functions that analyze medical device data in order to provide a notification or flag (e.g., that a parameter is out of range) are not excluded from the definition of device under subsection (D).”

This could, theoretically, include software which displays a “critical” lab value indicator, “severely out of range” vital sign notification, or sorts a patient task list based on their clinical risk according to published risk scoring methods – functions included in most EHRs which historically have enjoyed enforcement discretion.

Overall, the proposals in Changes to Existing Medical Software Policies result in more questions than answers, such as:

• If a generally accepted risk calculation is performed (which would be excluded under the Clinical and Patient Decision Support Software document) that might generate an alert for immediate clinical action one percent of the time, is the entire CDS function now regulated?  
• Is the entire CDS module regulated, or only the particular ‘rule’ or ‘content’?  
• What is the FDA’s position on CDS software tools provided by developers to healthcare clients who build their own content, which may generate “immediate clinical action” alerts?
• Does the choice by a client to build a CDS rule meeting the definition obligate the developer to FDA regulatory oversight?

While it is doubtful this was the intent of the FDA, the language in the draft Changes to Existing Medical Software Policies does not provide the necessary clarity.

Another item, which was not addressed in the proposed documents published this month and which dovetails with the preceding questions, is of particular interest to EHR developers. What is the FDA’s plan for software that contains a combination of regulated and non-regulated features? The FDA indicated its proposed approach will be issued in a future document.

Overall, EHRA members are glad to see the FDA moving forward to address the need for federal guidance on the types of health IT over which it plans to exercise regulatory oversight, and recognizing that low-risk technology and applications do not require federal regulations.

EHRA will be formally submitting comments on the draft proposals with the goal of decreasing the ambiguity of the guidelines in light of the 21st Century Cures Act. We look forward to future innovations to support the care and well-being of patients.

Shari Medina, MD, is vice chair of the EHRA Patient Safety Workgroup and Regulatory Affairs Specialist at Harris Healthcare.