How Pharma Can Strike the Right Balance Between Control and Flexibility in IT Quality Systems

A true risk-based approach to information technology (IT)-related compliance is necessary for pharmaceutical companies in today’s evolving technology and regulatory landscape, and in a climate of changing service consumption models.

Risk assessments that focus on system testing do not provide the necessary flexibility. It also does not help pharma companies identify risks or leverage quality and compliance activities performed earlier in the system life cycle activities.

Today, this flexibility is essential, as system implementations often involve working with service providers, deploying cloud or software as a service (SaaS) solutions, utilizing end-user programming tools, and adopting iterative system life cycle methodologies. Rigid IT quality systems prevent pharma from focusing on risk-mitigating activities.

Finding the right balance between control and flexibility requires pharma to consider:

· Forming a compliance center of excellence to drive consistent compliance and authorize risk-based decisions.

· Training and coaching project teams.

· Removing unnecessary details from procedures and templates.

· Moving decisions from the procedures that apply to all project and systems to the validation plans that are tailored to each project.

· Creating deliverable templates and examples that help authors, and creating tools that provide guidance and justification.

The battle between control and flexibility

Pharma companies still struggle to find the right balance between having a rigid recipe-driven quality system that is easy to follow consistently and a risk-based flexible quality system.

Some feel that procedures and templates need to be very detailed and rigid to enforce compliance, while others want flexibility that allows project teams to make risk-based decisions. Both sides experience IT projects that do not follow the expected quality and compliance processes, and result in non-compliant systems and considerable rework to fix the gaps.

At the same time, these companies also experience projects that suffer from overly conservative system life cycles that execute activities and produce documentation that has minimal or no value to quality or compliance. They follow rigid processes that were prescribed by their system life cycle and validation standard operating procedures (SOPs), and were not able to adjust project activities and deliverables based on actual risk or leverage quality activities already performed by the software developer and system integrator.

Inconsistent levels of quality and compliance, frequent debates by project team members, and excessive rework are often blamed on SOPs, work instructions, and templates that do not provide enough details and direction to ensure that everybody follows consistent processes and produces consistent and quality deliverables.

In other situations, lack of compliance is the result of overly prescriptive procedures and templates. Project teams skip activities or sections in documents in spite of them being required by the procedures or templates. They avoid executing tasks that add no value to quality, but this creates situations of non-compliance.

So where do we draw the line between a rigid recipe-like quality system and one that is flexible? The answer depends on multiple factors, including: organization and governance of IT projects, maturity of IT practices, team member skills related to quality and compliance, availability of consistent resources to support quality and compliance activities, and availability of tools that support risk-based decisions.

Create a compliance center of excellence

Varying interpretations of regulatory requirements and personal opinions prevent pharma from creating flexible, risk-based quality systems. Often, the problem stems from a very conservative interpretation of regulatory requirements by stakeholders who believe SOPs must describe every step of the process in great detail.

This belief also drives companies to create multiple SOPs for similar processes, in which some details vary between departments or systems (eg, location of records, specific titles of reviewers and approvers, validation deliverables based on system type). The belief that quality system assets must prescribe a rigid process often results in document templates that mandate the inclusion of sections that do not apply to certain system or add minimal value.

A flexible risk-based approach must be supported by compliance subject matter experts (SMEs) that ensure consistent quality and compliance. A compliance CoE, whose members are compliance SMEs, is the preferred method of addressing this need.

The SMEs facilitate risk assessments, review and approve critical project deliverables, coach team members, and ensure that the risk-based approach for a specific project is appropriate. The SME involvement mitigates the risk that project teams will take inappropriate shortcuts when the procedures and templates don’t prescribe every step and deliverable.

Design SOPs to provide flexibility in choosing life cycle approach

Procedures must be followed and must not be vague. However, they don’t need to enforce the same system life cycle with the same set of activities, responsibilities and deliverables for every project.

For example, instead of describing and mandating all phases, activities and deliverables, a system life cycle SOP may describe the process in which risks are assessed and decisions are made as to which ones are appropriate for a specific project and how they are documented in the validation plan. In this case, instead of mandating the same system life cycle with all its activities and deliverables for all projects and systems, regardless of risk, complexity, scope, etc, the validation plan for that project/system becomes the governing document that is tailored to the project. The SOP still has to be clear and followed consistently, but it provides flexibility in choosing the appropriate life cycle approach for the project and system.

Templates should also be useful tools that promote consistency and compliance, and help the authors create deliverables. For most deliverables, not all sections need to be mandatory. Those sections that are optional should be described as such and only included when they add value. Templates may also include instructions, generic text, and examples of text that can provide guidance on required content, style, level of detail, and format.

A concern with a flexible approach is how to ensure consistency and be able to defend risk-based decisions when the procedures don’t mandate system life cycle processes and deliverables. I’ve discussed the benefit of having compliance SMEs drive consistency, but that’s not enough.

Tools such as guidance documents, checklists, system life cycle methodology standard, risk assessment standards, and examples of deliverables are also required. These tools should provide guidance and rationale for making risk-based decisions. They should not replace the procedures by enforcing a rigid approach.