GAMP5指南作者Dr.Sion Wyn：10 questions on CSV

1.Q：How to distinguish between electronic data and electronic records? Could you please give an example?

A：GxP electronic data is data that is created, maintained or used by a process that supports the product life cycle. Some data becomes itself or is incorporated into GxP regulated records, which have a specific role to play in the regulatory framework, and are defined and required by the applicable predicate (basic) GxP regulation.

Regulated record are records required to be maintained or submitted by GxP regulations. These may be held in different formats; for example, electronic, paper, or both.

Regulated electronic records are regulated records maintained in electronic format. A regulated electronic record is a collection of regulated data (and metadata if relevant, i.e. if necessary to provide meaning and context) with a specific GxP purpose, content, and meaning.

Figure 1 illustrates how GxP is a subset of all data in a regulated company, how some of that data becomes or becomes part of a regulated record, and how some of those records have signatures applied to them – either electronically or by means of a handwritten signature (hybrid situation).

Example case Study: A validated GxP computerized system measures two million capsule weights for a single batch. It captures a large amount of GxP data. It also performs calculations and generates further temporary intermediate data. The system generates a summary report including minimums, maximums, standard deviations, and a curve showing that batch weight distribution falls within acceptable limits. The individual data points are not regulated (Part 11) records. The expectation of the predicate rule 21 CFR 211.188 is met by the final output, which is the regulated record.

2. Q：What is the basis for formulating a system backup strategy?

3. Q：Do all computerized systems require the development of a business continuity plan? GAMP introduces the concept of RTO. How can the RTO be assessed and determined for users, especially for production control systems?

[This answer addresses Questions 2 and 3 together]

A:The system backup strategy should be based on an understanding of the needs of the supported business process, considering types of potential disruption, impact of the system, and business requirements dependent on the system.

RTO and RPO are typically defined:

• Recovery Time Objective (RTO) - the duration of time and a service level within which a business process must be restored after a disaster in order to avoid unacceptable consequences associated with a break in continuity.

• Recovery Point Objective (RPO) the maximum length of time it should take to restore normal operations following an outage or data loss.

RTO should be based on how often a particular type of outage occurs, and how long it lasts, the practical consequences of an outage, and therefore the cost to the organization. Backup scheduling should be consistent with RTO.

Procedures should define the backup and restoration approach including the management of backup failures. Strategies may include replication to an alternative data center or cloud environment.

Backup technologies and/or services should be selected based on business need. Backup procedures and technologies should be verified to ensure correct operation. Contracts and/or SLAs should be in place with backup service providers.

Backup storage locations should be separated from the primary location. Geographical separation should be based on risk and consider natural hazards, e.g., earthquakes, hurricanes, fires

Elements of the strategy to consider include:

· Scope (e.g., data, records, configuration, applications)

· Approval responsibilities for restoration

· Backup identification (e.g., backup naming, labelling, inventories as appropriate for identification of backup content and timing)

· Backup approach (e.g., full, differential, incremental)

· Technologies and/or services selection as required to meet RPO and RTO

· Frequency of backup in response to RPO

· Logical as well as physical and separation requirements

· Monitoring and management of backup failures

· Periodic backup integrity verification

Business Continuity (BC) is the established process that guides organizations to respond, recover, resume, and restore to a defined level of operation during and following disruption. BC focuses on keeping businesses operational during a disaster, while DR focuses on restoring computerized systems and data to a known point (RPO) within an agreed time (RTO).

The regulated company should perform BC planning to actively protect its ability to continue to supply the public, maintain safety, and to comply with the regulatory requirements. Where DR plans can restore operations within an acceptable time, a separate BC plan may not be necessary.

4. Q：Is there any difference in validation strategies between open systems and closed systems? What are the main differences?

A：The distinction between Open and Closed systems was introduced in 21 CFR Part 11 in 1997. This distinction is no longer actively applied by the US FDA and is not used in GAMP guidance.

The distinction was based around whether system access is controlled by persons who are responsible for the content of electronic records that are on the system (i.e., the regulated company), or not. The distinction was effectively superseded in 2003 by the implementation of the flexible risk-based approach to controls as described in the FDA Part 11 Scope and Application Guidance.

As stated in that guidance, “We recommend that you base your decision on whether to apply [specific] measures, on the need to comply with predicate rule requirements, a justified and documented risk assessment, and a determination of the potential effect on product quality and safety and record integrity. We suggest that you apply appropriate controls based on such an assessment.”

Part 11 states that for open systems additional measures such as document encryption and use of appropriate digital signature standards (or similar controls) should be considered. This would be a natural outcome, where appropriate, of a risk-based approach such as advocated by FDA and GAMP and described above.

In any case the validation approach and strategy would be the same.

5. Q：What are the differences in the focus of verification for the Category 4 software software between production control systems, laboratory systems, and pure software systems?

A：For pure software systems the configuration activity is often focused on workflow logic options, dependent on the nature of the business workflow being automated. This may range from complex (e.g., ERP) to simple, e.g., EDMS, and the detail and the extent of the configuration specification and verification will vary accordingly. The focus is likely to be on the enforcement of the internal business rules, some of these traceable to regulatory requirements.

For production control systems there may be a significant element of integration with hardware components and equipment, which may require configuration specifically to deal with that aspect. Library functions may be selected, parameterized, and connected with branches and decisions. It is more likely that a Functional Specification may be required in this type of situation than with pure IT. There is likely focus on supporting the manufacturing process through secure processing and handling of CPPs (Critical Process Parameters) and providing accurate data to be incorporated in batch records.

The following characteristics are noted in the GAMP® Good Practice Guide: A Risk-Based Approach to GxP Process Control Systems (Second Edition):

· Requirements and specification documents relating to the control system may be shared with equipment, particularly for embedded process control systems.

· Specification documents owned by other disciplines often directly impact the control system design and configuration (e.g., Instrument loop diagrams, Process and Instrumentation Diagrams (P&IDs), Engineering Line Diagrams (ELDs)).

· For larger systems, there may be several suppliers requiring access to the same information.

· The structure of specification documents will be influenced by the phasing of delivery which may follow a horizontal or vertical design strategy (described in the GPG).

For laboratory systems such as LIMS there is likely to be a high degree of commonality between processes to be automated in specific examples of the various types of laboratories, but complexity and variety will be introduced by integration and interfacing with potentially a wide variety of laboratory equipment and other smaller systems. Data Integrity is an important focus area.

6. Q：For Category 4 and Category 5 software systems, what time will be more appropriate to conduct PQ, before or after the system goes live? What is the difference between PQ 、UAT and OQ? Could you please provide some examples?

A：GAMP 5 does not directly use the terms OQ and PQ but explains the terms in relation to the GAMP verification approach as follows.

For a pure IT system, the distinction between “OQ” an “PQ” is ambiguous and may be covered by various levels of Acceptance testing, e.g. FAT, SAT, UAT. Configuration testing may be considered as part of “OQ”. Much of what would be covered in “OQ” would have already been performed by the supplier of a Category 4 product during their product life cycle. Sometimes UAT is regarded as equivalent of “PQ” for pure IT systems.

For most category 4 and Category 5 IT systems, as much “PQ” should be performed before go-live, but sometimes (e.g. for large complex business systems) this is not possible due to constraints of resources, data, numbers of users etc. in the test environment, so some element of performance monitoring and testing may be performed after go-live, sometimes during a period of “hypercare”.

For most pure IT Category 5 applications the successful completion of developer testing and user acceptance testing will be pre-requisites for the system to go live.

Acceptance for process and manufacturing systems may be carried out in two stages, factory acceptance and site acceptance, and may be followed by a Final or User Acceptance Test stage.

· Factory Acceptance Tests (FAT) are performed at the supplier site before delivery to show that the system is working well enough to be installed and tested on-site.

· Site Acceptance Tests (SAT; sometimes called System Acceptance Testing) show that the system is working in its operational environment and that it interfaces correctly with other systems and peripherals

Acceptance tests may be leveraged in support of, or may form part of, but do not replace the need for, process qualification including Process Performance Qualification (PPQ) where relevant.

As described by FDA in discussing Process Validation:

“The PPQ combines the actual facility, utilities, equipment (each now qualified), and the trained personnel with the commercial manufacturing process, control procedures, and components to produce commercial batches. A successful PPQ will confirm the process design and demonstrate that the commercial manufacturing process performs as expected.”

7. Q：For SAAS (Software as a Service) systems, does the configuration function of the system need to be verified? If verification is required, what tests should be done?

A：For SaaS the expectation is that the configuration function of the product has been adequately verified within the supplier QMS and product life cycle, before engagement with the individual customers, and that from the regulated company perspective, what needs to be verified the correct configuration of the system, through the use of that configuration function.

The tests of the configuration function within the supplier QMS and product life cycle should verify that the configurability options delivered are accurate and complete and as defined in product specifications and the intended operational envelope of the product. During the supplier product life cycle it will be verified that it CAN be configured correctly. During the project/engagement process it will be verified that the configuration HAS been correctly applied to meet customer business needs.

8. Q：For software with a mobile end, what types of tests should be performed in the OQ (Operational Qualification)? In terms of user and data security risks regarding the mobile end, which aspects should be given the most attention?

A：The GAMP® Good Practice Guide: A Risk-Based Approach to Regulated Mobile Applications is recommended.

Mobile apps that are used as part of GxP operations at a regulated company, as a component of a GxP regulated computerized system, such as an interface to an instrument or control system should be addressed as part of wider system validation or qualification activities as defined

in the regulated company Quality Management System (QMS),but this requires taking into account the novel and particular aspects of mobile apps, and these are helpfully described in the Guide).

The Appendix on Mobile Apps Risk Landscape is extremely helpful In helping to define what controls are required, and therefore what verification activities should be considered to challenge those controls.   As stated, “Mobile apps share many of the risks associated with traditional server or PC-based applications; however, the nature of the mobile platform and environment may require specific controls to manage risks specific to mobile apps. This appendix presents the risk landscape with the intent of clarifying these new or different risks”.

The following are some (not complete) characteristics to consider for mobile elements of system testing:

· Interface, e,g, screen facilities (buttons, sliders, landscape versus portrait display, etc.), multi-touch gestures, accelerometer, NFC, etc., where used.

· Coverage of platforms (different models, different screen sizes, different operating system versions)

· Functionality

· Connectivity: (wireless, 4G or 3G, poor connection, no connection)

· Localization, including Time/Date:

· Memory warnings, and relevant actions and safeguards

9. Q：For software systems with good change control process, whether it is necessary to perform system revalidation? What aspects should be primarily focused on during revalidation? Is it necessary to conduct UAT testing again?

A：Following the GAMP approach, re-validation is NOT required under normal circumstances. The system should be maintained in a compliant and validated state through a combination of change management, configuration management, periodic review, incident and problem management and maintenance. This of course, depends on the initial system verification process being acceptable and effective. This may not always be the case with some legacy systems.

Re-validation is only applicable where a system was not initially adequately validated or has drifted seriously out of compliance through major uncontrolled changes impacting critical GxP requirements, and there is risk to product quality or patient safety, or other similar circumstances, including lack of control and lack of documentation update, including lack of upkeep of specification and user information. The system cannot therefore be regarded and demonstrated as being fit for intended use.

It would require a complete loss of control requiring significant remediation activity including re-specifying and re-verification to require the conduct of UAT again, if this has been successfully initially achieved as part of acceptance of the system for live GxP use.

10. Q：How to assess the impact of accumulated changes on a system developed under Agile model? What aspects should be considered during the assessment?

A：This topic is linked to regression testing and the creation and maintenance of a controlled set of regression tests that verify that changes, or additions, or defect corrections. have not adversely affected existing functionality, and the maintenance of the design integrity.

This requires continuous upkeep and improvement of the regression test suite, taking into account an analysis of the changes, and based on a clear definition and good understanding of the system/product design and architecture.

But ensuring the ongoing integrity of the architecture and design and good requirement management are equally as important as updating and maintaining the regression test suite.

Aspects that can aggravate accumulated change and cause problems include:

· Unclear or ill-defined requirements

· Incomplete or inconsistent requirements

· Ineffective requirements prioritization

· Lack of understanding of the underlying architecture and design due to lack of training, lack of staff experience or available documentation

· Unmanaged technical debt

In an Agile situation, and particularly in cases where there is a ML or learning component involved, it is important to define a strategy for ongoing performance monitoring to ensure that key business objectives continue to be achieved, by applying appropriate metrics/KPIs