医疗保险定点医院接口设计方案
荆州普爱康复医院 医保定点医院接口设计方案
【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院内HIS 系统的接口设计方案。
引言 为了更好的加快金保工程医保信息系统统一应用软件的实施，制定医疗保险定点医院院内HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁，医保接口方案采用了联机、脱机相结合的处理方案，社保卡全部采用Memory 卡.
一、总体设计 1、软件体系结构
医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成，如下图所示：
4、数据传输
3、圈存
1、医保交易
2、社保卡交易
2、系统运行体系
医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。
? 联机方案
读卡
医保接口动态库
医保接口WEB 应
用
社保中心数据
库
社保卡交易医保业务处理
医保交易
? 脱机方案 增加医保前置机, 圈存系统和数据传输系统.
3、系统物理结构
? 硬件物理环境
◆ 联机方案
医保中心大型定点医疗机构要求以太网10兆以上局域网或宽带网。 小型定点医疗机构也建议采用宽带网，但可以采用ISDN 或普通拔号上网。
社保中心数据库服务器
社保中心应用服务器
医院客户端医院客户端医院客户端
医保接口动态库
医保接口交易应用
联机方案
◆ 脱机方案
社保中心数据库服务器
社保中心应用服务器
医院客户端医院客户端医院客户端
医保前置机
医保前置机
医保前置机
数据传输服务器
圈存服务器医保接口动态库
数据传输系统
圈存系统
脱机方案
? 软件环境
操作系统：服务端为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)
输入参数：inputData
输出参数：outputData char*
返回值：成功 =0 失败 <0
输入参数是以“^、$、|”分割的字符串
输出也是以“^、$、|”分割的字符串
参数说明：
入参格式: inputData
业务编号^医疗机构编号^操作员编号^业务周期号^医院交易流水号^中心编码^入参^联机标志^动态库参数^
业务编号（4位）宏定义, 分别对应后台的一项业务操作
医院编号(8位)
操作员编号(8
位)
医院分配给操作员的唯一标识
业务周期号(最
大34位)
签到时的返回的业务周期号
医院交易流水号(发送方交易流水号)(最大30位) 建议规则：时间(14)+医院编号(8)+流水号(4) 例：20060101083030-10011001-0001
中心编码固定为0000
入参以“|”分隔，详见每个交易的参数表, 分项之间使
用管道分割符‘|’分割，最后必须要以管道分割符
号‘|’结尾，不以‘|’开始。如果入参为多条记
录，记录之间以‘$’分割，不同数据项之间以‘|’
分割
联机标志0：脱机 1:联机。
注意：在做读卡和门诊挂号这两个交易时，联机标
识必须传1。
动态库入参签到交易为：客户端MAC地址|用户数目|
其他交易为：客户端MAC地址|
出参格式: outputData char*
中心交易流水号^业务周期号^输出参数^联机标志^
中心交易流水号中心交易流水号(最大30位)中心返回
业务周期号中心根据操作员和中心时间，生成业务周期号
输出参数（该参数为输出参数，客户程序必须在调用本函数
之前分配足够长的空间，其最小值为1024字节，
如果未给本参数分配空间或分配的空间长度小于实
际返回的长度，客户程序将会出现内存保护错误），
最后以管道分割符号’|’结尾。
联机标志在读卡和门诊挂号时，从动态库的返回参数中取该
笔业务是联机还是脱机交易，HIS需要保存，后续
的明细录入和结算交易时，需要传入该标识。
返回值说明 :
0 –成功，表示此次交易请求成功，业务处理也正常
< 0 －错误，包括系统级别错误（网络、主机、数据库）和业务级别错
误，系统级别错误由动态库将错误信息写入输出参数，业务级别错误由后
台通过输出参数提示错误信息。
错误输出机制说明 :
Web应用返回给动态库的返回参数格式为：中心交易流水号^业务周期号^输出参数^交易相应码^，动态库接收到返回参数后，根据交易相应码判断交易处理成功与否，交易处理成功，则动态库返回值为0，否则，将交易相应码转换为小于0的返回值。动态库返回给开发商的出参，去掉交易相应码交易流水号说明：
规则：时间(14)+医院编号(8)+流水号(4)，之间用-分隔
例：20060101083030-10011001-0001
业务周期号说明：
说明：医院编号(8)＋操作员编号(最大8位)＋时间(14)+流水号(4)，之
间用-分隔
例：10011001-99999999-20060101083030-0001
注：4位流水号可以循环使用
交易编码说明：
交易编码为四位编码，第一位标志交易性质，后面三位表示流水号
序号交易码功能简介交易性质
1 1 1 1 0 医疗费用信息汇总查询
2 1 2 1 0 明细对帐请求查询
3 1 1 0 0 医疗费用信息查询查询
4 1 2 0 0 费用明细信息查询查询
5 1 3 0 0 信息批量下载查询
6
1 4 0 0 参保人员基本信息及其医保个人
帐户查询
查询
7 1 5 0 0 医疗待遇封锁信息查询查询
8 1 6 0 0 个人审批信息查询
99 1 0 0 签到认证交易109 1 1 0 签退认证交易
11 2 1 0 0 读卡主体交易
12 2 1 1 0 修改卡密码主体交易
13 2 1 2 0 校验卡密码动态库交易
14 2 2 1 0 门诊/住院登记主体交易
15 2 2 3 0 登记(挂号)信息修改主体交易
16 2 2 4 0 登记(挂号)撤销主体交易
17 2 3 1 0 费用明细上报主体交易
18 2 3 2 0 费用明细撤销主体交易
19 2 4 1 0 结算主体交易
20 2 4 2 0 预结算主体交易
21 2 4 3 0 结算撤销/取消报销主体交易
22 2 6 1 0 药店收费预结算主体交易
23 2 6 2 0 药店收费结算主体交易242 5 1 0 中心报销保存处方主体交易
25 3 1 1 0 医院审批信息上报申报业务
26 3 1 2 0 医院审批信息上报撤销申报业务
27 3 1 3 0 个人参加险种信息查询
28 4 3 0 0 结算信息冲正主体交易
29 4 5 0 0 查询系统时间查询
30 5 1 0 0 将卡中密码存入数据库主体交易
31 5 1 1 0 从数据库获取卡密码查询
32 6 1 0 0 医疗类别变更主体交易
33 5 2 0 0 医院端卡封锁主体交易
三、接口交易设计
1、查询类
A、交易功能
该交易主要完成诸如中心药品目录、诊疗项目目录、服务设施目录、病种目录等的查询及下载，同时还包括个人基本信息及帐户信息、封锁信息等的查询业务。对于中心药品目录、诊疗项目目录、服务设施目录、病种目录等的查询交易，下载时提供以TAB分隔的TXT文件。
B、交易设计
1）、批量数据查询下载
交易说明：批量下载中心目录等基础数据，然后对中心的药品目录和诊疗项目目录在his系统进行对照，上传处方时，根据对照结果，同时上传医院编码名称和中心编码。
项目编码项目名称说明
01 药品目录
02 诊疗项目信息
03 费用类别信息
04 病种信息
05 项目和一次性材料对应关系此交易为了HIS对项目与一次
性材料的控制。
输入参数：
编号名称长度约束说明
1 项目编码VARCHAR2(3) NOT
NULL
确定需要下载信息的种类
2 开始日期VARCHAR2(14) NOT
NULL YYYYMMDDHH24MISS
开始时间之后维护和发生变化的时间.
输出参数:
编号名称长度约束说明
1 文件路径及文件名称VARCHAR2(200) 参见配置信息
说明：下载文件的路径为：当前文件绝对路径\YBDLOAD\文件名.txt；文件名的命名规则为：
01：YPML_下载数据开始日期；
02：ZLXM_下载数据开始日期；
03：SFXMBM_下载数据开始日期；
04：BZXX_下载数据开始日期；
05：XMDYGX_下载数据开始日期；
2）、医疗费信息汇总
说明：该请求返回医疗费总额和各项费用合计，HIS系统中要进行对帐，先医疗费信息汇总
请求，当返回的费用合计与HIS系统中不符时，才有必要发送医疗费用信息查询交易。
输入参数：
编号名称长度约束说明
1业务周期号VARCHAR2(36) NOT NULL
2his医疗费总额VARCHAR2(10) NOT NULL 含两位小数
3His帐户支付合计VARCHAR2(10) 含两位小数
4His现金支付合计VARCHAR2(10) 含两位小数
5His统筹基金支付合计VARCHAR2(10) 含两位小数
6His救助金支付合计VARCHAR2(10) 含两位小数
7His公务员补助合计VARCHAR2(10) 含两位小数
8His建国前老工人基金合计VARCHAR2(10) 含两位小数
输出参数:
编号名称长度约束说明
1 医疗费总额VARCHAR2(10) 含两位小数
2 帐户支付合计VARCHAR2(10) 含两位小数
3 现金支付合计VARCHAR2(10) 含两位小数
4 统筹基金支付合计VARCHAR2(10) 含两位小数
5 救助金支付合计VARCHAR2(10) 含两位小数
6 公务员补助合计VARCHAR2(10) 含两位小数
7 建国前老工人基金合计VARCHAR2(10) 含两位小数
8 对帐标志VARCHAR2(10) 0 ：HIS与中心基金相同
1 ：HIS与中心基金不同
3)、明细对帐请求
输入参数：
编号名称长度约束说明
1住院号VARCHAR2(18) NOT NULL
输出参数:
编号名称长度约束说明
1费用总额VARCHAR2 (10) NOT NULL 含两位小数
2自理费用总额VARCHAR2(10) 含两位小数
3自费费用总额VARCHAR2(10) 含两位小数
4）、医疗费信息查询
说明：当汇总医疗费用信息查询结果与HIS不同时，发起该交易，由HIS提供程序进行对帐。
下载文件的路径为：当前文件绝对路径\YBDLOAD\ YLFY_下载数据开始日期.txt
输入参数：
编号名称长度约束说明
1 开始时间VARCHAR2(14) NOT NULL YYYYMMDDHH24MISS
2 终止时间VARCHAR2(14) NOT NULL YYYYMMDDHH24MISS
输出参数:
编号名称长度约束说明
VARCHAR2(200) 参见配置信息
1 文件路径及文件
名称
5）、医疗费用明细信息查询
当明细对帐结果与HIS不同时，发起该交易，由HIS提供程序进行对帐。
下载文件的路径为：当前文件绝对路径\YBDLOAD\ FYMX_住院流水号.txt。
输入参数：
编号名称长度约束说明
VARCHAR2(18) NOT NULL
1 住院(门诊)流水
号
输出参数:
编号名称长度约束说明
VARCHAR2(200) 参见配置信息
1 文件路径及文件
名称
6）、医疗待遇封锁信息查询
输入参数：
编号名称长度约束说明
1单位编号VARCHAR2(14) NOT NULL
2个人编号VARCHAR2(14) NOT NULL
3个人卡号VARCHAR2(20)
4医疗类别VARCHAR2(3) NOT NULL
5判断时间VARCHAR2(8) NOT NULL 判断有效期，YYYYMMDD
输出参数：
编号说明类型备注说明
1 封锁信息VARCHAR2(100) 多个封锁信息用‘$’分割,
数据项目用‘|’。
封锁类别|封锁原因|基金
类别|$
注：
封锁类别：0表示没有封锁，
1表示全封锁，
2表示部分封锁，
3表示卡封锁。
在录入信息前进行封锁控制，避免录入挂号信息后再提示封锁。
7）、个人审批信息
输入参数：
编号名称长度约束说明
1 个人编号VARCHAR2(14) NOT NULL
2 开始时间VARCHAR2(14) NOT NULL YYYYMMDDHH24MISS
输出参数：
编号名称长度约束说明
1 审批信息VARCHAR2(200) 多个审批信息用‘$’分割,
数据项目用‘|’。
审批类别|审批编号|$ 8）、个人参加险种信息
输入参数：
编号名称长度约束说明
1 个人编号VARCHAR2(14) NOT NULL
2 开始时间VARCHAR2(14) NOT NULL YYYYMMDDHH24MISS
输出参数：
编号名称长度约束说明
1 险种信息VARCHAR2(200) 多个险种用‘$’分割, 多
个数据项目用‘|’。
险种|$
9）、查询系统时间
输入参数：
无。
输出参数：
编号名称长度约束说明
1 系统时间VARCHAR2(14) YYYYMMDDHH24MISS 10）、将卡中密码存入数据库
输入参数：
编号名称长度约束说明
1 卡密码VARCHAR2(20) 密文
输出参数：
无
11）、从数据库获取卡密码
输入参数：无
输出参数：
编号名称长度约束说明
1 卡密码VARCHAR2(20) 密文形式返回。如果没有取
到，返回A
12)、医疗类别变更
输入参数：
编号名称长度约束说明
1 原发送方交易流水号VARCHAR2(30) NOT NULL
2 门诊/住院流水号VARCHAR2(30) NOT NULL
3 原医疗类别VARCHAR2(3) NOT NULL
4 新医疗类别VARCHAR2(3) NOT NULL
说明：原医疗类别只能为普通门诊、药店购药、未定住院. 对原医疗类别为普通
门诊、药店购药，可以选择新医疗类别为门诊慢性病，门诊特殊病，门诊特定项
目。
输出参数：无
2、认证类
A、交易功能
签入签出是为了验证客户端为合法的用户，一台客户端可以正常进行交易处理，必须要签入，不签入不允许交易。
为了满足联机方案下合理控制客户端的用户数，在签入时由动态库向医保接口的数据库里插入机器的物理MAC地址和用户数目做为交易的入参，并
检索该医院的物理地址数量是否超过限制数量；在签出时由动态库更新该表
内的该医院连接信息。
说明：认证交易开发商直接调用，不需要传入入参。动态库获取客户端的MAC地址和授权用户数目后做为入参传给接口。
B、交易设计
1）、签到
输入参数：无
输出参数:
编号名称长度约束说明1业务周期号VARCHAR2(36) NOT NULL
2）、签退
输入参数：无
输出参数:无
3、交易功能
该类交易主要完成参保患者挂号登记、处方上报、结算及撤销结算等的各项业务处理。
在有关事务提交方面，不管是联机情况还是脱机方案，都是由医保接口
自动控制事务，而不是由客户端控制事务。如果客户端需要取消事务，则可以发起撤销交易请求。
4、动态库交易类
A、交易功能
该类交易主要完成接口部分只向动态库公开，不向开发商公开的交易。
交易卡密码的输入参数为动态库截取后传给后台。
B、交易设计
开发商调用所有需要动态库读卡的交易时，动态库先调用校验卡密码的交易，校验成功再调用正常的业务。
输入参数：
编号说明类型约束备注
1 密码VARCHAR2(20)
输出参数:无
四、故障处理说明：
本系统采用的基本错误处理方法和原则：统一采用C++ try-catch错误方法，所有错误最终必须以界面形式向用户说明。用一览表方式说明各类可能的错误或故障出现时系统的处理方法和补救措施。
UB接口EM设计方案完整版
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直接电气连接。 三、连接器设计
第三方支付系统总体方案设计
在线支付系统 总体设计方案说明书 V1.0 2019 年 8 月 6 日
文档修订记录 日期版本说明作者2019-08-06 V1.0 创建XXX
目录 前言 (5) 1.1 文档说明 (5) 1.2 项目愿景和范围 (5) 1.3 本期系统建设目标 (6) 1.4 方案特点 (6) 1.5 系统功能需求 (7) 1.5.1 用户分析 (7) 1.5.2 系统功能 (7) 1.6 技术需求 (8) 1.6.1 主要系统指标 (8) 总体设计 (9) 2.1 设计原则 (9) 2.1.1 基本原则 (9) 2.1.2 可配置、可扩充原则 (10) 2.1.3 面向对象的分析、设计和编码 (11) 2.1.4 组件技术 (12) 2.1.5 模块化设计 (12) 2.2 系统功能结构 (12) 2.3 系统软件架构 (15) 2.4 与其它系统的接口 (16) 2.4.1 与银行的接口 (16) 2.4.2 与企业商户平台接口 (16) 2.5 在线支付系统数据存储设计 (17) 2.6 应用系统扩展能力 (19) 系统功能说明 (21) 3.1 在线支付子系统 (21) 3.1.1 在线支付模块 (21) 3.2 商户平台子系统 (22) 3.2.1 商户充值模块 (22) 3.2.2 商户提现模块 (22) 3.2.3 商户转账模块 (22) 3.2.4 交易模块 (22) 3.2.5 商家服务 (23) 3.2.6 系统管理 (24) 3.3 系统管理子系统 (25) 3.3.1 客户管理 (25) 3.3.2 运营管理 (26) 3.3.3 客户结算管理 (26) 3.3.4 客户账户管理 (28) 3.3.5 银行管理 (29) 3.3.6 网关订单及支付管理 (30) 3.3.7 交易管理 (32) 3.3.8 清结算管理 (33) 3.3.9 风控管理 (35) 3.3.10 订单掉单管理 (36)
医保接口方案(提供第三方)
新农医接口方案 （提供第三方） 中软国际 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)要求医院提供独立的新农医服务器
医保不用选也能报销的北京市医保定点专科和A类医院名单
医保不用选也能报销的北京市医保定点专科和A类医院名单A类医院 A类定点医院 1、首都医科大学附属北京同仁医院 2、首都医科大学宣武医院 3、首都医科大学附属北京友谊医院 4、北京大学第一医院 5、中国医学科学院北京协和医院 6、北京大学人民医院 7、北京大学第三医院 8、北京积水潭医院 9、中国中医研究院广安门医院 10、首都医科大学附属北京朝阳医院 11、中日友好医院 12、北京大学首钢医院 13、首都医科大学附属北京中医医院 14、北京市健宫医院 15、北京市房山区良乡医院 16、北京市大兴区人民医院 17、首都医科大学附属北京天坛医院 18、北京市石景山医院
19、北京世纪坛医院（北京铁路总医院） 专科医院和中医医院 东城 1151001北京中医药大学东直门医院中医三级甲 1151002首都医科大学附属北京中医医院中医三级甲 1151003首都医科大学中医药学院附属鼓楼中医医院中医二级甲1151004中国中医研究院骨伤科医院中医三级 1151005中国中医研究院针灸研究所门诊部中医 1151006北京天安中医院中医一级 1151007首都医科大学中医药学院东城中医门诊部中医 1151008北京市东城区中医药学会东单中医门诊部中医 1152001首都医科大学附属北京妇产医院专科三级甲 1152002北京市东城区妇幼保健院专科二级甲 1153001北京市东城区精神卫生保健院专科一级甲 1154001北京地坛医院专科三级甲 1155001北京市东城区口腔医院专科 1155002北京市东城区急救站专科 1155003北京地坛口腔门诊部专科 西城 2110013北京市丰盛中医骨伤专科医院（北京市西城区丰盛医院）中医二级2151001北京中医药大学附属护国寺中医医院中医二级甲
系统对接方案
系统对接设计 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医保接口设计规范解析
HIS医保接口设计规范 一、导言 BSHIS在两年前就开始涉及医保软件接口的设计和实施了。随着时间的推移，越来越多的新签医院工程也要求实施医保；而一些以前上的老工程，也开始在实施各地的医保政策。可以说，医保的实施已经成为HIS软件在医院实施中一个很重要的组成部分。从某种意义上讲，医保实施的好坏也已经直接影响了工程实施的进度和效果。 由于医保政策的复杂性，再加上政策有很大的地区差异。在实施过程中，软件设计人员遇到了很多比较复杂也或者很难于解决的问题。另外，由于医保政策一般都是刚刚指定出来不久的。所以，在实施的过程中，经常会遇到修改政策的过程。这在一定程度上给软件设计和实施增加了不少的难度。同时，也会导致医保接口软件设计上的不确定性，直接的后果是可能导致很多的重复劳动。 结合前面很多人医保实施成功和失败的教训，对在医保接口设计过程中的，好的方法进行了归纳，并尽量给出一种比较完善和完美的设计解决方法和规范，可帮助医保实施和软件接口设计人员比较好地实施医保。当然，现在只是个草稿，需要医保实施实践不断地扩充此规范，以至形成一种比较固定的综合解决方案。 二、关于医保政策软件和应对方案 我们通过对北京安宁盈科、创智公司、东大阿儿派、杭州新世纪、建达电子、万达公司等各个医保险政策软件提供商提供的接口方案进行了分析，总计出他们之间的共性如下： 1、一般都提供DOS和WINDOWS两套方案，DOS下一般用文件形式传递 数据，WINDOWS下一般以WIN32 API的形式在HIS和医保前置机之间 调用和传递数据（DLL提供了政策函数）。我们以后者为重点说明问题。 2、政策函数一般分为两类：单个函数和多个函数两种类型设计 多个函数是指每中业务或者比较相似的业务为一个函数，这样组成结算、登记、退费等多个函数。如：杭州新世纪、东大阿儿派 单个函数是指所有的业务都用一个函数实现。参数一般用结构字符串实现。 如：上海万达公司。 3、明细数据一般都和结算时必要的项目数据分开传递到医保中心服务器。 这样做的目的是为了减少网络阻塞。如果是同时要传的，一般在结算准 备阶段就已经将数据计算好了。 4、平时发生费用时，一般分成两种方式处理： 1）平时的自负比例按HIS中设置的算，也不需要审批
MES系统与ERP接口设计解决方案文件
智慧工厂 一、方案概述 塔网智慧工厂的构建基于公司的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建设背景 (1) 2总体设计 (4) 2.1建设目标 (4) 2.1.1建设统一支付平台，推进“互联网+政务服务” (4) 2.1.2丰富缴款方式，拓展支付渠道，让缴款人缴款更方便 . 4 2.1.3规范非税收入收缴，满足收缴电子化改革的要求 (4) 2.1.4配合财政电子票据改革，推广使用财政电子票据 (5) 2.1.5实现各单位业务办理平台的最小化改造 (5) 2.2总体架构设计 (5) 2.2.1缴费平台 (6) 2.2.2电子票据管理系统 (6) 2.2.3可对接财政非税银行接口 (7) 2.2.4可对接非税电子收缴系统 (7) 2.2.5为开票单位业务系统提供标准接口 (7) 2.2.6可对接银行代理财政中间业务系统 (7) 3方案内容 (8) 3.1方案概述 (8) 3.2方案实现 (9) 3.2.1缴费平台建设 (9) 3.2.2电子票据系统建设 (10) 3.3方案建设 (12) 3.3.1功能设计 (12) 3.3.2数据接口 (23)
3.3.3业务流程 (25) 3.3.4数据交互 (32) 4方案价值 (39) 4.1对地方政府的价值 (41) 4.2对地方财政的价值 (41) 4.3对执收单位的价值 (42) 4.4对缴款人的价值 (43)
1建设背景 2016年9月，国务院印发了《国务院关于加快推进“互联网+政务服务”工作的指导意见》（国发〔2016〕55号），提出如下工作目标：2017年底前，各省（区、市）人民政府、国务院有关部门建成一体化网上政务服务平台，全面公开政务服务事项，政务服务标准化、网络化水平显著提升；2020年底前，实现互联网与政务服务深度融合，建成覆盖全国的整体联动、部门协同、省级统筹、一网办理的“互联网+政务服务”体系，大幅提升政务服务智慧化水平，让政府服务更聪明，让企业和群众办事更方便、更快捷、更有效率。 为贯彻落实《国务院关于加快推进“互联网+政务服务”工作的指导意见》（国发〔2016〕55号），加快构建陕西省“互联网+政务服务”体系，推动政府职能转变，提升政务服务水平，最大程度利企便民，2017年1月9日陕西省省政府办公厅发布《陕西省人民政府关于加快推进全省“互联网+政务服务”工作的实施意见》。要求2017年底前，基本建成省级“互联网+政务服务”平台，全面公开政务服务事项，实现统一申报、统一受理、统一反馈和全流程监督，显著提升省级政务服务能力。到2019年，建成省级统筹、部门协同、贯通市县乡村的多级联动“互联网+政务服务”体系，做到政务服务事项“应上必上、全程在线”，实现办事一号申请、一窗受理、一网通办，大幅提升政务服务标准化、网络化、智慧化水平。 同时，由于传统纸质财政票据印制成本高、开具效率低下、管理不规范、传输不便捷、保管存放要求高、报销入账程序复杂、不便于
医疗保险接口功能规范
医疗保险接口功能规范 第一条《医疗保险接口功能规范》是用于协助整个医院，按照国家医疗保险政策对医疗保险病人进行各种费用结算处理的计算机应用程序，其主要任务是完成医院信息系统与上级医保部门进行信息交换的功能，包括下载、上传、处理医保病人在医院中发生的各种与医疗保险有关的费用，并做到及时结算。 《医疗保险接口功能规范》必须符合国家、地方的有关法律、法规、规章制度的要求。 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年规划方案
创业医院信息管理系统 医 保 控 费 系 统 医疗事业部 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接口规范性设计 系统平台中的接口众多，依赖关系复杂，通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口
……北京19所A类定点医疗机构名单
关于公布2009年度北京市基本医疗保险A类定点医疗机构名单的通知 京医保发〔2009〕65号 -------------------------------------------------------------------------------- 各区、县劳动和社会保障局医疗保险科、医疗保险经办机构，各定点医疗机构： 为进一步做好北京市基本医疗保险定点医疗机构管理工作，为参保人员提供更加优质的服务，根据原北京市劳动和社会保障局《关于印发<北京市基本医疗保险定点医疗机构分级分类管理办法>的通知》(京劳社医保发［2006］107号)精神，我们对全市基本医疗保险定点医疗机构医疗保险管理情况、医疗费用控制及综合考评情况进行认真分析和研究，首都医科大学附属北京同仁医院等19家定点医疗机构(具体名单附后)符合A类定点医疗机构条件，认定为2009年度北京市基本医疗保险A类定点医疗机构。 附件：2009年度北京市基本医疗保险A类定点医疗机构名单 北京市医疗保险事务管理中心 二〇〇九年八月十二日 附件： 2009年度北京市基本医疗保险A类定点医疗机构名单 1、首都医科大学附属北京同仁医院 2、首都医科大学宣武医院 3、首都医科大学附属北京友谊医院 4、北京大学第一医院 5、中国医学科学院北京协和医院 6、北京大学人民医院 7、北京大学第三医院 8、北京积水潭医院 9、中国中医科学院广安门医院 10、首都医科大学附属北京朝阳医院 11、中日友好医院 12、北京大学首钢医院 13、首都医科大学附属北京中医医院 14、首都医科大学附属北京天坛医院 15、北京世纪坛医院(北京铁路总医院) 16、北京市健宫医院 17、北京市房山区良乡医院 18、北京市大兴区人民医院 19、北京市石景山医院
医保收费接口规范
南平医保医院接口规范 一、接口设计主体思路： 采用文本文件交换信息的方式，每个业务接口主要步骤均为：医院程序删除应答文件（如果存在），提交一个请求文件，医保程序检测到后自动解释，生成一个回答文件，并删除原来的请求文件，医院程序检测到应答文件生成后就去读取医保程序返回的信息。 文件的结构主要借鉴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数据格式，通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。 在接口协议中，包含接口的版本信息，通过协议版本约束服务功能规范，支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持多个版本的客户端，从而使得组件服务的提供者和使用者根据实际的需要，独立演进，降低系统升级的复杂度，保证系统具备灵活的扩展和持续演进的能力。
西安市医保定点医院名单
西安市医保定点医院共104家 （一）75所综合医院 第四军医大学西京医院三甲长乐西路17号 第四军医大学唐都医院三甲东郊新寺路 西安交通大学医学院第一附属医院三甲雁塔西路277号 西安交通大学医学院第二附属医院三甲西五路157号 陕西省人民医院三甲友谊西路256号 西安市中心医院三甲西五路161号 西安市第一医院三甲粉巷30号 西安市第四医院三甲解放路21号 解放军第323医院三甲建设西路66号 解放军第451医院三甲友谊东路269号 武警陕西总队医院三甲南二环东段88号 长安医院三甲（相当）文景路17号 高新医院三甲（相当）团结南路16号 西电集团医院三乙丰登路97号 陕西省友谊医院三乙友谊西路277号 陕西省辅仁医院三乙纺织城纺东街167号 西安市铁路中心医院三甲南二环东段151号 兵器工业521医院二甲丈八东路12号 西安医学院附属医院二甲沣镐西路48号 解放军第518医院二甲公园南路11号 陕西省建材医院二甲咸宁东路512号 中铁一局西安中心医院二甲南二环东段319号 陕西省第二人民医院二甲尚勤路3号 陕西省交通医院二甲大学南路276号 西安唐城医院二甲太华北路99号 陕西正和医院二甲西影路486号 武警工程学院医院二甲三桥武警路4号 西安市北方医院二甲长乐中路170号 西安市东方医院二甲咸宁东路106街坊新科路28号西安市华山中心医院二甲康乐路17街坊8号 庆安集团有限公司职工医院二甲大庆路636号 西安市第五医院二甲（相当）西关正街112号 西安市第二医院二级（相当）糖坊街65号 西安远东医院二乙大庆路636号 陕西省新安中心医院二级（相当）南二环中段36号 民航西安医院二级（相当）沣镐路2号 陕西省博爱医院二甲电子二路52号 灞桥区人民医院二乙灞桥街28号 西安庆华医院二乙灞桥田红正街1号 北车集团西安车辆厂职工医院二甲建章路南段54号 陕西航天医院二甲灞桥田洪正街303号 西安西郊纺织医院二级（相当）阿房二路1号
医疗保险定点医院接口设计方案
荆州普爱康复医院 医保定点医院接口设计方案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院内HIS 系统的接口设计方案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施，制定医疗保险定点医院院内HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁，医保接口方案采用了联机、脱机相结合的处理方案，社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成，如下图所示： 4、数据传输 3、圈存 1、医保交易 2、社保卡交易 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、
数据库系统组成。 读卡 医保接口动态库 医保接口WEB 应 用 社保中心数据 库 社保卡交易医保业务处理 医保交易 社保中心数据库服务器 社保中心应用服务器 医院客户端医院客户端医院客户端 医保接口动态库 医保接口 交易应用 联机方案 脱机方案
社保中心数据库服务器 社保中心应用服务器 医院客户端医院客户端医院客户端 医保前置机 医保前置机 医保前置机 数据传输服务器 圈存服务器医保接口动态库 数据传输系统 圈存系统 脱机方案 软件环境 操作系统：服务端为UNIX ，客户端为WINDOWS2000以上； 应用服务器：WEBLOGIC8以上版本； 数据库：ORACLE10.2； 4、技术路线 联机时： 由医保接口动态库通过向医保接口WEB 应用发送HTTP 请求进行交易；医保接口的事务提交则由医保接口WEB 应用管理；所有业务均通过交易体现。 脱机时： 由医保接口动态库通过OCI 接口，向数据库发送数据操作请求，医保接口的事务提交是用接口内部来实现的，它需要HIS 有医保前置机，所有业务均通过交易体现， 与联机方式的交易格式是相同的。 脱机/联机时： 在中心网络畅通时使用联机交易， 在网络不通时走脱机模式，在读卡和登记两个交易判断是否联机，并返回给HIS 联机标识，之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱
……温州市区定点医疗机构名单和医保定点药店
温州市区定点医疗机构名单和医保定点药店: （定点医疗机构50家，医保定点药店5家） 第七批基本医疗保险定点医疗机构名单 瓯海区茶山中心卫生院、瓯海区丽岙镇中心卫生院、瓯海区南白象街道卫生院、瓯海区仙岩镇卫生院、瓯海区泽雅中心卫生院、龙湾区海城街道中心卫生院、市环境卫生管理处医务室（限环卫系统参保人员门诊）、鹿城区老干部保健医疗门诊部。 第六批基本医疗保险定点医疗机构名单 瓯海区第二人民医院（原新桥中心卫生院二级）地址：瓯海区新桥金蟾大道119号
温州市瓯海区瞿溪中心卫生院（一级）地址：瓯海区瞿溪镇兴学街71号 温州经济技术开发区滨海园区社区卫生服务中心（一级）地址：温州经济技术开发区滨海园区南龙商住区5幢温州经济技术开发区龙湾园区社区卫生服务中心（一级）地址：温州经济技术开发区龙湾园区玉苍西路83号温州市疾病预防控制中心门诊部（限结核病门诊）地址：温州市飞霞桥路结防大楼 温州市财税职工中专专业学校医务室（限门诊）地址：温州市鹿城后巷47号 鹿城区人民医院分院（鹿城微创医院一级）地址：鹿城路93号 鹿城区藤桥中心卫生院（一级）地址：藤桥镇北市东路46号 鹿城区南郊乡卫生院（一级）地址：民航路2号 温州市公安局医务室（限门诊）地址：鹿城区金桥路2号 第五批基本医疗保险定点医疗机构（限门诊）名单
温州大学（筹）医务室地址：温州市瓯海区茶山高教园区 温州市温州职业技术学院医务室地址：温州市瓯海区茶山高教园区 温州市瓯海区老干部医务室地址：温州市将军桥繁新路4—101 第四批基本医疗保险定点医疗机构名单及地址 1、温州市龙湾区人民医院（参照一级）地址：龙湾区状元镇前潘路51号 2、温州市龙湾区第一人民医院（参照二级）地址：龙湾区永中街道中央汇路62号 3、温州手足外科医院（参照二级）地址：温州市信河街大士门27号 4、温州糖尿病专科医院（参照一级）地址：温州经济技术开发区鳌江北路98号 5、温州牙科医院（参照一级）地址：府前街府前大楼A幢2楼 6、温州曙光骨伤医院（参照二级）地址：温州市龙湾区状元镇龙飞西路 7、温州市中西医结合医院市级机关医务室（限门诊）地址：温州市行政中心东辅楼1楼 8、温州市老干部医务室（限门诊）地址：温州市蛟翔巷52号 9、温州市社保门诊部（限门诊）地址：温州市黎明西路29弄5号。
医疗保险定点医院接口方案及对策
荆州普爱康复医院 医点医院接口设计案 【摘要】本文主要介绍了医疗保险定点接口医院的医保信息系统的与院HIS 系统的接口设计案。 引言 为了更好的加快金保工程医保信息系统统一应用软件的实施，制定医疗保险定点医院院HIS 系统与医保系统的对接接口。医保接口做为连接医疗保险与诸多定点医疗机构之间的桥梁，医保接口案采用了联机、脱机相结合的处理案，社保卡全部采用Memory 卡. 一、总体设计 1、软件体系结构 医保接口系统主要由医保交易、社保卡交易、圈存、数据传输等子系统组成，如下图所示： 2、系统运行体系 医保接口系统主要由医保接口交易、社保卡交易、圈存系统、数据传输系统、数据库系统组成。
小型定点医疗机构也建议采用宽带网，但可以采用ISDN或普通拔号上网。
医院客户端医院客户端医院客户端 ◆ 脱机案 医院客户端医院客户端医院客户端 脱机方案 ? 软件环境 操作系统：服务端为UNIX ，客户端为WINDOWS2000以上； 应用服务器：WEBLOGIC8以上版本；
数据库：ORACLE10.2； 4、技术路线 ?联机时： 由医保接口动态库通过向医保接口WEB应用发送HTTP请求进行交易； 医保接口的事务提交则由医保接口WEB应用管理；所有业务均通过交易体现。 ?脱机时： 由医保接口动态库通过OCI接口，向数据库发送数据操作请求，医保接口的事务提交是用接口部来实现的，它需要HIS有医保前置机，所有业务均通过交易体现，与联机式的交易格式是相同的。 ?脱机/联机时： 在中心网络畅通时使用联机交易，在网络不通时走脱机模式，在读卡和登记两个交易判断是否联机，并返回给HIS联机标识，之后的业务(费用录入)需要按照这个联机标识,建议只在不使用医保基金的业务才使用脱机，其他必须联机. 联机交易注意事项： 动态库返回成功，开发商才能处理，否则容易造成中心和医院事务不一致。 如果由于线路等问题，动态库无法接收web应用返回的交易处理结果，则返回失败，由动态库保证中心业务的冲正。 脱联结合时各地市业务脱机情况： 城市: , , 宿迁