对医院信息系统审计的初试，本文主要内容关键词为：初试论文,信息系统论文,医院论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
本文根据对某医院进行的信息系统审计做如下实例分析。
一、被审计单位主要信息系统的总体情况
该单位所用信息系统由总务物资管理系统、医用器械管理系统、药房药库管理系统、门诊病房管理系统、收费核算管理系统五个模块构成，对医院及其所属各部门的药品、物资、就诊信息等进行综合管理，对在医疗活动各阶段产生的数据进行采集、储存、处理、提取、传输、汇总、加工并生成各种信息，从而为医院的整体运行提供全面的、自动化的管理及各种服务。该系统既包括医院管理信息，又包括临床医疗信息。其中，收费核算管理系统模块的后台数据库采用DBF核算，其他四个模块均采用SQL5ERVER作为后台数据库。
二、对具体信息系统审计事项的实例分析
根据审前调查结果以及我们对该信息系统流程的分析，我们决定对如下信息系统审计事项进行重点审计。
（一）对IT规划和计划审计
1.具体审计目标。确认该医院是否制定了信息系统规划和计划文档，其规划是否得当、有效。
2.审计实施阶段。把该单位有无信息系统规划和该规划是否得当、有效作为关键控制点，并对其规划是否得当，能否支持该单位的发展目标，满足业务活动需求和信息需求作了重点分析。审计中我们使用了面谈询问法和调查问卷法。
3.审计发现问题和建议。审计发现该单位对于信息系统发展规划不够重视，至审计日并未编制信息系统发展规划和计划文档。审计建议该单位应以领导为核心牵头，派专人负责制定信息系统规划和发展计划。
（二）机房物理环境控制审计
1.具体审计目标。确认被审计单位机房物理环境控制能否保障信息系统安全可靠的运行，能否保护计算机及相关配套设备、设施及信息载体免遭人为或自然危害等。
2.审计实施阶段。把该单位实物安全控制措施是否适当、有效作为关键控制点，并通过调查问卷法和实地观察法来获取充足的审计证据材料，以便对关键控制点进行分析。在测试过程中，为了避免单份调查问卷填写有误，我们下发了多份调查问卷，并采用个别发卷、统一汇总的方式操作，问卷的设计也尽可能细致地列出关键性的内容和问题。对于实地观察法，我们则采用不定时突击审查的方法，以避免被审计单位为应付检查，临时突击整改，从而妨碍审计人员作出结论的正确性。
表1：组织控制调查问卷
表2：信息系统物理实体安全环境调查表
3.审计发现问题和建议。审计发现该单位机房内未安置灭火器；未对突发性事件制订应急计划；机房内疏于清扫，灰尘较多，不利于防尘。审计建议该单位及时安装并正确放置灭火器，制定突发性事件的应急计划，对机房内灰尘及时清扫，注意防尘。
（三）数据库系统安全控制审计
1.具体审计目标。确认被审计单位有关制度和程序能否最大限度地降低数据库安全风险，能否使数据得到妥善保护。
2.审计实施阶段。把该单位数据安全控制措施是否适当、有效作为关键控制点，并通过采用查阅文件法、问卷调查法和实地观察法来获取充足的审计证据，以便对关键控制点进行分析。通过审计我们发现，该单位通过制度规定对用户的数据存取权限表和存取控制表进行了合理授权，但收费模块后台数据库类型为DBF格式，该模块基于DOS环境开发，并且后台数据库为FOXPRO。由于FOXPRO无有效加密机制，对数据的删改操作都不留任何纪录，这样会给数据安全带来较大隐患，故其并不适合做诸如收费等系统关键模块的数据库。除收费模块外，其他四个模块的后台数据库均采用SQLSERVER，属中等安全的数据库模式。该单位对收费模块的数据库未进行有效加密，对SQL为后台的数据库采用系统带的加密机制，并设置了有效密码。
3.审计发现问题和建议。审计发现该单位收费模块所采用的DBF数据库不具备完善的安全、加密机制，对数据的更改、添加、删除等操作不留痕迹，不能用于企业级管理，更不能用于财务、收费、结算等要害部门金额账目管理。审计建议该单位及时对收费模块的数据库升级至SQLSERVER，这样既能增强其保密性，也便于与其他模块进行数据交流。
表3：信息系统数据安全控制调查表
（四）数据处理逻辑审计
1.具体审计目标。确认被审计单位数据处理逻辑是否符合系统设计的目标，数据处理是否恰当、准确、完整，数据间逻辑关系能否在程序中得到有效执行。
2.审计实施阶段。把该单位数据处理逻辑是否有效，是否符合系统设计思路作为关键控制点，并通过采用系统文档审核法、面谈询问法和计算机辅助审计技术获取充足的审计证据，以便对关键控制点进行分析。通过审计准备，我们了解到系统开发文档中所设计的总务物资管理系统模块和医用器械管理系统模块，自身具有进、领、存的核算功能，但通过面谈询问法我们了解到，该医院对大型设备的维修、报废却未能在系统中设计跟踪管理程序，又由于该系统所核算的医用器械和办公用物资进出库较为频繁，故对进、领、存的真实性作为重点审计。综合面谈询问法和系统文档审核法，我们发现医用器械管理系统模块和总务物资管理系统模块结构基本相似。由于篇幅所限，我们以医用器械管理系统为例说明。数据库中“DICT-GDZC-KM”表是医用器械具体分类的数据字典，内含医用器械分类码和医用器械分类名等重要内容；“BG-GDZC-LK+（器械分类码）”表核算医用器械的入库情况，即进货环节；“BG-GDZC-LY+（器械分类码）”表核算医用器械的领用情况，即销货环节；“BG-GDZC-ZK+（器械分类码）”表核算医用器械的在库情况，即存货环节。按照程序设计应符合“进货器械金额=领用器械金额+库存器械金额”的基本原理，我们设计了对数据库结构进行实质性审计测试的程序，即把进货、领用、库存三个阶段所涉及到的所有表按进、领、存的概念分类汇总成三个大表，分别求出合计金额后，检查验证结果是否符合“进货器械金额=领用器械金额+库存器械金额”，以此来倒推验证该库所涉及主要数据逻辑的正确性和有效性。在此我们不妨把这种方法暂时命名为“审查数据倒推验证系统法”。由于金审工程二期中应用系统建设的重点《现场审计实施系统》（即AO）已在全国政府审计机关推广使用，我们决定对数据验证采用AO中的ASL语言，同时为便于推广，在AO中形成自动审计方法。编写程序核心代码如下：
Var cx,bz,chae://义变量，其中bz为标志变量chae表差额
cx:=CreateQ('select*from分类数据汇总表where差额◇0',-1)；//调用创建查询函数
bz:=qeof(cx)；//调用查询判空函数，判断纪录是否为空。
while bz◇1do//bz=l为空
begin
chae:=QFD Value（cx，‘差额’）；
if chae◇O then
Add TransRsh（cx，‘入库金额不等于领用金额与库困金额之和’）；
bz:=Qmov(cx,1)；//调用查询移动函数
bz:=qeof(CX)；
end；
TransBatch（cx，‘入库金额不等于领用金额与库困金额之和’）；//将差额不为零的记录存放到业务疑点库中
end.
3.审计发现问题和建议。审计发现该单位的数据处理逻辑存在错误，从而造成医疗器械核算不准确的问题。产生该问题的原因是：医用器械、物资管理与门诊病房所使用的价目表不唯一，各数据库之间多份重复保存，并且有些数据库相互之间不存在关联，造成价格更新不及时，不能保证正确性和统一性，从而容易产生价格混乱。 审计建议该单位应构建一个内含药品、器械价目表等多个数据库所共享内容的共享区，这样就可避免价格等信息的混乱。
（五）数据输出控制审计
1.具体审计目标。确认被审计单位输出信息的完整性、正确性；输出权限是否得到合理控制；输出数据是否得到了审核控制；输出数据资料是否只分发给了有权接受资料的人员。
2.审计实施阶段。把系统能否完整、准确输出数据作为关键控制点，并通过采用系统文档审核法、面谈询问法和计算机辅助审计技术获取充足的审计证据，以便对关键控制点进行分析。通过查阅系统文档和面谈询问，我们了解到该系统的收费管理系统只单向接受由药房药库管理系统和门诊病房管理系统传递的收费数据，违背了一般医疗系统收费模块与业务模块之间有关数据能够联网核对的基本原则。我们认为，这种设计模式有可能造成输出数据的不准确，而这种不准确又难以通过人工核对发现，同时这种设计模式也增加了人为舞弊的可能性，故我们把通过验证输出数据的准确性作为审计重点。由于篇幅所限，我们以医疗器械模块为例说明。综合面谈询问法和系统文档审核法，我们发现医疗器械的收费与其在医用器械模块中的领用价格是对应的，同时发现医疗器械中的一次性医疗器械价格容易产生变动，如果系统出现故障，需要检修，这就容易产生系统数据传输错误，造成费用核算模块输出数据准确性的降低。根据审计分析结果，我们采用受控处理法获取审计证据。在实际操作中，针对受控处理法存在的缺点，我们对该方法做了尝试性的改良。首先分析被审系统业务流程，然后有目的地设计审查数据，利用计算机辅助技术，使需审查数据量尽可能的增多，这样测试数据虽不能涵盖系统所有功能，但能够使漏掉重大问题的审计风险降低；同时，对导入到审计分析软件的业务数据进行分析，使之独立于被审单位信息系统，不影响其正常工作。利用AO中的ASL语言，在AO中形成自动审计方法。编写程序核心代码如下：
Var cx,bz；//定义变量，其中bz为标志变量
cx:=CreateQ（‘select*from［一次性材料收费领用价格对比表］where收费单价◇领用单价’，-1）；
bz:=qeof(cx)；//调用查询判空函数，判断纪录是否为空。
while bz◇1 do//bz=1为空
begin
AddTransRslt（cx，‘存在领用价格与收费价格不一致’）；
bz:=Omov(cx,1)；//调用查询移动函数
bz:=qeof(cx)；
end；
Trans Batch（cx.‘存在领用价格与收费价格不一致’）；//将存在领用价格与收费价格不一致的记录存放到业务疑点库中
end.
3.审计发现问题和建议。审计发现该系统不能保证数据输出的真实性，主要原因是：该系统五个模块的设计是以科室为单元，彼此成为信息孤岛，除药房药库模块与门诊病房模块之间可以进行局部数据交流外，两者与住院结算均只存在单向数据传输，不能通过双向比对核查传输结果的正确性，这就不符合经典的医院信息系统的设计思路，没有起到真正联网的作用。审计建议该单位应设计一个双向数据传输接口，使收费与其他模块之间能够关联核查，发现问题能够及时审查解决，从而保障数据输出的真实性。
（六）交易数据输入控制审计
1.具体审计目标。确认被审计单位输入系统数据的准确性、完整性、可靠性。
2.审计实施阶段。审计流程：通过面谈询问法和检查流程图法，我们发现按照设计思路，门诊病房模块内的价目表应随医疗器械模块和总务物资模块中价目表的变动而变动（下面以医疗器械模块为例说明该问题），即各模块间价目表的数据应保持一致。但根据我们了解的情况得知，医疗器械模块和总务物资模块内的价目表数据是通过人工操作方式输入至门诊病房模块，由于药品、医疗器械价格随市场价格波动而变化，如果价目表靠人工输入、人工检查，很难做到医疗器械模块和总务物资模块中的价目表与门诊病房模块中的价目表一致，因此我们把验证输入数据的正确性作为审计重点。为了进一步取得审计证据，我们决定采用“倒退数据验证系统法”验证输入数据的正确性。以价格较易发生变化的“一次性材料”为例，通过AO编写ASL语言，程序核心代码如下：
Var cx,bz；//定义变量，其中bz为标志变量
cx:=CreateQ（‘select*from一次性材料价格对比表where价格◇单价’，-1）；
bz:=qeof(cx)；
while bz◇1 do
begin
AddTransRslt（cx，‘存在领用价格与收费字典不一致’）；
bz:=Qmov(cx,1)；
bz:=qeof(cx)；
end；
TransBatch（cx，‘存在领用价格与收费字典不一致’）；//将存在领用价格与收费字典不一致的记录存放到业务疑点库中end.
3.审计发现问题和建议。审计发现该系统不能保证数据输入的真实性，主要原因是该院依靠手工输入而不是程序传递门诊病房内的价目表。审计建议该单位应构建一个数据共享区，内含药品、器械价目表等多个数据库共享的内容，这样就避免了价格等信息的混乱。
三、本次信息系统审计的特点
本次信息系统审计不仅对该医院信息系统进行了全面审计，并且根据所发现问题对该医院提出了整改建议，同时对部分传统的信息系统审计方法进行了创新和改良。文中还描述了怎样使用AO进行信息系统审计，创建审计方法，为医院的信息系统审计提供了参考实例，使本案例具有实用性、可参考性、易推广性和创新性。
标签：医院信息系统论文; 审计计划论文; 数据库审计论文; 审计目标论文; 审计收费论文; 审计流程论文; 价格发现论文;