Search Site
01606 871332 | Search
26 August 2015

How Can You Validate What You Don’t Understand?

How Can You Validate What You Don’t Understand?

The truth of the matter is – like regulations themselves – industry guidelines and good practices always lag behind the technology they are intended to govern.

Regulations are generally written once something has already gone wrong – they are drafted to address an existing risk which is reasonably well understood. Likewise, industry guidelines (including the GAMP Guide and associated Good Practice Guides) and industry standards are only written once a topic is well understood and consensus can be reached on how to address a topic.

In a fast moving industry like information technology things advance much faster than regulators can think about risks or industry bodies can pull together groups to think about new topics. While the stance of the regulators is understandable – they can only observe while the implications of new technologies are understood – if the truth be told I’ve been disappointed over the time taken by some industry groups to get together and fully address some topics.

In the last few years I can think of topics such as virtualisation, Agile SDLCs, middleware/Service Oriented Architecture (SOA), Open Source Software and Cloud Computing as technology driven initiatives which have taken industry bodies years to address – and I’m talking about three to fives years, not one or two.

In the real world, real pharmaceutical, medical device and biotechnology companies adopt these technologies well ahead of the publication of regulatory and industry guidance – which can leave those of us on the compliance and validation side playing catch up.

On a number of occasions I’ve been asked to look at some new application or new technology and asked “Should this be validated?”, “How do we apply our current validation SOPs to this?” or “Is it even possible to validate this?”.

On a number of occasions I’ve scratched my head and had to go back to first principles:

  1. I need to understand what the application/technology does and how it works. Often this involves a lot of research and asking a lot of questions of the technical SMEs involved.
  2. I have to go back to regulatory first principles and ask myself “What is the real risk here, what are the consequences and how likely are they?”. I also need to relate back to earlier regulatory observations or enforcement actions where the underlying concerns and principles have been similar.
  3. I need to find a way in to the problem… Generally I’ll find a similarity to something more common or an analogy with something well understood and accepted, something that I – and more importantly – other people can relate to and understand.

Once I’ve figured that out we can start to develop an appropriate risk-based qualification or validation approach , with a well documented rationale for the approach being taken.

In many cases that will require extensions to or expansion on existing SOPs, to interpret the IT QMS in a context that fits the new application or technology. In some cases parts of the IT QMS will need revising. It can be a challenge to get this done in appropriate timescales to suit the needs of the project, but generally it can be done.

I see my roles as an enabler – it’s my job to find a way to say “Yes we can, if we just…” rather than “No, our SOPs don’t allow it”.

I can only do that if I understand what I’m being asked – and this is where we all have a duty as CSV / IS Compliance professionals. It all comes down to keeping abreast of new technologies and understanding what’s really happening in the world of IT, rather than hiding behind guidance that is always going to be behind the curve.

Back to Blog

Keep up to date