(中文内容在下方
）
To Implementation Cloud Service Model in GLP test facility, the key is understanding the Shared Responsibility Model. As you move from IaaS to SaaS, the test facility's direct technical control decreases, but its responsibility for GLP compliance remains 100%. Therefore, the focus of your control activities must shift from hands-on technical management to rigorous vendor management and process oversight. Here are specific examples for each model and the distinct implementation focus for each.
1. Infrastructure as a Service (IaaS)
Definition: You rent fundamental IT resources (servers, storage, networking) from a cloud provider. You manage the operating systems, applications, and data running on that infrastructure.
GLP Analogy: It's like renting a plot of land (the data center) and a building shell (the virtual servers) from a landlord. You are responsible for everything inside the building: security, plumbing, electricity (OS, software, data).
Example: Hosting a Validated Database Server
A test facility wants to host its own instance of a specific chromatography data system (CDS) database server in the cloud instead of maintaining physical servers on-site.
Cloud Provider's Responsibility: Physical security of the data center, power, cooling, network infrastructure, and the hypervisor (virtualization layer).
Test Facility's Responsibility:
Installing and validating the Windows/Linux operating system on the virtual machine.
Installing, configuring, and validating the CDS database software.
Applying security patches to the OS and database.
Managing user accounts and access controls within the OS and application.
Performing database backups and restores.
Ensuring data integrity and archiving.
Implementation Steps for IaaS:
1). Risk Assessment: Focus on risks related to managing your own OS/software (e.g., misconfiguration, security vulnerabilities, backup failures).
2). CSP Assessment: Select a provider (e.g., AWS, Azure, Google Cloud) based on their uptime guarantees, data center certifications (e.g., ISO 27001), and physical security measures.
3). SLA: The SLA will focus on infrastructure uptime, availability, and performance metrics. It must include your right to know the geographic location of your data and the right to audit their infrastructure controls.
4). Validation: Your facility is responsible for the full validation lifecycle of the CDS software stack, just as if it were on a physical server in your basement. This includes Installation Qualification (IQ) of the virtual machine environment, Operational Qualification (OQ) of the CDS installation, and Performance Qualification (PQ) in the cloud environment.
2. Platform as a Service (PaaS)
Definition: The provider supplies a platform allowing you to deploy your own applications without managing the underlying infrastructure (servers, storage). You control the deployed applications and possibly some configuration settings for the application-hosting environment.
GLP Analogy: You are renting a fully serviced, secure office space. The landlord (provider) manages the building, security, utilities, and maintenance. You are responsible for the business you run inside the office (your application and data).
Example: Custom Laboratory Information Management System (LIMS)
A test facility develops a custom application to manage study samples and associated data. They deploy this application on a PaaS.
Cloud Provider's Responsibility: Everything in IaaS, plus the operating system, runtime environment, database management system, and development tools.
Test Facility's Responsibility:
Developing, deploying, and validating the custom LIMS application itself.
Managing the data within the application.
Configuring application-level user access and roles.
Ensuring the application functions correctly for its intended GLP use.
Implementation Steps for PaaS:
1). Risk Assessment: Focus on risks specific to the application code and the platform's constraints (e.g., application logic errors, data flow issues, dependency on provider-managed services like databases).
2). CSP Assessment: Assess the provider's (e.g., Heroku, Azure App Service) ability to manage the platform securely and their change control process for platform updates that might affect your application.
3). SLA: The SLA must specify responsibilities for platform patching and updates. It should guarantee that the provider will not make changes that break your validated application without notice and a testing period.
4). Validation: Your facility validates the custom application. You will rely on the provider's qualification of the underlying platform (which you should review as part of your assessment). Your validation focuses on the application's functionality, data integrity controls (audit trails), and performance in the PaaS environment.
3. Software as a Service (SaaS)
Definition: You use the provider’s applications running on their cloud infrastructure. You access the application via a web browser. You have minimal control, typically limited to user-specific application settings.
GLP Analogy: You are subscribing to a business service, like a payroll company. You are responsible for inputting correct data and using the service appropriately, but the service provider runs the entire operation.
Example: Electronic Laboratory Notebook (ELN)
A test facility subscribes to a commercial, cloud-based ELN system for capturing raw data directly from scientists.
Cloud Provider's Responsibility: Everything: application, data, runtime, middleware, O/S, servers, storage, networking.
Test Facility's Responsibility:
Configuring the system for its intended use (e.g., setting up study templates, user roles).
Managing user access within the application.
Ensuring users are trained and use the system correctly to generate ALCOA+-compliant data.
Reviewing electronic records and audit trails.
Exporting and archiving data at the end of a study.
Implementation Steps for SaaS (Most Common & Critical Scenario):
1). Risk Assessment: This is paramount. Focus on risks like:
Lack of Control: Inability to control when the provider updates the software.
Data Access: Uncertainty about who at the provider can access your data.
Exit Strategy: Difficulty in retrieving all data and metadata in a usable format upon contract termination.
Customization Limits: The application may not perfectly fit your process, leading to workarounds that risk data integrity.
2). CSP Assessment: This is your primary control point. You must conduct a thorough audit of the SaaS vendor. Key areas:
Their Development Lifecycle: How do they design, code, test, and validate their software?
Their Change Control Process: How do they manage, test, and communicate updates?
Their Data Integrity Features: Does the application have built-in, configurable audit trails? Are electronic signatures compliant with 21 CFR Part 11 or equivalent?
Their Business Continuity/Disaster Recovery: What are their proven RTO and RPO?
3). SLA: The SLA for SaaS is the most critical. It must be explicit on:
Change Notification: A minimum 30-60 day notice for any update, with access to a test ("sandbox") environment to re-qualify the system before the update goes live.
Data Ownership & Exit: A guaranteed right to retrieve all data, metadata, and audit trails in a non-proprietary, readable format (e.g., CSV, PDF) upon request.
Security & Access: A clause prohibiting their personnel from accessing your data without your written permission, except for essential maintenance under your controlled procedures.
Audit Rights: Your right to audit them or receive their recent third-party audit reports (e.g., SOC 2 Type II).
4). Validation (Often called "Configuration Qualification" or "Validation of Configured Software"):
You cannot validate the software code itself, but you must validate that the configured system is fit for its intended use in your GLP processes.
Activities: This involves testing the specific workflows you will use. For the ELN example: creating a test study, entering data, revising data (checking the audit trail), approving data, and finally, exporting the data for archiving. You are proving that your use of the service is controlled and reliable.
This plan integrates the examples above into a actionable workflow：
Phase
|
Key Activities
|
Responsible Party
|
Deliverable
|
1.Planning & Assessment
|
Form a cross-functional team (TFM, IT, QA, Lead Scientists).
Define User Requirements (URS).
Perform Risk Assessment: Identify risks to Data Integrity.
|
TFM
|
Approved URS.
Documented Risk Assessment Report
|
2.Vendor Selection
|
Create a vendor assessment checklist based on GLP requirements.
Review vendor certifications (ISO 27001, SOC 2).
Conduct an audit for high-risk systems (especially SaaS).
Select vendor based on ability to meet URS and mitigate risks.
|
TFM with IT/QA
|
Vendor Audit Report.
Vendor Selection Justification
|
3.Contract & Agreement
|
Negotiate a detailed Service Level Agreement (SLA) that covers all GLP concerns (see examples above).
Crucially, include Exit Strategy and Audit clauses.
Have the SLA reviewed by QA and legal.
|
TFM
|
Executed SLA
|
4.Implementation & Validation
|
IaaS/PaaS: Perform full system lifecycle validation.
SaaS: Configure the system and perform a Performance Qualification (PQ) to test your specific workflows.
Write/update SOPs for system use, administration, and business continuity.
Train all users.
|
System Owner
Users
QA
|
Validation Plan & Report New/Revised SOPs.
Training Records.
|
5.Operational Management
|
Monitor the SLA: Review provider performance reports.
Manage Changes: Re-qualify the system after any major update from the provider.
Perform Periodic Reviews: Re-assess risks and system validity annually or as needed.
Execute Exit Strategy: Test data retrieval procedures.
|
TFM
QA
System Owner
|
SLA Performance Reviews.
Periodic Review Reports.
Successful data migration tests
|
By following this structured approach and tailoring it to the specific cloud model, a test facility can confidently adopt cloud technologies while providing demonstrable evidence of GLP compliance to regulators.
GLP试验机构在部署云服务模型时，关键在于理解责任共担模型。随着服务模式从IaaS转向SaaS，试验机构对技术的直接控制会减弱，但其对GLP合规性的责任始终是100%。因此，控制活动的重点必须从亲力亲为的技术管理，转向严格的供应商管理和流程监督。以下是针对每种模式的具体示例及不同的实施重点：
1. 基础设施即服务（IaaS）
场景定义：试验机构从云提供商处租用基础IT资源（服务器、存储、网络）。试验机构负责管理在该基础设施上运行的操作系统、应用程序和数据。
场景类比：这就像您从房东那里租用了一块地皮（数据中心）和一个建筑外壳（虚拟服务器）。您负责建筑内部的一切：安防、管道、电力（操作系统、软件、数据）。
应用举例：托管经过验证的数据库服务器
试验机构希望将某个色谱数据系统数据库（CDS）服务器的部署在云服务器中，而不是在本地维护物理服务器中。
云服务提供商的责任：数据中心的物理安全、电力、冷却、网络基础设施及管理程序（虚拟化层）。
试验机构的责任：
在虚拟机上安装并验证Windows/Linux操作系统。
安装、配置并验证CDS数据库软件。
为操作系统和数据库应用安全补丁。
管理操作系统和应用程序内的用户账户与访问控制。
执行数据库备份与恢复。
确保数据完整性和归档。
IaaS实施步骤：
风险评估：重点关注与自行管理操作系统/软件相关的风险（例如，配置错误、安全漏洞、备份失败）。
云服务提供商评估：根据提供商的正常运行时间保证、数据中心认证（如ISO 27001）和物理安全措施来选择提供商（例如，AWS, Azure, Google Cloud）。
服务等级协议：SLA将侧重于基础设施的正常运行时间、可用性和性能指标。其中必须包含您对数据地理位置的知情权以及审计其基础设施控制措施的权利。
验证：您的机构负责CDS软件的完整验证生命周期，就如同它在您本地机房的物理服务器上一样。这包括虚拟机环境的安装确认、CDS安装的运行确认以及在云环境中的性能确认。
2. 平台即服务（PaaS）
场景定义：云提供商提供一个平台，允许试验机构部署自己的应用程序，而无需管理底层基础设施（服务器、存储）。试验机构控制部署的应用程序，并可能控制应用程序托管环境的一些配置设置。
场景类比：您租用的是设施齐全、安全的办公空间。房东（提供商）负责管理大楼、安防、公用设施和维护。您负责在办公室内经营的业务（您的应用程序和数据）。
应用举例：定制化实验室信息管理系统
试验机构开发了一个定制应用程序来管理研究样品及相关数据。他们将该应用程序部署在PaaS上。
云服务提供商的责任：IaaS中的所有责任，外加操作系统、运行时环境、数据库管理系统和开发工具。
试验机构的责任：
开发、部署并验证定制的LIMS应用程序本身。
管理应用程序内的数据。
配置应用程序级的用户访问和角色。
确保应用程序在其GLP用途中功能正常。
PaaS实施步骤：
风险评估：重点关注与应用程序代码及平台限制相关的特定风险（例如，应用程序逻辑错误、数据流问题、对提供商管理服务（如数据库）的依赖）。
云服务提供商评估：评估提供商（例如，Heroku, Azure App Service）安全管理平台的能力，以及他们针对可能影响您应用程序的平台更新的变更控制流程。
服务等级协议：SLA必须明确提供商在平台补丁和更新方面的责任。它应保证提供商不会在未通知且未提供测试期的情况下，进行会破坏已验证应用程序的更改。
验证：试验机构负责验证定制应用程序。将依赖提供商对底层平台的确认（应在评估时审查此确认）。试验机构的验证重点在于应用程序的功能性、数据完整性控制（审计追踪）以及在PaaS环境中的性能。
3. 软件即服务（SaaS）
场景定义：试验机构使用提供商在其云基础设施上运行的应用程序。试验机构通过网页浏览器访问该应用程序。此时，试验机构只有最低限度的控制权，通常仅限于用户特定的应用程序设置。
场景类比：您订阅的是一项商业服务，就像payroll 公司。您负责输入正确的数据并恰当地使用服务，但服务提供商运营着整个系统。
应用举例：电子实验记录本
试验机构订阅商业化的、基于云的ELN系统，用于直接采集科学家产生的原始数据。
云服务提供商的责任：所有一切：应用程序、数据、运行时、中间件、操作系统、服务器、存储、网络。
试验机构的责任：
配置系统以用于其预定用途（例如，设置研究模板、用户角色）。
管理应用程序内的用户访问。
确保用户经过培训并能正确使用系统以生成符合ALCOA+原则的数据。
审查电子记录和审计追踪。
在研究结束时导出和归档数据。
SaaS实施步骤（最常见且关键的情景）：
风险评估：这一点至关重要。重点关注以下风险：
控制力缺乏：无法控制提供商更新软件的时间。
数据访问：不确定提供商处何人能访问您的数据。
退出策略：合同终止时，难以以可用格式检索所有数据和元数据。
定制限制：应用程序可能不完全符合您机构的流程，导致可能危及数据完整性的变通方法。
云服务提供商评估：这是试验机构的主要控制点，必须对SaaS供应商进行彻底审计。关键领域包括：
他们的开发生命周期：他们如何设计、编码、测试和验证其软件？
他们的变更控制流程：他们如何管理、测试和沟通更新？
他们的数据完整性功能：应用程序是否内置可配置的审计追踪？电子签名是否符合21 CFR Part 11或等效法规？
他们的业务连续性/灾难恢复计划：他们经过验证的RTO和RPO是多少？
服务等级协议：针对SaaS的SLA最为关键。它必须明确以下内容：
变更通知：任何更新至少提前30-60天通知，并允许访问测试（"沙盒"）环境，以便在更新上线前重新确认系统。
数据所有权与退出：保证您有权在请求时以非专有、可读格式（例如，CSV, PDF）检索所有数据、元数据和审计追踪。
安全与访问：条款规定，禁止其人员在未经试验机构书面许可的情况下访问机构的数据，除非是在机构受控程序下的必要维护。
审计权：试验机构有权审计他们或接收他们近期的第三方审计报告（例如，SOC 2 Type II）。
验证（常称为"配置确认"或"已配置软件的验证"）：
试验机构无法验证软件代码本身，但必须验证配置后的系统适用于试验机构在GLP流程中的预定用途。
活动：这涉及测试试验机构将使用的具体工作流程。以ELN为例：创建研究、输入数据、修改数据（检查审计追踪）、批准数据，最后导出数据以备归档。试验机构需要证明对该服务的使用是受控且可靠的。
将上述三类模型的实施要点整合为可操作的工作流程，如下图所示：
阶段
|
关键活动
|
责任方
|
交付成果
|
1. 规划与评估
|
组建跨职能团队。
定义用户需求规格。
执行风险评估。
|
TFM
|
批准的URS 风险评估报告
|
2. 供应商选择
|
制定基于GLP要求的供应商评估清单。
审查供应商认证。
对高风险系统进行审计。
基于满足URS和缓解风险的能力选择供应商。
|
TFM
(IT/QA)
|
供应商审计报告 供应商选择理由
|
3. 合同与协议
|
谈判详细的SLA，涵盖所有GLP关切点。
关键点：包含退出策略和审计条款。
由QA和法律部门审查SLA
|
TFM
|
已签署的SLA
|
4. 实施与验证
|
IaaS/PaaS：执行全系统生命周期验证。
SaaS：配置系统并执行PQ以测试您的特定工作流程。
编写/修订系统使用、管理和业务连续性的SOP。
培训所有用户。
|
系统拥有者 用户
QA
|
验证方案与报告 新增/修订的SOP 培训记录
|
5. 运行管理
|
监控SLA：审查提供商绩效报告。
管理变更：在提供商进行任何重大更新后对系统进行再确认。
执行定期评审：每年或根据需要重新评估风险和系统有效性。
执行退出策略：测试数据检索程序。
|
TFM
QA
系统拥有者
|
SLA绩效评审报告 定期评审报告 成功的数据迁移测试
|
通过这种结构化方法，并结合具体云服务模型进行针对性管理，GLP试验机构能够在合规前提下有效采用云技术，同时为监管审查提供充分证据。