Motivated by internal government recommendations, initiatives, and legal mandates, the US Food and Drug Administration released structured product labeling (SPL)–related regulations for 21 

 Parts 314 and 601. On Feb. 5, 2004, the agency provided an SPL draft guidance for industry entitled, 

Providing Regulatory Submissions in Electronic Format—Content of Labeling

 (1) and announced acceptance of SPL applications on Sept. 24, 2004, in public docket number 92S-02512. The challenge was to build an effective regulatory guidance system using more-flexible application tools than portable document format (PDF) or Microsoft Word for the electronic maintenance of market applications such as human drugs and biologic content. At the forefront of the research was Health Level Seven (HL7), a volunteer American National Standards Institute–accredited standards developing organization that focuses on the development of specifications for the standardized maintenance of clinical and administrative healthcare data. HL7 has defined a new data file definition called SPL, which is based on the Web standard extensible markup language (XML). As of this month, FDA requires that all labeling content information for human prescription drugs be submitted in SPL XML format. PDF format will no longer be accepted. So, what is XML and why is it important for SPL compliance? 

XML, an electronic file format supported by numerous software manufacturers and endorsed by the World Wide Web Consortium (W3C) as an industry standard, enables practical solutions for electronic business transactions. Because it can be read by multiple source applications and disseminated in a variety of formats, XML delivers the promise of "one version of the truth." For example, the boxed warning information in an FDA-approved submission can be repurposed immediately as the content in the next print run of an accordion-style printed insert that accompanies a physical product. The printing system can be readily updated by the approved structured content in the SPL file. 

Designed for large-scale electronic publishing and exchanging information on the Web, XML is a subset of standard generalized markup language (SGML). XML development began in 1996 and was formally recommended by W3C in 1998 (3). XML is much like HTML in its coding structure. They differ, however, in that XML was created to define and describe specific pieces of information using user-defined custom tags and attributes, while HTML is limited by the use of predefined tags for visual representation of information.  

The XML standard provides a wide-open platform to create data structures and related data-storage elements. Custom designed data definitions, data types, attributes, hierarchal relationships, and general taxonomy are collected in XML schemas. Once created, XML tag elements defined in the schema can be used, as needed, to record the actual data values in the XML file.  

FDA provides a large set of elements in a predefined SPL schema for representing labeling data. This SPL schema set is dedicated to recording drug product information and has embedded coding values to support efficient computability for search and retrieval. The SPL schema structure ensures that a uniform representation of the product data is maintained across all labels. 

SPL XML applications can maintain all of the textual-based information, data elements, and images needed for drug approval, including drug listing information. XML also can efficiently handle multimedia such as tables, images, and complex documents. Pharmaceutical companies can expand the XML format into almost every branch of their businesses.  

XML can integrate dissimilar operations by consistently exchanging standardized data. Because the content is kept separate from the format, multiple application databases using XML can be distributed across many servers while maintaining the integrity of the data. Likewise, documents can be viewed on various media with extensible stylesheet language (XSL) style sheets, which allows different ways of presenting the labeling information, in accordance with the preferences of the targeted audience without the need to reprogram or manipulate the information. XML supports both unicode and multilingual documents, thereby facilitating the internationalization of complex data. 

SPL is the introductory XML-based standard for medical and biological labels. Interestingly, XML is quickly becoming the standard in the healthcare industry. In fact, pharmaceutical and medical markets are planning to extend the appliation of XML to clinical trials and patient medical histories. HL7 is developing XML data definitions for stability data and protocols. Before SPL, PDF files were used for human drug biological content submissions throughout all process stages. The format's inability to allow queries and the reuse of specific data, however, made it impractical for labeling. We project XML eventually will be the defacto file format for the electronic submissions of all medical products information. XML enables real-time changes as well as the submission of changes or additions in sections, thereby eliminating the need to resubmit the entire label for approval. This capability may significantly reduce the labeling-content negotiation phase of the FDA approval process. 

 Three major components comprise the SPL XML format: header, body sections, and data elements. The header, or classification, contains general information about the label and product. It sets the context for the remainder of the document. Header elements are primarily data-field items such as identification, version, name, and address.  

Human readable content, multimedia, and encoded computer processing content are included within the SPL body sections, which are primarily text-based information but can include tables, images of molecular structures, lists, and chart diagrams. The body sections contain product content divided into units of text such as drug interactions, dosage and administration, and warnings.  

The drug listing information is defined by many data elements organized according to packaging, active ingredient, inactive ingredient, observation (

 color), and route of administration sections. Storing the information and exchanging it across and within institutions requires that the structure be identical throughout all documents; the SPL format accomplishes this conversion.  

Detailed SPL specifications can be found on the FDA structured product labeling resources Web site entitled, "SPL Implementation Guide for FDA Content Labeling Submissions" (4). FDA's required format is defined in the SPL version 2a. 

Executing SPL compliance using XML can provide several advantages not only to pharmaceutical and medical products manufacturers, but also prescribers and consumers. Coordinating data collection and storage makes the evaluation of labeling changes more efficient and the dissemination of labeling to improve risk management faster. Therefore, higher quality prescribing and safety information can be delivered to a medical practitioner faster than it is delivered today. 

Minimizing redundant data collection also improves patient safety and quality assurance. Revisions can be made to existing legacy data elements or sections for original or subsequent submissions. As a result, companies no longer need to resubmit an entire product label from scratch because XML markups can call up data buried in the body section or narrative block. Moreover, interoperability with other systems and human-readable labeling content compatible with other systems promotes more coordinated efforts across regulatory agencies.  

One of the most compelling benefits of XML related to product labeling is its potential to facilitate global harmonization of labeling content. The same content used for an SPL submission can be repurposed for use in a European Union product information management (PIM) submission. Europe will begin voluntary implementation of the PIM standard for centrally registered products on Nov. 20, 2005. The evolving nature of XML technology and data definition standards offers the opportunity for the internationalization of a whole host of medical, pharmaceutical, and biological products applications and services. XML is redefining the database infrastructure with a standardized product for the international community. 

 is the president of ThinSpring,  991 US Highway 22, Suite 200, Bridgewater, NJ 08807, tel. 908.595.2145, fax 908.231.0444, 

 is the manager of Structured Content Services for Reed Tech (Horsham, PA), 

*To whom all correspondence should be addressed.

1.  US Food and Drug Administration, "Providing Regulatory Submissions in Electronic Format: Content of Labeling," 

a257.g.akamaitech.net/7/57/2422/14mar20010800/edocket.access.gpo.gov/2004/pdf/04-2536.pdf

2.  FDA, "Content Labeling," public docket 92S-0251 (Sept. 2004),  http://

www.fda.gov/ohrms/dockets/dockets/92s0251/92s-0251m000031.pdf

3. World Wide Web Consortium (W3C), "XML Recommendation" (Mar. 27, 1999), http://

4.  FDA, "SPL Implementation Guide for FDA Content of Labeling Submissions: Version 2a" (Mar. 2005), http://

• D.Obasanjo,"Understanding XML"(July 2003), http://

msdn.microsoft.com/XML/Understanding/default.aspx?pull=/library/en-us/dnxml/html/understxml.asp

• S.Powell and G.Kalten,"The Future of Labeling," 

Guidance for Industry Providing Regulatory Submissions in Electronic Format—Content of Labeling 

www.xml.com/pub/a/98/10/guide0.html?page=2#AEN58

Articles

The extensible markup language (XML) format facilitates compliance with FDA's new requirements for prescription drug labeling submissions, improves patient safety, and enhances manufacturing sponsor efficiencies.

FDA's New Labeling Requirements: The Importance of XML for SPL Compliance

Compliance in the pharmaceutical industry used to be virtually synonymous with compliance with the US Food and Drug Administration current good manufacturing practices (CGMPs), which date to the late 1970s. Once a manufacturer validated its processes and systems, it discouraged any changes that would require a time-consuming and expensive revalidation process. Manufacturing productivity, innovation, and product quality often fell victim to this approach. 

The compliance challenge has become more complex in recent years as a result of significant changes at FDA and other federal government agencies, ranging from new electronic signature regulations to new manufacturing best practices. There also have been significant changes in the world market such as the increased international trade of drugs, increased drug counterfeiting, and the threat of terrorist acts targeting the food or drug supply, which have a highly visible impact on public health. In addition, increased industry consolidation makes compliance more challenging at huge multinational corporations, which have grown through the acquisition and mergers of companies with disparate compliance initiatives and approaches.  

In addition to dealing with manufacturing compliance, pharmaceutical companies today grapple with at least three other sets of requirements, including: 					

 All companies must comply with many cross-industry regulations relating to employee health and safety, patient privacy, and financial integrity. Examples include Occupational Safety and Health Administration regulations, the protection of patient-related data under the Health Insurance Portability and Accountability Act, and Sarbanes-Oxley requirements.

 Increasingly, customers require compliance with quality assurance standards as part of their contractual agreements. For example, they may require certificates of conformance or analysis to accompany each shipment and may base future agreements on both quality performance data and on-time delivery. To remain competitive, manufacturers must efficiently manage these stringent vendor agreements as well as data-exchange requirements.

 To lay the foundation for compliance with external requirements, internal rules must be built, maintained and documented. These rules include equipment safety procedures, standard operating procedures, nondisclosure rules, and procedures for product launches. 

In the pharmaceutical industry, validation requirements and good manufacturing practices have fostered the 

and thus have been one cause of the industry's manufacturing inefficiency. The rule of thumb has been, Once a system or process has been validated, don't touch it. 

Increasingly pressured by competition from generics and public pressure to lower the cost of drugs, many innovator companies see the need to abandon the 

 to focus on improving productivity, efficiency, and quality. Unfortunately, they have often been constrained by the very regulatory processes put in place to protect the public.  

Companies operating in the United States may soon get some regulatory relief, thanks to a shift in the way FDA plans to regulate the industry, emphasizing a quality-by-design model as opposed to its historical quality-by-testing results approach and encouraging a risk-based approach to compliance and enforcement. 

Thus, pharmaceutical manufacturing is in a state of transition, as the industry evaluates long-standing practices and new technologies and FDA introduces new regulatory paradigms. Increasingly, information technology is playing an important role in helping companies streamline compliance and improve operational efficiency throughout their supply chain, manufacturing, and distribution operations. 

A solid regulatory program aims to ensure compliance and quality by formalizing policies and procedures, instituting administrative controls to ensure procedures are followed and creating alerts that indicate when procedures are not followed. All of these components must work together for an organization to achieve and maintain compliant operations.  

Historically, compliance has been a time-consuming and expensive task for the industry—largely as a result of the sheer volume of data that must be collected, managed, and maintained, as well as the multiple and often simultaneous steps in the manufacturing process. Other factors contributing to the complexity of compliance include:					

 There are many models to estimate the cost of validating IT systems. The rule of thumb in the early to mid-1990s was that validation costs were ~20–30% of the projected costs of implementing an enterprise resource planning (ERP) system. By the late 1990s, however, validation efforts became more integrated with implementation, rather than being handled as a separate, sequential effort. In the last several years, risk assessment has been widely leveraged, lowering validation cost estimates to 15–20%. Regardless, validation remains a large proportion of implementation costs, and companies sometimes are tempted to skimp on validation to save money.

Misinterpreting the scope of the requirement.

 In many instances, manufacturers had given a similar level of scrutiny to all areas of risk, regardless of their potential to negatively affect quality. Because of this failure to prioritize their efforts, companies often wasted valuable resources with minimal return. In recent years, risk-based approaches to validation—as recognized by the GAMP Forum in its good automated manufacturing practices guide (GAMP 4) (1) and encouraged in the United States by FDA and worldwide by members of the Pharmaceutical Inspection Convention and the Pharmaceutical Inspection Cooperation Scheme (PIC/S)—have put the focus on doing the right things well rather than using a one-size-fits-all approach to validation (2, 3). 

 Traditional manual documentation processes are expensive, time-consuming, and often inaccurate. For example, it is difficult to circulate standard operating procedures and keep records up-to-date with paper-based systems. In addition, a given procedure may have multiple data sources, leading to confusion, inconsistency, redundancy, and increased risk.

 Traditionally, compliance has been managed in "silos" dedicated to specific requirements. This approach leads to the duplication of efforts and often precludes analysis that would improve efficiency or quality control.

Risk-based approaches have significantly improved regulatory compliance in recent years. Increased automation of compliance controls and reducing paper systems offer additional opportunities for cost reduction and improved risk management. 

A discussion of the high cost of regulatory compliance would be incomplete without describing how an inflexible regulatory environment has negatively affected productivity and quality in manufacturing.  

In spite of the industry's focus on quality, pharmaceutical manufacturing has failed to keep up with other industries in terms of efficiency and productivity, largely because of the cost and burden involved in revalidating any process changed for the purpose of improvement. The industry, as a result, is still largely focused on manual inspection for quality control. In this context, it is interesting to consider that the number of drug recalls has more than doubled in recent years (4). Although it is also true that the number of drugs on the market increased between 1998 and 2002, the reject percentage in the pharmaceutical industry ranges from 5 to 10%, compared with 0.0001% (1 ten-thousandth of a percent) in the semiconductor industry. This reject percentage costs the pharmaceutical industry approximately $4.5–9 billion per year (4).  

Although research and development (R&D) is generally considered a major cost for the industry, manufacturing quietly accounts for more than twice the expense of R&D—representing, on average, 36% of a pharmaceutical company's costs (2) (see Figure 1). The true cost of manufacturing becomes even more apparent when one considers the portion of manufacturing costs attributed to non-value-added activities and waste: 80% and 50%, respectively (2). 

 Figure 1: Estimated breakdown of manufacturersÃÂ´ spending. Contrary to popular belief, manufacturing accounts for more than twice the expense of research and development (2).			

FDA's renaissance: opportunity for change

The good news for pharmaceutical companies is that they may soon enjoy regulatory flexibility that will give them the freedom to progress from the 

 into a new era of quality, productivity, and efficiency. In recent years, FDA has recognized that the industry is strangled by controls that impede manufacturing advances. FDA also has acknowledged that IT systems can improve processing efficiency while helping companies attain and maintain a compliant state. In a recent white paper, The Economist Intelligence Unit explains this change: 

"The FDA discovered that pharma companies were freezing their manufacturing processes based on approved Standard Operating Procedures (SOPs) on the assumption that they could control the quality of raw materials at the front-end and catch any defects through inspection at the back-end. However, this method of controlling quality doesn't take into account the day-to-day variation in raw materials, the aging of manufacturing equipment, or the institutional knowledge of staff. 

Dependency by drug companies on "quality by inspection" runs counter to decades of improvements through 'quality by design' among other manufacturers. (5)" 

In recent years, FDA has also begun promoting a risk-based approach, focusing on inspecting processes with the highest potential to risk public health and sites with spotty compliance records. It is also working to ensure that risk mitigation strategies are in place and that companies with clean records are rewarded with more freedom to change processes.  

Process analytical technology (PAT) is an important part of FDA's quality-by-design focus. PAT provides a process and technical tool kit for building-in quality improvements on the factory floor. FDA defines PAT as: 

"a system for designing, analyzing, and controlling manufacturing through timely measurements (

 during processing) of critical quality and performance attributes of raw and in-process material and processes with the goal of ensuring final product quality." (6) 

To leverage PAT, a manufacturer must be able to monitor the status of ingredients and a batch as they move through various manufacturing and distribution steps. Nonetheless, internal,  regulatory, and operations data are often fragmented, and companies often have separate data files in different IT systems at various sites. This siloed approach precludes a comprehensive view of the enterprise and a quality-by-design focus. 

Information technology is helping manufacturers gain enterprise-wide visibility into their operations to enable more efficient compliance and improve operational efficiency, and PAT implementation. By implementing comprehensive IT solutions, pharmaceutical companies can: 					

 A key to streamlined compliance is complete confidence in the integrity of an enterprise's supply-chain, manufacturing, and distribution data. A single source of data, which replaces information silos, can significantly improve confidence in the data. By eliminating duplication and outdated information, a single data source accelerates decision-making and lowers administrative costs. 

A single data source also provides a clear audit trail, which reduces risk. For example, if a bad lot of drug product is introduced to the market, a manufacturer can quickly establish where the lot was produced, which equipment was used, the source of the ingredients, and the locations to which the compound was distributed. A single source of data eliminates the need to synchronize multiple sources of redundant data and manage various technologies—which increase risk and complexity. This advantage is especially critical in regulated industries, which must review data across operations quickly and effectively in a regulatory agency audit. 					

Capture more data from in-line technology.

 Adopting PAT allows companies to capture and process in-line data, which can help them understand the effects of raw materials on the chemical and physical properties of drug products and then use that information to improve formulation and processing. Thus, by using PAT to collect data from every part of the supply chain and manufacturing process, companies can understand sources of product variability. 

For example, a probe might capture the particle-size distribution of a batch during a granulation process. To make adjustments to improve product quality or consistency, the manufacturer must determine how the particle-size distribution compares with previous batches and standards—a process that depends on capturing and analyzing in-line and benchmarked data. Integrated IT systems available today enable manufacturers to capture such secure, analyzable, and actionable data that can transform their operations.					

Increase automation and build quality into the process

. Process and workflow automation—which allow manufacturers to build quality into a process—is IT's single greatest contribution to streamlining compliance. An integrated IT infrastructure enables management to rely less on manual checks—which present greater risk and variability—and more on automated checks that can be audited easily by regulatory agencies. For instance, automation can enforce electronic signature checkpoints during batch processing (see Figure 2) and automatically notify key personnel of nonconformances so that reviews can be undertaken quickly.

Figure 2: Automated controls and approvals help build quality into the product lifecycle. Information technology systems can streamline and improve compliance by automating controls and approvals. Red checkmarks indicate checkpoints for 21 CFR Part 11-compliant electronic records.										

Automation also can help standardize, implement, and enforce business processes and procedures. Traditional barriers to internal process controls have included varying working practices for the same procedure; unclear organizational structure and responsibilities; multiple and conflicting sources of data; and manual processes, including physical signatures for approvals. IT can drive automation that standardizes business processes and procedures; establish and document enterprise-wide organization structure and responsibilities; and create a single source of truth—all of which can streamline compliance and enhance operational efficiency.  

With effective IT systems, automated systems can be validated more quickly and cost-effectively. Today, many organizations still rely on the "brute force" approach to compliance, which involves voluminous manual processes and recordkeeping. With the right blend of technology and administrative and procedural controls, companies can begin to automate compliance and build quality checks directly into the workflow.  

IT and automation, however, do not replace the need for ongoing training. To achieve and maintain compliance, organizations must educate their employees regularly about the procedures and systems with which they work. Even FDA concedes that no system is perfect, but the right combination of procedures, administrative controls, secure systems, and employee training implemented in a pragmatic manner will stand up to a rigorous audit. 

Greater automation reduces compliance and validation costs because standardized workflow and controls can be built directly into a process (see Figure 3). For example, a manufacturer can dictate that a batch requires an electronic signature before continuing to the next step in the cycle. In materials management, automation can enforce business rules that require materials to go through certain quality tests before they reach a customer, instead of relying on paper documentation that testing was done. Automating controls also reduces complexity, redundancy, the potential for operating error, and, ultimately, waste. 

Figure 3: The benefits of automating compliance. Greater automation can reduce compliance and validation costs by standardizing workflows and controls directly into a manufacturing process.									

 Information technology that delivers a single source of truth and automates processes can help companies quickly identify and mitigate potential risks in several ways. First, an integrated IT infrastructure that enables the visibility of supply-chain, manufacturing, and distribution data across the enterprise allows organizations to spot exceptions more rapidly, thus facilitating root cause analysis and corrective and preventive actions. With enterprise-wide visibility, managers can quickly spot when something out of the ordinary happens (

 an out-of-tolerance in-process control value) and build an analysis thread so that root-cause analysis can occur. The same integrated system can enable the manufacturer to restore all noncompliant processes or links in the chain and document all communication that has occurred around such events. 

In the case of a problem or sabotage, an integrated IT environment allows manufacturers to gain rapid access to lot tracking. It can also be used to efficiently track maintenance and recalibration of plant floor equipment, which represent potential areas of risk.

 Paper records are cumbersome and expensive to circulate for review and approval when multiple staff members or departments are involved in the process. This challenge is compounded in a global enterprise in which stakeholders are dispersed across many countries. Faster and cheaper product development, manufacturing, and quality assurance turnaround are possible with the electronic routing of signature requests anywhere—instantly.

Whereas paper records are local and isolated, electronic records can be stored in a single, secure, globally accessible database. Individuals with proper credentials can access important information in the electronic records quickly and easily from anywhere in the world.  

Regulations require that organizations retain manufacturing records for at least one year after the product batch expiration date, which is often several years (7). Thus, it is easy to see how maintaining  production batch records alone—even for a short-lived product—can become quite cumbersome. Because individual batch records can exceed 100 pages, storing these records electronically saves space and reduces cost. 

Electronic recordkeeping also improves accuracy. Apart from rigorous and time-consuming manual checks, there are limited ways to prevent users from entering invalid data on paper forms. Sophisticated electronic record systems, however, can reduce data errors by providing users with lists of appropriate values from which to choose and by validating data formats before accepting or saving the data into files or tables. 

In addition, electronic records facilitate advanced searches and analysis. Information on paper is static and standalone. With paper records it is also very difficult, or even impossible, for organizations to find trends. Enterprise systems based on advanced relational database management systems allow managers to search data records to find trends and patterns across many records. 

Search vast quantities of data to reveal trends that can drive compliance, quality improvement, and increased operational efficiency. 

Many companies possess massive quantities of data on processes as far ranging as purchasing office supplies and gas chromatography. Many, however, cannot analyze or interpret the paper-based or siloed information to yield important trends needed to make informed regulatory and manufacturing decisions. 

A single source of data, coupled with advanced analytics, today enables analysts to run real-time reports that yield the kind of business intelligence that reduces risk, helps to ensure compliance, and improves operating efficiency. For example, a manufacturer can use advanced analytics to conduct quality analysis, risk assessment, yield analysis, and processing efficiency comparisons between multiple plants, to name just a few of the endless possibilities. 

Information technology can streamline compliance and increase operational efficiency and quality.

Business Efficiency and Regulatory Compliance

During the last few years, industry has been focused on having validated computer systems. But, computer validation is not a new task, and the regulations demanding validated computer systems are not new either. The big questions always asked are, "how much validation is enough" and "which systems do we have to validate?" The answers to both of these questions are contained in the activity of planning validation for the organization. Although the answers may sound simple, the solutions are often difficult and tedious to carry out. 

Both the European (1, 3) and US regulations (4) require planning of validation activities. Some of the regulations imply the planning of validation activities, where others explicitly refer to planning documents, such as in the European legislation, Annex 15. Guiding documents, such as the Good Automated Manufacturing Practice (GAMP) 4 (11), set forth requirements for planning documents. Because the European Union (EU) regulations and the GAMP guidance are the most comprehensive on the subject, these are the documents on which the interpretations in this article are based. 

Traditionally, planning validation activities has been dealt with on a case-by-case basis by producing validation plans for each system or for each validation project. In order to coordinate validation efforts throughout an organization and to plan activities and budgets at the highest level, management requires an accurate and timely overview. Fulfilling this need demands top-level planning documents, which, in this article, will be called the validation master plan (VMP).  

It is worth remembering that planning validation activities and creating a VMP are not exclusive to computer systems, but are meant to be included for all regulated systems and processes in some form. Compliance for all systems should create business benefits as processes are continuously optimized and downtime is reduced.  

This article discusses regulatory requirements and gives an interpretation of how they can be implemented by defining an approach to a VMP. This article focuses on computerized systems, but also covers the subject of the VMP from a general perspective. Many of the statements in this article are valid for general validation purposes. 

Validation activities should be planned. This statement makes sense; one would not be able to perform any activity satisfactorily without having a predefined goal and a prescribed way of completing the activity. It also makes sense from a business point of view because resources should be allocated, and validation activities should not get in the way of normal business flow and production (or 

 depending on your function and responsibility). 

The terminology that is used in the validation field is not as uniform as one might wish. The terms are very much subject to interpretation. In fact, the author of this article has seen a difference between the way industry terminology is used in the EU and the way it is used in the US. This article will attempt to settle one of the arguments by setting some of the definitions straight and by giving some interpretations that we can all live with and benefit from. 

The US Food and Drug Administration calls for a planning document in its guidance for process validation (9, 7). This planning document has been implemented by industry and is widely used for every validation project or system to be validated. The EU regulations (3) also reflect this planning for validation as an essential part of the regulations, but the system level or project level is only one tier in the organization.  

Validation activities should be planned in several layers, and adequate procedures and controls must be in place for each of these layers. In order for any organization to work successfully, strict and effective planning is required on all levels. The goal for an organization must be to have the appropriate level of control for each layer of validation activity. That is why management calls for a tool to create an overview of the validation activities required within the organization in order to plan and prioritize resources. This tool is what in Europe is known as the validation master plan (VMP). 

From the literature, it is evident that the term VMP is often used in the US for the planning of validation activities of a specific project or system (15, 10, 14, 12, 18). The EU regulations (3), the Pharmaceutical Inspection Convention/Cooperation Scheme (PIC/S) Guidance (16,17), as well as the GAMP 4 Guide (11), however, use the term for a higher level document covering the entire organization, and this is supported by Kropp as well (13).

Where the US regulations are a bit vague on how companies should document control of their validation planning, the EU regulations and GAMP 4 are much more specific on how to accomplish the expected level of control.

Considering the different layers of control, it seems sensible to develop some kind of document hierarchy that reflects the need for controls in the different layers. Such a model would take into consideration the difference in the level of detail between the layers and within the multitude of the documents. 

The more detail included in a layer of documents, the more documents will be needed to contain the level of detail wherein all the systems in the organization must be described. This is reflected in the model in Figure 1, in which the triangular shape of the hierarchy shows that one validation plan for a project or system can cover many protocols, and one VMP can cover many validation plans. 

 Figure 1: Document hierarchy of validation.			

In the EudraLex Vol. 4 Annex 15 (3) there is a very good list of what should be included in a VMP, and this is—almost to the letter—reflected in the GAMP 4 (11). The contents of these lists can be seen in Table I. 

Table I: Required contents for a validation master plan.			

This outlines the VMP as a high-level planning document needed by management to map out activities and resources. The VMP sets the scene for all of these activities by providing a procedural framework within which validation activities should be performed.  

The VMP should state how you intend to validate systems, including which methodology and which procedures to use. Furthermore, there should be a plan for validating every relevant system in the organization based on an inventory of systems.  

The contents described in the EudraLex are not necessarily required to exist in one document, because with the phrase "or equivalent documents," the regulation gives companies the freedom to document content as they choose.  

Organizations then face the challenge of implementing this plan in the most efficient and operative way without invalidating their own quality systems. The danger is that organizations produce a procedural document that is not supplemented or supported by the regular procedure system, and thereby risk overlapping or contradictory procedures.  

As outlined above, a very important part of the VMP is the validation policy or how the organization intends to approach each aspect of a validation. The terminology used can often cause discussion, and, to avoid any misunderstandings, the word "validation" is used in this article to encompass all documented testing activities related to implementing and improving systems, including all qualification activities. Definitions of the terms "validation" and "qualification" as taken from the EU and US regulations can be seen below: 

The first question to look at is not, however, "how to do it," but rather, "what are we looking at?" In many cases, validation ends up being a paperwork exercise because the scope, requirements, and approach to validation are not adequately defined up front. So, what are we looking at? The important thing is to ensure that business processes run consistently, produce the desired output, and that we are able to trust the consistency of that output. One way of illustrating that is by applying a process model to validation thinking (see Figure 2). 

Figure 2: An illustration of some of the factors and subprocesses that influence the overall manufacturing process in a pharmaceutical organization.			

Many factors and subprocesses influence the overall manufacturing process in an organization. The goal must be to have an overall process that is validated. No one is able to "eat this elephant" in one bite, and the only way to get this overall process validated is by validating every subprocess and the factors influencing them. This is illustrated in Figure 3. 

Figure 3: An illustration of a subprocess and the factors influencing it. The gray square designates a computerized system.			

Sometimes a computer can be one part of the factors influencing a given subprocess. Then the system supporting the process is considered a computerized system.  

Computers can be qualified separately, and that is what is done when qualifying the platform, hardware, and installing the software, but it does not make sense to claim you have a validated computer system without looking at the process the system supports. How can you prove that the system will give the expected result when used in the process if the process has not been taken into consideration?  

The process approach makes it possible to take a risk-based approach to validation. You may be able to cut down on validation efforts in areas less significant to the process.  

The risk-based approach is not an easy path to take, and it requires considerable effort up front. It requires a very thorough knowledge of the processes supported by the system, understanding of how different factors influence the process, and familiarity with the behavior of the system during the process.  

Learning about systems like this will, in the end, be a valuable experience for the organization. Using this information well is the essence of quality management and will lead to a better quality process. It will open the organization up to continuous process and system improvements, which, in the end, will lead to reduced downtime, and thus will save money. This optimization does not happen overnight, and it must be documented. The trick is to document wisely. 

The implementation of systems must be done according to a lifecycle approach, taking the entire lifecycle of the system into consideration. If not, you may find yourself with a system that works beautifully at installation, but ends up killing the process. In other words, systems and processes change over time, and system implementation should be prepared for change.  

There are many approaches to lifecycle models. One of the most well known is the 5-model proposed by the GAMP forum (11). The GAMP 5-model, in itself, does not fully meet the model for the entire lifecycle of a computerized system. A modification of the GAMP model, however, can solve this problem as can be seen in Figure 4, where the model reflects the project-like nature of implementation and the cyclical nature of change handling. 

Figure 4: A lifecycle model based on the GAMP 4 model. This chart takes the full life-cycle of the system into consideration. It can be seen as a flattened V-model in which the change-control loop is illustrated and can lead to varying levels of requalification. The figure also illustrates that the organizationÃÂ´s approach to the entire lifecycle should be reflected in the VMP. The steps of process development and process validation have been included to emphasize that these steps should be taken into consideration in the VMP. Although usually they are not part of a specific system or equipment implementation, they usually do form, however, the reason for acquiring the system. 			

The VMP must reflect the organization's approach to all the steps of the lifecycle, including change control. Procedures should be in place for the documentation of every step as well as the documentation describing how the different steps are aligned and work together. This document also should include who, in general, is responsible for each step. The lifecycle approach is not specific to computerized systems and may be applied to any kind of system. 

The model in Figure 4 can be seen to include a timeline, but it does not reflect that a validation of, for instance a laboratory system, consists of several steps where some things should be considered separately whereas other things can be done jointly with great benefit.  

In the case of a laboratory analyzer, the hardware can usually be tested partly by using the software and 

 so it does not make sense to look at the software as something separate and do the same testing twice. The timeline illustration in Figure 5 shows how the different steps can be combined to reduce the validation effort. 

Figure 5: A validation project timeline illustrating how the various steps overlap and can be combined with benefit.			

A uniform way of handling documentation is beneficial for an organization, and thus documentation format and approach to the various steps in the lifecycle should be addressed.  

This may seem like a waste of effort to some, because the documentation can be read no matter what format it is in, but a uniform approach to documentation makes future use of the validation documentation much easier. Using this type of formatting, one can always find a specific piece of information in the same place in the documents. Furthermore, the uniform format will make it easier to ensure that all items have been covered, and review will be made significantly easier once the organization has grown accustomed to the uniform format.  

The documentation should be structured, and the hierarchical structure of the documentation should be described in the VMP. All that has been designed or foreseen in the validation plan for a specific project should be answered and discussed in the validation report. A similar structure should be found on all levels of the documentation hierarchy. The expected flow of documents should follow this hierarchy through the different levels of detail, as illustrated in Figure 6, where the highest level of detail is naturally observed during the execution of validation activities. 

Figure 6: Document flow and hierarchy of documents. Documents generated before validation are always directly referred to after validation in a document with a similar level of detail. The validation master plan is the top document and provides a framework for all the other documents.			

Once the approach to validation has been established, the next big question comes up: how much do we really need to do? The answer is, on the one hand, fairly easy: "enough!" But that answer is not very helpful when you have an organization full of systems that all need validating. The more helpful answer would be "that depends," as any consultant would say. This hits the core of the matter in a risk-based approach.  

Systems must be assessed in different ways to estimate how critical they are to the organization and the processes and to provide prioritization of the different systems, because everything cannot be done at once. The VMP should describe the different assessment methods that an organization uses to evaluate risk related to systems and to prioritize those systems. The most important of these assessment methods commonly used in industry include: 					

GXP (Good Manufacturing Practice, Good Clinical Practice, Good Laboratory Practice) risk assessment

Coordinating validation efforts throughout an organization requires an accurate and timely overview and a validation master plan (VMP).

Computer Validation Master Planning "Validation Strategies"

Although the pharmaceutical industry has pioneered information technology as a research and development tool, it has consistently lagged behind other industries in using technology to automate and streamline manufacturing processes. Although in some cases, massive investments in drug discovery technology have yielded successful new products, inefficient production processes have prevented companies from meeting market demands quickly and cost effectively. 

As the US Food and Drug Administration's Center for Drug Evaluation and Research has observed, "While Americans have the highest quality of drugs in the world, the process used to produce them can be expensive and wasteful" (1). Government and industry initiatives addressing this problem attribute much of that inefficiency to limited automation and point to manual recordkeeping and information collection as major contributors leading to the industry's poor manufacturing-efficiency record. Meanwhile, the pharmaceutical industry accepts equipment use rates that hover below 40%, a figure no other major industry tolerates, and batch quality failures range from 5 to 15%. With batches worth as much as $1 million apiece, these failures add up to significant loses. By comparison, the semiconductor market, which dealt with similar process problems 25 years ago, currently maintains waste well below 1%.

The industry's manufacturing inefficiency is a result of three factors:  					

poor process understanding and control, which causes lower yields and production delays as a result of subsequent quality control procedures; 

inefficient, voluminous, paper-based production workflow, which produces very slow set up, production, verification, and so forth; 

the chronic uncertainty of demand in the consumer market.

These factors are a recipe for supply-chain inefficiency that has yielded average inventory turns of 3–5 

 50 for worldclass manufacturers in other industries. The pharmaceutical industry's evolving economics won't allow companies to continue in this vein. Consumers already are balking at the high cost of pharmaceuticals. Neither they nor government regulators are likely to stand for steadily increasing prices caused by manufacturing inefficiency. Markets are becoming more competitive, forcing companies into a new production paradigm that demands greater agility than today's model can provide. In addition, companies need more products in the market and higher profit margins on each product. That requires a production paradigm based on smaller batches produced in less time.

FDA identifies process analytical technology (PAT) as the best means for improving pharmaceutical industry production processes. FDA defines PAT as "a system for designing, analyzing, and controlling manufacturing through timely measurements (

 during processing) of critical quality and performance attributes of raw and in-process materials and processes with the goal of ensuring final product quality" (2). In other words, PAT is a form of in-line quality control that allows small, real-time adjustments to be made to a batch to maintain its quality and keep its expected process completion on schedule.

PAT is a parallel effort to the longer-established electronic batch record (EBR) movement, which focuses on using one or more network-based computer systems to replace paper batch records. In the same way that PAT makes production more efficient than the typical postprocess quality inspection, EBR makes regulatory compliance more efficient by consolidating and organizing data that companies once had to manage manually with paper. PAT systems themselves produce critical electronic batch records.

PAT and EBR both require highly reliable point-of-production data collection and data processing. The EBR system cannot have any breaks in the regulatory record chain or the batch in question must be discarded. PAT requires manufacturers to record process data as well as the adjustments that are made to ensure batches viability. PAT and EBR applications must operate in a continuous manner to electronic record gaps that reduce their value-add to virtually nothing. Without combined continuous availability of computer, network, and storage systems, PAT systems could be less useful than manual processes.

Although forward-thinking companies are considering adaptation of PAT and EBR systems, most are unaware of how heavily these systems depend on continuously available information system infrastructures. This article examines the current  pharmaceutical IT landscape, including how PAT fits into the picture and how a continuously available infrastructure is the mandatory foundation of a PAT implementation.

A PAT system consists of sensors networked to computer systems that run analytical applications for processing raw data into real-time knowledge about a batch. PAT systems can have their own sensor arrays or they may import data from existing production-line controllers.  

Many of the building blocks for PAT systems already exist in pharmaceutical IT infrastructures or companies are developing them as part of EBR deployments. Production-line controllers, computerized data historians, for example, are used widely to collect production line–level data. Many companies already are using PAT systems to manage and monitor specific steps within their production processes. PAT systems enable technicians to monitor the batch's condition constantly, rather than periodically by means of manual tests. Technicians use a PAT system's knowledge to modify batches in real-time to prevent spoilage and serious delays. For example, sensors on the production line feed a steady stream of pH readings into a mathematical PAT model. The PAT system detects a significant drop in the batch's acidity and notifies a technician in real time. The technician corrects the problem and most likely saves the batch from spoiling. More automated systems are making their way into production facilities, where adjustments to the process are done automatically.

Delays in the overall production process are just as much of a problem for pharmaceutical companies wanting to switch to a more flexible model of quickly moving smaller batches through production. PAT systems and other data-collection technologies deployed as spot solutions don't help companies' overall production throughput. Although PAT-enabled steps of the production process may be more efficient, the production line as a whole may not. For example, the automotive and semiconductor industries have been using PAT-like technology (SPC, advance process control, 

) since the 1970s, but these industries didn't see overall production throughput improvements because such implementations focused on specific operations rather than whole production-line throughput.

A locally deployed PAT system reacts to problems on a small piece of the production line, but it doesn't help the company trace the source of problems. In the pH-monitoring scenario described previously, leveraging the PAT system's knowledge of process parameters while making required adjustments upstream ("feedback") and downstream ("feed-forward") in the production process can not only increase batch-process efficiency but also provide less drop-out in postbatch or secondary manufacturing operations. Using this information throughout the production environment requires an information system that can span the production site. Without a system providing constant feedback to production dispatching, for example, batches could be started with inherent raw material or processing problems.

Companies that opt to implement PAT systems and link them to an end-to-end production management system require a continuously available data networking infrastructure in which every component—including servers, data storage, and applications—has been "hardened" to prevent crashes, unacceptable performance, and so forth, or to provide tolerance to such conditions. Conventional computer system network infrastructures haven't been specifically designed for such situations and, therefore, do not provide the reliability that pharmaceutical production demands.

In most industries, information systems that run 97–98% of the time deliver excellent performance. In the pharmaceutical industry, a PAT implementation that's down 2–3% of the time creates huge monetary losses, disrupts supply to the market (leading to lost revenue), and noncompliance risks. Every failure is a potential for a break in the regulatory record chain, a breakdown in the production schedule, or a trashed batch that may be worth millions of dollars in active pharmaceutical ingredients facilities. Without uninterrupted operation, PAT solutions will not pay off as a cost-effective, risk-based approach to manufacturing efficiency. Therefore, the IT infrastructure that supports these applications must exceed standard corporate benchmarks of reliability, availability, and uptime.

There are many IT product and service vendors that tout phrases such as "high availability," "high reliability," and "continuous availability" for their products and services, but few of them provide high availability (99.999% or better uptime). Server clusters are a good example. Clusters are the most commonly cited high reliability solutions. In clusters, pairs of servers linked by clustering software operate as a primary and as a backup. If the primary server fails, the software shifts the processing load to the backup server.

The various clustering technologies suffer from common weaknesses: complexity, cost, and unproven reliability. To meet pharmaceutical manufacturing's quality and regulatory requirements, each computer system requires laborious, proper change control and validation. Clustering software requires duplicate control records and custom scripting, which must satisfy on-going operational qualification demands to test the cluster's functionality, in addition to the relatively simple installation qualification and maintenance necessary for typical hardware components such as storage systems and network devices. Clusters require two servers, which increases management and cost. Clusters run on enterprise-class versions of operating systems instead of relatively inexpensive versions. The costs of additional compliance activities (

 operational qualification) add up quickly. Finally, a cluster is a custom-configured set of computer systems (hardware and software), not one that a company can plug in and run, and configuration is expensive and time consuming. 

Aware of the challenges associated with clusters, pharmaceutical companies have begun exploring fault-tolerant servers that are essentially two servers operating in lockstep inside a single chassis. Until recently, fault-tolerant computers have been available only in the realm of "big iron"—highly funded corporate data centers that have the budgets and staff to run large legacy systems. In the past few years, however, the market has seen an emergence of cost-effective fault-tolerant computers that run the commercially available operating systems used in pharmaceutical manufacturing. Such infrastructure components can be purchased off the shelf with built-in, factory-tested, high availability capability. Like their network and storage counterparts, they only require installation qualification, which significantly simplifies validation and maintenance. Furthermore, only one version of the operating system is required. Some low-end versions even run the less-expensive server operating system configurations (as opposed to the enterprise versions). This form of fault tolerance is ideally suited for the regulatory, cost, and management burdens of pharmaceutical manufacturing.

Whether it's clusters or fault-tolerant computers, however, vendors who define availability in terms of a single network element are only addressing part of the continuous availability problem space. True continuous availability of a networked computing environment extends beyond the computer system. It requires looking at the server, network, storage, and database environment as a whole. The concept of creating a "continuously available" infrastructure does not begin and end with a single component but treats the entire flow of information across these components as a potential problem—including the software applications and supporting software components. It is critically important to leverage fault-tolerant hardware in an infrastructure on the basis of appropriate risk evaluation. It is just as important, however to monitor the performance of the entire plant IT environment to prevent failures and to manage the lifecycle (evaluation and change control of patches, appropriate validation processes, 

) of hardware and software components to ensure the integrity of the infrastructure.

PAT systems, supported by continuously available network infrastructures, have an enormous potential upside for pharmaceutical companies. Assuming that a single drug at one site generates $1 billion in revenue, even a one percent improvement in yield is significant. Across the industry, a one percent improvement could save at least $400 million annually, according to a 2004 FDA Science Board meeting presentation (3). As a component of broader initiatives to improve pharmaceutical production (

, Six Sigma and quality management systems), PAT can be beneficial and even more extensive.

FDA's efforts to develop a regulatory framework for PAT will drop any compliance fears of PAT adoption. Advances in sensor technology will improve front-line data collection, enabling companies to monitor an ever-growing set of parameters that contribute to product quality. PAT application logic and mathematical modeling already are mature from years of development for spot applications in pharmaceuticals and other industries. The remaining crucial component is a continuously available IT infrastructure to unify these elements. In addition, to gain the speed, efficiency, and constancy that computerization offers, companies must use systems they can trust to collect, process, and distribute data in a constant upstream–downstream flow. Such systems are commonly referred to as manufacturing execution systems and can take the point-process improvements of PAT and leverage them into an overall production quality and throughput engine. PAT is a first important step, but to meet the small batch, higher product diversity needs that are making their way into pharmaceutical company business plans, it must be part of a total quality and throughput agenda.

 is the director of the life science practice at Stratus Technologies 111 Powdermill Road, Maynard, MA. 01754, tel. 978.461.7000, 

CDER 2001 Report to the Nation: Improving Public Health Through Human Drugs

www.fda.gov/cder/reports/rtn/2001/rtn2001.htm

PAT — A Framework for Innovative Pharmaceutical Development, Manufacturing, and Quality Assurance

Continuous Quality Assurance for Improved Business & Process Performance in Pharmaceuticals (Proceedings)

 (International Quality and Productivity Center, London, UK, July 1, 2005).

To implement process analytical technology systems into the current information technology landscape, manufacturers will need to adopt continuously available systems and infrastructures.

Process Analytical Technology: Real-Time Reliability

This article describes how to adopt risk-based approaches for the validation of commercial computer systems used in the regulated pharmaceutical industry. This paper will help to guide readers through a logical, risk-based approach for computer system validation. It offers recommendations on how to define risks for different system and validation tasks and for risk categories along the entire life of a computer system. The scope of this paper is limited to Commercial Off-the-Shelf (COTS) systems and does not include risks typically involved during software development.  

The article contains two parts. Part one deals with risk assessment, in which we discuss approaches to categorizing computer systems into high, medium, and low-risk levels. (These levels serve as an example. Any ranking of levels of risk that is relevant to the product and the manufacturer may be substituted. The thought process of ranking is the same.) Part two offers recommendations for validation steps for the different categories as defined in part one. 

Computer systems are widely used in pharmaceutical industry for instrument control and data evaluation in laboratories and manufacturing. They are also widely used for data transmission, documentation, and archiving. When used in regulated environments they should be formally validated. The main compliance-related purpose of their validation is to ensure accuracy and integrity of data created, modified, maintained, archived, retrieved, or transmitted by the computer system. In addition, a computer validation, typically, is a pre-requisite to obtaining reliable system operation and the highest system uptime, which are business requirements of the industry. Depending on the complexity and functionality, validation of computer systems can be a huge task. 

The efforts for validation should be balanced against the benefits, which means the amount of work should be in line with the problems that can occur if the system is not fully validated. The mechanism to balance benefits against investments is risk assessment in which we define the extent of validation according to the risk a specific computer can have on data integrity, and ultimately, product quality and safety. The risk-based approach should enhance industry's ability to focus on identifying and controlling critical functions that affect product quality and data integrity. 

Industry task forces have recommended risk-based approaches for validation for a long time. For example, Good Automated Manufacturing Practice (GAMP) has a chapter in its "Guide for Validation of Automated Systems in Pharmaceutical Manufacture"(1). Also, the United States Food and Drug Administration has recognized the importance of risk-based compliance. This became most obvious when the FDA announced its science and risk-based approaches as part of the Twenty-First Century drug Good Manufacturing Practice (GMP) initiative in 2003 (2). 

"We will focus our attention and resources on the areas of greatest risk with the goal of encouraging innovation that maximizes the public health protection," said FDA Commissioner Mark McClellan at an FDA–industry training session (8). David Horowitz added, "there are two elements to a risk-based approach to inspections: We need to go to the right places and we need to look at the right things" (8). 

One reason for this risk-based approach is FDA's limited resources to inspect all manufacturing sites every two years.  

"We have over 6000 domestic drug facilities and the number of GMP inspections that we have been able to inspect has declined by about two thirds in the last 20 years. So we can't take the chance that we are squandering our limited resources on lower risk facilities. That would prevent us from doing a minimum level of scrutiny and oversight and working with the higher risk facilities," Horowitz said (8). 

In the meantime, FDA has begun to allocate its resources based on risk. For example, beginning in the fall of 2004, FDA began using a risk-based approach for prioritizing domestic manufacturing site inspections for certain human pharmaceuticals. This approach should help the Agency predict where its inspections are likely to achieve the greatest public health impact (2). 

The FDA is not only taking advantage of the risk-based approaches, but also encourages the industry to do so, for instance, in software and computer validation. The industry guidance on 

General Principles of Software Validation

The selection of validation activities, tasks, and work items should be commensurate with the complexity of the software design and the risk associated with the use of the software for the specified intended use (3).

The same guide has also specific recommendations on what is expected for lower risk systems:  

For lower risk devices, only baseline validation activities may be conducted. As the risk increases, additional validation activities should be added to cover the additional risk. 

The "FDA Part 11 Guidance on Scope and Application" states:  

We recommend that you base your approach (to implement Part 11 controls, 

 validation) on a justified and documented risk assessment and a determination of the potential of the system to affect product quality and safety, and record integrity.  

The most specific advice for risk-based compliance of computer systems came from the Pharmaceutical Inspection Convention's, "Good Practices for Computerized Systems Used in Regulated Environments" (5). It has several recommendations related to risks:  

For critical GXP applications, it is essential for the regulated user to define a requirement specification prior to selection and to carry out a properly documented risk analysis for the various system options. This risk-based approach is one way for a firm to demonstrate that it has applied a controlled methodology, to determine the degree of assurance that a computerized system is fit for its intended purpose.  

Risk analysis and evaluation of software and computer systems is a good tool to optimize validation costs by focusing on systems with high impact on both the business and compliance.

Pharmaceutical Technology-11-01-2005

FDA's New Labeling Requirements: The Importance of XML for SPL Compliance

Business Efficiency and Regulatory Compliance

Computer Validation Master Planning "Validation Strategies"

Process Analytical Technology: Real-Time Reliability

Risk-Based Validation of Commercial Off-the-Shelf Computer Systems