Why do we need documented processes in Clinical Research?
The answer to this question may seem obvious – we work in a regulated space, where it is essential that the welfare and rights of research subjects are protected and that the clinical studies we conduct are scientifically rigorous and are able to evaluate the product under study for safety and efficacy. To ensure this we need to have consistency in the way we operate and controls in place to ensure this consistency is maintained and appropriately corrected when there are problems (which there will be). Having said that, in many years of conducting research and evaluating systems I have seen myriad processes that are unclear, ambiguous or with gaps and inconsistencies in them. They may have started out as great quality systems, but after several rounds of amendments over the years they often become a Frankensteinian patchwork of mismatched parts.
Traditional GCP Model
The traditional model for a GCP quality system is generally based on the GMP background of a hierarchical document strategy. As we traverse the hierarchy there is an increasing level of detail explaining what needs to be done.
Such traditional structures almost always fall into the following model:
– Work instruction
– Business Practice
This is often further complicated by policies and procedures from Corporate, Legal, IT, HR and other departments which serve to confuse the system at an organizational level. And, yet again, with study plans and procedures, which can make for an intriguing spider’s web of despair when mapped out. How many times have you seen one policy contradict another? Just think of your organization’s record retention policy as but one example. Often the viewpoint of Legal and Corporate is not the same as the regulatory requirements of ICH-GCP to which the organization will be held when it comes to submitting a new drug application.
Furthermore, the use of this structure is often based on false assumption that “regulators will only want to see SOPs,” which has resulted in some interesting philosophical positions being adopted. Many times I have seen detailed information being embedded in lower document strata so that SOPs don’t really have sufficient detail for the employee to conduct their activity. This usually results in a hurried (and harried) management decision during an inspection to decide whether or not “to release” work instructions to the inspector or risk a finding for having inadequate SOPs.
I don’t think there is fundamental issue with having a document hierarchy but some of the issues I have encountered over the years include: multiple levels of documents with identical or similar names, duplication and unclear relationships between documents, content drift both up and down the hierarchy, lack of clarity, and potential for inconsistency. All this leads to an overall difficulty in content management and often huge, bloated and inefficient GCP document management systems which seem to eat resource.
So, what can we do?
In simple terms the regulators just want to know, “How do you do your job and make sure the process is under control?” And for this, the inspector expects to see a good set of documents to support your answers. Now, whether you call such a document an SOP, Work Instruction, Business Practice, Desk Instruction, Office Guidance, or Fred (yes, I’ve seen that, too!) doesn’t really matter, it still fulfills the same role: keeping the process under control to protect subjects and ensure scientific integrity of the study.
Any informed auditor will know this and should ask to see your “written procedures” rather than falling into the trap of just asking for SOPs. Again, over the years you would be surprised at how many organizations I have seen waste time trying to justify putting instructional procedures into “business practices” and the like so that they don’t have to produce them when asked for SOPs. Come on, folks if it covers activities that impact our two principles: subject welfare and scientific integrity, then you should be proud to explain it.
A Simplified Solution
So, all that being said, I still think our methodology is fundamentally sound, but it really is in need of clarity to get people thinking about why we have such documents and how to develop and use them more effectively.
Firstly, I propose we remove what I consider to be the “baggage” associated with existing terminology. Too often I have seen protracted discussions (often heated) regarding whether a process should be in a policy or an SOP, or a work instruction versus a business practice. We work in an industry where time is money and where the phrase “every day’s delay costs the company over $1,000,000” was often banded about 25 years ago. Ten people sitting around a table discussing the document hierarchy for an hour is simply not good use of resource.
To achieve our goal I suggest that what we need is a system that is easy to understand “at a glance” by any reader. I suggest we retain some of the existing 3-tiered structure which we are all familiar with but break the quality system down for clarity into the following document types:
To concisely describe, at a high level, why we need to do something. For example, because it is a regulatory requirement.
To describe what we have to do to achieve the activity.
This is where the detail is captured. These documents should describe how we do the activity, and include who does it, when, and how interactions and controls are managed. The HOW documents should be the area where people focus and there should be an efficient and effective process where they are routinely reviewed and amended as processes are improved. This should not just be annually or biannually!
An Obvious Naming Convention
Given that we are looking for clarity for such a system I also propose we rethink the routine naming conventions with which we have been saddled for decades. Wouldn’t it just be simpler to use an obvious system that incorporate the why, what, how? I suggest the following approach, as this would also fit with many existing document naming structures I have encountered:
Where nnn = document number and xx = revision number
But now we have no SOPs!
Now here’s the fun part. When asked for a list of SOPs we can simply say with a smile, “but we don’t have any!” And when the regulator has gained their composure we continue, “but we do have detailed documents describing why we do something, what we do, how we do it, by whom it is done. Would you like to see those?”
This short article has been written “tongue in cheek”, so to speak, but the underlying theme remains a serious one. The goal was to get you thinking about how your quality system is set up, and perhaps more importantly, encourage individuals to really think about why we do things, what we do and how we do them to protect people and the science that should help them. The subject of SOPs is a dry one at the best of times and maintenance of procedural documents is often seen as a chore by many in the industry. However, without such a framework we jeopardize both the safety and science of the critical work we do.
It is mildly ironic that we expect our cars to have inspection checklists and for the technicians to follow procedures to service our vehicles, yet many individuals in the GCP world will still roll their eyes when asked if they are following a documented procedure.
With over 25 years experience in Clinical Quality Management and Clinical Operations in both the EU and US, Richard Reeve has a proven track record of establishing and re-engineering GCP quality systems, hosting external inspections by regulators and business partners, and managing inspection planning. Combining a business-focused approach with practical operational experience he is able to quickly identify compliance issues and areas for optimization in the GCP arena.
All content of this website is Copyright © RPR Consulting, Inc. and may not be reproduced in any format without written permission. You are free to reference this article on your webpage using a hyperlink, with appropriate accreditation to the author.