Software in Medical Devices, by MD101 Consulting

To content | To menu | To search


Computer Software Assurance for Production and Quality System Software

That's a bit like a new album of your favorite group. You've been waiting it for years. At last, it's been released! Are you going to be be impressed or disappointed?
The draft FDA guidance on Computer Software Assurance [CSA] for Production and Quality System Software has been published in September 2022. At last!

Scope and purpose

First, this guidance is neither about Software as a Medical device (SaMD, a.k.a. standalone software medical device), nor about Software in Medical device (SiMD, a.k.a. embedded software).
This guidance in about software in used in QMS processes and production processes. It addresses 21 CFR 820.70(i) requirement. From an ISO 13485 perspective, it addresses clauses 4.1.6 and 7.5.6.

The reason why this guidance has been published is explained in the Background section. The use of software to automate the realization or the monitoring of processes is quite common. The FDA felt the need to supplement the section 6 of the existing guidance on General Principles of Software Validation (GPSV). It's true that this existing guidance, published in 2002 suffers of its age. It is a bit vague on the validation process to establish. Manufacturers had to rely on other guidance like AAMI TIR 36 or IEC/TR 82002-2 to define their QMS software validation procedures.
Even though the draft FDA guidance brings some new recommendations, the AAMI and IEC guidances are still useful. We can view this draft guidance as a complement of information on how to validate QMS software to be in line with regulatory requirements.

Similarities with medical device software

This CSA draft guidance works pretty like medical device software guidance. It requires:

  • An intended use,
  • A risk-based approach, like in the Content of premarket submissions for device software functions draft guidance,
  • A modular approach, like the Multiple Function Device Products: Policy and Considerations guidance,
  • And a testing strategy resulting from the two above, like the GPSV guidance

Intended use

That's where all begins, like medical device software (MDSW).
You can use a QMS software to record your recalls and only rely on it. But you may continue to have hardcopy records, using that software only to have a convenient workflow. Same software, different intended uses, the CSA approach will be different as well.

Logically, the draft guidance also states that 21 CFR 820.70(i) doesn't apply to software, which is neither directly used in, nor supports production production or QMS. Namely software outside the scope of your QMS.
Surprisingly, the draft guidance quotes software intended to support business continuity as such software. Beware about that example! If the same software supports business continuity and record retention, then 21 CFR 820.70(i) is applicable.

Risk-based approach and modular approach

The new recommendations (not so new, the way of thinking is already applied by manufacturers veterans in QMS software validation) stem from a risk-based approach. This risk-based approach is based on the intended use of the software.
We can see here a similar approach to the one we have for medical device software in the draft guidance on content of premarket submissions for device software functions; a twofold approach (emphasis below from FDA):

  • High process risk software: Software used directly as part of production or QMS,
  • Not high process software: Software used to support production or QMS.

Note that the wording low risk isn't present in the guidance.

This looks like what we have in gestation for medical device software, a twofold approach based on the intended use of the medical software function:

  • Basic software documentation level, for low-risk medical software function,
  • Enhanced software documentation level, for high-risk medical software function.

We can see here a new paradigm (or a new fashion) appearing with this binary approach to all kinds of software by the FDA.
Exit the major / moderate / minor levels of concern!

Reasonably foreseeable risk

The draft guidance also insists on the way risks should be managed. Organisations should consider which failures are reasonably foreseeable (as opposed to likely). We see the difference of treatment between medical device software risks, versus production or QMS software risks.
To say it (a bit too) short:

  • Every medical device risk shall be treated seriously, hence they lead to direct (or indirect for SaMD) harms to patients,
  • Production and QMS risks can be taken with more flexibility when they aren’t reasonably foreseeable,
  • Production and QMS risks shall be taken seriously, when they are reasonably foreseeable and result in the potential to compromise the production or the [QMS].

A similar approach with severity and frequency, borrowed from ISO 14971, can be taken to assess production or QMS software risks:
Taking QMS / produbtion software failure as the initial step in the sequence of events, we can draw several sequences of events depending of the intended use:

With QMS software:

  • Sequence
    • Data Corruption / Loss Re. Process (records, traceability…) E.g.: loosing archived batch records
  • Consequence
    • Regulatory non-conformity


With production software:

  • Sequence
    • Production data Corruption / Loss E.g.: labeling, control card
  • Consequence
    • Product non-conformity or production process non-conformity


Or service support software:

  • Sequence
    • Data Corruption / Loss Re. service (service interventions, complaints…) E.g.: not treating complaints
  • Consequence
    • Service process Non-conformity and possibly missed adverse event

Mitigation action outside software

The draft guidance also makes use of the principle of mitigation action to decrease the QMS / production software risk profile.
No need to have a hardware mitigation action in place, like in most of software embedded in an electromedical device. Some additional controls or mechanisms can be implemented, provided that they are effective. For example, human awareness or review is accepted (provided that operators are trained and so on, this is another story).
This is similar to the type of mitigation action accepted by clause 4.3.a of IEC 62304:2006 + Amd1:2015.

Modular approach

It is possible to split software into several modules, features or functions. Each function may have a different intended use, with a different risk profile. The guidance gives an example with a spreadsheet. I find the example of an ERP more handy. An ERP has several modules. Some are not QMS software (accounting). Some are QMS software with various functions, like a CRM module. If this module is used to manage customer complaints, some high risk profile is expected for the subset of functions managing customer complaints. But not for functions managing other aspects of CRM.
This logic is similar to the Multiple Function Device Products: Policy and Considerations guidance.

Bespoke software

The draft guidance contains nothing clear about bespoke software; namely software internally developed or outsourced to a software development firm.
You won't find a word about design qualification, a step often found in QMS software validation procedures. A practical solution for bespoke software it to follow a software development lifecycle similar to IEC 62304 class A.

Expected records for high-risk software

The draft guidance gives some examples for high-risk and not high-risk software. High risk software records list looks quite similar to what is expected by clause 5.7 of IEC 62304.
Some differences, however, are present for not high-risk software. The FDA accepts some reduced of even very abbreviated test plans and test reports. They use the wording unscripted testing, something disallowed by IEC 62304.

The draft guidance also contains a discussion about types of testing strategies. No worries if you don't use them. It's quite common to use robust scripted testing for high risk, limited scripted testing for moderate risk and unscripted testing for low risk software. These testing strategies are there for information.

No IQ/OQ/PQ!

You will not find these concepts in this guidance. No need to disguise your software validation process in a tweaked IQ/OQ/PQ process, commonly used for hardware equipments! Most of validation procedures make use of this IQ/OQ/PQ artefact. It is an easy way to make software-illiterate auditors happy (that kind of beast tends to disappear).
Thanks to this FDA guidance, we can do a plain old Software test plan and a software test report, getting rid of this IQ/OQ/PQ behemoth!

21 CFR part 21

The draft guidance reminds the reader that some data (most of data) treated / stored by QMS / production software are electronic records according to 21 CFR part 11. The guidance doesn’t give any cue on hiw to validate software functions in the scope ot part 11.
I suggest to take that seriously and not hesitate to put some effort on part 11 validation protocol (using robust script testing and a detailed traceability matrix to part 11 requirements), despite the least burdensome approach claimed by the FDA.

Conclusion

We have a clear least burdensome approach in this draft guidance! The previous GPSV guidance left the manufacturer in an unclear situation about the extent of validation to perform with various QMS / production software risk profiles. And the AAMI TIR 36 or IEC/TR 82002-2 didn’t give the FDA view.

With this new guidance: we know we can pull the brakes on low-risk software, and use the two other guides as a source of information on how to validate high-risk software.



Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed