医疗保险标准化信息系统
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
深圳天源迪科计算机有限公司
SZHI-HISI/PDD 版本:0.1
状态:CF
深圳市医疗保险标准化信息系统
――医院系统接口 概要设计说明书(讨论稿)
本文件属深圳天源迪科计算机有限公司所有 未经书面许可,不得以任何形式复印或传播
文件建立/修改记录
目录
1引言 (4)
1.1 编写目的 (4)
1.2 文档约定 (4)
1.3 背景 (4)
1.4 预期的读者和阅读建议 (4)
1.5 参考文献 (4)
2总体设计 (5)
2.1 需求规定 (8)
2.2 运行环境 (8)
2.3 基本设计概念和处理流程 (9)
2.4 结构................................................................................................. 错误!未定义书签。
2.5 功能需求与程序设计 (9)
2.6 人工处理过程 (16)
3运行设计 (16)
3.1 运行模块组合 (16)
3.2 运行控制 (16)
3.3 运行时间 (16)
4数据规范设计.................................. 错误!未定义书签。
4.1 逻辑结构设计要点......................................................................... 错误!未定义书签。
4.2 物理结构设计要点......................................................................... 错误!未定义书签。
4.3 数据结构与程序关系..................................................................... 错误!未定义书签。
5系统出错处理设计. (16)
5.1 出错信息 (16)
5.2 补救措施 (16)
6系统维护设计 (17)
1引言
1.1 编写目的
编写本概要设计说明书的目的在于为定点医院系统接口定义一个概要的设计方案,使社保机构用户方和医院系统用户方对该接口采用的技术方案和接口实现过程有一个总体上的了解,作为医院系统接口详细设计的基础的同时,该设计方案也将为医院HIS系统开发商提供一份系统接口改造的技术说明书。
1.2 文档约定
“深圳医保――医院系统接口”产生的文档和文档格式遵循公司ISO9001质量管理体系要求。
1.3 背景
♦系统名称:深圳医保――医院系统接口
♦任务提出者:软件三部
♦开发者:软件三部
♦系统用户:深圳市社会保险局
1.4 预期的读者和阅读建议
本概要设计说明书的使用人群为:社保机构“医保标准化信息系统”项目领导和主要技术工程师,医院系统最终用户代表,医院系统开发商,深圳市医疗保险标准化信息系统的系统分析设计人员、软件开发人员,系统测试人员。
1.5 参考文献
《统一软件开发过程》机械工业出版社[美]Ivar Jacobson
Grady Booch
James Rumbaugh
《软件需求》Microsoft Press/机械工业出版社[美]Karl E.Wiegers
《DIC72002软件需求规格说明书编制规范》深圳天源迪科计算机有限公司
《DIC42300文件控制程序》深圳天源迪科计算机有限公司
《DIC42301质量管理体系文件编码规则》深圳天源迪科计算机有限公司
《DIC42302受控文件管理条例》深圳天源迪科计算机有限公司
2基本概念和技术方案
2.1 接口技术及方案介绍
由于各定点医疗机构的系统平台和软件多不相同,所以采用Corba(公共对象请求代理)技术规范来实现分布式计算。
公共对象请求代理程序体系结构(corba)是编写分布式对象系统的一个统一标准。
Corba是一种与语言无关的标准,它允许由多种语言编写的代码相互通信,是一个多语言编写的代码进行合作的理想平台。
2.1.1使用Corba工作过程中的概念说明
对象请求代理程序:
对象请求代理程序即通常说的orb,是网络中对象通信的助手。
Orb是分布式对象间的介质,可以使不同的应用程序在不知道底层通信机制的情况下相互通信。
Orb负责查找所调用方法的对象,处理参数,并返回结果。
对象实现和对象引用:
当你完成了corba对象实现时,该对象可以通过网络被远程客户任意调用。
远程客户对corba对象实现的接口进行操作(不直接操作corba对象)。
从而实现接口/实现的隔离。
CORBA对象适配器(POA):
当对象被访问时,对象适配器负责将对象引用映射到对象实现中。
当客户调用某操作时,orb、对象适配器和对象实现共同计算出哪个实现对象应当被调用。
如果客户调用了一个未读入内存的对象实现的方法,则对象适配器将激活该对象(在内存中初始化),使其可以响应客户的需要。
接口定义语言:
即IDL,IDL是语言无关的,平台无关的一种中介语言。
你可以通过映射工具将IDL映射成具体的语言。
2.1.2基本结构
2.1.3计划采用结构说明
2.1.4使用服务类型说明
CORBA事件服务:
是一种信息传递机制,允许对象动态地注册或注销他们感兴趣的特定事件。
时间服务的两种模式:
(1)采用“推”模式
HIS实现步骤:
✧绑定到ORB和事件信道上;
✧从事件信道中获取一个推提供者代理;
✧创建一个推消费者;
✧将消费者连接到事件信道;
✧在一个push()实现中被接收。
这种模式适用于数据的单向发送。
(2)采用“拉”模式
HIS实现步骤:
✧绑定到ORB和事件信道上;
✧从事件信道中获取一个拉提供者代理;
✧创建一个拉消费者;
✧将消费者连接到事件信道;
✧对拉提供者代理调用try_pull()接口或者pull()接口并且将它转换为消息类型。
CORBA命名服务:
通过名称来定位ORB,一个Corba命名或事务的对象实例会接受客户端的请求,然后把处理的结果返回给客户,服务器端的程序只要运行在特定端口的网关机器上,接受用户的请求即可。
2.1.5医院接口实现途径
(1)社报局提供标准IDL文件,定义社报局提供的各服务规范。
(2)定点医疗机构根据IDL文件,对自己的系统进行改造,统一调用社报局提供的接口。
2.1.6接口服务的两种方案
定点医疗机构所需的个人信息,由社报机构提供。
定点医院HIS系统调用IDL定义的接
口,取个人信息(基本信息,参保信息,个人帐户等),送医疗明细数据。
针对数据交互量大的门诊结算,考虑两种方案:
方案一:
定点医疗机构HIS系统对门诊进行结算,将处方明细用“推”技术送至社报局。
最后需要双方约定,进行核算。
方案二:
定点医疗机构将处方明细送到社报机构,社报机构进行结算,将结算数据返回定点医疗机构。
定点医疗机构根据结算数据与病人结帐。
3总体设计
3.1 需求规定
本文档所涉及的主要业务需求的规格、功能、性能要求均采用《SZHI-HISI/SRS》(《“深圳市医疗保险标准化信息系统――医院系统接口”需求规格说明书》)中的定义,详细资料可参见系统文档《SZHI-HISI/SRS》。
3.2 运行环境
医院端(客户端):
HIS应用系统体系采用c/s结构;
系统服务器平台为WIN2000、WINNT;
数据库使用SQLSERVER等关系数据库;
HIS系统采用Windows标准应用,开发工具采用用PB等。
社保机构(服务端):
接口采用Corba体系结构;
服务器平台为IBM AS400;
数据库服务器使用DB2;
服务单元开发工具RPG/C++。
3.3 基本设计处理流程
医院系统接口实现模式见下下图描述:
corba服务器和应用服务器为社保机构的AS400,医院的HIS系统通过corba接口来调用corba服务。
接口改造过程描述:
(1)社保机构制定相应的接口标准、业务规范、数据规范;
(2)定点医院根据社保机构制定的业务规范、数据规范采用社保机构提供的医院接口标准进行医院HIS系统改造;
(3)医院HIS系统在发生与医保相关业务时调用接口规定的相应服务项目完成向社保机构医保系统服务请求的递交;
(4)社保机构医保系统根据医院相应请求实时完成相应的服务处理,并将服务结果返回医院系统;
(5)医院HIS系统医保相关业务处理完结。
接口服务单元实现过程描述:
(1)HIS系统调用接口发出医保业务相关服务请求;
(2)社保机构医保系统完成医保业务服务处理,并返回请求服务结果或结果集;
(3)HIS系统得到服务结果;
(4)HIS完成医保相关业务。
3.4 功能需求与程序设计
根据《SZHI-HISI/SRS》(《“深圳市医疗保险标准化信息系统――医院系统接口”需求规格说明书》)中对医保系统接口需求规格的详细描述、定义,系统从接口功能设计上分别作如下设计,接口定义文件(IDL)的内容见附件HISI.IDL。
3.4.1医保数据库服务器连接检查服务请求
功能需求:医保数据库服务器连接检查服务请求
服务编号:
服务名称:数据库连接检查
输入参数:(无)
内部处理:检查CORBA服务器到数据库的连接是否连通。
输出参数:返回连接状态
3.4.2时间服务请求
功能需求:时间服务请求
服务编号:
服务名称:取社保时间
输入参数:(无)
内部处理:取社保服务器的系统时间。
输出参数:社保系统时间
3.4.3医保资格验证请求
功能需求:时间服务请求
服务编号:
服务名称:医保资格验证
输入参数:医院标识码、医生标识码、参保人标识码
内部处理:调用社保黑名单进行相应对象的医保资格进行验证,具体包括定点医院资格验证、医院医生处方权验证、操作原权限验证、当前处理参保人员黑名单检查输出参数:医保资格标识
3.4.4医保通知请求
功能需求:医保通知请求
服务编号:
服务名称:医保信息发布
输入参数:时间参数、医院编号
内部处理:根据时间参数、医院编号,查找最新的医保通知。
输出参数:医保通知信息
3.4.5读取参保人情况请求
功能需求:读取参保人情况请求
服务编号:
服务名称:取参保人个人信息
输入参数:参保号
内部处理:通过参保号,取出社保系统数据库中个人基本情况。
输出参数:个人基本信息
3.4.6读取参保人所在单位基本情况请求
功能需求:读取参保人所在单位基本情况请求
服务编号:
服务名称:取参保人所在单位基本情况
输入参数:个人参保号码
内部处理:通过个人参保号码,取数据库中个人所在单位编号,根据单位编号取出单位基本情况和参保情况。
输出参数:单位基本情况和参保情况
3.4.7读取参保人参保情况请求
功能需求:读取参保人参保情况请求
服务编号:
服务名称:取个人参保情况
输入参数:个人参保号码
内部处理:通过个人参保号码,取数据库中个人参保情况。
输出参数:个人参保情况
3.4.8读取参保人医疗保险个人帐户情况请求
功能需求:读取参保人医疗保险个人帐户情况请求
服务编号:
服务名称:取个人帐户
输入参数:个人参保号码、时点
内部处理:根据参保号码,查找个人帐户的余额。
输出参数:个人帐户的余额
3.4.9读取参保人相关支付限额请求
功能需求:读取参保人相关支付限额请求
服务编号:
服务名称:取支付限额
输入参数:个人参保号码码、时点、支付限额类别
内部处理:根据个人费用历史,按照医保政策对参保人各支付限额进行计算。
输出参数:支付限额
3.4.10读取参保人缴费情况请求
功能需求:读取参保人缴费情况请求
服务编号:
服务名称:取缴费情况
输入参数:个人参保号码、时点
内部处理:根据个人参保号码、时点查找个人缴费历史
输出参数:个人缴费情况
3.4.11读取参保人消费情况请求
功能需求:读取参保人消费情况请求
服务编号:
服务名称:取消费情况
输入参数:个人参保号码、时点
内部处理:根据个人参保号码、时点查找个人消费历史
输出参数:个人消费情况
3.4.12读取医疗保险结算比例请求
功能需求:读取医疗保险结算比例请求
服务编号:
服务名称:取政策参数
输入参数:服务项目类别(分药品、诊疗项目)、服务项目名(或编码)
内部处理:根据服务项目类别、服务项目查找结算比例
输出参数:结算比例
3.4.13读取住院共济金请
功能需求:读取住院共济金请求
服务编号:
服务名称:取住院共济金
输入参数:个人参保号码、时点
内部处理:根据个人参保号码、时点查找个人缴费历史
输出参数:个人缴费情况
3.4.14门诊费用登记请求
功能需求:门诊费用登记请求
服务编号:
服务名称:门诊登记
输入参数:个人参保号码、时点、门诊处方或诊疗项目内容、(门诊编号)内部处理:将传送来的门诊数据保存到数据库。
输出参数:保存结果(对数据库的操作是否成功)
3.4.15门诊费用结算请求
功能需求:门诊费用结算请求
服务编号:
服务名称:门诊结算
输入参数:个人参保号码、门诊编号
内部处理:根据数据库保存的门诊处方或诊疗项目内容按照医保政策进行结算。
输出参数:门诊结算结果
3.4.16住院医嘱登记请求
功能需求:住院医嘱登记请求
服务编号:
服务名称:住院医嘱登记
输入参数:个人参保号码、时点、住院编号、卫生部住院病案、住院医嘱(长期、短期)内部处理:将传送来的门诊数据保存到数据库。
输出参数:保存标志(对数据库的操作是否成功)
3.4.17住院费用结算请求
功能需求:住院费用结算请求
服务编号:
服务名称:住院结算
输入参数:个人参保号码、住院编号
内部处理:根据数据库保存的住院医嘱按照医保政策进行结算。
输出参数:住院结算结果
3.4.18基础目录对应表更新请求
功能需求:基础目录对应表更新请求
服务编号:
服务名称:医院基础目录对应
输入参数:(无)
内部处理:下载最新的社保基础目录库。
输出参数:社保基础目录库
3.4.19基础目录对应表更新请求
功能需求:读取参保人缴费情况请求
服务编号:
服务名称:基础目录对应表上传
输入参数:医院的基础目录对应表、时点、医院编号
内部处理:
输出参数:保存标志(对数据库的操作是否成功)
完成对应以后调用该服务模块将对应表更新信息提交医保服务器。
3.4.20基础目录对应表更新
功能需求:基础目录对应表更新
服务编号:
服务名称:取对应表审批状态
输入参数:医院编号
内部处理:根据医院编号查找对应表审批状态(社保机构直接在送来的对应表上审批)输出参数:对应表审批状态(即经审批的对应表)
3.4.21审批业务登记请求
功能需求:审批业务登记请求
服务编号:
服务名称:审批业务
输入参数:申请表
内部处理:将申请表保存到数据库(社保机构直接在申请表上审批)
输出参数:申请表保存标志
当需要办理社保机构进行审批的业务时需要调用该服务完成审批的申请工作。
3.4.22检查审批结果请求
功能需求:其它审批业务
服务编号:
服务名称:审批业务
输入参数:个人参保号码、申请时点、申请审批项目
内部处理:取出经审批的申请表。
输出参数:经审批的申请表
3.5 人工处理过程
接口应用中影响医院系统业务处理过程的管理办法和政策,由社保机构各业务处室或局方进行与医院的沟通。
4运行设计
4.1 运行模块组合
说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合,说明每种运行所历经的内部模块和支持软件。
4.2 运行控制
说明每一种外界的运行控制的方式方法和操作步骤。
4.3 运行时间
说明每种运行模块组合将占用各种资源的时间。
5系统出错处理设计
概述。
5.1 出错信息
用一览表的方式说朗每种可能的出错或故障情况出现时,系统输出信息的形式、含意及处理方法。
5.2 补救措施
说明故障出现后可能采取的变通措施,包括:
a.后备技术说明准备采用的后备技术,当原始系统数据万一丢失时启用的副本的建立和启动的技术,例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术;
b.降效技术说明准备采用的后备技术,使用另一个效率稍低的系统或方法来求得所需结果的某些部分,例如一个自动系统的降效技术可以是手工操作和数据的人工记录;
c.恢复及再启动技术说明将使用的恢复再启动技术,使软件从故障点恢复执行或使软件从头开始重新运行的方法。
6系统维护设计
说明为了系统维护的方便而在程序内部设计中作出的安排,包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。
各个程序之间的对应关系,可采用矩阵图的形式。
附件:医院系统接口定义文件(HISI.idl)。