Pain-Free System Transition

By Dimitrios Saponas and Demetre Kolokotronis

© PHOTOGRAPHER: MYLIGHTSCAPES | AGENCY: DREAMSTIME.COM

IT Rides Off Into the Sunset

Retiring an information technology system doesn't have to be a headache

Retirement is the last phase in an information technology (IT) system'S life cycle (SLC) and must be performed to satisfy U.S. Food and Drug Administration (FDA) requirements for record retention and system validation. Retirement, or decommissioning, means the cessation of the use of hardware (HW) and/or software (SW), along with the migration or conversion of data. Unfortunately, this last phase, if it is performed at all, is usually done in a haphazard manner. When this occurs, both availability of records and compliance with regulatory requirements may be compromised.

Why and when a system is retired is up to the business owner and is, in essence, a business risk decision. Some considerations that influence decommissioning may stem from the following:

• Are the systems in question no longer supported by the vendor, or is the vendor no longer in business?

• Is upgrading more profitable in the long run? Will it improve throughput and output and/or reduce required resources and cost?

• Will the change further ensure part 11 requirements or enhance the quality of the end product or, at the very least, maintain acceptable quality and safety?

What the competition is doing can also fuel the need for change, potentially resulting in a loss of market share. The question is, therefore, whether or not to change. Retiring, modernizing, improving, or moving SW or HW used by IT or in production that is affected by good manufacturing, clinical, and laboratory practices (GxPs) must be a decision that respects the predicate rule requirements. There can be no compromise allowed. This discussion will focus on the IT requirements as they pertain to the decommissioning of electronic records, SW, and HW, including firmware (a computer program embedded in a HW device) and their SLC documentation.

All About the Records

All businesses in the medical device, pharmaceutical, cosmetic, and food industries must account for any activity related to the manufacture, production, and distribution of human and animal products destined for implant or consumption. The requirement to document all related activity is governed by the predicate rules, namely, the Code of Federal Regulations (CFR). The CFR is law in the United States and applies to all GxP-impacted products destined for the U.S. market.

These records are the hard copy and/or electronic copies that are generated and, at a minimum, are required to demonstrate adherence to the stipulated requirements set forth by the FDA. They also demonstrate that due diligence is exercised by all parties at every stage of the product'S manufacture through its receipt by the patient or end user. A company'S internal policy should clearly identify any records that are regulated, how they are to be maintained, and the length of time they are to be retained. The paper printouts or electronic records must meet all of the requirements of the applicable predicate rules.

The FDA may take a company'S business practices and decisions into account when determining whether predicate regulation and internal policy meet Part 11 requirements and record retention periods as specified in agency regulations (see "Part 11 and Record Retention," p. 49). The predicate rules imply that all SW-generated data and records must be readily available to an inspector. If the SW can no longer operate and be validated on current computer HW and operating systems (OS), it is a generally accepted-and perhaps easier-practice to maintain a validated version of the last computer system the given application SW and OS were run on. Effective and representative data migration and data conversion are expensive, time consuming, and, in most cases, not necessary if the requirements can be met by maintaining a working validated version of the original computer equipment, as discussed below.

The consideration of the validated state brings into question the validity of acquired GxP data. In order to authenticate and document the validated status of equipment at the time of its retirement, it must be proven beyond any doubt that the equipment was in its intended working state. This proof, in turn, provides confidence that at the time the equipment was removed from service, it was decommissioned with sound scientific evidence and that all results generated with the unit in question for the release of product were trustworthy and reliable. If this evidence is not gathered, all output from the unit since its last documented validated state can be called into question. As appropriate, final calibration and functional verification should be conducted at the time of system retirement.

When the time to decommission does arrive, a company must (at a minimum) follow an outline or plan similar to the one presented below. The detailed outline or plan must be explained in a company'S retirement policy.

Retirement Policy and Plan

It is good practice to have a company or corporate policy that addresses system retirements. Such a policy can serve as a road map to ensure that FDA requirements for the conservation and retrieval of GxP data are met. Moreover, the policy must consider activities for the retention of system documentation. These must demonstrate, at the time of retirement, the preservation of the validated state and proper operation with respect to intended use throughout the life of the system.

The system retirement policy must require that a retirement plan be generated for each GxP system. The policy must indicate how the retirement process is initiated-through a controlled notice or a change request/control process-as well as how the process is to be closed upon completion of all required activities.

The FDA may take a company'S business practices and decisions into account when determining whether predicate regulation and internal policy meet Part 11 requirements and record retention periods as specified in agency regulations.

The retirement plan (RP) is a written document that must be approved by all departments affected or be required in the company'S retirement policy. The effort that will be put into the activities outlined in the RP must be based on a documented risk assessment. At a minimum, the following topics should be considered when generating a RP.

1. Introduction

This section briefly explains the use of the system at the time of retirement and includes a brief description of its interfaces with other systems, SW, and components. A reason/rationale for conducting the system retirement should also be provided here.

2. Roles and Responsibilities

This section outlines the tasks that each participating department (system owner, IT, engineering, quality assurance, and so on) has to accomplish for the decommissioning/retirement of the system. The roles and responsibilities are determined on a per project basis and depend on a multitude of factors such as the type and complexity of the system and other specifics discussed below.

3. Record Requirement

This section documents what electronic records and data stored in the system must be retained in order to satisfy predicate rule record retention requirements. Working together, the system'S owners, users, and quality assurance (QA) can identify the records used to support GxP activities. The vendor and/or IT can identify the database tables containing the data required to generate the reports. As a note of caution, it is often easier to keep the original data. Another important consideration is the retention of associated audit trail data and meta-data-data about the data-as well as other information. As stated previously, record retention is required by various predicate rules and must indicate how long the records will be maintained before they are allowed to be destroyed.

4. Documentation

Each system has a certain amount of documentation that comes with it. This includes vendor user manuals, system standard operating procedures (SOPs), commissioning and validation protocols and reports, specifications, logbooks, and more. Documentation found with the equipment files, such as calibration and maintenance reports, should also be considered. A list of all system documentation must be established, with an associated action to be performed for each. SOPs will have to be retired and removed from circulation, and all other documentation will be archived for a period at least equivalent to the duration of the records requirement. Documentation can be archived either on or off site but must be readily available for any auditor who asks to review it. The documentation can only be disposed of at the end of the required retention period; the manner in which this will be accomplished must be clearly explained.

5. Data Migration and Archiving

Data migration is needed when data from the retired system must reside on the new computer systems and the database management system (DBMS) or if its configuration is incompatible with the new systems. If the DBMS or the records file is compatible, simply copying and moving the data from one system to the other may be sufficient.

Data migration can be complex and requires planning with IT personnel knowledgeable in the specific tasks needed to ensure complete and correct migration of the data mapping. Data mapping reads data from the system to be retired, formats it to the new system'S formats and requirements, and then writes it to the new system'S databases. The complexity of the mapping activity depends on many factors, including types of DBMSs, ability to export data in a readable format, the need for conversion, and the number of tables or files to migrate. Data migration is usually executed using customized programs or scripts that automatically transfer the data.

Data archiving involves copying files and data to a storage device for long-term storage, with the intention of deleting or removing the data from the source media after it has been copied. Data archiving is usually performed when the data has record retention requirements but will not be required for day-to-day activities and/or is not likely to be asked for by an auditor/inspector. Data and records that are migrated or archived must maintain their integrity, so it is important to include all date-time stamped audit trails and associated metadata and to retain electronic signatures where applicable.

The company should also consider the need to conduct parallel operations for a period of time, utilizing the retiring system for official results while the new system is checked for areas of disparity. This period of parallel operation can be used for operator training and confirmation of validation.

The RP for the system must include a statement explaining whether or not the data from the old system will be retained. If data is retained, explain the strategy-migration or archival-and include the data that will be retained or not retained, again with a rationale. Migration activities must include testing after loading to verify that the data was accurately mapped, that it supports functionality in the new system, and that it is complete. The company should also consider the need to conduct parallel operations for a period of time, utilizing the retiring system for official results while the new system is checked for areas of disparity. This period of parallel operation can be used for operator training and confirmation of validation.

If the data migration is complex, a system-specific data migration plan should be developed, but the details of such a plan are beyond the scope of this discussion. If data is archived, the RP must define the media on which the data will be archived (e.g., CD, DVD, or hard drive), the storage format (e.g., backup or image), and the final destination where the data will be securely maintained. Testing should be performed on the archived data to ensure that it is retrievable. Making two archive copies of the data should be considered in case one cannot be read. Finally, the destruction of data from the retired system must be performed when the archiving and restoration processes have been determined to be satisfactory.

6. Hardware and Software

If the data is successfully migrated, the system'S HW and SW may not require retention, and their disposition must be covered in the RP. Some companies keep all HW and SW, while others dispose of them or recycle and reuse the HW for another application. It is the company'S responsibility to assess what needs to be done with retired HW and SW and to document this decision in the RP.

PART 11 AND RECORD RETENTION

The FDA'S regulations set out Part 11 requirements and record retention periods. The agency may take a company'S business practices and decisions into account when determining whether the following policies have been met:

• Data handling, storage, and retrieval-cGLP 21 CFR 58.81 (b)(10);

• Retention of records-cGLP 21 CFR 58.195 (b)(1)(2)(3) for five years after submission of the application or two years after approval;

• General record requirements-cGMP 21 CFR 211.180 for at least one year after the expiration date of the batch or, in the case of certain over-the-counter drug products lacking expiration dating because they meet the criteria for exemption under 211.137, three years after distribution of the batch;

• Retention of records-cGCP 21 CFR 312.57 (c) A sponsor shall retain the records and reports required by this part for two years after a marketing application is approved for the drug; or, if an application is not approved for the drug, until two years after shipment and delivery of the drug for investigational use is discontinued and the FDA has been so notified; and

• General record requirements-cGMP 21 CFR 820.180 (b) record retention period. All records required by this part shall be retained for a period of time equivalent to the design and expected life of the device, but in no case less than two years from the date of release for commercial distribution by the manufacturer.

If the data is archived, the company may need to retain SW to process the data. Likewise, specific HW to run the application SW and other supporting programs may be required. The considerations that determine the SW and HW items to be retained are many and should be addressed by the retirement team, with input from IT and system vendors (see "Should it Stay or Should it Go?," below).

The easiest method to retain HW and SW is to keep the whole system intact. This is rarely used today because it takes a great deal of storage space and does not allow recycling of HW systems. Another approach is to retain all installation media and re-install the system when electronic data must be retrieved.

It is good practice to have a company or corporate policy to address system retirements. Having such a policy in place can serve as a road map to ensure that all required steps and considerations are taken to make certain that FDA requirements for the conservation and retrieval of GxP data are accomplished.

SHOULD IT STAY OR SHOULD IT GO?

When retiring one information technology system and migrating to another, a company needs to decide which software and hardware must be retained to meet future needs. Below is a non-exhaustive list of questions that may help determine what to retain and what to dispose of:

• Is an operating system (OS) or are other program requirements needed to run the application software (SW)?

• Can the system run with a more recent OS version?

• Will the required original OS version be available to run the application when and if data retrieval is required?

• Does the system have a configuration that must be retained?

• Are there special hardware (HW) requirements?

• Can the OS or the application SW run with other or more recent HW?

• What is the possibility of accurately retrieving data if the original HW is not available?

The major drawback with this approach is that system configuration is not retained. The third and most common approach is to perform an image of the system'S hard drive. An image is a clone of the disk that allows for an exact copy of the hard drive or partition. The OS and all SW, programs, and system configurations can be saved with an image. Additionally, data can also be imaged and used as backup.

7. Other Considerations

A system that is retired may have operational or documentation ramifications on other systems. The RP should list, where possible, the other systems that are affected, what is impacted, and how it will be addressed. All training material related to the system and the retired SOPs should be archived. Additionally, employee training modules should be reviewed to remove any scheduling that is no longer relevant. Typically regulated computer system activities such as backups, periodic reviews, and performance monitoring should be stopped. The site computer-system inventory should be updated, and any vendor support agreements should be reviewed to determine if they are still applicable.

Users should be notified that a system is to be removed from active support and use. Depending on the environment, this notification can take many forms, including a change control or a memorandum that is distributed before any activities begin. The RP should explain how the process is initiated and what information it must include. This notification must ensure that all users of the system are aware that it will be retired and must be distributed with enough lead time to make any arrangements that are necessary. Once all activities in the RP are completed, another notification memo should be distributed to inform all parties that the system'S retirement is complete.

The final notification memo should be signed by a QA representative and should confirm that all required activities outlined in the RP have been accomplished. The RP and final notification should be stored as per company documentation practices. �

Saponas is a process and utilities engineer and Kolokotronis is director of compliance and quality systems, both at Validapro Biosciences, Inc. in Laval, Québec, Canada. Reach them at d.saponas@validapro.com or (450) 668-1144, or demetre@validapro.com or (917) 941-0177.

RESOURCES

1. International Society for Pharmaceutical Engineering (ISPE). GAMP 4. Guide for Validation of Automated Systems. Tampa, Fla.; 2001:59.

2. Institute of Electrical and Electronics Engineers, Inc. (IEEE). Std 1074-1997. Standard for Developing Software Life Cycle Processes. Washington, D.C.: Institute of Electrical and Electronics Engineers, Inc.;1997:57-58.

3. U.S. Food and Drug Administration. Title 21 Code of Federal Regulations (21 CFR PART 11). Electronic Records; Electronic Signatures. Washington, D.C.: U.S. Food and Drug Administration; 2000.

4. U.S. Food and Drug Administration. Title 21 Code of Federal Regulations (21 CFR PART 58). 5. Good Laboratory Practice for Nonclinical Laboratory Studies. Washington, D.C.: U.S. Food and Drug Administration; 2001.

5. U.S. Food and Drug Administration. Title 21 Code of Federal Regulations (21 CFR PART 211). Current Good Manufacturing Practice for Finished Pharmaceuticals. Washington, D.C.: U.S. Food and Drug Administration; 2001.

6. U.S. Food and Drug Administration. Title 21 Code of Federal Regulations (21 CFR PART 312). Investigational New Drug Application. Washington, D.C.: U.S. Food and Drug Administration; 2007.

7. U.S. Food and Drug Administration. Title 21 Code of Federal Regulations (21 CFR PART 820). Quality System Regulation. Washington, D.C.: U.S. Food and Drug Administration; 2007.