SDLC Quality Gates: Saving you time in your SaMD certification

In many industries, the cost of software-related defects grows exponentially with each phase of the Software Development Life Cycle (SDLC). Software manufacturers are encouraged to “shift-left” to unearth and resolve defects earlier in the SDLC and avoid lengthy, unexpected delays and rework later in their projects.

In Software as a Medical Device (SaMD) development, this phenomenon is exacerbated by the burden of accurately and comprehensively documenting SDLC activities within a technical file that must be made available to a Notified Body for review and approval. This means that on top of software defects, SaMD manufacturers must also contend with software documentation-related defects.

In some cases, these defects are discovered during the manufacturer’s software verification or validation testing activities. This can cause technical file and software rework, which lengthens the road to an SaMD certification. In even worse scenarios, documentation-related defects are only discovered later during the assessment process by the Notified Body. If these defects are severe, they can invalidate already conducted regulatory activities and can require the manufacturer to undertake a substantial amount of costly rework prior to re-assessment by the Notified Body. 

Fortunately, these defects can typically be avoided with more robust internal quality reviews prior to assessment.

Why software verification is a key phase for quality-gate review during SaMD development

The Medical Device Software Development standard, IEC 62304, promotes flexibility in the manufacturer’s choice of SDLC model. The standard describes how a classic waterfall SDLC, or more modern evolutionary SDLC models, can each be applied in the development of medical software. The flexibility to use evolutionary SDLCs can be beneficial to a manufacturer as they can quickly iterate on drafts of technical documentation, software code, and informal software testing. This allows them to unearth and resolve software and documentation defects early on in the SDLC.

However, the guidance in IEC 62304 aims to ensure that robust, safe software development practices are still respected within this flexible framework. As such, it dictates that the manufacturer must implement a comprehensive configuration management system that maintains the logical dependencies between software development processes and artefacts, irrespective of their chosen SDLC.

The statements below, inferred from the IEC 62304 text, implicitly place the software verification phase at a key juncture in the SaMD SDLC, where a quality-gate review is most beneficial to the manufacturer.

1. Software code must be brought under configuration management control prior to engaging in a related software verification activity. Subsequent modifications to the software configuration are subject to a documented software change management process.
2. All relevant software development process outputs (e.g. software design input documentation relating to risk analysis, risk controls, requirements, design and verification methods/specifications) must be brought to a consistent state to be available for conducting the software verification activity.

In summary, the development team is free to iterate on drafts of software design input documents, software implementation, and informal testing during the early phases of the evolutionary SDLC, thus keeping the cost of remediating defects relatively low. However, in order to execute a software verification activity, the manufacturer must first reconcile all relevant technical file documentation and software code to establish a controlled, consistent, and traceable baseline of artefacts. Any documentation or software defects discovered during, or after, this SDLC phase will then carry the burden of documented software problem resolution and software change management processes. Thus, the remediation efforts for these defects increase dramatically.

Catching and resolving as many defects as possible prior to software verification will significantly reduce the risk of unanticipated, additional effort later in the SDLC. So, how can this be achieved?

An effective strategy is to schedule a quality-gate review prior to executing a software verification activity. This review aims to evaluate the relevant baselined technical file documentation and software code, correct any defects, and confirm the team’s readiness to successfully verify the software implementation.

How to conduct a quality-gate review for software verification readiness

A large percentage of software-related defects that are commonly discovered by Notified Bodies during assessments can be traced back to inadequate quality-gate review prior to conducting software verification activities. Examples of these include:

• Inadequate software risk analysis or definition of software-implemented risk controls
• Incorrect software safety classification
• Ambiguous or untestable software requirements description
• Insufficient definition of software requirements
• Inadequate description of software architectural or detailed design
• Inadequate software verification methods
• Mismatch between software requirements acceptance criteria and software verification results
• Insufficient or missing tracing between software requirements and software verification results
• Software verification results that do not adequately verify the effectiveness of software-implemented risk controls

To avoid some of these common missteps and conduct a robust quality-gate review for software verification readiness, perform the following tasks prior to executing any software verification activity:

1. Review and evaluate the relevant baselined technical file documentation.
   • This is inclusive of documentation artefacts such as: software development plans, software integration plans, software verification plans, software risk analysis, software risk controls, software requirements, software architectural design, software detailed design, software verification activities, and verification test specifications.
   • The criteria for evaluating each documentation artefact are outlined in the latest international standards for SaMD product development (e.g. IEC 62304 & IEC 82304). For examples of good software requirement evaluation criteria, see our previous blog posts (here and here).
2. Review and evaluate the baselined software code to ensure that all software items have been implemented in accordance with the software development plans and the relevant software architectural and detailed designs.
3. Perform informal execution of the relevant verification test specifications to ensure that there will be no unexpected defects discovered during the software verification activity.

Time well spent

These quality-gate review activities can themselves be time consuming to conduct. However, it is advisable to have planned allocations of time within a software development project so that baselined versions of documentation and software code can be adequately critiqued early in the SDLC.

This approach to software development management is more efficient and predictable than rushing through development and verification only to face unexpected delays when defects are discovered during the Notified Body assessment.

It is a worthwhile investment of time and effort that provides a more predictable route to SaMD certification.