Wednesday, June 28, 2017

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 Excel); 
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 ..., PQ to repeatedly challenge key operations;
4.  Extract proofs for each test case from retroactive files (for preexisting systems); perform any additional test cases proactivel (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 Word.  Initial /date any copies.

jel@jelincoln.com

Tuesday, June 6, 2017

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 want to see “risk” tied specifically to to patient (and user) risk.

I have always recommended that companies tie such key medical product risk-based decisions to a Product Risk Document -  ISO 14971 Risk Management File / Report, or ICH Q9;
     -  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 / “safety”.

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."  (emphasis added)
 -- https://www.fda.gov/drugs/developmentapprovalprocess/manufacturing/questionsandanswersoncurrentgoodmanufacturingpracticescgmpfordrugs/ucm137175.htm#_Toc84065737 

John E. Lincoln        jel@jelincoln.com