Wednesday, May 25, 2016

A "SIGNATURE" SOPBy "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.

Thursday, May 12, 2016

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).