Michael Weis, SM, is principal of Michael B. Weis Consultancy, P.O. Box 414, Ringoes, NJ 08551, (609) 466-1261, fax (609) 466-9353, email: michaelbweis@aol.com.

Michael Weis

The right person can successfully promote proper management of quality and compliance, leading to desired clinical trial outcomes.

The purpose of this article is to propose a role called "quality coach," an independent expert dedicated to system and project quality, as a member of teams implementing software applications to support clinical data management activities. The article presents the issues unique to the regulated environment in which the software project resides, and explains the advantages the quality coach role brings to the team and the accomplishment of its goals. The concept of a quality coach is new and unproven. However, the authors have informal feedback from one company's widespread efforts that there are benefits, and look forward to interviews and surveys to fine-tune the concept in the future.

Regulatory agencies have encouraged the use of electronic records in clinical trial research. Such records offer advantages for data management, communication, and processing. However, along with these advantages come concerns. If it is easier to manage the data, it is also easier to mismanage the data, whether intentionally or accidentally.

Enter the regulators to ensure that adequate controls are in place to either preclude or identify mismanagement. The control mechanism is typically a combination of system validation, an audit trail, and a set of SOPs. The goal of the control mechanism is always the same-to reduce the probability of negative outcomes and make such occurrences highly visible.

At the most basic level, the risks of using electronic records in clinical research fall into two categories. The first category includes risks that endanger the utility of the data. Data corruption can be caused by inadequately tested systems or by individuals with criminal intent. If the data cannot be used to make decisions about the safety and/or efficacy of a drug compound, then the effort spent to collect that data will have been wasted. The FDA has set forth its expectation that data be attributable, legible, contemporaneous, original, and accurate.

The second risk category includes risks that endanger our ability to know and replicate the life story of the data. If we cannot describe what happened to our data, when it happened, and the actors and actions that caused it to happen, then we are not in control. If doubts should arise concerning data quality, we have no mechanism for reviewing data history and either alleviating or confirming doubts. If lack of control is pervasive we have reason to doubt data quality, even if no other specific reasons have raised questions about the data.

The design of computer systems that manage clinical data-for all or part of a life cycle that typically includes creation, modification, maintenance, archiving, retrieval, and transmission of records-must be a process that is permeated by awareness of the two noted types of risks. Features and safeguards must be implemented that protect data quality. And given the possibility that unforeseen circumstances may compromise those features or safeguards, there must be mechanisms in place that assist the system owner in identifying failures, understanding how they occurred, and preventing repetition in the future.

What are the possible ways to implement these safeguards? Who is in the best position to take on the responsibility for this implementation? Let's look at the qualifications of such a person. He or she must be knowledgeable in several areas:

 Its importance to the business process, along with specific system requirements and functions, and risks associated with its malfunction.

 The flow of the data in the system; the actions performed on that data, and risks associated with failed or incorrect actions; the different types of electronic records managed by the system, e.g., CRF data, consent forms, laboratory data, etc.

 The relevant rules and guidelines for clinical data records and the systems that manage such records, e.g., 21 CFR Part 11, corporate SOPs, etc.

 The steps involved in delivering a computer application system; familiarity with the quality issues related to the steps; general knowledge of computer systems validation and its associated deliverables.

It is unrealistic to expect a single individual will have in-depth expertise in all these areas. A team approach brings together people whose shared knowledge covers the required areas sufficiently to support the development project. Focusing on key requirements helps to identify the members of the team required to implement, monitor, and manage safeguards. 

Knowledge of the system and its data tends to reside in a designated system owner. The system owner is ultimately responsible for ensuring that the system meets the requirements of the business process. Also, this individual is responsible for ensuring the quality of the system, including compliance with regulatory requirements and corporate SOPs.

In-depth knowledge of the software development process resides in a project manager. This individual maintains a project schedule and a catalog of expected deliverables, monitors progress, conducts project meetings, and addresses the issues that arise. Because computer systems validation is an important component of a good software development life cycle methodology, the project manager is responsible for including validation-related activities in project plans. This individual must ensure risks are assessed; required team members are appropriately assigned; sufficient funding is secured; processes are defined; and specifications, validation scripts, and summary reports are defined and documented.

Every software development project presents unique issues regarding validation, quality, and regulatory compliance. Special analysis and decision-making are required to manage these issues. A project manager, even though familiar with the general concepts and deliverables, may not have the required breadth of experience and in-depth knowledge of the regulations. Further, a system owner will likely be managing competing priorities and be focused on taking delivery of a completed solution with implicit expectations regarding quality of a production system.

Providing a quality coach to support the system owner and project manager can be a successful approach for ensuring the proper management of quality and compliance requirements. The quality coach is an active member of the project team, responding to questions from other team members. The coach initiates discussions on quality and compliance topics and guides activities that lead to successful resolution. The quality coach can advise by reviewing documents and procedures. The coach is part of the group that approves two fundamental documents-the Validation Plan and the Validation Summary Report-and may be involved in approving other documents, such as user requirements, functional specifications, and/or technical specifications.

The involvement of the quality coach in the writing of the Validation Plan and the development of the risk analysis establishes the importance of the role early in the project. Working in partnership with the project manager and the system owner, the quality coach earns recognition as a resource across all phases of the project. In addition, the quality coach creates a firm foundation to understand and evaluate the concepts of risk, control, validation, evidence, and credibility. Placed in the proper context through effective communication by the quality coach, these concepts will serve as the backdrop for all ensuing project activities. These concepts will impact the way the project team executes daily activities and will become second nature when the team members talk and think about their tasks. 

The issue of objectivity is important when implementing a quality coach role. The quality coach is part of a team, but also a reviewer and approver of team activity. The quality coach must walk the thin line between supporting team efforts and imposing quality-related requirements. It is the job of the quality coach to make the thin line disappear by convincing team members that quality-related standards belong to everyone and are an essential part of goal achievement. The system owner is typically the person ultimately responsible for the quality of a system. The quality coach helps the system owner assess the risks associated with quality issues, which become the basis for key planning processes. The system owner and quality coach agree on an approach to managing risks that makes best use of available resources. 

There may be situations in which the objectivity of the quality coach comes into conflict with the priorities of the system owner. The compliance activities recommended by the quality coach may be unacceptable to the system owner due to budget costs or schedule delays. The system owner makes the final decision, accepting responsibility for the potential negative outcomes. Validation and project documents should describe the differences in opinion and the decisions made. The quality coach can sign the relevant documents for accuracy, even though he does not support the decisions that were made. In reality, this scenario is unlikely to occur if the quality coach does a good job of educating project personnel regarding the importance of quality and compliance and the risks of ignoring regulatory requirements, SOPs, or best practices. 

The identification of risks is a task in which the quality coach can play an especially valuable role. Ask a system owner or project manager "Where can things go wrong?" and you will probably be met with silence. The dialogue needs structure, and the quality coach can bring focus, sequence, and clarity to the discussion. The quality coach's knowledge and experience, gained from a variety of software development projects, can counter the unfamiliarity and discomfort with an infrequently done task that may be felt by some team members. With appropriate questions, examples, and explanations, the quality coach can help the team members understand risks , likelihood of occurrence, and the level of difficulty in detecting them.

The quality coach's role must also be distinguished from the role of a formal quality assurance (QA) department. The QA department may perform audits, enforce regulatory compliance, and identify the entire set of compliance problems for a particular system. Throughout the software development life cycle, the quality coach educates the project team on compliance issues, maintains constant vigilance for emerging quality issues, and proposes solutions for the problems discovered. The goal of this involvement is to set the stage for successful completion of the QA/validation process.

Similar to poorly defined user requirements for an application that takes on additional functionality and suffers from "scope creep," a quality coach must be vigilant and avoid "role creep." For example, a quality coach who wants to see project success might take on some of the project manager's responsibilities. This altruistic behavior can lead to negative outcomes. The quality coach's objectivity may become compromised, or his ability to meet the demands of other assignments may be undermined.

The implementation of a quality coach role offers the opportunity for improved compliance planning across the organization. Quality coaches from separate development projects can meet regularly to share experiences, suggest solutions, and improve the services offered by quality coaches across all software development projects. In addition, a group of quality coaches can serve as a resource to a formal quality assurance department or to a group responsible for setting policy and standards for computer systems validation or other quality and compliance activities.

Is a quality coach needed for every software development project? Probably not. A small, tightly focused application may present a narrow range of quality and compliance issues that do not require such a focused role. A project manager may be able to address some of these issues with the quality assurance department. However, a more comprehensive application, with greater complexity, could reap the benefits of a quality coach participating on the project team.

EdD,* is associate director, technology and quality control, with Johnson and Johnson Pharmaceutical Research and Development, 920 Route 202, Raritan, NJ 08869, (908) 704-4993, email: icantor@prdus.jnj.com.

MS, MBA, is manager of IM quality and compliance for J&JPRD, Raritan, NJ, (908) 704-4370, email: mlink@prdus.jnj.com. 

SM, is principal of Michael B. Weis Consultancy, P.O. Box 414, Ringoes, NJ 08551, (609) 466-1261, fax (609) 466-9353, email: michaelbweis@aol.com.

*To whom all correspondence should be addressed.			

Michael Weis

Articles

The Quality Coach