Posted: 02 Jan 2017 04:10 PM PST
By Jeffrey K. Shapiro & Jennifer D. Newberger –
Our firm has previously posted some summaries of the 21st Century Cures Act (Cures Act), which the President signed into law on December 13, 2016 (Public Law No. 114-255). (Those summaries are available here, here, and here.)
This post focuses on only one section of the new law: Section 3060, “Clarifying Medical Software Regulation.” We covered the basics of Section 3060 in our prior summary, but thought it would be worthwhile to delve a little further in a separate post.
Section 3060 amends the Food, Drug, and Cosmetic Act (FDCA) to exclude from the definition of a “device” software intended:
The fourth exclusion provided in the Cures Act is software intended:
The last type of software excluded from the definition of a device is software intended:
The application of the definition in Category E will not always be self‑evident. There are questions about what it means for a health care professional to “independently review” the basis for software recommendations. Surely it does not require that the health care professional understand how the software reached a recommendation at the level of software coding and algorithms. It would be more reasonable to infer that the software must provide a sufficient level of transparency to allow a health care professional to discern the clinical basis of a recommendation. How exactly that must be accomplished will have to be worked out by FDA in guidance and administration and implementation of the statute.
In many cases, it may be sufficient for the software to provide links to the underlying clinical literature or guidelines. But what if the software uses “big data” from hospital records to derive recommendations for a patient? What information must the health care professional be given? And may the recommendations have confidence levels attached, if they are worked out with complicated probabilistic analysis? If so, what must be said about how the confidence levels are derived or should be used?
Another question is how the intended use environment factors in. For example, healthcare professionals have different levels of training and expertise. One of the benefits of CDSS is to encode the expertise of the best trained and most experienced doctors and make it available to other doctors. Yet, the latter are likely to rely more heavily on the software recommendations than would the best trained and most experienced doctors. Does that bring the CDSS under FDA regulation? FDA has long been prohibited under the statute from restricting devices to particular classes of health care practitioners based upon training or experience (see FDCA § 520(e)). However, the question here is whether the software is or is not to be regulated as a medical device. Therefore, it is not so clear that FDA may not make distinctions among the health care practitioners for whom the CDSS is intended when determining if it is regulated.
There is one more aspect of Category E we have not discussed. The clause that begins “unless the function is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system” designates software products that are excluded from Category E and will continue to be fully FDA regulated as medical devices.
Had this clause not been included, one could argue that computer‑assisted detection or diagnostic (CAD) devices that analyze image data (e.g., identifying suspicious lesions in a CT scan) and in vitro diagnostic devices are a type of CDSS. Nonetheless, FDA has a long history of regulating these types of devices. This language ensures that FDA will continue to do so.
Section 3060 also gives FDA authority to bring some excluded CDSS software back under its jurisdiction. FDA may bring software described in Categories C, D, or E, above, back under its jurisdiction if it makes certain findings regarding: (1) the likelihood and severity of patient harm if the software does not perform as intended, (2) the extent to which the software is intended to support the clinical judgment of a health care professional, (3) whether there is a reasonable opportunity for a health care professional to review the basis of the information or treatment recommendation, and (4) the intended user and use environment.
For FDA to determine that software excluded from the device definition should in fact be regulated, FDA must publish a notification and proposed order in the Federal Register, and must include its rationale and evidence on which it is relying for the conclusion that such software should be regulated. The notice must allow for at least 30 days of public comment before issuing a final order or withdrawing the proposed order.
The Cures Act requires the Secretary of Health and Human Services to publish a report, within two years of enactment of the Cures Act and every two years thereafter, that includes input from industry, consumers, patients, health plans, and other “stakeholders with relevant expertise.” The report must include information about any risks and benefits associated with the software functions provided in the Cures Act, and “summarizes findings regarding the impact of such software functions on patient safety, including best practices to promote safety, education, and competency related to such function.” Time will tell how this information may be used to further modify FDA’s authority over software.
For now, the software exclusions in Section 3060 of the Cures Act are welcome news to an industry that has been struggling with the question of whether its products are subject to FDA regulation, particularly in the area of CDSS. The new clarity will allow innovative software developers to move forward with greater confidence as to whether a product will or will not be regulated by FDA as a medical device.
Our firm has previously posted some summaries of the 21st Century Cures Act (Cures Act), which the President signed into law on December 13, 2016 (Public Law No. 114-255). (Those summaries are available here, here, and here.)
This post focuses on only one section of the new law: Section 3060, “Clarifying Medical Software Regulation.” We covered the basics of Section 3060 in our prior summary, but thought it would be worthwhile to delve a little further in a separate post.
Section 3060 amends the Food, Drug, and Cosmetic Act (FDCA) to exclude from the definition of a “device” software intended:
(A) “for administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow;”The exclusion of the above classes of software from the FDC Act should not be controversial. Category A are obviously not medical devices. Categories B and C are arguable, but FDA has said already that, even if these types of software fall within the definition of a medical device, as a matter of agency enforcement discretion, FDA does not intend to regulate them. Now Congress has taken them off the table altogether.
(B) “for maintaining or encouraging a health lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition;” and
(C) “to serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart, so long as” such records “were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals” and the software “is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.”
The fourth exclusion provided in the Cures Act is software intended:
(D) “for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device,” unless the software “is intended to interpret or analyze clinical laboratory test or other device data, results, and findings.”Category D above appears to include products meeting the definition of either a medical device data system (MDDS) or a laboratory information system (LIS). FDA has previously announced it is exercising enforcement discretion not to regulate MMDS; this provision codifies that position. FDA currently regulates LIS as 510(k)‑exempt Class I devices under 21 C.F.R. § 862.2100, product code NVV. An LIS is “intended to store, retrieve, and process laboratory data.” FDA has continued to apply the quality system regulation (QSR) to these devices. Under the exclusion above, LIS products will now not be subject to the QSR or any other regulatory requirements at all.
The last type of software excluded from the definition of a device is software intended:
(E) unless the function is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system, for the purpose of –The software described in the above provision is commonly known as “clinical decision support software” (CDSS). It is well known that FDA has been mulling CDSS guidance for the past few years. However, it has never issued draft guidance. The closest FDA has come is the Mobile Medical Apps guidance (Feb. 2015), which classifies mobile apps as medical devices if they perform “patient‑specific analysis and provid[e] patient-specific diagnosis, or treatment recommendations.” This statement suggests that FDA intended to regulate CDSS. However, it is possible that the CDSS guidance, had it been issued, would have walked that position back to some extent. In any event, Section 3060 resolves the status of CDSS more definitively than FDA guidance could have, by excluding CDSS from the definition of a medical device altogether.
(i) displaying, analyzing, or printing medical information about a patient or other medical information (such as peer-reviewed clinical studies and clinical practice guidelines);(ii) supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and(iii) enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.
The application of the definition in Category E will not always be self‑evident. There are questions about what it means for a health care professional to “independently review” the basis for software recommendations. Surely it does not require that the health care professional understand how the software reached a recommendation at the level of software coding and algorithms. It would be more reasonable to infer that the software must provide a sufficient level of transparency to allow a health care professional to discern the clinical basis of a recommendation. How exactly that must be accomplished will have to be worked out by FDA in guidance and administration and implementation of the statute.
In many cases, it may be sufficient for the software to provide links to the underlying clinical literature or guidelines. But what if the software uses “big data” from hospital records to derive recommendations for a patient? What information must the health care professional be given? And may the recommendations have confidence levels attached, if they are worked out with complicated probabilistic analysis? If so, what must be said about how the confidence levels are derived or should be used?
Another question is how the intended use environment factors in. For example, healthcare professionals have different levels of training and expertise. One of the benefits of CDSS is to encode the expertise of the best trained and most experienced doctors and make it available to other doctors. Yet, the latter are likely to rely more heavily on the software recommendations than would the best trained and most experienced doctors. Does that bring the CDSS under FDA regulation? FDA has long been prohibited under the statute from restricting devices to particular classes of health care practitioners based upon training or experience (see FDCA § 520(e)). However, the question here is whether the software is or is not to be regulated as a medical device. Therefore, it is not so clear that FDA may not make distinctions among the health care practitioners for whom the CDSS is intended when determining if it is regulated.
There is one more aspect of Category E we have not discussed. The clause that begins “unless the function is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system” designates software products that are excluded from Category E and will continue to be fully FDA regulated as medical devices.
Had this clause not been included, one could argue that computer‑assisted detection or diagnostic (CAD) devices that analyze image data (e.g., identifying suspicious lesions in a CT scan) and in vitro diagnostic devices are a type of CDSS. Nonetheless, FDA has a long history of regulating these types of devices. This language ensures that FDA will continue to do so.
Section 3060 also gives FDA authority to bring some excluded CDSS software back under its jurisdiction. FDA may bring software described in Categories C, D, or E, above, back under its jurisdiction if it makes certain findings regarding: (1) the likelihood and severity of patient harm if the software does not perform as intended, (2) the extent to which the software is intended to support the clinical judgment of a health care professional, (3) whether there is a reasonable opportunity for a health care professional to review the basis of the information or treatment recommendation, and (4) the intended user and use environment.
For FDA to determine that software excluded from the device definition should in fact be regulated, FDA must publish a notification and proposed order in the Federal Register, and must include its rationale and evidence on which it is relying for the conclusion that such software should be regulated. The notice must allow for at least 30 days of public comment before issuing a final order or withdrawing the proposed order.
The Cures Act requires the Secretary of Health and Human Services to publish a report, within two years of enactment of the Cures Act and every two years thereafter, that includes input from industry, consumers, patients, health plans, and other “stakeholders with relevant expertise.” The report must include information about any risks and benefits associated with the software functions provided in the Cures Act, and “summarizes findings regarding the impact of such software functions on patient safety, including best practices to promote safety, education, and competency related to such function.” Time will tell how this information may be used to further modify FDA’s authority over software.
For now, the software exclusions in Section 3060 of the Cures Act are welcome news to an industry that has been struggling with the question of whether its products are subject to FDA regulation, particularly in the area of CDSS. The new clarity will allow innovative software developers to move forward with greater confidence as to whether a product will or will not be regulated by FDA as a medical device.
.png)
No hay comentarios:
Publicar un comentario