123
第2楼2023/01/30
验证要点
LIMS 验证是指确保计算机化系统以一致且可重复的方式准确执行其设计目标的记录过程。验证过程从系统提案/要求定义开始,一直持续到系统退役并根据监管规则保留电子记录。1在验证方面,LIMS 功能,如自动报告、再现性、吞吐量和准确性,对于捕获很重要,并且必须是可量化和可验证的。在进行验证时,作为 LIMS 的定制部分的任何单个应用程序模块都成为该过程中最关键的元素。配置和定制都需要修改“开箱即用”的产品,这会带来更大的复杂性和项目实施运行时间,尤其是在需要编码时。
对于一个基本系统,LIMS 实施的最短时间通常约为 18 个月,而典型的多阶段、多站点项目可能需要 18 到 36 个月才能完成第一阶段。阶段通常由站点或功能建立。为了正确确定时间表,项目的范围必须得到所有相关人员的理解和同意。除了控制时间,还需要注意预算。
为了推动有效的验证,分配一个由关键利益相关者组成的项目团队。虽然有必要对流程和实验室工作流程有透彻的了解,但现有的工作流程也需要修改。这需要按原样映射当前流程以及要实现的所需流程。当与多个部门打交道时,这项任务变得更加复杂。为了简化实施过程,协调部门之间的工作流程是一种很好的做法(这也有助于降低成本,并且更容易传达给审计师)。
验证的一个重要方面是数据。确保数据经过数据清理以确保它们正确且有用是很重要的。为此,用户需要能够检查输入到 LIMS 的数据的正确性、意义和安全性。作为验证工作的一部分,这可能涉及:
验证通过用户输入提供的单个字符是否与数据类型的预期字符一致:整数;小数位;加号、减号和括号
评估最小/最大范围
检查与评估字符序列的测试的一致性,例如针对正则表达式的一个或多个测试
评估任何公式。
LIMS 验证中出现的一个主要挑战与模型构建、模型验证和模型在筛选集中应用所需的信息的组装有关。这是因为数据通常存在于文件或数据库中,并且可能以各种不同的格式存储。此外,数据可能驻留在各种不同的硬件平台上。2
用户需求规范
一个重要的前身是用户需求规范 (URS)。在受监管的环境中使用计算机化系统时,建立系统控制文档或系统描述是适当的,对系统进行详细的书面描述,并涵盖开发和维护。此 URS 应包含系统必须或不得做什么的明确声明。本文档对于遗留系统和正在开发的系统也很重要。URS 应包含功能性和非功能性需求:功能性、有效性、可维护性、可用性等。此类需求应是可客观验证的。
从 URS 中,软件的供应商(或内部开发人员)应该能够开发功能规范(在定制程序的情况下)或清楚地确定用于选择和购买现成系统的功能规范。功能规范应定义满足 URS(即客户需求)的系统。它旨在为计算机系统和外部接口的每个基本要求提供精确和详细的描述。反过来,这将导致设计规范,即提供有关设计产品或过程的信息的文档。例如,设计规范必须包括所有必要的图纸、尺寸、环境因素、人体工程学因素、美学因素和所需的维护。综合起来,功能和设计规范定义了系统将如何满足要求以及系统将如何在技术层面上运行。还应编写这些规范以实现客观测试。LIMS 验证以 URS 开始,其中将包含:
所有适用的监管要求
系统管理要求
多个站点要求(如果适用)
将使用新 LIMS 应用程序的实验室
需要实施的用户角色
需要实现的所有样本类型
包括批次、样品、项目、批次相关样品和稳定性样品(如适用)的工作流程
必须记录测试方法的功能;但是,由于需要记录的测试方法的数量会有所不同,因此可以考虑使用 URS 的附录或参考数据迁移计划。
产品规格功能也必须记录在案,并且与上述测试方法类似,如果要实施许多产品规格,则可以考虑附录或数据迁移计划参考。
报告应包括分析证书、标准品和试剂、稳定性结果以及任何其他适用的报告。
任何接口需求,如仪器、采购软件、质量管理软件等。
适用于 LIMS 实施的标准操作程序
风险评估
应创建风险评估以确定 LIMS 应用程序文件要求的风险级别。风险级别将有助于确定需要执行的测试级别、应创建的 SOP 以及应进行的培训级别。例如,如果有一个已识别的需求如果失败会对数据完整性产生很大影响,并且它失败的可能性很高(主要是如果它是应用程序的配置或定制部分),则测试活动将包括单元测试、操作测试和性能测试。所有 LIMS 都应经过书面的前瞻性验证或鉴定。
在良好自动化制造规范 (GAMP) 验证下,有三个核心要素:
安装认证 (IQ) – 确认完整的文档,包括根据制造商的规格检查采购订单、正确的硬件安装和软件验证;用户和供应商共同承担主要的测试责任。有效的 IQ 确定仪器按设计和规定交付,正确安装在所选环境中,并且该环境适合仪器的操作和使用。
在 IQ 和操作资格 (OQ) 之间,必须设计功能。当项目进入 OQ 时,用户仍然在编写脚本是错误的,从而导致时间和金钱的浪费。
操作鉴定——通过测试追溯到功能规范的设计要求来确认系统操作,包括在正常负载和现实压力条件下的软件和硬件功能,以评估设备和系统是否正常工作;用户和供应商共同承担主要的测试责任。特别是对于 LIMS,OQ 提供了一个书面验证,证明系统或子系统在整个代表性或预期的运行范围内按照 LIMS 规范中的规定运行。
性能确认(PQ)——这确认系统能够在特定环境中运行时执行或控制过程的活动——即用户对系统的原始需求规范进行一系列检查;责任完全落在用户身上。对于 LIMS,PQ 是记录验证集成 LIMS 在其正常操作环境中按预期执行的过程,即计算机相关系统按预期执行的过程。PQ 涉及负载测试、性能测试或两者的组合。负载测试旨在确保系统可以在正常使用期间处理系统中预期的数据和用户。负载测试需要大量的计划和资源。如果在项目的早期阶段没有计划,
PQ 的脚本应由最终用户制作,最好与训练有素的脚本编写者一起工作,以确保脚本满足验证要求。对于多个站点和部门,重要的是,如果协调允许,每个组或站点的脚本相同。
软件测试
软件有四个级别的测试:3
作为软件开发过程的一部分,软件开发人员对软件的各个单元/组件执行单元(或代码)测试。重要的是在系统开发过程中进行测试,以便在过程的早期潜在地消除错误。
集成/模块测试是软件开发过程中最关键的方面之一,因为它涉及组合和测试软件代码(和硬件,如果适用)的各个元素,直到整个系统被集成。在集成测试阶段发现的错误比在测试后期发现的错误更便宜。
系统测试测试完整和集成的软件。此级别的目的是评估系统是否符合规定的要求。
然后,用户(或客户)验收测试或性能鉴定由用户执行,作为软件测试过程的最后阶段。在这样的测试过程中,实际用户确保它可以根据需求和业务流程和相关程序处理现实场景中所需的任务。
在执行验证阶段的职责方面,程序的一般验证由供应商执行。然而,用户总是需要覆盖验证的所有阶段。4
对于测试,应开发测试脚本,正式记录并用于证明系统已安装并且正在运行并令人满意地执行。这些测试脚本应该与 URS 和系统的功能规范相关。除了 GAMP (IPSE, 2008),测试软件的指南可以在 IEEE 1298 (1992) 和 ISO/IEC/IEEE 29119-3:2013(以前的 IEEE 829)中找到。例如,ISO 29119 标准提供了有用的测试文档的大纲:
组织测试过程文档:
测试政策
组织测试策略
测试管理过程文档:
测试计划(包括测试策略)
测试状态
测试完成
动态测试过程文档:
测试设计规范
测试用例规范
测试程序规范
测试数据要求
测试数据准备报告
测试环境要求
测试环境准备报告
实际结果
测试结果
测试执行日志
测试事件报告
在评估上述内容时,用户应查看测试报告样本并询问:
测试是否涵盖了限制的边界以及无效数据的输入?
是否已记录所有测试?
是否对所有错误/故障进行了跟进?
minhao
第6楼2023/02/01
感谢指教LIMS权限确实不太好控制,不过如果使用得当,确实能减少不少人工工作量,也方便数据的利用,还是大趋势吧