What could go wrong?

When projects start, who knows when they will end? What do you do to go back on tract?

Each organization has its own merits and challenges. One element revealing how the organization deals with its own challenges is project management. I have been probably involved with 20 different PV organizations in the last three years and none has the same balance or approach here.

What is the main trait of the challenges the organization has with its projects?

Decision Taking.

I precisely set the tip point to taking a decision and not making a decision.

Making a decision is a process with inputs, recommendations etc.

Taking a decision is an action done by either an individual or a group.

That's where most of the organizations fail: they do not know where they really need to go.

As there's no clear heading, there's no precise direction and any road will make it. If it's a group taking the decision, everyone will have a different and somewhat strong opinion. Things will spin out of control since egos are taking over brains.

So how do you go back on track?

You have to be prepared, you have to clearly set the prospective, what a decision will require as preparation, rolling out, changes, risks and benefits. You will have to find ways to monitor and account the results.

The good way to put it, is to start by stating that it's no one fault (if the decision does not have the expected results). When putting in place a governance (giving a code of conduct to people acting under a power or a designated responsible), you need to start as when you were learning to play cards.

All faces up, no one looses or wins, every body learn.
You can do it once or twice.

Once the practice has been set, accounting can start, and as with the cards, the fun will.

Long Time

I have been very busy lately and I did not had time to write here. Shame on me.

Thru those last months, I have faced many times the same situation again: users and managers are loosing the business focus and get an IT-Database approach that is always the low road.

If you want to aim high, pharmacovigilance should always be first about business (as in business process).


As an example, an organization tried to get the events in a case re-ordered after the case was medically evaluate. The reason was they thought using a dedicated procedure capability in their software will help supporting it.

I had to detail why they were wrong. I have not detailed it from an IT perspective (the call they wanted to use was supposed to be a function and not a data updating feature), I took the business road: why is it done AFTER the medical evaluation and not BEFORE?

By putting the discussion on the right level (business) I put them back on the road they should not have left. My approach was acknowledged as the safest (audit anyone?) and the technically meaningful (updating data when you're allowed to).

I hope you will remember that the next time you talk about a software capability in your pharmacovigilance system.

B.3.1e: Interesting case

I was answering today a question on lab test result and I refer to the EMEA documentation to see what was the situation.

As often when I have to look in detail to the guidance, I'm discovering little surprises.

As you might know or not, the European MEdicine Agency is promoting guidance to use at best the electronic transmission of safety information including individual cases.

For that puprose EMEA with other agencies set forth a standard. The standard is divided in various section one of which is E2b (Efficacy guidelines section b of  to make it simple).

Each section follows a certain series of updates and the latest one is EV 7.1 (EV stands for Eudravigilance which covvers all the resources involved in monitroing health situation in European Economic Area).

The description of what you should put in the electronic information sent is very detailed and B3.1e (lab test unit) element is mandatory if lab test result (B.3.1d) is provided.

If you fail providing the two fields together, your information is rejected.

The interesting piece is that the authority gives answers thru a working group to the industry now and then (more or less every quater we have updates). Since December 2007, the answer given to one question about B.3.1 element is not compliant with the standard provided by EMEA.

The test is related to Blood Glucose and the result is increased. the working group suggests that you send it as two fields B.3.1c (test name) and B3.1.d (result) without the B3.1.e unit.

I will be amused if one tries to send this to the agency and get the case rejected. If you do, let me know.

Signal Detection Principles

"Volume 9A, Part I, Section 8 “Overall Pharmacovigilance Evaluation and Safety-Related Regulatory Action” describes the principles of signal detection and highlights the sources of information where a signal may be detected.

Signal detection procedures can range from individual case review, trend analysis of case reports to the use of complex statistical methodologies (e.g. Bayesian methods).

The methods used (including periodicity of review) should be determined, for example, by the product portfolio and the number of reports of suspected adverse reactions received. 
The MAH should, based on risk assessment, decide what signal detection methods are to be used for which products or types of products, and should document this risk assessment. 
All MAHs are expected to have in place systems and procedures for systematic signal detection that are adequately documented in formalised procedures (e.g. SOPs). 

Within this documentation it is useful to provide a definition of what constitutes a potential signal, in order to educate all personnel involved in the process and to identify what requires further evaluation. 
These documents should also provide detail about the roles and responsibilities of all personnel involved, the sources of information included in the analysis and the methods used for signal detection. 

In addition, formal written procedural documents should describe what actions MAHs intend to take based on the outcomes generated from signal detection activities. 
This could include escalation procedures following identification of a potential signal, such as further analysis that will be undertaken or referral to a company committee. 

Whilst there are no defined minimum requirements for signal detection, whichever method is employed by MAHs for signal detection, certain criteria should apply, namely: 

• The method used is appropriate for the MAH’s data set. For example, the use of complex statistical tools may not be appropriate for MAH’s with a small data set. 

• That data from all appropriate sources are considered. 
  
• MAHs have systems in place to assure the quality of their signal detection processes. 
  
• That any outputs from cumulative data review are assessed by an appropriately qualified person in a timely manner (and that the QPPV is informed of new information relevant to the evaluation of risk/benefit). 
  
• That the MAH takes timely and appropriate actions and decisions based on the outputs from cumulative data review. 
  
• That the MAH adequately documents signal detection and evaluation. 
  

Signal detection performed only at the time of PSUR production is unlikely to be adequate in most situations. 
However, for a generic substance with low numbers of ADRs (and other safety information) generated which is currently on a six-monthly PSUR cycle, this may be appropriate. 

Flexibility and Improvements

Every organization reaching a certain capability in processing reports will need to set up measures.

If you don't know what you are doing now, how will know what you'll be doing next?

It's very easy to account the reports ratio given by the number of staff you have and the number of reports you process. But this measure is very uneasy to analyze.

So now how do we handle that complexity? Pondering is the best way to go.

Every report has a certain number of data organized by categories: product, reporter, patient, etc.
Every category has structured data: Product's indication, product's dosage, patient's medical history.
Every structured data has more or less information (start/stop date partial or complete).

As you have defined the mandatory information, those are not accounted. This is key to make the measure really informative. What you're interested in are the information that will make the report more accurate, more difficult to process but more valuable for your analysis and organization. This will be the subject of our next post.

accidental exposure (with or without an AE) to study drug (non-marketed) by a non-subject

I would like to share with you this interesting topic.

Susanna Flores, Manager of Drug Safety at SuperGen asked the question and among the answers Bruce Graves Owner, Pharma GCP Support Services, Inc, Dr. Yeshpal Mathangi Clinical Data Reviewer at Clinnovo and Anuj Kapoor Medical Writer at Novartis provided great answers.

In a nutshell, this is a very rare situation, hence it won't require a SOP.

Without an AE, you should get as much as possible from the patient and supporting the investigator to make sure you collect the sequence of the event and save it into your database.

With an AE, you should report it as you'll do for events occuring during the study, making sure you clearly separate this single report from the rest of the study.

In the US, Poison Prevention Packaging Act (PPPA) administered by US Consumer Product Safety Commission is providing guidance on the situation.

CIOMS is working on the question too and Classify accidental exposure as an reportable event: Inadvertent or accidental exposure to study product with or without an ADR http://www.cioms.ch/march2008_pv_in_rpc_final_14dec2005.pdf.