武汉市区域卫生信息平台医疗服务数据接口标准(修订版)

1、武汉市区域卫生信息平台医疗服务数据接口标准(修订版) i 武汉市区域卫生信息平台 医疗服务数据接口标准 (修订版) 武汉市卫生局 2021 年 11 月 ii 目 录 第 1 章 概述 . 1 1.1. 编写目的 . 1 1.2. 内容构成 . 1 1.3. 术语说明 . 1 第 2 章 数据采集实施方案 . 3 2.1 数据采集架构说明 . 3 2.1.1 医院端提交数据的方式 . 3 2.1.2 前置端数据反馈与处理 . 4 2.1.3 中心端数据反馈和处理 . 5 2.2 需医院配合的事项 . 5 2.2.1 应有专人配合 . 6 2.2.2 数据上传的时点 . 6 2.3 临床诊疗病史

2、数据的整合 . 8 2.4 采集数据的质控 . 10 第 3 章 接口总述 . 11 3.1 数据交换形式说明 . 11 3.1.1 全 xml 文档格式 . 11 3.1.2 全数据库中间表方式 . 11 3.1.3 xml 文档格式与数据库中间表混用方式 . 12 3.2 接口数据集概述 . 12 3.2.1 业务运营数据集 . 12 3.2.2 临床诊疗记录数据集 . 13 3.2.3 合理用药数据集 . 15 3.2.4 基础字典数据集 . 15 第 4 章 业务运营数据集 . 16 4.1 门急诊业务 . 16 4.1.1 挂号 . 16 4.1.2 诊疗收费 . 18 4.2 住院

3、类业务 . 20 4.2.1 入院登记 . 20 4.2.2 出院登记 . 21 4.2.3 在/出院结算 . 22 4.3 手术业务 . 23 4.3.1 手术记录 . 23 4.4 业务数据统计报告 . 24 4.4.1 数据表内容定义 . 25 第 5 章 临床诊疗记录数据集 . 26 5.1 患者基本信息 . 26 5.1.1 数据表内容定义 . 26 5.2 门诊就诊信息 . 32 5.2.1 数据表关系说明 . 32 5.2.2 数据表内容定义 . 32 ii 5.3 住院就诊信息 . 40 5.3.1 数据表关系说明 . 40 5.3.2 数据表内容定义 . 41 5.4 实验室

4、检验报告 . 47 5.4.1 数据表关系说明 . 47 5.4.2 数据表内容定义 . 48 5.5 医学影像检查报告 . 53 5.5.1 数据表内容定义 . 54 5.6 住院病案首页主体报告 . 59 5.6.1 数据表内容定义 . 59 5.7 出院小结报告 . 67 5.7.1 数据表内容定义 . 67 5.8 手术明细报告 . 69 5.8.1 数据表内容定义 . 69 5.9 诊断明细报告 . 70 5.9.1 数据表内容定义 . 70 第 6 章 合理用药数据集 . 73 6.1 药品明细字典 . 73 6.1.1 数据表内容定义 . 73 6.2 药品库存信息 . 74 6

5、.2.1 数据表内容定义 . 74 6.3 药品入库信息 . 74 6.3.1 数据表内容定义 . 74 6.4 药品入库明细信息 . 75 6.4.1 数据表内容定义 . 75 6.5 药品消耗信息 . 75 6.5.1 数据表内容定义 . 75 6.6 医生触警明细表 . 76 第 7 章 基础字典数据集 . 77 7.1 医院的科室字典表(tb_dic_department) . 77 7.2 医护人员字典表(tb_dic_ practitioner) . 77 7.3 明细项目字典(tb_dic_detail_item) . 78 7.4 明细项目对照字典表(tb_dic_detail

6、_comparison) . 78 7.5 标本字典表(tb_dic_specimen) . 79 7.6 检验指标字典表(tb_dic_test_indicator) . 80 7.7 检查类型字典表(tb_dic_ris_type) . 80 7.8 审查指标编码表 . 80 7.9 企业字典表 . 81 4 前 言 本文档是武汉市区域卫生信息平台医疗服务数据接口标准（试行版）第 一次修订。本接口文档与武汉市区域卫生信息平台医疗服务数据接口标准（试 行版）文档的区别如下： a、删除挂号表、诊疗收费表、出院记录表、门诊就诊记录表、住院就诊记 录表、住院病案首页主体表中保险类型字段，增加 医疗

7、费用来源类别字段，修改患 者归属地字段名 wdbz 为 hzgsd，将要求改为可选。 b、删除诊疗收费表、在/出院结算表手术材料费、摄片费、透视费、输血费、 输氧费，增加手术费、材料费、麻醉费。 c、删除手术记录表、手术明细表中日间手术标志字段及字段说明。 d、删除业务量、收入统计表中今日入院、今日出院字段。 e、删除患者信息表中患者类型字段，增加患者归属地字段。增加字段说明 人的性别代码表、婚姻状况代码表、民族代码表。 f、修改门诊收费明细表、住院收费明细表中收费明细 id 字段长度 32 为 64。 修改明细费用类别字段说明。 g、删除门诊处方明细表、住院医嘱明细表中用药方法字段。 h、删

8、除住院病案首页主体表出院方式字段，将离院方式字段选填改为必填。 i、修改药品分类字段说明为按照药品药理类别分类。 j、添加企业字典表中的字段要求。 k、修改出院小结表中的年龄字段长度 10 为 16。 该接口标准自实施之日起代替武汉市区域卫生信息平台医疗服务数据接口 标准。 本标准由武汉市卫生局信息办提出。 本标准由武汉市卫生局批准。 1 第 第 1 章 概述 1.1. 编写目的 本接口文档是武汉市区域卫生信息平台的医疗服务数据接口标准说明文档。 编制此文档的目的主要是为武汉全市联网医疗机构能更便捷地实现信息共享、更 好地控制采集数据质量，为建立覆盖武汉全市医疗卫生单位的区域卫生信息提供 基础

9、规范保障。各个试点单位，在对于医疗机构的诊疗服务部分的业务数据进行 采集时应按照此文档执行。 1.2. 内容构成 本接口文档主要包括以下内容： l 数据采集实施方案 a) 数据采集架构说明 b) 需医院配合的事项 c) 临床诊疗病史数据的整合 d) 采集数据的质控 l 接口总述 l 业务运营数据集 l 临床诊疗记录数据集 l 合理用药数据集 l 基础字典数据集 1.3. 术语说明 门诊类业务指：普通门诊、急诊、急诊观察，基本.医疗保险界定的专 科门诊，专家门诊。住院类业务指：普通住院、特需住院、留院观察，基本. 医疗保险界定的家庭病床。 2 医院被认为均具有 his、cis、lis、ris 等

10、信息管理系统，为此，要求医院对 数据的填报采取由信息系统自动汇集产生的方式运作。医院的 his 是指实现医院 内门诊、住院的诊疗从挂号、登记、配药、收费结算等业务流程的信息系统。医 院的 cis 是指医院内的医生工作站、护士工作站信息系统。医院的 lis 是指实现 医院内实验室检验从电子申请单到报告业务流程处理的信息系统。ris 是指实现 医院内医学影像检查从电子申请单到报告业务流程处理的信息系统。 就诊患者的身份电子标识卡有： （1）中华人民共和国.保障卡（以下简称"社保卡'）。即武汉市政府或外 地医保人员持有符合国家人保部标准规范的.保障卡。包括中小学生学籍卡等 对各种类

11、型人员分别发放的.保障 ic 卡。 （2）武汉地区使用的医保磁卡（以下简称"医保卡'，卡面码 10 位，卡内码 20 位）。 （3）统一自费卡：按全区域规范化格式统一编号，所以可作为患者跨区域 跨联网医院就诊时通用。 （4）医院内部自费卡：指各联网医院自行编号的，不符合全区域统一规格 编号的自费就诊卡或新农合卡。 3 第 第 2 章 数据采集实施方案 2.1 数据采集架构说明 2.1.1 医院端提交数据的方式 医院提交以及中心采集的数据流如下图所示： 图 2-1：医院端提交数据方式 在具备运作条件的前提下，医院提交数据的方式为定时批量式的。定时批 量式提交采集数据将包含除部分

12、字典数据外的其他全部采集内容。 定时批量式地提交采集数据，要求医院内部信息系统自动生成数据并定时 批量提交到前置机中约定的发送文件缓存区的相应数据表中。特别需要说明的 是：医院内部信息系统在编制提交采集数据的程序逻辑时，不要将提交采集数据 的操作逻辑嵌入到医院内日常医疗业务流程中，即不要将提交采集数据成功与否 作为日常医疗业务流程是否可继续流转的必要条件。而作为一个单独的处理程序 逻辑予以定时单独运作。 在部署前置机时会建立数据库管理系统，并预先创建各数据表的表结构。 4 这些预先建立的数据表分为两类：发送文件缓存区和接收文件缓存区，所有的表 4 根据功能的不同向医院内相关信息系统开放不同的读

13、写权限。在提交数据时，医 院信息系统需要按照数据采集时点要求，定时批量的将生成的采集数据填入对应 的数据表内。 由医院提交到前置机发送文件缓存区的采集数据，由部署在前置机中的医 院端数据交换平台自动进行整合、上传等一系列工作。对发送文件缓存区内的存 储空间释放工作，也将由数据交换平台在完成了上传之后的若干时间之后自动进 行。 医院端提交数据的程序，要确保支持按时间段和业务域提交数据的功能， 要确保在断电或断网的情况下，支持数据重传的功能。 2.1.2 前置端数据反馈与处理 前置端由平台建设单位部署数据质量控制应用，用户分为两类：医院数据 接口厂商和医院数据质量控制专人。其中数据自检提供给医院数

14、据接口厂商，自 行调用此功能，对上传到数据接口中的各类业务数据，进行数据情况自检。通过 前置端数据质控应用系统，可以查看自检的结果，包括如下信息： l数据自检应用是否通过 l按照"数据提供单位'，"数据接口表名称'进行分类汇总。各数据提供单 位各数据接口表所插入数据的，记录总量、校验通过记录量，校验异 常记录量、校验严重错误量、校验警告错误量等 l对各类校验严重错误、校验警告错误进行分类展示。在提示存在相应异 常错误的记录总量的同时，对部分错误记录的相关信息进行摘录汇总 l对具体某个校验严重错误、校验警告错误相关的错误提示记录进行详细 展示。 生成的处理日志

15、保存在前置端的数据接入区中，且只保留最后一次的数据 质量自检结果。这样有利于接入单位针对接口程序进行调试，直到符合数据上传 的要求。 医院数据质量控制专人负责每天对本单位数据上传情况进行巡检，牵头上 传数据问题的解决。通过前置机端数据质控应用系统，可以查看如下信息： l按照"数据提供单位'，"数据接口表名称'进行分类汇总。各数据提供单 5 位各数据接口表所插入数据的，记录总量、校验通过记录量，校验异 常记录量、校验严重错误量、校验警告错误量等 l对各类校验严重错误、校验警告错误进行分类展示。在提示存在相应异 常错误的记录总量的同时，对部分错误记录的相关信息进

16、行摘录汇总 l对具体某个校验严重错误、校验警告错误相关的错误提示记录进行详细 展示。 l根据前置机核心区域中所保存的历史数据，依照指定业务发生时间、指 定接口数据表或数据域这两类参数进行数据重新发送。 l备份数据恢复、已有数据清除。 根据前置机端数据质控应用系统提供的功能，能够帮助医院数据质控专人 快速了解数据上传的情况、问题的锁定和问题的解决。 2.1.3 中心端数据反馈和处理 市区域卫生信息平台通过中心端的数据质控应用，将把采集数据的处理结 果通过系统的内部网站向医院发布，医院也可以到中心端数据质控相应的页面中 对处理结果进行查询。发布的处理反馈结果包括如下信息： l 日期、时间、处理的数

17、据表、提交数据条数、提交处理成功数据条数、 未成功处理数据条数。 l 未成功处理数据的内容和未成功的原因。 医院需要根据处理反馈结果查找原因，在解决了存在的故障之后，对未成功 的数据再次进行提交操作。 2.2 需医院配合的事项 武汉市区域卫生信息化平台建设需要各级医疗卫生机构的大力支持，在接下 来的项目推进过程中，需要完成与医院、社区信息系统的对接和平台应用的推广， 因此需要各级医疗机构提前做好准备并指定专人进行配合。所涉及到的具体工作 包括： 6 no. 整合名称 处理频次、时间点 1 医院数据填报过程 每日处理；每日 22 时前结束，与原方案相同 2 前置端整合过程 每日处理；22 时后开

18、始，24 时前结束 3 数据交换过程 每日处理；24 时（次日 0 时）后开始，次日 3 时前结束，与原2.2.1 应有专人配合 应指定专门人员负责以下工作，该人员必须可以随时联系。 l 在需求调研阶段，配合项目组对院内情况进行摸底，协调院内相关业务、 技术人员以及医院信息系统开发商参与调研。 l 在开发实施阶段，协调医院信息系统开发商按照市级项目组的要求完成 对医院信息系统的改造和接口的开发，配合项目组完成对院内所上传数 据的质量控制。协调医院内部资源完成对医院前置交换区域的软硬件环 境的准备，保证前置服务器的正常运行，保证网络的通畅。 l 在调试阶段，负责和项目组和各相关医院开发商联系，解

19、决问题，报告 解决的问题进度。 l 在验收阶段，负责医院端的验收准备工作，并负责对验收中出现的问题 进行跟踪解决，直至问题关闭。 l 试运行和正式运行阶段，如果医院端出现任何和中心系统有关的或是无 法判别的问题，需要及时通知项目组，并跟踪解决情况，直到问题关 闭。 2.2.2 数据上传的时点 如上一节所述，医院通过内部信息系统自动生成数据并定时批量提交到前 置机的提交数据缓冲存储区。医院端信息系统应每天提交业务运营数据，以及患 者基本信息、就诊履历信息、检验报告信息、住院病案的当天以及此前新增的诊 疗数据以及字典表的全量数据。 医院的信息系统应在每天 22:00 点以前完成将业务运营数据和诊疗

20、数据填 报提交到前置机的工作（医院可根据本单位情况安排上传时间），前置机从 22:00 开始数据整合、匹配的工作，市数据中心从医院的前置机采集数据的处理时点是 当日的 24:00 整（即第二天的 0 点整）。详见下表： 7 案相同 表 2-1：市数据中心从医院的前置机采集数据的处理时点 注：第 1 点由医院方面完成，第 2、3 点由市数据中心完成，即医院在 22 时前需完成数据填报的工作。 说明：在技术可行的情况下建议医院尽可能做到每日提交当天的全量数据； 若技术上有难度，则应做到提交前一日的全量数据，如 2 日 22 点前上传 1 日 0 点24 点所有的业务数据。 医院对下述三类数据的整合

21、处理期间策略为： l 对于临床病史中的门急诊类业务产生的患者基本信息、就诊履历信息、 检验报告信息：业务发生时点为此前 48 小时开始，直到当前时点已经结 束或尚未结束的全部诊疗信息。 l 对于临床病史中的住院类业务产生的住院病案信息以及相应的患者基本 信息、就诊履历信息、检验报告信息：业务发生时点为此前 72 小时开始， 直到当前时点已经结束或尚未结束的全部诊疗信息（包括出院、在院）。 l 对于业务运营相关数据中的业务量统计表、业务收入统计表，应提 交 48 小时以前开始、24 小时以前结束的业务的统计结果。 l 与整合处理时点之前 24 小时内产生的任何修改信息，包括字典表的全量 数据；

22、前置机将于每天 24 点整将当天医院信息系统填报提交的数据上传市数据 中心的数据库中，从而完成从医院获取业务数据的整个采集过程。 为避免医院内各子信息系统相互无法同步填报上传的数据时点。建议当患 者入院治疗开始的时点，医院即可将已经采集到的患者基本信息以及入院诊疗诊 断基础信息预先提交上传市数据中心，而不必等待患者出院结束治疗之后再全部 上传，有关的诊疗报告也可以陆续上传。当患者出院结束治疗之后，医院可再次 将入院时曾提交上传的信息连同新产生的各类报告一并上传，原先在院期间提交 的信息将会在市数据中心被更新。由此，市数据中心将在患者入院之际即为患者 在市数据中心建立档案组套，为此后获取的各类诊

23、疗报告整理入档打下基础。但 患者在入院期间的档案报告原则上将不会被跨医院联网调阅（除非住院期间的跨 院会诊情况）。 8 2.3 临床诊疗病史数据的整合 根据临床诊疗医疗业务逻辑以及中心端的数据库处理方式，数据表之间以 及数据表的字段之间存在着相互关联关系。医院提交的数据应该保证数据之间的 关联性，对由于特殊情况医院确实无法关联的情况下，由中心端的整合、匹配来 实现关联。 关联的原则是，对于同一家医院： （1）门诊急诊就诊记录表、住院就诊记录表、住院病案首页主体表、实验 室检验报告表头、医学影像检查报告、诊断明细表、手术明细表、出院小结表这 八个表必须与患者信息表通过"卡号+卡类型&#

24、39;关联。否则，市数据中心获取的有 关数据将不会被归入患者个人病史档案供利用。 图 2-2：门诊等按"卡号+卡类型关联' （2）实验室检验报告表头、医学影像检查报告、手术明细表、诊断明细表 可以与门诊就诊记录表或住院就诊记录表通过"就诊流水号'关联。住院病案首页 主体表、出院小结表则应该与住院就诊记录表通过"就诊流水号'关联。 9 图 2-3：实验室检验报告等按"就诊流水号关联' （3）手术明细表、诊断明细表、出院小结必须与住院病案报告主表通过"就 诊流水号'关联。 图 2-4：手术等按就诊流水号关联

25、（4）检验结果指标表、细菌结果、药敏结果必须与实验室检验报告通过"检 验报告单号'关联。见下图： 图 2-5：检验结果指标等按"检验报告单号关联' 10 对于不满足上述"必须'关系的数据不会被整合载入市数据中心的个人诊疗 档案库。 2.4 采集数据的质控 从医院采集的数据质量是支撑区卫生数据中心的各功能、各应用的基础和关 键。质量无保障的数据是无法支撑各项业务功能运作的。为此，需要对采集数据 从及时性、完整性、准确性三个方面进行控制。需要对医院提交的数据进行质量 整合处理，归理合格的数据入库，分层次筛选出质量欠合格的数据。将数据质量 上出现

26、的具体问题即时通知基层机构进行整改。区域平台将从前置机及区数据中 心分别进行数据控制： Ø 前置机数据质量控制：当每天晚上医院软件厂商完成数据提交到前置机数据 库后，将首先在前置机上运行区信息中心提供的数据质量控制软件，只有通 过此软件控制的数据才能被上传区数据中心，没通过的会留在前置机数据库 中。需医院内部软件厂商及时查看前置机数据库中是否有数据未通过前置机 端数据校验，若有数据未通过则修改后再次提交数据质量控制软件。 Ø 市区域平台数据中心数据质量监控：每家医院上传的数据通过前置机数据质 量控制软件后会自动通过数据交换平台上传到市区域平台数据中心，市区域 平台数据中心会

27、再进行严格的数据质控，并将质控结果下发到各家医院前置 机，并会提供质控结果统计分析界面让各级医院负责人在武汉市区域平台网 中查询并下载质控结果。 11 第 第 3 章 接口总述 3.1 数据交换形式说明 目前阶段，全国的卫生信息化在区域级大型规模的联网项目建设方面仍旧处 于起步阶段，国家层面已发布的规范标准仍有不健全的地方，而且，即便对于已 发布的有关说法实际上大多仍处于书面阶段，可行性尚未经过项目实施的验证。 作为项目建设首要的是实现整体上的业务目标，以此为前提，尽可能逐步向国际 行业的规范靠拢，同时也为形成本地行业的规范标准作出探索并打下基础。 为此，在目前项目实施阶段，对于各接入单位向市

28、级中心提交共享用诊疗文 档的技术方式，本规范界定了三种方式供各接入单位根据各自的实际情况作出最 适合的选择。市级中心端可以根据各接入单位作出的选择而进行针对性处理，针 对市级平台一期项目，我们绝大多数数据会采用全数据库中简表方式进行数据交 换，对于协同性实时性业务，我们提供 xml 方式进行交换。 3.1.1 全 xml 文档格式 参考 hl7 cda 国际行业规范的思路，按照国际行业对诊疗文档通常的处理方 式，将文档归为"文档头'与"文档体'两个部分。文档头（注册类信息）包括服务 对象身份标识、地点、时间、文档内容类型等以可分析计算为主数据信息。文档 体包

29、含的是文档详细内容，其中采用代码化填报的则可进行计算，否则属于可阅 读的，采用格式化文本文字填报的则可进行基于文字内容的搜索。 此方式是指，各接入单位提交给市级中心供共享用诊疗文档的文档头与文档 体均采用 xml 的格式。 3.1.2 全数据库中间表方式 当前的现实情况是，实际上各级各类医疗卫生信息系统之间通常仍旧是采用 数据库中间表来进行数据交互的。这种方式对于诸多服务商在实施上是比较方便 12 的，理解上是比较容易的。但其缺点是对内容的可扩展性和灵活性会具有相当大 的局限性。如果有接入单位对本规范推荐的数据库中间表在内容和格式上认为有 其个性化调整要求的，可以直接提出，我们可以进行针对性的

30、适应性调整。 当接入单位采用推荐的数据库中间表格式进行文档提交，则不必再将各个文 档按照文档头+文档体的方式进行信息化处理，有关的文档头信息将可以由市级 中心端进行归理和抽取。 3.1.3 xml 文档格式与数据库中间表混用方式 指并不是全部采用数据库中间表，也不是全部采用 xml 文档格式，而是对 于文档头采用 xml 文档格式，但文档体的内容采用数据库中间表，或者是相反， 即文档头采用数据库中间表，文档体采用 xml 格式。相对来说，由于文档体的 内容比较灵活，如果采用 xml 格式则在应对将来的灵活变化上更加有利。文档 头的内容相对比较确定，灵活变化的可能性相当小，所以即便采用数据库中间表 也无妨。对于文档头采用数据库中间表的推荐格式，本规范暂不进行界定，待有 接入单位提出比较明确的意向后可以增补。 3.2 接口数据集概述 本接口数据集主要包括业务运营数据集、临床诊疗记录数据集、合理用药数 据集、基础字典数据集。业务运营相关数据是指医院在医疗服务主营业务方面的 业务量、业务收入数据。临床诊疗记录相关数据主要包括服务对象信息、就诊事 件信息、诊疗报告等。合理用药预警及管理系统将从各医疗机构采集药品的生产、 配送、使用机构以及患者的用药信息。基础字典相关数据包括医院科室字典、医 护人员字