cookieOptions = {...}; .醫院啊醫院,告訴你如何用 AWS 來應對挑戰 - 3S Market「全球智慧科技應用」市場資訊網

3S MARKET

3S MARKET
2016年5月25日 星期三

leiphone 熊蒙


編者注:本文作者為Medium專欄作者Christopher A. Ryan。他在Medium上發佈了一系列關於亞馬遜雲服務(AWS)的應用文章,堪稱是MediumAWS的頭號推廣者。

医院啊医院,告诉你如何用AWS来应对挑战


當今世界,醫療組織現在正在面臨種種挑戰:不斷變化的政府監管制度、減少的政府資金支持、增加的病人數量、呈爆發式增長的專利數據……所有這些都讓醫院資金感到壓力山大。

醫院不同於能夠銷售產品和服務的傳統產業,只有極少機會來出售服務,因此,它們必須尋找到解決方案來應對這些挑戰: 兼並與收購、外包非病人服務、運用迅猛發展的科技。這些措施讓醫院能夠生存下來,並能持續不斷地救助病人,造福人類。

儘管醫院現在面臨種種挑戰,但醫院較之往日已不似從前,今天的醫院可以以新的創新方式來解決問題。今天,我們來講講醫院如何運用AWS資源來應對挑戰。


現在,醫院正以一個前所未有的速度兼並與收購。20042009年全美有著55起醫院兼並收購案。然而,2010年,此數量上升到702012年更是增加到95。從2012年開始,兼並收購數量有所下降,而並不是因為醫院現在已經對兼並收購沒有興趣,而是因為小型獨立醫院組織已經被大型醫院兼並完了。今天的兼並收購趨勢,為大型醫院系統融入更大的醫院。這些兼並與收購為支持醫院的IT組織帶來了挑戰。
医院啊医院,告诉你如何用AWS来应对挑战



流動的IT服務
很多年來,醫院都是將 IT 科技服務外包給其他組織。其目的是降低IT成本,同時從這些專注於健康醫療科技的公司提取價值。這些公司能夠提供給醫院的核心價值之一,就是醫院的數據中心可以流向外來組織,有價值的醫院資源瞬間變成了可以賺取錢財的服務。這些資源包括新的門診、實驗室,甚至病房。

一旦醫院被另一外包醫院IT服務的組織兼並或收購,這些資源開始為醫院賺錢了。在不影響病人服務的前提下,醫院的數據中心若從一處轉移到另一處,醫院便會面臨成本損失。

一個典型的數據中心轉移項目需要籌劃6個月。在此期間,所有的IT資源將會投入到此項目,同時其他所有IT項目將會暫時凍結。此過程需要花費大量時間和金錢:硬件轉移至少需要花上整整一個週末,同時要運輸這些硬件的話,通常需要花費數千英鎊來租賃私人飛機或其他交通工具。

雖然這是一個勞神傷財的過程,但是此過程並不是一蹴而就的。下一場兼並或收購也許就近在咫尺,一家醫院在五年之內被收購了好幾次,也不是什麼讓人驚訝的事兒。

AWS如何解決
若一家公司簡單地採取措施來減少創新成本、增加機會,它面臨的挑戰並沒有上面提到的挑戰大。簡單的將技術支持從一家公司轉移到另一家公司,是一項任務,而不是項目。兼並收購並不能影響病人的照顧質量和數據,因此在此過程中,醫院面臨的挑戰不可小覷。


而我們可以用AWS來應對此挑戰,下面我們來列舉一下具體方法。

AWS Direct Connect
AWS Direct Connect提供的連接是醫院環境所需要的,因為其中轉移的數據量非常巨大,從病人數據到醫院員工數據,所有的數據轉移都可以通過AWS Direct Connect完成。

亞馬遜VPC
另一個要求就是亞馬遜Virtual Private Cloud(虛擬私人雲端),它能為AWS雲端提供一個獨立的部分,來為醫院環境服務。因為醫院都會有一個小型數據中心,醫院網絡必須擴展至AWS,來進行數據的無縫轉移。

 亞馬遜EC2和亞馬遜Elastic Block Store
亞馬遜EC2和亞馬遜Elastic Block Store形成了該組織數據中心基本的構建模組。

AWS Import/Export Snowball & VM Import/Export
醫院和病人的大型數據要從醫院轉移到AWS,需要通過AWS Import/Export Snowball來轉移。有了此工具,幾百兆兆字節的電子圖片、數據庫備份和其他的數據可以轉移到AWS資源,過程簡單,花費較少。

VM Import/Export則在服務器轉移到AWS EC2資源的過程中使用。

AWS Storage Gateway
AWS環境與公司數據相連,需要執行AWS Storage Gateway來同步數據。

亞馬遜 RDS&AWS Database Migration Service
AWS Database Migration Service為亞馬遜環境提供了一個轉移途徑,但是亞馬遜RDS為保持所有權、開源數據庫,提供了重要的途徑。

亞馬遜 WorkSpaces

在數據中心轉移到開源地點之後,醫院將使用虛擬工作台和應用基礎設施解決方法。用這種複雜的基礎設施和成本(硬件、軟件、執照、支持)來取代亞馬遜WorkSpaces是一個明智的措施。

医院啊医院,告诉你如何用AWS来应对挑战

電子圖片
過去幾年中,實體圖片經歷了巨大的轉變,由電子圖片轉移。科技不僅僅限制於最富有的醫院之中,小型醫院現在也在運用科技,來確保儲存病人圖片和其他的數據。隨著HIPAA(健康保險流通與責任法案)和聯邦政府規定的日益嚴格,收集和儲存的數據正以前所未有的數據增長。

保護數字圖片
多年以來,醫院在保障、儲存和保護數據上面臨的挑戰變得更加困難,對於最大的醫院系統也是如此。PACS(圖片存檔和通訊系統)可以從100兆兆字節開始,並在短短幾年中增加至幾百兆兆字節。其中,面臨的具體困難包括日積月累的數據儲存、硬件兼並、並以一個快速而持續的速度來支持和恢複數據。

很多醫院發現運用傳統工具來支持數據花銷較大。磁帶驅動器和基於磁盤的備份並不能解決兼並之中產生的數據。傳統方法的步驟是加倍的:在儲存層複製本地數據,然後在界外再複製一遍這些數據。這就將數據複製了三遍,形成了非常複雜昂貴的基礎設施,但是仍然不能保護數據免受傷害。關於這個問題,並沒有簡單的解決方法。

PACS基礎
在講述AWS的解決方法之前,很有必要解釋一下PACS圖片的數據生命圈。

一位病人來到醫院,前往門診部,接受物理療法。這種物理療法可能只是電子X-Ray儀或者是核磁共振機,這些儀器都會產生出一些圖片,而這些圖片會暫時儲存在儀器之中,幾年之後才會移除。這就讓技術人員在必要時向中央PACS重新發送這些圖片。

技術人員或醫生一旦收集到圖片,加入圖片備注或者其他數據,這些圖片的付印件將會發送到中心PACS地方。圖片會在瞬間複製,並會儲存在設備中一個叫做「短期知識庫」的地方,這樣一來,一個無損的壓縮文件就被創造出來了。

放射線醫師可以用「短期知識庫」來儲存數據,當數據變得不再新時,文件將會自動刪除。如果醫師後來需要瀏覽這些文件,他可以從「長期知識庫」中查看數據,並將它儲存在短期數據庫中,以便隨時使用。

本地儲存需求
PACS數據的大小和數量通常會阻止「短期知識庫」再次定位。醫生查看病人文件數據的能力意義重大,通常與一個病人能否活下來息息相關。

醫院中的「短期知識庫」必須隨時都能被醫生獲取,以備不時之需。而「長期知識庫」可以交給AWS來負責。

AWS如何解決
前文提到的很多AWS解決方法適用於數據轉移過程,和PACS環境的長期支持,而下文提到的解決辦法將致力於其他挑戰。

亞馬遜Elastic File System
傳統的PACS應用建立在UNIX服務器頂端,並需要數據的直接儲存。增長的儲存需求和正常的市場推動將會帶來一些改變。現在,越來越多公司在開源操作系統上來建立應用,並基於儲存設備來平衡這些數據。
  
而亞馬遜Elastic File System讓長期資料儲存定位到固態硬碟中,並通過網路檔案系統將這些資料連接到PACS中。

亞馬遜Glacier

亞馬遜Glacier和亞馬遜Storage Gateway一樣,可以完美解決提供長期儲存數據的問題。它能讓數據連接變得花費更小。亞馬遜Glacier使用的原型是iSCSI,它能讓昂貴的醫院儲存數據和亞馬遜資源直接連接。

医院啊医院,告诉你如何用AWS来应对挑战


災難防治
對於醫院來說,抗災救災能力是至關重要的。每當自然災難爆發,醫院將會面臨巨大的挑戰。傳統企業通常會在災難之後關門大吉,而醫院卻將陷入空前忙碌的狀態。這要求醫院不僅需要快速從災難中恢復過來,還要擔任起搶救病人的重任。
而更加重要的是,醫院必須讓病人數據免受災難的侵襲。即時醫院不能在災難中幸存下來,數據也要幸存下來。從2005年的卡翠娜颶風中,我們就能吸取到教訓。那些準備不足的醫院丟失了病人的數據。例如,癌症病人在此醫院的數據將會被損壞,並無法恢復。那麼醫生如何接著治療呢?這將會給病人帶了很多麻煩,甚至會危及到生命。

AWS如何解決
AWS可以很好地解決這些問題。亞馬遜可以為病人數據提供一個HIPAA許可、安全的儲存地點。如果醫院不能幸免於難,AWS的作用就體現出來了,這與病人生死攸關。

結論
上文我們談到了醫院將面臨的三個挑戰,以及利用AWS應對這些挑戰的方法,這些解決方法可以縮減信息科技成本,讓醫院在兼並與收購中靈活地生存下來,併發展壯大。

當今醫療行業瞬息萬變,醫院的職能雖然仍然是救死扶傷,但是醫院也需要融入到科技滾滾的浪潮之中,而AWS就是醫院能夠利用的科技之一。總而言之,醫院只有與時俱進,才能更好地造福人類。
Via:Medium

                                                                                                                                                                                                                            

0 comments: