Lean Documentation 2b

System Analysis (2) – System Interaction

In the last report we analysed part of an SOP control system for inefficiencies and opportunities for error, by mapping the system and asking ‘what if?’ at each stage.  But, as we mentioned previously, documentation systems (or, indeed, any type of control system) rarely operate in isolation.  So let’s look at some of the inputs and outputs there might be on a typical site, using the same process as before.

Step 1: Map your system -- overview

Flowcharts are less appropriate for this overview map: just use a simple relationship diagram.

First assess the inputs to the SOP system.  What events might result in an SOP update or creation?  Typical examples include:

·                SOP due for periodic review (typically every two or three years);

·                change to regulatory requirements, either external (21 CFR, ICH) or corporate;

·                change to physical system (equipment, process etc);

·                knock-on change from another document;

·                internal GxP deviation;

and so on.

These can be shown diagrammatically as follows (Fig. 1):

Fig. 1 Overview of influences

Next assess the outputs.  What effect might the changes to your SOP have?  The two most common are:

·                knock-on changes to other documents, whether other SOPs, associated forms, or just an index that needs updating;

·                new training requirements, either retraining on a new version of an existing SOP, or adding the new SOP to a training system.

The diagram now becomes (Fig. 2):

Fig. 2: Inputs and outputs

You now have a summary of interactions.  The next step is to look at these in more detail.

Step 2:Map your system – detail

Mapping the detail of the interactions means looking more closely at how the transfer of information between the different systems is managed.  On the diagram above, this means assessing the arrows.  We can revert to a flowchart for this.

Let’s assume that there is a slight change to regulations.  The process for ensuring that the relevant SOPs are updated might look like this (Fig. 3):

Fig. 3: Regulatory change

The phrase ‘become aware of’ is intended to cover the various different ways in which QA departments find out about regulatory changes.  Often corporate QA pass the message on, or the QA Manager might receive communications direct from the regulatory authorities, or check the FDA or EMEA websites on a regular basis.

As with the SOP process itself, this looks quite straightforward until you start asking ‘what if?’.

·                What if QA fail to identify all impacted SOPs?  Some SOPs are more obviously impacted than others.

·                What if the author doesn’t respond to the request for update?  This isn’t as crazy as it sounds.  If the request is by e-mail, it may be easily overlooked or deleted; if the request is via the manager at a Quality Council meeting, there’s a risk that it won’t be passed on.  What if the author receives the request then leaves, goes on holiday or off sick before taking any action?  Will s/he still remember it on (if) returning?

The flowchart now looks like this (Fig. 4):

Fig.43: Regulatory change with ‘what ifs’

The QA department will almost certainly have a follow-up system in place to ensure that the SOPs do get updated, so I’ve included this in the flowchart.

Step 3: Identify your risks

Asking ‘what if?’ identifies the risk areas in any system.  The risks in this particular interaction are perhaps lower than in some others, but the risk assessment exercise is still valid.

1.       Are there any inefficiencies?  The most likely place for these is in the follow-up system, which could itself be mapped and assessed.

2.       What are the opportunities for error?  Assuming that QA will always get the message about regulatory changes, the obvious opportunity for error is in failing to identify every impacted SOP.  The chances are that any SOPs that are overlooked will bear only an indirect reference to the changed regulation, so perhaps this risk is not as great as it first appears.

Which brings me neatly to the next step: risk assessment.

Step4: Assess risks

Once you’ve identified your risks and inefficiencies, whether within a system or in its interactions, you need to classify them according to the level of risk and the ease with which the risk can be addressed, as follows:

Level 1:            High risk/very inefficient; easy to address

Level 2:            High risk/very inefficient; less easy to address

Level 3:            Low risk/small inefficiencies; easy to address

Level 4:            Low risk/small inefficiencies; less easy to address

This will help you categorise and priorities your risks and decide on a plan of action.  Again, a diagram can help (Fig. 5):

You will obviously start with addressing those risks that are both high and easy to address (red area) – the ‘quick fixes’.  Follow this with risks in the yellow areas – high but less easy to address, and lower risk but easy to address.  You may decide not to address risks in the green area at all – it’s not cost-effective to spend a lot of effort on issues that present little risk.

Step 5:Close gaps

So now you need to close gaps.  Sometimes it’s a matter of changing the way you do things, sometimes you may just need to add a simple safeguard.  But do try not to introduce inefficiencies (more steps in a process) in order to reduce the compliance risk: this defeats the object, will introduce new risks and is almost certainly not the only way to do things.  Those using the systems (rather than their managers) often have better suggestions than those who are more removed.

Concerning the approval cycle inefficiencies in the previous report, one approach might be to bring all the managers together in one place, at one time, to sign off the SOP together.  This method is used successfully for batch documentation updates at one manufacturing site.  There are, of course, other approaches – introducing electronic workflow is one.

The risks in the system discussed in this report can be greatly reduced by good communication (so that the site, as well as QA, is aware of the regulatory change) and a simple but effective follow-up system.

Only you know what will work for your systems.