医疗保险管理信息系统建设初探

张弛

（连云港市医疗保险管理处，江苏 连云港 222046）

为了全面贯彻落实国家这一惠及全民的大政方针，做好本市各用人单位及其职工参加基本医疗保险的有关工作，必须加大对医疗保险信息化的建设，全市市直、县区分成不同的统筹区，各统筹区实行相似的政策，使用统一的软件，避免各县区重复开发而浪费大量的人力物力。本市选择了东软作为软件开发商，各县区分步实施，到2000年底实现全市医保全部上线运行。

下面就从医保系统目前的现状和存在的问题出发，提出新的适应目前需求的医疗保险管理信息系统。

1 医疗保险管理信息系统的现状以及存在的问题

1.1 医疗保险管理信息系统的发展状况

我国医疗保险管理信息系统(MIMIS)的建设始于20世纪90年代后期。经过几年的发展，医疗保险管理信息系统建设已经初具规模。信息系统的发展经历了从单机系统、局部网络系统到整个部门统一信息系统的多个阶段。

在信息系统应用技术上，客户/服务器结构的信息系统已经成为医疗保险信息系统的主流，使用Windows环境和图形化的用户界面是目前社会保障管理部门主要采用的客户端环境，基于SQL语言访问的大型数据库在医保中心、社会保障管理部门中也已普遍使用。

1.2 医疗保险管理信息系统目前存在的问题

医疗保险的特点决定了MIMIS存在本身的特点，医疗保险一般是以政府或社会组织举办，立法强制、统筹互济，并且是非营利的性质。它是面向社会的，覆盖面较广，一些企业都必须强制参保，参保的人数较多。所以医疗保险管理信息系统就具有了政策性强、涉及面广、信息量大等特点，因为数据量大且数据交换频繁，所以医疗保险管理信息系统是一项非常复杂的系统工程。

由于医疗保险信息系统的这些特点，导致了我国医疗保险信息系统的建设中存在的问题很多。

比如业务流程不规范，网络和数据库设计还不够完善，系统稳定性差。一些地方设计的系统只是手工操作的简单翻版，系统运行一段时间后，才发现有很多业务流程需要优化，致使系统不得不进入第二次开发。另外，一些城市盲目追求一步到位、一劳永逸的目标，希望采用的技术最先进，系统最稳定，且能保持很长时间不被淘汰。但是由于医保工作尚处于改革阶段，一些管理模式、业务流程、组织机构的变化在所难免，致使“高大全”的目标难以实现。还有一些地方在系统建设之初，由于缺乏充分的需求分析，站的高度又不够，开发的软件不能适应医保业务的变化要求，致使不少系统陷入了不死不活的尴尬境地。还有一些地方，仅仅从医保的角度出发进行设计规划，没有充分考虑社会保险业务发展的一体化要求，系统割裂增加了运行成本，重复建设造成了巨大浪费。还有一些系统，由于各种各样的原因，应用效果不理想，长期搁置不用，导致系统的发展后劲不足。除此之外，由于前两年劳动和社会保障部门对医保管理信息系统的建设市场没有进行明确规范，而全国从事这个领域应用软件开发和服务的公司非常多，竞争非常激烈，这些公司的业务系统标准规范不统一，缺乏统一管理，给医保管理信息系统间的信息共享和信息交换造成了障碍。

2 适应需求的医疗保险管理信息系统所要达到的功能

医疗保险管理的计算机化是一项规模巨大的信息系统工程。它的基本模式是：以医疗保险管理中心为信息系统的中心，与全市各定点医疗机构、定点药店联网，构成一个庞大的覆盖统筹地区的医疗保险计算机管理网络系统。

2.1 基本的业务功能要求

系统的总体逻辑结构应根据系统的数据和功能需求，MIMIS主要由医疗保险管理中心业务子系统、定点医院业务子系统、定点药店业务子系统三个部分构成。

该系统涉及医疗保险管理中心、参保单位、定点医院和药店、财政部门、银行等单位以及众多的参保单位、参保职工。

参保单位：定期申报本单位参保职工的变更情况；按时进行医疗保险费的申报和缴纳，定期代表单位职工到医保中心办理报销业务。

参保职工：按月缴纳个人应负担的医疗保险费；持医保IC卡到各定点医疗机构就医或购药。

定点医院、药店：按照医疗保险政策和医保中心制订的药品、诊疗、病种等医保目录，完成参保职工在医疗机构的治疗、购药等服务工作，允许其持医保IC卡结算，按约定与医保中心结算医疗费用。医疗保险管理中心：负责单位和个人基本信息(档案)的管理工作、负责医保基金的征缴核定工作、负责管理统筹基金收支、负责完成参保职工的特殊医疗费用的报销、负责定期与定点医疗机构进行费用结算、负责监督检查医保政策在各定点医疗机构的执行情况。

2.2 子系统的功能要求

由于定点药店业务子系统的功能相对来说并不是很重要，这里就主要把医疗保险管理中心业务子系统和定点医院业务子系统作一下介绍。

2.2.1 医疗保险管理中心业务子系统功能

医疗保险管理中心业务子系统包括：投保服务、参保管理、基金财务管理、个人账户管理、医保：IC卡管理、医疗监督管理、医疗审核管理、现金报销管理、系统管理、统计分析、领导查询共11大类136个业务，覆盖了参保、征缴、实缴、缓缴、分配、变动、调动、结算、报表、查询、统计、管理和控制等各个层面上的业务。接口包括医疗机构接口、上下级经办机构接口、劳动主管部门接口和财务接口，满足了上下级、同级相关部门的信息交换。

2.2.2 定点医院业务子系统功能

定点医院业务子系统包括：门诊管理、住院管理、药房管理、系统管理共4大类业务。其中覆盖了门诊挂号、退号、挂号日结、门诊收费、退处方、门诊日结、科室核算、数据查询、药库的出入库管理、门诊药房的出入库管理、病区药房的出入库管理、系统参数定义、操作员管理、与医保中心的数据传输等医院各层面的业务 (见图3)。

3 对新的医疗保险管理信息系统的具体设计和思考

根据目前MIMIS的功能需求，笔者在此对医保信息系统提出了新的设计方法，把UML技术运用到了MIMIS中，并加强和完善了医保系统的网络和数据库。

3.1 UML在医疗保险管理信息系统中的应用

下面将做的就是利用UML提供的这些技术手段运用到医疗保险管理信息系统领域建模的基本过程，并与传统面向过程的建模过程进行比较。

3.1.1 UML简介UML是基于面象对象的建模语言，即统一建模语言(Unified ModelingLanguage，UML)，它的前身是对象建模技术(OMT)，UML的出现，则标志着面向对象技术已进入了一个发展成熟时期，UML统一了面向对象建模的基本概念、术语和图示符号，描述了建模过程所必须遵循的基本步骤，为学者和工程师们之间研究交流提供了共同语言。UML是一种定义清晰、易于表达，适用范围广的建模语言，集软件研究领域的许多新思想、新方法、新技术于一体，强有力地支持软件开发的全过程。

3.1.2 UML建模语言采用图形表示法，一共定义了5类模型图。第一类是用例图(USE CASE)从用户角度描述系统的功能，并列出这些功能的执行者，用例图由表示图例的椭圆和执行这一功能的角色构成，第二类是静态图，静态图有类图、对象图和包图三种图型符号，系统中的类用类图定义，类图由类名、类属性和操作三部分组成，对象图是类图的一个实例，表示符号和类图完全相同，但对象图表示的是一个具体的对象，包图表示了一个或多个类的组合，是一个比类更大的软件单位。第三类是行为图，描述系统的动态模型和对象间的交互关系。第四类是交互图，描述对象间的交互关系。第五类是实现图，包括组件图和配置图。这些基本图示符号为系统的分析、设计建模提供了十分方便的可视化手段。

3.1.3 医疗保险管理信息系统的UML建模。使用UML建模技术进行软件开发时，一般要经过开始、细化、构造和交接4个阶段。在开始阶段，根据用户提出的需求产生角色、使用案例，并采用使用案例框图进行可视化描述，清晰表达用户系统的真实目标；在细化阶段，首先要进一步分析开始阶段产生的使用案例模型，对使用案例低层要求进行详细描述，包括使用案例的处理流程，使用案例中涉及的角色、对象，并用交互框图描述出所有角色对象之间的详细交互活动及对象本身的状态变化，用类框图显示要建立的类对象及其相互关系；在构造阶段，和细化阶段类似，围绕使用案例来进行，根据已有的工作基础，设计出组件和组件框图，自下而上建立一个完整的系统模型，并通过一系列迭代过程来构造实际可用的系统，每一次迭代开发都是一个小项目，每一个小项目完成后，就向用户演示，并完成局部系统测试，证明已正确实现了用户要求的功能，待全部小项目完成时，进行整体的测试集成，在移交阶段的任务是将设计完成的软件产品交给用户，接受用户的检测，完善文档。

医疗保险管理信息系统的UML建摸就是按上述基本过程进行的。在医疗保险系统业务流程的基础上可以得到医疗保险系统的基本功能：实现医疗保险系统业务处理的计算机化，把定点医疗机构、定点药店、银行、参保单位、参保个人连接起来，通过计算机网络提供实时参保登记、保险费收缴、医疗费用和医药费用支付的电子化，通过各种监控手段控制基本医疗费用使用，开拓资金来源，为医疗药品行业的公平竞争提供支持，建立患者医疗费用负担、病种费用、住院周期、大型设备使用、药品使用等医疗状况资源数据库，并利用这些资源对医疗保险的收支情况，病种费用定额，平均住院费用定额等进行预算，建立医保资金收入支出模型。(1)医保系统UML建模的案例模型。(2)相关对象的顺序图、合作图和活动图模型。顺序图非常直观地层示了对象之间传送消息的时间顺序，反映了对象之间的一次特定的交互过程。在本例中，就诊者对象向医院门诊发送参保身份验证的消息，门诊完成身份验证后便向医生对象发送就诊人看病的消息，医生看病开处方单后，向处方单对象发出保存处方单的消息，处方单对象完成保存工作，并同时对处方单进行药品准入验证，然后向支付系统发送处方单费用计算的消息。支付系统完成处方单费用计算后，通知就诊人付款，就诊人插卡到pos机，pos机通知支付系统扣除应付款数，整个过程是顺序完成的。(3)医保系统的类图模型。类图技术已成为面向对象方法中真正的主要的技术，事实上，每种方法都含有这种技术的变化情形。账务管理一共包含基金总帐、实收账、应收帐、住院基金、风险基金、个人帐户、住院费用单、门诊费用单、购药费用单、参保职工、参保单位、缴费凭证等12类对象。其中类对象实收账和应收账都是基金总账的一部分，它们之间的关系是整体与部分的关系，是一种组成关系，同样住院基金、风险基金和个人账户和实收账的关系也是一种组成关系。住院基金和住院费用单是一种带约束的一对关系，即如果费用单金额之和超过定额支付数，则只支付定额数。同样风险基金和住院费用单的关系也是一种带约束的关系。

3.2 UML与面向过程模型的比较

3.2.1 UML模型的特点。从需求分析到设计和实现，UML都提供了一套连续的可视化表示符号，可以实现模型之间的无缝转换。UML在初始阶段使用“USECASE”图来刻画用户需求，强调了系统相关的角色和这些角色在系统中完成的主要功能，忽略了各个角色与功能之间的联系及其它细节，通过“USE CASE”图，用户和开发者对系统功能一目了然，把注意力引导到弄清楚系统要干什么，而其细节则用文字详细描述，在详细分析阶段，用交互图，包括顺序图、合作图和活动图来描述“USECASE”相关对象之间的消息传递、协作关系，进一步经过设计，用对象模型来表示整个系统。

3.2.2 面向过程的特点。而面向过程模型一般采用数据流程图和数据字典，来描述系统需求。分析、设计、编码之间缺少统一的表示方法，因而各个阶段之间存在较大的间隙，这种技术是面向功能的方法，即根据用户需求的功能画出流程图。然后在对需求的功能进行分解以及得到系统的子功能，再继续进行这种分解，直至得到每个子功能都是可管理的，然后把这些数据流图变化成对应的软件结构，这种面向过程的方法容易为开发者所接受。但这种方法所得到的软件结构，严重的依赖于系统功能，在软件开发过程中，用户的功能需求是软件开发过程中最不稳定的开发因素。用户可能随软件开发过程的进行加深对软件的认识，因而可能改变其需求。另外，随时间的进行，也会加深对其应用领域的认识，因而提出新的需求，这些改变将导致软件结构的改变，因而给软件的开发以及其维护造成了困难。

3.2.3 UML更具优势面向过程的方法其数据和操作是相对分开的，例如，程序中的全局变量以及多个模块所存储的数据文件不属于任一单一模块，因此，数据和操作是分离的。现假设需修改某项功能，那么必须修改数据结构的某一部分，同时修改或增加某个模块。但是，我们不能仅改变数据字段的名字而不改变其他影响程序，如果是普通的数据文件，那么不修改全部有关程序，而单独修改数据文件是不可能的。但是对于UML也就是面向对象的方法把数据和操作封装在一起，实行了信息隐蔽的原则，因而程序的改变是相对容易的。像医疗保险管理信息系统这一类的计算机软件，在开发过程中或开发工作完成之后，用户的需求经常改变，因此这类系统的开发采用UML的技术可以适应系统功能不稳定的特点。

3.3 医疗保险系统中网络和数据库的完善

在MIMIS中，网络和数据库设计的好坏是至关重要的，这直接影响到整个MIMIS性能，所以必须要加强和完善医保系统中的网络和数据库。

(1)系统的网络结构设计。根据前面的医疗保险管理信息系统的功能，可以勾画出系统的网络结构的硬件平台。医疗保险管理信息系统的硬件平台包括医保中心的局域网、定点局域网和网络接入设备等构成。医保中心局域网及其网络接入设备是医保系统的核心部分，负责系统的安全运行、业务管理等重要工作。定点医院局域网是支持本系统中定点医院管理业务子系统的硬件平台。由于定点药店业务子系统业务量小，不需要建局域网，可用一台高档PC机采用拨号方式入网。

由于传统的二层Client/Server结构存在部分局限，因此医疗保险管理信息系比较好的方法应该采用三层Client/Serve计算模式。随着Internet获得愈来愈广泛的应用，同时基于B/s结构的特点，系统采用B/s信息发布与查询模式，即对于参保单位投保、领导查询、决策支持、网络扫描、信息发布等功能采用B/S结构。

（2）远程实时通讯及数据传输功能。

如何将医保中心的个人账户等信息传输到医疗机构，以及如何将参保人员在定点医疗机构的消费信息传送到医保中心，及时正确扣减个人账户，是系统数据保持一致性和正确性的关键，也是系统保持正常运转的关键。而在以前的医疗保险管理信息系统中，对这一方面虽然也很重视但做的并不是很成功。本文在此给出了同时支持实时和定时联机的两种方案，一般情况下，系统采用实时联机通讯方案，当线路出现故障或通讯条件不满足时采用定时通讯方案。(i)采用TCP/IP的SOCKET网络编程实现数据实时传输。各定点医疗机构和医保中心需要实时传递的数据很多，这里只考虑参保职工个人的Ic卡如何在医疗机构实现在线划款。由于医保中心每月(年)在职工缴纳了医疗保险基金后，为参保职工个人账户划拨一次，而个人账户划拨后中心数据库的个人账户增加，而个人的IC卡中没有写入。为了做到医保中心数据库中个人账户的数据和职工个人手中的IC卡上的个人账户数据一致，当参保职工到医院、药店就诊时，系统自动实现向个人IC卡中划款。

医院的工作站完成个人IC卡划款的程序设计过程：判断个人IC是否需要划款；如需要，向中心的通讯前置机发起个人IC卡划款请求；接受请求结果，正确，向IC卡中写入个人账户最新数据；向中心返回IC卡划款成功标志。医保中心的通讯前置机监听进程中关于个人IC卡划款的程序设计过程：监听端口信息，得到请求后，判断请求类别(验证请求的正确性、申请最新个人账户数据、返回在医院的划款结果)；根据请求对医保中心的数据库进行操作；将结果写回端口。(ii)采用TCP/IP的FTP编程来实现数据包传输。针对医保中心和各医疗机构之间需要定时传输的数据，系统采用TCP/I P的FTP编程实现。系统需要传输的数据均由各医疗机构来完成，包括医保中心需要下传和医院需要上传的信息。各医疗机构的数据传输程序用DELPHI编写，利用DELPHI提供的NMFTP控件类。实现的设计过程如下：医保中心和各医疗机构需要传输的数据打包、加密后，存放在规定的目录中；通过医院端运行传输文件包程序，将数据传送到对方规定的目录中；双方运行相应数据库中相应的数据。

（1）数据库技术的规范

医保中心的参保人数一般较多，数据量很大，像两江试点之一的镇江目前其参保人数就达30万。如果数据库设计不合理就会明显的使系统的性能降低，查询数据的时间延迟，因在医保工作人员工作时较高的响应率还是很重要的所以医疗保险管理信息系统的数据库的设计必须使用正确的设计方法分步进行。具体来看就是按照下面数据库设计的生命周期的四个阶段来进行。

需求分析：在系统分析阶段，收集用户需求，明确地了解有用数据及管理对象，进行需求分析，反复权衡制定初步方案，这些为数据库的进一步设计打下了基础。概念设计：这个阶段是从用户观点来描述数据库，即对现实世界(医疗保险信息系统)，包括人员、机构、概念、事件等进行描述，进而抽象出系统管理的基本模式。对已有的存储文件(台帐、报表)、原始凭证等进行分析，若不需变动的则视为一个实体，如需要变动的再进一步地分解、组合，最后将每一个数据存储视为一个实体，分析实体之间的联系和实体的属性，导出符合用户要求的模型一-概念模式。

逻辑设计：这一步的目标是精确地表示出数据的关系，其结果为一系列的表格和数据字典。具体做法是对数据存储(如表格等)和上级报表经过修改(如增、减项目，分解表格等)即可得到数据库的二维表格：采用下述转换规则转换成二维表格。

每个实体集作为一个关系模型(二维表格)，实体的属性作为关系的属性，实体的关键字作为关系的关键字。

实体间的联系，对应一个关系，其属性由参加这个联系的所有关系的关键字和本联系的属性组成。

用上述方法得到数据库模型之后，还必须提高规范化程度。由于管理中的信息表格化程序很高，经过分析设计的关系模型(表格)就一目了然，数据之间的依赖关系很容易发现，所以，我们从实际出发，不断改进，尽量使其达到第三范式(3NF)的要求，但是也感觉到虽然提高数据库模式的规范化程度可以减少冗余和引起更新数据库时的异常现象，但由此而导致的数据库增多，使得解决一个问题常常需要打开多个数据库进行连接等操作，这样事必造成降低速度和产生不必要的麻烦。

[1]徐铭.城镇居民医疗保险管理信息系统研发[J].山东大学，2009-04-15.

[2]刘宏宇.社会医疗保险网络管理信息系统设计和实现[J].电子工程师，2001-11-30.

[3]阳辉.医疗保险管理信息系统[J].四川大学，2001-05-07.