京颐CTO宋建康：如何应对系统高度分化异构的挑战，打造不间断服务的在线交易云平台

【现场视频】京颐CTO兼医疗云事业部总经理宋建康：基于医疗核心业务系统的在线交易云平台，点此进入→https://yq.aliyun.com/video/play/1171

---

摘要：在9月7日云栖专家“走进京颐”线下活动中，京颐CTO兼医疗云事业部总经理宋建康分享了移动互联网医疗的发展历程和所面临的挑战，以及京颐在线交易云平台的设计、挑战和应用，以及对于互联网医疗行业的未来展望。错过了线下活动的小伙伴们，不要错过本文哦~

本文内容根据演讲专家音频材料以及PPT整理而成。

前言

移动互联网医疗的发展
通常情况下，当提到云平台的时候，大家往往会联想到互联网和大数据等新技术，但是从本次分享的主题前面的定语就可以看出，在本次分享所提到的云平台与通常情况下大家所理解的云平台有所不同。首先，这里的云平台不是单纯的互联网云平台，其功能不仅仅限于在线交易，它还可以和各级医疗机构的内部局域网内的核心业务系统直接打通的，而这一差异对于整个云平台的管理以及业务交易会产生非常复杂的交互。其次，在这里之所以强调在线交易，是因为京颐集团在最近一两年的时间内对于大数据的收集和应用都投入了很大精力，但是就目前而言，数据的隐私性问题比较严重并且国家的相关政策不甚明朗。而京颐集团基于医疗核心业务系统的在线交易云平台目前聚焦在于给包括患者、医院以及第三方等提供实时的业务交易的通道，但目前暂时还没有将云平台上面的数据进行汇聚和保存。这是因为如果想要实现将云平台之上的数据进行汇聚和保存不仅需要提供庞大的存储空间，而且还需要负担起数据安全的重大责任。所以就目前而言，京颐的云平台基本上承担的是在线交易平台的任务，所做的就是把各方都打通，实现医疗核心业务相关的在线交易。
对于在线交易系统而言，听上去可能比较抽象，但是当提到互联网医疗，大家可能就比较熟悉了。其实上面所提到的在线交易也好，云平台也好，都离不开互联网医疗的发展。这里简单回顾一下移动互联网医疗的发展历程。在2011年的时候，移动互联网医疗概念开始被提出，之后的发展经历了几个阶段。首先是患者问诊类的APP开始上线，但其实它和医院的问诊系统是没有任何关系的，仍然只是医生和患者都在互联网上进行问答，并没有进入医疗的核心领域。之后，医生工具类APP开始上线，出现比如像丁香园等的应用，不过它们只是一些知识库，医生可以直接在上面做一些知识共享，这个阶段仍然和主流的医疗系统以及医院没有进行互联互通。再之后就开始出现大批的互联网医疗创业公司，此时有一些医院实现了在线的挂号、预约，其实这些功能并不新鲜，之前做的比较早的就是无付费的“在线医院”，其实这也和医院的系统没有直接关连，只不过是将医院的号源拿出来放到在线平台上，患者通过在线医院预约挂号之后，到晚上平台再通过包括邮件、线下人工传递等方式返回给医院。后来又出现了预约挂号的在线付费，这时候其实就发生了本质变化，也就是说患者可以直接在“在线医院”上面直接预约，挂号完成之后可直接把钱付给医院，当患者到医院之后就能直接去看病。所以当发展到这一步时其实就已经产生了比较本质的变化，这代表着线下的医疗系统已逐渐向互联网领域去延展了。

而到了2014年，互联网的风潮来了，整个业界都开始着手去做互联网医疗以及“互联网医院”等，逐步出现了像趣医网这样大规模地与医院系统接通的模式。而从2016年到现在的一段时期，移动互联网医疗也经历了一些低谷。其实大家可以看到，这个阶段互联网医疗的发展历程是呈现螺旋形的，好像是高潮过来之后就会出现低谷，但是在这中间已经发生了一个本质的变化，就是各大医院对于互联网业务已经从最开始担心和排斥到现在普遍地开始接纳。即便是在低谷期，虽然整个医疗行业的投资可能降低了，但是放眼看去，几乎所有的大三甲医院都有自己的公众号以及网上预约挂号平台，患者几乎都能够在互联网上实现预约、挂号以及缴费的直接实时操作。

其实，当移动互联网的风潮刮过去之后，其对于行业理念的定性和发展也产生了巨大的影响。当京颐在开始去做前两家医院业务的时候，医院对于互联网医院系统表现出极其慎重，甚至需要只能够进行单向访问，也就是说医院系统可以将内部的数据送出来，但是外部却不能直接去访问内部的数据，就好像是单通的二极管一样。

移动互联网医疗的堂吉诃德

今年有一篇文章上面列举了很多个“移动互联网医疗的堂吉诃德”，这里就包括了京颐集团的两家重要成员企业：京颐股份和趣医网。这篇文章当时提出了两个论点：第一个论点中国医疗体制问题对互联网的打通造成了非常多的障碍；第二个论点就是医疗行业的门槛非常高，互联网整合还存在相当的难度，包括医院内部信息系统的复杂度、收费问题以及国家政策问题都在影响医疗行业的互联网整合。

移动互联网医疗面临的挑战
移动互联网医疗也面临着一些挑战，比如受政策影响较大、盈利压力凸显以及难以深入医疗核心等。对于政策影响而言，目前总体来看国家的引导还是正向的，对于其他的“互联网+医疗”以及整个的应用还是偏向于鼓励的。对于互联网医疗的盈利压力而言，无论是纯线上的模式还是线上线下打通的模式，盈利的压力都是比较大的。
首先，这些应用的使用频率往往比较低；其次，对于国家向患者收费的管制也是比较严格的。京颐集团与很多医院的合作都是基于医院的医患互动，这一点开展的也比较好，目前与很多医院都签署了相关的协议，可以实现患者在医院时，每个医生都有一个二维码，患者扫码之后就可以将自己与医生关联上了。当患者回去之后如果还有问题就可以线上询问自己的主治医生。这样的做法就解决了两个问题：第一个就是原来在线问诊的时候，医生往往不了解陌生患者的具体情况；第二个问题就是陌生患者线上提出问题的时候，即使之前已经看过病了，医生也可能想不起来。而基于这种将医院信息系统打通的模式，当患者线上问诊的时候，医生可以通过点击患者的头像了解患者当时就诊时的诊断情况以及医嘱等信息，从而非常方便地将医疗活动接续起来。

目前各个医院都特别欢迎这样的模式，并且国家对于诊后复诊的随访也有要求，政策也要求医院关怀出院的患者。但是遇到的最大问题就是收费问题，如果不收费，医生往往就会没有积极性，如果收费，对于公立医院而言，就需要有收费的依据，这也就导致了收费策略的障碍。目前这一点也正在突破，很多医院也在逐渐开展收费咨询的业务，并且京颐集团与医院双方的配合也逐渐顺畅。最后一个挑战就是医疗核心领域难以深入，上面也有所提到，对于大多数医院信息系统而言，基本都是从底向上建设的，也就是在院内建设的比较多。除此之外，数据的归属权也存在问题，医院的数据到底是属于患者的还是属于医院的，在这一点上，国家的相关政策也不是很明确，导致各个医院都是在进行孤岛式的信息化建设，对于医疗数据对外共享或者传送都比较保守，所以目前京颐集团的云平台也只是对患者提供服务，而不会存储数据，当交易完成，数据的生命周期也就结束了。

京颐集团产品地图
下图所示的就是京颐集团的产品地图。目前京颐集团大概有60多款产品，整个京颐集团聚焦于医疗核心业务系统，而与传统的医疗信息化存在一个较大的差异就是：京颐集团在未来的核心战略就是互联网化和平台化。大家可以看到图中下面的“医疗机构应用”其实属于京颐集团具有优势的传统业务包括临床服务、医疗管理以及运营管理等。
相对于友商和合作伙伴，京颐集团最大的优势就是拥有核心平台性产品—— “医院+”平台。基于“医院+”平台之上，京颐集团在区域应用、患者应用以及第三方应用上面引申出了很多的互联网平台和业务方面的应用。整体而言，从医院外面的互联网项目向内部发展，以及从医院内部系统向外突破，这里分别是京颐股份的优势和趣医网的优势，所以双方在未来会慢慢地整合形成更大的优势互补。

一、平台的设计与挑战

前面的业务趋势分享完之后，再回顾一下京颐云平台的两个业务特点：医疗核心业务系统的对接和在线交易。而这两个特点也带来了非常多的挑战，接下来就为大家分享京颐集团在云平台建设中遇到的挑战，收获的经验、教训以及所具备的优势，期望能够为大家带来帮助。

“医院+”平台建设情况
首先介绍一下 “医院+”平台的建设情况，其实京颐集团的其他业务平台基本上都是围绕“医院+”平台建设的。截止2016年年底，“医院+”平台签约3000家二级以上公立医院，其中三甲医院有1200多家，占全国三甲医院的54%。在 “医院+”平台上面维护的中心服务器大概有500多台，各个端的前置服务器大概有2000多台，目前大概上线了1500多家医院。在上线的医院中，有一些使用的是双服务器，还有一些使用的是单服务器，分布在各个医院中的2000多台端服务器以及“医院+”平台上的500多台服务器组成了一个庞大的网络。最后，具备资金结算以及交易功能的医院大概有1000多家，这里的资金结算功能除了线上的预约缴费之外，还包括线下的财务对账等功能。就如同支付宝或者微信支付一样，患者缴纳的费用将会先交到区域的支付平台上，之后再去医院进行结算，这就不仅会涉及到业务流信息系统的直接打通，还会涉及到财务流的银行转账以及财务对接等。如上图所示的就是与京颐集团合作的医院在全国的整体分布图。从全国看来，除了西藏和青海地区比较少外，在其他的各个地区中，京颐集团合作医院的分布还是比较均匀的，这张地图上大概标注出了目前已经上线的1500多家医院。

平台业务架构

“医院+”平台承担了京颐集团的所有业务组件和专业业务平台，包括了分级诊疗、数据中心、预约挂号、门诊以及后面的供应链等各种各样的业务，这些业务都会到“医院+”平台上进行注册和提供服务。京颐集团的“医院+”平台实现了微服务的架构，平台的技术架构和规范是由“医院+”部门总体搭建的。除此之外，“医院+”平台还负责整体的运维和监控，而周边的各个业务部门可以自行按照规范开发和注册自己的组件。除了在云平台上实现组件化，部署在各个医院中的端服务器，也就是“医院+”平台的前置2000多台服务器上面的应用也是实现了组件化的。不过除了在云平台上加上自己的业务组件外，还需要到提供服务的医院的端服务器上加上自己的组件，实现整个业务的对应。以上就是京颐集团的“医院+”平台的集中和分布式管理的实现方案。目前，“医院+”平台已经对接了2000多家医院的核心业务系统，并且兼容目前所有厂家的异构业务系统。

平台技术架构
京颐集团的“医院+”平台的技术架构主要还是依赖于阿里云所提供的技术服务架构，包括集群分发、HRV分发、RDS数据库、数据容灾备份以及只读库的分离等技术基本上都是基于阿里云的，而在阿里云的技术之上，京颐还做了一些扩展。阿里云的应用服务器的集群化做得非常好，现在基本上可以实现一个HRV能够带无限制的集群用户。所以从理论上来说，只需要一个阿里云的HRV服务就可以了。但是目前而言，阿里云的数据库服务还没有特别好的集群自动化实现，基本上还是单一的数据库。但是单一数据库的IO读写能力以及性能都是有限的，所以如果想要扩展数据库的能力就必须要在业务层面上进行规划。

经过分析，“医院+”平台的交易数据可以分为两端，一端是医院的数据，另外一端则是患者通过服务请求发过来的数据。对于医院的数据而言，如果需要进行写操作，那么这天然就是分布式的，因为数据必须要回写在医院这端，而在云平台之上则不需要再去保存医院的回写数据了，可以直接将实时的交易数据写回到医院中去，这样写的能力自然而言就会分散出去。而对于医院这端数据读取的能力则必须是集中的，当一个患者登录到云平台上面需要能够看到全国所有的医院，而不是只能够看到区域性的医院。所以需要将读数据的能力集中起来，这方面阿里云也能够提供比较好的支持，可以实现将一个数据库分多个只读实例出来，这样就可以将医院的号源、排班、医生以及基础信息全部定时地抽取到云平台之后提供给用户。这样的数据是比较完整的，也就是说如果数据库的读能力不够，那么就可以拆分出来几个只读块就可以了。
而公共分区主要针对的是医院端的数据，其实全国只有一个公共分区，即使需要拆分也是拆分出几个只读分区出来，并且只读分区的数据需要与主分区严格地保持一致，这一部分阿里云也可以提供强大的技术支持，并且能够实现主分区和只读分区秒级的数据同步。业务分区存储的则是请求端的交易数据，比如患者的注册信息以及预约挂号信息等。对于这些信息而言，是无法做简单的分布式拆分和处理的，所以就需要对其进行业务的拆分。

根据患者的身份证或者手机号进行行政区域的划分，目前“医院+”平台的业务分区划分为南综合区和北综合区这两个。而未来随着业务的发展，可以很方便地进一步拆分成省级分区。这样的技术架构基本上能够解决目前容量的无限扩展问题，即使业务量再大，通过这样简单的拆分也能够支撑。而且这种拆分基本上不会造成业务的中断，而且在拆分出新的分区之后，可以很容易地实现数据的同步。比如原来有两个分区：南综合区和北综合区，这时把南综合区再拆分成两个之后，其实每个分区都拥有拆分前全部的数据，只不过会存在一些冗余数据，但是只要不动这些数据就好了，马上就能开启业务，所以拆分是比较容易的。

阿里云资源在“医院+”平台上的使用情况
目前，京颐集团使用了阿里云的536台ECS、81台RDS、205个SLB、16台Redis、5个DTS，以及其它云资源及产品服务。上图中对于整体业务生产系统所占用的云资源进行了数据统计，“医院+”平台大概占据了10%的资源，而目前用户量比较少的医疗云也占据了5%。基本上最低配置的业务单元就是1个HRV加上至少2个ECS，再加上1个RDS这样一整套资源。其实现在的服务器的计算能力还是比较强的，即使业务量会有所上升，对于全国的“医院+”平台，大概10台服务器就已经足够了。所以其实后面上涨的幅度会比较小，但是每个独立的业务单元和业务组件最基础的数量却不能减少太多，至少需要上述所说的这样一套物理组件，并且对于不同的组件而言，配置、价格以及容量也会有所差异。

构建“医院+”平台过程中所遇到的技术难点

在构建“医院+”平台的过程中，京颐集团遇到了以下技术难点、技术挑战以及应对的策略。

1、挑战一：业务与系统异构
业务和系统的异构体现得非常明显，目前平台一共对接了200多家HIS厂商，基本上全国能够提供HIS系统的厂商都已经对接过了。即便是县级人民医院这样的单个医院系统也会有100多个业务系统，而大型三甲医院则可能会拥有超过200个业务系统，所以可以说整个医院的系统以及业务是极其复杂的，这就是京颐集团在平台构建过程中遇到的第一个难点。
针对于上述的业务难点，其实是无法为每一家医院都单独开发一个业务平台的。所以京颐集团采取的解决方案是进行兼容，也就是做了参数以及差异性适配的配置。京颐集团在上线前50家医院的时候，客户化配置和客户化开发工作非常繁重，但是当做完50家医院之后，目前可以实现每上线一家医院几乎不需要做任何的系统开发，只需要做一些配置工作就可以了。

据数据统计，需要配置的系统参数大致有1000~2000个，这样就可以兼容2000个以上医院的系统差异。举个比较简单的例子，医院挂号这个业务在全国所有的医院系统里面的规则可能大概有20多种情况，因为可能某些医院的预约是不限号的，只需要约到某一天就可以了，而某些医院约到上午和下午是不能混淆的，患者只能在预约的上午或者下午来看病，还有一些医院可能预约的时候每5分钟或者每半个小时一个号。因为医院的管理水平以及地域不同，会导致业务要求完全不一样，所以想要实现全国医院系统兼容的平台，工作量还是相当大的。

2、挑战二：系统网络部署环境的挑战
第二个挑战就是系统网络的分布式部署，而整个分布式的交易系统会涉及到不同的厂家、不同的物理节点以及不同的地域之间进行交互。同样也会面临这样挑战的典型场景就是银行系统互相之间通过银联进行结算，以及通信行业中，网络上不同厂家的、跨地域的节点进行信息交互。京颐在实现平台的系统网络部署架构的时候，也参照了以上两种场景下的技术架构，但是仍旧会需要面对两个问题：第一个就是银行和通信行业对于内外网的隔离可能还没有医疗平台这么严格，所以对于医院的内外网隔离、网闸以及防火墙进行设计时，京颐借鉴了海关系统的一套解决方案来帮助解决安全问题；除了安全问题之外，还存在网域网和互联网的延迟问题以及内网IP问题，其实医院在之前可能连外网IP都没有，可能一些应用只有内网IP，所以这时候医院内的系统访问外部是没有问题的，但是当想要从外部访问医院系统内部却可能出问题。
除此之外，还存在事务控制的问题。对此，在最开始京颐也犯了很多错误，比如当请求一笔交易过去之后，因为这中间会经过很多环节，需要经过端服务器然后再送到医院内部的HIS系统中，HIS系统收到请求之后会进行处理，处理完成之后会返回一个正常的响应，但是因为网络压力特别大，可能出现断网进而造成没有收到响应，这时候常规的做法就是去做事务回滚，如果是缴费业务的话就要把钱退给患者。这时候医院就会找过来询问HIS在处理什么，为什么响应消息没有收到，这样就会产生各种各样的纠纷，所以说分布式的事务处理也是一个非常大的挑战。其实对于分布式事务的挑战而言，可以通过多次握手以及业务校验解决。也就是针对每一个业务最终是否能够成功，去进行三次握手或者反复探测和询问，当询问到确切的消息之后才可以办理退款等业务。对于每一个交易或者业务而言，会在正常的业务逻辑和正常处理上面增加额外的保证健壮性的业务逻辑。

3、挑战三：业务量的挑战--多分区支持
第三个挑战就是业务量的挑战，这一部分其实在前面已经分享过了，而且在业界里面阿里云的应用也经受住了考验。

4、挑战四： 7*24小时不间断服务
京颐是将分区以及分布式的架构加以优化以应对业务量的挑战，来满足7*24小时不间断业务需求。在互联网云平台上有一些比较成熟的技术，比如像比较常规的去中心化以及ZooKeeper分发等。而这里比较显著的问题是如图中的医院1、医院2以及医院N这样的会产生分布式不可控的业务。
举个比较简单的例子，像交互性的业务，当出现了错误，患者是会投诉的，最差的效果就是被投诉了之后再去改进这个问题。但是还有一些单向性的查询业务产生的错误，对此，可能连被用户投诉的机会都没有。比如患者上午去做一个检查，检查报告不会是立即给到的，可能需要等到下午或者第二天甚至一周以后才能给到，如果患者比较心急就会去系统上不断地进行查询，这样会产生两种结果：一种是能够查到，另外一种就是没有查到。如果在没有查到的情况之下，又存在两种可能情况：一种是报告没有出来；另外一种就是报告已经出来了，但是因为系统没做好，导致查询不到。在这样的情况之下，如果整体业务系统不去实现一些复杂的业务保障工作，是无法确保业务可用性的。在最初，京颐在这一点上也没有做，但是后来发现一些医院的业务量以及报告单数量很低，通过查找原因发现这些医院系统的HIS的接口更改了，这样就不会返回结果。

最后京颐针对于每一种业务的特性还做了很多的探测，最简单的模式就是拿一个已经有的报告单数据反复查询，比如每5分钟查询一次，如果每次都能够查询出来并且与之前的报告单的内容一样就说明这条通路是好的。通过这样的探测发现有一半以上的业务不好用，通过慢慢的整改现在可以达到90%以上的业务都是可用的。最后还会有一些问题，比如对于医院而言，其业务数据会需要归档的，当某一个报告单的ID现在能够查到，两周以后再使用相同的ID查询就已经查不到了，这是因为医院已经将这个报告归档了。因此对于这样的问题就需要去更新用例设计，所以其实整体系统的设计完善和系统的健全并不是一蹴而就的，而是在系统运转过程中不断地进行完善，并慢慢走向成熟。

业务流程中间经过的节点非常多，从患者的手机端APP，到像预约挂号这样的专业平台，到“医院+”平台，再到医院前置机的服务器，再到医院的真正的业务系统HIS这一长串的交易过程中，任何一个节点都有可能出错，而出错所导致的结果就是患者可能投诉说挂号失败了。面对这样的问题，京颐集团在一开始也会去逐个环节地进行检查，针对每个节点可能会需要花费很多时间去定位错误，后来发现这样做的效率实在是太低了，于是就进行了改造。从手机端开始，每一个请求都会带一个请求ID，而这个请求从头到尾经过的任何一个网页、所有的日志以及所有交互过程都会带上这个ID，最终一旦出现了问题，只需要从手机端将用户的请求提取出来，那么整个网络上所有节点的相关记录以及日志都会连接起来，这样就可以快速地实现端到端的错误定位分析。对于这个问题，其实意识到的越晚，进行改造所需要的工作量就会越大。当各种系统都已经完成之后再去添加这部分就会比较复杂，如果在一开始设计的时候就将这一点添加到系统中就会比较简单了。
因为整个网络上的节点特别多，如果让一个人来处理异常、进行维护或者掌管全局，其知识面可能并不完善。因为维护可能会涉及到设计、开发等各个业务部门，如果系统能够自动定位出问题应该归属于的业务部门，那么对于日常响应以及问题处理效率提升也会是非常明显的。所以京颐后来针对于不同的业务、不同的异常类型以及不同的问题又进行了分组，并在系统中做了一些内置，现在可以达到出现问题后，系统有80~90%的概率能够找到问题对应的责任人，即便是找错了再进行分发也会比传统方法更加迅速。

5、挑战五：版本管理
1) 高低版本兼容适配
版本适配问题也是目前存在的一个比较大的挑战。目前，针对终端应用的APP和服务器的适配，业界里面有一些比较成熟的版本适配的工具或者解决方案。但是在 趣医网平台上的适配其实是独有的两端适配，其中一端是用户端APP，而现存的用户手机里面可能存在5~10个版本的应用，而又不能每次都强制用户升级；另外一端则是放置在各个医院的前置服务器上的应用，因为目前 京颐的平台上有2000多家医院以及2000多台服务器，即使每天升级200家，那么每个版本都需要至少10天的时间进行升级才能完成，所以医院端的版本也会特别多。即便是做了大量的远程升级和远程监控工作，想要实现版本的统一也是不太可能的，所以趣医网平台至少需要允许5个版本的周期的差异。
除了需要兼容个性化差异之外，还需要兼容两端的版本差异。 趣医网平台采用了很多的技术手段，也做了很多技术方面的工作，但是最开始的效果并不明显，最终采用了集中管控的策略，就是在所有的开发环境、测试环境以及发布环境中，对于各个接口上的参数都记录下来，当每次新的版本出来之后就会去与上一个版本中所有的参数进行比较，形成一个参数变化的清单，如果发现了之前没有出现过的或者发生变化的参数再进行额外的处理。当采用了这个策略之后就基本上再也没有出现过版本兼容性的问题。而对于每一个增加和减少的参数是如何兼容的以及参数改变所带来的后果都是经过分析的，这样就相当于将原来的版本兼容靠开发或者设计人员的主动思考，变成被动的集中管控，通过这种方式解决了版本的兼容问题。

2) 全量&增量升级
除了版本的兼容问题之外，还会存在版本的升级问题。趣医网希望用户能够从任何一个版本一键式升级到最新版本，所以需要让各个操作人员能够根据目前的版本来获取升级包，这个过程要比王者荣耀的升级更加复杂，因为每次都要求必须升级到最新的版本。

3) 远程升级
在版本管理中，不可能每次都派人去各地医院进行系统升级，所以需要实现系统的远程升级。所以京颐还研发了HTM和ATM这样的服务端和远端的管理系统工具来实现系统的远程升级、数据的收集以及防病毒和远程监控等，甚至如果医院没有远程数据接口，还可以实现一个远程数据接口。而只要医院提供了这个接口，平台的工作人员不需要在现场就可以开拓一些新的业务并且提供一些新的接口部署过去，这也是京颐集团投入了大量精力维护起来的。目前，在接入平台中的至少60%的医院系统可以通过远程进行维护和升级。

6、挑战六：业务可靠性保障
下图所展示的是接入了京颐云平台的所有医院的智能监控。请求发送过去之后，会存在一定的响应时间，可能部分响应还没回来。
目前系统中的业务主要有两种：一种是实时的业务，这种业务将会实时地把数据传输到HIS系统，这部分主要是与支付相关的业务；还有一些业务比如像查询报告单以及病历等，往往会故意将这样的业务做成非实时交互的，也就是当一个这样的请求发送出去之后，只是在医院的端服务器上作为一个待办任务存储起来，而在平台的服务器上设置一个计时器，大概每经过1分钟或者30秒来集中获取待办任务并且集中地找HIS系统处理。这样做的好处就是无论全国的用户访问量有多大，对于HIS系统的冲击是可以控制的，即便是不间断地发送请求，在端口机这里也会有节制地将流量控制起来。
而这时候就需要对于待办任务在医院端的滞留情况以及滞留时间进行监控，以便于发现问题并且及时处理，下图中所展现的就是平台所提供的各种监控措施。

二、平台的应用和展望

前面从技术角度分享了在搭建“医院+”平台过程中收获的一些经验和教训，接下来简单介绍一下基于围绕“医院+”平台，京颐集团开展了哪些业务。

1、医院+互联网的生态平台
上图所示的就是“医院+”互联网生态平台的概念，“医院+”平台在底层会接入很多的实体医疗卫生机构，并且会通过上述提到的各种技术手段和方式提供能够满足实时交易和事务控制的集中的云平台。在“医院+”平台之上则会开展包括社保平台在内的很多的便民服务以及第三方服务等。

2、京颐互联网医疗服务生态圈
“医院+”平台的愿景就是希望能够提供给药店、医生、医院、支付方以及供应商各方参与的平台。而对于各种用户，平台也会提供不同的交易平台，比如在医生和患者之间提供了医患互动的平台，对于管理者而言则会提供移动管理的平台，对于医院和物资供应商之间提供了物资供应链的平台。总之“医院+”平台针对于不同的应用场景提供了各种各样的交易平台。

3、互联网就医便民服务平台
互联网就医便民服务平台搭建在“医院+”平台上面，它提供了预约挂号、排队候诊、在线缴费、报告单查询、个人健康档案管理、健康卡充值、家庭医生签约等端到端的全流程便捷就医服务，可以说只要是能够在门诊大厅办理的业务在互联网就医便民服务平台也都能够办理。

4、分级诊疗平台
分级诊疗平台是将中小医院和大医院以及各个医疗机构进行融合的平台，这个融合包括了患者的转出和转入、交互系统、远程会诊以及影像中心和心电中心等各种资源的共享。除了实现了网络上的患者转出转入之外，分级诊疗平台还会把各个医院之间的数据打通，当一个患者从下级医院转入到上级医院之后，上级医院的专家可以直接看到患者在下级医院拍摄的影像以及检查报告等。

5、四大中心——区域临检、影像、心电、病理中心
四大中心可以说是医院业务开展的基础。京颐集团的“医院+”平台在这部分有很多实际的落地案例和实践，目前的方案也是比较成熟的。

6、物资供应链平台
物资供应链平台所基于的是“医院+”平台与医院之间的对接，相对于前面所提到的平台，物资供应链平台还有一个不同的地方就是医院内的物资系统也是由这个平台沉淀的。在将医院内的专业物资系统构建完成之后，可以基于云平台接入到互联网上，而互联网上还存在供应商操作的集中平台，这样就可以将供应商和医院之间进行打通。

7、商保理赔平台
人力资源社会保障局的社保在报销的时候是比较方便的，患者可以直接在医院里报销。但是商业保险基本上还需要患者在出院之后携带自己的病历以及发票去找商业保险公司报销。而目前越来越多的商业保险公司也希望能够做到像普通社保一样在医院就能够结算，而这也是目前京颐集团成员企业之一趣医网的一个优势所在，也就是“医院+”平台和医院内部系统打通之后，就能够基于平台将所有的数据直接送给商业保险公司，那么就可以实现在线的保险结算，基本上在三分钟左右就能到款。这也是趣医网在主推的一款产品，目前已经上线了几十家医院，签约了大概几百家。

8、智能综合支付平台
智能综合支付平台作为打造医疗支付体系的核心产品，有效地结合了医疗机构、患者、银行等各方特点及需求，实现互联网的就医支付模式。智能综合支付平台这个概念其实是最先被京颐集团提出的，类似于最开始的 “银医通”业务，基本上就是使用自助机的模式，也就是将自助机摆放在医院的大厅中供患者进行支付以及相关操作。

智能综合支付平台的优点在于平台建设完成之后可以支持各种各样的支付模式，包括微信支付、支付宝支付以及其他第三方APP支付，其强大的功能在于方便财务之间的对账，医院的财务只需要与平台对账就可以了，至于与第三方对账的工作则由平台负责。如果是单一医院，基于“医院+”平台的技术实现就可以了，不会涉及到与“医院+”整个大平台的对接。除此之外，京颐集团还实现了区域的智能支付平台，比如像居民健康卡的一卡通以及洛阳这样大城市的各个医院拉通，并通过“医院+”平台进行交互。这些平台都立足于连接全国各个医院的大平台的搭建，而在大平台之上只需要花费很少的精力就可以将主要的业务都开展起来。

9、区域清结算平台
京颐集团还建设了很多区域清结算中心，可以方便地实现跨医院资金统一管理与结算，目前也比较成熟。

10、医疗云平台
在阿里云上面搭建完成之后，医疗云平台可以直接面向中小型医疗机构提供“一站式”IT软硬设施租赁式云服务。以云HIS、云HRP、云PACS为核心，全面满足各医疗机构所需，为客户提供基于互联网的低成本、免维护、高安全的SAAS服务。