2 min read
New guidance from the FDA replaces similar, but now obsolete, guidance. Some of the guidance was issued in response to the PATCH Act, which is a 2022 amendment to the Food, Drug and Cosmetics Act of 1938 that also pertains to medical device cybersecurity. It includes a requirement that sponsors need to make a plan to monitor post-market cybersecurity, a broad definition of “cyber device,” a requirement to create a Software Bill of Materials (SBOM), and a requirement of making sure the device is cybersecure during development. Below is a list of major changes that the FDA implemented.
The documentation level determines what documentation the FDA requires in a product submission and what activities need to occur during the development process.
Before Change: Software was categorized by “Level of Concern,” which included the categories of “Major,” “Moderate,” and “Minor”
After Change: Software is now categorized by “Documentation Level,” which includes categories of “Basic,” or “Enhanced”
ISO 14971 defines risk analysis as, “the systematic use of available information to identify hazards and to estimate risk” and spans the full total product lifecycle of medical devices.
Before Change: Only a device hazard analysis was required
After Change: A full ISO 14971-compliant risk management file is required including a risk management plan, risk benefit analysis, and a risk management report.
An unresolved software anomaly is a defect that still resides in the software because a sponsor deemed it appropriate not to correct or fix, according to a risk-based rationale about its impact on the device’s safety and effectiveness.
Before Change: A list of unresolved software anomalies was required only for software with Level of Concern designation of “Moderate,” or “Major”
After Change: A list of unresolved anomalies is always required
The security risk management plan/report includes two parts. Part one is the plan, which is written early in a development project. It describes how security threats will be identified, analyzed, and mitigated during development. The second part is the report, which is written at the end of a development project. It describes how security threats were actually identified, analyzed, and mitigated during development.
Before Change: The security risk management plan and report were not required
After Change: The security risk management plan and report are required unless the security risk management activities are planned/reported in the general risk management plan/report
The purpose of the system and software architecture diagram is to show a roadmap of the device design to facilitate a clear understanding of the modules and layers that make up the system and software, the relationships among the modules and layers, the data inputs/outputs and flow of data among the modules and layers, and how users or external products interact with the system and software.
Before Change: The software architecture document was not required
After Change: The software architecture document is required
The SBOM lists all the software components of the device software. The SBOM is machine-readable so it can be quickly scanned for cybersecurity vulnerabilities.
Before Change: A SBOM was not required
After Change: A SBOM is required
The security architecture document is similar to the software architecture document, but it highlights security concerns.
Before Change: A security architecture document was not required
After Change: A security architecture document is required
6 min read
As artificial intelligence transforms healthcare innovation, the FDA continues to evolve its regulatory framework for AI-enabled device software...
7 min read
As artificial intelligence continues to revolutionize medical device development, the FDA’s evolving regulatory framework presents both...
2 min read
Pharmaceutical manufacturers, medical device companies, and advanced diagnostic manufacturers are increasingly incorporating patients’ and...
