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 还提及以下几点：
Das Qualitätsrisikomanagement sollte im Zusammenhang mit Change Control genutzt werden.
质量风险管理应与变更控制结合使用。
Änderungen sollten von verantwortlichen Personen genehmigt werden.
变更应经负责人批准。
Die Bewertung der Auswirkungen der Änderung vor der abschließenden Genehmigung.
在最终批准之前评估变更的影响。
Nach Durchführung der Änderung sollte bewertet werden, ob die Änderung erfolgreich war.
变更完成后，应评估变更是否成功。
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 章详细介绍了变更控制。首先是对文件的基本要求。应该记录什么？
Es soll ein Verfahren zur Prüfung und Freigabe von Änderungen (SOP) geben.
应有一个变更审核和批准的程序（SOP）。
Ausführliche Aufzeichnungen über vorgeschlagene Änderungen mit Begründung.
变更的详细记录并附有理由。
Ermittlung der Auswirkungen vor Implementierung der Änderungen.
在实施变更之前确定影响。
Aufzeichnungen über Überprüfung und Urteil zum Change (Freigabe oder Ablehnung).
记录变更的审查和决定（批准或拒绝）。
Einführung einer Methode zur Anzeige des Änderungsstatus.
描述用以显示变更状态的方法。
Methode zur Beurteilung der Gesamtauswirkung der Änderung, einschl. Tests.
用以评估变更的整体影响的方法，包括测试。
Schnittstelle zwischen Änderungskontrollverfahren und Konfigurationsmanagementsystem.
变更控制程序和配置管理系统之间的交叉。
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:
将变更划分为不同级别是有意义的。以下是一些示例：
Klasse 1, 2, 3 usw.
1级、2级、3 级等。
Major, Minor
主要，次要
Critical, Significant, Insignificant, …
重大、主要、微小、...
Kritisch, wenig kritisch, sehr kritisch, …
关键，一般，非常关键，...
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
公司已建立变更控制系统。但是，尚不清楚将通过此程序处理哪些变更。只有关于如何处理软件更新的说明。以下几点处理不规范：
Hardware defekten
硬件缺陷
Security-Patches
安全补丁
Änderungen bei Benutzerkonten
对用户帐户的变更
Notwendigen Änderungen auf Grund erkannter Softwarefehler
由于检测到软件错误而进行的必要变更
Änderungen am Testsystem
测试系统的变更
Zu den Security-Patches ein Hinweis aus PIC/S PI 041-1:
PIC / S PI 041-1 关于安全补丁的规定如下：
PIC/S PI 041-1
Security patches for operating systems and network components should be appliedin a controlled and timely manner according to vendor recommendations in orderto maintain data security. The application of security patches should beperformed in accordance with change management principles.
操作系统和网络组件的安全补丁应根据供应商的建议以受控和及时的方式应用，以维护数据安全。安全补丁的应用应按照变更管理原则进行。
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:
受监管公司应制定一种修补和升级管理方法，该方法：
Provides criteria for determining enterprise threat levels, and thus the urgency for applying patches
提供确定企业威胁级别的标准，从而提供应用补丁的紧迫性
Allows for flexibility in patch application that considers risks to both the enterprise and risks to the compliant status of regulated systems
允许在补丁应用中灵活地考虑企业风险和受监管系统合规状态的风险
Generates configuration records that show the version and patch level for a system at any point in its life cycle
生成配置记录，显示系统在其生命周期中任何时间点的版本和修补程序级别
Generates change records that describe what level of testing was done. This may include general testing at the enterprise level and/or application-specific tests. It may be determined by analysis of release notes that an application is unaffected, and no testing is required.
生成描述已完成的测试级别的变更记录。这可能包括企业级的一般测试和/或特定于应用程序的测试。可以通过分析发布说明来确定应用程序不受影响，并且不需要测试。
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 风险的修补程序，则业务流程所有者和质量部门应共同努力以降低风险。这可能涉及验证活动、临时业务流程变更或其他方法。
