Open wanghaisheng opened 5 years ago
2018年09月19日 12:51:12 东边的小山 阅读数：260
_BSHIS_在两年前就开始涉及医保软件接口的设计和实施了。随着时间的推移，越来越多的新签医院工程也要求实施医保；而一些以前上的老工程，也开始在实施各地的医保政策。可以说，医保的实施已经成为_HIS_软件在医院实施中一个很重要的组成部分。从某种意义上讲，医保实施的好坏也已经直接影响了工程实施的进度和效果。
由于医保政策的复杂性，再加上政策有很大的地区差异。在实施过程中，软件设计人员遇到了很多比较复杂也或者很难于解决的问题。另外，由于医保政策一般都是刚刚指定出来不久的。所以，在实施的过程中，经常会遇到修改政策的过程。这在一定程度上给软件设计和实施增加了不少的难度。同时，也会导致医保接口软件设计上的不确定性，直接的后果是可能导致很多的重复劳动。
结合前面很多人医保实施成功和失败的教训，对在医保接口设计过程中的，好的方法进行了归纳，并尽量给出一种比较完善和完美的设计解决方法和规范，可帮助医保实施和软件接口设计人员比较好地实施医保。当然，现在只是个草稿，需要医保实施实践不断地扩充此规范，以至形成一种比较固定的综合解决方案。
我们通过对北京安宁盈科、创智公司、东大阿儿派、杭州新世纪、建达电子、万达公司等各个医保险政策软件提供商提供的接口方案进行了分析，总计出他们之间的共性如下：
1、 一般都提供_DOS_和_WINDOWS_两套方案，_DOS_下一般用文件形式传递数据，_WINDOWS_下一般以_WIN32 API_的形式在_HIS_和医保前置机之间调用和传递数据（_DLL_提供了政策函数）。我们以后者为重点说明问题。
2、 政策函数一般分为两类：单个函数和多个函数两种类型设计
多个函数是指每中业务或者比较相似的业务为一个函数，这样组成结算、登记、退费等多个函数。如：杭州新世纪、东大阿儿派
单个函数是指所有的业务都用一个函数实现。参数一般用结构字符串实现。
如：上海万达公司。
3、 明细数据一般都和结算时必要的项目数据分开传递到医保中心服务器。这样做的目的是为了减少网络阻塞。如果是同时要传的，一般在结算准备阶段就已经将数据计算好了。
4、 平时发生费用时，一般分成两种方式处理：
1） 平时的自负比例按_HIS_中设置的算，也不需要审批
如：万达公司
2） 平时的自负比例不按_HIS_中设置的算，需要审批；需要维护标准的_HIS药品/_项目的对照表，并在对照表中设置比例。如：东大阿儿派，记费代码需修改。
5、 结算前一般都要刷卡，有些允许只在登记或者挂号的时候刷卡，结算时不刷卡，只要将必要的个人信息从_HIS_端保存的档中取即可。
6、结算分计算（准备）阶段和确认结算阶段两部分。
计算（准备）阶段：处理结算数据的上传或者调用结算计算函数获得医保支付信息，并获得自负金额，_HIS_端可据此结算和打印发票。
确认结算阶段：执行结算处理，和医保政策软件进行结算交易。
基于上面的分析和考虑，我们希望能够利用各个医保政策软件的共性，屏蔽其个性和特殊性、隔离_HIS_端业务和医保端业务。这样，对_HIS_端调用来说，调用的方式和接口是相同，有利于批量的实施和迎合医保险业务的多变性；减少_HIS_端程序的频繁修改和很大的后期维护量。所以，我们总的原则是：
1） 隔离_HIS_端业务和医保端业务：_HIS_端窗口和模块中，不要加入医保的处理过程，
但可以加入对象方法的数据准备和方法调用。这样可减少_HIS_端业务和医保端业务
的关联性，可适合批量医院上医保、各家医院程序又有客户化的情况。
2） 利用共性，屏蔽个性：尽量将_HIS_端该调用医保处理的位置、函数名称和步骤明确
化，规范化，避免不必要的重复劳动和差异程序维护。
3） 尽量减少调用医保的地方，或者在一个事件或者函数中集中处理，利于维护。
4） 调用方法参数用结构体或者DATAWINDOW，避免很多的参数。
5） 函数返回值类型单一化，就成功或者失败两种情况，其他的返回信息放在医保接口对象的实例结构体变量或者实例变量中。
入院或者挂号_(需要验证身份)_ _à_发生费用 à 结算
发生费用时处理：
有些医保需要个别项目进行审批，有些需要统一按标准目录取比例
这时需要_HIS药品/_项目和医保之间有个对照
如杭州医保就需要按上面的方法处理
有些医保则不需在发生费用时和医保有关，只是在结算时发送相关的大项目结算
金额就可以了。 如上海医保，无对单个项目的处理
结算的流程：
先身份验证 à 计算请求：结算前先获得费用支付结构
à 确认结算：发送确认交易命令，调用医保软件实现结算
退款的流程：
先身份验证 à 由_HIS_向医保政策软件发送退款需要的数据和请求命令
à 获得医保政策软件响应处理_HIS_业务
退款补结算的流程（指不是退全部款，而是新增或者退一部分）：
先身份验证 à 由_HIS_向医保政策软件发送退款和重新结算的数据和请求命令
门诊挂号（住院入院登记）处理：
在正式保存数据前，先调用医保政策提供商提供的函数验证，成功后，才保存
正式的挂号或者已登记人员（在返回时一般可从函数的返回值中获得病人的基本
信息，该信息保存在医保中心）
新增 yb_ybcl.pbl 放医保公用对象和数据；以后，只要替换此文件即实现医保变化。
新增医保处理基对象 u_ybcl_base（基础类，负责和医保的业务调用），医保处理对象 u_ybcl（业务类，负责从_HIS_端获得和准备数据，以及与_HIS_端的交互操作）。
_HIS_端调用对象_u_ybcl_的方法（函数和事件），并提供必要的参数信息。
4）要书写上了医保后的表结构变化记录和字段变化记录。
建议写成能直接执行的_SQL_语句，这样实施医保险的人，直接执行即可。避免让实施的人到_DBMS_上去修改。如，宁波医保的_SQL_如下：
字段添加请参考 《_bshis2.x宁波新医保___新增字段》 适用于 Sybase or MsSql
表的添加请参考 《_bshis2.x宁波新医保___新增表sybase》 适用于 Sybase 11 or later
或者 《_bshis2.x宁波新医保___新增表sql70》 适用于 Microsoft Sql Server
可让工程技术人员阅读，知道其上医保系统。最主要的
是说明“需要设置的基础数据”（包括了执行表结构修改和新增表的_SQL_语句）
如，可看《_bshis2.x宁波新医保__若干注意事项.txt_》
如：事件的命名规范为：
ue_mzgh_xxxx 门诊挂号相关的事件
ue_mzsf_xxxx 门诊收费相关的事件
ue_mztf_xxxx 门诊退费相关的事件
ue_zydj_xxxx 住院（入院）登记相关的事件
ue_zysf_xxxx 住院收费相关的事件
ue_zytf_xxxx 住院退费相关的事件
可让_HIS_端在计算自负金额和打印用，以及其他处理的时候用。
结算结果结构体中的信息有：自理金额、现金金额（就是自理金额_+_医保的现金支付部分）、本次结算总费用、结算后的帐户余额、其他必要的结算信息（如当前结算的类型等）、医保支付信息子结构体、各项目金额组成子机构体、个人信息子结构体等。具体需要多少信息可根据实际情况而定。
下面是医保的结构体实例变量的说明：
//====================================================================
// s_his_ybjsxx isu_ybjsxx 结算信息（可供_HIS_端打印发票是用）
integer ghsf 结算类型 _1_挂号_2_门诊_3住院-2门诊退费-3_住院退费
integer jsbz 结算方式 _0_普通_1_特病_2_家床
string jzbz 普通_/_急诊 _1_普通_2_急诊
yb_ybfymx fymx 项目费用信息（在预结算时产生）
decimal {2} zjje 当前结算费用总额
decimal {2} fyje[100] 按医保归并得到的项目金额
... 其他需要的项目费用数据
yb_ybzfxx zfmx 支付结构（预结算后得到）子结构体
（因为各个地区医保不同，内部项目具体命名可到时候实施的时候再修改）
decimal {2} grzhzf 个人帐户支付
decimal {2} gbjjzf 公补基金支付
decimal {2} tczf 统筹支付
decimal {2} jzzf 救助支付
decimal {2} xjzf 医保现金支付
decimal {2} qfdzhzf 起付段帐户支付
decimal {2} qfdgbzf 起付段公补支付
decimal {2} qfdxjzf 起付段现金支付
decimal {2} tcdzhzf 统筹段帐户支付
decimal {2} tcdgbzf 统筹段公补支付
decimal {2} tcdxjzf 统筹段现金支付
decimal {2} jzdzhzf 救助段帐户支付
decimal {2} jzdgbzf 救助段公补支付
decimal {2} jzdxjzf 救助段现金支付
decimal {2} xjzfa 现金支付A
decimal {2} xjzfb 现金支付B
decimal {2} xjzfc 现金支付C
decimal {2} grzhye 进行了当前结算后的帐户余额
decimal {2} tfxjje 退费现金（_<0退 >0_补交），退费时用；一般不建议退费，而用隔日作废后重新结算
decimal {2} zjje 当前结算的总计金额
decimal {2} qzlje 当前结算的全自理金额
decimal {2} xjzf 当前结算的医保现金金额
decimal {2} xjje 当前结算的全部现金金额 = 当前结算的全自理金额 + 当前结算的医保现金金额
decimal {2} zhye 进行了当前结算后的帐户余额
string tsbbm 特病代码（不是特病结算无意义）
string zcyydm 转目标医院代码（不是转院结算无意义）
// s_his_jbxx isu_jbxx 病人基本信息（刷卡后获得）
string knxx 卡内信息
string brkh 病人卡号
string bxhm 保险号码
yb_ybgrxx grxx 个人信息子结构体
string brxm 病人姓名
string sfzh 身份证号
string zhbz 帐户标志
string dwdm 单位编码
string qxdm 区县代码
integer brnl 年龄
integer brxb 性别
string djbz 冻结状态 _0_未冻结 _1_已冻结
datetime csny 出生年月
decimal {2} zhye 帐户余额
... 其他项目可根据实际情况添加
integer bz -1 表示刷卡未成功 否则成功
若返回值有很多的信息，建议放在对象的结构体实例变量中。_HIS_端要用的时候，再访问这个结构体实例变量即可。
成功_/_失败两种情况，其他的返回信息放在医保接口对象的实例结构体变量或者实例变量中。
如：return integer = 1 成功 –1 失败，对象的 is_errortext 变量保存了错误信息。
这样避免不必要的看到很多的函数或者事件，也搞不清楚哪些是内部调用的，哪些是外部调用的，不易于程序维护和代码修改。
另外，注释一定要写的详细，注释的风格请参考_BHIS2.2_住院系统的风格。
主要是代码中，要做阶段性的注释。每个块做写什么。这样，有利于整理看懂代码。
需要继承的窗口有：结算确认窗口：w_hjsf_jscl （门诊确认）
w_ghcl_jkcl （门诊挂号确认）
w_zy_jsgl_jscl （住院结算确认）
窗口命名方法，一般以： w_yb_xx_xxxx 或者： w_xx_xxxx_yb
一般在祖先窗口中定义事件的调用次序，而在继承的医保的窗口中，重载该事件。
如果是HIS2.21 或者以后的版本，住院系统一般用原来系统中的医保预留事件的定义。
门诊系统到现在为止，一直没有医保预留事件，需要按下面的方式定义：
下面的事件都是窗口事件，不是按钮或者是_DATAWINDOW_的事件。
事件：ue_Pre_Dispose()，RETURN BOOLEAN
预结算事件，用于医保结算请求费用计算
事件：ue_Before_Dispose()，RETURN BOOLEAN
在_HIS_的 _gf_begin_transaction(sqlca)_前做的工作
事件：ue_On_Dispose()，RETURN BOOLEAN
在_HIS_的 _gf_begin_transaction(sqlca)_后
在_gf_commit_transaction(sqlca)_前做的工作
事件：ue_After_Dispose()，RETURN BOOLEAN
在_HIS_的_gf_commit_transaction(sqlca)_后做的工作
至于到底是在ue_Before_Dispose()，还是在ue_On_Dispose()，还是在
_ue_After_Dispose()_中处理医保代码，一般需要根据实际情况而定。
以上三个事件，祖先的初始代码是：RETURN TRUE
在继承的医保的窗口中，才实现具体的代码。
下面已_BHIS2.21_的门诊系统的门诊收费确认窗口的修改说明：
门诊系统：w_hjsf_jscl****：结算确认窗口修改****
1）新增实例变量string is_errortext
2）新增窗口事件 ue_Pre_Dispose、ue_Before_Dispose、ue_On_Dispose，return boolean
三个事件的中，都增加 RETURN TRUE
3）EVENT：OPEN：修改如下：
。。。。。。。
IF NOT event ue_Pre_Dispose() then
_messagebox('提示', is_errortext)_
gs_exchange.longparm[1]=-1
close(this)
return
end if
_id_yshj=iw_hjsf.id_prefyhj+round(id_qtje,iw_hjsf.ii_decnum) //应收合计\=上次未收+_本次合计
sle_zjje.text=string(id_zjje,"0.00")
。。。。。。。。。
3）EVENT：cb_ok.chicked 修改如下：
IF NOT event ue_Before_Dispose() then
_if not iw_hjsf.wf_save(il_jkfs,id_zhje,id_qtje) then //_保存单据
gf_rollback_transaction(sqlca)
iw_hjsf.id_fyhj = iw_hjsf.id_prefyhj
_messagebox("提示","保存数据出错,本次收费无效!")_
else
IF NOT event ue_On_Dispose() then
gf_commit_transaction(sqlca)
IF NOT event ue_After_Dispose() then
iw_hjsf.wf_ResetUpdate()
debugbreak()
_wf_create_fp() //_生成发票信息并打印
sle_pay.setfocus()
门诊系统：继承w_hjsf_jscl 得 w_yb_hjsf_jscl****，存在 mz_ybcl.pbl 中，然后做后面的修改****
1）在界面中，新增DATAWINDOW DW_YBJSXX，DATAOBJECT = “d_yb_jsxx”
并调整界面为下面的样子：
2）重载窗口EVENT ue_Pre_Dispose，增下面的代码：
// Script - ue_pre_dispose for w_yb_hjsf_jscl inherited from w_hjsf_jscl
// Description: 医保预结算
// Returns: (BOOLEAN)
// Author: LIQW Date: 2002.03.14
ib_ifyb = gu_ybcl.uf_ifyb(iw_hjsf.is_mzxx.id, 1)
IF NOT ib_ifyb THEN RETURN TRUE
_//_预结算数据准备
gsu_mzjsxx.jsrq = gf_server_date() // 结算日期
gsu_mzjsxx.czgh = base_info.userid // 操作工号
gsu_mzjsxx.brid = iw_hjsf.is_mzxx.id // 病人的_ID_编号
gsu_mzjsxx.mzhm = iw_hjsf.is_mzxx.mzhm // 病人的门诊号码
gsu_mzjsxx.fphm = iw_hjsf.st_fphm.text // 发票号码
gsu_mzjsxx.dw_cf02 = iw_hjsf.dw_cf02 // 处方数据源
gsu_mzjsxx.dw_yj02 = iw_hjsf.dw_yj02 // 检查单数据源
_gsu_mzjsxx.dw_sfxm = iw_hjsf.dw_sfmx // HIS_中的项目金额
gsu_mzjsxx.dw_ybjsxx = dw_ybjsxx // 医保结算信息返回
gsu_mzjsxx.ghgl = iw_hjsf.is_mzxx.ghgl // 挂号关联
_//_调用医保支持对象预结算函数
if gu_ybcl.trigger event ue_mzsf_yjs(gsu_mzjsxx) <> 1 then
is_errortext = gu_ybcl.is_errortext
return FALSE
_//_预结算后取结算信息
id_zhje = 0
id_qtje = gu_ybcl.isu_ybjsxx.xjje
RETURN TRUE
3）重载窗口EVENT ue_Before_Dispose，增下面的代码：
// Description: 处理医保的结算
if ib_ifyb then
gf_begin_transaction(sqlca)
if gu_ybcl.trigger event ue_mzsf_js() <> 1 then
以前，很多地方的医保在开始做的时候，没有认真考虑此问题。很有可能导致到时候做报表的时候，数据不一致。一般将医保的业务放在_HIS_业务最后一条即_commit_之前。先做好_HIS_所有的业务，再做医保的业务。这样有个好处，万一医保失败了我们可以回滚_HIS_业务。
如果医保的业务可能需要很长的时间，我们不能用两个事务一致的控制方法。一般先做好_HIS_的所有的业务并提交。然后在打发票前处理医保的业务，若失败则自动作废_HIS_业务，而不是回滚事务（这时_HIS_业务已提交）。湖州医保就是这样做的，可参考。
而应该全部封装在医保支持对象中。这样可充分隔离_HIS_端的处理和医保端的处理。
以便统一修改程序和版本维护。
判断是不是医保病人：通过传入病人唯一编号来判断
此函数一般用在进行业务处理前，判断接下来的业务是不是要进行医保处理
判断是否为医保病人, al_byh： 门诊病人用 MS_BRDA.ID 住院病人用 zyh
al_lb =1 门诊 = 2 住院
return true 是 false 不是
判断是不是医保病人：通过传入病人性质来判断
判断是否为医保病人, al_brxz：病人性质
初始化数据，一般用于处理医保接口支持对象的初始数据准备
参数：ai_xtsb，系统识别，\= base_info.syscode
对象的is_errortext 实例变量，保存了失败信息
一般业务库和医保接口_DATABASE_都连接了事物后调用，比如设置了base_info 信息后，在打开业务窗口前调用
return true 初始化成功
_return false_初始化失败，一般_HIS_调用的地方，就应该终止程序了。
获得病人信息，一般指刷卡的过程。分门诊挂号（包括挂号、退号）、门诊结算（包括收费、作废、退费）、住院登记（登记、注销）、住院结算（包括结算、作废、退费）等地方都要调用。也可在此函数中处理应急医保（即在医保中心联系不上的情况下，在本地完成大致的医保的结算计算和结算，到时候再到医保中心手工处理报销，宁波医保有应急处理）。
参数：al_byh 病员号 门诊为 MS_BRDA.ID 住院为 ZY_BRRY.ZYH****
当ai_mode = 0 and ai_sflx=1****时设置为 0****
ai_sflx **收费类型 1**挂号 2****门诊 3****住院****
ai_mode **使用场合和方式 0**挂号或者入院登记建立档案时用****
1****收费结算或者挂号 2****退费 –1****作废结算或者退号****
其他必要设置的参数：idw_hisdata 设置为必要传参数的DATAWINDOW
有时候同时起到回填数据的功能
return 1 成功 –1 失败
下面是几种常见的使用场合：
住院登记：al_byh = 0 ai_sflx = 3 ai_mode = 0
在入院登记窗口中，新增“医保”按钮，并处理刷卡和获得基本数据。
挂号建档：al_byh = 0 ai_sflx = 1 ai_mode = 0
门诊病人建立新档案时调用。如：w_mzgh_new
建议新增“医保”按钮，统一处理医保病人的档案建立和刷卡过程。
挂号： al_byh = ID ai_sflx = 1 ai_mode = 1
一般在挂号模块中选定了病人后，要选挂号科室前调用。
退号： al_byh = ID ai_sflx = 1 ai_mode = -1
进行退号确认时调用
门诊收费：al_byh = ID ai_sflx = 2 ai_mode = 1
选择了病人后，进入收费结算主界面前，一般在 w_hjsf_mzxx“确定”按钮
门诊作废：al_byh = ID ai_sflx = 2 ai_mode = -1
进行作废确认时调用
门诊退费：al_byh = ID ai_sflx = 2 ai_mode = 2
选择了病人后，在进行退费操作前
也可以在进行确认结算前，如：_w_tfcl_的“确认”按钮中
住院结算：al_byh = ZYH ai_sflx = 3 ai_mode = 1
住院作废：al_byh = ZYH ai_sflx = 3 ai_mode = -1
住院退费：al_byh = ZYH ai_sflx = 3 ai_mode = 2
此功能一般在_BSHIS2.1_中使用，在_BSHIS2.21_以上的版本中，一般建议使用隔
日作废功能。
住院入院登记\__保存档案，处理向医保前置机发登记请求
其他必要设置的参数：idw_hisdata 在这里做入院登记的DATAWINDOW，用于参数传递
一般在入院登记窗口中，“确定”按钮中处理
住院入院注销\__撤消档案，处理向医保前置机发登记请求
一般在住院病人基本信息维护，处理注销病人的“确定”按钮中处理
住院预结算，在调用前，先给对象的_isu_zyjsxx_结构体变量赋值。
isu_zyjsxx 结算信息必要的结构体变量，具体内容（如zyh、jscs、jsrq、_czgh_等）根据实际需要而定。建议将结算界面中的项目_DATAWINDOW_传入以便结算。
一般在结算确认窗口的_OPEN_事件中调用，处理医保病人费用支付的计算，也即执行医保的计算请求。
住院结算
一般在结算确认窗口“确认”按钮的事件中调用。
住院结算发票作废，在调用前，先给对象的_isu_zyjsxx_结构体变量赋值。
isu_zyjsxx 作废结算信息必要的结构体变量，具体内容（如zyh、jsrq、_czgh_等）根据实际需要而定。
一般在结算窗口作废“确认”按钮的事件中调用。
门诊挂号\__预结算，在调用前，先给对象的_isu_mzghxx_结构体变量赋值。
isu_mzghxx 结算信息必要的结构体变量，具体内容（如fphm、id、jsrq、czgh、挂号项目数据信息等）根据实际需要而定。
一般在挂号结算确认窗口的_OPEN_事件中调用，处理医保病人费用支付的计算，也即执行医保的计算请求。
挂号确认结算
参数：adw_ghxx 挂号信息窗口，一般为 w_ghcl.dw_ghxx
一般在挂号结算更新数据表时调用。
门诊退号，在调用前，先给对象的_isu_mzghxx_结构体变量赋值。
isu_mzghxx 作废必要的结构体变量，具体内容（如id、jsrq、czgh、_sbxh_等）根据实际需要而定。
一般在退号窗口“确认”按钮的事件中调用。
门诊预结算，在调用前，先给对象的_isu_mzjsxx_结构体变量赋值。
isu_mzjsxx 结算信息必要的结构体变量，具体内容（如fphm、id、jsrq、_czgh_等）根据实际需要而定。建议将结算界面中的项目_DATAWINDOW_传入以便结算，同时用_DATAWINDOW_的形式传入_CF02_和_YJ02_的内容，以便结算费用信息。
门诊确认结算
一般在确认结算确认窗口“确认”按钮的事件中调用。
门诊发票作废，在调用前，先给对象的_isu_mzjsxx_结构体变量赋值。
isu_mzjsxx 作废结算信息必要的结构体变量，具体内容（如id、fphm、jsrq、_czgh_等）根据实际需要而定。
一般在作废发票窗口的“确认”按钮的事件中调用。
门诊退费预结算，在调用前，先给对象的_isu_mzjsxx_结构体变量赋值。
_isu_mzjsxx_必要的结构体变量，具体内容（如有效的_CFSB_数组、_YJXH_数组、tphm、fphm、id、jsrq、_czgh_等）根据实际需要而定。
一般在退费结算确认窗口的_OPEN_事件中调用，处理医保病人退费的必要的数据准备。
门诊退费确认结算
一般在退费确认结算确认窗口“确认”按钮的事件中调用。
HIS医保接口设计规范
2018年09月19日 12:51:12 东边的小山 阅读数：260
一、导言
_BSHIS_在两年前就开始涉及医保软件接口的设计和实施了。随着时间的推移，越来越多的新签医院工程也要求实施医保；而一些以前上的老工程，也开始在实施各地的医保政策。可以说，医保的实施已经成为_HIS_软件在医院实施中一个很重要的组成部分。从某种意义上讲，医保实施的好坏也已经直接影响了工程实施的进度和效果。
由于医保政策的复杂性，再加上政策有很大的地区差异。在实施过程中，软件设计人员遇到了很多比较复杂也或者很难于解决的问题。另外，由于医保政策一般都是刚刚指定出来不久的。所以，在实施的过程中，经常会遇到修改政策的过程。这在一定程度上给软件设计和实施增加了不少的难度。同时，也会导致医保接口软件设计上的不确定性，直接的后果是可能导致很多的重复劳动。
结合前面很多人医保实施成功和失败的教训，对在医保接口设计过程中的，好的方法进行了归纳，并尽量给出一种比较完善和完美的设计解决方法和规范，可帮助医保实施和软件接口设计人员比较好地实施医保。当然，现在只是个草稿，需要医保实施实践不断地扩充此规范，以至形成一种比较固定的综合解决方案。
二、关于医保政策软件和应对方案
我们通过对北京安宁盈科、创智公司、东大阿儿派、杭州新世纪、建达电子、万达公司等各个医保险政策软件提供商提供的接口方案进行了分析，总计出他们之间的共性如下：
1、 一般都提供_DOS_和_WINDOWS_两套方案，_DOS_下一般用文件形式传递数据，_WINDOWS_下一般以_WIN32 API_的形式在_HIS_和医保前置机之间调用和传递数据（_DLL_提供了政策函数）。我们以后者为重点说明问题。
2、 政策函数一般分为两类：单个函数和多个函数两种类型设计
多个函数是指每中业务或者比较相似的业务为一个函数，这样组成结算、登记、退费等多个函数。如：杭州新世纪、东大阿儿派
单个函数是指所有的业务都用一个函数实现。参数一般用结构字符串实现。
如：上海万达公司。
3、 明细数据一般都和结算时必要的项目数据分开传递到医保中心服务器。这样做的目的是为了减少网络阻塞。如果是同时要传的，一般在结算准备阶段就已经将数据计算好了。
4、 平时发生费用时，一般分成两种方式处理：
1） 平时的自负比例按_HIS_中设置的算，也不需要审批
如：万达公司
2） 平时的自负比例不按_HIS_中设置的算，需要审批；需要维护标准的_HIS药品/_项目的对照表，并在对照表中设置比例。如：东大阿儿派，记费代码需修改。
5、 结算前一般都要刷卡，有些允许只在登记或者挂号的时候刷卡，结算时不刷卡，只要将必要的个人信息从_HIS_端保存的档中取即可。
6、结算分计算（准备）阶段和确认结算阶段两部分。
计算（准备）阶段：处理结算数据的上传或者调用结算计算函数获得医保支付信息，并获得自负金额，_HIS_端可据此结算和打印发票。
确认结算阶段：执行结算处理，和医保政策软件进行结算交易。
基于上面的分析和考虑，我们希望能够利用各个医保政策软件的共性，屏蔽其个性和特殊性、隔离_HIS_端业务和医保端业务。这样，对_HIS_端调用来说，调用的方式和接口是相同，有利于批量的实施和迎合医保险业务的多变性；减少_HIS_端程序的频繁修改和很大的后期维护量。所以，我们总的原则是：
1） 隔离_HIS_端业务和医保端业务：_HIS_端窗口和模块中，不要加入医保的处理过程，
但可以加入对象方法的数据准备和方法调用。这样可减少_HIS_端业务和医保端业务
的关联性，可适合批量医院上医保、各家医院程序又有客户化的情况。
2） 利用共性，屏蔽个性：尽量将_HIS_端该调用医保处理的位置、函数名称和步骤明确
化，规范化，避免不必要的重复劳动和差异程序维护。
3） 尽量减少调用医保的地方，或者在一个事件或者函数中集中处理，利于维护。
4） 调用方法参数用结构体或者DATAWINDOW，避免很多的参数。
5） 函数返回值类型单一化，就成功或者失败两种情况，其他的返回信息放在医保接口对象的实例结构体变量或者实例变量中。
三、医保接口规范
1、医保病人结算的一般流程
入院或者挂号_(需要验证身份)_ _à_发生费用 à 结算
发生费用时处理：
有些医保需要个别项目进行审批，有些需要统一按标准目录取比例
这时需要_HIS药品/_项目和医保之间有个对照
如杭州医保就需要按上面的方法处理
有些医保则不需在发生费用时和医保有关，只是在结算时发送相关的大项目结算
金额就可以了。 如上海医保，无对单个项目的处理
结算的流程：
先身份验证 à 计算请求：结算前先获得费用支付结构
à 确认结算：发送确认交易命令，调用医保软件实现结算
退款的流程：
先身份验证 à 由_HIS_向医保政策软件发送退款需要的数据和请求命令
à 获得医保政策软件响应处理_HIS_业务
退款补结算的流程（指不是退全部款，而是新增或者退一部分）：
先身份验证 à 由_HIS_向医保政策软件发送退款和重新结算的数据和请求命令
à 获得医保政策软件响应处理_HIS_业务
门诊挂号（住院入院登记）处理：
在正式保存数据前，先调用医保政策提供商提供的函数验证，成功后，才保存
正式的挂号或者已登记人员（在返回时一般可从函数的返回值中获得病人的基本
信息，该信息保存在医保中心）
2、在程序设计中应该遵循的原则
1）保证医保处理业务和_HIS_处理业务隔离开
新增 yb_ybcl.pbl 放医保公用对象和数据；以后，只要替换此文件即实现医保变化。
新增医保处理基对象 u_ybcl_base（基础类，负责和医保的业务调用），医保处理对象 u_ybcl（业务类，负责从_HIS_端获得和准备数据，以及与_HIS_端的交互操作）。
_HIS_端调用对象_u_ybcl_的方法（函数和事件），并提供必要的参数信息。
2）若有医院和标准业务不同，请从 u_ybcl 对象继承
3）需要修改 u_nbcl 对象和yb_ybcl.pbl，请在修改后，覆盖所有使用该_PBL_的地方，保持版本的统一，避免不必要的版本不相同而导致不能充分地共享代码。
4）要书写上了医保后的表结构变化记录和字段变化记录。
建议写成能直接执行的_SQL_语句，这样实施医保险的人，直接执行即可。避免让实施的人到_DBMS_上去修改。如，宁波医保的_SQL_如下：
字段添加请参考 《_bshis2.x宁波新医保___新增字段》 适用于 Sybase or MsSql
表的添加请参考 《_bshis2.x宁波新医保___新增表sybase》 适用于 Sybase 11 or later
或者 《_bshis2.x宁波新医保___新增表sql70》 适用于 Microsoft Sql Server
5）需要书写必要的注意事项，以便实施。
可让工程技术人员阅读，知道其上医保系统。最主要的
是说明“需要设置的基础数据”（包括了执行表结构修改和新增表的_SQL_语句）
如，可看《_bshis2.x宁波新医保__若干注意事项.txt_》
6）代码中，对象的函数和事件命名要统一和规范化。
如：事件的命名规范为：
ue_mzgh_xxxx 门诊挂号相关的事件
ue_mzsf_xxxx 门诊收费相关的事件
ue_mztf_xxxx 门诊退费相关的事件
ue_zydj_xxxx 住院（入院）登记相关的事件
ue_zysf_xxxx 住院收费相关的事件
ue_zytf_xxxx 住院退费相关的事件
7）医保对象中，提供结算结果、个人信息结构体等必要的实例变量（即对象属性）。
可让_HIS_端在计算自负金额和打印用，以及其他处理的时候用。
结算结果结构体中的信息有：自理金额、现金金额（就是自理金额_+_医保的现金支付部分）、本次结算总费用、结算后的帐户余额、其他必要的结算信息（如当前结算的类型等）、医保支付信息子结构体、各项目金额组成子机构体、个人信息子结构体等。具体需要多少信息可根据实际情况而定。
下面是医保的结构体实例变量的说明：
//====================================================================
// s_his_ybjsxx isu_ybjsxx 结算信息（可供_HIS_端打印发票是用）
//====================================================================
integer ghsf 结算类型 _1_挂号_2_门诊_3住院-2门诊退费-3_住院退费
integer jsbz 结算方式 _0_普通_1_特病_2_家床
string jzbz 普通_/_急诊 _1_普通_2_急诊
yb_ybfymx fymx 项目费用信息（在预结算时产生）
decimal {2} zjje 当前结算费用总额
decimal {2} fyje[100] 按医保归并得到的项目金额
... 其他需要的项目费用数据
yb_ybzfxx zfmx 支付结构（预结算后得到）子结构体
（因为各个地区医保不同，内部项目具体命名可到时候实施的时候再修改）
decimal {2} grzhzf 个人帐户支付
decimal {2} gbjjzf 公补基金支付
decimal {2} tczf 统筹支付
decimal {2} jzzf 救助支付
decimal {2} xjzf 医保现金支付
decimal {2} qfdzhzf 起付段帐户支付
decimal {2} qfdgbzf 起付段公补支付
decimal {2} qfdxjzf 起付段现金支付
decimal {2} tcdzhzf 统筹段帐户支付
decimal {2} tcdgbzf 统筹段公补支付
decimal {2} tcdxjzf 统筹段现金支付
decimal {2} jzdzhzf 救助段帐户支付
decimal {2} jzdgbzf 救助段公补支付
decimal {2} jzdxjzf 救助段现金支付
decimal {2} xjzfa 现金支付A
decimal {2} xjzfb 现金支付B
decimal {2} xjzfc 现金支付C
decimal {2} grzhye 进行了当前结算后的帐户余额
decimal {2} tfxjje 退费现金（_<0退 >0_补交），退费时用；一般不建议退费，而用隔日作废后重新结算
decimal {2} zjje 当前结算的总计金额
decimal {2} qzlje 当前结算的全自理金额
decimal {2} xjzf 当前结算的医保现金金额
decimal {2} xjje 当前结算的全部现金金额 = 当前结算的全自理金额 + 当前结算的医保现金金额
decimal {2} zhye 进行了当前结算后的帐户余额
string tsbbm 特病代码（不是特病结算无意义）
string zcyydm 转目标医院代码（不是转院结算无意义）
//====================================================================
// s_his_jbxx isu_jbxx 病人基本信息（刷卡后获得）
//====================================================================
string knxx 卡内信息
string brkh 病人卡号
string bxhm 保险号码
yb_ybgrxx grxx 个人信息子结构体
string brxm 病人姓名
string sfzh 身份证号
string zhbz 帐户标志
string dwdm 单位编码
string qxdm 区县代码
integer brnl 年龄
integer brxb 性别
string djbz 冻结状态 _0_未冻结 _1_已冻结
datetime csny 出生年月
decimal {2} zhye 帐户余额
... 其他项目可根据实际情况添加
integer bz -1 表示刷卡未成功 否则成功
8）调用方法参数用结构体或者DATAWINDOW，避免很多的参数。
若返回值有很多的信息，建议放在对象的结构体实例变量中。_HIS_端要用的时候，再访问这个结构体实例变量即可。
9）函数返回值类型单一化。
成功_/_失败两种情况，其他的返回信息放在医保接口对象的实例结构体变量或者实例变量中。
如：return integer = 1 成功 –1 失败，对象的 is_errortext 变量保存了错误信息。
10）对象内部之间调用，一般用对象的函数实现；供外部调用的，一般用对象事件实现。
这样避免不必要的看到很多的函数或者事件，也搞不清楚哪些是内部调用的，哪些是外部调用的，不易于程序维护和代码修改。
11）代码书写风格请参考公司相关的开发文档。
另外，注释一定要写的详细，注释的风格请参考_BHIS2.2_住院系统的风格。
主要是代码中，要做阶段性的注释。每个块做写什么。这样，有利于整理看懂代码。
12）一般不直接在原来的_HIS_代码上嵌入医保，需要定义事件和使用对象继承。
需要继承的窗口有：结算确认窗口：w_hjsf_jscl （门诊确认）
w_ghcl_jkcl （门诊挂号确认）
w_zy_jsgl_jscl （住院结算确认）
窗口命名方法，一般以： w_yb_xx_xxxx 或者： w_xx_xxxx_yb
一般在祖先窗口中定义事件的调用次序，而在继承的医保的窗口中，重载该事件。
如果是HIS2.21 或者以后的版本，住院系统一般用原来系统中的医保预留事件的定义。
门诊系统到现在为止，一直没有医保预留事件，需要按下面的方式定义：
下面的事件都是窗口事件，不是按钮或者是_DATAWINDOW_的事件。
事件：ue_Pre_Dispose()，RETURN BOOLEAN
预结算事件，用于医保结算请求费用计算
事件：ue_Before_Dispose()，RETURN BOOLEAN
在_HIS_的 _gf_begin_transaction(sqlca)_前做的工作
事件：ue_On_Dispose()，RETURN BOOLEAN
在_HIS_的 _gf_begin_transaction(sqlca)_后
在_gf_commit_transaction(sqlca)_前做的工作
事件：ue_After_Dispose()，RETURN BOOLEAN
在_HIS_的_gf_commit_transaction(sqlca)_后做的工作
至于到底是在ue_Before_Dispose()，还是在ue_On_Dispose()，还是在
_ue_After_Dispose()_中处理医保代码，一般需要根据实际情况而定。
以上三个事件，祖先的初始代码是：RETURN TRUE
在继承的医保的窗口中，才实现具体的代码。
下面已_BHIS2.21_的门诊系统的门诊收费确认窗口的修改说明：
门诊系统：w_hjsf_jscl****：结算确认窗口修改****
1）新增实例变量string is_errortext
2）新增窗口事件 ue_Pre_Dispose、ue_Before_Dispose、ue_On_Dispose，return boolean
三个事件的中，都增加 RETURN TRUE
3）EVENT：OPEN：修改如下：
。。。。。。。
IF NOT event ue_Pre_Dispose() then
_messagebox('提示', is_errortext)_
gs_exchange.longparm[1]=-1
close(this)
return
end if
_id_yshj=iw_hjsf.id_prefyhj+round(id_qtje,iw_hjsf.ii_decnum) //应收合计\=上次未收+_本次合计
sle_zjje.text=string(id_zjje,"0.00")
。。。。。。。。。
3）EVENT：cb_ok.chicked 修改如下：
。。。。。。。
IF NOT event ue_Before_Dispose() then
_messagebox('提示', is_errortext)_
return
end if
_if not iw_hjsf.wf_save(il_jkfs,id_zhje,id_qtje) then //_保存单据
gf_rollback_transaction(sqlca)
iw_hjsf.id_fyhj = iw_hjsf.id_prefyhj
_messagebox("提示","保存数据出错,本次收费无效!")_
else
IF NOT event ue_On_Dispose() then
gf_rollback_transaction(sqlca)
_messagebox('提示', is_errortext)_
return
end if
gf_commit_transaction(sqlca)
IF NOT event ue_After_Dispose() then
_messagebox('提示', is_errortext)_
return
end if
iw_hjsf.wf_ResetUpdate()
debugbreak()
_wf_create_fp() //_生成发票信息并打印
end if
sle_pay.setfocus()
门诊系统：继承w_hjsf_jscl 得 w_yb_hjsf_jscl****，存在 mz_ybcl.pbl 中，然后做后面的修改****
1）在界面中，新增DATAWINDOW DW_YBJSXX，DATAOBJECT = “d_yb_jsxx”
并调整界面为下面的样子：
2）重载窗口EVENT ue_Pre_Dispose，增下面的代码：
// Script - ue_pre_dispose for w_yb_hjsf_jscl inherited from w_hjsf_jscl
// Description: 医保预结算
// Returns: (BOOLEAN)
// Author: LIQW Date: 2002.03.14
ib_ifyb = gu_ybcl.uf_ifyb(iw_hjsf.is_mzxx.id, 1)
IF NOT ib_ifyb THEN RETURN TRUE
//====================================================================
_//_预结算数据准备
//====================================================================
gsu_mzjsxx.jsrq = gf_server_date() // 结算日期
gsu_mzjsxx.czgh = base_info.userid // 操作工号
gsu_mzjsxx.brid = iw_hjsf.is_mzxx.id // 病人的_ID_编号
gsu_mzjsxx.mzhm = iw_hjsf.is_mzxx.mzhm // 病人的门诊号码
gsu_mzjsxx.fphm = iw_hjsf.st_fphm.text // 发票号码
gsu_mzjsxx.dw_cf02 = iw_hjsf.dw_cf02 // 处方数据源
gsu_mzjsxx.dw_yj02 = iw_hjsf.dw_yj02 // 检查单数据源
_gsu_mzjsxx.dw_sfxm = iw_hjsf.dw_sfmx // HIS_中的项目金额
gsu_mzjsxx.dw_ybjsxx = dw_ybjsxx // 医保结算信息返回
gsu_mzjsxx.ghgl = iw_hjsf.is_mzxx.ghgl // 挂号关联
//====================================================================
_//_调用医保支持对象预结算函数
//====================================================================
if gu_ybcl.trigger event ue_mzsf_yjs(gsu_mzjsxx) <> 1 then
is_errortext = gu_ybcl.is_errortext
return FALSE
else
//====================================================================
_//_预结算后取结算信息
//====================================================================
id_zhje = 0
id_qtje = gu_ybcl.isu_ybjsxx.xjje
end if
RETURN TRUE
3）重载窗口EVENT ue_Before_Dispose，增下面的代码：
// Script - ue_pre_dispose for w_yb_hjsf_jscl inherited from w_hjsf_jscl
// Description: 处理医保的结算
// Returns: (BOOLEAN)
// Author: LIQW Date: 2002.03.14
if ib_ifyb then
gf_begin_transaction(sqlca)
if gu_ybcl.trigger event ue_mzsf_js() <> 1 then
gf_rollback_transaction(sqlca)
is_errortext = gu_ybcl.is_errortext
return FALSE
end if
end if
RETURN TRUE
13）务必保持两个事务的一致性。
以前，很多地方的医保在开始做的时候，没有认真考虑此问题。很有可能导致到时候做报表的时候，数据不一致。一般将医保的业务放在_HIS_业务最后一条即_commit_之前。先做好_HIS_所有的业务，再做医保的业务。这样有个好处，万一医保失败了我们可以回滚_HIS_业务。
如果医保的业务可能需要很长的时间，我们不能用两个事务一致的控制方法。一般先做好_HIS_的所有的业务并提交。然后在打发票前处理医保的业务，若失败则自动作废_HIS_业务，而不是回滚事务（这时_HIS_业务已提交）。湖州医保就是这样做的，可参考。
14）医保对象和前置机的交互方式和实现方法一般不让_HIS_端的程序来处理和实现。
而应该全部封装在医保支持对象中。这样可充分隔离_HIS_端的处理和医保端的处理。
15）其他和医保相关的处理，如：药品审批、用药限制等最好都放在医保的对象中处理。
以便统一修改程序和版本维护。
3、医保接口对象常用方法说明
下面列出是_u_ybcl_对象中给_HIS_端调用的函数和事件，内部相互调用的函数不再说明：
（和前置机的交互方式和实现方法一般不让_HIS_端的程序处理，而是封装在_u_ybcl_中）
1） 函数：uf_ifyb (long al_byh, integer al_lb)，RETURN BOOLEAN
判断是不是医保病人：通过传入病人唯一编号来判断
此函数一般用在进行业务处理前，判断接下来的业务是不是要进行医保处理
判断是否为医保病人, al_byh： 门诊病人用 MS_BRDA.ID 住院病人用 zyh
al_lb =1 门诊 = 2 住院
return true 是 false 不是
2） 函数：uf_ifyb (long al_brxz)，RETURN BOOLEAN
判断是不是医保病人：通过传入病人性质来判断
此函数一般用在进行业务处理前，判断接下来的业务是不是要进行医保处理
判断是否为医保病人, al_brxz：病人性质
return true 是 false 不是
3）事件：ue_init(integer ai_xtsb) 对象事件，return Boolean
初始化数据，一般用于处理医保接口支持对象的初始数据准备
参数：ai_xtsb，系统识别，\= base_info.syscode
对象的is_errortext 实例变量，保存了失败信息
一般业务库和医保接口_DATABASE_都连接了事物后调用，比如设置了base_info 信息后，在打开业务窗口前调用
return true 初始化成功
_return false_初始化失败，一般_HIS_调用的地方，就应该终止程序了。
4）事件：ue_getbrxx (long al_byh, integer ai_sflx,integer ai_mode)，return integer
获得病人信息，一般指刷卡的过程。分门诊挂号（包括挂号、退号）、门诊结算（包括收费、作废、退费）、住院登记（登记、注销）、住院结算（包括结算、作废、退费）等地方都要调用。也可在此函数中处理应急医保（即在医保中心联系不上的情况下，在本地完成大致的医保的结算计算和结算，到时候再到医保中心手工处理报销，宁波医保有应急处理）。
参数：al_byh 病员号 门诊为 MS_BRDA.ID 住院为 ZY_BRRY.ZYH****
当ai_mode = 0 and ai_sflx=1****时设置为 0****
ai_sflx **收费类型 1**挂号 2****门诊 3****住院****
ai_mode **使用场合和方式 0**挂号或者入院登记建立档案时用****
1****收费结算或者挂号 2****退费 –1****作废结算或者退号****
其他必要设置的参数：idw_hisdata 设置为必要传参数的DATAWINDOW
有时候同时起到回填数据的功能
return 1 成功 –1 失败
下面是几种常见的使用场合：
住院登记：al_byh = 0 ai_sflx = 3 ai_mode = 0
在入院登记窗口中，新增“医保”按钮，并处理刷卡和获得基本数据。
挂号建档：al_byh = 0 ai_sflx = 1 ai_mode = 0
门诊病人建立新档案时调用。如：w_mzgh_new
建议新增“医保”按钮，统一处理医保病人的档案建立和刷卡过程。
挂号： al_byh = ID ai_sflx = 1 ai_mode = 1
一般在挂号模块中选定了病人后，要选挂号科室前调用。
退号： al_byh = ID ai_sflx = 1 ai_mode = -1
进行退号确认时调用
门诊收费：al_byh = ID ai_sflx = 2 ai_mode = 1
选择了病人后，进入收费结算主界面前，一般在 w_hjsf_mzxx“确定”按钮
门诊作废：al_byh = ID ai_sflx = 2 ai_mode = -1
进行作废确认时调用
门诊退费：al_byh = ID ai_sflx = 2 ai_mode = 2
选择了病人后，在进行退费操作前
也可以在进行确认结算前，如：_w_tfcl_的“确认”按钮中
住院结算：al_byh = ZYH ai_sflx = 3 ai_mode = 1
住院作废：al_byh = ZYH ai_sflx = 3 ai_mode = -1
住院退费：al_byh = ZYH ai_sflx = 3 ai_mode = 2
此功能一般在_BSHIS2.1_中使用，在_BSHIS2.21_以上的版本中，一般建议使用隔
日作废功能。
5）事件：ue_zydj_login ()，return integer
住院入院登记\__保存档案，处理向医保前置机发登记请求
其他必要设置的参数：idw_hisdata 在这里做入院登记的DATAWINDOW，用于参数传递
return 1 成功 –1 失败
一般在入院登记窗口中，“确定”按钮中处理
6）事件：ue_zydj_logout ()，return integer
住院入院注销\__撤消档案，处理向医保前置机发登记请求
其他必要设置的参数：idw_hisdata 在这里做入院登记的DATAWINDOW，用于参数传递
return 1 成功 –1 失败
一般在住院病人基本信息维护，处理注销病人的“确定”按钮中处理
7）事件：ue_zysf_yjs ()，return integer
住院预结算，在调用前，先给对象的_isu_zyjsxx_结构体变量赋值。
isu_zyjsxx 结算信息必要的结构体变量，具体内容（如zyh、jscs、jsrq、_czgh_等）根据实际需要而定。建议将结算界面中的项目_DATAWINDOW_传入以便结算。
return 1 成功 –1 失败
一般在结算确认窗口的_OPEN_事件中调用，处理医保病人费用支付的计算，也即执行医保的计算请求。
8）事件：ue_zysf_js ( )，return integer
住院结算
return 1 成功 –1 失败
一般在结算确认窗口“确认”按钮的事件中调用。
9）事件：ue_zysf_zf ()，return integer
住院结算发票作废，在调用前，先给对象的_isu_zyjsxx_结构体变量赋值。
isu_zyjsxx 作废结算信息必要的结构体变量，具体内容（如zyh、jsrq、_czgh_等）根据实际需要而定。
return 1 成功 –1 失败
一般在结算窗口作废“确认”按钮的事件中调用。
10）事件：ue_mzgh_yjs ()，return integer
门诊挂号\__预结算，在调用前，先给对象的_isu_mzghxx_结构体变量赋值。
isu_mzghxx 结算信息必要的结构体变量，具体内容（如fphm、id、jsrq、czgh、挂号项目数据信息等）根据实际需要而定。
return 1 成功 –1 失败
一般在挂号结算确认窗口的_OPEN_事件中调用，处理医保病人费用支付的计算，也即执行医保的计算请求。
11）事件：ue_mzgh_js ( datawindow adw_ghxx)，return integer
挂号确认结算
参数：adw_ghxx 挂号信息窗口，一般为 w_ghcl.dw_ghxx
return 1 成功 –1 失败
一般在挂号结算更新数据表时调用。
12）事件：ue_mzgh_zf ()，return integer
门诊退号，在调用前，先给对象的_isu_mzghxx_结构体变量赋值。
isu_mzghxx 作废必要的结构体变量，具体内容（如id、jsrq、czgh、_sbxh_等）根据实际需要而定。
return 1 成功 –1 失败
一般在退号窗口“确认”按钮的事件中调用。
13）事件：ue_mzsf_yjs ()，return integer
门诊预结算，在调用前，先给对象的_isu_mzjsxx_结构体变量赋值。
isu_mzjsxx 结算信息必要的结构体变量，具体内容（如fphm、id、jsrq、_czgh_等）根据实际需要而定。建议将结算界面中的项目_DATAWINDOW_传入以便结算，同时用_DATAWINDOW_的形式传入_CF02_和_YJ02_的内容，以便结算费用信息。
return 1 成功 –1 失败
一般在结算确认窗口的_OPEN_事件中调用，处理医保病人费用支付的计算，也即执行医保的计算请求。
14）事件：ue_mzsf_js ( )，return integer
门诊确认结算
return 1 成功 –1 失败
一般在确认结算确认窗口“确认”按钮的事件中调用。
15）事件：ue_mzsf_zf ()，return integer
门诊发票作废，在调用前，先给对象的_isu_mzjsxx_结构体变量赋值。
isu_mzjsxx 作废结算信息必要的结构体变量，具体内容（如id、fphm、jsrq、_czgh_等）根据实际需要而定。
return 1 成功 –1 失败
一般在作废发票窗口的“确认”按钮的事件中调用。
16）事件：ue_mztf_yjs ()，return integer
门诊退费预结算，在调用前，先给对象的_isu_mzjsxx_结构体变量赋值。
_isu_mzjsxx_必要的结构体变量，具体内容（如有效的_CFSB_数组、_YJXH_数组、tphm、fphm、id、jsrq、_czgh_等）根据实际需要而定。
return 1 成功 –1 失败
一般在退费结算确认窗口的_OPEN_事件中调用，处理医保病人退费的必要的数据准备。
17）事件：ue_mztf_js ( )，return integer
门诊退费确认结算
return 1 成功 –1 失败
一般在退费确认结算确认窗口“确认”按钮的事件中调用。