简介这是一份可直接移植的ISO13485计算机软件确认控制程序模板主要面向医疗器械生产企业以及需要满足体系认证的质量、研发、质检相关岗位。文档依照YY/T 0287-2017等同采用ISO13485-2016编写内容系统明确了软件确认的适用场景、职责权限并给出初次使用前确认和软件修改后再次确认的总体要求特别强调5M1E因素变化后的评估以及软件升级后重新确认的必要性。流程部分详细展开首次确认的具体操作对照使用说明书逐项确认基本功能验证人机界面的通讯连接、测量显示和故障报警参数通过切断电源、切换负载、插拔端子等方式模拟故障进行联动调试试运行后由研发人员对终端产品做理化性能综合检验以此判断软件整体性能。除程序正文外还附有《计算机软件确认表》等记录表单可结合公司实际流程修改后直接使用。资源包共包含1个PDF格式文件整体大小约70KB内容紧凑实用目前已有504人浏览学习适合医疗器械行业体系工程师、研发人员及内审员在体系建立、内外部审核或换版时参考。1. ISO13485计算机软件确认控制程序这份借鉴文档到底在救什么第二次给医疗器械相关企业做信息化系统验证时我经常看到一种现象质量部的文件柜里已经有“计算机软件确认控制程序”但 IT 手里那份软件台账只有系统名称和版本号既没有风险评估也没有对应验证报告。这样的情况在 ISO 13485 监督审核里很容易被开不符合项因为标准并不要求所有软件都做同样深度的验证却要求你有充分的理由说明什么没做、为什么没做。“ISO13485计算机软件确认控制程序(含表格)借鉴.pdf”这类文件最值得借的不是那句“应当确认”的泛泛规定而是它用“程序表格”把确认活动变成可操作、可留痕的工作流。这篇文章结合我自己的实施习惯把这件事拆成四个层次来写软件分级、表格结构、一次具体确认的执行、以及借鉴文件落到自身体系后的验收办法。2. 先做软件分级和风险评估再谈 ISO13485 验证活动的深度2.1 标准里的两个确认入口4.1.6 与 7.5.6ISO 13485:2016 与旧版本的一个明显差异就是单独增加了 4.1.6 条款要求对质量管理体系中使用的计算机软件应用进行确认。这句话很多人看过就过了但它意味着凡是在质量文件流转中起作用的软件从统计过程控制的电子表格到文档管理系统的审批流都被纳入“受确认软件”的范围。而 7.5.6 条款则覆盖生产、监视和测量中使用的软件更看重对产品特性、过程参数和放行判断的影响。两份要求并不冲突它们迈向同一个落点软件用在受控业务里就必须有证据证明它能持续完成预期功能。条款软件示例确认目标证据类别4.1.6QMS、DMS、培训平台、ERP权限、发布流程、数据可靠性软件清单、风险评估、用户验收7.5.6MES、检验系统、Excel 计算表计算逻辑、审计追踪、批记录URS、IQ/OQ/PQ、偏差记录在设计控制程序时我会在软件清单表上保留一列“合规条款”让每一条软件都能被归到其中一个或两个入口下。这样做的好处是审核员从生产记录倒查到管理系统时能立刻看出该软件是依据哪个条款被拉入确认范围的不会出现“这台电脑里装的系统凭什么是受控软件”的质疑。做 4.1.6 范围下的确认主导人通常是 IT审批人是 QA做 7.5.6 范围下的确认测试用例必须由使用部门起草QA 批准。程序正文里如果没把这个职责边界写清楚最后执行时很容易互相等。2.2 用 GAMP 5 分类确定验证深度拿到一份借鉴模板时先看它有没有“软件类别”字段。行业里最通用的做法是参照 ISPE 的 GAMP 5 分类思路把软件分成 1、3、4、5 四类。并不强制你在程序里写“依据 GAMP 5”但分类逻辑可以作为内部统一语言GAMP 类别软件特征示例通常验证深度1基础设施或操作系统Windows、数据库引擎记录环境不单独做 IQ/OQ3标准功能软件不可配置业务规则Excel 简单计算表、杀毒软件记录用途与风险做安装检查和关键功能确认4可配置软件ERP、LIMS、MES、校准管理平台做配置清单、权限矩阵、接口测试、OQ/PQ、数据完整性测试5定制开发软件自研数据采集程序、算法模块做全部验证并增加代码评审、单元测试、集成测试这个分类最大的价值是防止验证活动“一刀切”。我见过不少公司把所有软件都要求做 IQ/OQ/PQ导致验证计划堆了上百页实际连一台设备都没测完反过来也有把可配置的 LIMS 当成“现成软件”只登记不验证的。控制程序里建议用一句话兜底“对于类别 3 软件确认重点为应用环境与业务流程的匹配对于类别 4 软件必须结合配置模块的功能测试对于类别 5 软件必须在验证记录中体现源代码及变更加载过程。”这样每张软件清单表上面对应哪一列都有依据不需要临时争论。2.3 风险评估表和验证级别判定矩阵风险评估是让验证范围合理的核心工具。借鉴文件里的风险表形式可能各不相同但常见做法是打四类分患者安全影响、产品质量影响、数据完整性影响、业务连续性影响。我的做法是每项单独打 1 到 5 分再按最高分和总分综合出低、中、高三个等级。评估前先给一个打分示例“直接影响放行决策”算 5 分“只产生提示信息”算 1 分。下面是一张我常用的表格结构评估项1 分3 分5 分患者安全影响不接触患者数据间接影响设备或治疗直接用于剂量、报警、灭菌参数产品质量影响不接触过程参数影响部分记录和判断决定放行或拒绝产品数据完整性影响无关键记录有部分电子记录签核、审批、实验室数据等受监管记录业务连续性影响短期不可用无风险业务中断但可恢复停机导致产品报废或合规失效等级判定可以用一段简短的 Python 逻辑固化到验证工具里def risk_level(scores: dict) - str: max_score max(scores.values()) total sum(scores.values()) if max_score 4 or total 12: return 高 if max_score 3: return 中 return 低 print(risk_level({ph: 3, pq: 5, di: 4, bc: 2}))这段逻辑把“高风险任何一项达到 4 分或者总分达到 12 分”写成了程序规则避免每个人对规则的理解不一致。scores字典的值分别对应患者安全、产品质量、数据完整性和业务连续性。不同公司可以调整阈值但一旦调整风险评估表旁边的说明也要同步改否则现场审核时容易产生“表格规则和实际判定不一致”的问题。确认策略跟着等级走低等级做系统登记、版本锁定和备份检查中等等级增加 IQ 和关键工作流 OQ高等等级再补 PQ、审计追踪、电子签名、备份恢复和回归测试。2.4 软件确认范围上的三个典型偏差第一个偏差是“现成软件不用确认”。只要软件处理医疗业务流程或产生受控记录就得确认区别只在深度。第二个偏差是“只验证生产环境”。开发环境和测试数据的隔离也是审核重点程序里要把开发库、测试库、生产库的权限矩阵写清楚。第三个偏差是“验证一次永久有效”。操作系统补丁、软件升级、服务器迁移之后没有触发再确认遗留版本清单和实际环境不一致这是仅次于“完全没有验证记录”的常见不符合项。确认不是测试完就结束。所有版本的验证计划、报告、偏差记录要建立受控库保证证据在几年后还能回溯。这里说的受控库至少是带权限管理的网盘或 DMS而不是个人电脑的 D 盘文件夹。3. 把借鉴 PDF 拆成自有程序文件从表格提取到模板改造3.1 控制程序正文中最少要有六个部分拿到一份标题类似“ISO13485计算机软件确认控制程序(含表格)借鉴.pdf”的文件最忌讳的是整篇替换 logo 后提交审批。借鉴的准确方式是先拆结构再重写。一份能落地的确认控制程序除了修订记录正文里至少要包含六个部分目的与范围、规范性引用、职责分工、工作流程、记录与归档、变更控制。其中工作流程必须写清五步软件登记、风险评估和分类、制定验证计划、执行测试与处理偏差、发布使用通知。职责部分建议用矩阵表比大段文字直观得多活动使用部门ITQA提出系统需求负责协助审批风险评估参与执行审核编制验证计划参与起草批准执行 IQ/OQ见证执行复核执行 PQ执行支持批准放行使用确认-批准放行这张矩阵要放进程序正文里。无论借鉴文件是否提供我都建议在程序里补上特别是“放行”一栏必须由 QA 批准否则质量体系和实际使用会脱节。3.2 用 pdf 解析把借鉴 PDF 表格转成可编辑草稿PDF 适合阅读不适合直接当编辑素材。对规整的非扫描版 PDF我会用 pdfplumber 做表格抽取这一步本身不复杂真正花时间的是清洗数据。下面是一段可复用的提取脚本import pdfplumber import pandas as pd # 目标把 PDF 里的表格解析成 CSV再手工清理 src 借鉴-ISO13485-CSV.pdf with pdfplumber.open(src) as pdf: for page_no, page in enumerate(pdf.pages, 1): table page.extract_table() if not table: continue header table[0] rows table[1:] df pd.DataFrame(rows, columnsheader) # 横向合并单元格在 PDF 里经常表现为空值这里向上填充 df df.ffill() df.to_csv(fpage_{page_no}.csv, indexFalse)代码的执行逻辑是逐页打开 PDF调用extract_table()找到表格区域第一行作为列名其余行作为数据ffill()用意是把多行合并造成的空单元格用上一行内容补齐最后按页数输出 CSV。参数需要注意extract_table()在表格跨页时会丢失表头所以输出后要单独处理拼接列名里可能带空格或换行建议在 Excel 里批量替换。如果你的借鉴文件是扫描版pdfplumber 无法直接提取文字需要先用 OCR 工具把图片层转成文字层或者用支持 PDF 转 Word 的编辑器先做一次格式转换再抽内容。表格提取干净后把字段改成你想要的列名形成公司内部模板。3.3 软件清单表格的最小字段集软件清单是整个确认体系中最常被翻阅的附件也是审核员最愿意打开的表格。我一般要求清单纯文本尽量简化但下面这些字段一个都不能少字段填写说明是否必填系统编号例IT-2025-001全公司唯一必填系统名称与版本记录详细版本号不含“最新”这类词必填使用部门与组织架构一致必填部署形态单机、CS、BS、虚拟化、云端必填合规条款4.1.6 / 7.5.6 / 两者皆有必填GAMP 类别1 / 3 / 4 / 5必填风险等级低 / 中 / 高必填验证策略以风险等级为依据中、高必填证据文件编号对应验证计划或报告编号中、高必填最近确认日期精确到日必填下次再确认评估日期用于触发周期评估必填“部署形态”这一列容易被忽略但它直接决定验证内容云端系统要查供应商审计报告本地单机软件要查系统盘兼容性CS 架构要查数据库连接和端口权限。如果没有这一列后面做再确认评估时往往只能靠记忆判断影响范围。3.4 历史遗留系统和散落 Excel 的补确认路径很多公司 80% 的受控软件是历史遗留系统。对它们控制程序里要增加一条“遗留系统确认路径”允许用历史记录、配置快照、近期批记录和实际业务数据反向补做风险评估和功能抽查。这条路径的最终产出不是一张纸而是一份说明“系统在现有业务下可用”的报告审批权仍然在 QA。对于散落的 Excel 宏和计算表补确认的最小做法是把公式视图截图存档用一组已知数据重算双人复核计算结果再对文件设置保护密码并归属到 IT 台账。不要试图在一台共享电脑上追踪几十个版本的 Excel 文件直接设统一归档目录由 IT 负责发布版本。4. 实战执行一次确认URS、OQ参数和测试脚本4.1 可测试的 URS 需求怎么写用户需求说明不能只写“能算 F0 灭活值”而是要写清楚按什么逻辑、接受什么偏差。下面这张表是我的常用结构需求编号需求内容验证方法可接受标准URS-01按 Z 值和累计时间重新计算 F0展示公式与手工演算与独立计算结果差值不超过 0.01URS-02未授权人员不能修改公式单元格对工作簿设置保护并验证修改或另存的行为被阻止或留有审计痕URS-03可支持 1500 行数据输入输入 1500 行测试数据计算耗时小或缺少性能要求时则确认功能URS-04原始记录不可直接覆盖文件权限与归档目录源文件保存于受控目录修改仅为副本每一行 URS 在后面都要能对应到测试用例。验证计划表里要有“需求编号”和“测试案例编号”两列的映射关系。项目启动时 QA 必须参与写作评审否则测试都做完了QA 才说需求写得不具体返工成本最高。4.2 测试前后的文件完整性与环境参数核对对 Excel 或轻量数据库这类软件确认记录里最容易成为审查重点的是文件是否在测试前后被改动过。测试开始前我先计算受控文件的 SHA-256归档后再次校验用命令固化整个过程sha256sum F0_计算表_v1.2.xlsm F0_计算表_v1.2.xlsm.sha256 mkdir -p /archive/csv_evidences cp F0_计算表_v1.2.xlsm F0_计算表_v1.2.xlsm.sha256 /archive/csv_evidences/ cd /archive/csv_evidences sha256sum -c F0_计算表_v1.2.xlsm.sha256第一条命令生成当前文件的哈希摘要第二条命令创建归档目录第三条把文件和哈希摘要一起复制进去第四条进入归档目录第五条用-c参数校验哈希输出 OK 表示一致。这个流程的意义在于测试时用的版本、提交给审核的版本、日后复现的版本是同一个对象测试后的记录不会被偷偷修改。同步还需要做环境核对记录计算机名、操作系统版本、Excel 版本这些信息放进 IQ 报告。系统时间建议与 NTP 服务对齐因为电子签名和时间戳都依赖系统时钟若时间漂移证据链的可信度会下降。4.3 用结构化模板记录测试证据并导出 PDF很多人以为记录测试证据靠截图其实截图只是辅助结构化字段才是可检索的档案。我习惯把测试用例写成 YAML在 VSCode 里填写再导出 PDF 存档。模板如下case_id: OQ-001 requirement_ref: URS-01 title: F0 灭活值计算准确性确认 precondition: - 使用受控副本 v1.2 - 启用公式审计工具 steps: - step: 在 B2 输入温度121.1C2 输入 z 值10D2 输入时间间隔0.5 expected: F0 增加 0.5 - step: 追加一行时间间隔改为1分钟 expected: F0 增加 1.0 test_data: - {temp: 121.1, z: 10, dt: 0.5} actual_result: PASS tester: (手写/电子签名) date: 2025-03-10YAML 的precondition写测试前置条件steps和expected是一组动作与预期结果的配对actual_result留手写判定栏。写清楚test_data能方便将来做回归时直接替换参数。填写完成后用 VSCode 的 Markdown PDF 插件导出就能得到带页码、带目录的存档文件。如果你在浏览器里操作业务系统也可以用浏览器打印功能把完整界面输出成 PDF业内常说的网页打印输出就是这个用法它能保留按钮状态、当前用户名和时间戳作为辅助证据很有效。4.4 偏差处理、回归测试与再确认触发条件测试过程一定会遇到输出与预期不一致的情况。控制程序中要写明偏差编号必须关联到测试案例写明根因分析结论如果偏差不影响试用结论由测试负责人和 QA 批准回归测试范围若偏差影响范围大应当重新执行完整 OQ 再考虑放行。再确认触发点建议写成清单放到程序附录里。我一般保留这些条目软件补丁或升级、服务器迁移或虚拟化调整、操作系统基线变更、关键配置参数变化、相关过程风险分析发现新风险。再确认不一定要全部重跑可以通过风险评估决定只做 IQ 还是 IQOQ但“判定”本身必须保留记录不能口头说不用做。提示补丁确认时不要只检查版本号还要验证受影响的服务是否真的启动。我遇到过升级补丁后版本号显示成功但程序入口没有加载的情况最终是靠 OQ 里的“服务可访问”测试环节抓出来的。5. 借鉴进自家库后的验收方法版本比对与审计展示借鉴文件最终要收进受控文件库作为公司正式程序。这里有一个容易忽略的动作转录后要做版本及内容一致性比对。如果在借鉴文件上直接改动很容易漏改残留旧公司的抬头或表格编号。我用文本层比对工具输出差异报告例如先用pdftotext抽取两版文字再执行 diff人工只检查页眉、表格列名和程序标题对报错位置不兼容字符造成的差异不做判断。差异列表打印后作为受控变更的附件。接下来做“程序正文与附件表格一致性核对”。检查规则就一句话程序里提到的表格附件里必须有对应编号程序里要求生成的记录执行例子里就必须出现对应记录。建议维护一张对应矩阵放到程序修订页程序正文步骤使用到的表格表单编号与版本软件登记软件清单QM-SW-01 A/02风险评估风险评估表QM-SW-02 A/02验证计划验证计划与范围QM-SW-03 A/01执行测试IQ/OQ/PQ 记录模板QM-SW-04 A/01偏差处理偏差报告与回归记录QM-SW-05 A/01验收时给 IT 和 QA 各准备一条演练路径。IT 侧从受控软件清单里随机挑一个系统现场呈现三件套风险评估、URS、IQ/OQ/PQ 报告。QA 侧从某一批次产品记录倒查其计算工具和验证证据这条链拉通后审核时基本不会翻多份文件。所有证据不要散落在个人手里统一传至 DMS 或受控网盘设置只读权限并做备份。最后建议把“再确认评估触发器”做成日历提醒而不是每年做一次固定大检查。系统升级、服务器迁移、关键补丁这些事件发生时就触发评估每年 1 月再对上一年新增和变更的系统做一次回归扫描比对软件清单与实际运行环境的差异。这份差异清单就是当年确认体系的自我体检结果。本文还有配套的精品资源点击获取 ISO13485计算机软件确认控制程序：从GAMP 5分类到验证执行
简介这是一份可直接移植的ISO13485计算机软件确认控制程序模板主要面向医疗器械生产企业以及需要满足体系认证的质量、研发、质检相关岗位。文档依照YY/T 0287-2017等同采用ISO13485-2016编写内容系统明确了软件确认的适用场景、职责权限并给出初次使用前确认和软件修改后再次确认的总体要求特别强调5M1E因素变化后的评估以及软件升级后重新确认的必要性。流程部分详细展开首次确认的具体操作对照使用说明书逐项确认基本功能验证人机界面的通讯连接、测量显示和故障报警参数通过切断电源、切换负载、插拔端子等方式模拟故障进行联动调试试运行后由研发人员对终端产品做理化性能综合检验以此判断软件整体性能。除程序正文外还附有《计算机软件确认表》等记录表单可结合公司实际流程修改后直接使用。资源包共包含1个PDF格式文件整体大小约70KB内容紧凑实用目前已有504人浏览学习适合医疗器械行业体系工程师、研发人员及内审员在体系建立、内外部审核或换版时参考。1. ISO13485计算机软件确认控制程序这份借鉴文档到底在救什么第二次给医疗器械相关企业做信息化系统验证时我经常看到一种现象质量部的文件柜里已经有“计算机软件确认控制程序”但 IT 手里那份软件台账只有系统名称和版本号既没有风险评估也没有对应验证报告。这样的情况在 ISO 13485 监督审核里很容易被开不符合项因为标准并不要求所有软件都做同样深度的验证却要求你有充分的理由说明什么没做、为什么没做。“ISO13485计算机软件确认控制程序(含表格)借鉴.pdf”这类文件最值得借的不是那句“应当确认”的泛泛规定而是它用“程序表格”把确认活动变成可操作、可留痕的工作流。这篇文章结合我自己的实施习惯把这件事拆成四个层次来写软件分级、表格结构、一次具体确认的执行、以及借鉴文件落到自身体系后的验收办法。2. 先做软件分级和风险评估再谈 ISO13485 验证活动的深度2.1 标准里的两个确认入口4.1.6 与 7.5.6ISO 13485:2016 与旧版本的一个明显差异就是单独增加了 4.1.6 条款要求对质量管理体系中使用的计算机软件应用进行确认。这句话很多人看过就过了但它意味着凡是在质量文件流转中起作用的软件从统计过程控制的电子表格到文档管理系统的审批流都被纳入“受确认软件”的范围。而 7.5.6 条款则覆盖生产、监视和测量中使用的软件更看重对产品特性、过程参数和放行判断的影响。两份要求并不冲突它们迈向同一个落点软件用在受控业务里就必须有证据证明它能持续完成预期功能。条款软件示例确认目标证据类别4.1.6QMS、DMS、培训平台、ERP权限、发布流程、数据可靠性软件清单、风险评估、用户验收7.5.6MES、检验系统、Excel 计算表计算逻辑、审计追踪、批记录URS、IQ/OQ/PQ、偏差记录在设计控制程序时我会在软件清单表上保留一列“合规条款”让每一条软件都能被归到其中一个或两个入口下。这样做的好处是审核员从生产记录倒查到管理系统时能立刻看出该软件是依据哪个条款被拉入确认范围的不会出现“这台电脑里装的系统凭什么是受控软件”的质疑。做 4.1.6 范围下的确认主导人通常是 IT审批人是 QA做 7.5.6 范围下的确认测试用例必须由使用部门起草QA 批准。程序正文里如果没把这个职责边界写清楚最后执行时很容易互相等。2.2 用 GAMP 5 分类确定验证深度拿到一份借鉴模板时先看它有没有“软件类别”字段。行业里最通用的做法是参照 ISPE 的 GAMP 5 分类思路把软件分成 1、3、4、5 四类。并不强制你在程序里写“依据 GAMP 5”但分类逻辑可以作为内部统一语言GAMP 类别软件特征示例通常验证深度1基础设施或操作系统Windows、数据库引擎记录环境不单独做 IQ/OQ3标准功能软件不可配置业务规则Excel 简单计算表、杀毒软件记录用途与风险做安装检查和关键功能确认4可配置软件ERP、LIMS、MES、校准管理平台做配置清单、权限矩阵、接口测试、OQ/PQ、数据完整性测试5定制开发软件自研数据采集程序、算法模块做全部验证并增加代码评审、单元测试、集成测试这个分类最大的价值是防止验证活动“一刀切”。我见过不少公司把所有软件都要求做 IQ/OQ/PQ导致验证计划堆了上百页实际连一台设备都没测完反过来也有把可配置的 LIMS 当成“现成软件”只登记不验证的。控制程序里建议用一句话兜底“对于类别 3 软件确认重点为应用环境与业务流程的匹配对于类别 4 软件必须结合配置模块的功能测试对于类别 5 软件必须在验证记录中体现源代码及变更加载过程。”这样每张软件清单表上面对应哪一列都有依据不需要临时争论。2.3 风险评估表和验证级别判定矩阵风险评估是让验证范围合理的核心工具。借鉴文件里的风险表形式可能各不相同但常见做法是打四类分患者安全影响、产品质量影响、数据完整性影响、业务连续性影响。我的做法是每项单独打 1 到 5 分再按最高分和总分综合出低、中、高三个等级。评估前先给一个打分示例“直接影响放行决策”算 5 分“只产生提示信息”算 1 分。下面是一张我常用的表格结构评估项1 分3 分5 分患者安全影响不接触患者数据间接影响设备或治疗直接用于剂量、报警、灭菌参数产品质量影响不接触过程参数影响部分记录和判断决定放行或拒绝产品数据完整性影响无关键记录有部分电子记录签核、审批、实验室数据等受监管记录业务连续性影响短期不可用无风险业务中断但可恢复停机导致产品报废或合规失效等级判定可以用一段简短的 Python 逻辑固化到验证工具里def risk_level(scores: dict) - str: max_score max(scores.values()) total sum(scores.values()) if max_score 4 or total 12: return 高 if max_score 3: return 中 return 低 print(risk_level({ph: 3, pq: 5, di: 4, bc: 2}))这段逻辑把“高风险任何一项达到 4 分或者总分达到 12 分”写成了程序规则避免每个人对规则的理解不一致。scores字典的值分别对应患者安全、产品质量、数据完整性和业务连续性。不同公司可以调整阈值但一旦调整风险评估表旁边的说明也要同步改否则现场审核时容易产生“表格规则和实际判定不一致”的问题。确认策略跟着等级走低等级做系统登记、版本锁定和备份检查中等等级增加 IQ 和关键工作流 OQ高等等级再补 PQ、审计追踪、电子签名、备份恢复和回归测试。2.4 软件确认范围上的三个典型偏差第一个偏差是“现成软件不用确认”。只要软件处理医疗业务流程或产生受控记录就得确认区别只在深度。第二个偏差是“只验证生产环境”。开发环境和测试数据的隔离也是审核重点程序里要把开发库、测试库、生产库的权限矩阵写清楚。第三个偏差是“验证一次永久有效”。操作系统补丁、软件升级、服务器迁移之后没有触发再确认遗留版本清单和实际环境不一致这是仅次于“完全没有验证记录”的常见不符合项。确认不是测试完就结束。所有版本的验证计划、报告、偏差记录要建立受控库保证证据在几年后还能回溯。这里说的受控库至少是带权限管理的网盘或 DMS而不是个人电脑的 D 盘文件夹。3. 把借鉴 PDF 拆成自有程序文件从表格提取到模板改造3.1 控制程序正文中最少要有六个部分拿到一份标题类似“ISO13485计算机软件确认控制程序(含表格)借鉴.pdf”的文件最忌讳的是整篇替换 logo 后提交审批。借鉴的准确方式是先拆结构再重写。一份能落地的确认控制程序除了修订记录正文里至少要包含六个部分目的与范围、规范性引用、职责分工、工作流程、记录与归档、变更控制。其中工作流程必须写清五步软件登记、风险评估和分类、制定验证计划、执行测试与处理偏差、发布使用通知。职责部分建议用矩阵表比大段文字直观得多活动使用部门ITQA提出系统需求负责协助审批风险评估参与执行审核编制验证计划参与起草批准执行 IQ/OQ见证执行复核执行 PQ执行支持批准放行使用确认-批准放行这张矩阵要放进程序正文里。无论借鉴文件是否提供我都建议在程序里补上特别是“放行”一栏必须由 QA 批准否则质量体系和实际使用会脱节。3.2 用 pdf 解析把借鉴 PDF 表格转成可编辑草稿PDF 适合阅读不适合直接当编辑素材。对规整的非扫描版 PDF我会用 pdfplumber 做表格抽取这一步本身不复杂真正花时间的是清洗数据。下面是一段可复用的提取脚本import pdfplumber import pandas as pd # 目标把 PDF 里的表格解析成 CSV再手工清理 src 借鉴-ISO13485-CSV.pdf with pdfplumber.open(src) as pdf: for page_no, page in enumerate(pdf.pages, 1): table page.extract_table() if not table: continue header table[0] rows table[1:] df pd.DataFrame(rows, columnsheader) # 横向合并单元格在 PDF 里经常表现为空值这里向上填充 df df.ffill() df.to_csv(fpage_{page_no}.csv, indexFalse)代码的执行逻辑是逐页打开 PDF调用extract_table()找到表格区域第一行作为列名其余行作为数据ffill()用意是把多行合并造成的空单元格用上一行内容补齐最后按页数输出 CSV。参数需要注意extract_table()在表格跨页时会丢失表头所以输出后要单独处理拼接列名里可能带空格或换行建议在 Excel 里批量替换。如果你的借鉴文件是扫描版pdfplumber 无法直接提取文字需要先用 OCR 工具把图片层转成文字层或者用支持 PDF 转 Word 的编辑器先做一次格式转换再抽内容。表格提取干净后把字段改成你想要的列名形成公司内部模板。3.3 软件清单表格的最小字段集软件清单是整个确认体系中最常被翻阅的附件也是审核员最愿意打开的表格。我一般要求清单纯文本尽量简化但下面这些字段一个都不能少字段填写说明是否必填系统编号例IT-2025-001全公司唯一必填系统名称与版本记录详细版本号不含“最新”这类词必填使用部门与组织架构一致必填部署形态单机、CS、BS、虚拟化、云端必填合规条款4.1.6 / 7.5.6 / 两者皆有必填GAMP 类别1 / 3 / 4 / 5必填风险等级低 / 中 / 高必填验证策略以风险等级为依据中、高必填证据文件编号对应验证计划或报告编号中、高必填最近确认日期精确到日必填下次再确认评估日期用于触发周期评估必填“部署形态”这一列容易被忽略但它直接决定验证内容云端系统要查供应商审计报告本地单机软件要查系统盘兼容性CS 架构要查数据库连接和端口权限。如果没有这一列后面做再确认评估时往往只能靠记忆判断影响范围。3.4 历史遗留系统和散落 Excel 的补确认路径很多公司 80% 的受控软件是历史遗留系统。对它们控制程序里要增加一条“遗留系统确认路径”允许用历史记录、配置快照、近期批记录和实际业务数据反向补做风险评估和功能抽查。这条路径的最终产出不是一张纸而是一份说明“系统在现有业务下可用”的报告审批权仍然在 QA。对于散落的 Excel 宏和计算表补确认的最小做法是把公式视图截图存档用一组已知数据重算双人复核计算结果再对文件设置保护密码并归属到 IT 台账。不要试图在一台共享电脑上追踪几十个版本的 Excel 文件直接设统一归档目录由 IT 负责发布版本。4. 实战执行一次确认URS、OQ参数和测试脚本4.1 可测试的 URS 需求怎么写用户需求说明不能只写“能算 F0 灭活值”而是要写清楚按什么逻辑、接受什么偏差。下面这张表是我的常用结构需求编号需求内容验证方法可接受标准URS-01按 Z 值和累计时间重新计算 F0展示公式与手工演算与独立计算结果差值不超过 0.01URS-02未授权人员不能修改公式单元格对工作簿设置保护并验证修改或另存的行为被阻止或留有审计痕URS-03可支持 1500 行数据输入输入 1500 行测试数据计算耗时小或缺少性能要求时则确认功能URS-04原始记录不可直接覆盖文件权限与归档目录源文件保存于受控目录修改仅为副本每一行 URS 在后面都要能对应到测试用例。验证计划表里要有“需求编号”和“测试案例编号”两列的映射关系。项目启动时 QA 必须参与写作评审否则测试都做完了QA 才说需求写得不具体返工成本最高。4.2 测试前后的文件完整性与环境参数核对对 Excel 或轻量数据库这类软件确认记录里最容易成为审查重点的是文件是否在测试前后被改动过。测试开始前我先计算受控文件的 SHA-256归档后再次校验用命令固化整个过程sha256sum F0_计算表_v1.2.xlsm F0_计算表_v1.2.xlsm.sha256 mkdir -p /archive/csv_evidences cp F0_计算表_v1.2.xlsm F0_计算表_v1.2.xlsm.sha256 /archive/csv_evidences/ cd /archive/csv_evidences sha256sum -c F0_计算表_v1.2.xlsm.sha256第一条命令生成当前文件的哈希摘要第二条命令创建归档目录第三条把文件和哈希摘要一起复制进去第四条进入归档目录第五条用-c参数校验哈希输出 OK 表示一致。这个流程的意义在于测试时用的版本、提交给审核的版本、日后复现的版本是同一个对象测试后的记录不会被偷偷修改。同步还需要做环境核对记录计算机名、操作系统版本、Excel 版本这些信息放进 IQ 报告。系统时间建议与 NTP 服务对齐因为电子签名和时间戳都依赖系统时钟若时间漂移证据链的可信度会下降。4.3 用结构化模板记录测试证据并导出 PDF很多人以为记录测试证据靠截图其实截图只是辅助结构化字段才是可检索的档案。我习惯把测试用例写成 YAML在 VSCode 里填写再导出 PDF 存档。模板如下case_id: OQ-001 requirement_ref: URS-01 title: F0 灭活值计算准确性确认 precondition: - 使用受控副本 v1.2 - 启用公式审计工具 steps: - step: 在 B2 输入温度121.1C2 输入 z 值10D2 输入时间间隔0.5 expected: F0 增加 0.5 - step: 追加一行时间间隔改为1分钟 expected: F0 增加 1.0 test_data: - {temp: 121.1, z: 10, dt: 0.5} actual_result: PASS tester: (手写/电子签名) date: 2025-03-10YAML 的precondition写测试前置条件steps和expected是一组动作与预期结果的配对actual_result留手写判定栏。写清楚test_data能方便将来做回归时直接替换参数。填写完成后用 VSCode 的 Markdown PDF 插件导出就能得到带页码、带目录的存档文件。如果你在浏览器里操作业务系统也可以用浏览器打印功能把完整界面输出成 PDF业内常说的网页打印输出就是这个用法它能保留按钮状态、当前用户名和时间戳作为辅助证据很有效。4.4 偏差处理、回归测试与再确认触发条件测试过程一定会遇到输出与预期不一致的情况。控制程序中要写明偏差编号必须关联到测试案例写明根因分析结论如果偏差不影响试用结论由测试负责人和 QA 批准回归测试范围若偏差影响范围大应当重新执行完整 OQ 再考虑放行。再确认触发点建议写成清单放到程序附录里。我一般保留这些条目软件补丁或升级、服务器迁移或虚拟化调整、操作系统基线变更、关键配置参数变化、相关过程风险分析发现新风险。再确认不一定要全部重跑可以通过风险评估决定只做 IQ 还是 IQOQ但“判定”本身必须保留记录不能口头说不用做。提示补丁确认时不要只检查版本号还要验证受影响的服务是否真的启动。我遇到过升级补丁后版本号显示成功但程序入口没有加载的情况最终是靠 OQ 里的“服务可访问”测试环节抓出来的。5. 借鉴进自家库后的验收方法版本比对与审计展示借鉴文件最终要收进受控文件库作为公司正式程序。这里有一个容易忽略的动作转录后要做版本及内容一致性比对。如果在借鉴文件上直接改动很容易漏改残留旧公司的抬头或表格编号。我用文本层比对工具输出差异报告例如先用pdftotext抽取两版文字再执行 diff人工只检查页眉、表格列名和程序标题对报错位置不兼容字符造成的差异不做判断。差异列表打印后作为受控变更的附件。接下来做“程序正文与附件表格一致性核对”。检查规则就一句话程序里提到的表格附件里必须有对应编号程序里要求生成的记录执行例子里就必须出现对应记录。建议维护一张对应矩阵放到程序修订页程序正文步骤使用到的表格表单编号与版本软件登记软件清单QM-SW-01 A/02风险评估风险评估表QM-SW-02 A/02验证计划验证计划与范围QM-SW-03 A/01执行测试IQ/OQ/PQ 记录模板QM-SW-04 A/01偏差处理偏差报告与回归记录QM-SW-05 A/01验收时给 IT 和 QA 各准备一条演练路径。IT 侧从受控软件清单里随机挑一个系统现场呈现三件套风险评估、URS、IQ/OQ/PQ 报告。QA 侧从某一批次产品记录倒查其计算工具和验证证据这条链拉通后审核时基本不会翻多份文件。所有证据不要散落在个人手里统一传至 DMS 或受控网盘设置只读权限并做备份。最后建议把“再确认评估触发器”做成日历提醒而不是每年做一次固定大检查。系统升级、服务器迁移、关键补丁这些事件发生时就触发评估每年 1 月再对上一年新增和变更的系统做一次回归扫描比对软件清单与实际运行环境的差异。这份差异清单就是当年确认体系的自我体检结果。本文还有配套的精品资源点击获取