GXP

Trustworthy Computer Systems | IVT

Peer Reviewed: Computer Validation


In previous written articles[1], [2] the author discussed the issues of the Good Manufacturing Practice (GMP) controls to preserve the integrity of critical electronic records and how to assess the effectiveness of the implementation of these controls. However, to ensure the integrity[3] of electronic records, it is essential that the system managing these electronic records[4] must also be trustworthy.

This paper describes the concept of trustworthy computer systems in a GMP regulated activity[5] and the regulatory requirements and key guidelines associated with trustworthy computer systems within the scope of the referenced competent authority. Examples of such computer systems performing GMP regulated activity are those to:

  • Make decisions on market release of drugs and, to create and retain market distribution records;
  • Create and retain manufacturing orders and manufacturing records;
  • Control/manage manufacturing processes and to retain relevant data;
  • Manage storage and inventory, and so on, of raw materials and products (including intermediates);
  • Control/manage laboratory instruments used for quality control (QC) tests and systems to retain QC test results and relevant data;
  • Control/manage equipment and facilities, including HVAC and water supply systems, and so on, which may have a significant impact on quality of products, and systems to retain relevant data;
  • Create, approve and retain documents (SOPs, Quality Standard Code, Product Standard Code, and so on.

This paper covers key requirements and guidelines of worldwide competent authorities, and related organizations (e.g., Pharmaceutical Inspection Convention (PIC) and the Pharmaceutical Inspection Co-operation Scheme (PIC/S) connected with trustworthy computer systems.

For the purpose of this paper, the terms and definitions given in 9000-3 and ISO 12207 are applicable. In the event of a conflict in terms and definitions, the terms and definitions specified in ISO 9000-3 apply.

 

INTRODUCTION TO TRUSTWORTHY COMPUTER SYSTEMS

Latest electronic records integrity issues from the regulated users uncovered by competent authorities have revived the dialog among the industry on the GMP controls around electronic records. There is a better understanding of the topic by the competent authorities and the regulated user[6] after United States (US) Food and Drug Administration (FDA) 21 CFR Part 11, Electronic Records: Electronic Signatures[7] became effective in 1997.

Nevertheless, to ensure integrity to the electronic records it is essential to assure trustworthy computer systems. Trustworthy computer systems are the first line of defense to protect the critical electronic records managed by these systems.

Trustworthy computer systems consist of computer infrastructure, applications, and procedures that:

  • Are reasonably suited to performing their intended functions; 
  • Provide a reasonably reliable level of availability, reliability and correct operation;
  • Are reasonably secure from intrusion and misuse; and;
  • Adhere to generally accepted security principles.

The driver of the computer systems validation process is to ensure an acceptable degree of evidence (documented, raw data), confidence (dependability and thorough, rigorous achievement of predetermined specifications), intended use, accuracy, consistency and reliability[8], or that the computer system is a trustworthy system.

In the context of electronic records integrity, the objectives of a trustworthy computer system are to ensure:

  • consistency of data; in particular, preventing unauthorized creation, alteration, or destruction of data (integrity);
  • that legitimate users are not improperly denied access to information and resources (availability); and
  • those resources are used only by authorized persons in authorized ways (Legitimate use).

 

COMPUTER SYSTEM SUITED TO PERFORMING THEIR INTENDED FUNCTIONS.

This is one condition that links the intended use[9] of computer systems and the functionality of the computer system provided by the developer. Trustworthy computer systems conform to the GMP controls and to the efficacy of the computer system to perform the prescribed operation.

Related with GMP controls, computer systems executing GMP regulated activities, should[10] follow the quality management system requirements of the International Organization for Standardization(ISO)9001 (e.g., ISO 9000-3), or equivalent acceptable development methodology[11] (e.g., ISO 12207, ISO 12119). As an example, the origins of the Good Automated Manufacturing Practices (GAMP) embraced ISO 9000-3.

The intended use of a computer system is established during the requirements analysis and settles in the requirements specification.

The requirements specification describes the required functions of the computer system and, it is based on a documented risk and GMP impact assessments. This specification must be managed[12] and the requirements contained traceable throughout the computer system life cycle (SLC) (EMEA Annex 11-4.4). The requirements specification is based on the inputs from many sources, including computer system users, quality assurance, applicable regulations, information technology, infrastructure architecture, potential data migration, engineering, safety and many others. Based on this specification, the system is developed or configured following the applicable best compliance practices transcribed as procedural controls.

The precise execution of an approved comprehensive quality management system enables both the regulated user and competent authority to have a high level of confidence in the integrity of both the processes executed within the controlling computer system(s) and in those processes controlled by and/or linked to the computer system(s) within the prescribed operating environment(s).

The evidence to demonstrate the conformance of the computer systems with the established process requirements and applicable regulatory requirements of computer systems performing GMP regulated activities is accomplished via the computer validation[13] process.

The definition of computer systems validation by PIC/S make reference to the “formal assessment and reporting of a computer systems validation.” This reference should be interpreted as requiring controlled documented methodology and records based on best compliance practices. The controlled documented methodology and records ensure that the regulated user has generated documented evidence (electronic and/or paper based) that gives a high level of assurance that both the computer system and the computerized system will consistently perform as intended, designed, implemented, verified, tested and maintained[14], [15].

The relevant requirements and/or guidelines about this topic are:

ISO 9000-3

Section 7.3.6.1 states that validation of software is aimed at providing reasonable confidence that it will meet its operational requirements.

US FDA

FDA considers software validation to be the confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended use, and that the particular requirements implemented through software can be consistently fulfilled. 

The computer validation process takes place within the environment of an established SLC. The SLC contains software engineering tasks and documentation necessary to support the software validation effort. In addition, the SLC contains specific verification and testing tasks that are commensurable to the risk associated to the computer system.

European Medicines Agency (EMA) Annex 11, Therapeutic Goods Administration (TGA)[16] and China SFDA[17]

According to the interpretation of the GAMP Community of Practice (CoP) Task Team[18], the 2nd principle in the EMA Annex 11, “The application should be validated; IT infrastructure should be qualified” reflects the GAMP 5 definition of computerized system validation as achieving and maintaining compliance with applicable GxP[19] regulations and fitness for intended use.

PIC/S PI-011-3, Association of Southeast Asian Nations (ASEAN) and Canadian HPFBI[21]

Some of the specifics PIC/S PI-011-3, intended for inspectors, may need some modification to account for the updated EMA Annex 11, but overall it remains a good resource.

Consistent with the US FDA expectations on software validations, PIC/S considers that computer validation is the formal assessment and reporting of quality and performance measures for all the SLC stages of software and system development, its implementation, qualification and acceptance, operation, modification, requalification, maintenance and retirement.

International Conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH)

The ICH Q7A GMP Guidance for API (Chapter 5) calls for the suitability of the computer system is demonstrated during an “appropriate installation and operational qualifications.

World Health Organization (WHO)

The Technical Report Series (No. 937, Annex 4. Appendix 5, “Validation of computerized systems”) establishes that the purpose of validation of a computer system is to ensure an acceptable degree of evidence (documented, raw data), confidence (dependability and thorough, rigorous achievement of predetermined specifications), intended use, accuracy, consistency and reliability.

Japanese MHLW

The Japanese Ministry of Health, Labor and Welfare (MHLW) published the Guideline on Management of Computerized Systems for Marketing Authorization Holders and Manufacturers of Drugs and Quasi-drugs in October 2011. The purpose of this guideline is to specifying the activities during development of computerized systems, validation items to verify such systems, and the activities to be observed during the operations of such systems with the purpose of ensuring that such systems perform as intended.

Brazil ANVISA

Article 572 of the Brazilian Agência Nacional de Vigilância Sanitária (ANVISA) rules on good manufacturing practice of medicinal products establishes that the extent of validation depends on a number of factors, including the intended use of the system, the type of validation to perform (prospective, concurrent and retrospective) and inserting new elements.

 

PROVIDE A REASONABLY RELIABLE[22] LEVEL OF AVAILABILITY, RELIABILITY AND CORRECT OPERATION.

The best application will not meet user’s need if it is unavailable. In the technical sense, availability is the measure of the percentage of time that an application is available for use. The typical end-user expects an application to be available 24/7/365. Anything else is deemed unacceptable. But up-time is not the only indicator of availability. Offutt[23] suggests that “using features available on only one platform” makes the application unavailable to those with a different platform. The user will go invariably go elsewhere. 

Maturity, fault tolerant, and recoverability are related with reliability or the amount of time that the computer system is available for use.

In the event of a system failure there should be a general procedure to remedy and restore the hardware or software from any situation to a correctly functioning and basic condition and to reconstruct the relevant data reliably[24] (EMA Annex 11-16).

The procedure to remedy and restore system errors should consider the following:

  • conduct error analysis
  • commission and carry out repairs
  • implement additional organizational measures (work around)
  • test software components
  • check stored data
  • reconstruct data
  • system release for re-use
  • documentation instructions

All performance requirements, including reliability and recovery, that the software must meet must be specified in the requirements specification.

Testing of the recovery related requirements include challenging the ability of the system to recover from programming errors, data errors, and hardware failures. If the recovery is automatic, re-initialization, checkpoints mechanism data recovery and restart should be evaluated.

Incidents related to computer systems that could affect the reliability of records should be recorded and investigated.

GAMP5 Appendix M4 (Section 3.1.14) provides guidance on reliability and error recovery.

The correct operation consists of those attributes of the computer system that provide full implementation of the required functions. The application-dependent algorithms consisting of manufacturing procedures, control, instructions, specifications and precautions to be followed within such automated systems are embodied in the computer program(s) that drive the computer. It includes those instructions to enforce process sequencing with significant impact on drug product quality.

The lack of operational checks to enforce event sequencing is significant if an operator's ability to deviate from the prescribed order of computer system operation steps results in an adulterated or misbranded product, and/or data integrity[25].

The relevant requirements and/or guidelines about this topic are:

ISO 9000-3

The operational environment requirements (Section 7.2.1.1) may include, but not be limited to, the following characteristics: functionality, reliability, usability, efficiency, maintainability and portability.

US FDA

The General Principles of Software Validation[26] establishes reliability as a quality factor to be addressed during the quality planning and clearly established in the requirements specification. 

21 CFR 11.10(a) requires computer systems reliable and performing the correct operation.

EMA and TGA

Annex 11-11 stipulates that during the periodic reviews the reliability of a computer system must be evaluated.

PIC/S PI-011-3, ASEAN and Canadian HPFBI

Understanding that the majority of the software used in the healthcare industry is developed by suppliers, PIC/S guideline stresses in the quality of the software engineering processes followed during the development of the software product by the supplier.

To have confidence in the reliability of the products, the regulated user should evaluate the quality methodology of the supplier for the design, construction, supply and maintenance of the software. Refer to GAMP 5 Appendix M2, Supplier Assessment.

After acquiring a system, software product or service, the regulated user needs to execute the activities, defined in the applicable procedural controls, to demonstrate the correct operation of the computer system associated components and the integration of the components.

ICH

There is no explicit statement related with the availability and reliability of the computer systems.

Implicit requirements linked with the correct operation of the computer systems can be found in the requirements associated with validation of computer systems.

WHO

Refer to the previous note related with the WHO in which reliability and correct operation are referenced.

China SFDA

As in the ICH, there is no explicit statement related with the availability and reliability of the computer systems.

Implicit requirements associated with the correct operation of the computer systems can be found at the Article 6:

“Computerized system validation, including application validation and infrastructure qualification, the scope and extent should depend on scientific based risk assessment. Risk assessment should adequately consider the scope and purpose of use a computerized system. Verification should be run throughout the life cycle of a computerized system.” 

Brazil ANVISA

As in the ICH and China SFDA, there is no explicit statement related with the availability and reliability of the computer systems in the ANVISA’s Rules on Good Manufacturing Practice of Medicinal Products in the Resolution of the Executive Board No. 17 (Title VII-Computerized Information).

Implicit requirements associated with the correct operation of the computer systems can be found in Articles 577 and 578:

“The system should include, where applicable, verification of data entry and processing.”

“Before starting to use a computerized system, one must test and verify the ability of the system to store the desired data, ensuring the technological infrastructure necessary to its full operation.” 

 

SECURE FROM INTRUSION AND MISUSE.

To avoid the intrusion into computer systems, physical and/or logical controls must be established enabling access to authorized persons only[27]. For those users allowed to access a computer system, the precise access level to the applications and resources must be assigned based on an authorization level. In all moments, it must be documented the creation, change, and cancellation of access authorizations and the level of authorization[28].

In order to minimize intrusion risks to computer systems, computers inputs and outputs (I/Os) must be monitored for the correct and secure entry and processing of data. One illustration of an I/Os monitoring is an intrusion detection system. This is a device or software application that monitors network or system activities for malicious activities or policy violations. These systems produce reports that can be used to strength the security controls.

The misuse of computer systems by the users can be remediated by the system owner implementing a training program of the intended use of the related applications and all computer resources must be established.

All intrusion and misuse incidents should be reported and assessed. The root cause of an intrusion and misuse should be identified and should be the basis of corrective and preventive actions.

The relevant requirements and/or guidelines about this topic are:

ISO 9000-3

During the review of the requirements, risk associated with security issues are to be assessed (Section 7.2.2.2). The management of the security controls is performed during the system development lifecycle. ISO 9000-3 recommends writing a plan specifically to manage the implementation of the security controls. During the operational phase the security controls are maintained and the effectiveness evaluated as applicable. 

US FDA

Overall, 21 CFR Part 211.68 symbolizes the US FDA security related requirements. Computer systems must have adequate controls to prevent unauthorized access or changes to data, inadvertent erasures, or loss.

According to the 2003 applicability to 211 CFR Part 11, 11.10(d) requires access to the electronic records in the computer system to authorized individuals only.

EMA, TGA and China SFDA

According to EMA Annex 11-12, physical and/or logical controls to restrict the access to the computer systems and data storage areas should be in place and based on a risk assessment. The user’s authorization levels and the changes to such levels must be controlled and documented. 

Similar to the 2003 US FDA 21 CFR Part 11 Guideline, high-risk computer systems managing critical data should implement audit trail functionality.

PIC/S PI-011-3, ASEAN and Canadian HPFB.

The PI-011-3 provides a complete section, Section 19, covering the security of computer systems.

Summarizing this section, the security of the system and security of the data is very important and, the procedures and records pertaining to these aspects should be based on policies of the regulated user and in conformance with the relevant regulatory requirements. It is very important for the regulated user to maintain the procedures and records related to the access to the system(s). There should be clearly defined responsibilities for system security management, suitable for both small and complex systems, including:

  • The implementation of the security strategy and delegation
  • The management and assignment of privileges
  • Levels of access for users
  • Levels of access for infrastructure

ICH

Section 5.43 calls for sufficient controls by the computer system to prevent unauthorized access or changes to data. There should be controls to prevent omissions in data (e.g. system turned off and data not captured). There should be a record of any data change made, the previous entry, who made the change, and when the change was made.

ICH Q7 requires in Section 6.6 a complete record of all raw data generated during each test using laboratory equipment. The information to be collected by test includes graphs, charts and spectra from laboratory instrumentation. A second person must verify this information for accuracy, completeness, and compliance with established standards.

WHO

The Technical Report Series (No. 937, Annex 4. Appendix 5) establishes that the security procedures should be in writing. Security should also extend to devices used to store programs, such as tapes, disks and magnetic strip cards. Access to these devices should be controlled.

Brazil ANVISA

Article 579 establishes that the entries and data modifications can only be performed by authorized persons.

  • Measures should be taken that do not allow unauthorized persons to include, exclude or alter data in the system and can be used for security measures, such as the use of passwords, personal code, access profiles, keys or restricted access to the system.
  • A procedure should be established for access management, defining how to issue, amend and cancel the passwords of persons who are no longer authorized to enter or change data in the system, including changing d.
  • Should be given preference to systems that allow registering attempting unauthorized access.

ADHERE TO GENERALLY ACCEPTED SECURITY PRINCIPLES.

Each predicate rule (e.g., 21 Code of Federal Regulations (CFR) Part 211.68(b)) or guideline (e.g., Guidance for Industry Computerized Systems Used in Clinical Investigations), requires/outlines appropriate security related controls over applications, infrastructure, and infrastructure components, to ensure that only authorized personnel have a hierarchy of permitted access to enter, amend, read, or print out electronic records and information stored within.

The following are essential practices relevant to the security of applications. The applications can be networked or stand-alone. If the application is networked, supplementary practices are contained in the next section[29].

  1. All applications must have a qualified authentication mechanism to control access (EMA Annex 11-Principle #2).
  2. Software “virus checking” must take place periodically to protect of the applications and data.
  3. Procedural controls must be established to specify the manner in which application security is administered (ICH Q7 Section 5.44).
  4. The process for setting up access to applications must be defined and executed by the appropriate application-specific security administration personnel. The technical preparation, education, and training for personnel performing administration tasks, and associated documented evidence, are a key regulatory requirement (EMA Annex 11-2).
  5. The management of the user application accounts is a key procedural control. This procedural control includes requesting the addition, modification, and removal of application access privileges (EMA Annex 11-12.3). The request is approved by the appropriate manager, is carefully documented, and submitted to the application security administration for execution of the request.
  6. There must be a procedure to grant temporary application specific access for personnel (21 CFR Part 11.10(d)).
  7. In the event that a user leaves the company, there must be a process to notify the appropriate security administration as soon as the employee departs (EMA Annex 11-12.3).
  8. A procedure must exist which defines the escalation process and actions to be taken upon discovery of unauthorized access (EMA Annex 11-13).
  9. A documented record of security administration activities must be retained.
  10. Procedures must exist to control remote modem access to applications via the applicable infrastructure[30].
  11. In cases where data or instructions are only available from specific input devices (e.g. instruments, terminals), the system should be checked for, and the operator should verify, the use of the correct device (EMA Annex 11-5).
  12. When an individual has been authorized to use the system, time stamped audit trails (EMA Annex 11-9) must record write-to-file operations and changes, and independently record the date and time of the application specific operator's actions or entries.
  13. Time stamped audit trails (EMA Annex 11-9) must be used to keep track of modifications by the database administrator to the application related electronic records.
  14. The use of operational checks is recommended to enforce sequencing (21 CFR Part 11.10(f)).
  15. Authority checks (21 CFR Part 11.10(g)) must be used, when applicable, to determine if the operator can use the system, operate a device, or perform the operation at hand.
  16. The electronic records must not be altered, browsed, queried, or reported via external software applications that do not enter to the data repository area through the protective technological controls (US FDA[31], EMA Annex 11-7.1 and Annex 11-17, and TGA[32].
  17. Unauthorized modification to the system clock must be prevented (21 CFR Part 11.10(d)). One possible technological control around this item is the use of a Digital Time-stamping Service or an infrastructure that supports time stamping from a trusted time service (e.g. coordinated universal time).

As an example of the above #17 is a recent Statement of Non-Compliance with GMPs issued on December 2014[33] following an inspection by the Italian Medicines Agency in accordance with Art. 111(7) of Directive 2001/83/EC as amended. One of the concerns was that “analysts routinely use the terminal administrator privileges to set the controlling time and date settings back to over-write previously collected failing and/or undesirable sample results. This practice is performed until passing and/or desirable results are achieved.” 

The relevant requirements and/or guidelines discussed in “Secure from intrusion and misuse” are also applicable in this section.

 

TRUSTWORTHY COMPUTER SYSTEMS INFRASTRUCTURE

The following items are the key practices that are applicable for the security of the networked environments (Local Area Networks or Wide Area Network).

  1. Network resources have a qualified authentication mechanism for controlling access (EMA Annex 11-12.1). Table 1 shows the authentication requirements and the methods of implementation. These authentication requirements and methods of implementation are relevant to applications security as well.

    Access control decision function are defined using access right lists, such as Access Control Lists (ACLs), and these allow the allocation of use, read, write, execute, delete, or create privileges. Access controls enable a system to be designed in such way that a supervisor, for example, will be able to access information on a group of employees, without everyone else on the network having access to this information.

    The access controls are an element of the authority check requirements.

  2. The process for setting up user access to a network is the responsibility of the appropriate network security administration personnel. The technical preparation, education and training for personnel performing administration tasks are fundamental (EMA Annex 11-2). The determination of what is required and the provision of documented evidence of the technical preparation, and the education and of personnel training is a key regulatory requirement (21 CFR Part 11.10(i)).Table 1 -- Authentication
  3. Procedural controls, which specify the manner in which network security is administered, must be established and documented. Network users must be trained in the policies, practices, and procedures concerning network security.
  4. The management of network user accounts is a key procedural control. This process includes the request for the addition, modification, and removal of access privileges (EMA Annex 11-12.3). The request must be approved by the appropriate manager, documented, and submitted to the network security administration for implementation.
  5. There must be a procedure for granting controlled temporary network access for personnel (21 CFR Part 11.10(d)).
  6. In the event that a user leaves the company, there must be a process for notifying the appropriate security administration as soon as the employee departs (EMA Annex 11-12.3).
  7. Provisions must be made for the regular monitoring of access to the network. There must be an escalation procedure for defining the actions to be taken if unauthorized access to the network is discovered (EMA Annex 11-13).
  8. A documented record of security administration activities must be retained.
  9. Procedures must be established to control remote access to the network. Systems that have connections to telephone communications through modems should have strict access controls and restrictions. Access restrictions on these systems should be designed to prevent unauthorized access or change. One possible method for controlling remote access is telephone call back.
  10. Access to applications remotely must be performed through the protective technological controls.
  11. The use of time stamped audit trails (21 CFR Part 11.10(c) and (e) and EMA Annex 11-9) to record changes, to record all write-to-file operations, and to independently record the date and time of any network system administrator actions or data entries/changes.
  12. Unauthorized modification of the system clock must be prevented (21 CFR Part 11.10(d)).

 

COMPUTER SYSTEM PROCEDURES.

As part of the GMP controls to computer systems and associated electronic records in manufacturing environments that may impact upon the quality of the products, must have procedural controls for the development, operation, maintenance and retirement. The procedural controls should include: 

  • Assurance computer system is performing as intended. 

            This is covered on “Computer System Suited to Performing their Intended Functions.”

  • Checking the computer systems and associated electronic records at appropriate intervals. 

Software, hardware and back-up procedure must be checked regularly to ensure reliability. The back   procedure must guarantee data integrity. Each backup set should be checked to ensure that it is error-free.

The critical hardware and, interfaces between computers and equipment should be checked periodically or continuous to ensure accuracy and reliability. The periodic I/Os verification is clearly established in the USA FDA Compliance Manual, Sec. 425.400 Computerized Drug Processing; Input/Output Checking (CPG 7132a.07).

In addition to the periodic verification, the majority of the worldwide computer regulations and guidelines concur that a periodic review is necessary “to confirm that they remain in validation state and are compliant with the GMP.” (EMA Annex 11-11). During the periodic review, the electronic records that were transferred to another format or system (EMA Annex 11-4.8) during the concerned period should be checked as well. The objective of this review is to confirm that the electronic records have been accurately and reliably transferred[34].

  • Retention of suitable back-up or archival systems such as copies of the computer software, configuration files and electronic records. 

For the purpose of electronic records retention, investigation after an incident (EMA Annex 11-13) and/or business continuity (EMA Annex 11-16) it is necessary to guarantee the availability of all files and stored data to reconstruct all GMP-relevant documentation. This also applies to the system programs required to save and restore the data. For that reason records must be regularly and progressively backed up, and the backup retained at a location remote.

Following changes to the system and/or backup utility, change control should ensure the availability and integrity of the backup files and stored data by comparing backup data and the original files backed up on a trial basis.

The backup(s) should be made and stored in a secure location to prevent intentional or accidental damage.

  • Assurance that changes to computer software (infrastructure and applications), infrastructure hardware, configuration files, electronic records and process equipment are verified and documented and only made by authorized personnel. 

Procedural controls must be established to prevent unauthorized access or changes to computer software, configuration files and electronic records. All changes to the hardware (infrastructure and process equipment) must be controlled as well (EMA Annex 11-10).

  • Maintaining the Validated State in Computer Systems[35].

There should be written procedural controls for performance monitoring, change control, applications, infrastructure and data security, calibration and maintenance, personnel training, business continuity and periodic re-evaluation[36].

In the event of a breakdown a relevant procedure to preserve a computer system as trustworthy is the business continuity procedural control (EMA Annex 11-16). The business continuity procedure should be periodically checked for the return of the system to its previous state, 

The business continuity procedural control is contemplated as part of the documented contingency planning. For critical computer-dependent systems, the contingency plan should consider alternate systems accessible in the event of a systems failure. 

 

TRUSTWORTHY COMPUTER SYSTEMS IN CLOUD ENVIRONMENTS

The first sidebar in this section provides a view of the typical models in cloud environments. In each model the blue colored portion relates the elements controlled by the cloud service provider.

From the perspective of the regulated user, the worst-case scenario is the Software-as-a-Service (SaaS) model. In this model a regulated user uses a vendor’s software application from a web browser or program interface. The regulated user does not manage or control the underlying cloud infrastructure; including the network, servers, operating systems, storage, or application capabilities; with the possible exception of application configuration settings.

Where the regulated user chooses to outsource any computer related service, such as cloud computing, that can affect product conformity with requirements, the regulated user shall ensure control and hold responsibility for the suitability and operability over such computer related service. Control of such outsourced computer related service shall be identified within the quality management system[37] and clear statement of the responsibilities of the cloud service provider.

The pharmaceutical regulated user therefore should have in place procedures and records that indicated how and on what basis (e.g., requirements) the cloud service provider is selected (PIC/S PI-011-311.2), the tools for assessing fitness for purpose against predetermined requirements, specifications and anticipated risks, and periodic reviews to assess if the computer system is maintained and operated in accordance with the specified requirements and quality agreement.

In the context of EMA Annex 11, the second sidebar in this section provides a pictorial view of the items that the regulated user and the supplier need to comply in a cloud environment. Note that during the operation of the system, the interface between the regulated user and the supplier are the periodic audits to the cloud computing environment supplier.

As the reader may notice from above, no matter the selected model (traditional or cloud), the requirements for trustworthy and compliant computer systems performing regulated activities are the same. In addition, the responsibility of computer systems performing regulated activities always belongs to the regulated user. The way to achieve such regulated user controls over the cloud service provider are established defining clear requirements by the regulated user, comprehensive selection of the cloud service provider, all-inclusive quality agreement between the regulated user and the cloud service provider, and periodic evaluation to the cloud service providers.

 

SUMMARY

To ensure the integrity of electronic records it is essential that the system managing these electronic records must be, at the same time, trustworthy.

Trustworthy computer systems consist of computer infrastructure, applications, and procedures that:

  • Are reasonably suited to performing their intended functions
  • Provide a reasonably reliable level of availability, reliability and correct operation;
  • Are reasonably secure from intrusion and misuse; and;
  • Adhere to generally accepted security principles.

No matter the selected model (traditional or cloud), the requirements for trustworthy and compliant computer systems performing regulated activities are the same.

Finally, consistent with the globalization of the healthcare industry, the above principles are contained in all key regulations and guidelines. 

ADDITIONAL READINGS

  1. López, O., “A Computer Data Integrity Compliance Model”, Pharmaceutical Engineering, Volume 35 Number 2, March/April 2015.
  2. López, O., “Computer Technologies Security Part I - Key Points in the Contained Domain”, Sue Horwood Publishing Limited, West Sussex, United Kingdom, ISBN 1-904282-17-2, 2002.
  3. López, O., “Computer Systems Validation”, In Encyclopedia of Pharmaceutical Science and Technology, Fourth Edition, Taylor and Francis: New York, Published online: 23 Aug 2013; 615-619.
  4. López, O., “EU Annex 11 and the Integrity of Erecs”, Journal of GxP Compliance, Volume 18 Number 2, May 2014.
  5. López, O., “EU Annex 11 Guide to Computer Validation Compliance for the Worldwide Health Agency GMP”, CRC Press, April 2015.

__________________________________________

FOOTNOTES

  1. López, O., “EU Annex 11 and the Integrity of Erecs”, Journal of GxP Compliance, Volume 18 Number 2, May 2014.
  2. López, O., “A Computer Data Integrity Compliance Model”, Pharmaceutical Engineering, March/April 2015.
  3. Data Integrity - the property that data has not been altered in an unauthorized manner. Data integrity covers data in storage, during processing, and while in transit. (NIST SP 800-33)
  4. Critical Electronic Records – electronic records with high risk to product quality or patient safety. (ISPE GAMP COP Annex 11 – Interpretation, July/August 2011).
  5. In this article “GMP regulated activities” is defined as the manufacturing related activities established in the basic legislation compiled in Volume 1 and Volume 5 of the publication "The rules governing medicinal products in the European Union," http://ec.europa.eu/health/documents/eudralex/index_en.htm, US FDA 21 CFR Part 211, “Current Good Manufacturing Practice In Manufacturing, Processing, Packing or Holding of Drugs; General and Current Good Manufacturing Practice For Finished Pharmaceuticals” 
  6. http://www.computer-systems-validation.net/dataintegritydeviations.html
  7. 62 FR 13464, Mar. 20, 1997.
  8. WHO, Technical Report Series No. 937, Annex 4. Appendix 5, “Validation of computerized systems”, 2006.
  9. Intended use - Use of a product, process or service in accordance with the specifications, instructions and information provided by the regulated user.
  10. Should - Used to express a non-mandatory provision. Statements that use “should” are best practices, recommended activities, or options to perform activities to be considered in order to achieve quality projects results. Other methods may be used if it can be demonstrated that they are equivalent.
  11. Software life cycle process that contains the activities of requirements analysis, design, coding, integration, testing, installation and support for acceptance of software products. (ISO 9000-3)
  12. López, O., “Requirements Management,” Journal of Validation Technology, May 2011.
  13. Computer Validation - formal assessment and reporting of quality and performance measures for all the life-cycle stages of software and system development, its implementation, qualification and acceptance, operation, modification, requalification, maintenance and retirement. (PI 011-3. “Good Practices for Computerised Systems in Regulated “GXP” Environments”, Pharmaceutical Inspection Co‑operation Scheme (PIC/S), September 2007.)
  14. PI 011-3. “Good Practices for Computerised Systems in Regulated “GXP” Environments”, Pharmaceutical Inspection Co‑operation Scheme (PIC/S), September 2007.
  15. Cappucci, W.; Chris Clark, C.; Goossens, T.; Wyn, S., “ISPE GAMP CoP Annex 11 Interpretation”, Pharmaceutical Engineering, July/August 2011.
  16. On 29 July 2009, the Therapeutic Goods Administration (Manufacturing Principles) Determination No. 1 of 2009 adopted the PIC/S Guide to Good Manufacturing Practice - 15 January 2009, PE 009-8, to be the Code of GMP, except for its Annexes 4, 5 and 14 which are not adopted by Australia.  Annex 11, Computerized systems, was one of the PIC/S Guide to Good Manufacturing Practice annexes adopted.  TGA is Australia's regulatory authority for therapeutic goods. 
  17. The China State Food and Drug Administration (SFDA) released early 2014 draft of GMP Annex 2 Computerized Systems for comment. Actually, this draft is based on the 1992 EMA GMP Annex 11.
  18. Cappucci, W.; Chris Clark, C.; Goossens, T.; Wyn, S., “ISPE GAMP CoP Annex 11 Interpretation”, Pharmaceutical Engineering, July/August 2011.
  19. GxP - The underlying international life science requirements such as those set forth in the US FD&C Act, US PHS Act, FDA regulations, EU Directives, Japanese MHL.W regulations, Australia TGA, or other applicable national legislation or regulations under which a company operates. (GAMP Good Practice Guide, IT Infrastructure Control and Compliance, ISPE 2005)
  20. Based on the ASEAN Mutual Recognition Agreement recognition of GMP inspections, it will follow PIC/S GMPs.
  21. In the Health Products and Food Branch Inspectorate (HPFBI) GMP Guidelines (2009 Edition, Rev 2), Health Canada establishes that guidance to validate computer systems performing GMP regulated activities is provided in PIC/S PI-011-3.
  22. Reliable - Consistently good performance.
  23. Offutt, J., “Quality Attributes of Web Software Applications,” IEEE Software, March/April 2002, pp. 25-32.
  24. APV, “Guideline Computerized Systems based on Annex 11 of the EU-GMP Guideline”, April 1996.
  25. López, O., “Operational Checks”, in 21 CFR Part 11: Complete Guide to International Computer Validation Compliance for the Pharmaceutical Industry, Eds. (Interpharm/CRC, Boca Raton, Florida 1st ed., 2004).
  26. US FDA, “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”, CDRH and CBER, January 2002.
  27. Section C.02.005 Item 15 in the Computer Systems GMP Guidelines for API in Canada’s GUI-0104, December 2013.
  28. Article 579 Item 2 in the Resolution of the Executive Board No. 17, Brazilian GMPs, April 2010.
  29. O. López, “Computer Technologies Security Part 1 Key Points in the Contained Domain,” Sue Horwood Publishing Limited, 2002.
  30. PI 011-3. “Good Practices for Computerised Systems in Regulated “GXP” Environments”, Section 21.8, Pharmaceutical Inspection Co‑operation Scheme (PIC/S), September 2007.
  31. US FDA, “Guidance for Industry Computerized Systems Used in Clinical Investigations”, May 2010.
  32. TGA, “CGMP Human Blood Tissues”, Section 1011, April 2013.
  33.  http://eudragmdp.ema.europa.eu/inspections/gmpc/searchGMPNonCompliance.do?ctrl=searchGMPNCResultControlList&action=Drilldown&param=26750
  34. WHO, Technical Report Series No. 937, Annex 4. Appendix 5, “Validation of computerized systems”, Section 3.3, 2006.
  35. O. López, “Maintaining the Validated State in Computer Systems”, Journal of GXP Compliance Volume 17 Number 2, August 2013.
  36. WHO, Technical Report Series No. 937, Annex 4. Appendix 5, “Validation of computerized systems”, Section 1.6, 2006.
  37. ISO 9001, Quality Management Systems – Requirements (Section 4.1)



Product Added Successfully

This product has been added to your account and you can access it from your dashboard. As a member, you are entitled to a total of 0 products.

Do you want access to more of our products? Upgrade your membership now!

Your Product count is over the limit

Do you want access to more of our products? Upgrade your membership now!

Product added to cart successfully.

You can continue shopping or proceed to checkout.

Comments (0)

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Use to create page breaks.
Image CAPTCHA
Enter the characters shown in the image.
Validation Master Plan Download banner