Excel电子表格的合规与验证技术

从电子表格诞生以来，其应用领域便不断扩展，以至于如今任何需要用到计算机的职业和行业都离不开电子表格。制药行业概莫能外，而且成为电子表格的重度使用者。虽然如今随着各种大型软件的兴起和完善，不断地蚕食Excel的用武之地，甚至在讲述其软件的优势时，必然时时列举电子表格的劣势做对比，给人的印象似乎还在大量使用Excel电子表格就是落后的表现，但事实上国内制药企业在电子表格的使用方面整体上仍然处于十分基础的水平，远没有发挥出Excel作为生产力工具的作用。相比而言，二十年前，当各种专业化大型软件都缺乏或不成熟的时候，电子表格在欧美药企的数据自动化处理以及信息化方面起了十分重要的作用。可以说欧美企业经历了一段以电子表格为重要手段的信息化时期。这段电子表格的阶段并非如我们所认识的是走弯路，因为其广泛的使用规范了数据和流程，为后来上一些大型软件打下了坚实的基础。如今，电子表格仍然作为十分重要的工具活跃在一线。

当然，制药行业是受法规监管的行业，电子表格作为计算机化系统的一种，必然也需要符合相关的法规要求，本文将从电子表格的历史，合规控制，验证方面逐一进行探讨。 

◉  电子表格简史

世界上第一个称得上电子表格软件的是1978 年诞生于美国的VisiCalc。VisiCalc始于一名名叫丹尼尔·布莱克林（Daniel Bricklin）的哈佛商学院学生在其案例研究报告中有电子表格的类似需求。在其麻省理工学院（MIT）的熟人和另外一名创始人弗兰克斯顿（Bob Frankston）的帮助下，第一个电子数据表软件 VisiCalc 于 1978 年秋天诞生。尽管VisiCalc功能有限，但自1979年已经销售了一百多万份。1983年，IBM推出了 Lotus 1-2-3 软件包，并逐渐成为了电子数据表标准的领导者。Lotus 1-2-3 添加了完整的制图、绘图和数据库功能，增强了电子表格的功能以及易用性。用户也对软件在处理复杂计算方面的能力非常满意。最重要的是，Lotus 1-2-3 引入了命名单元格、单元格范围和宏的概念，这不仅解决了重复性任务自动化执行的问题，而且提供了一种拓展电子表格应用软件功能的工具。

直到1984年微软的 Excel在个人办公软件市场出现，Lotus 1-2-3才开始有衰退的迹象。

微软的Excel 是第一个使用下拉式菜单和通过鼠标点击进行操作的图形界面的电子表格软件。1995年春末，Excel取代了Lotus 1-2-3成为电子表格软件市场无可争议的领导者。微软一直通过增强 EXCEL 的功能来维护其优势地位，包括整合了 Visual Basic 程序语言的一个子集-Visual Basic for Application（VBA）到 EXCEL 平台的核心。这一方式允许 EXCEL 中的数据被其他微软应用软件如 Access 或 Word 共享和处理。

◉  Excel合规性缺陷与补救措施

随着电子表格软件功能的不断增强，电子表格逐渐应用到药物研发，实验室，生产，临床等各个领域。如今，一个Excel模板就相当于是一个独立的应用程序，其中包含复杂函数嵌套，逻辑判断、甚至包括采用高级语言和表单制作的用户图形化界面，用以实现数据计算，自动化报告，图表展示等多种用途，由此也对验证提出了更高的要求。

1997 年21CFR Part11“电子记录和电子签名”法规的发布，使得电子表格的验证复杂性进一步增加。这部法规要求受控的电子记录或用户签名的电子系统必须进行一些关键技术控制。电子系统的评估需要通过 4 个关键的要素：数据真实性，可靠性、机密性和不可篡改性。基于对这 4 个关键属性的要求，FDA 已经发布了一些警告信。

电子表格在访问控制方面存在固有的缺陷，即任何终端用户都可以对电子表格进行访问和编辑。不同于数据库，电子表格缺少用户水平的安全措施，这使得应用程序和支持性数据对获得了电子表格文件的所有用户都能轻易访问。针对这个缺陷，一种解决方法是部署局域网或网络服务器，将电子表格模板放入网络共享路径，公司就可以通过控制计算机中文件夹的访问权限来控制对电子表格的访问；这种方法同样提供了关于用户标识（ID）和密码的技术性控制，这包括用户 ID 的唯一性、密码策略、用户密码的周期性、历史密码的预防使用等等。另一种解决方法是，用户在Excel工作簿中自定义的访问电子表格的密码（包括工作表保护和工作簿保护），同样可以限制访问以保护电子表格的设置避免修改，包括单元格内容、公式，宏和 VBA。密码的维护必须由公司内与之无相关利益的人员，并且密码的修改应在严格的规程控制之下进行。 上述两种方法在一定程度上做到了访问控制，但能访问模板则代表用户必然能够复制该文件。复制出来的文件不受限的传播和使用又会产生新的问题。

电子表格另外一个关键的固有缺陷是没有审计追踪功能。这个缺点使得电子表格上输入的数据无法追踪和归属。其他缺点在 FDA 给各公司的警告信中均有体现，包括无法区分不同人员保存的版本，无法确认打印出的纸质文件和电子表格是否对应。根据 FDA 对电子表格开出的警告信来看，缺乏追踪审计是对电子表格数据的完整性产生质疑的最大来源。

现有的解决方案是将必要的追踪审计和数据完整不符合性降至最低。当前电子表格应用软件提供的变更追踪的机制，但并不十分安全，例如通过工作簿共享后，对所有人的编辑均可追踪单元格的修改历史，但工作簿共享能被其他用户关闭（如禁用），关闭后修订记录会全部丢失。另外，用户能在Excel应用程序中随意修改自己的用户名，从而导致修订记录的信息不真实。最后，由于修订记录与Excel文件本身放在一起，如果Excel文件丢失，修订记录同时也会丢失。为了弥补Excel本身的合规缺陷，有人使用 VBA来实现入门级的数据审计追踪和访问控制功能，即在打开Excel时要求用户输入用户名和密码，从而识别用户身份。用户登录后，在单元格中的操作被捕获后存储到Excel隐藏的工作表中或远端的数据库中。这些审计记录推荐存储到远端的数据库中，从而避免审计追踪记录同文件一同丢失。

有些公司也尝试把电子表格放到电子文档管理系统中（EDMS），由EDMS负责管理电子表格以及其中所含数据的完整性。但这种管控方式很难追踪到详细的修订记录，一般只能做版本上的管理。当前市面上比较成熟的是直接针对Excel 开发的合规化插件，通过Add-in的方式进行了合规性的功能开发。eInfotree就是这种基于Excel的合规插件，为电子表格提供了访问控制，审计追踪，电子签名等合规性功能。但囿于Excel桌面化软件的特点，虽然合规性得到了质的提升，但MS  Office文件可编辑则必然可被删除的特性，以及Excel文件出现崩溃后无法正常打开的情况时有发生，这两点仍然无法改变，甚至造成极具严重的后果。

为了保证电子表格打印输出是真实的，应在需要打印输出的电子表格页眉或页脚打印出根据数据所生成的哈希函数。生成的哈希函数应基于表格中储存的数据、电子表格保存的时间戳的组合。通过执行 VBA 代码将生成的哈希值插入打印件中。代码构建时应防止用户绕过程序的执行而无法产生哈希值，最后还要配合复核机制对打印件上的哈希函数进行确认。

尽管电子表格因为缺少技术控制手段导致其易于篡改，还是有很多解决方案可以使公司能够满足 21CFR Part 11要求。当这些解决方案能够按照合适的规程和制度得到恰当的实施，尽管不是非常完美，但可以在一定程度上保证数据的真实性，可靠性、机密性和不可篡改性。 

◉  电子表格验证

起草用户需求规范

用户需求规范是定义系统功能需求的一份文件。此文件一般由用户起草，阐述用户对电子表格具体的功能要求，以提供系统测试和确认的基础。电子表格的用户需求一般包括：

•        数据输入的类型（文本或数字）

•        数据输入的范围

•        计算

•        函数

•        报告

•        图表

•        安全，包括工作表、安全和数据

•        系统性能、质量、错误处理、启动、关闭等等

输入数据的类型和数据的有效范围必须明确规定，这一点可以看作是满足 21 CFR Part11 所要求的特定的控制，比如序列确认或装置核查。下面举几例说明：

•        输入的 pH 值在 1 到 14 之间

•        活性成分浓度（纯度）在 0.0%到 100%之间

•        输入的类型（文本 VS 数字）

•        数值是否真实或完整，只有正数，没有零等等

•        文本内容包括日期，符合“MM/DD/YYYY”格式标准或者被限制到特定的字符数。 

由电子表格自动进行的计算必须根据所使用的表达式，使用公式形式记录，而不是Excel中的公式表达形式。如果输入变量的界限已经制定，则需要在用户需求中详细说明，因为界限将会帮助定义输入数据的有效范围。下面是一个数学表达式计算的例子：

其中，H 为正态曲线的高度（纵坐标），μ 为平均值，σ 为标准偏差，π 为常数 3.14159，e 为自然对数的底数等于 2.718282，x 可以在（-∞，+∞）中取任何数值。

现代化的电子表格应用软件同样可以使用内置函数进行预定义的计算或操作。比如微软的 EXCEL，一些广泛使用的函数包括：

•        sum -求和函数

•        average-求算数平均值函数

•        stdev-计算标准偏差函数

•        count-计算单元格数函数

•        if-条件判断函数

•        lookup-查询函数

•        round-四舍五入函数

•        int.-向下取整函数

FDA 的软件验证原则指南规定：预设电子表格应用软件的内建函数能够按预期的工作是不合适的。用户需求必须详细说明使用何种内建函数以及在什么情况下使用。如果电子表格应用程序的提供者无法提供充足的文件以清晰的定义数学表达式和内建函数的对应关系，用户则需要详细的说明内建函数在数学上的形式，这是用户理解函数是如何工作的基础，还可以用此检查电子表格中的表达式是否与数学形式上的表达式对等。对于复杂的函数，包括分支或返回各种结果或计算值，当它用于判断时（ture 和 false 结果）用户需求必须说明函数所有可能的结果。如果函数使用查询值，查询参考值、查询向量和结果向量（统称为数组值），标准的查询结果应在用户需求标准中说明。如果在数值中使用外推法，则方法应同样清楚地详细说明。

电子表格可能需要根据输入的数据或自动计算出的数据以生成特定的报告和图表。这些报告或图表应在用户需求中明确，至少包括需汇总的数据范围、汇总计算的种类，报告或图表的样式 。

因为电子表格本身并不安全，所以用户需求表中应说明计算、函数、报告、图表或程序代码（宏或 VBA）如何保护以防止修改。安全措施依赖物理和逻辑组合措施，一般分为四个层次以满足 21CFR Part11 或相关法规的要求。这四层措施包括工厂、房间、用户和功能。在工厂层次，进入公司现场必须只限于公司员工，参观者必须有陪同或限制在一般的访问区域。在房间层次，进入存储主要电子表格的数据服务器的物理位置只限于指定的员工并且只能是特定的房间或区域。在工厂层面和房间层面，安全措施一般是通过锁和钥匙、保安和登记柜台、ID 卡和电子门禁卡组合措施来实现的。在用户水平，安全包括指定可以访问电子表格，这包括使用或修改的特定用户组。此安全层次涉及访问控制列表和网络安全管理的使用。功能级别包括应用程序中特定的安全功能，包括基于用户角色而制定访问不同级别的应用程序菜单。功能层次同样可以通过自定义的格式、界面和 VBA 实现。

用户需求标准由终端用户负责起草，注意用户需求中应尽量符合下面的要求：

●  独特性

●  简明性

●  明确性

●  完整性

●  可验证性

●  一致性

●  易理解性

●  可追溯性

在开始电子表格的设计与开发之前，用户需求必须尽可能的完整，因为这份文件是电子表格验证的基础，该文件应受控并且须经过相应人员的审核和批准，其中应包括终端用户的代表。批准后，用户需求规范须在变更控制管理程序下进行维护，以防止任何对项目和系统开发范围未经授权的更改。这种策略也能避免因为分歧和不断地变更干扰系统开发人员的工作。

电子表格的设计规范

当有需求规范后，用户下步可以要求开发者开发系统原型。一旦最终方案被用户接受，开发者必须提交设计规范以说明如何满足用户需求规范中的要求。设计规范至少必须包括系统的描述、表格结构，公式设计、需求追踪矩阵和具体的技术基础环境（如客户端和服务器、操作系统、电子表格版本、应用软件版本等）。

判断设计是否满足需求，可以使用需求追踪矩阵（见表 1）。一般而言，需求可以通过设计规范中一条或多条设计要素实现。

与用户需求规范相同，设计规范也必须受控。 

电子表格应用程序的验证

采用GAMP5指导原则中的软件分类，电子表格根据复杂度可分为1，3，4，5类，不同分类对验证交付物的要求亦有所不同。例如，对于4类，5类，根据GAMP5的要求，需要交付验证计划，功能规范，风险评估，设计配置规范，源代码审核，设计确认，安装确认，运行确认，需求追溯矩阵，验证总结报告等。

下表汇总了 Excel模板依据GAMP5的分类方法。

一般来讲，电子表格符合两个GAMP类别。首先，电子表格应用本身被视为标准软件包（OTS），因此属于第3类。运行电子表格应用的操作系统（如Windows）属于第1类。如果使用宏或VBA，则电子表格应用的自定义代码部分属于第5类。

软件验证相关指导原则的趋势是根据风险的大小逐渐降低安装、运行以及性能确认的工作量和复杂度。实际如何进行电子表格验证取决于签批的验证方案，验证方案需要包含测试描述，测试记录和接受标准。验证过程中，需要保留所有测试用例、输入数据和测试结果以及其他文件化的测试证据。在用户需求规范中定义的功能性需求均需要有测试用例进行测试。测试用例中需要包括系统硬件和软件配置的确认。另外，测试用例撰写和设计时，需要考虑针对关键的参数进行运行和性能测试或挑战测试。测试用例的执行结果应如实记录，并给出该测试用例是否通过的最终结论。确认方案中通过需求追踪矩阵（见表 3）将测试用例和用户需求以及设计要素进行追溯，防止设计测试用例时，遗漏测试项目。

电子表格验证的范围包括系统的静态和动态属性。技术性部分应从静态的环境配置开始。需要记录电子表格模板所在服务器硬件的配置和使用电子表格的客户端硬件的配置，记录的信息包括计算机型号、类型、制造商、序列号以及内存、磁盘容量、用户界面设施（鼠标、显示器）、外围设备（打印机、光驱）等等。对于软件配置，需要记录服务器和客户端的操作系统以及升级补丁包。对于客户端，应记录电子表格软件的版本以及对应模板的版本，编号等信息。如涉使用第三方解决方案以符合 21 CFR Part11，第三方系统的硬件和软件配置同样需要记录，并作为静态确认的一部分。

静态确认的下个阶段是核实公式、宏和 VBA 无法被终端用户修改。通过逐列逐行的对单元格中的公式进行检查以确认符合设计规范。当电子表格比较复杂时，在测试数据的选择上要考虑数量是否足够，以及是否能与表格的复杂性相匹配。例如需要确认计算所引用的单元格区域是否正确，可以选择引用开始、中间和结束点的单元格执行确认，因为在电子表格设计过程中经常应用到的复制操作容易导致出现引用偏差。

当静态确认完成后，即可开始动态的确认，以确认电子表格是否符合预期用途。动态确认需要进行电子表格模板基本操作的确认，包括应用程序的启动和关闭不存在错误。如果电子表格储存在服务器上，则必须进行数据的备份和恢复确认。其他方面的操作，如报告打印、模板检索和保存至网络服务器操作，也需要确认。对于网络化存储的电子表格，如果存在多个客户端，可以根据实际客户端总数评估和选择需要确认的客户端的数量。

最后是运行和性能确认。在这个阶段，应选择预先确定的测试数据，应用到电子表格中以获得预期的结果。若因合规考量，电子表格集成第三方解决方案的，这个部分也需要进行测试。相同的测试场景，如对含量计算准确度的测试。至少需要有3组测试数据用于测试含量计算的准确性，以确保确认结果可靠，能够始终如一的符合预期用途。

用于确认的测试数据不仅需要测试函数和计算公式有效范围内的值，还需要测试有效范围限值（上限或下限）和稍微超过范围限值（向上或向下）的值。对于条件分支函数，如果函数分支复杂，其中所有的分支和组合都必须进行确认。对于嵌套函数，应使用手动计算和独立确认的测试数据确认最终公式计算的准确性。如果存在 VBA，那么通过VBA实现的，比如按钮、下拉选择列表、选项和文本框等等同样需要进行功能实现层面的确认。

确认过程中的交付物同样十分重要。测试过程中的测试证据，如截屏、报告和打印输出物等均需要作为支持性证据加以保留。实施确认的人员需要如实填写确认记录，并整理和归纳验证过程中的测试证据，测试证据需要和特定的测试步骤进行对应，以便于追溯。

确认执行完毕后需要撰写最终的验证总结报告。报告中需要包含偏差和变更（若有）的处理方法，最终是否关闭。需要对电子表格验证工作是否完成以及该电子表格是否符合预期使用给出明确的结论。 

◉  总结

电子表格被广泛应用于各个公司的不同部门。对于制药企业，电子表格的应用需要符合21 CFR Part 11 的要求。对计算机化电子表格应用进行规范化受控管理是十分必要的。但在实践中，电子表格设计并未达到如其他计算机化应用程序所需要的用户控制和数据追踪的复杂水平，但是可以用补充性的技术解决方案来实现电子表格对 21 CFR Part 11 的符合性。

为能够达到21 CFR Part 11的符合性，终端用户需要很好的理解电子表格的应用场景，分析其局限性以及具体存在的合规差距。21 CFR Part 11 定义的策略和规程同样可以很好回答对电子表格的使用，什么是必须做的以及需要做到何种程度。最后，当评价一个系统对 21 CFR Part 11 和其他相关法规的符合性时，检查员只会关注系统是否进行了充分的测试和控制，以确保电子表格中数据的真实性，可靠性、机密性和不可篡改性。