Skip to main content

The latest (June 2023) changes to the FDA’s new premarket submission guidance

How will the June 2023 software premarket submission guidance document changes affect developers?
Lee Chickering
  •  
October 16, 2023
  •  
No items found.

On June 14, 2023, a long-awaited new FDA guidance Content of Premarket Submissions for Device Software Functions replaced the 2005 version which defined the content of software submissions. This guidance outlines key changes software developers, regulatory affairs, and quality professionals need to know about the differences between the original 2005 guidance and the 2023 version. 

The recent update brings significant changes to the submission process, particularly in the levels of documentation required based on the risk level of the device. We will guide you through the key points to clarify the FDA’s expectations while offering practical steps for you and your team to meet them without feeling overwhelmed.

Part 1: Software Categorization has changed 

In the 2005 version, device software fell into one of three categories: Minor, Moderate, and Major levels of risk. These levels of risk determined the type and amount of design control documentation to submit to the FDA. 

In 2023, the FDA has “reduced” the software risk level categories to an Enhanced or Basic construct, changing the degree of design control documentation previously required.

No device software is considered “Minor” anymore. Manufacturers whose device was previously categorized as “Minor” or “Moderate” will need to take a close look at the new requirements for their software documentation. 

In a recent webinar, the FDA made it clear that risk analysis is the determining factor for the assigned documentation levels. Companies, per the new mandated eSTAR program, must now complete a thorough Risk Analysis to determine if they qualify as Basic or Enhanced and submit their evaluation. This is called out in the 2023 premarket submission guidance document, Table 1 . Outline of Recommended Documentation—“A statement indicating the Documentation Level and a description of the rationale for that level [is required]."

Enhanced: “Device software function(s) where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use.” Device software previously labeled as Major falls under this category along with some Moderate categorizations. 

Basic: “Any premarket submission that includes device software function(s) where Enhanced Documentation does not apply”. Device software previously labeled as Minor along with some Moderate falls under this category  Generally, devices that fall in the Basic category require less submission documentation than the Enhanced category.

Summary Table of Documentation Level Changes

Part 2: Review of changes for required premarket submission documentation for device software

Here is a step-by-step breakdown of what stayed the same and changes that are now in effect as of August 14, 2023. You can also view our handy tool here to easily view changes based on either the 2005 or 2023 software categorization levels

  1. Documentation Level Evaluation (formerly Level of Concern (LOC)): While the methodology for determining a submission documentation category remains essentially the same, e.g., risk based, the type and amount of documentation changes significantly for previous minor and moderate risk level categories of devices.
  2. Software Description: The requirement for this type of documentation remains unchanged. However, the degree of detail required now, in the context of software systems engineering is significantly different, e.g., “overview of significant software features, functions, analyses, inputs, outputs, and hardware platforms”. It also references cybersecurity considerations (footnote).
  3. Risk Management File (formerly Hazard Analysis): Changes in guidance are significant. Previous guidance asked for a “summary” subset of the risk analysis process (hazard analysis) in tabular form with specific fields. Now the requirement is to provide a Risk Management File which contains all of the risk analysis information resulting in risk control measures and a benefit/risk analysis. Previous guidance was based on a risk/benefit analysis corresponding to standards of that era. Now, overall residual risk is assessed on a benefit/risk basis corresponding to current standards.
  4. Software Requirement Specifications (SRS): Previously, manufacturers of Minor LOC devices could summarize functional requirements. Now, everyone must submit a complete SRS document with appropriate quality assurance properties - enumerated in the guidance. The SRS should explain the software system, sub-systems, and traceability between design and development artifacts. 
  5. System and Software Architecture Design (formerly Architecture Design Chart): Detailed Architecture Design is now required for all software submissions, irrespective of the device risk level. Previously, manufacturers of devices with a Minor LOC device did not need to submit an architecture diagram. 
  6. Software Design Specification (SDS) (includes the former Traceability Analysis requirements): This section poses a unique scenario for Minor and Moderate LOC device software. Previously, Minor LOC devices didn’t require an SDS for software submissions. However, Moderate and Major LOC devices did require an SDS. All three LOC devices required a traceability analysis document. Now, manufacturers are not required to submit an SDS for Basic risk level devices (which was previously required for Moderate LOC devices), and no traceability analysis for Basic risk level devices (which was previously required for all LOC devices). Enhanced risk level devices require an SDS along with evidence of traceability to the SRS. For Basic level devices FDA may request additional information including the SDS.

    “During premarket review, FDA may request additional information, if needed, to evaluate the safety and effectiveness of the device.”


    As a result, it is recommended to be able to generate an SDS and develop this documentation internally.
  7. Software Development, Configuration, Management, and Maintenance Practices (formerly Software Development Environment Description: Similar to the architecture design requirements, documentation requirements have changed for a Minor LOC device. Previously, no documentation was necessary, but manufacturers will find that Minor (now classified as Basic) requires document generation that is either a summary of the life cycle development plan, configuration management and maintenance activities expected OR a Declaration of Conformity to IEC 62304 including specific subclauses of the standard. For  Enhanced software (previously Major and some Moderate device LOCs), a Declaration of Conformity OR extensive documentation that includes all Basic requirements, as well as configuration management and maintenance plans, is now required. 
  8. Software Testing as Part of Verification and Validation (formerly Verification and Validation Documentation): For those previous Minor LOC devices, more testing documentation is required. Detailed descriptions of V&V activities, integration, and other processes are now needed.  Those with Moderate LOCs will find additional requirements in the 2023 version. For the Major LOC devices (now Enhanced), the previous requirements still apply and, in addition, detailed test protocols, expected results, and detailed unit and integration test level reports are required.  
  9. Software Version History (formerly Revision Level History): There is a notable change in this category. All levels are required to continue documenting a history of tested software versions, and their date. A new requirement is to provide a brief description of each (tested) version. 
  10. Unresolved Anomaly List: All levels must provide this documentation. Previously, Minor LOC’s were exempt from this requirement. 
  11. Traceability Matrix: The requirement for an explicit traceability analysis (matrix) has been removed. In its place is a requirement to establish traceability between design documents (new SRS Section).

Part 3: The Impact of Changes to the FDA 510(k) Pre-market Submission

Over the years there has been a lot of confusion in determining the software LOC. In response, the FDA is clarifying the risk based activities that should be completed and artifacts expected from a Quality Management System.

Based on the level of detail, the updated guidance is more explicit, leaving less room for ambiguity. Accordingly, the FDA expects all companies to comply promptly with the new requirements. For some manufacturers, this update will have minimal impact on their daily processes. However, many manufacturers will find that these requirements, which were once more general or unnecessary, will place a massive strain on their company’s bandwidth to produce the required documentation. The implementation of better tools and a coordinated quality management system (QMS) is more important than ever as manufacturers generate new documents for the first time while updating their previous ones. 

Keeping on top of compliance with the latest FDA guidance will help ensure a successful premarket submission and a smoother path to market approval. 

Want to see how Ketryx can help you generate all FDA-required documentation automatically while enabling developers to use the dev tools they love? Try Ketryx today free here or schedule a time with our team.

Want to learn more about the FDA’s 2023 changes? Visit the Ketryx blog post “The FDA drops a Cybersecurity Compliance SBOM in 2023” or visit the Ketryx Learning Center to read more about the FDA with our eBook Inside the FDA Regulatory Process

--------

Sources:

July 20th, 2023 Webinar Slides: FDA Government Presentation

Content of Premarket Submissions for Device Software Functions - Final Guidance: FDA Government Publication

Interview transcript

More blogs

No items found.