At Long Last: FDA Updates Software Guidance (Part II of II)

Post Views: 1,335

As noted in Part I, last week the FDA released a long-awaited updated guidance document regarding the Content of Premarket Submissions for Device Software Functions. This guidance, the first update in over 16 years, was intended to provide clarity regarding the required documentation of Software in a Medical Device (SiMD) or Software as a Medical Device (SaMD).

In addition to what we highlighted in Part I, the guidance recommends the following Software Documentation Elements required for both Basic and Enhanced Documentation Levels:

  • Documentation Level Evaluation (Section IV.A) – A statement indicating the appropriate Documentation Level and a description of the rationale for that level.

  • Software Description (Section IV.B) – Software description, including overview of operationally significant software features, analyses, inputs, and outputs.

  • System and Software Architecture Design Chart (Section IV.C) – Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products (including IT infrastructure and peripherals) interact with the system and software.

  • Risk Management File (Section IV.D) – Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report.

  • Software Requirements Specification (SRS) (Section IV.E) – The complete documentation, describing the needs or expectations for a system or software, presented in an organized format and with sufficient information to understand the traceability of the information with respect to the other software documentation elements (e.g., risk management file, software design specification, system and software architecture design chart, software testing as part of verification and validation).

  • Revision Level History (Section IV.I) – Revision history tabulating the major changes to the software during the development cycle, including date, version number, a brief description of the changes relative to the previous version, and indication of the version on which testing was performed.

  • Unresolved Anomalies (e.g., Bugs, Defects, or Errors) (Section IV.J) – List of remaining software anomalies (e.g., bugs, defects) annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors, work-arounds, and timeframe for correction.

However, some recommendations for Software Documentation Elements differ by Basic Documentation Level and Enhanced Documentation Level.

Basic Documentation Level:

  • Software Design Specification (SDS) (Section IV.F) – Not required for Basic Documentation Level.

  • Software Development and Maintenance Practices (Section IV.G) –A Declaration of Conformity to IEC 62304 OR a summary of the life cycle development plan and a summary of configuration management and maintenance activities.

  • Software Testing as Part of Verification and Validation (Section IV.H) – A summary description of the testing activities at the unit, integration and system levels. System level test protocol including expected results, observed results, pass/fail determination, and system level test report.

Enhanced Documentation Level:

  • Software Design Specification (SDS) (Section IV.F) – The complete documentation, including sufficient information that would allow FDA to understand the technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness.

  • Software Development and Maintenance Practices (Section IV.G) – A Declaration of Conformity to IEC 62304 OR Basic Documentation Level PLUS complete configuration management and maintenance plan document(s).

  • Software Testing as Part of Verification and Validation (Section IV.H) – Basic Documentation Level PLUS unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports.

As in our last post, we offer the benefit of our extensive experience: The earlier your company implements the recommended practices, the better your documentation will ultimately be. If you need guidance regarding these regulations or on how to develop efficient and effective documentation, look to Rook; we have nearly a decade of hands-on experience translating “regulatory-ese” to English, and providing our clients with the optimal tools and templates to comply with regulations in domestic and international markets.

Back To Top