欢迎您注册蒲公英
您需要 登录 才可以下载或查看，没有帐号？立即注册
x
本帖最后由 背着小包包浪迹 于 2025-8-18 17:19 编辑
从生产角度谈谈，征求意见稿对生产来说需要提前准备哪些改变。- 适用范围：适用于药品和活性物质生产中使用的所有类型的计算机化系统。
- 质量风险管理：考虑流程的复杂性、自动化程度和新颖性，以及对产品质量、患者安全和数据完整性的影响
替代方法：若某些方法可作为本文件要求活动的替代方式，且已被证明并记录可提供相同或更高级别的控制，则可采用这些方法
个人思考 关于这个问题，作为企业最关注的就是遗留系统的问题，网上看到的部分讨论主要都是意思遗留系统将不会被允许。但实际看完附录内容，目前没看到明确说明。 从目前的经验看，个人觉得纸质审计追踪的方式，如果完善质量的监管以及台账和SOP的书写流程，同时结合风险评估的内容，证明纸质审计追踪记录满足计算机化系统的控制要求，即篡改的风险，理顺企业的控制逻辑，控制成本的情况下，勉强可以。但从监管的角度，如果是出口的，硬件的升级肯定是一步到位的，软件的控制可能会引起更多问题。
数据完整性： GMP 活动所用系统捕获、分析和报告的数据应可靠，这至关重要 外包活动：当使用外包活动时，受监管用户仍需对遵守本文件要求。 风险不增加：当计算机化系统取代另一系统或人工操作时，流程的总体风险不应增加。
计算机化系统的任何变更，包括但不限于其配置、硬件和软件组件、平台及操作系统的变更，都应按照既定流程进行 在验证或运行期间出现的所有偏差，均应记录，任何重大偏差均应开展调查 高级管理层应有效监督系统整个生命周期内的控制状态，分配适当资源，并营造一种促进数据完整性、安全性以及及时有效处理偏差的文化。
依赖系统：依赖系统就某一事件进行通知的计算机化系统中，应设置报警功能。当用户必须采取特定行动（若不采取该行动，产品质量、患者安全或数据完整性可能会受到损害 ）时，需设置此类报警。 设置：报警限值、延迟时间以及任何预警或警报，都应经过合理论证，并在已批准且经验证的工艺 和产品质量标准范围内进行设置。报警的设置、更改或停用操作，仅应向具备相应访问权限的用户开放，且应通过已批准的程序进行管理。
信号发出:当超出设定的报警限值且经过任何规定的延迟时间后,报警应触发可见和 / 或可听信号｡便于及时做出反应,与工作环境相适配｡
确认:可能影响产品质量､患者安全或数据完整性的关键报警,仅应由具备相应访问权限的用户进行确认｡作为确认的一部分(即确认已看到报警并将采取适当行动 ),应添加一条关于为何确认该报警的注释(见 12 审计追踪 )｡
记录:所有报警及确认需要有日志，日志应包含报警名称､报警发生的日期和 时间､确认的日期和时间､确认报警的用户的用户名和角色,以及关于为何确认该报警的任何注释｡遵循药品GMP开展工作的用户不应能够停用或编辑报警日志｡ 审核:报警日志进行适当的定期审核｡审核中应评估报警是否已被授权用户及时确认,是否采取适当行动｡审核应形成文件记录,且应对结果进行评估,以识别任何可能表明系统或流程存在不良表现或对产品产生影响的趋势｡频率和详细程度基于风险｡
输入验证:在手动输入关键数据的情况下,系统应在适用时具备验证输入合理性(如在预期范围 内 )的功能,并在输入不合理时向用户发出警报｡ 数据传输:当常规工作流程要求将关键数据从一个系统传输到另一个系统(如从实验室仪器传输 到实验室信息管理系统(LIMS) )时,应在可能的情况下基于经验证的接口进行传输,而非手动转 录｡若关键数据手动传输,应采取有效措施确保不会给数据完整性带来任何风险｡ 数据迁移:当临时流程要求将关键数据或整个数据库从一个系统迁移到另一个系统(如将数据从 旧系统迁移到新系统 )时,应基于经验证的流程进行｡除其他事项外,还应考虑发送方和接收方的约束条件｡ 加密:在适用情况下,关键数据应在系统上进行加密｡
持续管理:随着用户加入､变动以及结束参与药品GMP活动,应适时且相关地授予､修改和撤销用户访问权限及角色｡
可靠识别:身份验证方法应能高度可靠地识别用户,并有效防止未经授权的访问｡ 涉及唯一用户名和密码,或至少具备同等安全级别的方法(如生物识别 )｡仅通过令牌或智能卡进行身份验证是不够的｡ 保密密码:密码及其他身份验证方式应在系统和个人层面上对所有其他用户保密并加以保护｡从如经理或系统管理员处获取的密码,应在首次登录时更改,最好由系统强制要求更改｡
安全密码:密码应安全且由系统强制实施｡密码规则应与系统和数据中未经授权更改的风险及后果相匹配｡对于关键系统,密码长度应足以有效防止未经授权的访问,且应包含大写字母､小写字母､ 数字和符号的组合｡密码不应包含如字典中能查到的单词､人名､用户 ID､产品或组织名称,且应与 之前的密码有显著差异 ｡
强身份验证:从受控区域外对关键系统进行远程身份验证时,应包含多因素身份验证(MFA) ｡ 自动锁定:在连续多次身份验证失败(次数预先定义)后,账户应自动锁定｡仅在确认该情况并 非未经授权的登录尝试的一部分,或此类尝试的风险已消除后,系统管理员才可解锁账户｡
无活动注销:系统应包含自动无活动注销功能,在用户无活动状态持续预定义时长后,将用户注 销｡用户不应能够更改无活动注销时间(超出定义的可接受范围)或停用该功能｡ 访问日志:系统应包含访问日志(单独的,或作为审计追踪的一部分),对于每次登录,自动记 录用户名､用户角色(若可能,在多个角色中选择)､登录日期和时间､注销日期和时间(包括无活动 注销)｡ 指导原则:药品GMP活动所用计算机化系统的用户访问权限,应根据以下两项指导原则进行管理:职责分离,即参与 GMP 活动的用户不应拥有管理权限；最小权限原则,即用户拥有的访问权限不应高于其工作职能所需的权限｡
定期审核:用户账户应接受定期审核,由管理人员确认其员工的持续访问权限,以便发现那些在日常操作中本应更改或撤销但意外被遗忘的访问权限｡若用户账户通过角色进行管理,这些角色也应接受同类审核,确认角色的访问权限｡审核应形成文件记录,并采取适当行动｡这些审核的频率应与未经 授权人员对系统和数据进行更改的风险及后果相匹配｡
手动用户交互:用于控制流程､捕获､保存或报告数据,且用户可创建､修改或删除数据､设置 或访问权限､确认报警或执行电子签名等的系统,应具备审计追踪功能,自动记录所有手动用户交互｡
何人､何事､何时､何故.审计追踪应清晰捕获做出更改的用户(若用户可能有多个角色,包括用 户的角色)､更改的内容(包括被更改的数据以及旧值和新值),以及更改发生的日期和时间(如适 用,包括时区)｡审计追踪数据应在事件发生时记录,而非在流程结束时｡当数据从旧值更改为新值时,系统应自动提示用户并记录更改原因｡
不可编辑或停用:审计追踪功能应始终启用并锁定,任何用户都不应能够编辑审计追踪数据｡若 审计追踪设置或系统时间可更改,或该功能可停用,此操作本身应在审计追踪中创建一条记录,且仅应 由未参与任何药品GMP活动的系统管理员执行(见 11.10 指导原则 )｡
便于审核:系统应便于对审计追踪数据进行有效且高效的审核｡所有用户应能够在系统中对审计 追踪数据(何人､何事､何时､何故)进行排序和搜索,或者可将数据导出到具备该功能的工具中｡
独立审核:审计追踪审核应由未直接参与审核所涉活动的人员进行(同行评审)｡
审核范围:审核审计追踪记录中的所有条目可能并非有效方式｡审核应基于风险有针对性地开 展,并适应本地生产流程｡审计追踪审核程序应聚焦于检测对关键流程或数据的任何故意或无意更改, 这些更改可能表明违反了药品GMP原则,包括但不限于活动重复､错误､遗漏､未经授权的流程偏差 以及数据完整性受损｡其中一个关键要素是验证更改的原因 ｡
审核的及时性:应根据所审核流程的风险,及时开展审计追踪审核｡审计追踪审核应在批次放行 前进行,除非后续发现任何不当更改的风险可被证明是合理的｡
电子副本:应能够获取包含审计追踪数据在内的系统数据的完整电子副本｡静态且锁定的文件不可接受,应能够对数据进行搜索和排序｡
对质量受权人的可用性:对产品放行有直接影响的审计追踪审核结果,应在批次放行时可供质量 受权人(QP)查阅 ｡
开放系统:当系统所有者无法完全控制系统访问(开放系统),或其他法规有要求时,电子签名 还应满足适用的国家和国际要求,如可信服务｡
重新认证:执行电子签名时,系统应强制用户进行完整的重新认证,其安全级别至少应与系统登 录时相同(见 11.3 可靠识别 )｡连续执行后续电子签名时,可仅通过密码或生物识别进行认证｡仅通过智能卡､个人识别码(PIN)或依赖之前的系统认证进行认证是不可接受的｡
日期和时间:系统应自动记录应用电子签名的日期和时间,以及适用时的时区｡
含义:应明确用户何时执行电子签名,且在适用时,系统应提示用户说明签名的含义(如审核人 或批准人)｡
显示形式:当电子签名显示(在屏幕上或打印件上)时,显示内容应包括用户的全名､用户名 (如适用)､签名人的角色､签名的含义､签名应用的日期和时间,以及需要时的时区｡
不可争辩性:电子签名应具有不可争辩性,且与手写签名等效｡
不可破解的关联:电子签名应与其各自的记录永久关联｡应采取控制措施确保已签名记录无法被 修改,或者若后续对已签名记录进行更改,能明显显示为未签名状态｡
混合解决方案:若使用手写墨水签名(在纸上)对计算机化系统中保存的电子记录进行签名(混 合解决方案),应采取措施确保电子记录的任何更改都会使签名失效,且具有高度确定性｡可通过计算电子记录的哈希码(校验和)并将其打印在签名页上来实现｡
复制:在相关情况下,关键数据应从主数据中心复制到辅助数据中心｡复制应自动进行,且延迟 时间应足够短,以将数据丢失的风险降至最低｡辅助(故障转移)数据中心应与主站点保持安全距离, 以降低同一事件摧毁两个数据中心的风险｡
平台更新:应用程序的操作系统和平台应根据供应商建议及时更新,以避免在无支持的状态下使 用｡
及时打补丁:在操作系统和平台受支持期间,供应商通常会发布安全补丁以应对已识别的漏洞, 其中一些(关键漏洞)若不处理可能会被利用,使未经授权的人员获得系统的特权访问并执行代码(如 勒索软件攻击)｡因此,操作系统和平台供应商发布的相关安全补丁应根据供应商建议及时部署｡对于 关键漏洞,可能需要立即部署｡
验证与迁移:在供应商支持到期前,应规划并及时完成在更新后的操作系统和平台上对应用程序 的验证及数据迁移｡
严格控制:在药品GMP活动所用的服务器和计算机中,双向设备(如 USB)的使用应在组织内 部严格管控｡
有效扫描:若双向设备(如 USB)可能在组织外部使用过(如个人使用 ),它们可能有意或无 意地引入恶意软件并导致代码执行｡因此,除非已对其进行有效扫描并确认无害,且不会损害系统和数 据完整性,否则不应使用这些设备｡
停用端口:关键服务器和计算机中双向设备(如 USB)的端口默认应停用､屏蔽甚至移除,除 非这些端口用于操作系统必需的设备(如键盘或鼠标 )｡
定期备份:应按照既定程序定期备份数据和元数据,以防止在意外或故意更改､删除,或因故 障､损坏(如网络攻击导致的情况)而丢失数据时出现数据丢失｡
频率与保留期限:备份的频率､保留期限和存储方式对于减轻数据丢失影响的流程有效性至关重 要｡应按合适的间隔(如每小时､每天､每周､每月)进行备份,并通过基于风险的方法确定其保留期 限(如相应地为一周､一个月､一个季度､数年)｡
物理隔离:备份应与存储原始数据的服务器或计算机进行物理隔离,并存储在与其有安全距离的 位置,以防止两者因同一事件受到影响｡
逻辑隔离:备份不应与原始数据存储在同一逻辑网络中,以避免同时遭到破坏或篡改｡
范围:根据事件发生后恢复的关键性和紧迫性,应用程序和系统配置可能也需要进行备份｡
恢复测试:从备份中恢复数据的操作应基于风险进行测试并形成文件记录,测试应在系统验证期 间以及备份或恢复流程､工具发生变更后开展｡恢复测试应形成文件记录,且应包含对系统上数据可访 问性的验证｡
只读:在流程完成后(如产品放行),药品GMP数据和元数据(包括审计追踪 )在整个保留期 内应受到保护,防止被删除和更改｡可通过在生成或捕获数据的系统中将其状态改为只读,或通过经验 证的接口将其移至专用归档系统来实现｡
验证:当在系统内将 GMP 数据和元数据从一个位置移至另一个位置,或移至专用归档系统时, 应在删除任何系统之前,通过高度可靠的方式(如借助校验和 )验证数据的完整性｡若无法采用这种 方式,应手动验证数据的完整性和完备性｡不过,这种验证并不免除对归档和检索流程以及所涉及系统 和接口进行验证的需求｡
备份:若数据归档在服务器(磁盘)上,应按照与实时数据相同的程序定期进行备份(见16备份 )｡与其他备份一样,这些备份应在物理和逻辑上与归档数据隔离｡
耐久性:若数据长期归档在耐久性有限的易失性存储介质(如 CD )上,应遵循经验证的流程｡ 应确保根据供应商建议仅在经过验证的期限内存储数据,且如有必要,以安全的方式转移到新介质上 (见16备份 )｡
检索:应能够以允许对数据进行搜索和排序的格式检索归档数据和元数据,或者可将数据导出到 具备该功能的工具中｡
欧盟附录征求意见稿里面的内容部分个人觉得对于生产而言是细化了指导操作要求，比之前版本内容多了很多，目前征求意见中，结合之前讨论的点，好像行业对于内容反馈的比较多，也许会有很大的变动，这个具体执行层面的情况，还是需要根据具体定稿内容来操作。 分享一下最近看的欧盟附录11计算机化系统的相关内容，有兴趣可以扫码看全文
打个广告，大家有兴趣的话可以，可以扫码关注公众号，一起学习讨论学习。
补充内容 (2025-8-19 08:41):
选取的内容都是结合生产的内容进行解读，部分未体现，如有需要可以公众号输入关键词“计算机化系统”获取完整版资料 |
|手机版|蒲公英|ouryao|蒲公英
( 京ICP备14042168号-1 ) 增值电信业务经营许可证编号：京B2-20243455 互联网药品信息服务资格证书编号：(京)-非经营性-2024-0033
发表于 2025-8-18 17:02:44
置顶卡
变色卡
楼主
相互学习感谢