本项目是一个专为医疗机构伦理审查办公室设计的自动化核查工具解决临床研究中伦理批文与知情同意书版本号、生效日期、批件编号等关键元数据不一致的常见合规风险。我们用 OCRTesseract.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 结果或原生文本中提取三类关键字段版本号、日期、批件编号正则模式库驱动version-patterns.json辅以关键词上下文定位如“版本号”“Version No.”后跟随内容engines/执行批文与同意书的配对逻辑先按文件名/目录关系粗筛再按提取字段细比版本号严格相等、日期需满足“批文早于或等于同意书签署日”规则引擎非机器学习支持自定义宽松/严格比对模式reporters/生成 HTML 报告页含顶部统计卡片总文档数、不一致数、一致率、详情表格每对文档的提取结果与比对结论、时间线图按批件生效日排序的版本演进使用原生 DOM 构建零前端框架依赖适配移动端横向滚动exporters/将比对结果导出为 CSV供 Excel 分析、JSON供下游系统接入、HTML含内联样式离线可打开字段命名遵循伦理审查通用术语如approval_version、consent_date、is_consistent所有模块对外暴露统一接口例如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\\.\\ddate-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.tsCLI 层自动识别新来源。所有模块均有类型约束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
