4. 患者主索引与档案管理工程

慢病患者管理平台面对的是多机构、多系统、多时间点的数据汇聚场景:基层卫生院、体检中心、专科门诊、住院系统、可穿戴设备各自产生患者记录,同一名患者在不同系统中可能拥有不同的就诊号、身份证号缺失、姓名同音不同字、手机号更换等情况。如果平台不能把这些记录准确归并到同一个人身上,后续的随访提醒、用药管理、指标趋势分析都会失去意义。本节围绕患者主索引(EMPI)、多源数据合并、档案动态更新、隐私脱敏、版本管理与审计日志六个工程要点展开。

患者唯一标识:EMPI 的生成与维护

EMPI 的核心是给每个自然人分配一个平台内唯一、终身不变的主索引号(MPI ID),并维护它与各业务系统本地标识的映射关系。工程上通常采用“主索引号 + 交叉索引表”的结构:主索引号由平台统一生成,建议使用带校验位的规则,例如 MPI + 12位序列 + 1位校验,避免纯自增 ID 暴露患者规模。交叉索引表记录 mpi_id、source_system、local_patient_id、match_score、link_status 等字段,其中 link_status 可取 active、merged、unlinked 三种状态。

需要特别注意的是,EMPI 不是一次性建成的静态表,而是一个持续演化的关系网络。当两条记录被判定为同一患者时,不是简单删除旧记录,而是把旧 MPI ID 标记为 merged 并指向新 MPI ID,保留可追溯的合并链。这样即使后续发现误合并,也能通过反向操作恢复。

多源数据合并:匹配策略与冲突处理

多源合并的关键在于匹配算法。工程上常用“确定性匹配 + 概率匹配”两级策略。确定性匹配依赖强标识字段,如身份证号、医保卡号、院内就诊号;概率匹配则对姓名、性别、出生日期、手机号、地址等字段加权打分。一个可参考的权重示例如下:身份证号完全一致得 40 分,姓名完全一致得 20 分,出生日期一致得 15 分,手机号一致得 15 分,性别一致得 5 分,地址相似得 5 分。总分达到 85 分以上自动合并,60~85 分进入人工复核队列,低于 60 分视为不同患者。

合并过程中必然遇到字段冲突,例如两个系统记录的出生日期相差一天、姓名一个为“张伟”一个为“张玮”。此时应遵循“权威源优先 + 时间最近优先”的原则:身份证、出生日期以公安或医保权威源为准;联系方式、地址以最近一次更新时间较新的记录为准。冲突字段不能直接覆盖,而应写入 field_conflict 表,保留原值、新值、来源系统和处理方式,供后续审计。

多源患者数据合并与主索引生成流程 基层卫生院 就诊号 / 姓名 / 身份证 专科门诊系统 门诊号 / 手机号 / 地址 住院系统 住院号 / 出生日期 / 性别 可穿戴设备 设备ID / 血压 / 血糖 匹配引擎 确定性匹配:身份证/医保卡 概率匹配:姓名+生日+手机 加权评分 → 阈值判定 ≥85 自动合并 | 60~85 复核 自动合并 生成/复用 MPI ID 人工复核队列 核对证件 / 电话确认 判定为不同患者 各自分配新 MPI ID 患者主索引库 MPI ID(唯一主键) 交叉索引映射表 合并链 / 状态标记 字段冲突记录 合并后档案动态更新与治理要点 字段冲突:权威源优先(身份证/出生日期),联系方式取最近更新时间 版本管理:每次变更生成新版本号,保留旧版本快照,支持回溯 隐私脱敏:展示层对身份证、手机号、地址做掩码,审计日志记录访问者 审计日志:记录谁、何时、对哪个 MPI ID 执行了合并/修改/查看操作

档案动态更新:从增量采集到版本快照

患者档案不是静态文档,而是随每次就诊、随访、设备上传不断变化的动态集合。工程实现上,建议采用“事件驱动 + 版本快照”的方式:每次数据变更先写入变更事件表,记录 mpi_id、change_type、field_name、old_value、new_value、source_system、operator、change_time,再由异步任务将变更应用到档案主表,并生成新的版本号。版本号可采用 V + 年月日 + 序号 的格式,例如 V20250612003 表示 2025 年 6 月 12 日的第 3 次变更。

这样设计的好处是:任何时刻都能回答“这个患者的血压值是什么时候、由谁、从哪个系统改过来的”,也能在发现数据错误时快速回滚到指定版本。对于慢病管理场景,血压、血糖、用药方案这类关键字段的变更尤其需要保留完整轨迹。

隐私脱敏与审计日志

患者档案涉及大量敏感信息,脱敏必须在展示层和接口层同时实施。常见做法是:身份证号保留前 6 位和后 4 位,中间用 * 替代;手机号保留前 3 位和后 4 位;姓名在非必要场景只显示姓氏加 *。脱敏规则应配置化,不同角色看到不同粒度,例如随访护士可看到完整手机号,数据分析人员只能看到脱敏后的统计结果。

审计日志则要覆盖“谁、何时、从哪里、对哪个患者、做了什么操作、结果如何”。建议日志表至少包含 log_id、operator_id、operator_role、mpi_id、action_type、action_detail、ip_address、result、log_time。日志本身不可修改,只允许追加,并定期归档到独立的审计存储中。对于合并、拆分、导出、批量查询等高风险操作,还应触发实时告警。

工程实践中,建议把 EMPI 匹配阈值、脱敏规则、审计保留周期都做成可配置参数,而不是硬编码在代码里。不同地区对隐私合规的要求不同,配置化能让平台更快适配监管变化。

一个可参考的合并判定参数表

匹配字段 权重分值 匹配方式 说明
身份证号 40 完全一致 强标识,缺失时该字段不计分
姓名 20 完全一致 / 同音字 同音字按 12 分计
出生日期 15 完全一致 相差 1 天按 8 分计
手机号 15 完全一致 空号或缺失不计分
性别 5 完全一致 辅助字段
地址 5 相似度 ≥ 80% 按行政区划逐级比对

总分 ≥ 85 分自动合并;60~85 分进入人工复核;< 60 分判定为不同患者。该表为示例参数,实际部署时应结合本地数据质量做校准,例如某地区身份证缺失率较高,就需要适当提高姓名和出生日期的权重。

版本管理与审计的协同

版本管理和审计日志是两套互补机制:版本管理回答“档案曾经是什么样”,审计日志回答“谁在什么时候动了它”。两者通过 mpi_id 和 version_no 关联。当监管或内部质控需要追溯某次数据异常时,可以先从审计日志定位操作记录,再通过版本号调取当时的档案快照,形成完整证据链。对于慢病患者管理平台而言,这不仅是合规要求,也是保障随访连续性和用药安全的基础能力。

合并操作不可逆地删除旧 MPI ID 是常见设计错误。正确做法是保留旧 ID 并标记为 merged,指向新 ID,同时记录合并时间、操作人和合并依据。这样在发现误合并时,才能通过拆分操作恢复原始记录。