秦睿1
(1.武汉学院,信息工程学院,湖北 武汉430212)
摘要：通过分享了移动互联网医疗的发展历程和所面临的挑战，介绍应用性能管理概念、发展阶段和功能模型,从架构、关键技术等方面阐述医疗核心业务性能管理系统设计与实现,指出该系统的应用有效提升服务质量、改善用户体验。从在线交易云平台的设计、挑战和应用，以及对于互联网医疗行业的未来展望。如何应对系统高度分化异构的挑战，打造不间断服务的在线交易云平台。
关键词：应用性能管理;业务性能分析;医疗信息化运维;
Abstract: By sharing the development history and challenges of mobile Internet healthcare, introducing the application performance management concept, development stage and functional model, expounding the design and implementation of the medical core business performance management system from the aspects of architecture and key technologies, and pointing out the system The application effectively enhances service quality and improves user experience. From the design, challenges and applications of the online transaction cloud platform, as well as the future prospects of the Internet medical industry. How to deal with the challenges of highly differentiated and heterogeneous systems and build an online transaction cloud platform with uninterrupted services.
Keywords: application performance management; business performance analysis; medical information operation and maintenance;
一、移动互联网医疗的发展
基于医疗核心业务系统的在线交易云平台目前聚焦在于给包括患者、医院以及第三方等提供实时的业务交易的通道，但目前暂时还没有将云平台上面的数据进行汇聚和保存。这是因为如果想要实现将云平台之上的数据进行汇聚和保存不仅需要提供庞大的存储空间，而且还需要负担起数据安全的重大责任。所以就目前而言，云平台基本上承担的是在线交易平台的任务，所做的就是把各方都打通，实现医疗核心业务相关的在线交易。
对于在线交易系统而言，听上去可能比较抽象，但是当提到互联网医疗，大家可能就比较熟悉了。其实上面所提到的在线交易也好，云平台也好，现在疫情都离不开互联网医疗的发展。这里简单回顾一下移动互联网医疗的发展历程。在2011年的时候，移动互联网医疗概念开始被提出，之后的发展经历了几个阶段。首先是患者问诊类的APP开始上线，但其实它和医院的问诊系统是没有任何关系的，仍然只是医生和患者都在互联网上进行问答，并没有进入医疗的核心领域。之后，医生工具类APP开始上线，出现比如像在线问诊等的应用，不过它们只是一些知识库，医生可以直接在上面做一些知识共享，这个阶段仍然和主流的医疗系统以及医院没有进行互联互通。再之后就开始出现大批的互联网医疗创业公司，此时有一些医院实现了在线的挂号、预约，其实这些功能并不新鲜，之前做的比较早的就是无付费的“在线医院”，其实这也和医院的系统没有直接关连，只不过是将医院的号源拿出来放到在线平台上，患者通过在线医院预约挂号之后，到晚上平台再通过包括邮件、线下人工传递等方式返回给医院。后来又出现了预约挂号的在线付费，这时候其实就发生了本质变化，也就是说患者可以直接在“在线医院”上面直接预约，挂号完成之后可直接把钱付给医院，当患者到医院之后就能直接去看病。
而到了2019年，疫情到来，整个业界都开始启用互联网医疗以及“互联网医院”等，逐步出现了像趣医网这样大规模地与医院系统接通的模式。而从2020年到现在的一段时期，移动互联网医疗也经历了一些低谷。其实大家可以看到，这个阶段互联网医疗的发展历程是呈现螺旋形的，好像是高潮过来之后就会出现低谷，但是在这中间已经发生了一个本质的变化，就是各大医院对于互联网业务已经从最开始担心和排斥到现在普遍地开始接纳。即便是在低谷期，虽然整个医疗行业的投资可能降低了，但是放眼看去，几乎所有的大三甲医院都有自己的公众号以及网上预约挂号平台，患者几乎都能够在互联网上实现预约、挂号以及缴费的直接实时操作。
二、移动互联网医疗面临的挑战
移动互联网医疗也面临着一些挑战（如图1），比如受政策影响较大、盈利压力凸显以及难以深入医疗核心等。对于政策影响而言，目前总体来看国家的引导还是正向的，对于其他的“互联网+医疗”以及整个的应用还是偏向于鼓励的。
.jpg)
图1 移动互联网医疗面临的挑战
首先，这些应用的使用频率往往比较低；其次，对于国家向患者收费的管制也是比较严格的。与很多医院的合作都是基于医院的医患互动，这一点开展的也比较好，目前与很多医院都签署了相关的协议，可以实现患者在医院时，每个医生都有一个二维码，患者扫码之后就可以将自己与医生关联上了。当患者回去之后如果还有问题就可以线上询问自己的主治医生。这样的做法就解决了两个问题：第一个就是原来在线问诊的时候，医生往往不了解陌生患者的具体情况；第二个问题就是陌生患者线上提出问题的时候，即使之前已经看过病了，医生也可能想不起来。而基于这种将医院信息系统打通的模式，当患者线上问诊的时候，医生可以通过点击患者的头像了解患者当时就诊时的诊断情况以及医嘱等信息，从而非常方便地将医疗活动接续起来。
目前各个医院都特别欢迎这样的模式，并且国家对于诊后复诊的随访也有要求，政策也要求医院关怀出院的患者。但是遇到的最大问题就是收费问题，如果不收费，医生往往就会没有积极性，如果收费，对于公立医院而言，就需要有收费的依据，这也就导致了收费策略的障碍。目前这一点也正在突破，很多医院也在逐渐开展收费咨询的业务，并且与医院双方的配合也逐渐顺畅。最后一个挑战就是医疗核心领域难以深入，上面也有所提到，对于大多数医院信息系统而言，基本都是从底向上建设的，也就是在院内建设的比较多。除此之外，数据的归属权也存在问题，医院的数据到底是属于患者的还是属于医院的，在这一点上，国家的相关政策也不是很明确，导致各个医院都是在进行孤岛式的信息化建设，对于医疗数据对外共享或者传送都比较保守，所以目前的云平台也只是对患者提供服务，而不会存储数据，当交易完成，数据的生命周期也就结束了。
三、平台的设计与挑战
“医院+”平台建设情况，平台的两个业务特点：医疗核心业务系统的对接和在线交易。而这两个特点也带来了非常多的挑战，收获的经验、教训以及所具备的优势。首先介绍一下 “医院+”平台的建设情况，其实的其他业务平台基本上都是围绕“医院+”平台建设的。
3.1平台业务架构
.jpg)
图2业务框架图
“医院+”平台承担了的所有业务组件和专业业务平台（如图2），包括了分级诊疗、数据中心、预约挂号、门诊以及后面的供应链等各种各样的业务，这些业务都会到“医院+”平台上进行注册和提供服务。的“医院+”平台实现了微服务的架构，平台的技术架构和规范是由“医院+”部门总体搭建的。除此之外，“医院+”平台还负责整体的运维和监控，而周边的各个业务部门可以自行按照规范开发和注册自己的组件。除了在云平台上实现组件化，部署在各个医院中的端服务器，也就是“医院+”平台的前置2000多台服务器上面的应用也是实现了组件化的。不过除了在云平台上加上自己的业务组件外，还需要到提供服务的医院的端服务器上加上自己的组件，实现整个业务的对应。以上就是的“医院+”平台的集中和分布式管理的实现方案。目前，“医院+”平台已经对接了2000多家医院的核心业务系统，并且兼容目前所有厂家的异构业务系统。
3.2平台技术架构
“医院+”平台的技术架构主要还是依赖于阿里云所提供的技术服务架构，包括集群分发、HRV分发、RDS数据库、数据容灾备份以及只读库的分离等技术基本上都是基于阿里云的，而在阿里云的技术之上，京颐还做了一些扩展。阿里云的应用服务器的集群化做得非常好，现在基本上可以实现一个HRV能够带无限制的集群用户。所以从理论上来说，只需要一个阿里云的HRV服务就可以了。但是目前而言，阿里云的数据库服务还没有特别好的集群自动化实现，基本上还是单一的数据库。但是单一数据库的IO读写能力以及性能都是有限的，所以如果想要扩展数据库的能力就必须要在业务层面上进行规划。
经过分析，“医院+”平台的交易数据可以分为两端，一端是医院的数据，另外一端则是患者通过服务请求发过来的数据。对于医院的数据而言，如果需要进行写操作，那么这天然就是分布式的，因为数据必须要回写在医院这端，而在云平台之上则不需要再去保存医院的回写数据了，可以直接将实时的交易数据写回到医院中去，这样写的能力自然而言就会分散出去。而对于医院这端数据读取的能力则必须是集中的，当一个患者登录到云平台上面需要能够看到全国所有的医院，而不是只能够看到区域性的医院。所以需要将读数据的能力集中起来，这方面阿里云也能够提供比较好的支持，可以实现将一个数据库分多个只读实例出来，这样就可以将医院的号源、排班、医生以及基础信息全部定时地抽取到云平台之后提供给用户。
3.3阿里云资源在“医院+”平台上的使用情况
.jpg)
图3阿里云资源在“医院+”平台上的使用情况
目前，使用了阿里云的536台ECS、81台RDS、205个SLB、16台Redis、5个DTS，以及其它云资源及产品服务。上图3中对于整体业务生产系统所占用的云资源进行了数据统计，“医院+”平台大概占据了10%的资源，而目前用户量比较少的医疗云也占据了5%。基本上最低配置的业务单元就是1个HRV加上至少2个ECS，再加上1个RDS这样一整套资源。
3.4构建“医院+”平台过程中所遇到的技术难点
1、业务与系统异构，实现全国医院系统兼容的平台，工作量还是相当大的。
2、系统网络部署环境的挑战，整个分布式的交易系统会涉及到不同的厂家、不同的物理节点以及不同的地域之间进行交互。同样也会面临这样挑战的典型场景就是银行系统互相之间通过银联进行结算，以及通信行业中，网络上不同厂家的、跨地域的节点进行信息交互。
3、业务量的挑战--多分区支持，将分区以及分布式的架构加以优化以应对业务量的挑战，来满足7*24小时不间断业务需求。
4、版本管理
1) 高低版本兼容适配，将原来的版本兼容靠开发或者设计人员的主动思考，变成被动的集中管控，通过这种方式解决了版本的兼容问题。
2) 全量&增量升级，除了版本的兼容问题之外，还会存在版本的升级问题。
3) 远程升级，业务可靠性保障
四、平台的应用和展望
前面从技术角度分享了在搭建“医院+”平台过程中收获的一些经验和教训，未来基于围绕“医院+”平台，开展了一些业务，如医院+互联网的生态平台，希望能够提供给药店、医生、医院、支付方以及供应商各方参与的平台。而对于各种用户，平台也会提供不同的交易平台，比如在医生和患者之间提供了医患互动的平台，对于管理者而言则会提供移动管理的平台，对于医院和物资供应商之间提供了物资供应链的平台。总之“医院+”平台针对于不同的应用场景提供了各种各样的交易平台。
参考文献：
[1]医疗核心业务性能管理系统设计与应用，魏明月;凌琦鸣; 庞朝富，医学信息学杂志2020-06-25
[2]发展“云”上金融践行数字普惠，杨明，中国农村金融，2020-04-10
[3]基于云计算和服务化中台架构的医院信息系统构建，杨洋;严晓明;邓晓晖，中国卫生信息管理杂志2019-12-20
[4]共同协作:可持续发展目标、整合办法与机制，上海社会科学院信息研究所院，上海社会科学出版社，201903
[5]医疗信息运维管理平台探究，林帅，数字通信世界，2018-10-01，
[6]—种边防海岛伤病员急救系统的设计与应用，何健;石磊;孙文桥，中国数字医学，2017-04-15
[7]边界防护技术在医院信息系统安全建设中的应用，卫荣;耿明菲;李晓亮，中国信息界(e医疗)，2014-09-15
[8]基于门诊实时划卡结算信息系统的研究与应用，郝玉清;王浩术入，电脑知识与技2011-09-05
[9]医院信息系统的安全建设与管理，沈昆;杨松，中国医疗设备，2011-06-25
秦睿，男，山西省长治市上党区，出生于1997年8月16日，武汉学院信息工程学院软件工程专业，现研究方向是前端网页设计开发。