📚 课程目录第4章患者主索引与就诊结算账户

4. 患者主索引与就诊结算账户

在医院收费与结算系统中，患者主索引（EMPI，Enterprise Master Patient Index）与就诊结算账户是两条相互支撑的主线：前者解决“这个人是谁”，后者解决“这次就诊的钱怎么算”。如果患者唯一标识不稳定，账户就会挂错人；如果账户与就诊的关系设计不清，预交金、退费、欠费和医保结算就会互相污染。本节围绕患者唯一标识、就诊登记、账户建立、预交金与账户关系设计展开，重点说明数据模型与关键判断。

一、患者唯一标识：EMPI 的生成与合并

患者唯一标识不是身份证号本身，而是系统内部为每个自然人分配的一个稳定主键，通常称为患者主索引号（PatientID）。身份证号、姓名、性别、出生日期、手机号属于身份特征，用于匹配和去重；PatientID 才是账户、就诊、病历、检验检查结果长期引用的锚点。设计上建议采用与业务无关的代理键，例如“P + 12 位序列”或 UUID，避免因身份证升位、港澳台证件、外籍护照等导致主键变化。

EMPI 的核心操作是匹配与合并。当患者首次登记时，系统按身份特征计算匹配度：身份证号完全一致视为强匹配；姓名+出生日期+手机号一致视为中匹配；仅姓名相似视为弱匹配。强匹配可直接复用已有 PatientID；中匹配进入人工确认队列；弱匹配不得自动合并，防止把同名患者合并成同一人。合并时保留一个主 PatientID，将被合并的 PatientID 标记为“已合并”，并记录合并指向关系，历史就诊和账户全部迁移到主索引下，保证旧数据仍可追溯。

合并患者是不可逆的高风险操作。合并前必须核对证件原件或至少两项强特征，合并后要保留操作人、时间、原 ID 与目标 ID 的审计记录，不能物理删除被合并记录。

二、就诊登记：一次就诊的标识与状态

就诊（Visit/Encounter）是患者与医院发生一次医疗服务的实例。就诊登记产生就诊号（VisitID），并记录就诊类型（门诊、急诊、住院、体检）、科室、医生、时间、医保类型等。一个 PatientID 可以对应多次就诊，一次就诊只属于一个 PatientID。就诊状态通常包括：登记、挂号、就诊中、待结算、已结算、作废。状态流转决定了账户能否发生预交金和费用记账。

就诊登记时还要确定“结算主体”：自费、医保、工伤、商保或第三方。结算主体不同，账户的记账规则和预交金要求也不同。例如门诊自费通常先挂号后付费，住院则一般要求先建立账户并缴纳预交金。就诊号建议按“日期+院区+科室+序列”生成，便于人工识别和分库分表。

三、账户建立：账户与就诊的关系设计

账户（Account）是资金与费用的归集容器。关键设计问题是：账户挂在患者上，还是挂在就诊上？推荐采用“患者账户 + 就诊子账户”的两级模型。患者账户（PatientAccount）以 PatientID 为唯一标识，记录预交金总余额、可用余额、冻结金额；就诊子账户（VisitAccount）以 VisitID 为标识，记录本次就诊的预交金、已发生费用、已结算金额、欠费金额。这样既能支持跨就诊的预交金余额共享，又能按就诊独立核算，避免一次住院的费用影响门诊账户。

账户建立时机应与就诊登记联动：门诊挂号时自动创建就诊子账户；住院登记时创建就诊子账户并要求缴纳预交金。账户状态包括：正常、冻结、销户。冻结用于医保审核、欠费追缴或司法冻结场景，冻结期间只能收款不能退费。

四、预交金与账户关系设计

预交金是患者预先存入账户的资金，用于抵扣后续医疗费用。设计上要区分“充值”和“记账”两个动作：充值增加患者账户可用余额，同时生成预交金流水；记账在就诊子账户上产生费用，并从患者账户可用余额中扣减。若患者账户余额不足，则形成欠费，就诊状态进入“待结算”或“欠费”状态。

预交金与账户的关系可以用三个约束来固化：第一，患者账户可用余额 = 总余额 − 冻结金额；第二，就诊子账户已用预交金 ≤ 患者账户可用余额；第三，任何退费金额不得超过对应就诊子账户的已用预交金。这样设计后，门诊和住院可以共享同一患者账户的预交金，但每笔费用仍能追溯到具体就诊。

下面给出一个简化的账户与预交金数据表结构示例，便于落地实现：

-- 患者主索引
CREATE TABLE patient_master (
  patient_id      VARCHAR(20) PRIMARY KEY,
  name            VARCHAR(50) NOT NULL,
  id_card         VARCHAR(30),
  phone           VARCHAR(20),
  merged_to       VARCHAR(20),   -- 被合并指向的主ID
  status          VARCHAR(10) DEFAULT 'ACTIVE'
);

-- 患者账户
CREATE TABLE patient_account (
  account_id      VARCHAR(20) PRIMARY KEY,
  patient_id      VARCHAR(20) NOT NULL,
  total_balance   DECIMAL(12,2) DEFAULT 0,
  frozen_amount   DECIMAL(12,2) DEFAULT 0,
  status          VARCHAR(10) DEFAULT 'NORMAL'
);

-- 就诊
CREATE TABLE visit (
  visit_id        VARCHAR(24) PRIMARY KEY,
  patient_id      VARCHAR(20) NOT NULL,
  visit_type      VARCHAR(10),   -- OUTPATIENT/INPATIENT
  dept_code       VARCHAR(10),
  doctor_code     VARCHAR(10),
  visit_status    VARCHAR(12),   -- REGISTERED/IN_TREAT/SETTLED/VOID
  settle_type     VARCHAR(10)    -- SELF/INSURANCE/WORK_INJURY
);

-- 就诊子账户
CREATE TABLE visit_account (
  visit_account_id VARCHAR(24) PRIMARY KEY,
  visit_id         VARCHAR(24) NOT NULL,
  prepaid_amount   DECIMAL(12,2) DEFAULT 0,
  used_amount      DECIMAL(12,2) DEFAULT 0,
  debt_amount      DECIMAL(12,2) DEFAULT 0
);

-- 预交金流水
CREATE TABLE prepay_flow (
  flow_id         VARCHAR(24) PRIMARY KEY,
  account_id      VARCHAR(20) NOT NULL,
  visit_id        VARCHAR(24),
  flow_type       VARCHAR(10),   -- RECHARGE/REFUND/FREEZE
  amount          DECIMAL(12,2),
  pay_channel     VARCHAR(20),
  operator        VARCHAR(20),
  create_time     DATETIME
);

五、典型场景与判断依据

场景一：门诊患者先充值 500 元，随后发生检查费 320 元。系统在患者账户增加 500 元可用余额，就诊子账户记录预交金 500 元；记账时从患者账户扣减 320 元，就诊子账户已用金额变为 320 元，剩余可用 180 元。判断依据是患者账户可用余额与就诊子账户已用金额同步更新，且预交金流水有两条记录。

场景二：住院患者预交金 3000 元，住院期间费用 4200 元。出院结算时，就诊子账户已用预交金 3000 元，欠费 1200 元。系统应允许补缴 1200 元后再结算，或按医保结算规则由医保支付部分、患者自付部分分别记账。判断依据是欠费金额是否清零、结算主体是否匹配。

场景三：患者合并。若发现同一患者存在两个 PatientID，合并后原就诊和账户全部迁移到主 PatientID，原账户余额累加到主账户，原就诊子账户保留原 VisitID 但归属主患者。判断依据是合并后总余额不变、就诊数量不变、审计记录完整。

建议在账户表上增加“最后变动时间”和“版本号”字段，用于并发控制。当两名收费员同时对同一账户充值或退费时，通过版本号乐观锁避免余额覆盖。

综上，患者主索引解决身份唯一性，就诊登记解决服务实例，账户解决资金归集，预交金解决支付前置。四者关系一旦确定，后续的收费、退费、医保结算、欠费追缴和财务报表才能在同一套数据基础上稳定运行。