Is your IT infrastructure qualified?

A new Good Automated Manufacturing Practice (GAMP) guide on IT Infrastructure Control & Compliance was launched in Chicago (IL, USA) 23 August 2005.¹ The guide is intended to support pharmaceutical companies in their effort to establish a well-defined and compliant infrastructure. This article discusses different aspects of the guide that may support your organization in getting — and keeping — your infrastructure under control.

This article introduces the basic elements to manage and provides a roadmap to infrastructure compliance. Standardization can be a key to achieving compliance in a way that contains or even reduces cost. Simultaneously, it enables IT to keep platforms up-to-date, protected and optimized. Finally, if you consider outsourcing parts of your infrastructure, this guide will help you define the requirements.

Ever since the early 90s, there has been a constantly increasing focus on the use of computer systems supporting critical processes in the pharmaceutical industry. Initially, industry and regulators focused primarily on the implementation and use of business-critical applications and were less concerned about the infrastructure layers underneath. This changed in 2000 when FDA began to take an interest in networks and other infrastructure elements resulting in a number of warning letters and 483s being issued. FDA's reasoning was hard to argue with, as it was based on the fact that most infrastructure elements have a potential impact on regulatory data integrity, availability and confidentiality .

So the industry began to prepare itself for this new era in computer systems validation. It was facing a tough challenge combining constantly evolving IT in a complex and autonomous environment with rigid requirements on process and documentation. Projects were initiated, trying to bring the infrastructure in a state of control that would satisfy the regulators. But to get there they needed to define what 'state of control' implied for their company. Literature offered little help and there was a lack of available industry standards or best practices. Therefore, different companies took different approaches and developed company-specific standards for qualification of infrastructure. The need for an industry standard became apparent.

One of the positive outcomes from all the hard work was, of course, that a number of companies gained a lot of experience in the area. A milestone in synthesizing these experiences was achieved on 23 August 2005 when the International Society for Pharmaceutical Engineering (ISPE) released a new Good Practice Guide (GPG). The guide addresses key issues in the operation and maintenance of IT infrastructure in regulated environments. The objectives of the guide are to define a set of minimum requirements and to provide pharmaceutical companies with practical examples of best practices in the industry.

The basic elements

Qualification of infrastructure is not only about the hardware and software components forming your IT infrastructure. One of the main concepts in the new guide is that infrastructure consists of the following three elements: processes, personnel and platforms. Each of these must be adequately addressed for your infrastructure to be considered qualified.

Processes. For processes, you need to have a well-established quality management system implemented in your infrastructure organization. On a top level, the system must define the objectives of the quality system, the roles and responsibilities related to the system and how the system is governed and maintained. This part of the system should function as the interface to the corporate quality management system, defining the split in responsibilities between IT infrastructure quality assurance (QA) and corporate QA. In addition, a number of general procedures must be in place defining company policies for records management, documentation, internal audits, and so forth. On an operational level a number of processes must be covered by the quality management system (Table 1). The processes should be supported by instructions, checklists and templates as deemed adequate.

Table 1. Required operational processes.

Personnel. The personnel element may very well be the most challenging part. Traditionally, the IT environment is characterized by a very high focus on stability, continuity and availability, and less focus on — and sometimes even resistance towards — documented processes and documentation of activities. The challenge is to define the level of documentation that will ensure compliance and at the same time give the flexibility needed to maintain stability, continuity and availability of your business-critical systems. So we have the QA/regulatory affairs (RA) officers on one side with rigid requirements for documentation and IT professionals on the other in need of flexibility. As a starting point both sides need to realize that stretching is required. IT must accept that some level of documentation is required, and that sometimes the argument will be 'because it is required by FDA'. QA/RA must accept that this argument should be kept to an absolute minimum and that an operational focus is vital when defining required processes, procedures and templates. A common ground to meet on can be standardization: the 'building block concept' discussed later in this article.

Platforms. Two different strategies can be taken by pharmaceutical companies with respect to platforms. The traditional approach is choosing a platform on a case-by-case basis and it is driven directly by requirements from business applications. The consequence is system-specific platforms that require a considerable amount of validation and qualification work each time a new business-critical system is launched or major changes to existing systems are made. Also, from a maintenance point of view, this approach involves a significant amount of work regarding implementation of patches and hot fixes. In theory, you need to assess and possibly test and document each type of platform so that a certain patch does not negatively impact your business-critical application. If you have a unique platform set-up for each of your applications the challenge becomes obvious.

However, by taking a horizontal approach instead of the vertical one just described, your benefits will be two-sided. With the horizontal approach you define a number of standardized platform components such as clients, server hardware and databases. The obvious advantage is that each of these standard components can be prequalified, thereby making the qualification effort considerably less when using the components in business-critical applications. Another advantage is that infrastructure changes can be implemented more efficiently and rapidly because the number of permutations of infrastructure components is kept low. Third, standardization and consolidation of infrastructure optimizes the use of IT in the company.

Standardization

The horizontal approach or 'the building block concept' is illustrated in Figure 1.¹ As indicated, clients, databases, operating systems, server hardware and networks can be regarded as horizontal platforms shared by all business-critical systems. In the context of the new guide, these horizontal platforms, together with the necessary infrastructure processes and supporting tools and applications, constitute an IT infrastructure. The sole purpose of IT infrastructure is to support business-critical processes and systems.

Figure 1. The horizontal approach or 'building block' concept.

The building block concept requires that corporate standards are defined and implemented for each of the horizontal platforms. Several standards for each type of platform may co-exist: client standards may include standards for laptops, desktops and PDAs. Operating system standards may include several versions of Windows and UNIX. Based on such standards, platforms can be prequalified, thereby reducing the qualification work related to implementation and validation of business-critical systems. It is important to emphasize that the level of flexibility in such standards should be considered very carefully, balancing the advantages of standardization with business needs.

Prequalification is, in theory, performed prior to the platform being used by any system. Legacy platforms can be qualified retrospectively in a similar way if no qualification has been done previously. The prequalification will typically include the following activities and documentation on a generic level:

• Platform requirements specification: High level requirements for the platform are specified; for example, the types of systems that the platform must be able to support; considerations regarding interfaces to other platform types; and communication and security requirements.

• Platform design specification: The requirements to the platform are transformed into design specifications, defining hardware and software components, configuration and set-up. The design specification will typically also include a complete configuration item list of the platform.

• Configuration: The platform is configured in accordance with the design specification.

• Installation qualification: Documented verification that the platform is configured in accordance with the design specification.

• Operational qualification: Documented verification that all requirements specified by the platform requirement specification are addressed.

• Implementation document package: To support a system-specific implementation of the platform, system service agreement templates, installation checklists and templates for the installation qualification protocol and report are produced.

From a compliance point of view there are many benefits from the building block concept. A generic prequalification of the platforms adds transparency. QA/RA can be more assured of the qualification of complex infrastructure layers of a computer system. A uniform qualification process enables continuous improvement. And the work related to test and documentation of necessary platform changes can be reduced significantly as multiple systems are running on the same standard platform.

Key points

Roadmap

The following four steps should be followed to achieve a compliant infrastructure:

1. Define the basic strategy for qualified infrastructure: To start with, companies need to decide whether or not the building block concept is a feasible solution, and if the future infrastructure should be based on recognized standards and best practices such as ISO9001 and the IT infrastructure library (ITIL). Using the new GAMP guide as a basis for the project will benefit many companies regardless of maturity within infrastructure qualification. The guide is bound to become an industry standard as regulators use the guide in their inspection preparations.

2. Identify the gaps: An analysis should be performed to identify the gaps in the current technical setup and implemented processes and procedures against the guide. As this analysis must cover all existing platforms of regulatory concern, the exercise will be quite comprehensive for most companies. For each type of platform and for each area that needs to be covered there are three possible outcomes of the analysis:

• the company is 'spot on' and no further action is required

• the company identifies gaps from the guide that need to be addressed

• the company realizes that it has gone over the top in its effort to achieve compliance, and it could actually reduce the effort.

The last result can sound hard to believe, but some companies may have taken a very conservative approach to infrastructure compliance in the lack of industry standards. It could be that requirements regarding validation of business-critical applications have been transferred directly to infrastructure simply because of uncertainty or lack of knowledge. The result of such an approach may very well be an 'over the top' solution.

3. Prioritize and close the gaps: As previously indicated the gaps will fall in the three categories; processes, personnel and platforms. Each of the identified gaps must be evaluated based on the compliance risks associated with the gap and the benefits gained by closing it.

For some companies the gaps identified in the process area will include most of the required processes listed above, as infrastructure has not previously been in the scope of their systems validation. These companies have a massive challenge bringing their infrastructure functions into the required state of control. Other companies may lack a few areas in their current set-up that need to be addressed. Quite a large number of companies will realize that different departments have very different approaches to procedures such as change management, configuration management and problem management. These companies are likely to benefit from consolidating best practices from different departments into cross-functional processes. This can also drive consolidation of the infrastructure tools used across departments.

The gaps identified in the personnel area reflect the state of the implemented processes. If a large number of processes are identified as not existing, the gaps on the personnel side will typically also be substantial. In the area of platforms, most companies will experience that the current state of qualification differs from platform to platform. The reason being that the qualification work is currently not centrally governed and the building block concept not utilized. The most important task is then to define the acceptable level for each type of platform and bring the platform to this level.

4. Implement controls to stay in compliance: Once all processes, platforms and personnel are brought to a state of control, a number of controls have to be implemented to ensure that they remain compliant. Controls could include an internal audit programme ensuring compliance and ongoing improvement of the processes and frequent base lining of the platforms ensuring compliance with platform standards.

Getting ready for outsourcing

A number of uncertainties arise when considering IT outsourcing. First, how does a company stay in control when a critical part of the business is operated by others. There is no doubt that the responsibility for a compliant infrastructure stays with the company even if the work is subcontracted.

The concept of supplier control is not new to the pharmaceutical industry, as there is a long tradition of retaining control of suppliers of raw materials, components for medical devices, and so forth. The tools used are typically supplier audits and receiving inspections to ensure the expected safety, efficacy and quality of the final product. However, what do you do when receiving control is not an option? Can you ensure the necessary audit depth in an area fundamentally different from pharmaceutical production? Can you expect the supplier to have or obtain the required knowledge within regulatory requirements and good practices?

The first step is to get in control if not so already. If you are not already in control, outsourcing alone will certainly not bring you there.

The second step is to identify the elements of your infrastructure where outsourcing could be beneficial from both a financial and regulatory viewpoint. To identify these elements a risk assessment should be done identifying possible risks (business risk, technical risks and regulatory risks) and mitigating controls.

Being in control and knowing potential risks will enable the company to outline a company-specific standard for future outsourcing partners, defining requirements regarding content of the supplier's quality management system (QMS), and the training and regulatory knowledge of their staff. Known best practices such as ITIL and the new GAMP guide for infrastructure should be taken into consideration when preparing such a standard.

The next step is to perform an assessment of potential outsourcing partners against the standard. The assessment process must be fairly comprehensive to obtain detailed knowledge of the partners' capabilities and identify gaps from the standard.

The degree of compliance with the company outsourcing standard is only one of the components in the decision making when investigating outsourcing. However, in the regulatory perspective it becomes of utmost importance that a future IT service provider is capable of and willing to fulfil the company's requirements. Closing the gaps will require a close partnership between the pharmaceutical company and the supplier.

References

1. GAMP Good Practice Guide "IT Infrastructure Control & Compliance" (ISPE), Chicago (IL, USA), 23 August 2005 www.ispe.org/gamp

Morten Palm is a senior quality and validation consultant of NNIT, Lyngby, Denmark.