来源:HIT专家网 作者:李崇铭
“集团医院在信息系统架构选择上面临两难:既要隔离,又要互通。集团医院的组织模式和管理模式不尽相同,其信息系统架构选择的关键在于解决好各院区‘统’与‘分’的矛盾,即保持各院间一定程度的独立性,又能实现一定程度的信息共享和业务协同。”
如何规划、建设集团医院的信息系统?2024年7月21日,在由HIT专家网主办的“2024年集团医院信息化研讨会”上,解放军总医院医学大数据中心原主任薛万国概括了三种主要的集团医院信息系统架构模式,并结合三个典型场景,依次分析三种架构模式对既有系统的修改内容、实现方案、工作量与难易程度。薛万国表示,通过这种按需求场景“打分”的方式,可以更直观地评估架构模式与医院的契合程度。
集团医院信息系统的三种架构模式
集团医院选择信息系统架构需考虑的因素有很多,如能否满足集团医院的组织和管理模式需求?采用一套系统或多套系统?是否统一更换新系统?等。在选择合适的架构方案之前,首先要了解各架构的实现方式及适用场景。
薛万国介绍了三种主要的集团医院信息系统架构模式,包括:
模式A:独立系统之上的互联互通。也即各成员采用独立的信息系统,保证系统间的隔离;各成员系统通过接口接入统一的互联互通平台,确保信息共享和业务协同。
这一模式的适用场景为:成员之间的业务和管理相对松散,业务需求“统”少“分”多,且各成员均已建有系统,但既有系统不支持集团化,也不愿意更换为新系统,此时可考虑采取这种架构方案,特别是成员之间是异构系统的情况。
模式B:单主体单一系统。该方案整体上是一个单一实体医院的信息系统,将所有成员视为单一医院内部不同的科室,依靠科室代码等区分成员业务。
这一模式的适用场景为:集团医院成员之间的业务统一管理,业务需求“统”多“分”少,且既有系统不支持多主体分隔,成员也不愿意更换系统。
模式C:多主体单一系统。该方案通过一套系统实例管理多个成员,可视作“多租户系统”。信息系统内部从数据上区分每个成员,所有业务功能根据数据标识分隔成员主体。
这一模式的适用场景为:集团医院成员间的业务模式基本一致,成员之间业务和管理相对松散,业务需求“统”少“分”多,成员属于新建系统,或有意愿更换既有系统。
不同架构模式在三类典型场景中的应对表现
“上述三种架构模式实现集团医院‘统’与‘分’的方式不同,因此在具体需求场景的实现方案上也有区别。”薛万国以集团医院建设三个典型需求场景为例,分析三种架构模式如何实现对应场景下的“业务隔离需求”与“共享协同需求”。
场景一:运营统计与电子病历共享需求
假设这一场景的隔离需求是:各院区分别统计各自的工作量及收入等运行指标。共享与协同需求是:汇总统计所有院区的运行指标,且医生可查阅患者在不同院区的医疗记录,可跨院区申请特别指定的检查项目(如PET/CT)等。
采用模式A(独立系统之上的互联互通),各成员原有业务系统功能基本不变,需增加上报接口和共享平台汇总。具体实现方案是各成员统计相关指标,并按标准上传;共享平台汇总统计各成员运营指标,建立电子病历共享标准并采集汇总。这种方案的工作量与难易程度适中。
采用模式B(单主体单一系统),原有系统功能基本不变,由于是同一套系统,医生可以直接实现跨院区的电子病历查阅,但需从全部数据中将各成员进行区分。实现方案是在科室字典中增加成员标识,分组统计各成员指标。这种方案的工作量与难易程度较低。
采用模式C(多主体单一系统),需增加多成员运营指标汇总,并增加跨成员查阅患者电子病历的功能。实现方案是在已有逻辑隔离基础上,增加跨成员指标汇总;对原有的逻辑隔离,开放跨成员电子病历调阅。这种方案的总体工作量与难度很低。
场景二:门诊挂号业务管理需求
假设这一场景的隔离需求是:每个院区的窗口挂号系统只显示和可挂本院区的号别,不显示其他院区出诊号别。共享与协同需求是:跨院区预约或跨院区统计。
采用模式A(独立系统之上的互联互通),各成员挂号业务功能基本不变,需修改预约功能,增加跨院预约调用和外部预约服务,共享平台需增加出诊安排查询和预约服务代理。工作量与难易程度适中。
采用模式B(单主体单一系统),挂号系统需按院区展示号别和挂号。实现方式是以科室字典的院区标识为依据,按院区配置进行过滤,跨院区预约可直接实现。工作量与难度低。
采用模式C(多主体单一系统),需使挂号系统具备跨院区预约功能,实现方案是对原有的逻辑隔离,开放跨成员预约即可,工作量和难度很低。
场景三:医生检查申请管理需求
假设这一场景的隔离需求是:常规检查检验只针对本院区提供服务,特殊项目可跨院区提供服务。医生申请检查项目时,除指定项目外,只显示本院区的检查项目和科室。这一场景的共享与协同需求是:PET/CT等特殊项目可跨院申请,同时门诊医生可跨院区开具住院单。
采用模式A(独立系统之上的互联互通),各成员医生工作站业务功能基本不变,需修改针对特殊项目的检查申请、修改住院单,增加跨院区申请功能;共享平台增加跨院区检查申请和住院单转发功能。该方案的工作量与难度较低。
采用模式B(单主体单一系统),需要为医生工作站增加过滤条件,确保(除特定项目外)医生只能申请本院区的检查项目。实现方案是对检查项目字典增加院区标识,通过过滤使医生工作站仅显示本院区以及可跨院区申请的检查项目;跨院区住院单可以直接实现。总体工作量与难度较低。
采用模式C(多主体单一系统),需修改医生工作站,针对特定检查项目开放跨院区申请,开放跨成员开住院单,工作量与难度很低。
不同架构模式的选择方法
基于上述介绍,薛万国总结出集团医院信息系统架构模式选择的“方法论”:
首先是调研业务需求,列出业务协同场景,逐项列出“业务隔离需求”与“共享协同需求”;
其次是针对各业务场景下的不同架构进行难易程度与工作量分析,逐项给出定性或定量评估,综合所有需求,得出不同架构选择的优先级;
第三,结合其他约束性因素综合决策,包括既有系统的满意度、持续发展能力,以及更换系统的人力、财力成本等。
“以上案例是三种架构模式针对微观业务需求场景的实现路径和工作量分析,实际上,集团医院选择信息系统架构时要考虑的因素会更多、更复杂,需根据实际情况量体裁衣。”薛万国表示,希望通过类似于“为不同需求场景下各架构模式打分”的途径,启发医院信息部门找到量化各架构模式与集团医院契合度的方法,把选择信息系统架构模式的想法变成可以落地实施的方案。
【责任编辑:陈曦 版式:明超】
评论前必须登录!
注册