Standards: Incidents and Deviations

This short post is more of a footnote to an earlier post about Incidents, Problems and CAPA.

A colleague mentioned to me that he saw no real difference between Incidents and Deviations, because they are just different terms for unplanned events, one is an ITIL derived term and the other used more in the Life Sciences industry.
Without thinking too much I agreed, but then I started to ponder if this was really the case; it seemed to me there was a difference.

A deviation is an event that is contrary to an expected result or an incorrect operation; normally the event is a deviation from something stated in a plan.

An incident is an just event, but does not have to be a deviation; an incident is usually based on something in a procedure.

An example of incident that is not a deviation could be:
You may have a performance management procedure that states the system is configured to send an alert email when disk space drops below 10% free. When this happens, the email is sent and this is an Incident, but this is not a deviation, since it is an expected operation of the system.

However, in ITIL version 3, we have the "Request Fulfillment" process, which is designed to describe these incidents-that-are-not-deviations (as I have discussed previously), so maybe there really is no difference...although I still feel there is.

Standards: Incidents, Problems and CAPA

An analysis of FDA Warning Letters issued over the past few years shows some recurring themes (see previous posts). One of these that consistently stands out is the regulations cited more than any other; 21CFR Part 820.100 Corrective and Preventive Action closely followed by 21CFR 820.198 Complaint Files.

In this blog I want to highlight what CAPA is, and also place it in the context in terms of Incident Management and Problem Management, alongside Complaints.

Incident Management and Problem Management

ITIL has a clear explanation of Incident and Problem Management and the difference between them. It goes like this; consider the following analogy:

Every city has a stretch of road where accidents seem to occur on a regular basis; so called “accident black-spots”. When an accident happens, the police are usually the first on the scene, quickly followed by other emergency vehicles as required: ambulances, fire, tow truck, etc. The first order of business is to attend to the injured. Next is to get the traffic moving again.

This is the essence of Incident Management; it is reactive and looks for an immediate, short-term solution.

Somewhere, people are gathering information and analysing that accident, what may have caused it and how it may relate to other accidents which occurred along that same stretch of road. They analyse, among other things, traffic patterns, the time of day, weather conditions at the time, road signage. From this analysis, they seek to determine the ROOT CAUSE of the accidents and thus find a means of preventing accidents.

This is the essence of Problem Management; it is proactive and looks for a permanent solution to prevent further incidents.

Corrective and Preventive Action

FDA Guidance says the following;

Corrective action is a reactive tool for system improvement to ensure that significant problems do not recur.

and...

Being proactive is an essential tool in quality systems management. Succession planning, training, capturing institutional knowledge, and planning for personnel, policy, and process changes are preventive actions that will help ensure that potential problems and root causes are identified, possible consequences assessed, and appropriate actions considered.

So the focus in these activities is to find root causes and ways to stop problems happening in the future, rather than righting what has happened in the past.

It is important to understand that CAPA is not an Incident Management process - CAPA is all about Problem Management; it is the same as ITIL Problem Management, with both reactive (triggered by incidents/failures) and proactive (triggered by other sources) activities.

The Incident Management process is essentially addressed by the "Complaint Files" regulation for medical devices (and others focussing on manufacturing incidents and adverse events). Perhaps this is a source for the large volume of citations for violation of these regulations; companies lack an understanding of the interface between Complaints (incidents) and CAPA (problems), which is much easier to understand when viewed from the ITIL framework.

GAMP Honorable Mention

As a footnote to this, it is worth mentioning that GAMP4 did not really address either incident or problem management. This has been corrected in GAMP5 with the addition of the Operational Appendices O4 Incident Management and O5 Corrective and Preventive Action. Note how GAMP employs language recognisable to IT stakeholders (incidents) and regulatory stakeholders (CAPA), bridging the gap of understanding that may have existed before.

Solutions: Implementing ITIL methodology

ITIL is all fine and dandy in concept, but often implementing the processes can be cumbersome and expensive. Where do you start? All those processes that overlap and integrate...

Well I found a really useful and easy to use solution; ServiceDesk Plus. Now I do not work for or have any affiliations with this company and I don't get anything for plugging the software. I just think it is actually a good product. I'm no technical expert, but even I could download the free trial to a Linux desktop PC and install and have it up and running in less than 30 minutes (and Linux is not the easiest system to do that with).

So have a look and try it out.

Standards: ITIL v3...any good?

So ITIL v3 is in the wild. Has been for a while now. Is it any better than ITIL v2? Does it say anything new? Is it actually usable?

I think ITIL v3 is like Windows Vista...everyone had grown to love and understand its predecessor when a new shiny version comes along that really doesn't deliver anything spectacularly new or useful and has no compelling reason to be used. There's nothing wrong with the old version.

So why does it exist? Well, first let's look at the driving forces behind ITIL v3; consultancy companies. Accenture and others seems to be a major player in this, having co-authored a lot of the content - just look at the first line of the first book of ITIL v3:

"How do you become not optional?", William D. Green, CEO, Accenture

Can anyone say "Shameless promotion"?

Who will most benefit from a new ITIL version; I might suggest that certain consultancy companies who provide ITIL training and advisory services might have a lot to gain from a new ITIL, just when everyone was getting to grips with v2 (and hence not really needing those consultancy services anymore). Conflicts of interests?

So, maybe a cynical answer to Mr. Green's question is:

"You reshape the established system to your own design so everyone has to come and pay you to explain how it works." Brilliant.

Here's an example of this:
In ITIL v2 we had Incident Management and we had Problem Management.
Now we have Incident Management, "Request Fulfilment" and Problem Management.
What is this new and strange process? Well it is management of "routine" incidents or Service Requests (examples given in ITIL are "...e.g. a request to change a password, a request to install an additional software application onto a particular workstation, a request to relocate some items of desktop equipment...") .

By the way, it then goes on to say a few paragraphs later
"Note, however, that there is a significant difference here – an incident is usually an unplanned event whereas a Service Request is usually something that can and should be planned!"
So how exactly do you plan for someone forgetting their password and requesting it be changed?!

Well, I thought these events were covered just fine in v2 by the service management and incident management processes; you just use appropriate categorisation of an Incident as a Service Request. But here they have split a hair and come up with a whole new chapter of waffle.

OK, there is some extra stuff there that is useful, even if "borrowed" from existing standards - Access Management is one useful addition (ISO17799 anyone?). But seriously, was there really a need for an whole number increment of ITIL - I don't think so. Adding to and popularising ITIL v2 would have been fine.

How many books are there for ITIL v2? Two I hear? What, just Service Delivery and Service Support? What about the Application Management, ICT Infrastructure Management and Planning to implement Service Management books? There are FIVE books that comprise ITIL v2 - who use those last 3?

So in summary, I think ITIL v3 exists because ITIL consultants wanted it rather than IT managers wanting it. Use ITIL v2 and don't worry about certification - you need ISO 20000 certification anyway, so use ITIL v2 to inform your choices on how to be ISO 20000 compliant.