2. 医疗信息系统架构与数据流

医院里最常被同时提及的三套系统是 HIS、LIS 和 RIS。它们并不是三个彼此独立的“信息孤岛”,而是围绕同一位患者、同一次就诊、同一份医嘱展开协作的三条业务主线。理解接口集成,第一步不是看消息格式,而是先看清每条主线自己怎么走、在哪些点上必须互相调用、调用时谁提供数据、谁消费数据、失败时谁受影响。

三条主线各自的业务闭环

HIS 主线覆盖门诊、住院、收费与医嘱。门诊侧从挂号开始,产生患者主索引与就诊号,医生开立处方或检查申请,收费处根据医嘱计费,药房或执行科室再确认执行;住院侧从入院登记开始,医生下达长期/临时医嘱,护士站校对并执行,费用通过医嘱自动记账。HIS 的核心对象是患者、就诊、医嘱、费用,它掌握“谁、在什么就诊里、被开了什么、花了多少钱”。

LIS 主线围绕标本与检验报告。医生在 HIS 开出检验医嘱后,护士执行时生成标本条码,标本采集、运送、签收、上机、审核,最终形成检验报告并回传。LIS 的核心对象是标本、检验项目、结果、报告,它关心的是“这份标本对应哪条医嘱、结果是否危急、报告是否已发布”。

RIS 主线围绕检查登记与影像报告。检查申请同样来自 HIS 医嘱,患者到放射科登记后生成检查号,技师执行检查产生影像,医生阅片出具报告,报告回传 HIS 供临床查看。RIS 的核心对象是检查申请、登记、影像、诊断报告。

三条主线的共同起点都是 HIS 的医嘱,共同终点都是“结果回到临床”。这就是接口集成的本质:HIS 是业务发起方与费用归属方,LIS/RIS 是执行方与结果生产方。

关键调用关系与数据依赖

把三条主线放在一起看,真正需要接口打通的关键点并不多,但每一个都不可省略:

  • 患者与就诊同步:HIS 向 LIS/RIS 提供患者基本信息、就诊号、病区床位。若患者主索引不一致,后续标本和报告都会挂错人。
  • 医嘱/申请下传:HIS 把检验、检查医嘱以申请单形式下传,包含项目代码、优先级(普通/急诊)、临床诊断、申请科室与医生。
  • 标本/登记状态回传:LIS 把标本签收、拒收状态回传 HIS;RIS 把登记、已检查状态回传,让护士站和医生知道进度。
  • 报告回传与危急值:LIS/RIS 审核后的报告回传 HIS,危急值还需额外触发提醒,不能只等医生主动查看。
  • 费用与计费确认:执行科室确认执行后,HIS 完成计费或退费,这是业务闭环的最后一环。

下面这张图把三条主线与它们之间的关键调用关系画在一起,重点看箭头方向:申请向下走,状态和报告向上回。

HIS / LIS / RIS 三条主线与关键调用关系 HIS 主线:患者 / 就诊 / 医嘱 / 费用 门诊挂号 住院登记 医生开立 检验/检查医嘱 护士校对 执行确认 收费/记账 费用归属 临床查看结果 (报告/危急值) 申请下传 申请下传 LIS 主线:标本 / 检验 / 报告 标本条码 采集/运送 签收/上机 检验执行 审核发布 检验报告 危急值识别与提醒 RIS 主线:登记 / 检查 / 报告 检查登记 生成检查号 技师执行 影像采集 阅片审核 诊断报告 影像与报告关联存储 状态/报告回传 状态/报告回传 HIS 接收:标本/检查状态、检验/检查报告、危急值 报告挂接到就诊号与医嘱号,供临床与费用闭环使用 关键依赖:患者主索引一致 · 医嘱号唯一 · 状态可追溯 · 报告可回挂

接口集成中最容易出问题的四个衔接点

从工程实践看,三条主线之间的调用失败,绝大多数集中在四个衔接点,而不是系统内部逻辑。

第一,患者主索引不一致。HIS 用住院号或门诊号作为主键,LIS/RIS 若用标本号或检查号自行关联,一旦患者换就诊、改名或合并档案,报告就可能挂到错误的人身上。正确做法是:HIS 下传时同时给出患者唯一标识 + 就诊号 + 医嘱号,LIS/RIS 回传报告时必须原样带回这三个字段,不能只回传自己的内部号。

第二,医嘱号与申请单号映射断裂。HIS 的医嘱号、LIS 的申请单号、RIS 的检查号是三个不同体系的编号。集成时必须建立映射表,例如 HIS 医嘱号 ORD20240512001 对应 LIS 申请单 LAB20240512-0087,报告回传时按此映射回挂。若映射丢失,报告就成了“无主报告”。

第三,状态回传缺失导致流程卡死。护士站最关心的是“标本签收了没有、检查做了没有”。如果 LIS/RIS 只回传最终报告,不回传中间状态,护士就无法判断标本是否被拒收,医生也无法知道检查是否已执行。建议至少回传:已签收、已上机、已审核、已发布四个状态节点。

第四,危急值只入库不提醒。危急值报告回传 HIS 后,如果只是写入报告表而不触发弹窗、短信或护士站提醒,临床可能几小时后才看到。接口设计中,危急值应作为独立消息类型,带危急值标志、项目、结果、参考范围、报告时间,并记录提醒与确认时间,形成可追溯闭环。

一个可参考的接口字段约定示例

下面给出一份检验申请下传与报告回传的最小字段约定示例,字段名可按实际厂商规范调整,但语义必须完整。示例中的编号与数值均为教学假设,不代表真实系统数据。

【HIS → LIS 检验申请下传】
patientId      = P00012345        // 患者唯一标识
visitId        = V202405120078    // 就诊号
orderId        = ORD20240512001   // HIS 医嘱号
applyNo        = LAB20240512-0087 // LIS 申请单号(由 LIS 生成或 HIS 预生成)
itemCode       = CBC              // 检验项目代码
priority       = URGENT           // 普通 NORMAL / 急诊 URGENT
specimenType   = 全血
diagnosis      = 发热待查
applyDept      = 呼吸内科
applyDoctor    = 张医生

【LIS → HIS 状态与报告回传】
orderId        = ORD20240512001   // 必须原样带回
visitId        = V202405120078
status         = RECEIVED / TESTING / REVIEWED / PUBLISHED
reportTime     = 2024-05-12 10:35:00
criticalFlag   = Y                // 危急值标志
criticalItem   = WBC
resultValue    = 28.6
referenceRange = 3.5-9.5

判断接口是否真正打通,不看“消息发出去了”,而看三件事:报告能否按就诊号在 HIS 里查到、危急值能否在设定时间内被临床确认、费用能否随执行状态正确记账。这三点成立,三条主线才算形成闭环。

集成设计时建议先画“主线 + 调用点”图,再定消息字段。先明确谁发起、谁执行、谁回传、回传带哪些主键,比一开始就纠结 HL7 还是 WebService 更重要。