医院职工公费医疗系统.

Presentation on theme: "医院职工公费医疗系统."— Presentation transcript:

1 医院职工公费医疗系统

2 小组成员 李露平：主要负责核心Java程序设计和集成测试 潘逸凡：主要负责关键部分功能存储过程的实现和集成测试
周劲云：主要负责网站架设和系统数据整理。 周赓：主要负责数据库逻辑设计、物理结构设计。

3 系统概述

4 前期调研 我们前往中国中医研究院西苑医院进行了实地调研。 1.采访了保健科主任 2.跟随被采访者经历了整个手工处理员工公 费医疗流程
2.跟随被采访者经历了整个手工处理员工公 费医疗流程 3.获得了关于该系统的基础数据 4.搜集了关于中国医疗信息化的许多资料

5 基础数据 本医院共有员工约1500人，分属于大约40个科室与部门；
每年员工的医疗记录大约20000条，其中涉及公费医疗的部分有5000条，总额约300万人民币； 医院现有药品4000余种，其中绝大部分为甲类药，乙类药约50种，丙类药少于50种； 需要保留员工4年的医疗记录； 经常使用公费医疗的员工300余人。

6 公费医疗政策 总医疗费用= ∑（各项药费 ×药品对应的报销比例） 如果总费用>800元，可参与公费医疗
公费医疗=（总费用-800）×工龄对应的报销比例 若该员工在最近3年均未使用公费医疗，则在该年奖励400元，否则奖励100元。

7 工龄等级对应的报销比例 公费医疗等级 职工工龄 公费比例 1 0~5 70% 2 6~15 80% 3 16~25 85% 4 26~
及退休 90%

8 医药种类对应的报销比例 医药类别 公费基数 甲 100% 乙 80% 丙 0% 注:医药是指广义的医药，包括住院等项目。

9 系统目标 1.简化医院职工公费医疗记录管理流程与管理人员的工作负担。实现数据管理的自动化，其中包括费用自动计算、年度记录自动更新、药品记录自动更新、医院员工记录自动更新和维护。 2.方便公费医疗部门执行国家政策。 3.方便医院各级员工远程登录对自己的公费医疗信息进行查询

10 本次医疗任务的用药情况、总费用等与公费医疗无关的数据。
某次医疗任 务结束 核心功能： 相关数据入库 根据公费医疗政策计算 是否达到公费 医疗标准？ 是 根据公费医疗政策计算出公费额和自费额 职工选择 享受公费医疗 否 是 否 计算相关数据 然后数据入库 功能结束，退出

11 其他功能 一、员工和管理员可以查询公费医疗的政策。 二、员工可以查询自己的历史记录 三、员工可以修改自己的密码
四、管理员可以查询所有员工的历史记录 五、需求分析中的功能基本上都做到了，需求分析中没提到的功能有时间再补充完善（如每个科室职工奖励情况等)

12 系统实现前后的情况对比

13 系统实现前后的部门服务质量对比

14 系统实现前后的部门成本对比

15 系统实现

16

17 数据库系统内部统计信息 数据库：SQL server2000 11张表： 9张公费医疗系统用表+ 2张登录检查用表 13个存储过程 4张视图
2个用户定义的函数

18 小组交流1：定期交流 1.每周数据库下课后一定进行讨论。 2.其他时间每周至少集体讨论2次 3.每次资料更新后发至所有人的邮箱中。
4.每次提交报告前收集所有人意见，并进行修改。 5.每次提交报告后进行总结

19 小组交流2：选题 周劲云：医院职工公费医疗数据库系统 周赓： 社区小型医疗服务站数据库系统 潘逸凡：医院收费数据库系统系统
周赓： 社区小型医疗服务站数据库系统 潘逸凡：医院收费数据库系统系统 各方陈述了自己系统的优势和风险 最后四人投票决定选择医院职工公费医疗数据库系统

20 小组交流3：JDBC& ADO 周劲云：使用ADO进行数据库连接 理由：尝试新方法 周赓：使用JDBC进行数据库连接
理由：可以远程访问；小组成员比较熟悉 不过综合考虑了各方面因素之后，我们认为不论是JDBC还是ADO都不过是一种形式而已，与ADO在这上面花时间，不如好好在研究数据库系统一些内部特性，深入了解一下DBMS系统。

21 存储过程？触发器？自定义函数？ 我们只采用了存储过程。之所以不用触发器是因为：
1）许多功能用存储过程更容易控制。我们的一些操作涉及到对多张表的修改，用存储过程可以由我们控制对表的修改次序和时间，并且易于进行错误处理；而触发器带来的一些修改可能是我们无法预料的。 2）触发器的系统代价比较大。 我们在初期除了存储过程外，还写了用户定义的函数，当时是为了给javabean提供接口的选择；如果用户自定义函数的借口更容易实现，我们就采用自定义函数。

22 索引优化：案例 关于MEDICATION 表（约6-8万条元组）建立索引时
若在EID上建立聚集索引，方便对每个员工的查询，但对按年份的查询不利。 同时，因为MEDICATION表中记录只包含四个年份，但包含了1500余名员工，同一年份的记录比同一员工的记录多得多，所以可选择按年份建立聚集索引。 但若对年份建聚集索引，由于我们的操作一开始插入记录时并不插入年份，而是在第二次对表的操作时才插入年份，这样对建立聚集索引很不利，因为元组的初始磁盘位置和最终的位置可能不一致。 最终选择为保留默认的主索引，在EID和[YEAR]上建二级索引。

23 核心计算与更新的实现 计算是我们系统难度最大的一块，因为各种对表的更新和查询操作穿插在计算中。
精心设计的核心代码保证了计算和更新的正确性和可维护性。 存储过程的引入优化了整个过程的代码和设计思路，解决了困难

24 网站设计 网页风格截图

25 遇到的重要问题及解决 关键问题：系统在遇到非法输入时，由于数据库里的部分表已经更新过，破坏了数据库的一致性，这是绝对不允许的
创建错误检测机制，用于检测错误和触发还原机制（jsp和javabean 里实现）。 创建还原机制，将数据库还原到故障发生前的状态(存储过程里实现)

26 自动检测机制 我们系统的自动检测机制实例： 1.错误检测机制 2.数据库一年一度更新的自动检测机制

27 重点代码 1、对非法sql语句进行过滤： 2、循环传参 3、循环接参 if(!sql_inj(sqlStr))
{System.out.println("SQL 语句非法");return false;} 2、循环传参 name="liluping[<%=i%>]" 3、循环接参 request.getParameter("liluping["+Integer.toString(j)+"]")

28 Exec calFee 代价分析

29 calFee代码 CREATE PROCEDURE calFee @TaskId char(10), @Pub_Fee float AS
DECLARE @Eid char(10), @Total_Fee float, @Self_Fee float UPDATE Medication SET WHERE SELECT FROM Medication Where EXEC updateHistory GO

30 谢谢大家！