A  "SIGNATURE"  SOP

By "Signature SOP", I mean an SOP (Standard Operating Procedure) that defines what it means when a person signs their signature or initials on a document.  E.g:

o  An engineer signing for the engineering function, is only signing for the engineering portion of the document;

o  Marketing is only signing for approving marketing issues in the document;

o  Ditto Finance, Manufacturing, Operations ...;

o  Senior management is signing that the document meets company requirements and address the issues, based on reliance on the other signatures by function; and

o  QA is signing that the signatures are the latest after all iterations, that all elements mentioned in / required by the document have been addressed by the proper individual(s) / function(s), etc.


People have a hesitancy in signing a document dealing with subject matter they are unfamiliar with, may ask for unnecessary revisions, want additional clarification.  They are rightly concerned to be signing and "agreeing" to something that they don't understand, together with what they are involved with on the document.  

So such an  SOP would clarify what each functions' / individual's signature really stands for, and what it doesn't, and can assist in:
     1) getting the signatures, 
     2) defending a signature in an audit, and 
     3) defending a signature in court.

-- John  E. Lincoln, jelincoln.com

RISK  ANALYSIS

There seem to be several definitions of risk analysis, left unstated, in many on-line regulatory discussion threads, which can lead to incorrect focus and improper direction.   

The most important from a regulatory standpoint, either US FDA or EU MDD, et al, is product risk to the end user, the patient / clinician. For devices this is ISO 14971, for pharma it could be ICH Q9, which could include the d-, p-, and u-FME[C]A as well as other complementary methods recommended in those standards. 

IN ADDITION, a project leader may want to do risk analysis tied to project success, meeting budget and time deadlines, customer delivery commitments, etc. But those would be business / financial-related risks not the ones regulatory agencies mandate. And as mentioned, the earlier the better.  

So such risk analysis if performed on equipment would still have to trace any failure modes, malfunctions, or even correct functions that could cause problems, through to their effects on the end user / patient / clinician (an omission often cited for the disadvantage of using FME[C]A for patient / user risk analysis, although such can be compensated for by definitions and/or structure of such).

-- John E. Lincoln, jelincoln.com