单位文秘网 2021-08-08 08:15:45 点击: 次
摘要:医疗保险信息系统的规划设计,重点探讨了客户端应用软件的自动更新、ORACLE用户密码的安全管理、客户端应用软件操作权限管理,并就定点医疗机构操作员的管理提出设想。
关键词:自动更新;安全管理
中图分类号:TP311文献标识码:A文章编号:1009-3044(2008)36-3029-02
我市城镇居民基本医疗保险计算机信息系统已经运行近一年了,目前运行高效、稳定。这与最初的系统设计的高要求、高起点是分不开的。本系统在设计时就引进很多先进开发理念,与开发实力强大的江苏正融科技有限公司合作,采用成熟稳定的开发工具及ORACLE数据库软件,实现了客户端应用软件的自动强制更新、ORACLE用户密码的安全管理、客户端软件操作权限多层次管理,确保系统的先进性和可靠性。
1 客户端应用软件的自动更新
目前大型的数据库应用采用的基本上是B/S(Browser/Server)或C/S(Client/Server)模式,当然也可能是三层结构。尽管B/S结构有很多优点,如界面友好,软件更新简单等,但因为它是基于网页浏览的,你能浏览的东西,原则上别人也能浏览。出于安全考虑,B/S访问本地资源,比如串口,必须借助于其他技术实现。所以在它的安全性和执行效率方面还不尽如人意。因此B/S也不是万能的,必须考虑实际应用场合。
C/S结构是应用最久的,虽然程序的可维护性差,布置困难,升级不方便,维护成本高。但由于其稳定性好、安全性高、运行速度快,所以在我们的应用系统中还是用的C/S结构。
我们都知道,如果客户端软件更新不及时,可能出现严重问题,例如:某软件早期版本容许字段值不填,后来版本修改了,某个站点未能及时更新,造成数据不一致,或者业务无法进行,必须后台解决,增加数据风险。
要解决升级维护不方便的问题,首先要理清思路,本应用系统采用多种技术妥善解决了C/S结构的升级问题,整个软件结构包括:升级数据库服务器(数据库的一个表,不必单独设立)、升级代理程序、客户端应用程序、升级服务管理程序等。升级数据库服务器保存软件的版本、文件名、文件内容等信息;升级代理程序负责读取升级数据库服务器中的最新版本信息和文件信息,完成最新版本下载和更新,并启动客户端应用程序;客户端应用程序为客户端具体应用的程序软件,即为需要实现更新的软件;最新版本上载程序是升级信息管理程序,用于上传最新的版本信息和相应的文件内容。
因为更新的是主程序,那么就必须关闭主程序。可是主程序关闭了之后,谁来调用安装补丁呢?为了解决这个问题,我们把主程序和自动更新程序分开来做。当需要校验版本的时候,主程序调用自动更新程序。自动更新程序如果发现主程序需要更新,在下载了升级补丁之后,就会要求关闭主程序。主程序关闭之后,自动更新程序调用升级补丁进行安装,安装完成后再重新启动主程序。自动更新程序自动退出,完成更新任务。
按照以上实现思路,客户端应用程序运行之前,先启动一个升级代理程序,该代理从升级数据库服务器中读取升级信息,并与注册表中的版本升级日期比较,如果存在最新版本,提示用户并自动下载最新版本,解压缩,完成升级,然后自动启动客户端应用程序。
1) 创建应用软件数据表,字段包括:文件名、版本、日期和文件内容等。
create table SYS_APP_UPDATE
(FILENAMEVARCHAR2(80) not null,
FILEVER VARCHAR2(20),
UPDATE_DATE DATE not null,
FILEDATALONG RAW);
2) 升级服务管理程序
服务管理程序实际就是一个维护SYS_APP_UPDATE表的应用程序,可以修改版本信息,也可以添加新的版本信息和文件内容(上传程序),程序内容压缩存放在该表中。
3) 客户端升级代理程序实现
在PB中创建一个应用,在应用的实例变量中声明:
string old_version
declare get_new_filename cursor for
select filename
from SYS_APP_UPDATE
where filever > :old_version;
在Open事件中编写代码,连接数据库、判断版本、提示升级,升级结束后写注册表;如不成功自动退出程序,下次进入再次自动升级,确保程序一致性。
2 ORACLE用户密码的安全管理
既然采用的C/S结构,客户端应用程序中一般都会有个配置参数文件,如PB.INI:
[Database]
DBMS=O84 Oracle 8.0.4
LogId=test
LogPassword=IgRXPOh
ServerName=center
这里可能存放连接数据库的用户名和密码,可以是明码,当然也可以加密存储。在应用程序中打开此文件,读取连接参数,实现各种业务功能。
但这里存在一个很严重的问题:我们都知道,一个数据库应用一般都是一个ORACLE用户名,密码在客户端本地存放,不论加密与否,安全都是问题;更麻烦的是如果系统修改了密码,各客户端的配置参数无法自动同步,会造成数据库连接失败;密码的定期与不定期更改是安全制度,而每次更改密码都需要对所有客户端参数修改一遍,工作量之大难以想象,真是令人头疼。
是否有什么好的办法呢?答案是肯定的!
我们可以建立ORACLE中间用户过渡一下,客户端本地的参数文件存放过渡用户的帐户(密码可以固定在程序内),而把真正的ORACLE应用的用户及密码加密存放在数据库的某个表中。
create user user-pass identified by baomi;
create table SYS_DB_CONN
( DATABASE_NAME VARCHAR2(40) not null,
DBMSVARCHAR2(80),
LOGID VARCHAR2(40),
LOGPASSWORD VARCHAR2(40),
OPERATEDATE DATE);
该表由系统用户创建,过渡用户仅有只读权限,正常工作用户对此表无权限,确保安全。
程序执行后,先连接到过渡用户,读取密码表获得连接用户名及密码,再次连接数据库,开始后续工作。如果更改数据库密码,只需修改数据库表中的字段,无需到各客户端更改参数,极大地减轻维护的工作量,也可以做到经常性地更改密码,增强了数据库安全性。
3 客户端应用软件操作权限管理
应用软件操作权限管理通常不太被重视,或者做的很简单。其实对一个大的应用系统,特别是跨地区、业务分工明确、业务权限复杂、分布广泛的应用至关重要。
我们的城镇居民基本医疗保险信息系统包含四县四区,中心端涉及窗口近两百个,定点医疗机构近百家。用户管理采用按级别、分层次管理,分为系统管理员,县区管理员,操作员三大类;操作员分为县区级、街道、社区等,每一级可对下一级进行管理。
正如一个人在社会上有各种角色:可以是领导,同时也可以兼做业务;既可以是父亲,也可以是老公,还可以是儿子。我们的系统设计中也引入角色的概念,每个角色就是拥有同样权限的一类人,完成一类工作,有自己的业务或管理权限;同时每个用户也可以扮演多个角色。
系统可以实现角色的创建、授权;然后创建用户,再根据用户的工作需要给用户授予各种角色(当然也可以专为某个用户创建角色);用户用某个角色登录系统后,就具有相应的权限,修改密码时仅修改本角色的密码,不同角色可以设置不同的密码(例如:不会因为告诉别人业务密码导致管理密码泄密)。大致结构如右图所示。
尽管本系统具备很多优点,但也并非尽善尽美。因为需求是不断变化的,软件的发展潜力是巨大的,这里我想就其中一个问题与大家探讨一下:
随着医疗覆盖面的扩大,定点医疗结构也成倍增加,对定点结构的监管也提出更高的要求。但毕竟医疗监管工作量大,人员少,力量有限,定点医院违规操作的事情时有发生。增加违规成本(罚款、停业等)固然是个办法,但执行起来难度不小。
基于此,我们设想是否可以在软件程序上做些事情,配合监管以期达到更好的效果呢?
我们知道:定点结构的结算都是通过操作员完成的,加强对操作员的学习培训,实行操作员的准入制度,并发给操作卡,要求操作员持证上岗,进入系统需要刷卡,对操作员实行记分管理,积分达到一定值,取消操作卡。
这就如同驾驶员的管理,驾驶过程中不会说领导叫违章就违章,他还需要考虑个人违章成本,即使罚款可以报销,但吊销驾驶证可没几人原意。这种做法表面上是对操作员不利,其实对他们更是一种保障。能取得操作卡就是一种资格,单位聘用后凭合同到中心备案,并在数据库中与该定点机构关联,进入收费系统时要先刷卡,系统可自动识别用户名,再配合密码,实现多重安全保障。即使卡被别人拿走,也需要密码才能进入系统。
当然这仅是个人的一点设想,还不够成熟,未能在本系统实现,在此抛砖引玉,希望有志之士共同完善此设想并早日实现。我衷心祝愿我们的城镇居民基本医疗保险信息系统更加完善,功能更加强大,更好地服务于医疗保险。
注:“本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。”
(责任编辑:单位文秘网) )地址:https://www.kgf8887.com/show-242-82378-1.html
版权声明:
本站由单位文秘网原创策划制作,欢迎订阅或转载,但请注明出处。违者必究。单位文秘网独家运营 版权所有 未经许可不得转载使用