企业官网建设流程全解析

简介：这份《智慧医院集成平台建设方案》PPT面向医院信息科、医疗信息化厂商方案人员及医疗IT项目售前工程师，针对系统不断增多、信息孤岛、标准不统一、接口无法监管等痛点，给出从服务总线、统一数据中心到平台应用的一体化解决思路。方案围绕HL7引擎、数据转换、流程整合与服务整合展开，覆盖门诊、药事、医技、财务、人力等业务系统的接入，并以电子病历、临床数据中心、运营数据仓库支撑病人信息集成视图、病历综合浏览器、闭环信息展示及BI决策支持，同时梳理了数据元、值域代码、数据集与53个CDA共享文档模板等标准规范。资源压缩包3.58MB，内含1个pptx文件，以架构图与分层框架为主，便于直接引用或二次改写。目前已有209人学习，适合作为方案汇报、立项材料与集成平台规划的参考底稿。

1. 从22家异构系统到一张集成网：智慧医院集成平台到底在解决什么

一个在信息科干过几年的人，大概率都经历过这种场面：门诊挂号在 HIS，检验报告在 LIS，影像在 PACS，手术排班在手麻系统，医生想看一份完整的诊疗记录，得同时在四五个客户端之间来回切。智慧医院集成平台要解决的就是这件事——它不是再往医院里塞一套新业务系统，而是把已经存在的二十多家异构系统用服务总线横向拉通，把散落在各处的数据沉淀进统一数据中心，再通过门户和应用层把整合后的结果呈现给临床、运营和患者。服务总线负责消息路由和协议适配，数据中心负责标准化与主索引，平台应用负责闭环展示与决策支持。适合读这篇的人：医院信息科负责接口和集成的工程师、医疗信息化厂商做接口开发的同学、集成平台实施顾问，以及正在准备互联互通测评和等级评审的技术负责人。

2. 七层架构拆分与服务总线选型：中间表、视图那一套为什么撑不住

把一个省级三甲医院的集成平台拆开看，本质上是七层架构加两条纵向体系。搞不清楚每层职责边界，后面接口对接、数据落地、性能调优全都会乱。

2.1 七层架构的职责边界与数据流向

从下往上数：信息基础层是软硬件、存储和网络设备，也就是机房和虚拟化那一层；医院业务层是 HIS、CIS、EMR、LIS、PACS、手术麻醉这些产生业务数据的系统；集成交换层是真正的核心，包含消息传输、HL7 引擎、数据转换、流程整合、服务整合和监控管理；平台资源层存放基础信息库、业务信息库、交换信息库、临床文档、数据仓库和术语字典；平台服务层对外暴露病人索引服务、电子病历档案服务、全院业务协同支撑服务、病人集成视图、BI 决策支持、等级评审服务和绩效考核；再往上是平台应用层和平台门户层。两条纵向体系分别是信息标准体系和信息安全体系，贯穿所有层。

数据流向是单向下沉再向上服务：业务层产生消息，集成交换层做协议转换和路由，资源层做标准化存储，服务层封装成可复用接口，应用层和门户层消费。理解这条链路之后你会发现，任何一次接口开发，实际都是在集成交换层加一段路由和转换规则，而不是去动业务系统的库表。

2.2 中间表、视图、存储过程的老路为什么走不通

先说结论：不是这些技术不能用，而是它们在多系统、多厂商、频繁升级的环境下会把耦合度推到不可维护的程度。

传统方式最大的问题是「系统升级成本高、风险大」。某家 LIS 厂商把检验结果表加了一列或者改了字段类型，所有读中间表和视图的下游系统全得跟着改，出了问题还很难定位是谁的锅。服务总线的思路是把接口从「库表级」抬到「服务级」：对方只需要发布一个服务，谁要谁订阅，新系统接入时直接调用现成的服务，一次改造多方利用。

2.3 服务总线的消息流转与 HL7 引擎

服务总线内部跑的核心是 HL7 引擎。HIS 开一张检验申请单，发的是 ORM^O01；LIS 回一份结果，发的是 ORU^R01；病人基本信息同步通常是 ADT^A04 或者 ADT^A08。消息以 ER7 编码的段结构在总线里流转，引擎负责解析、字段映射、版本转换，再按路由规则分发给下游。

常见做法是用声明式的路由配置来描述一条消息的去向，而不是把逻辑写死在代码里。下面是一段检验报告推送的路由示意：

# 服务总线路由规则示意：LIS 检验报告推送 route: name: lis-report-push # 路由唯一标识，用于运行监控和消息跟踪 source: system: LIS # 消息来源系统 protocol: hl7v2 # 接入协议，可选 hl7v2 / http / mq trigger: ORU^R01 # 触发消息类型 transform: - map: hl7v2_to_xml # 第一步：ER7 转 XML version: 2.5.1 # HL7 版本，需与来源系统一致 - mapping_table: term_dict_obs_code # 第二步：用术语字典做检验项目编码对照 targets: # 一个消息可以分发到多个下游 - system: EMR protocol: http service: reportCallback # 同步回调，要求 EMR 提供 HTTP 接口 - system: 掌上医院 protocol: mq topic: patient.report.ready # 异步消息，患者端自行消费 policies: retry: 3 # 失败重试次数 timeout: 5000 # 单次调用超时，单位毫秒 dlq: lis-report-dlq # 死信队列，超过重试次数进这里人工排查

这份配置里有三个关键点值得单独说。trigger决定了引擎在什么消息类型上触发这条路由，写错会导致消息进不了流程；mapping_table指向术语字典里的对照关系，检验项目在两套系统里的编码往往不一致，不做映射下游会解析失败；dlq是排查问题的最后一道防线，没有死信队列的话，一条失败消息要么被静默丢弃，要么无限重试拖垮总线。版本映射工具负责处理 HL7 各版本之间的差异，比如 2.3 和 2.5.1 在某些段的字段位置上不一致，靠人工改字段迟早出错。

3. HL7 接入与 CDR 建模：接口梳理、标准映射、主索引怎么落地

总线配置写得再漂亮，接口梳理没做清楚一样落地不了。接入一个系统的顺序，我一般按下面四步走。

3.1 接入顺序：先梳理业务接口，再画交互图

交互图是这一步的核心产出。举个检验检查的例子：医生站开申请单，平台接单后分发到 LIS 和 PACS，检查完成后状态实时回写，报告结果推送回 EMR 并同步给掌上医院，危急值单独触发提醒。这张图一旦画清楚，接口数量、消息类型、失败重试点全都出来了。流程优化往往能砍掉近三成的往返消息，这也是服务总线除了「接线」之外更值钱的地方。

3.2 HL7 V2 消息解析与字段取值

解析 ER7 消息是所有映射工作的基础。段与段之间用回车分隔，字段之间用竖线分隔，组件之间用脱字符分隔。用 Python 快速拆一段看看：

def parse_er7(raw: str): """把 ER7 编码的 HL7 消息拆成 {段名: [字段列表]} 结构""" segments = {} for line in raw.strip().split("\r"): fields = line.split("|") # 竖线分隔字段 seg_name = fields[0] # 第一段是段名，如 MSH / PID / OBX segments.setdefault(seg_name, []).append(fields) return segments msg = parse_er7( "MSH|^~\\&|LIS|HOSP|EMR|HOSP|20240115103000||ORU^R01|MSG0001|P|2.5.1\r" "PID|1||P000123||张三||19800101|M\r" "OBX|1|ST|GLU^血糖||5.6|mmol/L|3.9-6.1|N|||F" ) pid = msg["PID"][0] obx = msg["OBX"][0] print("患者主索引:", pid[3]) # PID-3 是病人 ID，映射到 EMPI print("检验项目:", obx[3]) # OBX-3 是项目编码，需做术语映射 print("结果值:", obx[5]) # OBX-5 是结果值

这段代码的取值位置都是按 HL7 V2.5.1 的字段序号来的：PID-3存病人标识，接进平台后必须和 EMPI 病人主索引做对照，不能直接用业务系统的主键；OBX-3里的GLU^血糖是编码加名称的组合，组件分隔符是脱字符，做术语字典映射时要先按组件拆开再比对编码。实际项目里不会自己手写解析器，而是用现成的 HL7 引擎，但理解字段位置是排查「消息收进来了但数据是空的」这类问题的前提。

3.3 数据中心三库建模与 EMPI 主索引

数据中心由三块组成：标准基础信息库、临床信息库（CDR）和运营数据仓库。标准基础信息库里放的是主索引和术语对照，包括病人主索引、科室主索引、员工主索引、疾病诊断主索引；CDR 是临床数据的标准化沉淀，为科研分析和临床决策支持供数；运营数据仓库支撑决策支持、绩效考核和等级评审。

主索引是整套数据中心的锚点。没有 EMPI，同一个病人在门诊系统和住院系统里会是两条记录，集成视图就拼不出完整时间轴。匹配逻辑通常按身份证、姓名加出生日期、医保卡号做多级比对，下面是一个简化示意：

def match_empi(patient, index_pool): """三级匹配：身份证精确 -> 姓名+生日 -> 医保卡号""" for p in index_pool: if patient["id_card"] and patient["id_card"] == p["id_card"]: return p["empi_id"] # 一级：身份证精确命中 for p in index_pool: if patient["name"] == p["name"] and patient["birthday"] == p["birthday"]: return p["empi_id"] # 二级：姓名加生日 for p in index_pool: if patient["insurance_no"] and patient["insurance_no"] == p["insurance_no"]: return p["empi_id"] # 三级：医保卡号兜底 return None # 未命中则新建主索引

三级匹配的顺序不能乱，身份证优先级最高，因为唯一性最强；姓名加生日做二级是因为同名同姓在门诊量大的医院很常见，必须叠加出生日期；医保卡号做兜底覆盖没有身份证的自费患者。未命中时新建主索引并记录来源系统，方便后续人工合并。

4. 消息全过程跟踪与性能统计：日15-20万条消息怎么可视可控

服务总线一旦跑起来，每天 15 到 20 万条消息是常态。这个量级靠人工查日志根本不现实，必须让每条消息有唯一标识、有落库记录、有可视化统计。

4.1 服务生命周期管理与运行监测

服务不是发布完就不管了。服务生命周期管理至少要覆盖发布、启用、变更、下线和授权五个状态。运行监测关注的是实时吞吐、平均响应时间、失败率和积压队列深度。授权管理决定哪个系统能调哪个服务，避免越权订阅；服务体检是周期性校验服务的可用性和响应质量，提前发现那些「平时正常、高峰期超时」的服务。

一个容易被忽略的点是服务变更的向后兼容。某家厂商把服务返回的字段名从patientId改成empiId，如果下游没同步升级，消息就会解析失败。常见做法是服务版本号跟随接口路径，/report/v1和/report/v2并存一段时间，给下游留升级窗口。

4.2 消息跟踪的埋点与日志表设计

消息全过程跟踪的前提是每条消息都有一个贯穿全链路的唯一 ID。这个 ID 在总线入口生成，写进消息头，后续每一次转换、每一次分发都带着它，最后落到消息跟踪表里。

-- 消息跟踪主表：一条消息在总线上的一次流转 CREATE TABLE msg_trace ( trace_id VARCHAR(64) PRIMARY KEY, -- 全链路唯一 ID，入口生成 msg_type VARCHAR(32), -- HL7 消息类型，如 ORU^R01 source_system VARCHAR(32), -- 来源系统 target_system VARCHAR(32), -- 目标系统 status TINYINT, -- 0 处理中 1 成功 2 失败 3 进死信 retry_count INT DEFAULT 0, -- 已重试次数 err_code VARCHAR(16), -- 失败错误码，便于分类统计 created_at DATETIME, -- 消息进入总线时间 finished_at DATETIME, -- 处理完成时间 INDEX idx_created (created_at), INDEX idx_status (status, created_at) ); -- 查最近一小时内失败的消息，按来源系统聚合 SELECT source_system, err_code, COUNT(*) AS fail_cnt FROM msg_trace WHERE status = 2 AND created_at > DATE_SUB(NOW(), INTERVAL 1 HOUR) GROUP BY source_system, err_code ORDER BY fail_cnt DESC;

trace_id是全链路排查的钥匙，哪条消息在哪个环节出错，一条 SQL 就能定位。err_code分类很重要，否则每天上千条失败记录看下来毫无头绪——真正需要立刻处理的往往只有「连接超时」和「映射失败」两类，前者多半是对端服务挂了，后者是术语字典缺项。status里专门留了「进死信」这一档，重试耗尽的消息不会被丢掉，运维可以按时间窗口捞出来重放。

4.3 性能统计与容量估算

性能统计报告至少要给出四个维度的数据，下面这张表可以当作验收时的检查项：

容量估算按日 20 万条算，峰值通常集中在上午 8 点到 10 点，占总量的三成左右，换算下来峰值 TPS 大概在 17 到 20 之间，考虑到重试和补发，总线处理能力设计到 30 TPS 比较稳妥。存储方面，一条消息的跟踪记录加原始报文，按 2KB 估算，日增约 400MB，一年下来需要预留一个 TB 级别的空间，历史数据按季度归档到冷存储。

5. 集成视图与闭环展示的进阶做法：从 CDR 时间轴到质控指标

数据和消息都跑通了，最后一步是把它们变成临床和运营真正愿意看的东西。病人信息集成视图是集成平台里使用频率最高的应用，核心是一张按时间轴排列的诊疗事件流，把门诊、住院、检验、检查、用药、手术麻醉各个节点串起来。

时间轴的数据来源是 CDR，查询时按 EMPI 主索引拉取，再按事件时间排序。常见做法是用一张宽表缓存常用字段，避免每次打开视图都去扫全量临床文档：

-- 按 EMPI 拉取患者事件时间轴 SELECT event_time, event_type, dept_name, summary FROM cdr_patient_timeline WHERE empi_id = 'EMP00012345' ORDER BY event_time DESC LIMIT 200;

event_type用来区分事件类别，前端据此渲染不同图标和跳转入口；summary是预生成的摘要文本，不要把原始报告全文塞进来，否则视图首屏加载会明显变慢。LIMIT不是可选项，一个老病号十几年积累的事件可能上万条，必须分页。

闭环信息展示比时间轴更进一步。它要求一个业务动作从起点到终点全程可见，比如检验闭环：开单、缴费、采样、上机、审核、报告推送、临床签收，每个节点都要有状态回写。判断闭环是否真正落地，看的是有没有断点——采样了但缴费状态没同步，报告推送了但临床没签收，这些断点会在质控指标里暴露出来。三级医院质量控制系统、院感管理、病案质控这些应用，本质上都是在消费闭环数据。

一个实操技巧：先用闭环状态表把断点跑一遍，再去做可视化。断点没清干净就上大屏，展示出来的数据反而会误导管理决策。

-- 检验闭环断点扫描：已出报告但临床未签收，超过 24 小时 SELECT r.report_no, r.dept_name, r.finished_at FROM lab_report r LEFT JOIN lab_ack a ON r.report_no = a.report_no WHERE a.report_no IS NULL AND r.finished_at < DATE_SUB(NOW(), INTERVAL 24 HOUR);

这条查询返回的记录就是需要临床跟进的待签收报告，可以做成工作台提醒推给对应科室。finished_at取报告审核完成时间而不是采样时间，因为真正该催的是审核之后没人看的报告。把这类断点查询固化成定时任务，配合前面的消息跟踪表一起看，集成平台才算从「能通」走到「可控」。

本文还有配套的精品资源，点击获取