HIS医保接口设计规范

HIS医保接口设计规范
HIS医保接口设计规范

HIS医保接口设计规范

一、导言

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_https://www.360docs.net/doc/d014099309.html,erid // 操作工号

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 失败

一般在退费确认结算确认窗口“确认”按钮的事件中调用。

医保接口方案(提供第三方)

新农医接口方案 (提供第三方) 中软国际 2003年8月

一前言 (2) 二方案使用对象 (2) 三参照资料 (3) 四第三方软件实现接口的前提 (3) 五嵌入式接口软件简要说明 (3) 六农医办要求 (3) 七版权声明 (4) 一新农医病人 (4) 二、医疗项目 (4) 三、新农医药典 (4) 四、新农医大类 (4) 五、黑名单 (4) 一数据流程 (5) 二业务流程 (6) 一数据结构说明 (7) 二数据表中缺省值列的简写含义 (7) 三数据表中解释列的简写含义 (7) 一说明 (7) 二医院初始化定义相关的表 (7) 三数据更新方式 (8) 四进行关联 (9) 一门诊收费业务新农医数据保存 (9) 二住院登记业务新农医数据保存 (11) 三住院记账业务新农医数据保存 (11) 四住院结算部分新农医数据保存 (12) 一功能说明 (13) 二DLL函数说明 (13) 一退票问题 (18) 二特殊参保人群的报销方法说明 (18) 引言 一前言 《新农医接口方案》是中软国际和萧山区农医办根据萧山区新农医管理信息系统软件的数据流程的要求共同编写而成,用于辅助第三方医院或卫生院软件提供商修改现有软件,顺利实现与萧山区新农医管理信息系统软件进行联网运行。此方案交农医办确认后实施。 二方案使用对象 1)农医办相关科室及其他相关领导。

2)第三方软件开发商及其技术人员。 3)与新农医接口开发实施的相关技术人员。 三参照资料 4)新农医医疗发票格式.xls(暂无) 5)医疗项目目录.xls(暂无,参照萧山医保) 6)剂型定义.doc(暂无,参照萧山医保) 7)新农医费用大类定义.doc(暂无,参照萧山医保) 8)新农医接口部分软件安装调试说明 四第三方软件实现接口的前提 9)第三方软件必须提供真实有效的数据信息。 10)第三方软件经过修改后必须能够提供所有接口数据库需要的数据。(见数据保存) 11)拥有足够的技术实力,采用直接方式或间接方式正常调用DELPHI所编译的动态 链接库DLL。 12)对于不使用前置机的医院和卫生院,要求第三方软件开发商可以开发连接到农医办 sockect服务程序的前端接口。 五嵌入式接口软件简要说明 1.运行环境 ●操作系统:WIN98以上版本 ●数据库系统:ORACLE8.1.6及以上 ●服务器:PIII800以上 2.功能及构成简要说明 接口软件分为两部分:接口DLL程序、新农医数据管理程序。 13)接口DLL程序: 接口DLL程序,其中包含读取二维条玛卡信息,各种卡状态的判断,并对由第三方提供的就医信息进行新农医费用计算,调用函数后返回状态值。 14)新农医数据管理程序 新农医数据管理程序主要用于管理新农医相关数据,形成上传数据,保证与农医办的数据交换。 程序包括:数据交换(上传下载),数据查询(包括:农医办药典查询,剂型查询,新农医大类查询,黑名单查询,有效期查询),打印新农医对帐单(包括:住院对帐汇总表、住院对帐明细表)。 六农医办要求 15)要求医院提供独立的新农医服务器

HIS医保接口设计规范解析

HIS医保接口设计规范 一、导言 BSHIS在两年前就开始涉及医保软件接口的设计和实施了。随着时间的推移,越来越多的新签医院工程也要求实施医保;而一些以前上的老工程,也开始在实施各地的医保政策。可以说,医保的实施已经成为HIS软件在医院实施中一个很重要的组成部分。从某种意义上讲,医保实施的好坏也已经直接影响了工程实施的进度和效果。 由于医保政策的复杂性,再加上政策有很大的地区差异。在实施过程中,软件设计人员遇到了很多比较复杂也或者很难于解决的问题。另外,由于医保政策一般都是刚刚指定出来不久的。所以,在实施的过程中,经常会遇到修改政策的过程。这在一定程度上给软件设计和实施增加了不少的难度。同时,也会导致医保接口软件设计上的不确定性,直接的后果是可能导致很多的重复劳动。 结合前面很多人医保实施成功和失败的教训,对在医保接口设计过程中的,好的方法进行了归纳,并尽量给出一种比较完善和完美的设计解决方法和规范,可帮助医保实施和软件接口设计人员比较好地实施医保。当然,现在只是个草稿,需要医保实施实践不断地扩充此规范,以至形成一种比较固定的综合解决方案。 二、关于医保政策软件和应对方案 我们通过对北京安宁盈科、创智公司、东大阿儿派、杭州新世纪、建达电子、万达公司等各个医保险政策软件提供商提供的接口方案进行了分析,总计出他们之间的共性如下: 1、一般都提供DOS和WINDOWS两套方案,DOS下一般用文件形式传递 数据,WINDOWS下一般以WIN32 API的形式在HIS和医保前置机之间 调用和传递数据(DLL提供了政策函数)。我们以后者为重点说明问题。 2、政策函数一般分为两类:单个函数和多个函数两种类型设计 多个函数是指每中业务或者比较相似的业务为一个函数,这样组成结算、登记、退费等多个函数。如:杭州新世纪、东大阿儿派 单个函数是指所有的业务都用一个函数实现。参数一般用结构字符串实现。 如:上海万达公司。 3、明细数据一般都和结算时必要的项目数据分开传递到医保中心服务器。 这样做的目的是为了减少网络阻塞。如果是同时要传的,一般在结算准 备阶段就已经将数据计算好了。 4、平时发生费用时,一般分成两种方式处理: 1)平时的自负比例按HIS中设置的算,也不需要审批

医疗保险接口功能规范

医疗保险接口功能规范 第一条《医疗保险接口功能规范》是用于协助整个医院,按照国家医疗保险政策对医疗保险病人进行各种费用结算处理的计算机应用程序,其主要任务是完成医院信息系统与上级医保部门进行信息交换的功能,包括下载、上传、处理医保病人在医院中发生的各种与医疗保险有关的费用,并做到及时结算。 《医疗保险接口功能规范》必须符合国家、地方的有关法律、法规、规章制度的要求。 1.必须符合国务院下发的有关医疗保险的各项政策及法规。 2.必须符合劳动社会保障部下发的有关医疗保险的政策及法规。 3.必须符合地方政府下发的有关医疗保险的政策及法规。 4.《公费医疗管理办法》。 《医疗保险接口功能规范》基本功能: 1.下载内容及处理:实时或定时的从上级医保部门下载更新的药品目录、诊疗目录、服务设施目录、黑名单、各种政策参数、政策审核函数、医疗保险结算表、医疗保险拒付明细、对帐单等,并根据政策要求对药品目录、诊疗目录、服务设施目录、黑名单进行维护。 2.上传内容及处理:实时或定时向上级医保部门上传。 1)门诊挂号信息、门诊处方详细信息、门诊诊疗详细信息、

门诊个人帐户、支付明细等信息。 2)住院医嘱、住院首页信息、住院个人帐户支付明细、基金支付明细、现金支付明细等信息。 3)退费信息:包括本次退费信息,原费用信息、退费金额等信息。 4)结算汇总信息:按医疗保险政策规定的分类标准进行分类汇总。 3.医疗保险病人费用处理: 1)根据下载的政策参数、政策审核函数对医保病人进行身份确认,医保待遇资格判断。 2)对医疗费用进行费用划分,个人帐户支付、基金支付、现金支付确认,扣减个人帐户,打印结算单据。 3)校医疗保险指定格式完成对上述信息的上传。 4)在医院信息系统中保存各医疗保险病人划分并支付后的费用明细清单和结算汇总清单。 4.医疗保险接口系统维护: 1)对下载的药品目录与医院信息系统中的药品字典的对照维护。 2)对下载的诊疗目录与医院信息系统各有关项目的对照维护。 3)对下载的医疗服务设施与医院信息系统中各有关项目的对照维护。 4)对医疗保险费用汇总类别与医院信息系统中费用汇总类别的对照维护。

医保控费系统简述2020年规划方案

创业医院信息管理系统 医 保 控 费 系 统 医疗事业部 2020年01月

目录 一、系统技术架构 (3) 1、系统安全性设计 (3) 2、业务功能安全设计 (4) 二、系统功能 (4) 1、事前规划 (4) 1.1、患者结算规则 (4) 1.2、医院清算规则 (5) 1.3、科室二次分配规则 (5) 1.4、诊疗项目规则设置 (5) 2、事中监控 (5) 2.1、模拟结算 (5) 2.2、定额监控预警 (6) 2.3、单病种支付结算方式预测 (6) 2.4、其他预警 (6) 3、事后统计分析挖掘 (6) 3.1、门诊统计分析 (7) 3.2、住院统计分析 (7)

一、系统技术架构 医保费用调控系统是基于NET平台开发,精心架构,面向服务化实现,接口丰富易用,注重性能、扩展性,及与第三方平台的协同性。 医保费用调控系统设计为三层体系结构,包括:基础数据层、应用模块层和服务提供层。易于扩展,适应未来发展。 系统组件设计遵从于业界成熟、先进的设计理念和原则,包括:面向接口编程(IOP)、面向方面编程(AOP)、依赖注入(DI)以及对象关系映射技术(ORM)等。 基于以上分析系统结合PDCA,事前对医保规则及其数据进行标准化设置,事中根据规则引擎对数据进行费用监控预警,事后根据BI统计分析各类所需报表。 1、系统安全性设计 本系统安全性设计基于3个方面:通信网络安全设计、数据安全设计、业务功能安全设计。真正实现从数据源头到功能业务再到用户操作全流程的安全防范。 通讯网络安全设计系统是基于标准的REST风格设计,系统内外均是采用标准的WEB协议进行通信。客户端(包括系统自带的客户端系统和外部接口调用的外系统)与平台服务端之间均是采用标准的HTTP协议进行通信。 数据安全设计系统内部的全部业务数据(包括临床知识库数据、审核规则库数据、保险业务数据、审核结果数据、统计分析数据、用

医保收费接口规范

南平医保医院接口规范 一、接口设计主体思路: 采用文本文件交换信息的方式,每个业务接口主要步骤均为:医院程序删除应答文件(如果存在),提交一个请求文件,医保程序检测到后自动解释,生成一个回答文件,并删除原来的请求文件,医院程序检测到应答文件生成后就去读取医保程序返回的信息。 文件的结构主要借鉴Windows系统通用的信息文件格式(*.ini)。为安全起见,每一个涉及收费的接口均需校验卡号。为方便起见,对交换文件不进行加密处理,采用文本文件。 为了全省数据的一致性,病种编码,发票项目编码、药品项目和诊疗项目编码将统一标准。 注:如果医保政策或实施细则有变化,本规范将作相应调整。 二、医院程序设计注意事项: 1.发出请求前,应当删除应答文件,(否则医保程序将不会响应应答文件。) 2.发出请求文件时,填写request字段的内容应填写完参数后进行; (** 无论对或写,务必采用独占方式(LOCKREADWRITE!)打开文件。) 3.检测应答文件时,应当等到应答文件的reply=TRUE时,方可进行读取工作。 4.读结果文件时,可以和发送的信息进行一些简单的校验(例如接口发送和接收的处方数目,明细,总金额等是否一致等),保证程序正确运行。 三、各个具体业务的接口文件结构: 请求文件名为:request.txt 接口返回的文件名为:reply.txt 请求和应答文件中英文字段意义说明:(C代表字符类型 N代表数值类型例如N5,2代表取值0.00到999.99) (字段意义如文件中另有说明的除外)

注1:接口应答文件返回时如有参保人信息,都有参保人的各种信息如:姓名、性别、年龄、单位、ic卡状态、工作状态、个人账户余额、地区、分中心等;下面的接口说明中均以“<<参保人其他信息>>”字样代表: xming0= xbie00= brnl00= dwmc00= icztmc= gzztmc= grzhye= dqmc00= fzxmc0= 注2:接口应答文件返回时如有处方明细信息,都有收费项目的各种信息如:名称、规格等;下面的接口说明中均以“<<处方明细信息>>”字样代表: 医院收费项目在医保中心的编号 是否医保项目 医院收费项目在医保中心的发票项目名称 医院收费项目在医保中心的名称 医院收费项目在医保中心的规格 医院收费项目在医保中心的单位 医院收费项目在医保中心的单价 医院收费项目的数量 医院收费项目的金额 医院收费项目的医生姓名 此外,接口返回的收费文件的<<处方明细信息>>除有以上信息外,还增加一行信息,为医院收费项目在医保中心的个人自付比例(0 到1)。 注3:返回文件中的发票项目均分解到[yb0000]和[fyb000]两个小节中,分别代表按政策医保项目费用和按政策规定个人自付项目费用。 ◆门诊挂号: 1.医院程序形成"读卡请求"文件 : [mzghsk] request=TRUE 医保程序接受请求后将填写结果文件,并将原来的请求文件删除,此时医院程序检测到应答文件生成后(文件中reply=TRUE),就可以读取结果文件,读取完后将结果文件删除后,才可以发出下一个请求。(以下各个接口也须照此处理) [mzghsk] reply=TRUE success= error= cardno= id0000= <<参保人其他信息>> ;病人是否可以门诊挂号(TRUE or FALSE) valid0=

医疗保险定点医院接口方案及对策

荆州普爱康复医院 医点医院接口设计案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院HIS 系统的接口设计案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施,制定医疗保险定点医院院HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁,医保接口案采用了联机、脱机相结合的处理案,社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成,如下图所示: 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。

小型定点医疗机构也建议采用宽带网,但可以采用ISDN或普通拔号上网。

医院客户端医院客户端医院客户端 ◆ 脱机案 医院客户端医院客户端医院客户端 脱机方案 ? 软件环境 操作系统:服务端为UNIX ,客户端为WINDOWS2000以上; 应用服务器:WEBLOGIC8以上版本;

数据库:ORACLE10.2; 4、技术路线 ?联机时: 由医保接口动态库通过向医保接口WEB应用发送HTTP请求进行交易; 医保接口的事务提交则由医保接口WEB应用管理;所有业务均通过交易体现。 ?脱机时: 由医保接口动态库通过OCI接口,向数据库发送数据操作请求,医保接口的事务提交是用接口部来实现的,它需要HIS有医保前置机,所有业务均通过交易体现,与联机式的交易格式是相同的。 ?脱机/联机时: 在中心网络畅通时使用联机交易,在网络不通时走脱机模式,在读卡和登记两个交易判断是否联机,并返回给HIS联机标识,之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱机,其他必须联机. 联机交易注意事项: 动态库返回成功,开发商才能处理,否则容易造成中心和医院事务不一致。 如果由于线路等问题,动态库无法接收web应用返回的交易处理结果,则返回失败,由动态库保证中心业务的冲正。 脱联结合时各地市业务脱机情况: 城市: , , 宿迁

医疗保险定点医院接口设计方案

荆州普爱康复医院 医保定点医院接口设计方案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院内HIS 系统的接口设计方案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施,制定医疗保险定点医院院内HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁,医保接口方案采用了联机、脱机相结合的处理方案,社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成,如下图所示: 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。

医院客户端医院客户端医院客户端

◆ 脱机方案 医院客户端医院客户端医院客户端 脱机方案 ? 软件环境 操作系统:服务端为UNIX ,客户端为WINDOWS2000以上; 应用服务器:WEBLOGIC8以上版本; 数据库:ORACLE10.2; 4、技术路线 ? 联机时: 由医保接口动态库通过向医保接口WEB 应用发送HTTP 请求进行交易;医保接口的事务提交则由医保接口WEB 应用管理;所有业务均通过交易体现。 ? 脱机时: 由医保接口动态库通过OCI 接口,向数据库发送数据操作请求,医保接口的事务提交是用接口内部来实现的,它需要HIS 有医保前置机,所有业务均通过交易体现, 与联机方式的交易格式是相同的。 ? 脱机/联机时:

在中心网络畅通时使用联机交易,在网络不通时走脱机模式,在读卡和登记两个交易判断是否联机,并返回给HIS联机标识,之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱机,其他必须联机. 联机交易注意事项: 动态库返回成功,开发商才能处理,否则容易造成中心和医院事务不一致。 如果由于线路等问题,动态库无法接收web应用返回的交易处理结果,则返回失败,由动态库保证中心业务的冲正。 脱联结合时各地市业务脱机情况: 城市: 连云港, 淮安, 宿迁 只使用帐户,没有基金支出的业务(只有普通门诊),可以使用脱机或联机, 对于有基金支出的业务和其他查询类业务都要求使用联机,联机不通的情况下不允许做业务处理. 特殊情况在联机做住院登记后,再录入费用明细网络不通时,要求HIS方对费用明细信息保存在HIS数据库中, 在网络畅通时再将本地的HIS数据上传到中心,最后在联机时做出院结算,完成整个的住院就医流程. 对这种方式只对帐户及其帐户支出累计做写卡操作,其它数据以中心的为准. 二、用户接口函数 本系统提供给医院的是一个动态库接口,无用户界面,输入输出均通过DLL 完成。 程序文件名:SiInterface.dll 对外提供的接口函数: ?初始化函数: int INIT(char * pErrMsg) 功能描述: 检查整个运行环境:包括网络环境、运行所需文件、参数等的检查 返回值:成功:返回0 ;失败:返回 -1 ?交易函数: int BUSINESS_HANDLE( char* inputData, char* outputData)

医保接口设计方案

医保接口设计方案

目录

1引言 1.1文档编制目的 本报告主要表述了株洲金保项目中医保接口设计方案,内容包含了医保接口的部署方案以及软件接口设计等内容。 本报告的阅读对象包括软件开发人员、软件设计人员、软件实施人员以及与该项目相关的其他人员等。 1.2背景 医保接口方案采用了联机处理方案,社保卡全部采用CPU卡(当磁卡使用),不记录累计信息,只使用CPU卡的卡号)。 1.3 词汇表 1.4 参考资料 2总体设计 2.1 软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成,如下图所示:

在株洲项目中,由于采用了全联机方案,因此软件体系只包括了医保交易子系统。 2.2 系统运行体系 2.2.1运行体系图 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。

医院客户端医院客户端医院客户端 ?软件环境 操作系统:服务端为UNIX,客户端为WINDOWS2000以上; 应用服务器:WEBLOGIC8以上版本; 数据库:ORACLE9I以上版本; 2.4 技术路线 由医保接口动态库通过向医保接口WEB应用发送HTTP请求进行交易;医保接口的事务提交则由医保接口WEB应用管理;所有业务均通过交易体现。 动态库返回成功,开发商才能处理his系统的业务,his业务处理失败造成的事务不一致由开发商负责。如果由于线路等问题,动态库无法接收web应用返回的交易处理结果,则返回失败,由动态库保证中心业务的回退。 3系统接口设计 3.1 用户接口函数 本系统提供给医院的是一个动态库接口,无用户界面,输入输出均通过DLL完成。 程序文件名:SiInterface.dll 对外提供的接口函数: ?初始化函数: int INIT(char * pErrMsg) 功能描述:

接口设计方案

接口设计方案

接口设计方案 一、设计方案 由甲方调用监控模块,控制监控模块的启停、设置策略等,通过甲方调用监控模块DLL 的接口将监控策略告知监控模块,由监控模块监控相关操作行为,并根据策略配置调用甲方提供的文件内容检查模块,对相关文件进行文件内容筛查,来确定文件是否是涉密文件。同时通过甲方程序调用乙方监控模块DLL 接口获取监控结果。 甲监监控模块甲方文件

一、接口部分(监控模块DLL,乙方提供) ************************************ Function:Init Description:初始化操作 Input:无 Output:无 Return:true:成功,false:失败 Other: *********************************** 1、bool Init(); ************************************ Function:SetRule Description:设置监控规则 Input:char* pRule:监控规则,XML格式,见附1 Output:无

Return:true:成功,false:失败 Other: *********************************** 2、bool SetRule(char* pRule); ************************************ Function:Start Description:设置完规则,启动监控规则生效Input:无 Output:无 Return:true:成功,false:失败 Other: *********************************** 3、bool Start(); ************************************ Function:WaitData Description:实时等待获取监控数据可以是一条可以是多条。返回监控结果见附2 Input:无

医疗保险定点医院接口设计方案

荆州普爱康复医院 医保定点医院接口设计方案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院内HIS 系统的接口设计方案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施,制定医疗保险定点医院院内HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁,医保接口方案采用了联机、脱机相结合的处理方案,社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成,如下图所示: 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数

据传输系统、数据库系统组成。 或普通拔号上网。

医院客户端医院客户端医院客户端 ◆脱机方案 医院客户端医院客户端医院客户端 脱 机 方 案 ?软件环境 操作系统:服务端为UNIX,客户端为WINDOWS2000以上; 应用服务器:WEBLOGIC8以上版本; 数据库:ORACLE10.2;

4、技术路线 ?联机时: 由医保接口动态库通过向医保接口WEB应用发送HTTP请求进行交易;医保接口的事务提交则由医保接口WEB应用管理;所有业务均通过交易体现。 ?脱机时: 由医保接口动态库通过OCI接口,向数据库发送数据操作请求,医保接口的事务提交是用接口内部来实现的,它需要HIS有医保前置机,所有业务均通过交易体现,与联机方式的交易格式是相同的。 ?脱机/联机时: 在中心网络畅通时使用联机交易,在网络不通时走脱机模式,在读卡和登记两个交易判断是否联机,并返回给HIS联机标识,之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱机,其他必须联机. 联机交易注意事项: 动态库返回成功,开发商才能处理,否则容易造成中心和医院事务不一致。如果由于线路等问题,动态库无法接收web应用返回的交易处理结果,则返回失败,由动态库保证中心业务的冲正。 脱联结合时各地市业务脱机情况: 城市: 连云港, 淮安, 宿迁 只使用帐户,没有基金支出的业务(只有普通门诊),可以使用

相关文档
最新文档