【医疗信息化】医院自主研发HIS的经验和总结

医院自主研发HIS的经验和总结
蒙文涛①
①天津市宝坻区人民医院，301800，天津市宝坻区广川路8号网络信息中心
为加快我院的医疗信息化建设步伐，优化流程、方便病人就医，2013年初我院网络信息中心开始着手门诊HIS系统的自主研发的相关工作。

项目调研的前期，并没有输出项目章程，但是已经粗略的规定了项目的范围即门诊各个系统的研发，规定了项目经理的权利以及项目组中各个成员的职责，还有项目干系人的职责，以及在以后的项目范围管理工作中各个角色如何做好本职工作都有一个粗略明确的规定，后续可以工作可以更加有序的进行。

随着时间的推进我们确定了开发工具，确定了系统框架，确定了需要重新研发哪些系统以及各个系统的详细设计文档和数据结构，为将来项目决策提供了基础，以这些系统全部顺利上线，投入到正常使用中去为是否已经顺利完成的标准。

调研人员把项目的主要可交付产品和服务划分为更小的、更容易管理的单元，即形成工作分解结构（Work Breakdown Structure, WBS）。

WBS的建立对项目来说意义非常重大，它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来，使得项目管理有依据，项目团队的工作目标清楚明了。

WBS的指导思想是逐层深入。

先将项目成果框架确定下来，然后每层下面再把工作分解。

我院门诊系统的WBS图如下：
在项目启动的前期，网络中心与医技科室、临床科室、以及各个管理科室进行了多次的沟通，对项目的范围做了正式认定，确认各个科室的需求以及可交付成果。

这个过程是范围确定之后，执行实施之前各方相关人员的承诺问题。

一旦承诺则表明你已经接受该事实，那么你就必须根据你的承诺去实现它。

这也是确保项目范围能得到很好的管理和控制的有效措施。

范围管理工作结束之后，我们进行了时间管理工作。

如果只图节省时间，把这些前期工作省略，后面的工作必然会走弯路，反而会耽误时间。

由于一些是明显的、项目所必须的
前期工作基本确认完成后，我院于2013年6月17日组成了8人的研发团队，开始对现有的药品进销存、挂号、收费，门诊工作站做深入研究分析，取其精华去其糟粕，开始了漫长的系统改造工作。

2014年6月26日，由我院自主研发的HIS系统，正式上线，新系统的上线工作井然有序，稳步推进，没有因为病人的增多或操作人员的不习惯，带来排队长、秩序混乱等不好影响。

当然我们上线初期也遇到了各种问题，但是研发和项目实施一体化的团队，解决问题的效率是及时有效的，所以并没有造成严重后果。

但是门诊系统直到2014年11月份才全部上线完成。

针对此软件项目的上线工作，我进行了下面的总结：
一、项目范围的定义存在偏差。

在“范围计划”过程中只定义了各个软件的设计文档以及数据结构，但是在程序联动测试的时候发现了太多的接口没有实现，实际接口工作繁多，例如：医保接口、合理用药接口、银联接口、PACS接口、LIS 接口等，在程序开发的后期占用了大部分的时间。

二、在项目范围管理上没有针对于“范围变更控制”做系统的规划。

再好的计划也不可能做到一成不变，因此变更是不要避免的，关键问题是如何对变更如何进行有效的控制。

控制好变更必须有一套规范的变更管理过程，在发生变更时遵循规范的变更程序来管理变更。

通常对发生的变更，需要识别是否在既定的项目范围之内。

如果是在项目范围之内，那么就需要评估变更所造成的影响，以及如何应对的措施，受影响的各方都应该清楚明了自己所受的影响；如果变更是在项目范围之外，那么就需要商务人员与用户方进行谈判，看是否增加费用，还是放弃变更。

三、在“进度控制”上存在问题。

没有根据项目网络图、估算的活动工期、资源需求、资源共享情况、项目执行的工作日历、进度限制等因素制定严格的时间进度表；没有及时发现和纠正偏差、错误，导致后期程序出现了大规模的修改；进度控制中没有考虑影响项目进度变化的因素、项目进度变更对其他部分的影响因素。

四、软件的测试工作不够专业。

首先软件测试开始太晚，测试时间安排过于紧张，应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求；其次没有制定严格的测试计划，导致许多错误是上线后发现的，一定要制定测试计划，并且要有指导性；再次测试用例时没有虑到合法的输入和不合法的输入以及各种边界条件，没有制造极端状态和意外状态，如网络异常中断、电源断电等；最后没有妥善保存测试计划，
没有出错统计和最终分析报告，并且在出错修改后往往带来其他方面的错误。

五、轻视了上线工作。

全院工作人员对老HIS系统的界面、录入方式，操作习惯已经非常熟悉，所以每一个细节的变化对于工作人员来说都需要慢慢的适应，上线后我们在新HIS 系统的基础上，不断进行综合分析与提炼，尽量能满足各个医院临床科室的实际业务需要，并能够在实施过程中使用户的个性化需求得到进一步完善。

因此也花费掉了大量的时间和精力，导致系统结束时间一拖再拖。

制约一个软件项目的条件是项目“三约束条件”——范围、时间、成本。

在一个项目中这三个条件是相互影响、相互制约的，而且往往是由于范围影响了时间和成本。

项目一开始确定的范围小，那么它需要完成的时间以及耗费的成本必然也小，反之亦然。

很多项目在开始时都会粗略地确定项目的范围、时间以及成本，然而在项目进行到一定阶段之后往往会变得让人感觉到不知道项目什么时候才能真正结束，要使项目结束到底还需要投入多少人力和物力，整个项目就好像一个无底洞，对项目的最后结束谁的心里也没有底。

这种情况的出现对于项目团队来说，是他们最不希望看到的，然而这样的情况出现并不罕见。

造成这样的结果就是由于没有控制和管理好项目的范围、时间和成本。

可见项目启动前的工作是多么的重要。