Software V&V "In Brief"

To summarize:

0.  Download FDA SW Guidance documents, especially: 

"Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices", and obtain / generate / group documentation per Table 3 (for all SW V&V, not just devices / 510(k)s:

https://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm089543.htm

1.  Establish risk to patient by your company's / product's activities addressed by the software (Level of Concern, ISO 14971/ FMEAs...);

2. Develop a Project Plan (phases, milestones, tasks ...; timelines; responsibilities; I prefer the Gantt chart done on a spreadsheet); 

2.  List all your requirements for the software (the SRS), including applicable 21 CFR 11 (e-records / e-sigs); and cybersecurity if networked (especially firewalls, training to prevent opening unknown links, etc). 

3. Write an introductory narrative explaining the system and your validation approach; Write test cases to address all the requirements, e.g., IQ (for installation / hardware meets software rqmts ...), OQ (all software modules exist and initialize and shut down properly; 21 CFR Part 11 issues, especially limited access, audit trail / change history, names tied to files, date / time stamping, and cybersecurity (if networked), ..., PQ to repeatedly challenge key operations, especially addressing "allowable worst case" variables (I usually have one PQ for each allowable variable, e.g., 24/7 shifts(if that's what's used for this product's routine production = 1 (or more) PQ for day, 1 for swing, 1 for night, 1 for weekend/Sunday, and 1 for next holiday (the PQ test cases are the same, only the shift changes for each PQ); if validating software used by the company on different hardware platforms, use 1 PQ for each hardware platform / operating system, e.g., 1 PQ for an I phone, 1 for an Android, 1 for an I Pad, 1 for a Windows Tablet, and so on.

4.  Extract proofs for each test case from retroactive files (for preexisting systems); perform any additional test cases proactively (or all for new or remodeled systems);

5.  Compile all the above and other documentation (11 categories) into a Test Report / SW V&V File, and sign off.  Most documents can be generated in a word processing app.  Initial /date any copies.

jel@jelincoln.com

Updated 10/20/2021; 09/06/2023

See also entry of 05/23/2022 on Requirements Validation. 

The Guidance Document on software and 510(k) submissions has recently been revised - among other changes there are now only 10 categories. - JEL 09/19/2023

Risk vs. Risk

RISK  VS. RISK

"Risk-based ...", a source of confusion to the medical products industries.

Some say this should be a generalized approach throughout a company. This is partially correct.  If a company is primarily addressing ISO 9001, then they are focused on ISO 31000, Risk Management, which addresses all manner of business risk.    

   

However, if we are dealing with medical products, the U.S. FDA wants to see “risk” tied specifically to to patient (and user) risk. The recently revised ISO 14971:2019 requires the patient risk be considered in all applicable company's QMS systems.  

I have always recommended that companies tie such key medical product risk-based decisions to a Product Risk Document -  ISO 14971 Risk Management File / Review, or ICH Q9 file;

     -  Cite specific line items, e.g., from a FMECA;

     -  Include “Normal” as well as “Failure / Fault” in Hazard List / FMECAs.

“Risk” in FDA-regulated industries usually means patient risk, not business, IT, legal, etc., risks, though some are obviously tied together.  If you are marketing medical products both in the U.S. and EU / overseas, then your documentation will have to clearly address both types of risk, product / patient, and business.

ISO 14971 patient risk / safety vs. ISO 31000 business risk / financial risk / schedule risk / compliance risk / “safety”, et al.

Understanding such patient “risk” will determine how far to proceed on test cases, failure investigations / root cause analysis, degree of documentation, etc., needed to resolve a medical product risk issue.

Additional references:

"Pharmaceutical cGMPs for the 21st Century - A Risk-Based Approach", September 2004: 

"FDA has identified a risk-based orientation as one of the driving principles of the CGMP initiative.  The progress outlined below reflects FDA's commitment to the adoption of risk management principles that will enhance the Agency's inspection and enforcement program, which is focused on protecting the public health."  (bottom paragraph, page 3; emphasis added).

 - https://www.fda.gov/media/77391/download

John E. Lincoln        jel@jelincoln.com

Updated 05/23/2022; 06/20/2022

ISO 14971:2019 in its Introduction defines risk as 1) Patient risk; 2) User (clinician ...) risk; and/or 3) Use environment risk. - JEL 02/06/2023  

ISO 14971 is risk management for devices (and the device's QMS); ICH Q9 is risk management for drugs. Recently, the FDA has also used "risk" in the context of security risk, especially related to cybersecurity issues, but even here the emphasis is on patient safety. - JEL 09/06/2023 

... and CGMP compliance risk, which also emphasizes people risk. - JEL 10/20/2024