|
这四条内容其实阐述了两个方面的内容，一方面是通常情况下需要哪些管理规程，产生哪些验证文件，另一方面是具体的文件中应该有哪些细节的内容。 我们先来看看验证需要哪些文件，概括出来有两类：
管理规程性质的文件在OECD中的叫法是Further Management and Validation Procedure，比如如何进行生命周期的风险管理；如何与供应商签订服务协议；如何写验证计划；如何写用户需求标准；设计标准；如何写安装测试脚本；系统投入使用的流程；系统可追溯的流程；异常事件管理流程；配置管理流程；记录管理流程；验证过程中的职责和人员要求；文档管理流程等。 第二类文件比如，特定系统的操作规程（包括软件和硬件）以及系统运维阶段的人员的职责；对于特定系统的安全管理措施以防止非授权的访问以及对数据的修改的安全管理规程；特定系统发生变更时产生的变更相关的记录，比如变更的授权、变更的测试，软件和硬件的变更记录；如何去进行定期回顾的指导性文件；系统的预防性维护和维修的规程；如何进行特定系统软件开发、接收测试以及其他相关测试的指导文件；特定系统的备份和业务持续规程；如何对特定系统进行数据的归档以及数据/系统的retrieval，包括软件的版本，系统的配置等；如何对系统进行日常的监控与管理；如何对系统进行退役。 第一类管理性质的文件提要求What is the Requirement，然后第二类的文件根据第一类管理性质的文件，产生输出，体现出How the System is Validated。 对于这些规程和记录，OECD的要求是要足够详细，这实际上体现的也是基于风险的验证的理念，写文件的本质不在于长篇大论，而在于将法规要求的每个点用最简洁的话说明白。 对于特定系统的验证而言，以下的内容或者说要建议包括的（Typically Covering）: 1）系统及系统部件的软件版本信息，比如软件名，版本号，识别号（设备的序列号）等 ； 2）对于系统预期用途的描述； 3）系统的硬件及部件的信息； 4）系统的操作系统信息以及相关的系统工具信息，比如数据库工具； 5）系统的编程语言，如适用； 6）系统的类型以及数据流，详细可以参见之前的文章，COTS软件的四个分类以及COTS系统的验证要求； 7）系统产生的数据架构（电子记录的两种形式） 8）系统的报警信息； 9）配置以及模块之间的通信情况等； 对于记录，OECD用了一个词组叫may comprise but are not limited to，到底需要多少文件，在验证计划或者变更中一定要写明白，任何事情对于验证而言都不是绝对的。 最后再来看一看验证文件保留的时间要求，OECD明确要求，验证文件保留的时限与系统所产生的数据归档的时限要求一致。 |
|
|
