Keys To Computer System Compliance In Your Regulatory Department

By Kathy Pelley and Cori Rolland

Regulatory compliance departments are constantly challenged to pinpoint specific requirements and address those requirements effectively when the rules are vast, vague, and vary in interpretation. In this day of rapidly advancing computer and information technologies, one of the major areas of concern is computer systems compliance. This area presents even greater challenges when you try to understand not only the regulatory aspects (e.g. 21 CFR Part 11) but also the technology aspects. Perhaps one way to approach computer systems compliance is to apply the simple principles of playing a game.

What is the arena in which you are playing? Are you subject to U.S. regulations under the FDA alone, or are you impacted by global regulations as well? What are the rules? In this case, they are the regulations that govern your industry. What is your strategy to avoid a penalty or foul? What are the keys to winning the game? For the compliance department, you must know the regulations and how they impact your organization. It is also about applying a strategy that gives you an advantage over your competitors.

Define Your Business Arena
For many years, the FDA was the sole regulatory body you needed to be concerned with since you may have only done business in the United States. Today, more companies are selling their products in the global marketplace, thereby expanding the regulatory agencies with which a company must do business. So, one of the first steps is to determine the scope of the arena in which you are conducting business.

Understand The Rules And Regulations
Depending on the scope of your product marketplace, you will be subject to one or more regulatory agencies and their associated rules and regulations. It is generally accepted that the primary rules regarding computer systems compliance come from the FDA and the European Medicines Agency (EMEA). Individual foreign countries may have additional specific rules and regulations, but it is generally accepted that if you can meet the FDA requirements you will meet the majority of global expectations.

Develop A Strategy Or Game Plan
The strategy for overall computer systems compliance begins with a risk-based approach for computer systems validation (CSV) and IT compliance. It is very important for senior management to make sure that the IT and compliance groups are in general agreement about the risk-based approach to CSV and IT compliance. Often the IT group will resist additional documentation it considers unnecessary, and the compliance group will want extra documentation to avoid any questions during an audit or inspection. A fundamental understanding of the risk management approach and policy as defined by the organization can help alleviate disagreements, which can often become unproductive.

Your regulatory and IT leaders must be held accountable for agreeing on a pragmatic risk-based approach that can then be implemented in a documented process. This process should be accurate, reproducible, easy to use, and easy to interpret. The entire risk management process should be integrated into the compliance and IT business processes with clear indicators as to when, where, and how it should be used. The key to development of this process is to create an approach that validates what is necessary and justifies what you believe is not necessary.

Organize Your Approach To Documentation
The primary regulatory expectations are to be sure that appropriate documentation has been created and approved and that this same documentation reflects the installed system. Because documentation is a key element, an IT compliance or regulatory department may find it useful to create a hierarchy of documents in order to ensure the proper levels of documentation. A possible hierarchy is indicated in the graphic on this page.

The hierarchy differentiates the type of documentation and defines how the strategic documents drive the tactical ones. The strategic documents are driven by senior management’s risk-based approach and business goals. Two key strategic document types are:

• Policies that describe the declared intention, commitments, and responsibilities of senior management, including indication of any standards to be followed.
• Standards and Good Practice Guidelines that are supporting documents to a policy that provides tools, suggestions, and recommendations on how to achieve compliance with a given policy. ITIL (Information Technology Infrastructure Library) and GAMP5 (Good Automated Manufacturing Practices version 5) are examples of good practice guidelines, while ISO (International Standards Organization) is a source of many various standards.

The tactical documents, standard operating procedures, work instructions, and checklists will not be effective without the policy (including a quality manual), standards, and defined and supported good practice guidelines. It is also important to develop operating procedures that cast a wider net than just validation compliance in the event an IT disaster recovery or business continuity procedure is triggered.

Validation Is More Than Just Documenting And Testing
Often there is an assumption that computer system validation is simply documentation and testing; however, this is a false assumption that could prove to be costly for your company. Validation is a process that establishes “documented evidence, which provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and quality attributes” (FDA Glossary of Computerized System and Software Development Terminology).

Building quality into the system includes creating evidence that the system is suitable for its intended use and will perform reliably and repeatedly according to its specifications. Policies, standards, and procedures are put in place for ongoing control of the system. However, these policies and procedures are only as good as the execution, which makes training of key personnel a driving factor for success.

Elements Of Validation
The predetermined specifications and quality attributes for the computer system are defined when the concept and requirements are identified for the system implementation. The system validation plan is drafted in conjunction with these requirements, not at a later time.

During the design and implementation phases, the requirements are converted into the design for the system and the primary elements are reviewed and tested. Evidence of system design reviews and of development-level testing is gathered to document the system’s performance against those earlier pre-determined specifications and quality attributes. Final testing demonstrates if the completed system is fit for use and if validation has been achieved.

Final installation and use is the time for release of the system into production with completed validation records and standard operating procedures. This is accomplished using established change control, configuration management, and release processes.

A key part of these processes is for the compliance group to not wait until the testing or release phases to uncover inconsistencies or discrepancies between the actual performance and the desired attributes. Monitoring elements of validation at the earliest stages identifies problems sooner and during less complex and less expensive stages of system implementation. A gap in any of these processes can put computer system compliance at risk.

Put Your Game Plan Into ActionUltimately, the key to computer system compliance is preparation and planning. Defining a risk management approach and building the appropriate processes and procedures to support it can seem cumbersome and time-consuming. As Life Science Leaders, your role is to ensure that the risk-based approach is developed and reflects the business goals of the company. This risk-based approach should result in the appropriate policies established that reflect the philosophy of the company. Senior management should ensure that adequate resources are empowered to implement the policies and that supporting guidelines and tactical documentation are created to execute the risk-based approach. Ultimately, senior management needs to hold the appropriate people accountable for compliance.

However, an effective approach that provides discipline with enough controlled flexibility will shorten the execution and reduce overall costs and risk in the long run. It is important to adopt standards and best practices to maintain consistency in your approach to computer system validation and to provide the tools necessary to easily demonstrate your compliance during an audit or inspection.

Finally, senior management must be very diligent in its understanding and monitoring of the interaction and concerns between the IT and regulatory groups. Without that, the best-documented process may not be executed properly if one of these groups does not believe the process to be effective.