Tag Archive for: FDA Medical Device

FDA Draft Guidance

Notable Changes in the new FDA Draft Guidance – Content of Premarket Submissions for Device Software Functions

The FDA released its new draft guidance for the Content of Premarket Submissions for Device Software Functions on November 4, 2021. Once approved, this guidance will replace the preexisting Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices released in May 2005. A lot has changed in the last sixteen years where medical devices and software is concerned; the FDA released the new guidance citing technological advancements in all facets of health care, which has caused software to become an important part of many products and medical devices. The most impactful changes that we should be aware of from the guidance are as follows:

  • Change from Software Level of Concern (Major, Moderate, Minor) to Documentation Level of Concern (Basic, Enhanced)
  • Expanded scope, including –
    • Introduction of the term software function
    • Introduction of Software as a Medical Device (SaMD)
    • Addition of DeNovo Classification Request and Biologics License Application (BLA) to the premarket submissions to which the guidance applies
  • Introduction of additional consensus standards and guidance documents, including –
    • ANSI/AAMI/IEC 62304: Medical Device Software – Software Life Cycle Processes
    • Off-The-Shelf Software Use in Medical Devices
  • Provision of Examples (Documentation Level, System and Software Architecture Diagram Chart Examples)

RELATED: Understanding FDA Medical Device Class and Classifications, and its Impact on Requirements Management

Let’s analyze each of these changes and determine how impactful the change will be.

Where the change from Software Level of Concern to Documentation Level is concerned, there are several important things to consider when analyzing, the foremost being that Software Level of Concern is no longer used. The FDA now describes it as Documentation Level, which is more germane to the information conveyed. Additionally, the Documentation Level name change also avoids confusion with the IEC 62304 Software Classification and has the benefit of simplifying the process for determining the documentation level. Limiting the documentation level to two levels streamlines the process, as the only differences between the Moderate and Major Software Levels of Concern were the requirement to provide a Configuration Management Plan and Maintenance Plans instead of summaries, and the addition of Unit Test and Integration Protocols for the Major level of concern. Other changes related to the documentation to be provided are generally quite subtle, such as requiring the Risk Management File rather than just Device Hazard Analysis as specified by the current version of the guidance, and what used to be Software Development Environment Description being redesignated Software Development and Maintenance Practice. These changes create a tighter alignment with IEC 62304, highlight the importance of risk management and simplify the use of the guidance.

Although the scope of what the guidance is intended to cover remained unchanged, there are three new terms discussed in the scope section which serve to emphasize areas of importance to the FDA – device software function, Software in a Medical Device (SiMD) and Software as a Medical Device (SaMD). The term device software function is used to highlight the fact that a product could have multiple functions, a function being a distinct purpose of the product. SiMD and SaMD are new terms used in the industry, although the types of software covered by each term were already present in the original version of the standard. The premarket submissions for which the guidance applies now included the De Novo Classification Request (on July 9, 2012, FDA allowed a sponsor to submit a De Novo classification request to the FDA without first being required to submit a 510(k)) and Biologics License Application (as of March 23rd, 2020, all biological products must be approved through the BLA pathway), both of which were introduced after the current version of the guidance document. These changes serve to modernize the terminology used in the guidance and highlight the importance of the guidance being applicable to SaMD.

Another important update in the guidance is the mention of IEC 62304. This standard was first issued after the original FDA Guidance was released in May 2005; in the draft guidance, the FDA explains the relationship between its own draft guidance and IEC 62304. IEC 62304 is a software lifecycle process, whereas the scope of the FDA draft guidance is only the facilitation of appropriate review of premarket submissions, allowing for the evaluation of safety and effectiveness of medical devices. Since IEC 62304 is an FDA-recognized consensus standard, the FDA is allowing a Declaration of Conformity to IEC 62304 as documentation for Software Development and Maintenance Practices required by the draft guidance. In addition to the use of IEC 62304, the draft guidance also references other FDA guidance documents related to Cybersecurity and off-the-shelf software, which were likewise not available when the original version of the guidance was published in 2005. These changes also help modernize the guidance and demonstrate the importance of IEC 62304, as well as providing an indication of key areas that the FDA will expect to be addressed in future 510(k) submissions.

RELATED: Software as a Medical Device (SaMD): Four Key Development Best Practices

A further significant addition to the draft guidance is the inclusion of examples related to Documentation Level and System and Software Architecture. The examples included in the guidance provides different scenarios to show how to arrive at the Basic or Enhanced documentation levels. The draft guidance also provides an example of an architectural decomposition that can be applied to a system or software. In showing these diagrams, the FDA is proposing a level of documentation in the architecture document unseen in other FDA software-related guidance documents. The examples include different “functions” and are inclusive of SOUP (Software of Unknown Providence) modules. The inclusion of these examples provides an indication of FDA expectations when it comes to the documentation of software architecture and ensures that the new approach to determine the level of documentation required is well-understood.

In summary, the FDA Draft Guidance has been updated to bring it up to date with current standards and other guidelines that have been released since the initial guidance. There has been some level of simplification by substituting the software level of concern with basic and enhanced levels of documentation. Additionally, the guidance addresses current hot topics such as SaMD and IEC 62304. Examples have been added to the guidance to make it easier for users to understand and implement correctly.

RELATED


In this post, we highlight and summarize parts of the new “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions Draft Guidance for Industry and Food and Drug Administration Staff.” It is important to note that this content contains non-binding guidance and therefore is not currently for implementation.

With that said, while this draft is non-binding, some organizations may adapt to this guidance proactively to address hot topics not covered in formal regulation, for example: U/X Human Factors, Software as a Medical Device (SaMD), combination products, and others.

This blog post, while quoting the FDA draft guidance directly, is not a full representation of the content. It is comprised of snippets that were particularly relevant or interesting to the author. It also does not cover any appendices.

You can find the full draft guidance here.

Following this information, subject matter expert, Vincent Balgos, weighs in on the draft guidance. Read to the end to see his thoughts!

FDA Guidance for Cybersecurity for Medical Device

With the increasing integration of wireless, Internet- and network-connected capabilities, portable media (e.g., USB or CD), and the frequent electronic exchange of medical device related health information, the need for robust cybersecurity controls to ensure medical device safety and effectiveness has become more important.

In addition, cybersecurity threats to the healthcare sector have become more frequent and more severe, carrying increased potential for clinical impact. Cybersecurity incidents have rendered medical devices and hospital networks inoperable, disrupting the delivery of patient care across healthcare facilities in the U.S. and globally. Such cyberattacks and exploits may lead to patient harm as a result of clinical hazards, such as delay in diagnoses and/or treatment.

Increased connectivity and interoperability have resulted in individual devices operating as single elements of larger medical device systems. These systems can include health care facility networks, other devices, and software update servers, among other interconnected components. Consequently, without adequate cybersecurity considerations across all aspects of these systems, a cybersecurity threat can compromise the safety and/or effectiveness of a device by compromising the functionality of any asset in the system. As a result, ensuring device safety and effectiveness includes adequate device cybersecurity, as well as its security as part of the larger system. For the current edition of the FDA-recognized consensus standard(s) referenced in this document, see the FDA Recognized Consensus Standards Database.

Scope: Who Does This Apply To?

This guidance document is applicable to devices that contain software (including firmware) or programmable logic, as well as software as a medical device (SaMD). The guidance is not limited to devices that are network-enabled or contain other connected capabilities. This guidance describes recommendations regarding the cybersecurity information to be submitted for devices under the following premarket submission types:

  • Premarket Notification (510(k)) submissions;
  • De Novo requests;
  • Premarket Approval Applications (PMAs) and PMA supplements;
  • Product Development Protocols (PDPs);
  • Investigational Device Exemption (IDE) submissions; and
  • Humanitarian Device Exemption (HDE) submissions.

General Principles

This section provides general principles for device cybersecurity relevant to device manufacturers. These principles, found throughout this guidance document, are important to the improvement of device cybersecurity and, when followed, are expected to have a positive impact on patient safety.

These general principles include:

  • Cybersecurity is Part of Device Safety and the Quality System Regulations
  • Designing for Security
  • Transparency in Cybersecurity
  • Submission Documentation

RELATED: Understanding FDA Medical Device Class and Classifications, and its Impact on Requirements Management

Using an SPDF to Manage Cybersecurity Risks

The documentation recommended in this guidance is based on FDA’s experience evaluating the safety and effectiveness of devices with cybersecurity vulnerabilities. However, sponsors may use alternative approaches and provide different documentation so long as their approach and documentation satisfies premarket submission requirements in applicable statutory provisions and regulations. The increasingly interconnected nature of medical devices has demonstrated the importance of addressing cybersecurity risks associated with device connectivity in device design because of the effects on safety and effectiveness.

Cybersecurity risks that are introduced by threats directly to the medical device or to the larger medical device system can be reasonably controlled through using an SPDF.

The primary goal of using an SPDF is to manufacture and maintain safe and effective devices. From a security context, these are also trustworthy and resilient devices. These devices can then be managed (e.g., installed, configured, updated, review of device logs) through the device design and associated labeling by the device manufacturers and/or users (e.g., patients, healthcare facilities). For health care facilities, these devices may also be managed within their own cybersecurity risk management frameworks, such as the National Institute of Standards and Technology Framework for Improving Critical Infrastructure Cybersecurity, generally referred to as the NIST Cybersecurity Framework or NIST CSF.

Security Risk Management

To fully account for cybersecurity risks in devices, the safety and security risks of each device should be assessed within the context of the larger system in which the device operates. In the context of cybersecurity, security risk management processes are critical because, given the evolving nature of cybersecurity threats and risks, no device is, or can be, completely secure. Security risk management should be part of a manufacturer’s quality system. Specifically, the QSR requires, among other things, that manufacturers’ processes address design (21 CFR 820.30), validation of the production processes (21 CFR 820.70), and corrective or preventive actions (21 CFR 820.100). These processes entail the technical, personnel, and management practices, among others, that manufacturers use to manage potential risks to their devices and ensure that their devices remain safe and effective, which includes security.

Specific security risk management documentation where FDA has recommendations regarding 354 their scope and/or content are discussed in the following subsections:

  1. Threat Modeling
  2. Third-Party Software Components
  3. Security Assessment of Unresolved Anomalies
  4. Security Risk Management Documentation
  5. TPLC Security Risk Management

Security Architecture

Manufacturers are responsible for identifying cybersecurity risks in their devices and the systems in which they expect those devices to operate and implementing the appropriate controls to mitigate those risks. These risks may include those introduced by device reliance on hospital networks, cloud infrastructure, or “other functions” (as defined in FDA’s guidance “Multiple Function Device Products: Policy and Considerations), for example. FDA recommends that all medical devices provide and enforce the security objectives in Section IV, above, but recognizes that implementations to address the security objectives may vary.

Throughout this section, FDA outlines the recommended security controls and recommendations on how to document the resultant security architecture in premarket submissions through specific Security Architecture Views.

Cybersecurity Testing

As with other areas of product development, testing is used to demonstrate the effectiveness of control mitigations. While software development and cybersecurity are closely related disciplines, cybersecurity controls require testing beyond standard software verification and validation activities to demonstrate the effectiveness of the controls in a proper security context to therefore demonstrate that the device has a reasonable assurance of safety and effectiveness.

Security testing documentation and any associated reports or assessments should be submitted in the premarket submission. FDA recommends that the following types of testing, among others, be provided in the submission:

  • Security requirements
  • Threat mitigation
  • Vulnerability testing
  • Penetration testing

RELATED: Software as a Medical Device (SaMD): Four Key Development Best Practices

Cybersecurity Transparency

In order for users to manage security risks in devices, either by an end user or within a larger risk management framework like the NIST CSF, transparency is critical to ensure safe and effective use and integration of devices and systems. This transparency can be conveyed through both labeling and the establishment of vulnerability management plans. However, different types of users (e.g., manufacturers, servicers, patients, etc.) will have different abilities to take on a mitigation role, and the need for actions to ensure continued cybersecurity should be appropriate for the type of user.

In this section, FDA provides recommendations on:

  • Labeling Recommendations for Devices with Cybersecurity Risks
  • Vulnerability Management Plans
Vincent Balgos Afterward:

In general, cybersecurity continues to be a growing and significant issue in recent years. From the Experian data breach (2017), Marriot Hotel (2018), and LinkedIn (2021), the volume of sensitive data exposed at an alarming frequency poses a significant risk. In the healthcare sector, the Scripps Health cyberattack in my hometown of San Diego, CA, some estimate that the minimal impact is expected to be >$100 million. More significantly, the potential impact of sensitive patient data out in the public domain is immeasurable.

On the medical device front, the FDA has issued recalls on a variety of devices (insulin pumps, pacemakers, etc.) citing cybersecurity risks for years. As medical device technology advances, and interoperability becomes more common, the opportunity of cybersecurity risks is ever more present.

Medical companies have (or need to soon) started considering cybersecurity as part of their standard business practices. In addition to the suggestions mentioned in the FDA draft guidance, many of us at Jama Software have seen medical company initiatives that include hiring cybersecurity experts to proactively support these efforts, incorporating a dedicated cybersecurity focus within the overall risk management procedure, and/or continued monitoring of the products and systems for potential exploits.

Since a single vulnerability can have dramatic impact, a systems approach to cybersecurity can provide valuable perspective for various levels of mitigation. In complex systems, with multiple interfaces, data streams, etc., potential vulnerabilities increase at a non-linear rate.

But how does one measure the cybersecurity level of a product’s software? An emerging metric is the Common Vulnerability Score System (CVSS) that assesses software vulnerabilities in a quantitative value. Some organizations may include this CVSS as a design requirement during the product development phase.

This approach proactively incorporates cybersecurity best practices early in the design process, which in turn demonstrates security traceability into the design, and its subsequent testing. With Jama Connect, and specifically our unique ability to create Live Traceability™ across the product development process, this cybersecurity requirement can be continually monitored (along with all other requirements) to ensure that the final product is safe, effective, and secured from potential cyberattacks.

RELATED


>

In this blog, we preview our whitepaper “FDA New Draft Guidance of Premarket Submissions for Medical Devices: Are you ready?” Download the entire whitepaper to learn more!

FDA New Draft Guidance of Premarket Submissions for Medical Devices: Are you ready?

Technology innovation has undergone rapid transformation since the Food and Drug Administration first developed its “Guidance for the Content of Premarket Submissions of Software Contained in Medical Devices” in 2005. Over the past 17 years, significant advancements have disrupted the market, including the advent of the smartphone, watches that monitor your sleep and snoring habits, and smartphone-connected pacemaker devices, just to name a few.

The medical device industry has also undergone a sizable transformation, which is why the FDA recently released the “Premarket Submissions for Device Software Functions” draft guidance to keep up with the changes. Please note that while this guidance is valuable to medical device developers to get a sense of what’s to come, it is not currently being enforced.

It’s also important to note this guidance applies to all premarket approval (PMA) and to some 510k’s, based on risk level.

The new draft guidance, which as of March 2022 has not yet gone into effect and therefore is currently non-binding, revises documentation standards that apply to the software development, design verification, and design validation processes.

As you work to adapt to the new guidance, you might have many questions, including “Who and what does the new guidance apply to? And what exactly has changed?” Answering these important questions will assist you with getting ready for the changes, which are set to finalize in spring 2022.

The New Guidance: Does It Apply To Your Device?

The new guidance applies to all premarket submissions that include at least one device software function. However, it’s not intended to provide recommendations on how a device’s software should be developed, verified, and validated. Software in a medical device (SiMD) and software as a medical device (SaMD) are both included in the guidance. The following are also included, according to the FDA:

  • Firmware and other means for software-based control of medical devices
  • Stand-alone software applications
  • Software intended to be operated on general-purpose computing platforms
  • Dedicated hardware/software medical devices
  • Accessories to medical devices when those accessories contain or are composed of software

Recent changes made to section 520 of the Federal Food, Drug, and Cosmetic Act under the 21st Century Cures Act excludes some types of software, including those that are lower-risk, support software, such as certain mobile applications for consumers, and software for administrator support to laboratories. Additionally, the guidance does not apply to automated manufacturing and quality system software or software that is not a device.

Related: How Össur Uses Jama Connect to Keep Millions of People Moving

To learn more, download the entire whitepaper where we cover a summary of the draft guidance, plus:

  • The difference between the new and old guidance
  • Documentation levels: Basic vs. Enhanced
  • Software documentation elements
RELATED


One of the early steps I advise my clients to take when developing their medical device is to determine the class and classifications of their medical device. In conjunction with the complexity of the device, understanding the class and classification sets the foundation for your product development timeline and effort. 

This post gives a basic introduction to FDA medical device classes and classifications and the implications for your product development schedule and requirements management. 

What are FDA medical device class and classifications? 

The FDA established three regulatory classes based on the level of control necessary to assure the safety and effectiveness of the device. Classification is based on the intended use of the device and indications for use, as well as the risk the device poses to patients and users.   

There are three classes: Class I, Class II, and Class III. Class I devices are those with the lowest risk, Class II devices have a greater risk, and Class III includes devices with the greatest risk.   

The FDA also established classifications for over 1,700 generic types of medical devices and grouped them into 16 panels, or medical specialties. Example panels include Cardiovascular Devices and Radiology Devices. Each of the generic types is assigned as Class I, Class II, or Class III. 

RELATED POST: Complying with FDA Design Control Requirements Using Requirements Management

Impact of the device class and classifications 

The class and classification of the device impacts what FDA premarket submission or application is required for clearance to market. The common premarketing submission or application for each class are:  

Note: These are the common regulatory submission and applications for each class of device. There are exemptions, limitations on those exemptions, special controls that may apply, and exceptions, so be aware whether any of these applies to your device. For example, about a quarter of Class I devices are not exempt, and a 510k premarket submission is required. 

As the process for the 510k submission is 30-90 days, and the process for the more in-depth PMA submission is 180 days to accept or reject, this time should be understood and planned into your product development schedule.   

RELATED POST: Customer Story: Medical Device Startup, Proprio, Chooses Jama Connect® to Drive Innovation

Similarly, expect elements from the required design control process and design history file to be included as part of a 510k and PMA. Also keep in mind that when design controls are required for your device classification, the full design history file can be scrutinized as part of an FDA inspection of your organization. Since the FDA evaluates whether a device is effective and ensures the risk to the patients and users is appropriately addressed, good requirements and risk management is key. It’s important to have an organized manner in which to demonstrate and document that risk management and user needs are successfully traced through design inputs, design verification, and design validation. A requirements management tool like Jama Connect™ allows for this traceability in an efficient, collaborative, and regulatory-compliant manner. 

Understanding your device class and classification is a key step to understanding the path for FDA regulatory clearance and subsequent design control requirements for your medical device development. Knowing those expectations up front will make for a smoother medical device development journey.  

Learn more about developing medical devices with Jama Connect!