Blog Tag: software
The U.S. Food and Drug Administration (FDA) recently updated its software Precertification Program. A working program was originally rolled out in April 2018, but the program was updated in response to requested public input. The FDA expects to roll out a finalized version of the program by December 2018 and to have a pilot test available in 2019.
With the precertification program, the FDA hopes to streamline the certification of “mobile apps” and other software that is used to “treat, diagnose, cure, mitigate, or prevent disease or other conditions,” or so-called software as a medical device (SaMD), according to the updated program description. While software in a medical device (SiMD) is not currently part of the program, the FDA hopes to include SiMD and software that is an accessory to hardware in the future. The program will allow certain organizations that can demonstrate a “culture of quality and organizational excellence” to streamline their oversight of SaMD.
The update clarifies that not all software is subject to regulatory review even if it has some connection to the medical industry. In particular, the update notes that non-device software is exempt, such as software that is intended for (1) for administrative support, (2) for maintaining or encouraging a healthy lifestyle, (3) to serve as electronic patient records, (4) for transferring, storing, converting formats, or for displaying data, or (5) to provide certain limited clinical decision support.
According to the update, organizations “of all sizes” can qualify. The FDA makes clear that startups and smaller companies can apply and receive precertification. Two levels of precertification exist. Level 1 precertification allows an organization to develop and market “lower risk” software without review while also streamlining review of higher risk software. This level would be awarded to an organization that demonstrates excellence in product development but may have a “limited track record” in “developing, delivering, and maintaining” products in the healthcare market. Level 2 precertification allows “lower and moderate risk” software to be developed and marketed without review and allowing streamlined review of other software. This level is awarded to those organizations with a track record in demonstrating high quality software products.
In determining what amount of review is required for “lower risk” and “moderate risk” SaMD, the FDA looks at (1) the risk category of the product, (2) the level of precertification of the organization, and (3) the extent of the changes the software relative to an existing device. Under either level of precertification, “minor changes” require no review by the FDA.
The FDA is looking to update additional aspects of the precertification program, including how it relates to substantially equivalent device review. The FDA is currently requesting comments on the program.
The U.S. Food and Drug Administration announced the availability of a draft guidance for the clinical evaluation of software as a medical device (SaMD). The draft guidance was prepared by the SaMD Working Group of the International Medical Device Regulators Forum (IMDRF), an international group of medical device regulatory authorities including the FDA. When finalized by the IMDRF, the draft guidance will represent the FDA’s “current thinking” on SaMD clinical evaluation and will not be binding.
SaMD is defined in the guidance as software that functions as a medical device and can run on a general purpose computing platform, “without being part of a hardware medical device.” Unlike other medical device-related software, SaMD primarily has risks associated with incorrect output affecting clinical management of a patient, rather than risks resulting from direct patient contact. Thus, the guidance is intended to address the “uniqueness of indirect contact between patients and SaMD” and provide globally harmonized principles for establishing scientific validity, clinical performance, and analytical validity for a SaMD.
The FDA is seeking public comment on the draft guidance generally, and related to eight specific issues:
Does the document address the intention captured in the introduction/scope or vice versa?
Does the document appropriately translate and apply current clinical vocabulary for SaMD?
Are there other types of SaMD beyond those intended for non-diagnostic, diagnostic and therapeutic purposes that should be highlighted/considered in the document?
Does the document adequately address the relevant clinical evaluation methods and processes for SaMD to generate clinical evidence?
Are there other appropriate methods for generating clinical evaluation evidence that are relevant for SaMD beyond those described in the document?
Are the recommendations related to the “importance of clinical evidence and expectations” appropriate as outlined for the different SaMD categories?
Are the recommendations related to the “importance of independent review” appropriate as outlined for the different SaMD categories?
Given the uniqueness of SaMD and the proposed framework—is there any impact on currently regulated devices or any possible adverse consequences?
The draft guidance is available for comment until December 13, 2016.
The U.S. Food & Drug Administration (FDA) issued a proposed guidance on August 8, 2016, regarding software changes to medical devices. The proposed guidance relates to requirements for submitting medical device software changes to the FDA for approval. The final document will provide assistance to medical device companies and the FDA for determining when changes to software or firmware for a medical device require FDA clearance. The medical devices covered include 510(k)-cleared devices and preamendments devices subject to 510(k).
The FDA’s proposed guidance explains that premarket notifications are generally submitted for commercially-distributed medical devices undergoing significant changes in design. Such changes include modifications that “could significantly affect the safety or effectiveness of the device” or a “major change or modification in the intended use of the device.” The proposed guidance relates to software changes and is an update to the original guidance issued in 1997 regarding changes to existing devices.
The “software” subject to the proposed guidance is defined as “electronic instructions used to control the actions or output of a medical device, to provide input to or output from a medical device, or to provide the actions of a medical device.” This includes software embedded in a device, software that is an accessory to another device, and “software that is intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device.”
The FDA provides a flow chart for assisting with the determination, see below. Issues addressed in the determination include changes related to: strengthening cyber security; meeting specifications of the most recently cleared device; introducing or affecting hazardous situations; creating new risk control measures; and affecting clinical functionality or intended use of the device. Additional factors to consider beyond those in the flow chart and some examples of modifications are provided in the draft guidance as well.
The proposed guidance notes that in some cases a new 510(k) is not necessary, and that existing Quality System (QS) requirements may suffice. Such QS requirements mandate, among other things, that the manufacturer maintains records, for production upon request, regarding such changes and the processes used to determine the changed device meet the design specifications. Further, the proposed guidance does not apply to software for which the FDA has previously said it will not enforce compliance, including some mobile apps used with medical devices.
Some observers think the proposed guidance will help with improving cybersecurity of connected medical devices. The public may provide comments to the FDA on the proposed guidance until November 7, 2016: comments may be submitted electronically here.
Amid myriad media reports about potential vulnerabilities in medical device cybersecurity and the FDA’s efforts to strengthen medical device cybersecurity, the IEEE Cybersecurity Initiative released a report entitled “Building Code for Medical Device Software Security.” The report sets forth a set of elements aimed at reducing the vulnerability of medical device software to malicious attackers. The report employs a loose definition of “medical devices,” ranging from wearable devices to electronic health record systems.
The report highlights the most common types of software vulnerabilities that are exploited by malicious attackers. The bulk of the report proposes standards for five software implementation considerations in ways to (1) avoid, detect, or remove specific vulnerabilities like using memory-safe languages, secure coding standards, and automated thread safety analysis; (2) ensure proper cryptography; (3) improve software integrity; (4) impede attacker analysis or exploitation; and (5) detect malicious attacks. The report further brings up four software design considerations about maintaining service during or restore service after an attack and supporting privacy requirements, but does not propose any standards. Finally, the report notes that the “building code” itself should be consistent in categorizing particular types of attacks and should be maintained over time.
The IEEE Center for Secure Design has also released “Avoiding the Top 10 Software Security Design Flaws,” to give advice on ways to address particular issues including data authentication, authorization, and validation; cryptography; sensitive data classification; and integrating external software components.