新旧HIS衔接空档期，巧用过渡方案实现医疗收费电子票据对接

来源：HIT专家网 作者：陈昌齐

2020年，按照贵州省的统一要求，笔者所在医院应在当年9月30日前完成系统对接和医疗收费电子票据上线使用工作。但我们面临的特殊情况是：原HIS厂商的服务期限已到，医院正在进行全院信息系统的升级工作。在旧系统不能提供服务、新系统尚未上线的空档期，如何尽最大努力确保电子票据的对接工作？

医院信息科提出一种思路：医护人员保持现有临床业务流程不变，仍在原HIS系统中开展业务；在尽可能减少开发工作量的情况下，由医院信息科自主设计一个小程序，将原HIS系统产生的费用信息通过接口（中间表或视图）提供给新HIS系统的收费终端，借用新HIS的收费终端实现电子发票接口。通过这种方式开拓出一个过渡期，直到新HIS实施后全面接管和替换。

业务分析与设计思路

在该过渡方案的设计中，我们将医院现运行的HIS系统定义为“A端系统”，将即将上线的新HIS系统定义为“C端系统”，将信息科开发的、负责处理A端和C端数据的程序定义为“B端系统”，整体业务流程如图1、图2所示。

在该方案中，需要将A端系统的患者信息、待缴费信息等同步到C端系统；由C端系统完成挂号、结算缴费、申请开据电子发票、打印凭证等工作；B端系统负责进行模拟操作，将需结算数据、清算数据、费用明细等转换并同步到C端数据库里，在C端进行结算后，再写入A端系统的业务数据表，保证A端系统的业务正常运转。

该方案存在双向数据流，B端系统承担着重要的桥梁与纽带作用，由信息科自行设计开发。同时还需要完成A端系统与C端系统“三目录”（诊疗项目目录、疾病目录、地方通用性药品目录等）的对照，同时C端系统还应完成与医保“三目录”的对照。

在这个过渡方案中，门诊挂号流程如图3所示。挂号业务通过C端系统完成，挂号数据存在C端数据库里；B端系统将C端挂号数据转换同步到A端系统数据库；A端系统的医生工作站和其他医技科室可正常进行院内其他业务操作。

为了减少对A端数据源的操作过程，减少回写业务量，C端的挂号收费业务就在C端系统进行日结操作，而不用回到A端系统进行日结。如图4所示。

门诊收费流程如图5所示。A端系统的医生工作站接诊、开单后，B端系统将开单数据转换并同步到C端数据库，C端系统的收费终端从数据库里抽取数据进行收费，并通过电子发票接口、医保接口进行开票和医保业务结算等。

住院流程如图6、图7所示。A端系统负责入院登记和预交金缴费，减少数据转换和同步过程中出现的数据失真概率；C端系统负责出院结算与电子发票开具等工作。在结算时，结算所需数据通过B端程序从A端抽取后进行转换，并同步到C端的业务表；C端结算完成后，B端系统先进行一次模拟结算操作，确定无误后将结算结果反向更新和插入到A端业务表；A端收费员进行日结。

系统设计及实施

确定业务流程与设计思路后，医院信息科开始设计B端系统。

1.主要功能设计

此处介绍几个主要环节的功能设计。

（1）模拟挂号（退号）程序

挂号主要涉及挂号主表（clinic_master）和患者主表（pat_master_index），挂号操作要在这两张表中写入数据，数据流向如图8所示。退号环节只需更新clinic_master中的RETURNED_DATE和RETURNED_OPERATOR字段，一个是退号日期，一个是退号员。

（2）模拟收费程序

根据数据流方向，A端系统医生工作站开单后，数据流向收费子系统；收费子系统收费后，将对应的收费标志修改为收费状态，药房子系统、检查检验划价子系统就能看到对应的项目信息；B端系统此时应将开单数据同步到C端中间表，C端进行收费操作后将收费明细传回收费结束中间表；B端从收费结束中间表取出数据，对A端系统进行模拟收费操作。如图9所示。

在该环节，先由A端医生工作站开单，通过划价视图vw_charge_schedule（患者ID，门诊号，挂号单据号，处方号，姓名，性别，年龄，序号，收入项目ID，从属父号，收费项目ID，付数，数量，单价，金额，病人科室ID，开单部门ID，执行部门ID，开单人，发生时间，登记时间，规格），提供给B端同步程序；B端从vw_charge_schedule中取出数据，将数据写入C端划价表，C端收费程序将数据从划价表中取出并写入自己的开单记录表中，执行收费操作。视图设计如图10所示。

其中，outp_orders有一个ASYNC_FLAG字段，作为是否同步标识，默认为空。当有新开单数据产生时，根据vw_charge_schedule设计条件，在视图中会有数据产生。当B端执行同步结束时，将该字段设为“1”，此时数据就不会在视图中出现。

C端系统执行收费结束后，将收费数据写入收费中间表，B端模拟收费程序将数据从收费中间表取出，再与A端数据进行组织整合后写入A端的业务表，主要过程如下所示：

①将exam_appoints（检查申请表）、lab_test_master（检验申请表）、OUTP_PRESC（药品处方表）、OUTP_TREAT_REC（治疗处置表）的收费标识设为“1”状态。

②将开单记录（OUTP_PRESC、OUTP_TREAT_REC、基础字典、中间表）的数据通过关联进行组合，写入到医院业务表，其中收费标识设为“1”，要写入的数据表主要有outp_rcpt_master（门诊收费主记录）、outp_bill_items（门诊收费明细记录）、drug_presc_master_temp（待发药主记录）、drug_presc_detail_temp（待发药明细记录）、fin_invoiceinfo_record（发票记录）等。

退费流程与收费流程类似：在对应的数据表中插入负记录，并将收费标识设为“2”，表示退费，并删除待发药主记录和待发药明细记录。

（3）模拟住院结算程序

如图11所示，由于住院登记业务、预交金管理是通过A端系统办理的，所以C端进行出院结算时，B端要将这些基础数据及费用明细同步到C端进行结算操作。C端完成结算后，需要将结算数据存入中间表，B端模拟结算程序再进行一次模拟结算，更新A端业务数据，从而保证A端数据正常。

2.实施过程

实施工作主要包括两部分内容：第一部分是A端与C端基础数据的核对和梳理，牵涉到基础字典的对码工作。此时需要分析，是直接使用A端数据替换C端数据，还是在对码后通过B端程序转换写入A端？具体要看哪种方式更能提高效率。笔者所在医院使用的是​后一种方式。

第二部分是B端同步程序和模拟程序的开发工作，这一工作主要由信息科负责完成，相当于重新开发一套A端系统的挂号收费及结算程序，只是减少了相应的接口验证。在有限时间内要完成这项工作，压力可想而知，不过只要梳理清楚业务逻辑和A端系统的数据库表结构，努点力加一下班，基本能在规定时间内完成。

在开发B端程序时，我们采用Visual Studio 2019 .net5 core作为开发平台，数据库采用Oracle11G作为数据及中间表的存储。

为了便于维护，我们采用三层逻辑架构进行代码组织，分别为实体层、服务层、数据访问层及基础或公共包。为了便于和数据表统一，实体层的每个实体名取名和数据表一致，每个实体对应一个表名，方便开发过程中的数据映射。服务层作为对实体的操作或动作，为了和实体对应，命名规则为实体名+service，表示操作或为对应的实体进行服务。

B端程序的最终界面效果如图12所示。由于该程序只是运行在后台，所有功能都是自动完成，不需要人工操作，只要开启实时监控就行，因此界面越简洁越好。

实施遇到的问题及解决方法

B端程序设计完成后，我们在实施过程中也遇到了一些问题，主要是因为前期对A端系统的业务逻辑与实现模式了解不到位，对数据流的流向分析与梳理不够彻底，对追踪其系统日志获取的业务流和数据流不够全面，导致在模拟收费过程中写入的数据不够全面，从而回溯多次，造成工期的延期和业务流向失败。

这些问题的暴露，通常是在向A端写入数据时引发了数据库报错。比如：在门诊发药业务中，通过跟踪日志，我们发现并没有写入待发药主表和待发药明细表中，也没有将收费标识进行更新，因此B端程序模拟收费后，药房发药列表找不到该患者的处方信息，检查或检验科室看不到待检查和待检验的患者数据。我们根据这些情况，反推数据表字段，不停“试探”一些关键字段的值来尝试业务状态。比如：检查申请表和检验申请表中的BILLING_INDICATOR字段，其默认值是0，表示未收费。如果不更改此值，检查科室就看不到该患者数据。我们根据经验判断，在收费时将值更新为“1”进行尝试，结果显示正常，那么退费情况我们尝试将值更新为“2”，结果显示正常。因此，可用同样方式解决该类所有问题。

又如药房发药，由于之前收费时触发了触发器，导致模拟收费失败，通过查询该触发器可禁用相应代码，但这段代码的作用是判断费用类型是否是药品，如果是药品，该触发器会将待发药处方明细写入待发药主表和待发药明细表，不需要手工方式写入。由于此前禁用了该段代码，就无法往这两个表中写入数据，导致发药数据异常。所以，我们又通过修改模拟收费代码，把数据成功写入这两张表中，解决门诊发药业务。

再如退费后材料或药品库存不会自动恢复的问题。经查询A端系统之前正常的数据，包括收费主表、收费明细表、待发药主表、待发药明细表、已发药主表、已发药明细表等，进行对正交易和负交易对比，最后发现是退费交易中收费明细表中“数量”这个字段不为负数引起的。通过修改B端程序代码后，成功解决该问题。

以上举例只是一些典型问题，在其他细节上，我们也遇到过很多问题并一一解决。

2020年底的一个周六，我们正式上线使用该方案。选择周末上线的目的是周末患者较少，出现问题后影响面小，能及时解决问题，不至于造成患者拥堵。

周六和周日运行后，系统基本趋于稳定。但毕竟周末患者量少，待到周一患者量增加，暴露出的问题就很明显。因此，C端系统公司和医院信息科加派人手到各收费窗口和医生诊室引导工作人员操作、收集系统问题，对于影响患者就诊的问题，即时查询后台数据库和业务逻辑进行修正和处理，保证患者就诊正常。对于院内数据异常问题，放在下班后和患者不多的时候，加班处理。

其中最为典型的问题有：

1.患者已交费，但A端系统相应子系统（如门诊发药子系统、检查检验确认子系统等）没有患者信息。

经查询，是医生在A端系统开完处方、点击提交或保存后，B端程序已将处方同步到C端，但医生觉得处方有问题，又删除了处方。此时B端程序并未检测到这一动作，C端系统完成收费后，A端无法进行模拟收费，相应系统没有收费记录。

解决方法是：A端和C端的数据库通过DBLINK建立触发器，只要A端有删除处方的动作，立即触发C端，判断是否完成收费：如果完成收费，则拒绝其删除；如果未完成收费，则C端同步删除，保证两边数据一致。

2.医生开单后，收费失败。

最开始发现此问题时，经查询是A端系统新增了收费项目，但是没有及时通知C端，C端未增加对应的收费项目名称，导致C端进行规则效验时失败，收费无法进行。

解决方法是：工程师发现问题后，第一时间手工将A端项目添加到C端，再进行医保对码，先让患者正常就诊。待非高峰期或下班后，采用DBLINK技术，A端有新增项目和医保对码时，自动触发将A端数据同步到C端，保证数据一致性。

3.特殊病种或慢病医保报销比例问题。

对于特殊病种或慢病的医保报销比例问题，经查询发现，A端视图中没有将特殊病种的编码传到C端，因此在C端进行结算时，直接取非特殊病种编码进行结算，导致报销比例错误。

解决方法是：在出现此问题时，工程师通过手工先应付解决，待下班后通过DBLINK，通过C端访问A端的处方信息，抽取并校验门诊特殊病种编码，从而解决特殊病种或慢病的报销问题。

以上问题比较典型。通过两天的试运行后，我们基本解决了这些问题；此后又运行及观察了一个星期左右的时间，基本没有发现新问题，系统趋于稳定。借助这一过渡方案，在确保完成电子票据的对接工作的同时，我们为医院整体信息化的实施争取了时间，保证整体信息化规划和顶层设计的科学性、完整性，为未来发展打下了坚实基础。

【作者简介】

陈昌齐，2009年7月毕业于贵州大学计算机科学与技术专业，现为贵阳市第四人民医院信息中心软件组组长。曾负责医院HIS、EMR、LIS、输血管理、一体化护理平台、重症监护、手术麻醉等系统实施及协调工作。独立完成医院相关信息系统的数据库表结构及数据字典文档的完善工作。

【责任编辑：陈曦】