Computer Systems Validation Part 3 –
Roles and Responsibilities

In this post, I will be discussing the roles and responsibilities for Computer Systems Validation (CSV) – who should own it, who should be approving, who should be kept in the loop, and who ultimately does the work. It is critical to success that the roles and responsibilities are clearly defined and understood.

This progression of roles (Owner – Approver – Notified – Doer) is often seen as suggesting a sliding scale of seniority and inverse responsibility – i.e. the Doer has the ultimate responsibility.

Where the progression is correct for seniority, it is completely back to front in terms responsibility – i.e. it is the System and Process Owners who should be most responsible for the activity.

I was lucky that for many years I had a senior manager who recognised and understood the importance of CSV, would support and champion the Doer work I did without overt interference, and would actively promote what I was doing around the organisation.

But I have seen and spoken to enough CSV practitioners over the years to understand how often they feel largely alone – or at least will be the one singled out to carry the can if the project goes awry.

In order to understand what I mean by those O-A-N-D roles, the following people should typically be the ones that sit in these categories:

Computer Systems Validation - Owner

O – Owner

Owners can come in 2 flavours: System Owners and Process Owners. And they are not always the same thing.

For instance, a Warehouse Manager may own Distribution and Stock Control Processes, but the System used for these processes may be for instance owned by a Planning or Operations Manager.

So, who is ultimately responsible for the project? The answer is rather glibly, both of them. However, were an auditor come to call, they would most likely talk to the Warehouse Manager about the processes. Consequently, the role of the System Owner in this example is to ensure that the system is correct so that the Process Owner can do their job correctly – so in the true sense of the word “owner”, it is at the system-level we should look.

Computer Systems Validation - approver

A – Approver

Approvers are really anyone who needs to put their name on the documents against the exercise at some or all of the various validation stages.

Approvers would always include the System and Process Owners, often an IT representative, maybe Subject Matter Experts, a validation expert, and at least one Quality representative.

As “checkers” they should be trained and competent to understand what it is they are signing for.

However, caution should be applied when presenting the approvers with huge stacks of documents to check before approval. Not in the sense that they should not receive the documents when required, but more that it is good practice for the Validation expert to go through the documents with the Approvers, explaining what it is that was done and what each of the tests and results mean using language suitable for the individual to understand.

This will avoid the Approvers just signing their names without properly reviewing/understanding (or indeed not looking at the documents at all).

Computer Systems Validation - Notified

Image by Freepik

N – The Notified

Others may need to be kept in the loop – senior managers, functional area managers, other SMEs, Purchasing / Procurement staff, and potentially further IT representatives etc.

Crucially a vendor may well fall into this category and should not be forgotten!

D – Doers

These are the CSV experts and the users / SMEs who will be performing and executing the qualification activities.

Note: especially in smaller organisations / organisational functions, some individuals may fulfil two or more of these roles. This is not a problem.

So, who should be involved in the Validation Activities, and when should they get involved?

The answer is of course everyone and at Day One.

The obvious problem here is that the reality does not often meet the ideal.

All too often the process goes as follows:

  • A function decides it needs a new electronic system. This is Day One.
  • The manager of that function goes to Senior Management and gets agreement in principle they can have that system. And here is the budget.
  • If they haven’t already, the functional manager then goes out and finds a vendor who states they can provide what the company is after based on a verbal discussion. Because of course they can. Great!
    • All too regularly however this step has already occurred prior to Day One…
  • The vendor goes off and after a period of time turns up with the software to demo it. This is the point that the SMEs may get involved.
  • The Vendor arrives a short period of time later and installs the system. This is the point the end users, Validation and Quality get involved. This by all definitions should be the point of Go Live. Except the software doesn’t really do what we want. And yet again Quality Assurance says NO.

No-one is really to blame for any of this. Everyone is doing what they think is right for their needs and view of the business.

So, let’s break this down a bit and discuss what might be a better way of proceeding:

Day One

So someone needs a new electronic system. There is a business need for it and typically, new systems are included in a company’s capital expenditure plan.

But a process needs to be in place to ensure that everyone is aware that there are steps to take before it goes to management. A set of ‘Day Zero’ actions if you will.

Firstly, a User Requirement Specification (URS) needs to be drafted. This must be compiled with the relevant people, which as a minimum should be the process owner and SMEs, an IT expert / representative, and a validation expert. I have described what I believe the most effective role for each of these individuals later in this article.

I will discuss the URS in more detail in the next article but it important to remember that although vendors can be involved at this stage to assist with specific technical wording and content, they should not be the main contributor defining your requirements.

Additionally, it is important to remember that the IT function should not be the ones responsible for writing the URS; unless they are the functional owner of the system – and even then I personally would be very tempted to have someone else review the wording they have used…!

Note – I have not made any mention of GxP up to this point. This is not an oversight.

I will state repeatedly that good practice should not be exclusive to a regulated system, so the principle of having clearly defined and understood requirements should be universal for all systems.

Of course, identifying if the system has an impact upon GxP – either directly or indirectly – absolutely needs to be performed, and all specific regulatory requirements need to be included in the URS.

And if the system is defined as GxP, it HAS to be validated. This too is non-negotiable.

The definitions for what is considered a GxP system will vary slightly in precise wording between which guidelines you read, but they will essentially boil down to the following YES / NO questions:

  • Does the system generate, manipulate, or control data supporting Regulatory Submissions?
  • Does the system control Critical Processing Parameters (CPPs) or associated data used at any stage?
  • Does the system provide data for Product Release?
  • Does the system control data required in case of a Product Recall?
  • Does the system control Adverse Event or Complaint recording or reporting?
  • Does the system support Pharmacovigilance?
  • Does the system manage any other GxP data or processes? (bit of a catch-all at the end!)

I have highlighted the important words here in bold, and these criteria can be used subsequently as part of the Risk Assessment.

If the answer to any of them is YES, then validation must be performed.

Once the URS is agreed, it is at this point that approval for the system can take place and vendors agreed.

Project Start

Usually by this point a vendor has been chosen – and I will talk about vendors in a later article. I have quite a lot to say on the subject…

At this time there should be a project team (formal or less so – it depends on the project), including all the relevant individuals.

This team really has to include the functional SMEs, the validation SME, a Quality representative, potentially an IT representative, and crucially the vendor when selected.

Under the guidance of the Validation expert, the team can then perform the Risk Assessment, create the Validation Plan, and work with the vendor on the system implementation.

So, who should be doing what in this team?

Functional SMEs

Typically, the Functional SMEs are also likely to be end users, and so you would hope that they are the people that know the role inside out and would know exactly what is needed for the job.

But, be mindful that these users may be a little stuck in their ways and may not be as open or receptive to a new system or new processes that a new system may bring. Just because a process works in a certain way now, does not mean that will translate well to a new system, or that that is how it should work going forward. Managing Change here is important.

The functional SMEs will be the people who define the system functional requirements and should be the individuals who are involved performing the functional testing at all the stages.

Quality Representative

The Quality Team will always need to be onside and engaged. This not only includes managing any formal Change Control for the implementation, but also ensuring that the associated organisational quality processes, and the regulatory processes are followed.

In my experience the Quality Representative will want to understand everything before signing anything. Be prepared for some in-depth dialogue.

IT Representative

An IT Representative should always be part of any team created for the introduction of an electronic system.

This may be difficult for smaller organisations who may not have a dedicated IT resource and maybe use an external third party for this purpose.

Either way, it is important that someone with enough IT knowledge is involved because even if the system is being hosted on a cloud server, there will always be technical questions regarding the system and hardware requirements, servers, services, GAMP Level 1 applications, organisational standards etc.

However, as stated before, do not let the IT representative write the whole of the URS. They are not the functional process experts, and they will often use language that may be technical and not fully understood by the rest of the implementation team.

The Vendor

As I have said, I will go into vendors in some detail in a future article. But for now, let us just state that it is crucial that we work collaboratively with the vendors and use as much of their knowledge and expertise as possible.

Validation SME

The Validation expert is the person who will be generating the paperwork, organising the validation effort, and the person who often has to explain the validation concepts to others who are unfamiliar with the processes involved. They may also aid in the testing.

As you are reading this with (hopefully) an interest in CSV, it may well be that you fall into the category of the Validation SME. You will need to be the proverbial Jack of All Trades and understand ALL of the other roles, as well as having to perform a number of additional roles, not least of which is a new previously never considered position of “The Translator”.

The Translator

Bringing together a diverse group of individuals from different areas and skillsets can in itself be problematic and create unforeseen issues.

For example, let us look at a URS creation:

  • The SMEs / Users will create a list of functions that they require. These will often not be written in a technical manner, but will be in the form of a ‘brain dump’
  • The IT department will add their requirements using technical jargon and often shorthand terms
  • The Quality department will add regulatory requirements using wording they understand, often lifted straight from the legislation
  • The vendor will finally contribute very application-specific or terms they are comfortable with using

The problem here is that all the individuals are to a greater or lesser extent speaking in different languages (and in some cases this can be literal – where the vendor does not have the same first language as everyone else). And without full understanding, there will be problems.

So, the role of the Translator falls to the validation expert as they are placed in the middle of the different groups and becomes a vital cog in the machine for success.

I will discuss this further in the article on User Requirement Specifications.

A final note here should also be added regarding Senior Management. They sit as part of the ‘Notified’ group – i.e. the people who need to be kept in the loop. The are not the Owners, they are not the Approvers, and they are very much not the Doers.

And they 100% need to be kept in the loop and leaned upon when required. But remember, however much they may like to think otherwise, it is quite likely they are not experts.

Beware the over-important senior manager who gets over-involved and makes rash or downright bad decisions based on incomplete or incorrect understandings. So many projects have stuttered, struggled and even failed due to bad decisions being made for the right reasons.

Another job then for The Translator to reinforce understanding across the wider team…

Note: there are of course others who may be involved in specific circumstances – engineers for installation of equipment/control systems, people who provide inputs into the testing but do not do the testing themselves etc. Their roles are typically self-explanatory, but again, the Validation SME will need to ensure good communication and understanding with them.

So to conclude, based on experience, in this article I have highlighted what I think should be the main roles within a typical validation/implementation exercise, and how to use the strengths and key responsibilities of each effectively. It is critical to the success of all CSV projects that that the roles and responsibilities are clearly defined and understood.

In the next article, I will discuss the User Requirement Specifications – what should go in, what should stay out, the language to be used, and how a project can fail before it even starts if the URS is not what it needs to be.

To find out how we can help your organisation with your Computer Systems Validation and Data Integrity needs please get in touch at consultancy@jensongroup.com or to read more about our CSV services, please click here.

Read all posts in this series:

Neil Rudd
2024-01-22T09:47:40+00:00December 18th, 2023|
Go to Top