[开源] 伦理批文与知情同意书版本一致性自动核查系统：面向伦理审查办公室的合规性守门工具
本项目是一个专为医疗机构伦理审查办公室设计的自动化核查工具，解决临床研究中伦理批文与知情同意书版本号、生效日期、批件编号等关键元数据不一致的常见合规风险。我们用 OCR（Tesseract.js）识别扫描件、PDF 和图片中的文字，结合正则匹配与轻量 NLP 提取版本标识，再通过结构化比对引擎判断“一份批文是否覆盖对应知情同意书”的逻辑关系，最终生成可追溯、可导出、带时间线可视化的 HTML 报告。它不是文档管理系统，也不是通用文本比对器，而是一套聚焦于「伦理审查闭环验证」场景的垂直工具；支持 CLI 交互式运行与静默批处理，技术栈基于 Node.js / TypeScript，底层依赖 pdf.js、mammoth.js、commander.js 等稳定开源组件，所有配置项（如版本号正则、关键词库）均外置可编辑，不侵入核心逻辑。
定位与能力边界
我们不做全文语义比对，也不校验知情同意书内容是否符合《赫尔辛基宣言》条款，那是伦理委员会议事范畴。本系统只做一件事：确认「你归档的这份知情同意书，是不是被当前有效的伦理批文所授权」。这个判断依赖三个锚点：版本号（如 V2.1、Rev.3）、签署/生效日期（如 2024-03-15）、批件编号（如 伦审字〔2024〕第07号）。只要三者中任一存在明显冲突（例如批文是 V1.0 而同意书印着 V2.0；或批文生效日为 2024-04-01，但同意书签署日为 2024-03-20），系统就会标记为「不一致」并进入报告清单。它不替代人工复核，但把原本需要逐份翻查、肉眼对照、手工登记的重复劳动，压缩成一次点击+一份 HTML 表格。
这种定位决定了它的适用边界：
- ✅ 适用于已建立电子归档习惯、但尚未部署 EDC 或伦理管理系统的中小型医院、区域临床试验中心；
- ✅ 适配伦理办公室日常质控抽查、专项飞行检查前的自查、新项目启动前的材料预审；
- ❌ 不处理手写签名真伪识别、不解析 PDF 表单域（AcroForm）、不对接 HIS 或科研管理系统 API；
- ❌ 不支持非中文文档（如纯英文版知情同意书未作本地化适配）；
- ❌ 不校验多语言版本间的一致性（例如中英文两版同意书是否同步更新）。
换句话说，它守的是「版本链」这一道窄门，而不是整条伦理合规流水线。
核心功能模块
系统按处理流程划分为六个内聚模块，全部在src/下清晰分层，职责单一且可独立测试：
模块目录 | 职责说明 | 关键技术/策略 |
|---|---|---|
loaders/ | 统一入口加载 PDF、DOCX、PNG/JPG/BMP、TXT 四类源文件，自动判别格式并转为标准文本流 | pdf.js 解析 PDF 文本层；mammoth.js 提取 DOCX 语义结构；Tesseract.js 处理图像；纯文本直读 |
ocr/ | 对扫描件与图片执行 OCR，内置降噪、二值化预处理，支持中英混合识别（以中文为主） | Tesseract.js + 自定义 PSM 模式（按行识别优先） |
extractors/ | 从 OCR 结果或原生文本中提取三类关键字段：版本号、日期、批件编号 | 正则模式库驱动（ |
engines/ | 执行批文与同意书的配对逻辑：先按文件名/目录关系粗筛，再按提取字段细比（版本号严格相等、日期需满足“批文早于或等于同意书签署日”） | 规则引擎，非机器学习；支持自定义宽松/严格比对模式 |
reporters/ | 生成 HTML 报告页，含顶部统计卡片（总文档数、不一致数、一致率）、详情表格（每对文档的提取结果与比对结论）、时间线图（按批件生效日排序的版本演进） | 使用原生 DOM 构建，零前端框架依赖，适配移动端横向滚动 |
exporters/ | 将比对结果导出为 CSV（供 Excel 分析）、JSON（供下游系统接入）、HTML（含内联样式，离线可打开） | 字段命名遵循伦理审查通用术语，如 |
所有模块对外暴露统一接口，例如extractVersion(text)或comparePair(approvalDoc, consentDoc)，便于未来扩展 OCR 引擎或替换 NLP 提取逻辑。
使用与配置方式
运行无需服务器，本地 Node.js 环境即可。我们提供两种使用路径：交互式 CLI（适合初次试用、小批量核查）和命令行参数模式（适合集成进质控脚本、定时任务）。
首次运行前需安装依赖并编译：
npm install npm run build之后可直接运行：
# 进入交互向导：自动提示选择输入目录、输出格式、是否静默 npm run cli # 批处理模式：指定输入目录、输出目录、报告格式 npm run cli -- --input ./example-data --output ./output --format html # 查看完整参数说明 npm run cli -- --help配置完全开放：所有识别规则均存于src/config/下的 JSON 文件，无需改代码即可调整：
配置文件 | 作用 | 示例片段（节选） |
|---|---|---|
version-patterns.json | 定义版本号正则表达式，支持多级匹配优先级 | "V\\d+\\.\\d+(?:\\.\\d+)?", "Rev\\.\\s*\\d+", "版本[：: ]+\\d+\\.\\d+" |
date-patterns.json | 匹配常见中文/数字混合日期格式 | "\\d{4}年\\d{1,2}月\\d{1,2}日", "\\d{4}-\\d{2}-\\d{2}", "签署日期：\\s*(\\d{4}-\\d{2}-\\d{2})" |
keywords.json | 标记关键字段位置的上下文词 | "version_keywords": ["版本号", "修订号", "Version No.", "Rev."] |
若某批文惯用「批件字号」而非「版本号」作为主标识（如“伦审字〔2024〕第07号”），只需在version-patterns.json中新增对应正则，并确保该字段能被extractors/模块捕获，比对引擎即自动纳入判断依据。
工程结构与可维护性
项目采用典型的分层架构，目录即契约：
ethics-doc-version-checker/ ├── src/ │ ├── loaders/ # 输入适配层：屏蔽格式差异，输出统一文本流 │ ├── ocr/ # 识别层：仅负责图像→文本，不参与业务逻辑 │ ├── extractors/ # 提取层：纯函数式，输入文本→输出 {version, date, id} │ ├── engines/ # 核心逻辑层：输入两个提取结果→输出 {is_consistent, reason} │ ├── reporters/ # 展示层：输入比对结果→输出 HTML 字符串 │ ├── exporters/ # 导出层：输入数据结构→输出文件字节流 │ ├── cli/ # 交互层：参数解析、流程调度、用户反馈 │ └── types/ # 类型定义：所有模块共享的 interface 与 type ├── data/ # 运行时数据（如日志、缓存） ├── example-data/ # 内置示例：含 PDF 批文、DOCX 同意书、JPG 扫描件各一份 └── README.md这种结构让修改成本可控：
- 若某家医院的知情同意书固定在页眉第三行印版本号，只需调整extractors/中的定位策略，不影响 OCR 或报告生成；
- 若需增加对 Markdown 格式的支持，只改动loaders/新增一个mdLoader.ts，其余模块无感；
- 若未来要接入医院 OA 系统的 HTTP 接口拉取文档，只需新增loaders/httpLoader.ts，CLI 层自动识别新来源。
所有模块均有类型约束（TypeScript），关键函数附带单元测试用例（位于__tests__/），确保每次重构不破坏比对准确性。
数据规范与扩展建议
系统默认按「一对多」关系组织文档：一个伦理批文（Approval Document）可对应多个知情同意书（Consent Document）。配对逻辑优先依赖目录结构，例如./example-data/approval/下放批文，./example-data/consent/下放同意书；若同名（如2024-001.pdf与2024-001.docx），则自动尝试关联。不强制要求文件名完全一致，但建议保持基础标识符（如项目编号、申办方缩写）统一，以降低误配率。
对于多中心研究，可将各中心子目录按./example-data/center-a/approval/、./example-data/center-a/consent/方式组织，运行时指定根目录，系统会递归扫描并保留中心维度标签，HTML 报告中可按中心筛选统计。
扩展建议（均无需改核心代码）：
- 在config/version-patterns.json中补充本院常用批件编号模板（如沪伦审〔2024〕XX号）；
- 将example-data/替换为真实归档目录软链接，实现「零迁移成本」接入；
- 用npm run cli -- --format json输出结构化结果，再用 Python 脚本聚合全院季度不一致率，生成质控简报。
限制与说明
本系统在以下场景存在固有局限，已在设计阶段明确接受：
-OCR 识别精度受限于原始图像质量：模糊、倾斜、低对比度的扫描件可能导致版本号漏提，此时需人工复核原始图像并优化扫描参数；
-正则匹配无法覆盖语义等价但字面不同的表达：例如“V2.0”与“第二版”不会被判定为同一版本，需在version-patterns.json中显式添加映射；
-不处理跨文档引用关系：如知情同意书中提及“依据 XX 批文”，系统不会反向查找该批文是否存在，仅比对当前目录下显式存在的文件；
-时间逻辑仅校验“批文生效日 ≤ 同意书签署日”：不校验“批文失效日 ≥ 同意书签署日”，因多数伦理批文无明确失效日，此规则需由人工根据批件正文判断。
这些限制不是缺陷，而是边界声明。我们选择把确定性留给规则引擎，把模糊性留给伦理委员，这正是本项目能长期稳定运行的前提。
项目地址：
https://github.com/nexorin9/ethics-doc-version-checker