一、建设背景
我国医院信息系统经过近40年的发展，大部分医院已经被架构陈旧的HIS制约业务发展。一方面HIS厂商的技术人员流动，致使HIS对需求变更的响应越来越慢，成本越来越高，用户满意度越来越低；另一方面，随着互联网+医疗服务模式的兴起和医疗服务市场竞争的加剧，医院对IT系统提出越来越多的需求以期满足业务模式变革和精细化管理需要。医院与HIS厂商的矛盾越来越尖锐，医院更换HIS的代价和风险则与日俱增。
可以说，陈旧架构的HIS已经成为医院信息化的绊脚石，制约了HIT行业的健康发展。HIS大厂占据着大医院的基础核心业务系统，凡是新进入的软件应用系统，都需要向HIS缴纳不菲的接口费，严重制约创新产品的应用准入。医院对新应用系统产品的选择，需要看HIS厂商的脸色，要么委屈选用HIS厂商推荐的产品，要么向HIS厂商支付高额接口费选用中意的优秀产品。
摆脱HIS厂家绑架劫持，不仅是多数医院的呼声，也是广大中小HIT厂商的心声。
二、技术方案
（一）系统架构
1.云原生架构
云原生（Cloud Native）架构的软件系统，面向云计算环境，采用容器化分发部署，使得系统在云计算环境下具有很好的可管理性、可伸缩性和可用性。医院新开发的应用软件系统，应尽可能面向云原生架构；新采购的应用软件系统，优先选择云原生架构的软件产品。
应用系统设计开发，应尽可能采用多层应用架构、前后端分离和微服务架构，实现面向接口（API）的应用编程，便于应用的前端交互和后端服务可独立并行开展持续迭代优化和敏捷开发，减少系统升级、运维对用户的影响，同时降低系统的开发成本和运维成本。
2.基础支撑平台
当前，云原生架构的智慧医院应用软件产品还比较短缺，医院应用软件完全云化的目标，在短期内还难以达成。因为现有单体应用软件和新型微服务架构应用软件，将在相当长的一段时间内并存，所以，医院需要拥有基础支撑平台，为医院信息系统集成提供基础支撑和共性能力。
基础支撑平台提供微服务治理、微服务网关、认证网关等微服务应用支撑以及企业服务总线(ESB)等面向服务架构（SOA）的能力，为新架构应用系统的开发、运行和新老应用系统的集成提供平台支撑。
微服务是去中心化的SOA解决方案，可以采用当前主流的开源微服务框架，如Spring Cloud、Dubbo等。
ESB是中心化的SOA解决方案，其主要诉求是为了解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。ESB以中心辐射架构替代原来点对点的系统集成解决方案，成为企业应用通讯的中心枢纽。
目前存在许多成熟和应用广泛的开源ESB，如Open ESB、Service MIX、JBoss ESB、Ultra ESB、Mule ESB、WSO2 ESB等。可以使用支持医疗健康领域消息格式（HL7）的轻量级开源ESB，如Mule ESB或WSO2 ESB。
3.基础支撑应用
为了方便系统运维管理，同时减少不同应用系统的共性通用功能开发，基础支撑平台提供用户标识管理系统、统一授权管理系统和统一安全认证系统，实现不同应用系统的统一用户管理、集中授权管理和统一安全认证。
用户标识管理系统用于统一管理机构数字应用环境的用户标识，支持使用手机号码、电子邮箱、证件号码、用户名等属性来唯一标识用户身份，并支持使用密码、随机短信验证码、生物特指、CA证书等多种方式进行多因子用户身份认证，满足网络安全等级保护的用户身份识别要求。各应用系统均通过用户标识管理系统完成用户身份认证，避免用户敏感信息分散存储在多个应用系统，从而增大敏感信息泄露的风险。
统一授权管理系统用于统一管理企业的组织架构与用户权限，支持将多个应用的访问资源及资源访问权限进行集中管理与集中授权，运维人员只需在统一授权管理系统下，集中一次性完成各应用系统的授权管理工作，无需多次进入不同应用系统进行用户管理及用户授权；系统支持人员权限随着工作岗位变动而自然变化，岗变权变，极大地提高了IT系统运维效率，降低人员换岗、离职场景下可能存在的IT系统权限收回不及时造成的信息安全风险。
统一安全认证系统依托用户标识管理系统和统一授权管理系统，向内、外网应用提供统一的安全认证服务，主要包括应用接入认证、用户身份认证、应用访问控制、系统单点登录等。
基于内外网安全边界控制策略，既满足内、外网应用的统一安全认证需要，又避免将用户与权限数据库及服务直接暴露在外网上，降低用户及其鉴权信息的泄露风险。
（二）医院信息集成平台
医院信息集成平台使用企业服务总线（ESB）技术实施企业信息系统集成(EIP)，将医院临床信息系统(CIS)、医疗管理信息系统（HIS）、医技医辅系统（MTS）、医院运营系统(HRP)等应用系统进行数据与服务集成，同时通过平台对应用系统提供统一的基础服务（如患者主索引MPI、医院主数据MDI、统一安全认证UAA、医疗文档共享交换XDS等）。
1.医院服务总线（HSB）
梳理医院信息系统之间的交互与数据交换需求，厘清医院各应用信息系统之间的服务调用关系，制定医院信息系统的标准服务API和数据交换与系统交互规则，成为医院的系统集成标准；利用基础支撑平台的 ESB，配置医院信息系统API，使用ESB实现医院内外部系统之间的标准化编程接口 (API) 和数据交换。
2.平台基础服务
医院主数据和患者主索引是医院信息平台提供的基础服务。医院各应用系统必须使用医院信息平台的主数据和主索引服务，确保主数据和患者身份的一致。
医院主数据主要包括组织机构（分支机构及部门）、岗位、职员、专业技术人员(医师、护师、药师、技师)、药品耗材、物价收费项目、诊断、手术操作、检验检查项目、医嘱项目(组套)、医学术语等基础编码数据，以及人员性别、行政区划、血型、学位、学历、证件类型等国家或行业标准字典。
平台通过身份证件号码或其他信息为每一名患者建立唯一标识，并提供对患者信息进行创建、变更、合并等操作功能。医院信息平台建立患者主索引服务和患者交叉索引服务，各应用系统通过使用平台获得患者的全局唯一标识，并使用全局唯一标识关联相关业务记录和病历资料，以便能够通过患者全局唯一标识，对各系统产生的数据进行关联，形成完整的患者电子健康档案。
通过医院信息平台提供医疗文档存储服务，并实现医疗文档共享交换（XDS）。
3.医院数据资源管理
将HIS、EMR、LIS、PACS/RIS、HRP等不同业务信息系统产生的业务数据，通过数据清洗或数据转换、加载，汇聚到平台数据资源库，形成全方位的临床资源库（CDR）和全面的运营资源库（ODR）。
4.医院数据资源利用
整合不同业务信息系统产生的各类数据后，医院信息平台就可以使用大数据技术、方法对全院数据进行分析、挖掘和利用。主要的应用方向包括临床决策支持（CDSS）和管理决策支持（DSS）。
（三）医院信息系统解耦
HIS是医院信息化应用的基础，也是医院必备的核心业务系统之一，由于历史原因，HIS软件系统从最初的收费结算、基本医疗业务流程管理逐步发展到囊括临床(电子病历)、医技(LIS/RIS)、医辅（药品、耗材、消毒供应）和运营（预算、成本、财务、人事、后勤）等大部分医院业务内容的庞大复杂系统，因而系统的复杂度和运维成本越来越高，响应用户需求变更越来越慢，用户满意度越来越低，而医院更换HIS的代价和风险则越来越高。一家三级医院更换HIS不仅需要投入大量的人力物力进行项目现场保障，而且更换系统的用户阵痛期往往长达半年甚至1至2年，对医院的正常业务造成很多困扰甚至遭受损失。因此，目前大部分医院对现有HIS基本不满意，但又不好下定决心更换新的HIS，而一些HIS厂商则趁机对医院信息化进行劫持绑架——如果医院的后续信息化项目不由现HIS厂商承建，HIS厂商就会狮子大开口索要一笔巨额接口费，医院对新系统的选择被HIS厂商制约并提高了建设成本。
为了避免重蹈医院信息化被HIS掣肘或绑架的覆辙，医院信息系统需要进行解耦设计，将庞大臃肿的HIS弱化成为轻量级的HIS中台，并通过医院服务总线（HSB）对医院信息系统之间的接口实施标准化配置和运行监控。医院只要牢牢把握医院服务总线（HSB）的配置运维和HIS中台的数据标准等主导权，就不会被任何软件厂商绑架劫持。
1.轻量化HIS中台（MicroHIS）
轻量化HIS中台借鉴微内核架构设计理念，由极致精简的HIS数据中台与业务中台构成，其中HIS数据中台规范和定义医院各业务信息系统需要共享的业务数据存储管理与数据操作标准，包括挂号、诊疗、诊断、医嘱、处方、申请单、医嘱执行记录、申请单执行记录、手术记录、检验检查报告、医疗文档、危急值报告、服务费用记录、收费结算记录等数据的创建、存储、更新、查询等标准方法和过程。
HIS业务中台则提供HIS数据中台的数据操作API和基于HIS数据中台实现医嘱（申请单）执行、处方划价计费、收费结算、费用支付（如电子支付、医保结算、信用支付）等HIS基础应用功能，让HIS中台回归到最初的HIS设计目标，将临床（电子病历）、医技医辅（医技及医疗保障）、医疗管理（业务管控）、医院运营（人、财、物管理）等系统从HIS剥离出去，并通过医院服务总线（HSB）实现松耦合系统的标准化互操作。
2.临床信息系统解耦
临床信息系统以电子医嘱(CPOE)和电子病历(EMR)为主要应用功能，涵盖各类医护工作站和治疗执行工作站，主要包括门诊医生工作站、门诊护士工作站、病房医生工作站、病房护士工作站、手术麻醉病历系统、申请单执行系统等。临床信息系统可以由传统HIS厂商在HIS通用医护工作站(电子医嘱处理)基础上，扩展电子病历书写能力而成，也可以由EMR厂商在电子病历工作站基础上，扩展医嘱处理能力而成。
临床信息系统解耦后，医院各临床科室就可以根据本科室的业务特点，选择不同厂商的临床信息系统（医护工作站），让医院业务部门拥有自主选择业务信息系统的权利，临床科室的业务信息系统更换与升级，影响范围被限制在科室内部，不会对医院其他科室的业务造成任何影响，从而大大降低医院信息系统对临床学科发展的制约，有利于临床业务的能力提升和学科发展。
临床信息系统通过HIS中台获得门诊挂号、门诊诊疗及住院诊疗信息，诊断、医嘱、处方、申请单、医疗文书等信息与HIS数据中台实时共享，实时更新数据中台的共享数据。
3.医技医辅系统解耦
医技医辅系统主要包括放射、超声、内镜、病理、电生理、检验等医技信息系统和门诊药房、住院药房、静脉药物配置中心、消毒供应、医疗耗材供应等医疗辅助信息系统。大部分医技系统独立于HIS，而传统的HIS往往包含了药房系统和医疗耗材供应系统功能。
随着医院供应链精细化管理要求和SPD服务的兴起，传统HIS系统的药房、物资供应等医疗辅助应用模块已经难以适应医院的管理需求，SPD服务商和HRP厂商逐步推出独立的医疗辅助业务系统。
医技医辅系统解耦后，共享医院信息平台主数据，与基础支撑平台实施统一安全认证与单点登录，并与HIS数据中台实时共享医嘱与医嘱执行记录，使用HIS业务中台实现统一的医嘱执行与划价计费功能。
医技医辅系统解耦后，让医院各医技医辅部门有机会选择更加专业的业务系统，实现医院及科室的精细化管理目标。
4.医疗管理系统解耦
传统HIS系统提供的门诊排班、预约挂号、分诊排队、登记预约、医务管理、护理管理、药事管理、输血管理、会诊管理、手术管理、物价管理、医疗质控等功能应用，将作为独立的系统从HIS剥离，通过医院服务总线（HSB）实现与HIS中台和其他医疗信息系统的松耦合集成，这有助于医疗管理系统的灵活个性化定制和快速需求变更响应，提高医院各职能管理部门的信息化应用水平和管理效率，提高医院智慧管理与智慧服务应用水平。
5.医院运营系统解耦
医院的行政人事管理、财务管理、供应链管理、后勤管理等专业领域的管理子系统，取代传统HIS的相关管理模块功能（如人员管理、采购与库存管理、设备物资管理等）已经成为趋势。目前，HRP厂商和SPD服务商均已推出更加专业的医院运营管理系统，为医院的精细化管理提供专业的管理工具和托管服务。
（四）国产化适配
医院信息系统需要将国产化适配工作提上日程，新的应用系统，应该尽可能完成国产化适配，或者选择便于实现国产化适配的技术路线和技术方案。
云原生架构应用由于对硬件设备和操作系统的紧密依赖程度较低，能够使用较低成本迁移到纯国产化的云计算环境。
应用系统所依赖的中间件和PaaS平台，应该具有可替代的国产化产品；数据库管理系统优先选择与国产化数据库全兼容或具有可替代国产化数据库的产品，或者选择开源数据库。
三、建设内容
（一）基础支撑平台
基础支撑平台选用WSO2 ESB和Dubbo3微服务架构，部署用户标识管理系统、统一授权管理系统和统一安全认证系统等基础支撑应用。
1.用户标识管理系统
用户标识管理系统提供的核心功能是用户标识管理和用户身份认证。
（1）用户标识管理：支持使用手机号码、登录名、证件号码等多种方式，对数字环境下的用户身份进行唯一标识。
（2）用户身份认证：既支持使用用户标识+密码的简单身份认证，也支持用户标识+密码结合短信验证码、安全终端绑定与登录区域限制、生物特征识别、数字证书等多种方式的多因子身份认证与登录安全控制，提高用户身份认证强度。
2.统一授权管理系统
集中用户授权是统一授权管理系统的核心诉求。允许将多个应用的访问资源及资源访问权限进行集中管理与集中授权，运维人员只需在统一授权管理系统下集中一次性完成各应用系统的授权管理工作，无需多次进入不同应用系统进行用户管理及用户授权。
3.统一安全认证系统
统一安全认证系统向应用系统开放统一安全认证服务。包括应用接入认证、用户身份认证、应用访问控制、系统单点登录等。
（三）医院信息集成平台
医院信息集成平台建设医院主数据、患者主索引、基础知识库、病历存储管理等基础服务，并通过医院服务总线将平台基础服务向应用系统发布。
1.平台基础服务
通过平台统一维护性别代码、医师类型代码、给药途径代码、频次代码、职业代码、学科门类代码、学位代码、学历代码、身份证件类型代码、处方类型代码、诊断类别代码、医疗类别代码、险种类型代码、治疗类别代码等基础字典数据，并通过医院服务总线开放基础字典数据的订阅、查询服务。
通过平台统一维护管理病种编码、诊断编码、危急值项目编码、药品耗材编码、服务项目编码、医学术语编码、机构编码、科室编码、病区编码、诊室病房编码、床位编码、组套项目、医学术语编码等主数据，并通过医院服务总线开放数据订阅、查询服务。
平台统一管理和维护患者基本信息，实现患者查询、拆分、合并等功能，并对患者进行唯一标识，通过医院服务总线开放患者注册、患者查询、患者交叉索引等患者主索引服务。
平台统一维护医师、护师、药师、技师等专业技术人员基本信息和医疗小组，通过医院服务总线开放人员注册、人员查询、人员订阅等服务。
平台统一维护机构参数、机构处方集、机构医嘱必备项目、科室服务项目、科室后付费项目、科室常用医嘱项目等基础配置信息，通过医院服务总线开放基础配置信息查询服务。
平台统一维护机构服务物价、科室项目物价、科室给药收费设置等收费计价相关的基础数据及计价规则，各应用系统可以通过医院服务总线订阅收费物价基础信息和收费计价规则。
2.医疗文档存储管理
平台提供医学文档存储、签名、验签、调阅等管理功能，并通过服务总线提供医学文档共享(IHE-XDS)服务。
3.医院服务总线（HSB）
使用基础支撑平台的ESB中间件，将平台基础服务及各微服务架构应用的开放服务配置到ESB端点，形成医院服务总线(HSB)。使用ESB的监控组件对服务总线的运行状态及业务流进行监控跟踪。
（四）轻量化HIS中台
1.HIS数据中台
HIS数据中台定义了医院基本运行所需的各核心业务系统需要共享的精简数据集，包含管理、收费和临床、医技、医辅系统之间频繁交换共享的数据。数据中台提供对这些共享数据进行操作的标准服务接口(API)，允许应用系统通过API调用对中台数据进行创建、更新、查询等操作。数据中台也允许应用系统在遵循数据中台业务数据处理规则的前提下，直接操纵数据库，对数据库执行标准SQL的INSERT、UPDATE、DELETE、SELECT等操作。
HIS数据中台定义了挂号分诊记录、诊疗服务记录、诊断记录、医嘱记录、处方记录、申请单记录、手术记录、医疗文档记录、危急值报告记录、服务费用记录、收费结算记录、医嘱执行记录和申请单执行记录。
门诊挂号系统在挂号和预约取号时，在HIS数据中台创建挂号记录，挂号状态设置为正常，诊疗状态设置为未分诊。
排队叫号系统通过数据中台获取挂号记录，进入排队叫号系统排队，排队叫号系统需要回写数据中台挂号记录表的排队订单ID，方便通过挂号记录关联查询患者的排队动态。
需要预检分诊的诊区，从HIS中台获取相关未分诊的挂号患者进行分诊，分诊护士完成预检分诊后，创建（或更新）分诊记录，同时将挂号记录的诊疗状态设置为待接诊，如果原挂号记录未指定挂号医师，则在分诊时还应该为该诊疗记录设定挂号医师。
门诊医生工作站从HIS中台查询患者挂号记录，获得本人的各诊疗状态患者列表，使用顺呼策略呼叫患者前往诊室就诊（需要优先就诊的患者，应该通过排队叫号系统进行调整，确保就诊秩序的公平公开），若患者未能到诊，则将挂号状态变更为过号，过号的挂号记录诊疗状态仍然维持待接诊状态，过号患者可以通过排队叫号系统进行“过号重排”重新进入候诊队列等待医生呼叫接诊，过号重排的排队策略由分诊排队叫号系统管理。
门诊医生工作站接诊患者后，将挂号记录的诊疗状态设置为“诊查中”；医生接诊患者后，如果发现患者更适合到其他科室或本科室其他出诊医师看诊，为了改善患者体验，在不影响挂号费用结算的前提下，医生可以在诊间为患者办理院内转诊，从新科室（或新医师）申请到新的挂号号数后，更改当前挂号记录的科室代码（看诊科室）、挂号医师（看诊医师）、挂号号数（新申请到的挂号号数）和转出医师（当前医师），并分别将挂号状态和诊疗状态变更为转诊、待接诊；如果已经产生了诊疗记录，可以作废诊疗记录并清空挂号记录的诊疗ID，或者更新诊疗记录的。为了避免患者产生被推诿的误会，系统应该限制对同一挂号记录执行多次转诊。
退号后，将挂号状态设置为“退号”。
患者结诊患时，增加机构就诊当日的门诊结诊数量，并将统计数值更新到挂号记录的日门诊序号。
HIS数据中台将门诊、住院记录统一保存到诊疗记录表，并通过门诊病例表和住院病例表将门诊、住院诊疗的不同属性分表存储。
门诊医生接诊患者并提交门诊病历时，检查患者挂号记录是否已经关联诊疗记录，如果尚未关联则创建新的诊疗记录并建立挂号记录与诊疗记录的关联关系，否则，直接更新已经存在关联的诊疗记录相关信息。
住院患者在办理入院时创建住院诊疗记录，同时将收治科室作为该诊疗记录的第一个住院科室，在患者到达病区办理入区手续时，将诊疗记录加入科室在院患者表；病区护士站办理患者出区手续时，将患者从当前科室的科室在院患者表移除。
由于患者紧急转科时，出科后原转出科室可能仍然需要补录医嘱，此时应该通过向转入科室申请医嘱补录，转入科室批准并设置有效期限，将患者加入原转出科室的科室在院患者表，转出科室就可以进行医嘱补录。
录入或补录医嘱时，医嘱的科室序号应使用科室在院患者表中的科室序号（即转出前的科室序号），而不是诊疗记录状态表中的患者当前科室序号。补录完成后，原转出科室将患者从科室在院患者表移除。
为了减少重复诊断的数据冗余，HIS数据中台将门诊诊断、入院诊断、出院诊断等诊断信息都保存到诊疗记录诊断表，并分别通过门诊诊断表、入院诊断表、出院诊断表、医保诊断表对诊疗记录诊断进行引用。
医生对门诊诊断、入院诊断和出院诊断进行编辑时，如果诊疗记录诊断表已经存在诊断编码，就可以直接引用而无需重复添加。考虑到医保确定主诊断的原则与临床确定主诊断的原则可能不同，为此，允许医保医师或编码人员将出院诊断进行补充和重排，形成医保诊断用于医保结算和医保数据上传（如结算清单上传、病案首页上传等）。
病案编码人员可以根据医师诊断结合病历资料，调整或增补诊断编码，调整的诊断状态设置为“编码更改”，如果存在编码更改的诊断，则以编码员的诊断编码和诊断名称作为最终的诊断，否则使用医师的诊断编码和诊断名称。
医嘱记录在医嘱开立或医嘱补录时创建，医嘱一般由医生使用临床信息系统(如病房医生站)录入，也可以由实习生或抢救护士等人员录入，再由口头下达医嘱的医师审核签名。医师未签名的医嘱，护士不能核对和执行。
有赖其他科室执行的诸如医技、治疗类医嘱项目，需要填写申请单时，由医嘱录入人员创建或完善电子申请单内容，并将申请单流水号引用到医嘱记录，以便能关联申请单了解其状态变化。
医嘱签名采用批量医嘱合并签名方案，签名者根据医嘱状态筛选进行多条医嘱批量选中，按医嘱的显示顺序将所选医嘱的医嘱号、开立时间、开始时间、医嘱内容、嘱托、组标记等数据列构造JSON医嘱数组或XML文档对象，使用签名者的CA证书对JSON字符串或XML文档进行数字签名，并将签名结果(数字签名戳)保存到医嘱签名记录表，以供验签使用。
门诊处方由具有处方权限的医师开具，处方需要有患者的诊疗记录和诊断记录。西药处方的诊断从患者诊断记录中选择一条未排除的西医诊断，记录到处方的主病诊断，作为处方的用药依据；中药处方需要从诊疗诊断记录表中分别选择中医病名和中医症候作为处方的主病和主症。
申请单是在处方的基础上扩展属性，遵循处方的处理控制逻辑。门诊处方开具后，对于需要出库的处方（如中西药处方），划价时由划价系统向执行科室（药房）发送处方，申请确定处方药品规格型号及价格并进行库存预占，产生划价单并将划价单流水号回写到处方记录，同时设置处方收费状态为“待收费”；收费系统完成收费后，需要将处方的收费状态变为“已收费”。
处方执行科室收到其他科室发送的处方后，将处方设置为已接收，对于执行状态为已接收的处方，开单医生如果需要撤回处方，则必须让执行科室将处方执行状态退回到待接单或已撤销状态。执行科室开始执行处方前，应该判断处方的收费状态为已收费，避免尚未收费或已退费的处方被执行出现漏费；开始执行处方时，将处方执行状态变更为“已执行”，处方执行完毕，设置处方执行状态为“已完成”。
收费系统要对处方进行退费前，需要确认退费处方的执行状态必须处于已撤销状态，避免已接收（准备执行）、已开始或已完成的处方被中途退费。
处方可以设置成为处方模板，支持医生选用处方模板快速开具处方，在模板处方的基础上进行简单的用量、数量修改就能够快速完成处方开具。
处方签名使用签名者的数字证书，对电子处方单的JSON字符串或XML文档对象进行数字签名，签名时间、签名类型、签名证书及数字签名戳等信息保存到处方其他信息表。
检验申请单和检查申请单属于特殊的处方，申请单的检验检查项目保存在处方明细表，而具有多个检查部位的检查项目，其部位信息保存到处方明细部位表。
申请单可以通过划价收费系统进行自动划价，产生划价单，用于收费结算。医技执行系统在签发报告时，要将报告元数据和报告内容推送到HIS中台，保存到申请单报告记录表，同时增加申请单的未读报告计数，以便医师能够及时获得报告发布通知并及早调阅报告。
手术申请单是电子申请单的一种，手术执行的主要内容和结果状态记录在手术记录表中，正式的麻醉记录和手术病历，则分别采用独立的电子病历文档存储。
医疗文档主要记录电子医疗文书的元数据，并使用通用的外部存储服务（如文件存储、对象存储）存储文档内容。
医疗文档可以在签名时提交，也可以在归档时提交；为了便于实施在架病历质控，建议病历文件创建后，每次更新都提交到平台。
医技部门发现危急值时，填写危急值报告，并通知临床科室及时采取有效措施防范化解危及患者生命的风险。
HIS数据中台使用划价单存储医疗服务费用。处方划价、医嘱执行、申请单执行都会产生划价单，供门诊收费或住院结算使用。当处方、医嘱执行、申请单执行需要消耗供应部门的库存（如药品、耗材）时，需要使用库房的实际出库明细进行计价，出库单流水号被划价单引用，以备关联出库单明细查询。
通过处方划价产生的划价单，引用处方流水号（数据中台处方的唯一标识）跟处方建立关联。医嘱执行和申请单执行产生的划价单，处方流水号置空(NULL)。划价单明细表中的非医疗标志位、复方使用标志位、医院审核标志位和医保上传标志位用于医保结算的费用上传，医保费用上传返回的对应信息，保存到医保费用明细信息表。
收费结算针对未结算划价单进行合并结算，产生结算记录。收费人员根据结算记录的总金额，可以选择现金或不同渠道的电子支付完成收费结算的资金支付。资金交易记录表记录各电子支付渠道的资金支付交易请求交易及交易结果。发票记录表则根据发票开具规则，由收费结算系统在成功结算后产生，发票可以补打或者申请开具电子发票。
收费结算处理时，根据收费人员选择的划价单(结算记录划价单表)，对划价单的费用明细按费用类别汇总，保存到结算费别汇总表。结算费别汇总数据是发票的原始数据来源，有些医疗机构允许将所有费别打印到同一张发票，而有些机构则要求根据发票费别的发票归属编码分票，需要将不同发票归属编码的费别，放到不同的发票。
收费结算时，收费系统应该在向收费员展示各结算费别金额及总金额后，允许收费人员添加不同的资金类型和对应的金额到收费资金明细表。如果资金类型的电子支付标志位为非0，则需要选择一种支持该资金类型的交易渠道，发起支付交易，将交易流水号记录到收费资金明细表。如果收费资金明细表的交易流水号交易状态为“已成功”，则不允许收费员删除和修改该笔收费资金明细；若需要删除必须通过撤销交易实现。审核确认结算记录时，必须保证结算记录的收费资金明细表金额汇总与结算总金额一致（总分一致），且收费资金明细表中的各交易流水的交易状态均为“已成功”，否则可能会造成收费资金无法到账造成损失。
收费系统在确认收费结算完成时，需要在数据中台将本次收费结算涉及的处方的收费状态设置为“已收费”，以便处方执行部门在接收/执行处方时，对处方的收费状态进行判断，防止漏费。
医嘱执行记录和医嘱执行异常记录，是电子病历的重要组成部分。每次执行医嘱可以选择多条医嘱，可以记录从开始到结束的每一步操作步骤的操作人、操作时间及其费用明细；也可以按天或几天批量执行医嘱，根据医嘱的执行内容和次数，产生计费单用于住院费用结算。
医嘱执行步骤消耗费用，如果执行项目属于不需要管理库存的服务项目，则在步骤操作完成确认时，直接将执行步骤消耗明细加入医嘱执行费用明细表；如果项目是需要库存出库的商品，则需要等待出库完成后，依据出库单的商品明细，产生医嘱执行步骤消耗明细表，并同时将费用明细添加到医嘱执行费用明细表。医嘱执行完毕，对执行费用明细进行复核记账，产生划价单供结算使用。
与医嘱执行记录类似，申请单执行记录用于执行部门在执行其他科室发送的申请单时，对执行过程及其费用明细进行记录。执行完成后，对执行费用明细进行复核记账，产生划价单供结算使用。
2.HIS业务中台
1）收费会计业务
提供票据管理、备用金管理、出纳交账处理等收费会计处理API。
2）门诊业务
提供门诊挂号、预约取号、门诊划价、门诊接诊、门诊诊断、门诊病历、门诊处方、医保挂号/撤销、医保就诊信息变更、门诊结算/撤销等基本的门诊业务处理API。
3）住院业务
提供住院登记/撤销、病区患者入出办理、出院办理/召回、医保住院办理/撤销、医保就诊信息上传、医保费用明细上传/撤销、医保出院办理/撤销、住院费用结算/撤销等基本住院业务处理API。
4）申请单业务
提供申请单开立/签名/撤回/作废、划价、收费/退费、发送/登记/退单、登记排程、执行/完成/终止/撤销等操作的业务处理API。
5）医嘱处理
提供病区医生护士进行医嘱开立/签名/召回/作废、核对/驳回/发送、执行/停止、补录等业务操作的数据处理API。
6）电子支付业务
提供微信、支付宝、银联等电子支付和医保结算相关业务处理API，包括扫码支付、支付码支付、医保门诊预结算/结算/撤销、医保住院预结算/结算/撤销、医保结算对账、支付交易状态查询、支付交易异常处理等API。
7）医疗文档管理
提供医疗文档提交、签名、归档、查询等处理API，采用外部存储服务(如文件服务、对象服务等)存储文档。
HIS业务中台提供以下前端应用，满足医院门诊挂号、门诊收费、入出转院办理、住院结算、医技(治疗)执行、收费会计等日常精准收费结算和收费会计管理需要，成为智慧医院数字化运转的强大基石。可以灵活搭配不同厂商的医护工作站和医技医辅系统，达到电子病历应用4级甚至更高标准。
1）门诊挂号收费系统
门诊挂号收费系统提供门诊挂号/退号/改号、门诊收费/退费、门诊收费票据打印/作废/补打等功能，满足门诊挂号窗口、收费窗口的日常业务办理与数据查询需要。
2）住院入出转与结算系统
住院入出转与结算系统提供住院登记/撤销、出院(转院)办理/召回、住院预交金收费、在院中途结算/撤销、出院结算/撤销等功能，满足医院住院部对住院患者进行入出转院办理与收费结算管理的业务需要。
3）医嘱与申请单执行系统
医嘱与申请单执行系统提供临床及医技、功能科室对患者医嘱及申请单发送、接收、计价、执行等操作管理功能，实现医嘱与申请单精细化执行及精准计费管理。在医院更换HIS时，可以使用适配器将现HIS的处方及医嘱数据汇聚到HIS数据中台，使用HIS业务中台的划价收费功能，并利用本系统来处理老HIS开具的临床指令(医嘱、处方)的执行与计费，满足医院更换HIS期间的业务平稳运行需要，避免同时大规模更换临床系统带来的巨大风险和压力。
4）收费会计管理系统
收费会计管理系统提供各窗口收费出纳进行交账会计核算以及收费票据管理功能。
（五）其他应用系统
1.门诊排班管理系统
门诊排班管理系统提供医院门诊医生的出诊安排，根据门诊排班确定门诊挂号号源；门诊挂号号源是门诊预约诊疗的基础。
系统支持科室排班和专家排班两种排班模式。科室排班只安排科室的接诊号数，而不明确出诊医师；专家排班针对每个医师单独进行排班。
采用科室排班时，支持周固定排班模式，以一周为基本单位，设置好每天各午别的出诊医师人数和每人接诊的号数。系统在排班有效期内，根据当天的周排班设置自动产生号源，自动跳过节假日。
专家排班功能支持同时对专家在不同院区、不同科室的排班。
排班号源需要支持不同的号源取号方式（如线上、现场、任意等），可以设置号源取号方式的分布规律，自动根据采用的分布规律设置各个号源的取号方式。
2.分诊排队叫号系统
分诊排队叫号系统通过HIS中台获取患者挂号信息，并根据挂号信息和排队策略，自动按挂号号数顺序进行排队，并可根据老年优先、急诊优先、预约优先等原则进行动态调整。
通过候诊区大屏、诊室小屏等媒体终端，发布候诊排队信息，播报叫号语音，引导患者公平、有序到达诊室就诊，维持良好的门诊就诊秩序，缓解等候人员的焦虑情绪，改善患者就医体验。
3.基本供应保障系统
药库管理系统提供药品采购计划、采购入库、采购退货、药房申领、药房退库、库存盘点、库存损溢等业务功能，实现药剂部门对药库的有效管理。
设备物资库管理系统提供设备物资等非药品的采购入库、采购退货、物资申领、申领退库、库存盘点、库存损溢等业务功能和多级库房管理功能。
提供药房调拨申请、调拨入库、调拨退库、库存盘点、库存损溢、处方调配、处方发药、医嘱领药、医嘱摆药、医嘱发药等药房业务管理功能。
4.HIS/EMR、LIS、PACS/RIS更新升级
对现有HIS/EMR、LIS、PACS/RIS进行升级改造，满足集团化、O2O业务需要和电子病历应用评级要求。
（六）O2O医疗健康服务平台
建设支持线上线下融合(O2O)的医疗健康服务平台，通过互联网向患者提供更多便利服务，延伸医院服务半径，提高医院影响力。
O2O医疗健康服务平台的主要建设内容包括医生云诊室、O2O门诊医生工作站、用户事件反馈系统、医院信息门户与信息发布管理系统、便民服务平台和处方流转平台与云药房系统。