OpenMed No-Raw-PHI 日志策略面向本地优先医疗 AI 的日志安全边界与自动化守护【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmedOpenMed 是一个本地优先local-first的医疗 AI 开源项目核心能力是临床 NER 与 HIPAA PII 去标识化全部推理在设备端完成。当一段包含姓名、病历号、SSN、出生日期的临床文本经过 OpenMed 的清洗、实体抽取、去标识化与批量处理链路时其日志系统必须成为操作遥测而非数据复印机——这正是本文要讲解的No-Raw-PHI 日志策略。读完本文你将掌握该策略允许与禁止的日志内容边界、底层数据结构支撑、代码层实践范式以及如何运行自动化守护测试no-raw-PHI logging guard来确保每一次改动都不会把患者明文写进日志。策略总览日志是操作遥测不是数据存储No-Raw-PHI Logging Policy 是 OpenMed 的核心安全策略之一它提出了一条绝对底线OpenMed 代码不得在任何日志级别写入原始受保护健康信息PHI、患者文本、源文档或提取出的明文 span。日志仅是操作遥测。这句话包含两层含义任何日志级别不仅包括INFO/WARNING也包括DEBUG与ERROR。调试日志常因方便排查而携带文本但策略要求即便是最低级别的调试输出也一律禁止明文临床内容。日志仅是操作遥测日志存在的目的是让运维者看到系统在做什么、耗时多少、成败如何而不是让日志成为 PHI 的第二个存储副本。一旦日志中混入明文日志文件就变成了必须按 PHI 数据管理的资产泄露面随之扩大。这一策略与 No-Telemetry Guarantee 互为表里后者保证 OpenMed 不收集遥测、不向外拨号运行时默认无出站网络调用前者则保证即便在本地产生日志、追踪trace与错误报告其中也不含患者明文。二者共同支撑起患者数据永不离开你的网络这一项目承诺。允许写入日志的内容元数据与安全标识符策略并非禁止一切细节而是明确划定了五类安全日志内容数值与状态类计数counts、时长durations、阈值thresholds、模型标识符model identifiers、后端名称backend names、状态转换status transitions。例如处理了 1 个文档、耗时 2.3 秒、模型为 test-pii-model、状态从 pending 变为 done。Span 元数据标签label、起始偏移start offset、结束偏移end offset、置信度分桶confidence bucket、有效性标志validity flags。这些字段只描述哪里有什么类型的东西而不携带那个东西本身。预计算的 keyedtext_hash仅当该 span 或文档已经存在预先算好的带密钥哈希时才可写入日志。策略特别强调不要在日志语句里临时创建 ad hoc 哈希。异常类名exception class names。高层失败类别high-level failure categories。源码印证安全字段正是实体数据结构的组成部分允许清单并非空泛口号而是与 OpenMed 的实体预测数据结构一一对应。在 openmed/processing/outputs.py 中EntityPrediction数据类包含text实体明文禁止写入日志label实体标签允许如NAME、SSN、DATEconfidence置信度允许日志中通常按分桶记录start/end起止偏移允许metadata附加元数据可按需放入text_hash等安全字段也就是说OpenMed 的实体模型天然把明文与可安全记录的元数据分字段存储日志代码只需要取后四者而拒绝前者即可满足策略。从源码结构看这种字段分离正是策略可落地的设计前提。源码印证text_hash是预先计算的安全标识符预先计算的 keyedtext_hash在代码中确实存在而非日志语句临时拼凑。在 openmed/clinical/coref/mentions.py 中mention 数据结构带有text_hash字段并通过_normalize_text_hash与正则校验_SAFE_TEXT_HASH_RE保证其格式安全openmed/clinical/coref/clustering.py 在聚类时使用member.text_hash缺失时才退化为_mention_hash(hash_secret...)计算openmed/cli/main.py 则在报告输出中仅打印hash: {record.text_hash}。这些哈希允许在不同日志记录之间关联同一个 span、mention 或文档同时无法反推出原文——这正是安全标识符的含义。禁止写入日志的内容明文与可反推原语的完整清单策略对禁止项给出了非常细致的列举任何一项出现在日志中即视为违规输入文档文本、清洗后文本、截断的文本片段、提示词prompts、句子或任何可能包含临床内容的源文本表面source surfaces。注意截断片段也被禁止——截取前 N 个字符的折中方案并不安全因为片段仍可能包含足以识别患者的敏感信息。实体文本、原始 PII 值、redacted-to-original脱敏到原文映射以及替换映射负载replacement mapping payloads。去标识化系统内部必然维护原文→替代值的映射但该映射绝不能随日志流出否则去标识化形同虚设。可能包含用户输入的异常消息、源文件路径、请求体request bodies或下游库负载downstream library payloads。第三方库抛出的异常消息经常直接内嵌输入片段捕获并记录str(exc)是常见的泄密路径。从患者、病历chart、就诊encounter数据派生的文件路径或条目标识符。例如把 MRN 或就诊号拼进临时文件名再记录路径同样属于违规。工程要求四步编码守则结合策略的Engineering requirements小节在 OpenMed 中写日志时应遵守以下守则优先使用结构化字段而非格式化散文formatted prose。结构化字段如{num_entities: 3, model: x}便于检索与聚合也天然避免把文本拼进字符串。用长度、计数、标签、偏移和安全标识符替代文本。报告文档长度 1234 字符而非文档内容报告标签 NAME 的 span 位于 [45, 58)而非该 span 的明文。请求体与响应体不得进入服务日志。REST 服务日志只记录端点、状态码、耗时等绝不记录/pii/extract与/pii/deidentify收到的原文或返回的脱敏结果。当新增或修改 PII、去标识化、文本处理或批处理路径时必须运行 no-raw-PHI logging guard守护测试见下一节。自动化守护test_no_raw_text_logging.py如何把策略变成 CI 关卡策略不是建议而是由测试强制执行的工程契约。守护测试位于 tests/unit/test_no_raw_text_logging.py它模拟一条真实的 PHI 样本然后遍历多条处理与推理路径最后断言日志输出中不出现任何明文子串。测试样本覆盖七类敏感实体测试用PHI_TEXT构造了一位虚构患者并抽出七类 PHI 子串作为泄漏检测探针tests/unit/test_no_raw_text_logging.py子串标签Evelyn QuantumNAMEZQ-7391MEDICAL_RECORD_NUMBER04/17/1972DATE042-66-9001SSN919-555-0188PHONEevelyn.quantumexample.testEMAIL9 Radiant PlazaSTREET_ADDRESS_assert_no_phi_substrings把渲染后的全部日志记录拼接为字符串逐一检查这些子串是否出现一旦命中即断言失败并报告泄漏清单tests/unit/test_no_raw_text_logging.py。测试还内置了一个自检用例test_guard_detects_intentional_raw_phi_log_payload故意构造包含明文的日志行验证守护机制本身确实能报警——防止守护测试退化成永不过的摆设。被覆盖的路径从纯函数到 REST 服务核心用例test_pii_processing_and_service_paths_do_not_log_raw_phitests/unit/test_no_raw_text_logging.py以DEBUG级别捕获日志caplog.set_level(logging.DEBUG)保证最严格的级别也被检查依次走通五条关键路径TextProcessor().clean_text(PHI_TEXT)—— 文本清洗openmed/processing/text.py。extract_pii(PHI_TEXT, ...)—— 实体抽取openmed/core/pii.py。deidentify(PHI_TEXT, ...)—— 去标识化同上。BatchProcessor(...).process_texts([PHI_TEXT], ids[case-001])—— 批量处理openmed/processing/batch.py并断言successful_items 1。REST 服务端点POST /pii/extract与POST /pii/deidentify—— 通过TestClient发起真实 HTTP 请求openmed/service/app.py并断言返回200。其中 REST 测试通过monkeypatch注入_NoopLoader与假的分析/抽取/去标识化函数避免真实模型加载使守护测试可以快速、确定性地在任何 CI 环境运行同时通过monkeypatch.setenv(OPENMED_PROFILE, test)与清理相关环境变量隔离服务配置。运行守护测试的命令与策略文档一致.venv/bin/python -m pytest tests/unit/test_no_raw_text_logging.py -q发布或提交 Pull Request 前必须通过完整测试套件.venv/bin/python -m pytest tests/ -q值得一提的是同目录下的 tests/unit/test_no_telemetry.py 以静态扫描 网络面清单 自检用例的方式守护零遥测承诺与 no-raw-PHI 守护测试共同构成 OpenMed 隐私承诺的自动化防线。日志代码实践范式OpenMedLogger的示范策略在真实代码中的落地范式可以在 openmed/utils/logging.py 中直接观察到。get_logger(name)为模块提供openmed.name命名空间的 loggerOpenMedLogger封装了三个典型日志场景每个都只记录安全元数据log_model_loading(model_name, status)只记录模型名与状态started/completed/failed不记录任何输入文本。log_processing(text_length, processing_time)记录的是len文本长度与耗时而非文本内容——这正是用长度与计数替代文本守则的教科书式实现。log_predictions(num_entities, model_name)记录实体数量与模型名实体明文只存在于EntityPrediction.text字段中绝不进入日志格式串。注意log_processing位于DEBUG级别恰好在守护测试捕获的最严格级别之下从实践上证明了即便是调试日志也不写明文是完全可行的。对于需要更细粒度诊断的场景日志中应使用 span 元数据label、start/end 偏移、置信度分桶、有效性标志与预计算text_hash组合例如span labelSSN start118 end131 conf_buckethigh validtrue text_hash…。这类记录既能支撑调试与审计又不携带任何可反推原文的信息。策略的治理位置贯穿合规文档与贡献守则No-Raw-PHI 日志策略在 OpenMed 的合规体系中扮演被引用基线的角色多个治理文档直接援引它DPA 模板 与 DPIA 模板 将本文档列为数据处理协议与影响评估中关于日志处理的控制项贡献指南 要求所有涉及 PII、去标识化等路径的贡献者遵守本策略ISO-27701 控制证据 将 no-raw-PHI logging guard 与OPENMED_OFFLINE一同列为具体控制措施非洲上线指南 的验证清单要求日志、追踪、错误与审计导出中不含原始 PHIAgent 使用指南 同样规定绝不把原始 PHI 放入日志、追踪、缓存键或临时文件名。这种单一策略 多处引用的模式保证了整个仓库对日志安全边界有一致的定义任何模块的改动都必须回到同一份契约上来对齐。小结日志安全的三个可执行结论边界清晰OpenMed 日志只允许出现计数、时长、标签、偏移、置信度分桶、状态与预计算text_hash明文文本、实体原值、映射负载、异常详情与病历派生标识符一律禁止——且该边界适用于包括DEBUG在内的所有日志级别。设计支撑实体数据结构的字段分离明文与元数据分开存储与text_hash安全标识符机制使记录元数据、拒绝明文在架构上天然可行openmed/processing/outputs.py、openmed/utils/logging.py 提供了直接参考实现。CI 强制tests/unit/test_no_raw_text_logging.py以七类 PHI 子串为探针覆盖清洗、抽取、去标识化、批量处理与 REST 服务五条路径任何一次改动若引入明文日志都会让守护测试失败——配合完整测试套件pytest tests/ -q把隐私承诺变成可验证的工程事实。对于任何处理临床文本与 PII 的本地优先系统这套策略文档 字段级设计 自动化守护的组合都是一份可直接借鉴的日志安全实施方案。【免费下载链接】openmedLocal-first healthcare AI: clinical NER HIPAA PII de-identification that runs 100% on-device. 2,200 medical models, 21 languages, Apple MLX Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考