本项目是面向医院药房、临床医师与信息科的处方安全辅助系统专为落实《医疗机构处方审核规范》中“对患者过敏史进行前置核查”的刚性要求而设计。它不替代人工判断而是以可验证的规则引擎结构化知识库为底座将患者过敏史、药品成分、交叉反应关系三者实时比对在医嘱开具或审方环节自动识别风险。我们提供命令行工具CLI、Python API 和轻量 Web 界面三种交付形态支持 JSON/CSV 双格式数据接入核心模块包括患者过敏史管理器、过敏原知识库、多级风险检测引擎。技术栈采用 Python 3.8 生态依赖 pandas 做数据规整、pydantic 保障数据模型一致性、rich 渲染终端报告、Flask 构建 Web 服务所有逻辑均可本地部署、离线运行。定位与能力范围我们不做全院级 HIS 对接也不覆盖用药剂量合理性或药物相互作用分析。本项目的边界非常明确只做一件事过敏风险的确定性筛查。它不猜测、不推断、不学习只依据已录入的患者过敏史和预置的过敏原映射关系执行确定性的成分匹配与层级判定。这意味着- 若患者记录对「青霉素」过敏系统能识别出「阿莫西林」「氨苄西林」等 β-内酰胺类药物- 若知识库中定义了「磺胺类药物」与「呋塞米」存在化学基团交叉反应系统会在患者有磺胺过敏史时对含呋塞米的处方标出中危- 所有风险结论都附带可追溯的路径从患者 ID → 过敏原名称 → 药品成分 → 匹配依据全部落于报告字段不黑箱。这种设计不是妥协而是聚焦。医疗差错中过敏误用属于低频但高致命事件其防控关键不在模型复杂度而在规则透明、路径可查、结果即时。我们把“能不能拦住”这件事压在结构清晰、修改方便、验证直接的工程实现上。核心功能系统围绕过敏防控闭环构建四个不可拆分的功能模块模块职责数据来源与操作方式患者过敏史管理维护每位患者的过敏记录支持增删改查通过 CLI 加载 JSON/CSVWeb 界面提供表单录入API 接口供外部系统写入过敏原知识库存储药品通用名、商品名、活性成分、化学基团、食物交叉反应等映射关系静态 JSON 文件allergy_database.json人工编辑即可扩展检测引擎执行匹配逻辑成分级精确匹配 基团级模糊匹配 类别级泛化匹配内置三级判定策略输出结构化结果含风险等级、触发项、依据说明报告生成输出可读性强的结果终端彩色日志、JSON 结构化数据、Web 页面可视化表格CLI 默认输出 rich 格式终端报告--output参数指定 JSON 文件路径Web 界面自动渲染分级卡片风险等级并非主观打分而是由匹配深度决定-高危患者过敏原与处方药品活性成分完全一致如患者青霉素过敏处方含阿莫西林-中危患者过敏原与处方药品属同一化学类别或存在明确文献记载的交叉反应如患者磺胺过敏处方含氢氯噻嗪-低危仅存在结构相似性提示尚无临床共识如患者对某β受体阻滞剂过敏处方含另一结构相近品种-无风险未命中任何规则路径。每类结果均附带原文字段引用例如报告中会明确写出「触发项患者 P001 过敏原【头孢曲松钠】处方药品【头孢克肟胶囊】含相同β-内酰胺环结构」。使用与配置安装只需标准 Python 工作流无需编译或额外服务git clone repository-url cd allergy-prescription-firewall python -m venv venv source venv/bin/activate pip install -r requirements.txtCLI 是最常用入口支持以下典型场景python -m src.allergy_firewall.cli --patients data/sample_data/patients.json --prescriptions data/sample_data/prescriptions.json参数含义清晰对应业务动作参数说明示例值--patients指定患者过敏史文件路径data/sample_data/patients.json--prescriptions指定待检处方文件路径data/sample_data/prescriptions.json--output指定报告输出路径默认打印到终端report.json--verbose显示详细匹配过程调试用无值开关型Web 界面适合非技术人员快速试用或临时查检cd src python -m allergy_firewall.web_app启动后访问 http://localhost:5000界面分为三个标签页- 「处方检测」下拉选择患者、手动输入或粘贴药品列表支持通用名/商品名点击运行即得分级结果- 「患者管理」新增患者时需填写姓名、ID、过敏原可多选、过敏类型药物/食物/其他、发生时间- 「检测记录」按时间倒序列出历史检测点击任一条可展开原始输入与完整匹配链路。所有操作不依赖数据库全部基于内存计算与文件读写无后台服务依赖。数据与扩展数据结构完全开放所有示例文件均位于data/sample_data/目录下可直接作为模板复用-patients.json每个 patient 对象含id、name、allergies数组每条过敏记录含substance过敏原名称、type类型、severity严重程度描述仅作备注-prescriptions.json每个 prescription 含id、patient_id、medicines数组每种药品含name药品名、dosage剂量非必填、route给药途径非必填-allergy_database.json核心知识库以 JSON 对象形式组织键为过敏原名称值为包含components成分列表、cross_reactions交叉反应药品列表、chemical_groups所属化学基团的子对象。扩展知识库只需编辑该 JSON 文件。例如添加新交叉反应碘造影剂: { cross_reactions: [碘海醇, 碘帕醇, 泛影葡胺], chemical_groups: [有机碘化合物] }下次运行检测时即生效无需重启服务或重新安装。限制与说明我们坦诚说明当前能力边界避免误用- 不支持 HL7/FHIR 等医疗消息协议直连需外部系统先将数据转为 JSON/CSV- 不解析图片、PDF 或手写处方仅处理结构化文本输入- Web 界面为单机轻量版未内置用户权限、审计日志或 HTTPS 支持生产环境建议套 Nginx 并启用反向代理- 高危拦截不等于临床终审所有结果必须由药师或医师结合患者实际病史确认- 知识库覆盖以国内常用药品及《中华人民共和国药典》《临床诊疗指南》为基础罕见药或新上市药需人工补充。常见问题已在项目文档中结构化归档例如- 如何批量导入百名患者→ 使用patients.csv按照示例字段命名后CLI 参数指向该 CSV 即可- 检测结果与预期不符→ 先运行--verbose查看匹配路径再核对allergy_database.json中对应过敏原的components字段是否遗漏- Web 页面空白→ 检查浏览器控制台是否报 CORS 错误确认已安装flask-cors或改用 CLI 模式验证逻辑是否正常。这些不是缺陷清单而是协作接口告诉使用者哪些事该由本系统完成哪些事应交还给既有的临床流程与专业判断。工程结构代码组织严格按职责分层无冗余耦合-models.py定义 Patient、Prescription、AllergyRecord 等 Pydantic 模型强制字段校验-knowledge_base.py封装知识库加载、查询、缓存机制所有匹配逻辑从此处调用-patient_manager.py提供统一接口加载/筛选/序列化患者数据屏蔽文件格式差异-detection_engine.py是核心接收 PatientManager 与 KnowledgeBase 实例对外暴露.detect()方法-cli.py和web_app.py分别为两种交互入口共享同一套引擎确保结果一致性-examples/下的脚本是真实可用的最小运行单元可直接复制进自有项目调用。这种结构让二次开发成本极低若医院已有患者主索引系统只需继承PatientManager并重写load_from_external_api()方法若需对接内部审方平台直接 importDetectionEngine即可嵌入现有服务。项目地址https://github.com/nexorin9/allergy-prescription-firewall