862
人物
京頤CTO宋建康：如何應對係統高度分化異構的挑戰，打造不間斷服務的在線交易雲平台
【現場視頻】京頤CTO兼醫療雲事業部總經理宋建康：基於醫療核心業務係統的在線交易雲平台，點此進入→https://yq.aliyun.com/video/play/1171
摘要：在9月7日雲棲專家“走進京頤”線下活動中，京頤CTO兼醫療雲事業部總經理宋建康分享了移動互聯網醫療的發展曆程和所麵臨的挑戰，以及京頤在線交易雲平台的設計、挑戰和應用，以及對於互聯網醫療行業的未來展望。錯過了線下活動的小夥伴們，不要錯過本文哦~
本文內容根據演講專家音頻材料以及PPT整理而成。
前言
移動互聯網醫療的發展
通常情況下，當提到雲平台的時候，大家往往會聯想到互聯網和大數據等新技術，但是從本次分享的主題前麵的定語就可以看出，在本次分享所提到的雲平台與通常情況下大家所理解的雲平台有所不同。首先，這裏的雲平台不是單純的互聯網雲平台，其功能不僅僅限於在線交易，它還可以和各級醫療機構的內部局域網內的核心業務係統直接打通的，而這一差異對於整個雲平台的管理以及業務交易會產生非常複雜的交互。其次，在這裏之所以強調在線交易，是因為京頤集團在最近一兩年的時間內對於大數據的收集和應用都投入了很大精力，但是就目前而言，數據的隱私性問題比較嚴重並且國家的相關政策不甚明朗。而京頤集團基於醫療核心業務係統的在線交易雲平台目前聚焦在於給包括患者、醫院以及第三方等提供實時的業務交易的通道，但目前暫時還沒有將雲平台上麵的數據進行匯聚和保存。這是因為如果想要實現將雲平台之上的數據進行匯聚和保存不僅需要提供龐大的存儲空間，而且還需要負擔起數據安全的重大責任。所以就目前而言，京頤的雲平台基本上承擔的是在線交易平台的任務，所做的就是把各方都打通，實現醫療核心業務相關的在線交易。
而到了2014年，互聯網的風潮來了，整個業界都開始著手去做互聯網醫療以及“互聯網醫院”等，逐步出現了像趣醫網這樣大規模地與醫院係統接通的模式。而從2016年到現在的一段時期，移動互聯網醫療也經曆了一些低穀。其實大家可以看到，這個階段互聯網醫療的發展曆程是呈現螺旋形的，好像是高潮過來之後就會出現低穀，但是在這中間已經發生了一個本質的變化，就是各大醫院對於互聯網業務已經從最開始擔心和排斥到現在普遍地開始接納。即便是在低穀期，雖然整個醫療行業的投資可能降低了，但是放眼看去，幾乎所有的大三甲醫院都有自己的公眾號以及網上預約掛號平台，患者幾乎都能夠在互聯網上實現預約、掛號以及繳費的直接實時操作。
其實，當移動互聯網的風潮刮過去之後，其對於行業理念的定性和發展也產生了巨大的影響。當京頤在開始去做前兩家醫院業務的時候，醫院對於互聯網醫院係統表現出極其慎重，甚至需要隻能夠進行單向訪問，也就是說醫院係統可以將內部的數據送出來，但是外部卻不能直接去訪問內部的數據，就好像是單通的二極管一樣。
今年有一篇文章上麵列舉了很多個“移動互聯網醫療的堂吉訶德”，這裏就包括了京頤集團的兩家重要成員企業：京頤股份和趣醫網。這篇文章當時提出了兩個論點：第一個論點中國醫療體製問題對互聯網的打通造成了非常多的障礙；第二個論點就是醫療行業的門檻非常高，互聯網整合還存在相當的難度，包括醫院內部信息係統的複雜度、收費問題以及國家政策問題都在影響醫療行業的互聯網整合。
移動互聯網醫療麵臨的挑戰
移動互聯網醫療也麵臨著一些挑戰，比如受政策影響較大、盈利壓力凸顯以及難以深入醫療核心等。對於政策影響而言，目前總體來看國家的引導還是正向的，對於其他的“互聯網+醫療”以及整個的應用還是偏向於鼓勵的。對於互聯網醫療的盈利壓力而言，無論是純線上的模式還是線上線下打通的模式，盈利的壓力都是比較大的。
目前各個醫院都特別歡迎這樣的模式，並且國家對於診後複診的隨訪也有要求，政策也要求醫院關懷出院的患者。但是遇到的最大問題就是收費問題，如果不收費，醫生往往就會沒有積極性，如果收費，對於公立醫院而言，就需要有收費的依據，這也就導致了收費策略的障礙。目前這一點也正在突破，很多醫院也在逐漸開展收費谘詢的業務，並且京頤集團與醫院雙方的配合也逐漸順暢。最後一個挑戰就是醫療核心領域難以深入，上麵也有所提到，對於大多數醫院信息係統而言，基本都是從底向上建設的，也就是在院內建設的比較多。除此之外，數據的歸屬權也存在問題，醫院的數據到底是屬於患者的還是屬於醫院的，在這一點上，國家的相關政策也不是很明確，導致各個醫院都是在進行孤島式的信息化建設，對於醫療數據對外共享或者傳送都比較保守，所以目前京頤集團的雲平台也隻是對患者提供服務，而不會存儲數據，當交易完成，數據的生命周期也就結束了。
京頤集團產品地圖
下圖所示的就是京頤集團的產品地圖。目前京頤集團大概有60多款產品，整個京頤集團聚焦於醫療核心業務係統，而與傳統的醫療信息化存在一個較大的差異就是：京頤集團在未來的核心戰略就是互聯網化和平台化。大家可以看到圖中下麵的“醫療機構應用”其實屬於京頤集團具有優勢的傳統業務包括臨床服務、醫療管理以及運營管理等。
一、平台的設計與挑戰
前麵的業務趨勢分享完之後，再回顧一下京頤雲平台的兩個業務特點：醫療核心業務係統的對接和在線交易。而這兩個特點也帶來了非常多的挑戰，接下來就為大家分享京頤集團在雲平台建設中遇到的挑戰，收獲的經驗、教訓以及所具備的優勢，期望能夠為大家帶來幫助。
“醫院+”平台建設情況
平台業務架構
“醫院+”平台承擔了京頤集團的所有業務組件和專業業務平台，包括了分級診療、數據中心、預約掛號、門診以及後麵的供應鏈等各種各樣的業務，這些業務都會到“醫院+”平台上進行注冊和提供服務。京頤集團的“醫院+”平台實現了微服務的架構，平台的技術架構和規範是由“醫院+”部門總體搭建的。除此之外，“醫院+”平台還負責整體的運維和監控，而周邊的各個業務部門可以自行按照規範開發和注冊自己的組件。除了在雲平台上實現組件化，部署在各個醫院中的端服務器，也就是“醫院+”平台的前置2000多台服務器上麵的應用也是實現了組件化的。不過除了在雲平台上加上自己的業務組件外，還需要到提供服務的醫院的端服務器上加上自己的組件，實現整個業務的對應。以上就是京頤集團的“醫院+”平台的集中和分布式管理的實現方案。目前，“醫院+”平台已經對接了2000多家醫院的核心業務係統，並且兼容目前所有廠家的異構業務係統。
京頤集團的“醫院+”平台的技術架構主要還是依賴於阿裏雲所提供的技術服務架構，包括集群分發、HRV分發、RDS數據庫、數據容災備份以及隻讀庫的分離等技術基本上都是基於阿裏雲的，而在阿裏雲的技術之上，京頤還做了一些擴展。阿裏雲的應用服務器的集群化做得非常好，現在基本上可以實現一個HRV能夠帶無限製的集群用戶。所以從理論上來說，隻需要一個阿裏雲的HRV服務就可以了。但是目前而言，阿裏雲的數據庫服務還沒有特別好的集群自動化實現，基本上還是單一的數據庫。但是單一數據庫的IO讀寫能力以及性能都是有限的，所以如果想要擴展數據庫的能力就必須要在業務層麵上進行規劃。
經過分析，“醫院+”平台的交易數據可以分為兩端，一端是醫院的數據，另外一端則是患者通過服務請求發過來的數據。對於醫院的數據而言，如果需要進行寫操作，那麼這天然就是分布式的，因為數據必須要回寫在醫院這端，而在雲平台之上則不需要再去保存醫院的回寫數據了，可以直接將實時的交易數據寫回到醫院中去，這樣寫的能力自然而言就會分散出去。而對於醫院這端數據讀取的能力則必須是集中的，當一個患者登錄到雲平台上麵需要能夠看到全國所有的醫院，而不是隻能夠看到區域性的醫院。所以需要將讀數據的能力集中起來，這方麵阿裏雲也能夠提供比較好的支持，可以實現將一個數據庫分多個隻讀實例出來，這樣就可以將醫院的號源、排班、醫生以及基礎信息全部定時地抽取到雲平台之後提供給用戶。這樣的數據是比較完整的，也就是說如果數據庫的讀能力不夠，那麼就可以拆分出來幾個隻讀塊就可以了。
根據患者的身份證或者手機號進行行政區域的劃分，目前“醫院+”平台的業務分區劃分為南綜合區和北綜合區這兩個。而未來隨著業務的發展，可以很方便地進一步拆分成省級分區。這樣的技術架構基本上能夠解決目前容量的無限擴展問題，即使業務量再大，通過這樣簡單的拆分也能夠支撐。而且這種拆分基本上不會造成業務的中斷，而且在拆分出新的分區之後，可以很容易地實現數據的同步。比如原來有兩個分區：南綜合區和北綜合區，這時把南綜合區再拆分成兩個之後，其實每個分區都擁有拆分前全部的數據，隻不過會存在一些冗餘數據，但是隻要不動這些數據就好了，馬上就能開啟業務，所以拆分是比較容易的。
阿裏雲資源在“醫院+”平台上的使用情況
構建“醫院+”平台過程中所遇到的技術難點
在構建“醫院+”平台的過程中，京頤集團遇到了以下技術難點、技術挑戰以及應對的策略。
1、挑戰一：業務與係統異構
業務和係統的異構體現得非常明顯，目前平台一共對接了200多家HIS廠商，基本上全國能夠提供HIS係統的廠商都已經對接過了。即便是縣級人民醫院這樣的單個醫院係統也會有100多個業務係統，而大型三甲醫院則可能會擁有超過200個業務係統，所以可以說整個醫院的係統以及業務是極其複雜的，這就是京頤集團在平台構建過程中遇到的第一個難點。
據數據統計，需要配置的係統參數大致有1000~2000個，這樣就可以兼容2000個以上醫院的係統差異。舉個比較簡單的例子，醫院掛號這個業務在全國所有的醫院係統裏麵的規則可能大概有20多種情況，因為可能某些醫院的預約是不限號的，隻需要約到某一天就可以了，而某些醫院約到上午和下午是不能混淆的，患者隻能在預約的上午或者下午來看病，還有一些醫院可能預約的時候每5分鍾或者每半個小時一個號。因為醫院的管理水平以及地域不同，會導致業務要求完全不一樣，所以想要實現全國醫院係統兼容的平台，工作量還是相當大的。
2、挑戰二：係統網絡部署環境的挑戰
第二個挑戰就是係統網絡的分布式部署，而整個分布式的交易係統會涉及到不同的廠家、不同的物理節點以及不同的地域之間進行交互。同樣也會麵臨這樣挑戰的典型場景就是銀行係統互相之間通過銀聯進行結算，以及通信行業中，網絡上不同廠家的、跨地域的節點進行信息交互。京頤在實現平台的係統網絡部署架構的時候，也參照了以上兩種場景下的技術架構，但是仍舊會需要麵對兩個問題：第一個就是銀行和通信行業對於內外網的隔離可能還沒有醫療平台這麼嚴格，所以對於醫院的內外網隔離、網閘以及防火牆進行設計時，京頤借鑒了海關係統的一套解決方案來幫助解決安全問題；除了安全問題之外，還存在網域網和互聯網的延遲問題以及內網IP問題，其實醫院在之前可能連外網IP都沒有，可能一些應用隻有內網IP，所以這時候醫院內的係統訪問外部是沒有問題的，但是當想要從外部訪問醫院係統內部卻可能出問題。
3、挑戰三：業務量的挑戰--多分區支持
第三個挑戰就是業務量的挑戰，這一部分其實在前麵已經分享過了，而且在業界裏麵阿裏雲的應用也經受住了考驗。
4、挑戰四： 7*24小時不間斷服務
京頤是將分區以及分布式的架構加以優化以應對業務量的挑戰，來滿足7*24小時不間斷業務需求。在互聯網雲平台上有一些比較成熟的技術，比如像比較常規的去中心化以及ZooKeeper分發等。而這裏比較顯著的問題是如圖中的醫院1、醫院2以及醫院N這樣的會產生分布式不可控的業務。
最後京頤針對於每一種業務的特性還做了很多的探測，最簡單的模式就是拿一個已經有的報告單數據反複查詢，比如每5分鍾查詢一次，如果每次都能夠查詢出來並且與之前的報告單的內容一樣就說明這條通路是好的。通過這樣的探測發現有一半以上的業務不好用，通過慢慢的整改現在可以達到90%以上的業務都是可用的。最後還會有一些問題，比如對於醫院而言，其業務數據會需要歸檔的，當某一個報告單的ID現在能夠查到，兩周以後再使用相同的ID查詢就已經查不到了，這是因為醫院已經將這個報告歸檔了。因此對於這樣的問題就需要去更新用例設計，所以其實整體係統的設計完善和係統的健全並不是一蹴而就的，而是在係統運轉過程中不斷地進行完善，並慢慢走向成熟。
業務流程中間經過的節點非常多，從患者的手機端APP，到像預約掛號這樣的專業平台，到“醫院+”平台，再到醫院前置機的服務器，再到醫院的真正的業務係統HIS這一長串的交易過程中，任何一個節點都有可能出錯，而出錯所導致的結果就是患者可能投訴說掛號失敗了。麵對這樣的問題，京頤集團在一開始也會去逐個環節地進行檢查，針對每個節點可能會需要花費很多時間去定位錯誤，後來發現這樣做的效率實在是太低了，於是就進行了改造。從手機端開始，每一個請求都會帶一個請求ID，而這個請求從頭到尾經過的任何一個網頁、所有的日誌以及所有交互過程都會帶上這個ID，最終一旦出現了問題，隻需要從手機端將用戶的請求提取出來，那麼整個網絡上所有節點的相關記錄以及日誌都會連接起來，這樣就可以快速地實現端到端的錯誤定位分析。對於這個問題，其實意識到的越晚，進行改造所需要的工作量就會越大。當各種係統都已經完成之後再去添加這部分就會比較複雜，如果在一開始設計的時候就將這一點添加到係統中就會比較簡單了。
5、挑戰五：版本管理
1) 高低版本兼容適配
版本適配問題也是目前存在的一個比較大的挑戰。目前，針對終端應用的APP和服務器的適配，業界裏麵有一些比較成熟的版本適配的工具或者解決方案。但是在趣醫網平台上的適配其實是獨有的兩端適配，其中一端是用戶端APP，而現存的用戶手機裏麵可能存在5~10個版本的應用，而又不能每次都強製用戶升級；另外一端則是放置在各個醫院的前置服務器上的應用，因為目前京頤的平台上有2000多家醫院以及2000多台服務器，即使每天升級200家，那麼每個版本都需要至少10天的時間進行升級才能完成，所以醫院端的版本也會特別多。即便是做了大量的遠程升級和遠程監控工作，想要實現版本的統一也是不太可能的，所以趣醫網平台至少需要允許5個版本的周期的差異。
2) 全量&增量升級
3) 遠程升級
6、挑戰六：業務可靠性保障
下圖所展示的是接入了京頤雲平台的所有醫院的智能監控。請求發送過去之後，會存在一定的響應時間，可能部分響應還沒回來。
二、平台的應用和展望
前麵從技術角度分享了在搭建“醫院+”平台過程中收獲的一些經驗和教訓，接下來簡單介紹一下基於圍繞“醫院+”平台，京頤集團開展了哪些業務。
1、醫院+互聯網的生態平台
2、京頤互聯網醫療服務生態圈
3、互聯網就醫便民服務平台
4、分級診療平台
5、四大中心——區域臨檢、影像、心電、病理中心
6、物資供應鏈平台
7、商保理賠平台
8、智能綜合支付平台
智能綜合支付平台的優點在於平台建設完成之後可以支持各種各樣的支付模式，包括微信支付、支付寶支付以及其他第三方APP支付，其強大的功能在於方便財務之間的對賬，醫院的財務隻需要與平台對賬就可以了，至於與第三方對賬的工作則由平台負責。如果是單一醫院，基於“醫院+”平台的技術實現就可以了，不會涉及到與“醫院+”整個大平台的對接。除此之外，京頤集團還實現了區域的智能支付平台，比如像居民健康卡的一卡通以及洛陽這樣大城市的各個醫院拉通，並通過“醫院+”平台進行交互。這些平台都立足於連接全國各個醫院的大平台的搭建，而在大平台之上隻需要花費很少的精力就可以將主要的業務都開展起來。
9、區域清結算平台
10、醫療雲平台
最後更新：2017-09-16 16:04:25