文件版次：
目录
1引言 (5)
1.1文档编制目的 (5)
1.2背景 (5)
1.3 词汇表 (5)
1.4 参考资料 (5)
2总体设计 (6)
2.1 软件体系结构 (6)
2.2 系统运行体系 (6)
2.2.1运行体系图 (6)
2.3 系统物理结构 (6)
2.4 技术路线 (7)
3系统接口设计 (7)
3.1 用户接口函数 (7)
4接口交易详细设计 (11)
4.1查询类 (13)
4.1.1交易功能 (13)
4.1.2交易设计 (13)
4.1.2.1批量数据查询下载 (13)
4.1.2.2医疗费信息汇总 (26)
4.1.2.3明细对帐请求 (27)
4.1.2.4医疗费信息查询 (27)
4.1.2.5医疗费用明细信息查询 (28)
4.1.2.6个人基本信息及帐户信息查询（中心报销用） (30)
4.1.2.7医疗待遇封锁信息查询 (34)
4.1.2.8医疗待遇审批信息查询............................................................................... 错误！未定义书签。
4.2业务类 (52)
4.2.1交易功能 (52)
4.2.2交易设计 (52)
4.2.2.1读卡交易 (52)
4.2.2.2门诊/住院登记 (55)
4.2.2.3住院登记修改 (56)
4.2.2.4登记撤销 (57)
4.2.2.5处方明细上报 (57)
4.2.2.6处方明细撤销 (59)
4.2.2.7费用预结算 (59)
4.2.2.8费用结算 (67)
4.2.2.9费用结算撤销 (69)
4.2.2.10药店收费预结算 (69)
4.2.2.11药店收费结算 (70)
4.2.2.12中心报销保存处方 (71)
4.2.2.13中心凭证录入 (73)
4.2.2.14中心报销费用结算................................................................................. 错误！未定义书签。
4.2.2.15医院审批信息上报 (74)
4.2.2.16医院审批信息上报撤销 (75)
4.2.2.17医院自制药品信息上报 (75)
4.2.2.18医院自制药品信息上报撤销 (76)
4.2.2.19医院诊疗项目信息上报 (76)
4.2.2.20医院诊疗项目信息上报撤销 (76)
5数据结构与数据库设计 (84)
6故障处理说明 (84)
7尚需解决的问题 (84)
8附件 (84)
1引言
1.1文档编制目的
本报告主要表述了安徽金保项目中医保接口设计方案，内容包含了医保接口的部署方案以及软件接口设计等内容。
本报告的阅读对象包括软件开发人员、软件设计人员、软件实施人员以及与该项目相关的其他人员等。
1.2背景
安徽金保项目涵盖了安徽省社会保险五个险种（养老、医疗、失业、工伤、生育）以及劳动力市场管理，其中也包括了其他接口，如银行接口、医保接口等。
医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁，涵盖了17个地市医保算法的需求。医保接口方案采用了联机处理方案，社保卡全部采用磁卡（对于使用CPU卡的城市，CPU卡也当磁卡使用，不记录累计信息，只使用CPU卡的卡号）。
1.3 词汇表
1.4 参考资料
2总体设计
2.1 软件体系结构
医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成，如下图所示：
在安徽项目中，由于采用了全联机方案，因此软件体系只包括了医保交易子系统。
2.2 系统运行体系
2.2.1运行体系图
医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。
◆ 联机方案
2.3 系统物理结构
? 硬件物理环境
◆联机方案
医保中心大型定点医疗机构要求以太网10兆以上局域网或宽带网。
小型定点医疗机构也建议采用宽带网，但可以采用ISDN或普通拔号上网。
医院客户端医院客户端医院客户端
?软件环境
操作系统：服务端为UNIX，客户端为WINDOWS2000以上；
应用服务器：WEBLOGIC8以上版本；
数据库：ORACLE9I以上版本；
2.4 技术路线
由医保接口动态库通过向医保接口WEB应用发送HTTP请求进行交易；医保接口的事务提交则由医保接口WEB应用管理；所有业务均通过交易体现。
动态库返回成功，开发商才能处理his系统的业务，his业务处理失败造成的事务不一致由开发商负责。如果由于线路等问题，动态库无法接收web应用返回的交易处理结果，则返回失败，由动态库保证中心业务的回退。
3系统接口设计
3.1 用户接口函数
本系统提供给医院的是一个动态库接口，无用户界面，输入输出均通过DLL完成。
程序文件名：SiInterface.dll
对外提供的接口函数：
?初始化函数:
int INIT(char * pErrMsg)
功能描述：
检查整个运行环境：包括网络环境、运行所需文件、参数等的检查
返回值：成功：返回0 ；失败：返回 -1
?交易函数：
int BUSINESS_HANDLE( char* inputData,
char* outputData)
输入参数：inputData
输出参数：outputData char*
返回值：成功 =0 失败 <0
输入参数是以“^、$、|”分割的字符串
输出也是以“^、$、|”分割的字符串
参数说明：
入参格式: inputData
业务编号^医疗机构编号^操作员编号^业务周期号^医院交易流水号^中心编码^入参^动态库参数^
出参格式: outputData char*
中心交易流水号^业务周期号^输出参数^
返回值说明 :
0–成功，表示此次交易请求成功，业务处理也正常
< 0 －错误，包括系统级别错误（网络、主机、数据库）和业务级别错误，系统级别错误由动态库将错误信息写入输出参数，业务级别错误由后台通过输出参数提示错误信息。
错误输出机制说明 :
Web应用返回给动态库的返回参数格式为：中心交易流水号^业务周期号^输出参数^交易相应码^，动态库接收到返回参数后，根据交易相应码判断交易处理成功与否，交易处理成功，则动态库返回值为0，否则，将交易相应码转换为小于0的返回值。动态库返回给开发商的出参，去掉交易相应码
交易流水号说明：
说明：交易流水号必须是每一次交易的唯一标识，在整个系统中是唯一的，因此开发商应严格按照建议规则生成交易流水号
规则：时间(14)+医院编号(8)+流水号(4)，之间用-分隔
例：20060101083030-10011001-0001
业务周期号说明：
说明：医院编号(8)＋操作员编号(最大8位)＋时间(14)+流水号(4)，之间用-分隔
例：10011001-99999999-20060101083030-0001
注：4位流水号可以循环使用
交易编码说明：
47 5 5 6 6 芜湖结算单补打查询业务
48 4 2 1 0 医院项目对照上报主体交易
49 4 2 2 0 医院项目对照上报撤消主体交易
50 4 4 1 0 省直结算单数据返回查询业务
51 4 3 1 0 电子病历上传主体交易
52 4 4 2 0 省直结算单季度数据返回查询业务
53 4 3 9 0 门诊统筹规定范围用药提示主体交易
54 4 4 5 0 公告信息查询查询业务
55 4 4 3 0 省直跨年结算单数据返回查询业务
56 6 5 4 3 芜湖对账不平特殊处理主体交易3.2医院端调用接口交易序列图
4接口交易详细设计
此部分主要对医保接口交易的各具体业务作详细说明。
4.1 查询类
4.1.1交易功能
该交易主要完成诸如中心药品目录、诊疗项目目录、服务设施目录、病种目录等的查询及下载，同时还包括个人基本信息及帐户信息、封锁信息等的查询业务。
对于中心药品目录、诊疗项目目录、服务设施目录、病种目录等的查询交易，下载时提供以TAB分隔的TXT文件。
4.1.2交易设计
4.1.2.1批量数据查询下载
交易说明：批量下载中心目录等基础数据，然后对中心的药品目录和诊疗项目目录在his系统进行对照，
输入参数：
说明：
下载文件的路径为：当前文件绝对路径\YBDLOAD\文件名.txt；文件名的命名规则为：01：YPML_下载数据开始日期；
02：ZLXM_下载数据开始日期；
03：FWSS_下载数据开始日期；
04：SFXMBM_下载数据开始日期；
05：BZML_下载数据开始日期；
06：SPXX_下载数据开始日期；
07：TJTZ_下载数据开始日期；
08：YSXX_下载数据开始日期；
09：DZXX_下载数据开始日期；
10: MXBXX_下载数据开始日期；
11: DDTCQ_下载数据开始日期；
12：WDYYXX_下载数据开始日期；
药品目录：（20080227 更新）
诊疗项目目录：
服务设施目录：
?费用类别信息：
?病种目录：
U B接口E M设计方案 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】
接口E M C设计方案 一、接口概述 USB通用串行总线（英文：UniversalSerialBus，简称USB）是连接外部装置的一个串口汇流排标准，在计算机上使用广泛，但也可以用在机顶盒和游戏机上，补充标准On-The-Go（OTG）使其能够用于在便携装置之间直接交换资料。USB接口的电磁兼容性能关系到设备稳定行与数据传输的准确性，赛盛技术应用电磁兼容设计平台（EDP）软件从接口原理图、结构设计，线缆设计三个方面来设计接口的EMC设计方案 二、接口电路原理图的EMC设计 本方案由电磁兼容设计平台（EDP）软件自动生成 1. USB 接口防静电设计 图1 USB 接口防静电设计 接口电路设计概述： 本方案从EMC原理上，进行了相关的抑制干扰和抗敏感度的设计；从设计层次解决EMC问题。 电路EMC设计说明： （1） 电路滤波设计要点： L1为共模滤波电感，用于滤除差分信号上的共模干扰； L2为滤波磁珠，用于滤除为电源上的干扰； C1、C2为电源滤波电容，滤除电源上的干扰。 L1共模电感阻抗选择范围为60Ω/100MHz ~120Ω/100MHz，典型值选取90Ω /100MHz； L2磁珠阻抗范围为100Ω/100MHz ~1000Ω/100MHz，典型值选取600Ω /100MHz ；磁珠在选取时通流量应符合电路电流的要求，磁珠推荐使用电源用磁珠； C1、C2两个电容在取值时要相差100倍，典型值为10uF、；小电容用滤除电源上的高频干扰，大电容用于滤除电源线上的纹波干扰； C3为接口地和数字地之间的跨接电容，典型取值为1000pF，耐压要求达到2KV以上，C3容值可根据测试情况进行调整； （2）电路防护设计要点 D1、D2和D3组成USB接口防护电路，能快速泄放静电干扰，防止在热拔插过程中产生的大量干扰能量对电路进行冲击，导致内部电路工作异常。 D1、D2、D3选用TVS，TVS反向关断电压为5V；TVS管的结电容对信号传输频率有一定的影响，的TVS结电容要求小于5pF。 接口电路设计备注： 如果设备为金属外壳，同时单板可以独立的划分出接口地，那么金属外壳与接口地直接电气连接，且单板地与接口地通过1000pF电容相连； 如果设备为非金属外壳，那么接口地PGND与单板地GND直接电气连接。 三、连接器设计
新农医接口方案 （提供第三方） 中软国际 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)要求医院提供独立的新农医服务器
系统对接设计 1.1.1对接式 系统与外部系统的对接式以web service式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考以及关于服务目录的元数据指导规，对于W3C UDDI v2 API结构规，采取UDDI v2的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service 接口式，对于基于消息的接口采用JMS或者MQ的式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白、SSL认证等式保证集成互访的合法性与安全性。 数据交换标准：制定适合双系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2接口规性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规标准，实现接口
HIS医保接口设计规范 一、导言 BSHIS在两年前就开始涉及医保软件接口的设计和实施了。随着时间的推移，越来越多的新签医院工程也要求实施医保；而一些以前上的老工程，也开始在实施各地的医保政策。可以说，医保的实施已经成为HIS软件在医院实施中一个很重要的组成部分。从某种意义上讲，医保实施的好坏也已经直接影响了工程实施的进度和效果。 由于医保政策的复杂性，再加上政策有很大的地区差异。在实施过程中，软件设计人员遇到了很多比较复杂也或者很难于解决的问题。另外，由于医保政策一般都是刚刚指定出来不久的。所以，在实施的过程中，经常会遇到修改政策的过程。这在一定程度上给软件设计和实施增加了不少的难度。同时，也会导致医保接口软件设计上的不确定性，直接的后果是可能导致很多的重复劳动。 结合前面很多人医保实施成功和失败的教训，对在医保接口设计过程中的，好的方法进行了归纳，并尽量给出一种比较完善和完美的设计解决方法和规范，可帮助医保实施和软件接口设计人员比较好地实施医保。当然，现在只是个草稿，需要医保实施实践不断地扩充此规范，以至形成一种比较固定的综合解决方案。 二、关于医保政策软件和应对方案 我们通过对北京安宁盈科、创智公司、东大阿儿派、杭州新世纪、建达电子、万达公司等各个医保险政策软件提供商提供的接口方案进行了分析，总计出他们之间的共性如下： 1、一般都提供DOS和WINDOWS两套方案，DOS下一般用文件形式传递 数据，WINDOWS下一般以WIN32 API的形式在HIS和医保前置机之间 调用和传递数据（DLL提供了政策函数）。我们以后者为重点说明问题。 2、政策函数一般分为两类：单个函数和多个函数两种类型设计 多个函数是指每中业务或者比较相似的业务为一个函数，这样组成结算、登记、退费等多个函数。如：杭州新世纪、东大阿儿派 单个函数是指所有的业务都用一个函数实现。参数一般用结构字符串实现。 如：上海万达公司。 3、明细数据一般都和结算时必要的项目数据分开传递到医保中心服务器。 这样做的目的是为了减少网络阻塞。如果是同时要传的，一般在结算准 备阶段就已经将数据计算好了。 4、平时发生费用时，一般分成两种方式处理： 1）平时的自负比例按HIS中设置的算，也不需要审批
智慧工厂 一、方案概述 塔网智慧工厂的构建基于公司的TN技术平台，方案设计结合精益制造、TOC 瓶颈理论、工业物联网、自动化、设备改造、移动互联网，实现工厂的流程优化、并通过系统、自动化的方式将优化后的生产流程有效固化，并在PC端和手机端进行直观的展示。 二、智慧工厂方案设计的原则： 1、方案设计考虑企业现状与整个工厂生产中的价值链环节，分步骤的逐步实施 2、方案设计确保符合精益智能柔性化配套的辅助工具、夹具、载具和合理的物 流配送方式 3、方案设计确保各工位自动化设备配置的合理性，从流程上根本降低成本 4、方案设计确保停机时间短、有效生产时间长，发生异常反应迅速的精益智能 柔性生产线 5、方案设计确保具有拉动式生产模式的，可降低库存运转的精益智能柔性线 6、方案设计确保与现有的MES、ERP等信息系统进行深度融合，确保信息流的速度和高效的控制 三、智慧工厂设计参与人员 1、精益、TOC专家，在行业有10年以上的工作经验 2、自动化行业专家；在行业有10年以上的工作经验
3、机械设计专家：在行业有10年以上的工作经验 4、信息化专家：在行业有10年以上的工作经验 四、方案设计的主要内容： 1、方案设计的主要目标 2、系统功能的整体框架 3、产线布局（包括流水线设计、工位布局） 4、自动化产线改造设计 5、设备改造方案 6、物流系统框架 7、辅助工装夹具设计 8、规划步骤与项目风险 机械装备 1、机械设备制造行业特点： 机械、设备制造业是个非常有特色的行业，其行业特色是：大部分为标准化产品、部分产品为根据客户订单定做，产品型号不多、但组成产品所需的零件可能非常多、部分产品零件的工序非常多且加工难度高、材料种类少并常常通用、订单批次多、订单批量少、关键机器的产能和工人熟练度主要决定订单的交期。其原料是以钢材为主。 其产品一般经过：车、铣、磨、电火花、焊接、抛光、热处理、镀钛、镀铬、品 检等几十道工序。 2、机械设备制造行业所面临的主要问题是：
医疗保险接口功能规范 第一条《医疗保险接口功能规范》是用于协助整个医院，按照国家医疗保险政策对医疗保险病人进行各种费用结算处理的计算机应用程序，其主要任务是完成医院信息系统与上级医保部门进行信息交换的功能，包括下载、上传、处理医保病人在医院中发生的各种与医疗保险有关的费用，并做到及时结算。 《医疗保险接口功能规范》必须符合国家、地方的有关法律、法规、规章制度的要求。 1．必须符合国务院下发的有关医疗保险的各项政策及法规。 2．必须符合劳动社会保障部下发的有关医疗保险的政策及法规。 3．必须符合地方政府下发的有关医疗保险的政策及法规。 4．《公费医疗管理办法》。 《医疗保险接口功能规范》基本功能： 1．下载内容及处理：实时或定时的从上级医保部门下载更新的药品目录、诊疗目录、服务设施目录、黑名单、各种政策参数、政策审核函数、医疗保险结算表、医疗保险拒付明细、对帐单等，并根据政策要求对药品目录、诊疗目录、服务设施目录、黑名单进行维护。 2．上传内容及处理：实时或定时向上级医保部门上传。 1)门诊挂号信息、门诊处方详细信息、门诊诊疗详细信息、
门诊个人帐户、支付明细等信息。 2)住院医嘱、住院首页信息、住院个人帐户支付明细、基金支付明细、现金支付明细等信息。 3)退费信息：包括本次退费信息，原费用信息、退费金额等信息。 4)结算汇总信息：按医疗保险政策规定的分类标准进行分类汇总。 3．医疗保险病人费用处理： 1)根据下载的政策参数、政策审核函数对医保病人进行身份确认，医保待遇资格判断。 2)对医疗费用进行费用划分，个人帐户支付、基金支付、现金支付确认，扣减个人帐户，打印结算单据。 3)校医疗保险指定格式完成对上述信息的上传。 4)在医院信息系统中保存各医疗保险病人划分并支付后的费用明细清单和结算汇总清单。 4．医疗保险接口系统维护： 1)对下载的药品目录与医院信息系统中的药品字典的对照维护。 2)对下载的诊疗目录与医院信息系统各有关项目的对照维护。 3)对下载的医疗服务设施与医院信息系统中各有关项目的对照维护。 4)对医疗保险费用汇总类别与医院信息系统中费用汇总类别的对照维护。
系统对接设计 1.1.1 3、7、3 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准: 本系统采用SOA体系架构,通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享与集成,因此SOA体系标准就就是我们采用的接口核心标准。主要包括: 服务目录标准:服务目录API接口格式参考国家以及关于服务目录的元数据指导规范,对于W3C UDDI v2 API结构规范,采取UDDI v2 的API的模型,定义UDDI的查询与发布服务接口,定制基于Java与SOAP的访问接口。除了基于SOAP1、2的Web Service接口方式,对于基于消息的接口采用JMS或者MQ的方式。 交换标准:基于服务的交换,采用HTTP/HTTPS作为传输协议,而其消息体存放基于SOAP1、2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作,服务数据与服务操作采用WSDL进行描述。 Web服务标准:用WSDL描述业务服务,将WSDL发布到UDDI用以设计/创建服务,SOAP/HTTP服务遵循WS-I Basic Profile 1、0,利用J2EE Session EJBs 实现新的业务服务,根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准:使用没有扩展的标准的BPEL4WS,对于业务流程以SOAP服务形式进行访问,业务流程之间的调用通过SOAP。 数据交换安全:与外部系统对接需考虑外部访问的安全性,通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准:制定适合双方系统统一的数据交换数据标准,支持对增量的数据自动进行数据同步,避免人工重复录入的工作。 1.1.2 3、3、8接口规范性设计 系统平台中的接口众多,依赖关系复杂,通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准与接口
创业医院信息管理系统 医 保 控 费 系 统 医疗事业部 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协议进行通信。 数据安全设计系统内部的全部业务数据（包括临床知识库数据、审核规则库数据、保险业务数据、审核结果数据、统计分析数据、用
系统对接设计 1.1.1 3.7.3 对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、 外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范， 对于W3C UDDI v2 API结构规范，采取UDDI v2 的API的模型，定义UDDI的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于 SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs 实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。 数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2 3.3.8接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口
安徽省职工基本医保参保人数情况3年数据分析报告2019 版
前言 安徽省职工基本医保参保人数情况数据分析报告围绕核心要素城镇基本医 疗保险参保总人数，职工基本医保参保人数等展开深入分析，深度剖析了安徽省职工基本医保参保人数情况的现状及发展脉络。 安徽省职工基本医保参保人数情况分析报告中数据来源于中国国家统计局、行业协会、相关科研机构等权威部门，通过整理和清洗等方法分析得出，具备权威性、严谨性、科学性。 本报告从多维角度借助数据全面解读安徽省职工基本医保参保人数情况现 状及发展态势，客观反映当前安徽省职工基本医保参保人数情况真实状况，趋势、规律以及发展脉络，安徽省职工基本医保参保人数情况数据分析报告必能为大众提供有价值的指引及参考，提供更快速的效能转化。
目录 第一节安徽省职工基本医保参保人数情况现状 (1) 第二节安徽省城镇基本医疗保险参保总人数指标分析 (3) 一、安徽省城镇基本医疗保险参保总人数现状统计 (3) 二、全国城镇基本医疗保险参保总人数现状统计 (3) 三、安徽省城镇基本医疗保险参保总人数占全国城镇基本医疗保险参保总人数比重统计.3 四、安徽省城镇基本医疗保险参保总人数（2016-2018）统计分析 (4) 五、安徽省城镇基本医疗保险参保总人数（2017-2018）变动分析 (4) 六、全国城镇基本医疗保险参保总人数（2016-2018）统计分析 (5) 七、全国城镇基本医疗保险参保总人数（2017-2018）变动分析 (5) 八、安徽省城镇基本医疗保险参保总人数同全国城镇基本医疗保险参保总人数 （2017-2018）变动对比分析 (6) 第三节安徽省职工基本医保参保人数指标分析 (7) 一、安徽省职工基本医保参保人数现状统计 (7) 二、全国职工基本医保参保人数现状统计分析 (7) 三、安徽省职工基本医保参保人数占全国职工基本医保参保人数比重统计分析 (7) 四、安徽省职工基本医保参保人数（2016-2018）统计分析 (8) 五、安徽省职工基本医保参保人数（2017-2018）变动分析 (8)
南平医保医院接口规范 一、接口设计主体思路： 采用文本文件交换信息的方式，每个业务接口主要步骤均为：医院程序删除应答文件（如果存在），提交一个请求文件，医保程序检测到后自动解释，生成一个回答文件，并删除原来的请求文件，医院程序检测到应答文件生成后就去读取医保程序返回的信息。 文件的结构主要借鉴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=
系统对接设计 1.1.1对接方式 系统与外部系统的对接方式以web service方式进行。 系统接口标准： 本系统采用SOA体系架构，通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成，因此SOA体系标准就是我们采用的接口核心标准。主要包括： 服务目录标准：服务目录API接口格式参考国家以及关于服务目录的元数据指导规范，对于W3C UDDI v2 API结构规范，采取UDDI v2的API的模型，定义UDDI 的查询和发布服务接口，定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service接口方式，对于基于消息的接口采用JMS或者MQ的方式。 交换标准：基于服务的交换，采用HTTP/HTTPS作为传输协议，而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作，服务数据和服务操作采用WSDL进行描述。 Web服务标准：用WSDL描述业务服务，将WSDL发布到UDDI用以设计/创建服务，SOAP/HTTP服务遵循WS-I Basic Profile 1.0，利用J2EE Session EJBs实现新的业务服务，根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。 业务流程标准：使用没有扩展的标准的BPEL4WS，对于业务流程以SOAP服务形式进行访问，业务流程之间的调用通过SOAP。 数据交换安全：与外部系统对接需考虑外部访问的安全性，通过IP白名单、SSL 认证等方式保证集成互访的合法性与安全性。
数据交换标准：制定适合双方系统统一的数据交换数据标准，支持对增量的数据自动进行数据同步，避免人工重复录入的工作。 1.1.2接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准，实现接口规范定义的功能外，需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。 1.1. 2.1接口定义约定 客户端与系统平台以及系统平台间的接口消息协议采用基于HTTP协议的REST风格接口实现，协议栈如图4-2所示。 图表错误!文档中没有指定样式的文字。-接口消息协议栈示意图系统在http协议中传输的应用数据采用具有自解释、自包含特征的JSON数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。 在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持多个版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要，独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。
2018年安徽医疗保险个人缴费比例与缴费标准 安徽医疗保险个人缴费比例 职工个人缴费比例：职工基本医疗保险费用人单位和职工共同缴纳,职工缴费比例为本人工资收入的2%+3。 用人单位缴费比例：用人单位缴费比例为在职职工工资总额的6%,随着经济发展，用人单位和职工缴费比例可作相应调整。 安徽医疗保险个人缴费基数 个人以本人上年度月平均工资收入为月缴费基数，单位以上一年度在职职工月平均工资总额为缴费基数。 安徽医疗保险个人缴费标准多少？ 职工个人以本人上年度月平均工资收入为月缴费基数，按2%缴费，由单位在其工资中按月代扣代缴。例:王某月工资收入为900元，线每月应缴基本医疗保险费为900元*2%=18元。进入再就业服务中心的国有企业下岗职工，其基本医疗保险费(包括单位缴费和个人缴费)，由再就业服务中心按上年度本市职工月平均工资的60%为基数代为缴纳，退休人员个人不缴纳基本医疗保险费。
安徽医疗保险个人缴费与单位缴费比例 医疗保险单位缴费比例：6%， 医疗保险个人缴费比例：2%+3元。 个人医保缴费年限、最低缴费年限相关规定 个人医保缴费年限规定 医疗保险缴费年限是指医疗保险参保人员缴纳医疗保险费用的累计年限，其包含实际缴费年限与医保视同缴纳年限。为了完善医疗保险制度，规范医保支付流程，确保医保基金安全，避免出现骗取医保现象的发生，我国各省市均对医疗保险缴费做了明确规定。参加职工基本医疗保险的个人，达到法定退休年龄时累计缴费达到国家规定年限的，退休后不再缴纳基本医疗保险费，按照国家规定享受基本医疗保险待遇；未达到国家规定年限的，可以缴费至国家规定年限。参加居民医保人员就是一年缴费一次，停止缴费则停止享受医保待遇。 个人最低缴费年限规定 医疗保险最低缴费年限为男满30年，女满25年，其中本人按规定实际缴费年限必须满10年”，“缴满本人缴费年限并到达法定退休年龄的，不再缴纳医疗保险费（大额医疗保险继续缴纳），缴满本人缴费年限未达到法定退休年龄的，继续缴费至达到法定退休年龄”。就是说你的医保缴费最低年限在男满30年，女满25年的前提下，其中实际缴费不得低于10年，在满足基本缴费年限和实际缴费年限的条件下，但未达到法定退休年龄，仍需继续缴纳直到退休。
荆州普爱康复医院 医保定点医院接口设计方案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院内HIS 系统的接口设计方案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施，制定医疗保险定点医院院内HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁，医保接口方案采用了联机、脱机相结合的处理方案，社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成，如下图所示： 4、数据传输 3、圈存 1、医保交易 2、社保卡交易 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、
数据库系统组成。 读卡 医保接口动态库 医保接口WEB 应 用 社保中心数据 库 社保卡交易医保业务处理 医保交易 社保中心数据库服务器 社保中心应用服务器 医院客户端医院客户端医院客户端 医保接口动态库 医保接口 交易应用 联机方案 脱机方案
社保中心数据库服务器 社保中心应用服务器 医院客户端医院客户端医院客户端 医保前置机 医保前置机 医保前置机 数据传输服务器 圈存服务器医保接口动态库 数据传输系统 圈存系统 脱机方案 软件环境 操作系统：服务端为UNIX ，客户端为WINDOWS2000以上； 应用服务器：WEBLOGIC8以上版本； 数据库：ORACLE10.2； 4、技术路线 联机时： 由医保接口动态库通过向医保接口WEB 应用发送HTTP 请求进行交易；医保接口的事务提交则由医保接口WEB 应用管理；所有业务均通过交易体现。 脱机时： 由医保接口动态库通过OCI 接口，向数据库发送数据操作请求，医保接口的事务提交是用接口内部来实现的，它需要HIS 有医保前置机，所有业务均通过交易体现， 与联机方式的交易格式是相同的。 脱机/联机时： 在中心网络畅通时使用联机交易， 在网络不通时走脱机模式，在读卡和登记两个交易判断是否联机，并返回给HIS 联机标识，之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱
安徽省基本医疗保险基金支出综合情况3年数据解读报告 2019版
序言 安徽省基本医疗保险基金支出综合情况数据解读报告从基本医疗保险基金 总支出，职工基本医疗保险基金支出，居民基本医疗保险基金支出等重要因素进行分析，剖析了安徽省基本医疗保险基金支出综合情况现状、趋势变化。借助对数据的发掘及分析，提供一个全面、严谨、客观的视角来了解安徽省基本医疗保险基金支出综合情况现状及发展趋势。本报告数据来源于中国国家统计局等权威部门，并经过专业统计分析及清洗而得。 安徽省基本医疗保险基金支出综合情况数据解读报告知识产权为发布方即 我公司天津旷维所有，其他方引用我方报告均需注明出处。 安徽省基本医疗保险基金支出综合情况数据解读报告以数据呈现方式客观、多维度、深入介绍安徽省基本医疗保险基金支出综合情况真实状况及发展脉络，为需求者提供必要借鉴及重要参考。
目录 第一节安徽省基本医疗保险基金支出综合情况现状 (1) 第二节安徽省基本医疗保险基金总支出指标分析 (3) 一、安徽省基本医疗保险基金总支出现状统计 (3) 二、全国基本医疗保险基金总支出现状统计 (3) 三、安徽省基本医疗保险基金总支出占全国基本医疗保险基金总支出比重统计 (3) 四、安徽省基本医疗保险基金总支出（2016-2018）统计分析 (4) 五、安徽省基本医疗保险基金总支出（2017-2018）变动分析 (4) 六、全国基本医疗保险基金总支出（2016-2018）统计分析 (5) 七、全国基本医疗保险基金总支出（2017-2018）变动分析 (5) 八、安徽省基本医疗保险基金总支出同全国基本医疗保险基金总支出（2017-2018）变动对 比分析 (6) 第三节安徽省职工基本医疗保险基金支出指标分析 (7) 一、安徽省职工基本医疗保险基金支出现状统计 (7) 二、全国职工基本医疗保险基金支出现状统计分析 (7) 三、安徽省职工基本医疗保险基金支出占全国职工基本医疗保险基金支出比重统计分析.7 四、安徽省职工基本医疗保险基金支出（2016-2018）统计分析 (8) 五、安徽省职工基本医疗保险基金支出（2017-2018）变动分析 (8)
荆州普爱康复医院 医点医院接口设计案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院HIS 系统的接口设计案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施，制定医疗保险定点医院院HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁，医保接口案采用了联机、脱机相结合的处理案，社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成，如下图所示： 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。
小型定点医疗机构也建议采用宽带网，但可以采用ISDN或普通拔号上网。
医院客户端医院客户端医院客户端 ◆ 脱机案 医院客户端医院客户端医院客户端 脱机方案 ? 软件环境 操作系统：服务端为UNIX ，客户端为WINDOWS2000以上； 应用服务器：WEBLOGIC8以上版本；
数据库：ORACLE10.2； 4、技术路线 ?联机时： 由医保接口动态库通过向医保接口WEB应用发送HTTP请求进行交易； 医保接口的事务提交则由医保接口WEB应用管理；所有业务均通过交易体现。 ?脱机时： 由医保接口动态库通过OCI接口，向数据库发送数据操作请求，医保接口的事务提交是用接口部来实现的，它需要HIS有医保前置机，所有业务均通过交易体现，与联机式的交易格式是相同的。 ?脱机/联机时： 在中心网络畅通时使用联机交易，在网络不通时走脱机模式，在读卡和登记两个交易判断是否联机，并返回给HIS联机标识，之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱机，其他必须联机. 联机交易注意事项： 动态库返回成功，开发商才能处理，否则容易造成中心和医院事务不一致。 如果由于线路等问题，动态库无法接收web应用返回的交易处理结果，则返回失败，由动态库保证中心业务的冲正。 脱联结合时各地市业务脱机情况： 城市: , , 宿迁
安徽省直医保特殊病种门诊政策和流程介绍特殊病门诊简单解释：对患有冠心病、高血压病三期、糖尿病、恶性肿瘤、精神病、肝硬化、肾透析、肾移植术后等八种病的省直参保人员，申请了特殊病门诊后，每月在门诊定点医院针对特殊病发生的门诊费用，可以比照住院的政策报销（不同医院每月报销上限有所不同）。举例来说，如果某人患有糖尿病，申请了安徽省中医学院的特殊病门诊后，每月到中医学院拿糖尿病的药，那么前600元不能报销（相当于住院的门槛费），其余费用可以每月报销400元。 特殊病门诊申请流程：1、准备能证明患有特种病的出院小结等材料，填写《特殊病种门诊申请表》，到三级医院诊断盖章；2、带以下材料到拟申请的门诊定点医院的医保办办理：①《特殊病种门诊申请表》；②社保卡；③身份证； ④一张一寸照片；⑤申请高血压的要带出院小结（三级、二级医院都可以）；3、由定点医院到省医保中心代为办理，办理成功后本人到定点医院领取特种病门诊卡后，即可享受，以后每次带特种病门诊卡到定点医院拿特殊病的药可以享受报销。 填表说明：1、“医疗保险号”个人不必填写。2、根据病情按“特殊病种范围”规范填写“申请病种名称”（冠心病、高血压病三期、糖尿病、恶性肿瘤、精神病、肝硬化、肾透析、肾移植术后）。3、“三级定点医院诊断结论”个人不需填写（需在合肥三级医院签订、精神病由精神病专科医院鉴定，异地安置人员也可以在异地三级医院鉴定）。4、“申请门诊定点医院名称”必填，个人可自愿选择一家省直基本医疗保险定点机构（异地安置人员可选择异地三个定点医院中的一个）。5、“定点医院意见”由特殊病种门诊定点医院签署意见。 如何变更慢特病定点医院：于每年的12.1-12.15日将本人的《慢特病就诊卡》交新选择的定点医院医保办，由医院医保办到省医保办理变更，月底或次月初到医保办领取新的《慢特病就诊卡》，并于次月在新选择的医院享受相应待遇。 附件：《安徽省直基本医疗保险特殊病种门诊申请表》 人教处咨询电话：65592158，zhangyh@https://www.doczj.com/doc/f49807415.html,联系人：张艳辉2号楼326房间
荆州普爱康复医院 医保定点医院接口设计方案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院内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）所有的接口设计需遵循ITSS标准及行业接口规范； （2）技术上采用SOA组件化设计思想，实现系统间的松耦合。 其他原则 （1）使用简单、快捷，通用性好，可靠性高； （2）充分考虑接口所涉及系统的应用扩展，灵活支撑需求变化； （3）保证接口数据在接口所涉及的各个系统间的一致性； （4）在数据交互过程中，应具有传送和接收后的确认过程； （5）以XML格式数据为主要的数据传输载体。 1.2接口定义与分类 1.2.1内部接口 内部接口主要是指各个子系统间的接口关系，主要包含数据接口和服务调动接口。 1、内部系统间数据接口 主要是各子系统间数据共享接口。 2、内部系统间业务服务调用接口 主要是各个子系统间业务服务调用接口。
1.2.2外部接口 本项目是在文艺资源系统整合一期基础上建设，主要接口来源于整合一期中文艺资源数据库系统间的接口。 1、与文艺资源数据库系统对接接口 与文艺资源数据库系统对接，实现会员数据、作品数据交换至文艺资源数据库。 2、与身份认证系统对接接口 与身份认证系统对接，实现用户统一认证管理。 1.3接口设计模式 1、接口定义 接口是指用于完成各系统间和系统内部数据传递的接口。在系统中通常设计成一个数据库文件或接口转换模块，传出数据的系统通常对数据事先进行必要的加工处理，需要接收数据的系统按照用户的要求（用户事先定义的数据模式），通过接口完成数据传递的任务。 （1）数据模式 接口的核心是数据模式，所谓数据模式是指应用系统对要传递的数据应在数据的来源、内容、定义、分类、汇总、数据格式、数据去向等方面的处理上做出相应的规定。一般情况下数据模式是在软件初始化阶段由用户设定的，投入应用时大量的数据采集完全自动化。同时根据系统的实际需要用户也可以对数据模式进行修改和维护，甚至重新定义。 （2）传递数据的形式 对于传递数据的形式，不同的软件系统可采用不同的策略：一种是由接收数据的系统采取主动按照数据接口定义到对方系统去识别、采集。一种是由要传出数据的系统先对数据进行加工，然后按照数据接口定义将数据传递过去。如果是系统内接口，一般采用的是第一种，系统内外系统间的数据传递一般是第二种。 2、系统内部接口 系统内部接口适合于本项目内各业务系统之间的数据传递，要传递的数据的格式、内容基本上相同，无需再加工处理。接口不是系统之间的数据传递，而