Cloud Service Providers

Transcription

1 Cloud Service Providers Draft Guidance for Industry and International Health Authority Staff DRAFT GUIDANCE This guidance document is being distributed for comments purposes only. Document issued on: March 17, 2014 This guidance document has been developed by the Pharmaceutical User Software Exchange (PhUSE) Working Group on Lowering Barriers to Cloud Adoption and is subject to consultation and feedback from both industry and agency stakeholders. Pharmaceutical User Software Exchange Working Group for Lowering the Barriers to Cloud Adoption Lowering Barriers to the Adoption of Cloud Technology

2 Table of Contents 1 Introduction Background Definitions Scope Regulatory Interpretation of Cloud s Procuring Cloud Services Appendices References Lowering Barriers to the Adoption of Cloud Technology 2

3 Introduction 1 Introduction In 2013, the Pharmaceutical R&D Information Systems Management Executives Forum (PRISME forum) facilitated a working group within the Pharmaceutical User Software Exchange (PhUSE) to develop a guidance document on the topic of lowering barriers to cloud adoption in regulated life sciences operations. While cloud adoption has been robust in industries outside the life sciences and in non-regulated areas of life sciences, organizations adhering to good laboratory, clinical, and manufacturing practices (GXP) are just now beginning to scale-up their understanding and interest in cloud-based services. The PhUSE working group, comprised of volunteers from industry, consultants, and cloud service providers around the globe, began our effort of developing this document by identifying some key blockers to adopting cloud service providers in GXP-regulated life sciences. Through our discussions and brainstorming we quickly recognized that our different experiences and perspective on technology and GXP were barriers within the group, and we surmised that if this was true in relatively small team then industry as a whole must be having similar experiences. With that recognition we began to focus on four fundamental questions that would allow each of us to contribute from our own experiences while learning from the experience of others in the group. What are the key concepts and different varieties of cloud computing available to GXP organizations? Which current GXP regulations apply to cloud service providers and cloud-based computerized systems? What are the benefits and risks of the different types of cloud services in the context of GXP regulated organizations? What are the quality responsibilities of GXP organizations and cloud service providers? This guidance document does not establish legally enforceable responsibilities. Instead, this guidance describes the PhUSE working group s current thinking on a topic and should be viewed only as recommendations. The use of the word should means that something is suggested or recommended, but not required. Lowering Barriers to the Adoption of Cloud Technology 3

4 Background 2 Background Cloud computing is becoming more available and powerful, and innovators have begun developing computerized systems to leverage the agility, scalability, and reliability that cloud services can offer. Some of these new cloud-based systems are specifically targeted to supporting food and medical product organizations performing GXP activities. Other cloud solutions are positioned as tools to improve and facilitate the diagnosis and treatment of disease in a healthcare delivery setting. In the late 1980s, health authorities began preparing policies and guidance documents on how to use computer hardware and software in support of GXP activities and, for medical devices, how to determine whether a computer-based product and/or software-based product is a device. Since then the use of computer and software products in food and medical product organizations has grown in number and complexity, and medical devices. Because health authorities have not yet developed overarching policies that holistically address the use and classification of computerized systems in food and medicines, however, industry practices around qualification, validation, and system development life cycles (SDLC) have been developed through standards development organizations like International Standards Organization (ISO) and industry associations like the Good Automated Manufacturing Practices (GAMP) forum, Pharmaceutical Inspection Co-operation Scheme (PIC/S) and PhUSE. Cloud computing is one of the answers to the hosting needs based on the need for instant resources and demand for larger workloads, and the shift from Capex to Opex. Organizations want instant scalability, pay as you go, throughput, while demanding high availability, SLAs, regulatory compliance, Support and Disaster recovery, but to not want to do it them self. Lowering Barriers to the Adoption of Cloud Technology 4

5 Background What s the strategic GXP value of cloud s essential characteristics? On-demand Broad network access Resource pooling Rapid elasticity Measured service Lowering Barriers to the Adoption of Cloud Technology 5

6 Definitions 3 Definitions 3.1 Computerized Systems In good laboratory, clinical, manufacturing and distribution practices (GXP), a computerized system refers to the combination of computer hardware, infrastructure software, software applications, and associated documents (e.g. user manuals and standard operation procedures) that create, modify, maintain, archive, retrieve, or transmit digital information related to the conduct of GXP operations. i With a traditional computerized system (Figure 1), a GXP-regulated organization ( GXP Owner ) purchases and installs the physical hardware, infrastructure software (operating system, database environment, application stack, etc) and a GXP Application. When these components are installed in the GXP Owner s facility they re said to be on premises and when they re installed in someone else s facility and remotely accessed they re said to be co-located or hosted. GXP Application Infrastructure Software Physical Hardware Facility Figure 1 Traditional elements of a GXP Computerized System Physical computer hardware and infrastructure software ( Infrastructure ) generally consists of commercial-off-the-shelf (COTS) products purchased as is and without extensive risk assessments by the GXP Owner. COTS products are generally considered to be higher quality and lower risk due to the higher volumes of commercial users in comparison to custom products. After installation the GXP Owner configures and test the Infrastructure to verify and document that it s installed properly and operates according to the manufacturer specifications; this is typically referred to as qualification. GXP Applications can be COTS or custom software and the level of purchasing controls usually depends on the intended use of the application and a supplier assessment. GXP applications are installed on the qualified infrastructure, configured for the specific GXP processes and procedures, and then performance tested to ensure the GXP Owner s requirements are fulfilled; this is typically referred to as validation. Virtualization of computerized systems refers to the tools and methods for creating a virtual (rather than actual) version of a computing resource, such as a virtual machine, operating system, storage device, or networking resource. ii With virtualization, a single piece of computer hardware (i.e. server) can operate one or more virtual computers that operate independently, which allow more efficient use of the physical hardware and more flexibility to run different software programs and Lowering Barriers to the Adoption of Cloud Technology 6

7 Definitions security groups in each virtual computer. Alternatively, multiple physical computers could be virtualized to act as a single virtual computer, permitting changes or maintenance on one of the physical computers without interruption to the virtual computer or the GXP applications running on it. The type of software that makes virtualization possible is called a virtual machine manager ( hypervisor ) and Figure 2 depicts the basic elements of such a virtualized computer system. GXP Application Infrastructure Software Virtual Hardware Virtualization Services Physical Hardware Facility Figure 2 Elements of a Virtualized Computer System This trend toward virtualization (with reference to our era diagram) emerged strongly during the internet era driven by the technological demands of industries as well as new capabilities to optimize computer resources and costs of operations. 3.2 Cloud Computing Cloud computing is an approach to computerized systems that leverages the concepts and practical implementation of virtualization (described above) and takes it to the next level. Cloud computing is typically defined as a computing environment which is dynamically scalable and where virtualized resources are provided as services over a Local Area Network (LAN) or Wide Area Network (WAN) including the Internet. Essentially, multiple physical computers are outfitted with a hypervisor and connected to the Internet so that people who need computers can get as many virtual computers as they want, whenever they want, for as long as they want without having to buy, install, configure, test and maintain the physical computers themselves. The typical term for cloud systems connected directly to the internet, is public cloud. For cloud systems offered internally in an enterprise, the common term is private cloud. Terms are described later under deployment models. Cloud computing services are typically delivered in three service models: Infrastructure as a Service (IaaS) offers the basic compute, storage and networking capability that allows users to create their own virtual computer network including the automation needed to dynamically add and reduce resources based on user requirements. IaaS is typically oriented toward IT administrators and those who maintain computer networks. Platform as a Service (PaaS) builds on IaaS by offering additional resources needed to develop and deploy cloud-based applications. PaaS resources typically include logical resources such as databases, file systems, and application operating environments (runtime systems). PaaS is typically oriented toward software developers and those who build computer applications. Lowering Barriers to the Adoption of Cloud Technology 7

8 Definitions Software as a Service (SaaS) builds on IaaS and PaaS by offering complete software applications directly to individuals and enterprise users. Aside from network file systems in IaaS, SaaS is the cloud service that most non-it users will see and consume. Cloud computing has also invoked the following deployment models : Private cloud services are provisioned and customized for a specific customer. This may be provisioned and maintained by the GXP Owner or by a supplier. Community Cloud is where multiple organizations with shared concerns share infrastructure. Public cloud services are COTS solutions that are purchased as is. In a public cloud the physical environment and hypervisor are owned and maintained by the cloud service provider ( supplier ) and provided as services to multiple tenants, each of whom owns and maintains their virtual environments and the associated data. Hybrid cloud is a combination of two or more cloud services Infrastructure-as-a-Service (IaaS) IaaS refers to virtualized infrastructure resources being provided as an on-demand service. This includes virtualized servers and network devices with scalable processing capacity and reserved bandwidth for storage and Internet access. iii In IaaS, suppliers manage the facility, hardware, and virtualization layer, and users manage their virtualized infrastructure, platform, and applications. GXP User GXP Application Infrastructure Software Virtual Hardware Hypervisor Hardware Facility Infrastructure Services Physical Hardware Facility Figure 3 Example of IaaS Responsibilities (not comprehensive) Platform-as-a-Service (PaaS) PaaS is similar to IaaS but also includes the required services for a particular application to work. In other words, PaaS is IaaS with a runtime management and software components required for a given application to work on the infrastructure. In PaaS, suppliers manage the IaaS responsibilities and the virtual infrastructure, and the user manages the platform and application responsibilities. Lowering Barriers to the Adoption of Cloud Technology 8

9 Definitions GXP Owner GXP Application Infrastructure Software Platform Virtual Hardware Infrastructure Services Physical Hardware Facility Figure 4 Example of PaaS Responsibilities (not comprehensive) Software-as-a-Service (SaaS) SaaS is complete software applications provided as an on-demand service to food and medical product organizations performing GXP activities. SaaS systems are typically accessed via a web browser or installed application and the associated application data is stored and processed within the SaaS provider s data centers. GXP Owner GXP Application Infrastructure Software Virtual Hardware Infrastructure Services Physical Hardware Facility Figure 5 - SaaS Responsibilities 3.3 GXP GXP is a term that collectively refers to regulations for Good Laboratory Practices (GLP), Good Clinical Practices (GCP), Current Good Manufacturing Practices (cgmp), and Good Distribution Practices (GDP). For purposes of this guidance, Quality System Regulations (QSR) are also included in the meaning of GXP. 3.4 Solution What s the difference between a service, software and a solution? 3.5 s refers to the organization providing cloud services to the organization using the services in support of GXP activities ( GXP user ). The supplier could be internal to the GXP user s organization, such as an IT department, or external as in the case of commercial cloud service providers. Lowering Barriers to the Adoption of Cloud Technology 9

10 Definitions > GXP Owner > Consumer/Patient/Human Subject 3.6 Workload In the parlance of cloud service providers, a workload represents a unit of work performed that s represented by customer accounts, CPU cycles, I/Ops and storage. Regulated workloads, and their associated characteristics. Lowering Barriers to the Adoption of Cloud Technology 10

11 Scope 4 Scope This guidance explains the PhUSE working group Scope is Highlight principles and concepts, GXP-oriented Geographic Jurisdiction Scope is not not practical recommendations on implementation other regs/compliance requirements aren t included but may still apply (healthcare data privacy, intellectual property, financials, etc) Medical device data systems Lowering Barriers to the Adoption of Cloud Technology 11

12 Regulatory Interpretation of Cloud s 5 Regulatory Interpretation of Cloud s Government agencies such as FDA (US), EMA (EU), MHLW (JP), CDSCO (IN) and SFDA (CN) iv protect patients and consumers from harmful foods, medicines, and devices by regulating manufacturers and requiring them to comply with Good Laboratory, Clinical, Manufacturing, Distribution, Marketing, and Servicing Practices (GXP). Under current laws, GXP-regulated companies ( GXP Owners ) using computerized systems must follow certain regulations and, building on the virtualization concepts in section 3.1 Computerized Systems (page 6), Figure 6 maps the elements of a virtualized computer system to some of the applicable GXP regulations. Computer System Elements GXP Application Infrastructure Software Virtual Hardware Virtualization Services Physical Hardware Facility (Some) Applicable GXP Regulations COTS/Custom Applications, Validation, Quality Systems Infrastructure Software, Qualification Quality Systems Equipment, Qualification, Quality Systems Infrastructure Software, Qualification, Quality Systems Equipment, Qualification, Quality Systems Buildings and Facilities, Quality Systems Figure 6 Mapping Computer System Elements to Some GXP Regulations Agencies like the FDA hold GXP Owners legally accountable for ensuring that computer systems are suitable for their use in GXP operations ( intended use ), and suitability assessments are generally based on the benefits the system provides in relation to the potential risk factors the system poses to patient safety, medical product quality, and GXP data integrity. The availability of a diagnostic application, for example, would be a risk factor to patients who require a time-sensitive treatment, as would the security of an inventory control system be a risk factor to medical product quality. When cloud services providers ( s ) deliver IaaS, PaaS, and SaaS to GXP Owners, a number of legal responsibilities are being delegated from the GXP Owner to the, and Purchasing Control regulations require GXP Owners to evaluate, select, monitor and document the performance of the. v From a regulatory perspective, s are considered an extension of the GXP Owner vi and agencies have the legal authority to inspect the facilities and records of both GXP Owners and s. vii s may also be liable for causing the introduction of adulterated or misbranded medicines and devices into interstate or international commerce, where the causative factors for the violation are attributable to intrinsic defects in the service provider's hardware and software. viii Since GXP regulations do not specifically address cloud service providers, this part of the document provides an interpretation of the current GXP regulations that may apply to cloud s. The specific regulations that apply to a particular cloud-based GXP system must be determined on a case by case basis, and Section _, _, outlines how to do that. Lowering Barriers to the Adoption of Cloud Technology 12

13 Regulatory Interpretation of Cloud s 5.1 Quality Systems Regulatory agencies operate under the premise that to ensure the safety and privacy of human subjects and patients, a quality system with policies and procedures must be established, implemented and maintained. The rationale behind this perspective is that no amount of retrospective testing can make an unsafe product safe, so it s more effective to prevent unsafe products in the first place by requiring GXP Owners to continuously monitor and improve the quality of their product development and delivery processes. When GXP Owners use cloud s, the quality system requirements for each depend on the intended use in GXP operations, the cloud service model (IaaS, PaaS, and SaaS). For example, a mobile medical application running on IaaS would have a different set of quality system requirements than a laboratory notebook application being provided as SaaS or an IaaS-hosted ERP system. Below are some quality system elements that cloud s may be expected to have depending on the GXP Owner s intended use of the services: Change control and configuration management Complaint handling and incident management Corrective actions and preventive actions Document controls Organization, personnel & management responsibility Purchasing controls Quality unit and internal audits Quality system responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner. 5.2 Human Safety and Privacy Protections When cloud services are used in clinical research, human subject protection regulations require that the safety and privacy risks to the human subjects are reasonable in relation to the anticipated benefits. For example, the safety and privacy risks of a cloud-based application acting as a food diary in a drug study would be different than the safety and privacy risks of a cloud-based imaging system used to diagnose a life-threatening disease. Ethics committees (EC) and institutional review boards (IRBs) are responsible for reviewing and approving clinical research proposals, including the research computer systems posing potential safety and confidentiality risks to human subjects. Research Sponsors and Investigations must provide ECs/IRBs with evidence to demonstrate the system is well controlled and that potential safety and privacy risks are appropriately managed. An example of a research system security plan (SSP) is included in Appendix C. Lowering Barriers to the Adoption of Cloud Technology 13

14 Regulatory Interpretation of Cloud s Depending on the country and location where the research is being conducted, these human subject protections under GXP may be distinct from healthcare data privacy regulations. See section 5.8 Data Privacy and Protected Health Information. 5.3 Buildings and Facilities The physical environment of a computer system can have a material impact on the performance and reliability of the system and can also pose risks to patient safety, medical product quality, and GXP data integrity. Data center facilities where GXP software and data reside on physical media should follow the applicable GXP requirements for design, construction, maintenance, security, and emergency preparedness of buildings. Depending on the deployment model of the cloud service, data centers may be managed by the GXP Owner or by a and whoever manages the data center is responsible for meeting the GXP facility requirements. GXP facility responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner. 5.4 Equipment Computer and network hardware supporting GXP operations are considered by agencies to be equipment and subject to regulations for purchasing, installation, qualification, maintenance and emergency preparedness. ix In the cloud environment, the What are virtual goods? computer hardware has been virtualized so that there are now two sets of equipment: 1. the virtual devices (virtual servers, virtual network controllers, etc) running the GXP Application and data, and 2. the underlying physical equipment running the virtualization services. Although the interpretation of whether virtual hardware constitutes equipment has not yet been established in GXP regulations or agency guidance documents, from a technology perspective a virtual device performs the same function as a physical device but does so using virtual resources. Virtual goods are physical goods that have been represented in a computer system. Like paperbacks becoming ebooks and printed money becoming cryptocurrency, virtual computing devices are a new area for equipment and technology regulations. Until a regulation or guidance becomes available, it is not inappropriate from a technology perspective to manage both the physical hardware and virtual hardware as GXP equipment. GXP equipment responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner. 5.5 Recordkeeping Recordkeeping and data integrity are a central tenet of GXP regulations and virtually every regulation has an implicit or explicit recordkeeping requirement. These regulations apply to the data generated by the GXP Application as well as the records produced about the application, infrastructure, quality systems, buildings, and other GXP-regulated areas. The purpose of these Lowering Barriers to the Adoption of Cloud Technology 14

15 Regulatory Interpretation of Cloud s regulations is to ensure that sufficient evidence is maintained for an agency to evaluate the compliance of a GXP Owner or and, more importantly, to trace any root cause issues that result in harming the safety or privacy of a patient, consumer, or research subject. Recordkeeping requirements can include the minimum record content, retrievability, backup and protection, review and approval, as well as minimum retention periods. When GXP records are generated and maintained in GXP applications instead of paper, the application may require additional technical and procedural controls for electronic records and electronic signatures regulations. x These electronic records and signature requirements are generally more applicable to SaaS than IaaS, although not exclusively. When GXP Owners use cloud s the scope of recordkeeping requirements depends on the regulations applicable to the intended use. Responsibilities for recordkeeping apply whether they are performed by s or GXP Owners. Additionally, records required under GXP regulations must be made available to agency inspectors upon request and without unreasonable delay, in some cases within 2 working days. GXP recordkeeping responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner. 5.6 Software Under current GXP regulations and agency inspection reports, software is generally divided in two categories: infrastructure software (operating systems, database management systems, runtime environments, network device firmware, etc) and GXP applications (custom or commercial-off-theshelf software). Infrastructure software is subject to qualification requirements and GXP applications are subject to validation requirements. See section 5.7 Validation and Qualification. In the virtualized cloud environment, there are two sets of infrastructure software: one running on the physical equipment and another running on the virtual equipment. Until regulations or guidance on virtual equipment become available, infrastructure software on both the physical and virtual equipment should be qualified. GXP infrastructure software responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner. GXP Applications either replace manual activities (workflows, messaging, form fields, etc) or make possible processes that could not otherwise be manually performed (big data computations, realtime monitoring, etc). Most GXP activities require documented processes (i.e. records), as a result agencies have generally come to view software as equivalent to records. xi The kind of record the software represents (test protocol, procedure, form, etc) depends on the GXP activity the software performs, and the recordkeeping requirements applicable to the software come from the regulations that correspond to the GXP activity. The process of developing GXP Applications must also be documented and those GXP applications that are considered medical devices and medical applications may also be subject to design, development and testing regulations depending on their medical device classification. GXP software responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner at the regulated company. Lowering Barriers to the Adoption of Cloud Technology 15

16 Regulatory Interpretation of Cloud s 5.7 Validation and Qualification Qualification and Validation are forms of testing performed by GXP Owners on their facilities, equipment, and software. The purpose of qualification is to verify and document that the item (physical or virtual) being tested is installed properly and operates according to the manufacturer specifications. The purpose of validation is to verify and document that a GXP application is installed properly, operates according to the manufacturer specifications, and satisfies the user/business requirements defined by the GXP Owner. The extent of qualification and validation testing depends on the type of system (infrastructure, commercial-off-the-shelf, or custom) and the risk the system poses to patient safety, medical product quality, and GXP data integrity. In the cloud environment, each element of the virtualized system may require some amount of qualification and validation and, from a regulatory agency perspective, GXP Owners are responsible for ensuring the qualification and validation activities are adequate. s, however, may also incur liability for computer system validation, as well as hardware/software maintenance performed on behalf of users. xii GXP qualification and validation responsibilities performed by s should be documented in a Quality Agreement with the GXP Owner. 5.8 Data Privacy and Protected Health Information Cloud-based systems used in GXP research or commercial operations sometimes store and/or transmit personally identifiable information about patients, consumers and research subjects. Data privacy rules for personally identifiable information and protected health information vary from country to country and, in some cases, state to state. In many cases these data privacy requirements are in addition to the confidentiality requirements of the GXP human subject protections. When cloud-based systems support GXP-regulated medical products in a healthcare setting, such as a cloud-based medical imaging system in a hospital, privacy and security rules for protected health information (PHI) may apply to the covered entities (i.e. providers) who use the GXP product, as well as their business associates supporting the system operations (i.e. GXP Owners and/or cloud providers). In the context of GXP research, the scope of applicable data privacy regulations can depend on a wide range of factors such as the location where data is collected, the location where data resides on physical media, the nationality of the person who the data identifies, the data use permissions granted in any research subject consent forms, and whether the research data is also a part of the medical records. The human subject protection regulations generally require that computer systems containing private data are secure and, in the case of some cases like medical applications, certain security controls must be built into the software itself. In cases where GXP Owners using cloud have data privacy requirements beyond GXP, both the GXP and data privacy responsibilities should be documented in agreements between the and GXP Owner. Lowering Barriers to the Adoption of Cloud Technology 16

17 Procuring Cloud Services 6 Procuring Cloud Services One of the main drivers behind the adoption of cloud computing is that cloud represents a simplification and commoditization of IT-related duties. Activities that were once costly and timeconsuming for GXP Owners are now delivered as low-cost services that can be self-provisioned with the click of a button. Additionally, the quality and security capabilities of commercial cloud services often IT systems admini exceed the capabilities of GXP Owners who administer IT systems on a part-time basis. In GXP operations, this simplification of work and enhancement of control can reduce costs and increase agility and accountability in responding to new business and regulatory requirements. It s also important to recognize that cloud computing represents a fundamental shift in regulatory responsibilities between GXP Owners and their s. Responsibilities that GXP Owners have traditionally owned themselves are now being delegated to cloud s, both internal s within the GXP Owner s organization (such as an IT department) and s external to the GXP Owner s organization (such as a commercial cloud provider). This shift toward s, therefore, requires that GXP Owners update their purchasing practices to accommodate cloud services. This section provides an overview of the considerations and processes for effectively sourcing, contracting, and managing cloud s. 6.1 Sourcing The procurement process for onboarding new cloud s should begin with a sourcing phase that focuses on the GXP Owner planning and describing their business, technical and regulatory requirements, as well as educating themselves and their project stakeholders on the cloud market environment. During this education process it may be necessary for GXP Owners and their quality/regulatory teams to review their purchasing procedures, supplier assessment criteria and system development lifecycle (SDLC) processes to ensure they are appropriate for cloud service models and deployment models. GXP Owners who follow traditional waterfall development and ITIL methodologies should pay particular attention to their SDLC practices to ensure they can accommodate the current methodologies (such as Agile and DevOps) used by many commercial cloud service providers. Throughout the sourcing phase, as the GXP Owner learns about and interacts with potential cloud suppliers, the system requirements, designs and risk assessments should become increasingly defined and the list of potential suppliers increasingly narrowed. s should support this process by providing information about their services and compliance capabilities, as well as providing input on the GXP Owner s system-related plans. This should ultimately lead to the GXP Owner having a finalized set of system documentation and a short-list of suppliers to evaluate more thoroughly in the next phase of procurement, Contracting. Depending on the GXP Owner s intended use and the cloud services under consideration, a variety of sourcing documentation may be necessary for both the GXP Owner and the cloud. Lowering Barriers to the Adoption of Cloud Technology 17