Article Info

2017年6月1日《网络安全法》[1]实施后，“互联网+医疗”的信息安全越发重要。当前信息系统已成为医院各部门业务开展的必备工具，是实现医院现代化运营的重要手段，但若信息安全出现问题，小则影响医院业务开展甚至停摆，大则影响社会安定，加强医院信息安全建设势在必行[2-3]。在信息技术迅猛发展大背景下，医院内部的应用系统越来越多，这些系统互相独立，每个系统都需要识别用户的身份和授权认证，带来用户信息冗余、不同步等问题，长期下来，用户需要记住的用户名和口令越来越多，严重影响了工作效率，使得管理员在对人员系统授权的分配容易造成混乱，造成重要数据泄漏。而且医院大部分接口基于早期的数据库存储过程实现，随着越来越多第三方系统的接入，数据库接口错综复杂，长期下来，重复性对接工作越来越复杂，加上人员的岗位变动，没有形成一套完整的接口体系，且数据库存储过程难以调试，可移植性差，可读性及维护性差，数据接口管理存在无法监控、权限数据混乱等问题，在数据安全上存在很大的风险。

1 设计思路

传统医院现有的系统架构有C/S（Client/Server）两层架、C/S/S（Client/Server/Server）三层架构、B/S/S（Browser/Server/Server）三层架构，本平台以OAuth 2.0协议建立统一的认证授权中心。OAuth 2.0在当前互联网统一认证授权中应用最为广泛，目前各大APP、网站，如微信、支付宝、微博等，都用OAuth 2.0作为统一认证协议。OAuth 2.0有四种授权模式，本文主要采用授权码模式（Authorization Code）和密码模式（Resource Owner Password Credentials）及客户端模式（Client Credentials）三种模式[4-7]，通过对医院不同的系统架构进行分析，采用不同OAuth 2.0授权模式与本平台对接，实现统一的用户授权认证和接口授权认证。

1.1 平台用户授权

1.1.1 C/S两层架构

医院信息系统包括门诊医生站、检查检验系统、PACS等都采用了该架构，该架构特点是客户端与数据库服务器直接相连，不需要经过中间层服务器的处理，所以响应速度较快，但由于客户端与数据库服务器的关联性使得安全隐患无法有效避免，导致数据安全存在很大的风险。因此在与平台对接时，对用户数据库登录信息加密，把用户登录系统的信息与数据库登录信息完全分离。本文采用了OAuth 2.0中的密码模式，如图1所示，用户通过登录统一认证平台，平台认证后返回给客户端该用户加密[8]后的信息（HIS、LIS用户名密码及相关的资源信息），客户端根据此信息解密后登录到相关的数据库服务器。

1.1.2 C/S/S三层架构

医院信息系统包括医护一体化、护理文书等采用了该架构，该架构是客户端-服务端-数据库，与传统的两层结构相比，加了一个中间应用服务器。将业务逻辑在应用服务器上处理，减少了客户端的压力，本文采用了OAuth 2.0中的密码模式，如图2所示，以平台作为桥梁，客户端登录请求平台，平台认证返回token，客户端带着token与服务端实现交互，服务端通过token从平台获取用户相关信息。实现客户端与服务端用户的认证及信息的获取，解决了一个账号多点登录。

1.1.3 B/S/S三层架构

医院信息系统包括办公化自动化系统、微医疗、预约平台等Web系统采用了该架构，该架构是浏览器-服务端-数据库，只需要通过浏览器就可以使用，解决了系统安装及更新存在的复杂性问题，本文采用OAuth 2.0中的授权码模式，如图3所示，浏览器登录请求服务端，服务端通过请求到平台，平台返回授权码，服务端通过授权码获取token，服务端通过token从平台获取用户相关信息。该架构所有应用系统接入平台后，可配置在平台中，即可实现一次登录，访问授权过的应用系统。

1.2 平台数据接口授权

针对医院大部分接口采用存储过程维护性差、不宜管理且易出现安全问题等现状，对医院的现有接口进行改造。以平台的标准化开发，通过统一接入本平台，实现统一的接口授权管理，第三方只需要通过平台分配的授权机制及调用参数，即可实现接入调用所需要的医院信息数据。本文采用OAuth 2.0中客户端模式，如图4所示，第三方系统通过参数请求token，根据token去调用相关的授权接口。

2 平台建设与功能介绍

本平台是面向医院信息化标准的统一入口，肩负起支撑整个医院核心数据的调度，对于平台的建设，本文采用基于微服务架构的实现方式[9-10] 。如图5所示，当第三方系统请求平台时，通过Spring Cloud Gateway将请求动态转发到内部服务，网关接收到请求后，从注册中心Consul[11]获取可用服务，由Ribbon进行均衡负载后，分发到各个服务，首先进入了OAuth 2.0授权服务，认证第三方是否有获取数据的权限[12]，认证通过后使用Feign调用相应的医疗服务接口。服务集群通过Spring Cloud Config、Spring Cloud Bus、RabbitMQ实现通讯及配置更新。随着服务的越来越多，对服务间调用的分析会越来越复杂，本平台使用Spring Cloud Sleuth和Zipkin对这些信息进行监控采集，为服务之间调用提供链路追踪，方便对系统问题的实时监控。同时加入了Hystrix进行容错保护，防止基础服务的故障可能导致的级联故障[13]。在部署上，使用docker部署微服务[14-15]，为后期系统运营维护部署节约了巨大的成本，开发人员只需要关注业务模块，根据系统提供的开发布署文档，即可轻松开发自己熟悉的业务。

根据上述的设计思路，OAuth 2.0授权服务主要提供用户及接口授权认证。该服务将不同架构的医院信息化系统中的用户登录模块通过OAuth 2.0协议整合到平台中，用户不需要记住原来各个系统中的用户名密码，通过平台分配的用户名密码登录到平台，即可访问平台授权的接入系统。接入系统从平台获取相应的如用户id、姓名、科室、职位等用户信息关联到相应的接入系统表里，解决了接入系统内部的菜单权限；医疗服务接口主要提供医院数据接口服务，通过对医院各个系统原有存储过程的分类整理，改造成符合平台的接口模式，划分到各个不同的业务模块，部署到平台集群服务中。如图6所示，如门诊集群服务，服务中包括各种相关业务的接口，如获取患者信息接口、获取门诊预交金余额等接口。管理员通过平台对第三方系统授权相关接口配置，第三方系统即可调用相关的医疗数据。

根据以上对平台设计思路的分析和架构设计，设计出平台的主要功能，如图7所示。

2.1 系统管理

为实现系统基本管理信息的维护，系统用户可关联HIS用户，在用户授权调用时提供数据库登录信息。

2.2 授权接入管理

主要提供对第三方的OAuth 2.0授权配置，对用户授权和接口授权，第三方只需要根据系统分配的参数及调用文档，即可调用用户认证和授权接口，该功能可提供给第三方开发人调试，且仅提供测试数据。

2.3 接口管理

在设计上主要针对医院各个业务的模块拆分[16]，医院信息系统主要涉及门诊、住院、收费、检查、检验等，根据这些系统拆分成若干个服务，如医护患者信息、门诊收费信息、医护排班、预约挂号、就诊取药、住院收费信息、住院信息、检查信息、检验信息、问卷调查等服务，服务中又包括若干个接口，开发人员只需要根据系统的标准开发服务，服务会自动集成到相应的业务集群中，同时在该功能配置相应的接口信息，供接口授权调用。

2.4 监控管理

主要针对系统的服务、熔断、链路、数据库连接池进行实时监控。

2.5 服务治理

内嵌Consul自带的Web管理界面，可以看到各节点服务的信息，便于运维人员对服务节点的管理。

3 应用效果

统一接入平台通过建立统一的授权认证及接口管理规范平台，为医院提供统一数据接口接入，简化应用系统操作过程，提高了内部数据的安全性。

在该平台使用之前，医院每个系统独立运行，用户每天需要重复的登录工作，时间久了，用户名密码容易混淆，管理员对新用户账号分配或离职人员账号回收，需要在多个系统上进行配置，不仅工作量大，而且容易发生错误。同时对于各个系统对应的存储过程接口很多，重复且不规范，新系统接入时还需要重复性的编写存储过程，长期下来导致数据接口管理不规范且容易造成重要的数据泄漏。使用统一接入平台后，已有运维管理系统、办公自动化系统、微医疗、门诊预约系统、决策辅助支持系统等接入平台并通过平台获取医疗数据。

对比系统使用前后，用户每天在登录系统上的时间比原来缩短70%，大大提高了工作效率，管理员在对系统人员授权操作时间平均缩短90%，大大降低人员账号管理成本；对于系统开发人员，只需要通过平台文档及相关配置，即可从平台获取相应的数据，简化了开发流程。后续随着更多的系统接入及接口完善，管理员对医疗数据接口的治理将更加方便，第三方系统将不再与数据库直接关联。每个系统的接入调用，都有实时的日志记录，通过对日志记录的分析，可监控是否有可疑的系统接入，从源头上保障了医疗数据泄漏的安全。

4 总结

随着医疗信息化的不断深入，保障信息安全已成为当今最重要的话题，由于医院信息系统多套系统并存、开发维护复杂、业务逻辑和数据应用不合理、安全性得不到保证，使得在数字化医院集成改造过程中，困难重重。要克服和避免这些问题，需要更加合理的系统架构。基于全局的设计和先进的理念，医院统一接入平台，在原有基础上改造的同时，对相关的业务进行整合，解决了一个账号登录多个系统，统一了接口的管理及接入，不仅为医院信息化安全提供保障，而且为后续医院信息化建设打下了坚实的基础。目前系统也在不断完善中，最主要的是与院内系统的改造及数据接口迁移还不全面，各个系统的接入需要随着时间对接测试，形成医院内部统一的标准和规范。

[1]徐长安.《网络安全法》解读[J].中国建设信息化,2017,(3):62-65.

[2]何启红,曾理.如何确保医院信息安全[J].中国卫生质量管理,2018,(6):80-82.

[3]佘晓彬.医疗数据安全管理方法分析[J].信息与电脑(理论版),2017,(22):195-196.

[4]乔臻,袁骏毅,周晟劼.基于微信企业号的医院内部服务平台设计与实现[J].中国医疗设备,2018,33(4):135-138.

[5]袁海峰,胡锐,郁葱.基于OAuth2.0的高校数据中心Open API的设计与实现[J].电子世界,2017,(23):193.

[6]吴德,应毅,毛道鹤.基于OAuth2.0的认证授权方案设计与优化[J].软件,2018,39(10):18-21.

[7]邱永哲.OAuth 2.0授权协议常见安全问题及修复建议[J].无线互联科技,2018,(7):45-47.

[8]史婷瑶,马金刚,曹慧,等.医疗大数据隐私保护技术的研究进展[J].中国医疗设备,2019,34(5):172-175.

[9]赵然,朱小勇.微服务架构评述[J].网络新媒体技术,2019,8(1):62-65.

[10]马雄.基于微服务架构的系统设计与开发[D].南京:南京邮电大学,2017.

[11]张宁溪,朱晓民.基于Docker、Swarm、Consul与Nginx构建高可用和可扩展Web服务框架的方法[J].电信技术,2016,(11):21-25.

[12]庄璐,路学刚.微服务架构中认证与鉴权的探讨[J].金融科技时代,2018,278(10):40-42.

[13]王方旭.基于Spring Cloud实现业务系统微服务化的设计与实现[J].电子技术与软件工程,2018,(8):60-61.

[14]陈春霞.基于容器的微服务架构的浅析[J].信息系统工程,2016,267(3):97-98.

[15]章仕锋,潘善亮.Docker技术在微服务中的应用[J].电子技术与软件工程,2019,150(4):180.

[16]梁秋莲,徐健.模块化HIS系统的研究与设计[J].医学信息,2019,32(3):9-11.

基于微服务架构的医院统一接入平台设计与应用

引言