近些年，各家醫(yī)院均采用多種措施推進(jìn)醫(yī)療數(shù)據(jù)的開發(fā)和利用，希望從數(shù)據(jù)服務(wù)的層面提升醫(yī)院運(yùn)營(yíng)效能、改進(jìn)醫(yī)療質(zhì)量、提升患者服務(wù)。不過(guò)，由于醫(yī)療數(shù)據(jù)是在HIS、LIS、PACS、EMR等醫(yī)院信息系統(tǒng)中產(chǎn)生的，這些異構(gòu)系統(tǒng)越建越多，存在數(shù)據(jù)標(biāo)準(zhǔn)不統(tǒng)一的現(xiàn)象，這就導(dǎo)致了醫(yī)院的數(shù)據(jù)共享能力差、數(shù)據(jù)利用成本高、數(shù)據(jù)使用效率低，甚至數(shù)據(jù)無(wú)法使用的問題。要解決這些問題，必須進(jìn)行全面的數(shù)據(jù)治理。

劉慈欣在《三體》里描述人類地球的未來(lái)城市是樹狀的。在小說(shuō)中，作者生動(dòng)描繪了未來(lái)人類在樹狀城市里活動(dòng)的高效率、快捷和方便，這讓我們不禁思考，能不能將醫(yī)療異構(gòu)系統(tǒng)中的數(shù)據(jù)看成“樹狀”，然后按看圖說(shuō)話的全視圖方式進(jìn)行方便快捷的訪問查詢呢？

IT領(lǐng)域確實(shí)就有這樣的數(shù)據(jù)挖掘工具，而且正被FaceBook、淘寶、騰訊等擁有恐龍級(jí)用戶群、每天生產(chǎn)海量數(shù)據(jù)的公司使用著。這就是GraphQL技術(shù)，只是目前在醫(yī)療領(lǐng)域還比較少見。它能幫助開發(fā)人員進(jìn)行數(shù)據(jù)挖掘，節(jié)約大量的精力和成本，使得用戶可以快速、敏捷地挖掘數(shù)據(jù)并進(jìn)行賦能應(yīng)用。

云南省紅河州滇南中心醫(yī)院信息中心軟件開發(fā)組經(jīng)過(guò)學(xué)習(xí)和探索，在微服務(wù)數(shù)據(jù)中臺(tái)的基礎(chǔ)上，創(chuàng)新地應(yīng)用GraphQL技術(shù)進(jìn)行醫(yī)療數(shù)據(jù)挖掘與治理。具體方式是以圖狀數(shù)據(jù)結(jié)構(gòu)進(jìn)行存儲(chǔ)和查詢，實(shí)現(xiàn)醫(yī)療數(shù)據(jù)的全聯(lián)接集成，構(gòu)建醫(yī)療數(shù)據(jù)全聯(lián)接服務(wù)新模式。

本文旨在闡述通過(guò)結(jié)合醫(yī)院醫(yī)療場(chǎng)景和信息化特征，探索如何應(yīng)用GraphQL新技術(shù)在醫(yī)療數(shù)據(jù)開發(fā)中起到關(guān)鍵核心作用，從而高效率、低成本地推進(jìn)醫(yī)療數(shù)據(jù)服務(wù)工作，希望總結(jié)一套可復(fù)制、可推廣的經(jīng)驗(yàn)，供醫(yī)院信息部門、醫(yī)療信息化系統(tǒng)提供商及醫(yī)院大數(shù)據(jù)部門參考。

醫(yī)院數(shù)據(jù)服務(wù)中存在的問題

1.數(shù)據(jù)接口開發(fā)問題

對(duì)于醫(yī)院信息部門而言，提供信息系統(tǒng)數(shù)據(jù)接口服務(wù)是最常見的一項(xiàng)工作。有的醫(yī)院必須由第三方提供此項(xiàng)服務(wù)，接口費(fèi)非常昂貴，而這些接口提供的數(shù)據(jù)其實(shí)大同小異。對(duì)于有一定技術(shù)開發(fā)能力的醫(yī)院而言，由信息科自主開發(fā)接口也是一件較為困難的事情。因?yàn)閺募夹g(shù)角度來(lái)看，負(fù)責(zé)數(shù)據(jù)接口的開發(fā)人員往往處于被動(dòng)一方，需要由接口調(diào)用方整理具體需要開發(fā)數(shù)據(jù)的接口文檔，再根據(jù)需求文檔進(jìn)行定制化開發(fā)，往往難以復(fù)用。

實(shí)際上，這些接口存在很多共性數(shù)據(jù)。基于集成平臺(tái)提供數(shù)據(jù)接口服務(wù)的醫(yī)院，開始使用RESTful等微服務(wù)工具來(lái)構(gòu)建統(tǒng)一的數(shù)據(jù)接口平臺(tái)，一般是由開發(fā)方自行擬定醫(yī)院業(yè)務(wù)常用的數(shù)據(jù)字段，不管對(duì)方是否需要，都進(jìn)行統(tǒng)一提供。

這種方式的弊端是：業(yè)務(wù)需求增多后，應(yīng)用通過(guò)接口返回的字段會(huì)越來(lái)越多；而具體到某個(gè)應(yīng)用的前端頁(yè)面或第三方調(diào)用者而言，可能需要的只是其中一小部分?jǐn)?shù)據(jù)而已。這種臃腫的接口解決方案會(huì)增加額外的網(wǎng)絡(luò)傳輸量，導(dǎo)致接口越來(lái)越慢，這也是很多醫(yī)院信息系統(tǒng)“跑不快”的主要原因之一。

2.數(shù)據(jù)集成及利用問題

要實(shí)現(xiàn)醫(yī)療數(shù)據(jù)的利用，首先要解決數(shù)據(jù)集成的問題，醫(yī)院需要對(duì)兩方面數(shù)據(jù)進(jìn)行集成：一是針對(duì)醫(yī)療服務(wù)對(duì)象（患者）進(jìn)行診療信息收集，將分布在醫(yī)院各異構(gòu)系統(tǒng)中的診療數(shù)據(jù)進(jìn)行統(tǒng)一集成，構(gòu)建實(shí)時(shí)聯(lián)通的臨床數(shù)據(jù)中心，即CDR；二是圍繞醫(yī)療質(zhì)量和科研管理進(jìn)行數(shù)據(jù)集成，構(gòu)建對(duì)實(shí)時(shí)性要求不高的運(yùn)營(yíng)及科研數(shù)據(jù)中心，即ODR、RDR等。

其次要基于集成數(shù)據(jù)，快速、實(shí)時(shí)、智能、安全、清晰、定向地提供給數(shù)據(jù)服務(wù)對(duì)象，也即具體的應(yīng)用程序或數(shù)據(jù)接口進(jìn)行數(shù)據(jù)使用。目前醫(yī)院的常規(guī)思維是建設(shè)集成平臺(tái)進(jìn)行數(shù)據(jù)集成后，完成患者360度視圖和BI應(yīng)用，分別配置給臨床醫(yī)生工作站和部分管理者使用。

在國(guó)家衛(wèi)生健康委互聯(lián)互通標(biāo)準(zhǔn)化成熟度測(cè)評(píng)、電子病歷系統(tǒng)應(yīng)用水平分級(jí)評(píng)價(jià)等工作的推動(dòng)下，借助集成平臺(tái)實(shí)現(xiàn)醫(yī)療數(shù)據(jù)的集成和開發(fā)服務(wù)已成趨勢(shì)。但這也導(dǎo)致醫(yī)院醫(yī)療數(shù)據(jù)開發(fā)工作普遍存在技術(shù)單一、效率不高、建設(shè)周期漫長(zhǎng)、數(shù)據(jù)利用率不高、數(shù)據(jù)解耦度不足、完全依賴廠家等特點(diǎn)，而且還需要投入昂貴的建設(shè)費(fèi)用。

基于GraphQL的醫(yī)院全聯(lián)接數(shù)據(jù)集成服務(wù)解決方案

為解決上述問題，可通過(guò)應(yīng)用創(chuàng)新的GraphQL技術(shù)，構(gòu)建醫(yī)院全聯(lián)接數(shù)據(jù)集成服務(wù)。

1.GraphQL的定義

GraphQL是Facebook開發(fā)的數(shù)據(jù)查詢語(yǔ)言，2015年開源，旨在提供微服務(wù)RESTful體系的更強(qiáng)大的代替方案，從而能在大數(shù)據(jù)領(lǐng)域進(jìn)一步推進(jìn)微服務(wù)數(shù)據(jù)中臺(tái)的技術(shù)應(yīng)用，助力大數(shù)據(jù)的快速開發(fā)。

GraphQL是一種API查詢語(yǔ)言，類似于數(shù)據(jù)庫(kù)中的SQL，或集成平臺(tái)提供的數(shù)據(jù)接口服務(wù)。相對(duì)而言，RESTful API依賴于后端隱式的、被動(dòng)的數(shù)據(jù)約定，GraphQL則在獲取數(shù)據(jù)和更新數(shù)據(jù)時(shí)更加主動(dòng)，所見即所得。

2.GraphQL的特點(diǎn)

一是所見即所得。查詢的返回結(jié)果就是輸入的查詢結(jié)構(gòu)的精確映射。

二是減少網(wǎng)絡(luò)請(qǐng)求次數(shù)。如果設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu)是從屬的，直接就能在查詢語(yǔ)句中指定；即使數(shù)據(jù)結(jié)構(gòu)是獨(dú)立的，也可以在查詢語(yǔ)句中指定上下文。只需要一次網(wǎng)絡(luò)請(qǐng)求，就能獲得資源和子資源的數(shù)據(jù)。

三是請(qǐng)求方在請(qǐng)求數(shù)據(jù)時(shí)不僅可以描述需要請(qǐng)求的數(shù)據(jù)，還可以對(duì)各個(gè)字段起別名，以適配預(yù)設(shè)的字段名稱。

3.GraphQL的應(yīng)用方法

GraphQL的自身特點(diǎn)決定了其適用于醫(yī)院的業(yè)務(wù)場(chǎng)景和信息化場(chǎng)景。

一是將GraphQL技術(shù)應(yīng)用到醫(yī)院數(shù)據(jù)接口服務(wù)中，發(fā)揮其優(yōu)勢(shì)。

發(fā)送一條GraphQL查詢，可以精準(zhǔn)捕獲第三方或前端期望得到的數(shù)據(jù)。GraphQL查詢不僅訪問一個(gè)資源的屬性，還可以平滑地跟蹤它們之前的引用。GraphQL API可以在一條單一請(qǐng)求中獲取到應(yīng)用所需的所有數(shù)據(jù)，而典型的RESTful需要從多個(gè)URL進(jìn)行加載。使用GraphQL的應(yīng)用，即便在速度較慢的網(wǎng)絡(luò)下也依然能夠很快獲取數(shù)據(jù)。由于GraphQL API是基于類型和字段組織的，而非終結(jié)點(diǎn)，具有通過(guò)單一節(jié)點(diǎn)獲取數(shù)據(jù)的完整能力，這就能解決醫(yī)院因接口服務(wù)運(yùn)行慢從而拖累HIS等業(yè)務(wù)系統(tǒng)的痛點(diǎn)問題。

二是將GraphQL技術(shù)和RESTful API融合。

通過(guò)使用傳統(tǒng)RESTful API請(qǐng)求方式，將GraphQL查詢語(yǔ)句當(dāng)作請(qǐng)求參數(shù)傳遞，利用服務(wù)器端又是客戶端的方式，避免了GraphQL客戶端因依賴node.js造成部分第三方無(wú)法調(diào)用的問題；同時(shí)，前端不用重復(fù)輸入大量不同的URL請(qǐng)求數(shù)據(jù)，通過(guò)單一公共URL路徑請(qǐng)求即可，能讓前端更專注于描述需要的數(shù)據(jù)。

針對(duì)擴(kuò)展性，單個(gè)RESTful接口的返回?cái)?shù)據(jù)越來(lái)越臃腫；針對(duì)某個(gè)前端展現(xiàn)，實(shí)際需要調(diào)用多個(gè)獨(dú)立的RESTful API，才能獲取足夠數(shù)據(jù)。對(duì)于Web前端而言，由于Ajax技術(shù)的存在，這種請(qǐng)求數(shù)據(jù)的方式并不會(huì)造成太大的問題；但對(duì)于應(yīng)用來(lái)說(shuō)，由于渲染的方式不同，必須拉取全部數(shù)據(jù)之后才能繪制界面，這就導(dǎo)致這個(gè)界面必須要拿到所有RESTful接口返回的數(shù)據(jù)才能進(jìn)行渲染繪制。

三是將數(shù)據(jù)結(jié)構(gòu)抽象為圖，構(gòu)建全新的醫(yī)療數(shù)據(jù)中臺(tái)。

在將HIS、LIS、PACS、EMR等異構(gòu)系統(tǒng)實(shí)現(xiàn)數(shù)據(jù)全聯(lián)接的同時(shí)，將整個(gè)數(shù)據(jù)結(jié)構(gòu)抽象為圖，可以將患者、科室、醫(yī)生等任意節(jié)點(diǎn)作為起始節(jié)點(diǎn)，獲取全關(guān)聯(lián)數(shù)據(jù)，使得醫(yī)療數(shù)據(jù)具有連續(xù)性，大大豐富了數(shù)據(jù)維度和廣度。此外，前端開發(fā)人員可以根據(jù)自己的需求，自行確定需要獲取數(shù)據(jù)的維度和深度。

已有實(shí)踐及取得效果

紅河州滇南中心醫(yī)院已基于GraphQL構(gòu)建了醫(yī)院數(shù)據(jù)中臺(tái)。2020年，紅河州滇南中心醫(yī)院基于微服務(wù)架構(gòu)，自主開發(fā)應(yīng)用的多學(xué)科聯(lián)合會(huì)診MDT系統(tǒng)獲得2020數(shù)字中國(guó)創(chuàng)新大賽智慧醫(yī)療賽道暨第四屆智慧醫(yī)療創(chuàng)新大賽“最具發(fā)展?jié)摿Κ?jiǎng)”、云南省智慧醫(yī)療創(chuàng)新大賽一等獎(jiǎng)。該系統(tǒng)的構(gòu)建基礎(chǔ)之一，正是GraphQL技術(shù)。

在實(shí)踐中，我們進(jìn)行了以下探索與嘗試。

首先，為了避免調(diào)用方不可用或修改調(diào)用方式成本較高等問題，我們對(duì)GraphQL和RESTful進(jìn)行整合，通過(guò)RESTful的調(diào)用方法實(shí)現(xiàn)GraphQL所見即所得、由調(diào)用方選擇所需數(shù)據(jù)的特性。

其次，我們通過(guò)GraphQL API和RESTful API融合構(gòu)建數(shù)據(jù)中臺(tái)，對(duì)醫(yī)院數(shù)據(jù)進(jìn)行全聯(lián)接與統(tǒng)一管理，向個(gè)人、醫(yī)院、政府機(jī)構(gòu)等不同服務(wù)對(duì)象提供不同維度的全聯(lián)接數(shù)據(jù)查詢服務(wù)。在這種數(shù)據(jù)服務(wù)新模式中，實(shí)現(xiàn)了所見即所得，且盡可能地減少了數(shù)據(jù)接口的請(qǐng)求次數(shù)。

第三，我們對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行圖化抽象，由任意節(jié)點(diǎn)遍歷整個(gè)圖結(jié)構(gòu)，實(shí)現(xiàn)數(shù)據(jù)的閉環(huán)全聯(lián)接。診療數(shù)據(jù)全聯(lián)接的范圍包括：門診就診信息，如診斷、處方、用藥、檢查、病歷等；住院診療信息，如診斷、醫(yī)囑、住院信息、患者檔案、病案、病程、護(hù)理記錄等；所有醫(yī)技科室的服務(wù)信息，如檢查項(xiàng)目、結(jié)果、危急值等；以及門診住院的歷次就診信息，內(nèi)容涵蓋了診療數(shù)據(jù)的全部?jī)?nèi)容。

例如：可通過(guò)調(diào)用某患者的基本信息，遍歷到該患者的歷次就診信息，遍歷到每次就診的科室，遍歷到該科室信息以及在該科室就診過(guò)的所有患者，同時(shí)遍歷到這些患者的基本信息。或者通過(guò)調(diào)用醫(yī)生信息，遍歷到該醫(yī)生所屬科室信息或該醫(yī)生所診治過(guò)的所有患者信息。總之，可以將任何節(jié)點(diǎn)作為起始節(jié)點(diǎn)，僅需通過(guò)一次調(diào)用，就可遍歷整個(gè)圖。

在診療數(shù)據(jù)中臺(tái)的基礎(chǔ)上，我們完成了CDR的構(gòu)建，實(shí)現(xiàn)了醫(yī)生電子交班、護(hù)理智慧交班、臨床大數(shù)據(jù)多學(xué)科聯(lián)合會(huì)診MDT系統(tǒng)、醫(yī)生移動(dòng)查房醫(yī)企微系統(tǒng)等多個(gè)臨床應(yīng)用的自主開發(fā)構(gòu)建。

我們的切身感受是：給我一個(gè)支點(diǎn)（GraphQL），我能翹起地球（大數(shù)據(jù)）。有了全聯(lián)接的診療數(shù)據(jù)，就能源源不斷地為臨床提供更多的數(shù)據(jù)服務(wù)。

總結(jié)和思考

一個(gè)“全聯(lián)接醫(yī)療”的時(shí)代正在到來(lái)。個(gè)人就醫(yī)將變得更加主動(dòng)，醫(yī)療信息系統(tǒng)將轉(zhuǎn)變?yōu)椤耙曰颊邽橹行摹保颊摺⑨t(yī)護(hù)、醫(yī)院之間將發(fā)生越來(lái)越緊密的聯(lián)接，新醫(yī)療也將顛覆傳統(tǒng)就醫(yī)模式。

為了跟上時(shí)代步伐，有效緩解看病難、醫(yī)療資源不均衡等突出問題，我們必須對(duì)醫(yī)療體系進(jìn)行數(shù)字化重構(gòu)，應(yīng)對(duì)移動(dòng)醫(yī)療、遠(yuǎn)程醫(yī)療等帶來(lái)的新挑戰(zhàn)。通過(guò)對(duì)RESTful API、XML WebService等技術(shù)進(jìn)行更替，無(wú)論是在接口復(fù)用，還是在數(shù)據(jù)傳輸效率、數(shù)據(jù)集成全聯(lián)接等方面，GraphQL API方式都具有極大的技術(shù)優(yōu)勢(shì)，數(shù)據(jù)結(jié)構(gòu)圖化更使得醫(yī)療數(shù)據(jù)具有連續(xù)性和復(fù)用性，能為個(gè)人、醫(yī)院、政府機(jī)構(gòu)等不同服務(wù)對(duì)象提供不同維度的全聯(lián)接數(shù)據(jù)查詢服務(wù)。

從應(yīng)用層面分析，目前國(guó)內(nèi)醫(yī)療機(jī)構(gòu)還鮮見基于GraphQL技術(shù)的數(shù)據(jù)開發(fā)。但在互聯(lián)網(wǎng)創(chuàng)新企業(yè)，因GraphQL敏捷、快速、低成本的大數(shù)據(jù)開發(fā)服務(wù)能力，已經(jīng)得到了大批量的開發(fā)部署應(yīng)用。

從開發(fā)技術(shù)角度分析，由于GraphQL將數(shù)據(jù)關(guān)系視為圖，所以在抽象數(shù)據(jù)時(shí)有一定難度，而且醫(yī)院信息系統(tǒng)采用的數(shù)據(jù)庫(kù)管理系統(tǒng)版本也各不相同，實(shí)現(xiàn)數(shù)據(jù)全聯(lián)接的復(fù)雜程度相對(duì)較高。如果想要實(shí)現(xiàn)根據(jù)任意字段條件查詢的接口，難度較高、工作量不小。不過(guò)，從紅河州滇南中心醫(yī)院的開發(fā)應(yīng)用情況來(lái)看，該技術(shù)在醫(yī)療機(jī)構(gòu)具有極佳的應(yīng)用前景，不但能解決醫(yī)療數(shù)據(jù)的集成問題，還能解決臨床實(shí)際工作缺乏數(shù)據(jù)服務(wù)的痛點(diǎn)問題。和其他市面大數(shù)據(jù)產(chǎn)品相比較，基于GraphQL技術(shù)提供的醫(yī)療數(shù)據(jù)展示功能在全面性、實(shí)時(shí)性和流暢度等方面也具有較大優(yōu)勢(shì)。

來(lái)源：HIT180