计算机化系统验证管理 360,计算机化系统验证合集

2017-03-13~2017-04-04

计算机化系统验证系列(旧文重发)

2016-11-11~2016-11-25

遗留系统的验证

2017-03-06~2017-03-10

Excel表单验证系列

过往关于Excel的话题

2016-04-06~2016-05-03

计算机化系统附录总结

当然，在解读这个系列的时候，难免会有一些内容和GMP计算机化系统附录的总结重复，所以大家也可以参照计算机化系统验证总结中的内容。

OECD是个什么组织？中为大家介绍了这个组织的一些概况以及这个组织11个系列的文件，GLP是其中重要的一个组成部分，而GLP的系列文件下，这个所谓的17号文，共有122条，算是GLP领域的计算机化系统验证的一个指南性的文件，有需要的朋友可以通过今天的阅读原文按钮点击查看。

GLP和GMP计算机化系统验证的异同中为大家解读了GLP对于实验数据的可靠性的侧重，相比较GMP而言，弱化了对Intended Used的描述，但整体系统验证的要求与GMP在本质上并无太大的区别。

GLP关于计算机系统定义|预期用途中提到17号文中对于计算机化系统定义的图示与PIC/S几乎完全一致，除了软件硬件之外，还包括相应的Interface，这篇推送中详细解读了我所理解的Interface，用途方面则是从Study的角度和数据的角度去看，同时这篇推送中也提到了基于复杂程度分类的三个原则。

验证的定义以及三个关键词这篇推送Benchmark了FDA对于验证的定义，验证在我看来，并不是单纯为了产生书面的证明，书面的证明只是验证的副产物，通过验证完成一个知识和经验的积累更加重要。

Retrospective回顾性的验证已经是OECD等法规摒弃的做法了，但是在某些特殊情况下也是允许的，比如法规要求发生了变化，非GLP要求的系统变成了GLP相关的系统，这个其实和之前分享过的历史遗留系统的验证有异曲同工之处。

OECD对于Validation和Qualification的区别从GMP的角度来说，前者针对的是流程，后者针对的是具体的系统或设备，从GLP的角度来看，前者针对的是复杂的系统，后者针对的是简单的分析设备。GLP和GMP相比，计算机化系统验证的要求其实并不算特别高。

基于风险的验证并不是说一定要有一份独立的风险分析的文件，更重要的是将风险管理的思想体现在质量体系的要求中，基于流程产生的风险点得到有效的控制。

GLP中关于验证职责的原则讲得其实是培训和人员资质方面的要求，这个原则和GMP其实是通用的，人员要有资质，培训要和资质相匹配等等。

TFM-SD-QA是GLP中特有的职责的表述，TFM类似于GMP中的工厂的管理层，通常可以认为是资源的分配者，所以对应到验证中笔者的理解是做为业务流程所有者比较合适。

Facility+Inventory主要讲的是如何通过设计，达到物理安全的控制，关于系统的清单，OECD要求动态更新，同时需要体现GLP相关的用途和职责。

Vendor和Supplier哪个范围大？这个问题其实我现在已经忘记了答案，翻看原文，发现Supplier的范围更大，有的时候这些名词解释确实让人纠结，不要紧，知道在哪里找出处，坚持几次用对说对，问题也就解决了大半了。

与供应商的SLA需要写哪些内容？供应商的SLA需要明确的三点内容是各自的职责，质量体系的要求以及对验证文件保存的要求，验证活动之间的接口。

COTS软件的四个分类以及COTS系统的验证要求这四个分类其实在我看来比GAMP的分类更准确，值得参考。

系统的变更控制定义了一些常见的计算机系统变更的场景，系统的变更应该是一个更加频繁的动作，系统变更和流程变更包括控制策略的变更还是有区别的，但GLP这方面似乎区别并不如GMP那么明显。

验证文件关于文档的要求，文档管理大致可以分为管理规程类和支持特定系统验证的文件，前者定义了what is the requirement，后者定义了how the system is validated。

项目阶段(一)|  项目阶段(二)| 项目阶段(三)-关于测试，项目阶段，我们分了三期进行解读，可以说是验证的重点内容，但是项目有终点，验证无止境，项目阶段是一个很好的经验和知识累积的过程。

数据迁移与数据交换，数据准确性检查，数据以及数据的储存以及数据的储存与打印四篇文章基本上包括了整个数据的生命周期，在数据生命周期的一些管理要点OECD的17号文中都有体现，这其实是OECD说验证时的一个亮点。

审计追踪的定义以及审计追踪与系统安全日志的区别在这篇文章中有所体现，日志可以在某种程度上起到审计追踪的作用，但是审计追踪最根本的定义其实是针对电子记录的修改与变化的。

配置和变更管理在OECD中是一个段落，配置的变化与变更往往是相关的，但是何种程度的配置需要变更，OECD的指南并没有规定，不同的系统情况不同，也无法在通用的验证指南中进行定义。

业务持续和灾难恢复也属于运维阶段，启用这两个流程都应该获得相应的批准，同时特别需要强调对这两个流程需要有测试的过程，以确保关键时刻流程的可用性。

定期回顾的目的是确保系统的验证状态，定期回顾基于风险，基于历史数据，比如异常事件管理中对异常事件的统计，比如配置和变更管理中对变更的记录，如果没有一个很好的数据收集系统，定期回顾做起来会很麻烦。

物理安全+逻辑安全在强调数据完整性的当下显得非常关键与重要，逻辑安全涉及的帐号也应该建立相应的检查制度，更为关键的是，分配的权限要与培训相匹配。

电子签名(上)、电子签名(下)强调的最重要的观点是只在必要的情况下才需要产生电子签名，系统的安全日志与电子签名是两回事。

数据归档-上、数据归档-下分两期解读了归档的要求，GLP对于归档的要求除了纸质记录与电子记录外， 还涉及到样品，这在GMP中叫做留样管理，归档不同于备份，与备份的目的不同，可是很多场合还是没有一个很好的区分。

系统退役方面，OECD 17号文并没有太多的描述，需要经过计划，基于系统的复杂度与退役的风险，强调数据在生命周期内的可获得性。