Is that eQMS platform (such as SharePoint) fit for its purpose?

I saw a question today wondering whether SharePoint is suitable for maintaining a medical device QMS documents system and record control. In a nutshell, SharePoint (or whatever other eQMS practice is proposed) may or may not be suitable for maintaining the QMS documents system and record control, or for other QMS operations, depending on the case.  Here are some key points to consider when figuring out whether a computer platform is suitable for QMS purposes:

• ISO 13485:2016 (as amended; hereinafter “ISO 13485”) is intended (clause 0.1) to allow flexibility, rather than mandated uniformity, in the structure of different quality management systems.  Accordingly, ISO 13485 doesn’t out right prohibit the use of SharePoint, nor any other eQMS solution, to facilitate QMS operations.

• ISO 13485 doesn’t really allow anyone to just “believe” that an eQMS approach is unfit.  Instead, we are expected to employ an impartial scientific method whereby we validate the software for its defined intended use per clause 7.5.6, fourth paragraph.  If the software fails that process, only then can we conclude it is unfit for its purpose.  Don’t be tempted to assert unfitness apart from that impartial scientific method.

• The U.S. FDA’s eQMS software validation requirements [21 CFR §820.70(i)] reflect the same principles as described above for ISO 13485.

Don’t confuse FDA’s Part 11 with FDA’s software validation requirements of §820.70(i)

I oftentimes see narratives that state or imply that FDA’s security and integrity requirements for electronic records and signatures from 21 CFR Part 11 are the same thing as FDA’s quality system or manufacturing “software validation” requirements in 21 CFR §820.70(i) .  But these two things, though related, aren’t the same.  Specifically,

• 21 CFR 820.70(i) requires (among a couple other things) that, whenever computers or automated data processing systems are used as part of the QMS, then the manufacturer shall validate computer software for its intended use according to an established protocol.  This is FDA’s primary medical device QMS software validation regulation. As an aside, it is generally understood in the software validation community that the OQ/PQ concepts from the process validation world aren’t proper fits regarding software validation.  This is because the OQ/PQ concepts, when deployed as intended, are focused on process development and repetition which aren’t generally germane for software validation.  Indeed, if a software validation protocol employs the OQ/PQ concepts, then it’s most likely that it isn’t actually real OQ/PQ that is being done.

• Regarding 21 CFR Part 11, it’s important to remember and distinguish that its fundamental purpose is limited to, and focused on, when required records and signatures are kept in electronic format.  If so, then it demands the security and integrity controls of 21 CFR Part 11.  But two important points there:

1. 1. Don’t holistically equate Part 11’s coincidental validation requirements with the overarching software validation requirements of 820.70(i); and

   2. Remember in any event that FDA is currently employing Part 11 enforcement discretion as follows:

      1. fewer records are subject to Part 11 (FDA is only applying Part 11 if the required records or signatures are kept in electronic format instead of paper, or if one other similar condition is met);

      2. For those records that remain subject to Part 11, FDA is exercising enforcement discretion with regard to Part 11’s requirements for validation, audit trails, record retention, and record copying, yet while Part 11’s other requirements (e.g., limiting system access, use of various checks, etc.) continue to apply.