Documentation for Medical Device Software

Note: this is only an introduction to medical device software documentation. Experienced readers will see that I’ve left out (intentionally) many details about the documentation needed for medical device software.

An Awkward Couple

There is a basic mismatch between modern software development methods and medical device regulatory compliance documentation. Anyone familiar with agile methods for software development knows that agile emphasizes working software over documentation and that eliminating unnecessary documentation helps agile teams be more productive and flexible. Right?

But in the highly regulated world of medical devices, there is a lot of necessary documentation. Therefore the goal for agile teams developing medical software is not to eliminate documentation but to be as efficient as possible in generating and updating the software documentation. Another way to think about this is that the definition of done for a software team is not just finished software, it’s also delivering completed software documentation.

Many people misunderstand the purpose of documentation in medical device regulatory compliance. They often think the documents only refer to the design of the product but in fact the regulations are focused on processes and the documents are the evidence that your team is following the processes. So if you’re only documenting the design then you’re missing the majority of the documentation needed for compliance.

For example, here are the parts of the software development process defined in the IEC 62304 medical software standard with corresponding documents (evidence) for each process (activity).

62304 Processes (Activities)	Examples of Evidence
5.1 SW Development Planning planning the goals of the SW development project, the tasks and deliverables, roles and responsibilities; coordinating across groups; allocating resources; and controlling risks	Software Development Plan (or Design & Development Plan)
5.2 SW Requirements Analysis decomposing system/product requirements into SW requirements within the context of the system architecture design (identifying the system functions that are to be implemented in SW)	Software Requirements Specification
5.3 SW Architectural Design high level design of the software, including partitioning/segregation of high-risk software, as appropriate, and interfaces	Software Architectural Design (or System Architectural Design)
5.4 SW Detailed Design defining the SW units and their interfaces, including state diagrams, data structures, and risk controls	Software Design Specification (or Software Detailed Design or Software Specification)
5.5 SW Unit Implementation & Verification the core of SW development; coding and testing; code reviews; static analysis	Software Unit Verification Summary (or Code Unit Verification)
5.6 SW Integration & Integration Testing merge software units and demonstrate that multiple software components work properly together and with the system hardware	Software Unit Verification Summary (or Code Unit Verification)
5.7 SW System Testing verification of software against the SW requirements in a system environment	Software Test Protocols and Test Reports
5.8 SW Release deploying a controlled, verified version of software	Release Notes, Revision History, Open Bug List, SW BOM, etc.

Knowledge Is Power

Make sure everyone on the software team knows what needs to be documented, when documents need to be released, and how software changes impact the documentation.  With this basic knowledge the team can make intelligent tradeoffs in planning their work and make accurate estimates for completing tasks (and not run into unpleasant surprises at the time of software release).

This information should be clearly described in your company’s quality system SOPs (and to a lesser extent in each project’s Software Development Plan) and everyone involved should be trained on the procedures. The goal here is to integrate the documentation work into your software development methods so it becomes a matter of “turning the crank” instead of wasting time in lots of meetings and emails trying to figure out what needs to be documented.

Example Set of Software Documents

The table below describes a typical set of documents for medical device software (assumes Level of Concern = Moderate;  Safety Classification = B).  Note that there are many different ways to structure your software documentation and still comply with the IEC 62304 standard and FDA software guidances; this is just one way.  For example, some companies use the title “Software Design Specification” or “Software Specification” instead of “Software Detailed Design.”

Software Document	Description
Software Development Plan (SDP)	Defines SW development activities, roles/responsibilities, deliverables, and SW testing for this SW project.   Serves as the master document for the SW project.  Establishes overall risk level of software–defines A/B/C class (per 62304) and Level of Concern (per FDA)
System Hazard Analysis (SHA)	Top-down risk analysis which includes analysis of effects of potential SW failures and where SW serves as a risk control (alternative: analyze SW failures in specific SW DFMEA and cybersecurity risk analysis documents
Software Requirements Specification (SRS)	Defines what the SW needs to do; forms basis for SW system-level testing; implements product requirements; implements risk control measures
Software Architectural Design (SWAD)	High-level description of software system design, showing which parts are controlled by SW; shows organization of SW (functional units, state diagrams, interfaces, etc.)
Software Detailed Design (SDD)	Detailed description of SW design (how the SW reqts are implemented); includes UI design; written at a level that a SW engineer could understand the design and make changes for software upgrades
Software Test Plan (STP)	Defines how software will be tested (all types of software testing); roles/responsibilities, resources needed for testing; key milestones and phases;  can be combined with the overall SDP
Software Design Review records	Meeting minutes, decisions/conclusions, action items, and data reviewed at key milestones in the SW project
Software Unit Verification Summary	Evidence of unit testing, code reviews, and static analysis
Software Verification Protocols	Documents defining test methods, acceptance criteria, and test environments for testing of SW requirements (typically a set of test cases)
Software Traceability Matrix	A cross-reference table that defines traceability between SW requirements, implementation, and SW testing; sometimes combined in the SW V&V Summary Report
Software V&V Summary Report	A single report with results of all testing of SW requirements and overall product validation
Unresolved Anomalies Report	Open bug list at time of release with a risk assessment for each bug (can be combined with V&V Summary Report)
Software Release Package	Identifies the software being released:  SW version, SW BOM including all  OTS/SOUP software used in the product; revision level history with table of all SW versions previously released and changes between them; references all documentation associated with this release  (the ‘last’ software document)
Software Maintenance Plan	Describes how the software (including SOUP) will be monitored throughout its lifetime and updated as needed; may be combined with an overall post-market surveillance plan or simply be covered by QMS procedures
Validation for software test tools / test scripts	Sets of validation documentation (plans, designs, test protocols/reports, etc.) to qualify SW tools used in V&V testing

Documentation Automation

That’s a long list of documents and every time the team makes a change to the software they need to update some or all of the software documentation.  Think about the impact of that on your software team–it can easily take longer to update all the documentation than to update the software!  What to do?

This is where automatic generation of documentation from software tools makes a huge difference.  First consider the documents that are most frequently affected by changes to the software: requirements, design, test, and trace documents.  Then look at the information already stored and managed in the team’s development tools and develop ways to extract that information into the formal compliance documentation. For example, exporting a set of test cases from a test management tool and turning them into a formal software test protocol document, signed off in Doc Control.

In my experience, once a software team has gone through the laborious process of creating all the documentation by hand, they can be very resourceful in figuring out ways to automatically generate document content.  Investing time up front on this kind of automation will save time on every subsequent software release. 

Summary

The documentation needed for medical device software is lengthy and complex.  Make sure everyone on the software team knows what documentation is needed and integrate that into the development workflow.  And try to leverage software tools as much as possible to automatically generate document content.

Links

Here’s an alternative set of example software documents from Promenade Software:

  FDA and IEC 62304 Software Documentation

Here are even more documents: this is a map of medical device documentation showing relationships of software, hardware, and product DHF documentation and the content of a 510(k) submission:  Medical Device Documentation Map

FDA Submissions

This table, copied from the FDA software guidance on premarket submissions, summarizes the basic software documentation FDA expects in a regulatory submission.  The table divides the documentation requirements based on the safety Level of Concern of the software.  Minor LOC requires the least documentation; Major LOC requires the most.  Note that additional documentation for cybersecurity, usability, and other aspects of the product required for FDA submissions are not shown here. 

SOFTWARE DOCUMENTATION	MINOR CONCERN	MODERATE CONCERN	MAJOR CONCERN
Level of Concern	A statement indicating the Level of Concern and a description of the rationale for that level.
Software Description	A summary overview of the features and software operating environment.
Device Hazard Analysis	Tabular description of identified hardware and software hazards, including severity assessment and mitigations.
Software Requirements Specification (SRS)	Summary of functional requirements from SRS.	The complete SRS document.
Architecture Design Chart	No documentation is necessary in the submission.	Detailed depiction of functional units and software modules. May include state diagrams as well as flow charts.
Software Design Specification (SDS)	No documentation is necessary in the submission.	Software design specification document.
Traceability Analysis	Traceability among requirements, specifications, identified hazards and mitigations, and Verification and Validation testing.
Software Development Environment Description	No documentation is necessary in the submission.	Summary of software life cycle development plan, including a summary of the configuration management and maintenance activities.	Summary of software life cycle development plan.  Annotated list of control documents generated during development process. Include the configuration management and maintenance plan documents.
Verification and Validation Documentation	Software functional test plan, pass / fail criteria, and results.	Description of V&V activities at the unit, integration, and system level. System level test protocol, including pass/fail criteria, and tests results.	Description of V&V activities at the unit, integration, and system level. Unit, integration and system level test protocols, including pass/fail criteria, test report, summary, and test results.
Revision Level History	Revision history log, including release version number and date.
Unresolved Anomalies (Bugs or Defects)	No documentation is necessary in the submission.	List of remaining software anomalies, annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors.