Change Control bei computergestützten Systemen计算机化系统中的变更控制 Change Control bei computergestützten Systemen ist kein triviales Thema.Zwar sind die betrieblichen internen Vorgaben zum Change Control meistvorhanden, doch der Teufel steckt hier häufig im Detail. 计算机化系统中的变更控制不是一个微不足道的主题。尽管公司内部对变更控制的要求通常很到位，但细节往往是魔鬼。 Regulatorische Vorgaben 监管要求Die regulatorischen Vorgaben sind spärlich und insbesondere EU-GMP Annex11 'Computerised Systems' ist bezüglich der Anforderungen eherbescheiden. Hier findet man lediglich folgende Forderung: EU-GMP 附录11“计算机化系统”要求如下： Annex 11 - 10. Änderungs- und Konfigurationsmanagement: Jede Änderung an einem computergestützten System einschließlichder System-konfigurationen sollte kontrolliert und nach einem festgelegtenVerfahren erfolgen. 变更和配置管理： 对计算机化系统的每一次变更，包括系统配置，都应根据规定的程序进行控制和执行。 Zusätzlich muss man aber auch noch die im EU-GMP Anhang 15'Qualification and validation' genannten Vorgaben berücksichtigen.Ein erster wesentlicher Hinweis findet sich unter dem Abschnitt'Grundsätze': Alle geplanten Änderungen an Einrichtungen,Ausrüstung, Betriebsmitteln und Prozessen, die die Produktqualität beeinflussenkönnen, sollten formell dokumentiert und die Auswirkungen auf denValidierungsstatus oder die Kontrollstrategie untersucht werden. 此外，还必须考虑 EU-GMP 附录 15“确认与验证”中规定的要求。可在“原则”部分找到一些关键说明：所有可能影响产品质量的设施、设备、操作和流程的变更都应正式记录在案，并调查对验证状态或控制策略的影响。 Des Weiteren werden im Annex 15 unter anderem noch folgende Punkteangesprochen: 此外，附录 15 还提及以下几点：
Der PIC/S Guidance PI 011 befasst sich im Kapitel 18 ausführlich mit demChange Control. Zunächst werden grundlegende Forderungen an die Dokumentationgestellt. Was soll dokumentiert werden? PIC/S 指南 PI 011 的第 18 章详细介绍了变更控制。首先是对文件的基本要求。应该记录什么？
Inspektionspraxis 检查实践 Was wurde im Rahmen von GMP-Inspektionen als an Inspektionsmängelngefunden? Folgend einige Beispiele, die häufiger zu finden waren: GMP检查中发现了哪些检查缺陷？以下是一些更常见的示例： Beispiel 1 示例 1 Eine Bewertung hinsichtlich der Kritikalität des Changes konnte nichtvorgelegt werden. 无法提供关于变更关键性的评估。 Es macht Sinn, Änderungen in unterschiedliche Klassen einzuteilen. Auchdas AiM 07121202 (Aide mémoire - Katalog von Vorgaben, Fragen und Empfehlungen;dient der Harmonisierung bei der Vorbereitung, Durchführung und Nachbereitungeiner Inspektion) der EFG 11* beschreibt eine Klassifizierung. Aus derKlasse ergibt sich dann der Aufwand im Zusammenhang mit dem Change. ZurKlassifizierung können in der Praxis unterschiedliche Einteilungen vorgenommenwerden. Hier einige Varianten, die in der Praxis zu finden sind: 将变更划分为不同级别是有意义的。以下是一些示例：
Beispiel 2 示例 2 Der Betrieb hatte ein Change Control-System etabliert. Es war jedochunklar, welche Änderungen über dieses Verfahren abzuarbeiten sind. Es fanden sichlediglich Hinweise zum Umgang mit Software-Updates. Nicht geregelt warenfolgende Punkte im Umgang mit 公司已建立变更控制系统。但是，尚不清楚将通过此程序处理哪些变更。只有关于如何处理软件更新的说明。以下几点处理不规范：
Zu den Security-Patches ein Hinweis aus PIC/S PI 041-1: PIC / S PI 041-1 关于安全补丁的规定如下： PIC/S PI 041-1
操作系统和网络组件的安全补丁应根据供应商的建议以受控和及时的方式应用，以维护数据安全。安全补丁的应用应按照变更管理原则进行。 Beispiel 3 示例 3 Konkrete Vorgaben für Zeitintervalle, bis wann ein Change abgeschlossensein muss, sind nicht dokumentiert vorhanden. Es sollte hier ein dokumentiertesKonzept geben, innerhalb welcher Zeitintervalle eine Änderung abzuschließen ist(Zeitplanung). Hierzu empfiehlt es sich, ein abgestuftes Verfahren einzuführen.Angaben wie beispielsweise ein Jahr nach Antragstellung sind extrem lang undbei einem hot-fix nicht akzeptabel. 未规定必须完成变更的时间间隔。应有一个书面的时间间隔概念，在该时间间隔内必须完成变更（时间计划）。为此，建议引入分级程序。例如，变更申请后一年内完成对于缺陷整改来说是非常漫长且不可接受的。 Computerized System Change Management In GAMP5-Second Edition 新版GAMP5 建议的计算机化系统变更管理 变更分类： Standard/Routine Changes: Such changes may
be considered low risk to patient safety, product quality, and data integrity.
Work instructions, system administration plans, support plans, service
requests, or similar may be used to define the change implementation tasks and
responsibilities. A record of the change should be maintained, including any
verification tasks required to confirm successful implementation of the change.
Internal audit processes should identify any misuse of the standard/routine
change process. 标准/例行变更：此类变更可能被认为对患者安全、产品质量和数据完整性的风险较低。工作说明、系统管理计划、支持计划、服务请求或类似内容可用于定义变更实施任务和职责。应保留变更的记录，包括确认成功实施变更所需的任何验证任务。内部审计流程应识别任何滥用标准/例行变更流程的情况。 Like-for-Like Replacements/Repairs: These
changes may be controlled by maintenance, service management, or system administration
procedures designed to control materials usage and record system history. For
computerized systems, like-for-like changes may be extended to like-for-kind
(similar) changes providing use of such similar components has been prior approved,
e.g., replacement of a disk with an alternative higher capacity disk. 同类替换/维修：这些变更可能由用以控制物料使用和记录系统历史记录的维护、服务管理或系统管理程序进行控制。对于计算机化系统，同类变更可以扩展到类似变更，前提是此类类似组件的使用事先已获得批准，例如，用更高容量的磁盘替换磁盘。 Repairs and replacements are typically
low-risk changes. Repair and replacement processes may be defined in several
ways, including pre-approved or standard/routine changes, system administration
plans, or service requests. Replacement components and devices are pre-approved
for use as replacements. Approved replacements are usually determined during
the initial validation project. Replacements include like-for-like (identical components)
and like-for-kind (similar pre-approved components with the same functional
characteristics). Repairs and replacements are usually triggered by the
incident and problem management process following the detection of a failure.
Verification of successful repair or replacement should also be recorded. Where
devices hold data or configuration, procedures should define how data and/or
configuration is restored to the replacement component, including any
verification activities. 维修和更换通常是低风险的变更。维修和更换流程可以通过多种方式定义，包括预先批准或标准/例行变更、系统管理计划或服务请求。更换组件和设备通过已预先批准用作更换组件。批准的更换组件通常在初始验证项目期间确定。替换包括相同（相同组件）和同类（具有相同功能特征的类似预先批准的组件）。维修和更换通常由检测到故障后的事件和问题管理过程触发。还应记录验证维修或更换成功。如果设备保存数据或配置，则程序中应定义如何将数据和/或配置还原到替换组件，包括任何验证活动。 System Administration Changes: Some system
administration activities may involve changes to system components. Any such
changes and associated responsibilities should be defined as part of system
administration procedures; see Appendix O12. 系统管理变更：某些系统管理活动可能涉及对系统组件的变更。任何此类变更和相关责任都应定义为系统管理程序的一部分。 Emergency Changes: Emergency changes may be
implemented when a delay in the implementation of the change may result in a
greater impact, e.g., data loss or data integrity impact, impact on system
availability due to a cyber security attack. The criteria for determining an
emergency change should be defined in change procedures. Emergency changes may
require the retrospective application of the change process to document the
change. 紧急变更：当变更延迟实施可能导致更大的影响时，可能会实施紧急变更，例如，数据丢失或数据完整性影响，以及由于网络安全攻击而对系统可用性的影响。确定紧急变更的标准应在变更程序中定义。紧急变更可能需要回顾性应用变更流程来记录变更。 Temporary Changes: Temporary changes are
planned to be in place for a limited period. Any such changes may introduce new
or increased risk that should be assessed and managed. Particular attention should
be paid to the reversal of temporary changes to ensure that they are “rolled
back” and properly reviewed through the formal change management process before
being made permanent. Due to their temporary nature, temporary changes may not
require updates to system life cycle documentation and records. The
specification and assessment of the change may be contained within the change
records. Temporary changes should be monitored to ensure that they do not
remain beyond the plan duration. 临时变更：临时变更计划在有限的时间内实施。任何此类变更都可能带来新的或增加的风险，应对其进行评估和管理。应特别注意撤销临时变更，以确保在成为永久性变更之前，通过正式变更管理过程“回滚”和适当审查这些变更。由于其临时性质，临时变更可能不需要更新系统生命周期文档和记录。变更的说明和评估可能包含在变更记录中。应监视临时变更，以确保它们不会超出所计划的持续时间。 Global Changes: Changes to global systems
and services may require additional governance to minimize the impact of
locally identified changes on other functions and regions. For additional
information related to managing change in a globally implemented computerized
system, see the ISPE GAMP® Good Practice Guide: Global Information Systems
Control and Compliance (Second Edition) [80]. 全局变更：对全局系统和服务器进行变更可能需要额外的治理，以最大程度地减少本地识别的变更对其他功能和区域的影响。有关管理全球实施的计算机化系统中的变更的其他信息，请参阅 ISPE GAMP® 良好实践指南：全球信息系统控制和合规性（第二版）[80]。 系统在线升级/补丁引起的变更 Changes may be scheduled, for example
periodic updates by an IaaS, PaaS, and/or SaaS provider, with limited or no opportunity
to evaluate the impact of the change. Supplier assessment and monitoring
processes should ensure that the service provider has a robust change and
release management process that ensures such changes are not released without
appropriate change management and verification. 变更可能由 IaaS、PaaS 和/或 SaaS 提供商定期更新，评估变更影响的机会有限或没有机会。供应商评估和监控流程应确保服务提供商具有稳健的变更和发布管理流程，以确保不会在没有适当的变更管理和验证的情况下发布此类变更。 The regulated company should be aware of
the service providers release schedule and should evaluate the impact of
releases on business processes and regulated data. System use procedures should
be updated to reflect any impact on business processes. User training should be
provided as appropriate for major upgrades. Where appropriate, the regulated
company should conduct testing to confirm business processes have not been
adversely impacted by the changes. This may include leveraging supplier testing
through risk-based supplier evaluation. 受监管公司应了解服务提供商的发布计划，并应评估发布对业务流程和受监管数据的影响。应基于对业务流程的任何影响更新系统使用程序。应酌情为重大升级提供用户培训。适当时，受监管公司应进行测试以确认业务流程没有受到变更的不利影响。这可能包括通过基于风险的供应商评估来利用供应商测试。 Infrastructure support and/or DevOps teams
manage changes to IT infrastructure and platforms using standard configuration
templates (e.g., VM templates or IaC). Tools for managing such changes often
follow a standard (configurable) life cycle that ensures changes are assessed
and approved prior to deployment to controlled environments. Automated
monitoring may be used to deployed configuration changes and monitor
unauthorized changes to the IT infrastructure, including reverting back to
approved configurations. 基础架构支持和/或 DevOps 团队使用标准配置模板（例如 VM 模板或 IaC）管理 IT 基础架构和平台的变更。用于管理此类变更的工具通常遵循标准（可配置）生命周期，以确保在部署到受控环境之前评估和批准变更。自动监视可用于部署配置变更并监视对 IT 基础结构的未经授权的变更，包括恢复到批准的配置。 补丁和系统更新的管理方法 Regulated companies should develop an
approach to patch and upgrade management that: 受监管公司应制定一种修补和升级管理方法，该方法：
There is a need to determine what effect applying
(or electing not to apply) a patch or upgrade will have on the compliance
status of GxP regulated computerized systems. Many patches are released by
suppliers to address urgent security vulnerabilities, and exploits may already
be known or may be imminent. The time required to evaluate and test all
affected GxP regulated computerized systems prior to implementation of the
patch may therefore increase the risk to the integrity of these systems and
their data. 有必要确定应用（或选择不应用）补丁或升级对 GxP 监管计算机化系统的合规性状态有何影响。许多补丁是供应商发布来解决紧急安全漏洞，漏洞可能已经知道或可能即将发生。因此，在实施补丁之前评估和测试所有受影响的GxP监管的计算机化系统所需的时间可能会增加这些系统及其数据的完整性风险。 Regulated companies should develop a
risk-management approach for patch and upgrade management that considers both
regulatory compliance and the level of threat to the system and the wider
computing environment. The approach should ensure there is a requirement for
clear communication at the appropriate times. 受监管的公司应为补丁和升级管理开发一种风险管理方法，该方法既要考虑法规符合性，又要考虑对系统和更广泛的计算环境的威胁程度。该方法应确保需要在适当的时候进行明确的沟通。 Application-specific patches should be
planned as part of normal change management procedures. 应用程序的修补程序应作为正常变更管理过程的一部分进行规划。 质量部门在变更风险评估中的角色： The quality unit should approve the process
for risk evaluation of all patches, but generally is not involved in the
assessments. The evaluation should be performed by appropriate SMEs. If the
quality unit is involved in an assessment, they should not have final say in
how the patch is managed. Enterprise risk typically has to be given precedence
over GxP risk. If a patch must be applied that is considered to have
undesirable GxP risk, business process owners and the quality unit should work
together to mitigate the risk. This could involve verification activities, a
temporary business process change, or other approaches. 质量部门应对所有补丁的风险评估过程进行批准，但通常不参与评估。评估应由适当的主题专家进行。如果质量部门参与评估，他们不应该对如何管理补丁有最终决定权。企业风险通常必须优先于 GxP 风险。如果必须应用被认为具有不良 GxP 风险的修补程序，则业务流程所有者和质量部门应共同努力以降低风险。这可能涉及验证活动、临时业务流程变更或其他方法。 新版（2023版）GMP指南 计算机化系统变更管理 “变更管理适用于计算机化系统的硬件、软件、相关系统文档以及系统内的记录/数据。此程序一般具有通用性，可适用于公司的所有系统。 计算机化系统变更管理中需要根据变更内容和受影响的系统，考虑是否对于原先的验证范围(比如功能增减、适用范围变化等)有影响，来评估是否需要进行再验证，以及再验证需要进行的范围；一般在没有功能性变化的情况下，可以考虑不进行再验证行动，而是通过评估方式进行呈现。” “主数据维护可以作为日常操作的一部分通过系统操作SOP进行管理，通过系统变更申请表进行管理，如LIMS中产品标准、分析方法的维护等。系统升级或系统中流程的变更，应按质量体系变更流程执行。” “针对计算机化系统运维阶段涉及的IT基础架构的变更管理，根据发生的场景发起 IT 基础架构的变更，建议包含但不限于以下情况：
比如在LIMS 运行中，对其数据库或操作系统安装补丁包，即要发起变更评估其是否会对数据库的服务启动和应用系统服务启动产生影响。在网络拓扑中，对边界防火墙访问策略进行调整，即要评估其对访问及权限的影响并测试。”     公众号 GMP办公室 
  |
|
|
