季文飛 蔣同海 王 蒙 唐新余 陳 光

1(中國科學(xué)院新疆理化技術(shù)研究所 新疆 烏魯木齊 830011)2(中國科學(xué)院大學(xué) 北京 100049)3(中國科學(xué)院新疆民族語音語言信息處理重點(diǎn)實(shí)驗(yàn)室 新疆 烏魯木齊 830011)4(江蘇中科西北星信息科技有限公司 江蘇 無錫 214135)

0 引 言

醫(yī)養(yǎng)融合是國務(wù)院《關(guān)于加快發(fā)展養(yǎng)老服務(wù)的若干意見》中提出的創(chuàng)新養(yǎng)老服務(wù)模式，指將養(yǎng)老服務(wù)同醫(yī)療資源相結(jié)合，從而更好地服務(wù)老年人群[1]。醫(yī)養(yǎng)融合首先是數(shù)據(jù)融合，即打通醫(yī)療、養(yǎng)老信息系統(tǒng)的數(shù)據(jù)壁壘，統(tǒng)一相關(guān)系統(tǒng)業(yè)務(wù)和數(shù)據(jù)模型，共享相關(guān)系統(tǒng)數(shù)據(jù)。數(shù)據(jù)融合技術(shù)能夠?qū)Ａ繑?shù)據(jù)進(jìn)行融合處理，提高“數(shù)據(jù)質(zhì)量”[2]，減少數(shù)據(jù)中的錯(cuò)誤，為后續(xù)數(shù)據(jù)處理分析提供可靠的數(shù)據(jù)支持[3]。通過融合，一方面可以整合各自系統(tǒng)的就醫(yī)、用藥、養(yǎng)老等老年人生活數(shù)據(jù)[4]，讓老年人享受更加便捷的老年生活服務(wù)，另一方面可以提高政府對老齡問題的洞察能力，提高決策科學(xué)水平[5]。我國現(xiàn)有的醫(yī)療、養(yǎng)老系統(tǒng)數(shù)據(jù)模型復(fù)雜，重復(fù)較高，無法共享相關(guān)的老人就醫(yī)和養(yǎng)老數(shù)據(jù)，存在嚴(yán)重的“信息孤島”問題[6]。傳統(tǒng)的醫(yī)養(yǎng)融合系統(tǒng)一般采用硬編碼技術(shù)實(shí)現(xiàn)，根據(jù)具體項(xiàng)目制定數(shù)據(jù)模型、清洗融合模型、可視化和訪問模型，在靈活性、可擴(kuò)展性方面表現(xiàn)較差。

本文針對醫(yī)養(yǎng)數(shù)據(jù)融合中相關(guān)問題進(jìn)行研究，提出使用語義元數(shù)據(jù)模型解決醫(yī)養(yǎng)數(shù)據(jù)融合中的統(tǒng)一建模問題、清洗和融合問題、可視化和訪問問題，并實(shí)現(xiàn)了相應(yīng)的數(shù)據(jù)融合系統(tǒng)。該系統(tǒng)支持動(dòng)態(tài)數(shù)據(jù)建模、支持融合規(guī)則建模和可視化模型建模，具有較好的靈活性和可擴(kuò)展性，能滿足區(qū)域內(nèi)養(yǎng)老、醫(yī)療數(shù)據(jù)融合處理響應(yīng)時(shí)間的要求。

1 相關(guān)工作及面臨的問題

醫(yī)養(yǎng)融合需要匯聚來自各種醫(yī)療系統(tǒng)、養(yǎng)老系統(tǒng)的數(shù)據(jù)，需要支持物聯(lián)網(wǎng)設(shè)備、長護(hù)險(xiǎn)結(jié)算系統(tǒng)及其他第三方數(shù)據(jù)產(chǎn)生端的系統(tǒng)接入，同時(shí)需對匯聚的數(shù)據(jù)進(jìn)行清洗和融合，并提供數(shù)據(jù)可視化和訪問服務(wù)。

文獻(xiàn)[7]介紹了利用FHIR進(jìn)行醫(yī)療信息集成，通過構(gòu)建一個(gè)RESTFUL協(xié)議訪問的應(yīng)用系統(tǒng)，利用基于XML的HL7協(xié)議對醫(yī)療信息進(jìn)行建模，實(shí)現(xiàn)不同醫(yī)療系統(tǒng)之間的數(shù)據(jù)集成和共享。

文獻(xiàn)[8]介紹了基于本體理論進(jìn)行醫(yī)學(xué)數(shù)據(jù)建模及其應(yīng)用，首先利用本體進(jìn)行醫(yī)療建模，然后利用算法進(jìn)行數(shù)據(jù)檢測和本體識(shí)別。文獻(xiàn)[9]則在本體建模形成的醫(yī)療數(shù)據(jù)模型基礎(chǔ)上進(jìn)行了醫(yī)療知識(shí)抽取和可視化工作。

文獻(xiàn)[10]介紹了基于字符串模式匹配的數(shù)據(jù)交互集成方法，即利用人工干預(yù)進(jìn)行多次迭代的方式生成全局統(tǒng)一的中介模式，并介紹了其在二手房數(shù)據(jù)集成上的應(yīng)用。

文獻(xiàn)[11]介紹了使用新技術(shù)框架如Apache Hadoop、Apache Storm進(jìn)行醫(yī)療、護(hù)理數(shù)據(jù)集成和計(jì)算，并建立了一個(gè)能夠支持實(shí)時(shí)進(jìn)行醫(yī)療、護(hù)理數(shù)據(jù)計(jì)算的系統(tǒng)。

上述的研究一般以項(xiàng)目的形式，由編程人員在某一些醫(yī)療、養(yǎng)老系統(tǒng)之間，利用XML或者本體建模技術(shù)，進(jìn)行少量的數(shù)據(jù)清洗和融合，限于較低的靈活性和擴(kuò)展性，未能進(jìn)行大范圍推廣和使用，其主要原因是當(dāng)前醫(yī)養(yǎng)數(shù)據(jù)融合面臨以下問題：

(1) 統(tǒng)一數(shù)據(jù)建模問題[12]。醫(yī)、養(yǎng)相關(guān)的系統(tǒng)紛繁復(fù)雜，每個(gè)系統(tǒng)對醫(yī)療、養(yǎng)老業(yè)務(wù)的抽象能力參差不齊，導(dǎo)致所建的數(shù)據(jù)和業(yè)務(wù)模型不盡相同，需要對業(yè)務(wù)和數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化和統(tǒng)一化建模，抽取出全局標(biāo)準(zhǔn)模型；另外這些系統(tǒng)在建模時(shí)使用的工具各不相同，需要提供統(tǒng)一的數(shù)據(jù)建模描述工具并支持動(dòng)態(tài)建模。

(2) 清洗和融合問題[13]。不同來源的醫(yī)療、養(yǎng)老數(shù)據(jù)產(chǎn)生和采集方式不同存在數(shù)據(jù)缺失、異常、冗余等問題，為后續(xù)的處理帶來很大困難，需要對數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗和融合處理。不同的數(shù)據(jù)一般采用不同的清洗和融合策略，且需要?jiǎng)討B(tài)修改，因此需要對清洗和融合進(jìn)行建模，并提供相應(yīng)的過程描述工具。

(3) 可視化和數(shù)據(jù)訪問問題[14]。不同的醫(yī)療、養(yǎng)老業(yè)務(wù)場景對數(shù)據(jù)的訪問和可視化能力具有不同的要求，需要提供對數(shù)據(jù)不同粒度的查詢訪問和可視化訪問建模和描述工具。

2 基于語義元數(shù)據(jù)的醫(yī)養(yǎng)融合研究

語義元數(shù)據(jù)作為資源描述框架表現(xiàn)形式，具有結(jié)構(gòu)緊湊、表達(dá)直觀、語義豐富等特點(diǎn)，在數(shù)據(jù)集成、知識(shí)抽取得到大量研究和應(yīng)用[15]。語義元數(shù)據(jù)具有不同表示方法，例如元組、XML_DTD[16]、RDFa[17]、JSON-LD[18]等方法。由于元組具有較好的可讀性、緊湊性，是最直觀的方法之一，能夠靈活地對數(shù)據(jù)進(jìn)行建模和表述，支持?jǐn)?shù)據(jù)模型的擴(kuò)展，因此本文使用五元組表示的語義元數(shù)據(jù)，對上述醫(yī)養(yǎng)數(shù)據(jù)融合的問題進(jìn)行研究，并設(shè)計(jì)出靈活性好并可擴(kuò)展的數(shù)據(jù)融合系統(tǒng)。

語義元數(shù)據(jù)用一個(gè)五元組進(jìn)行表示,其中：x是元數(shù)據(jù)的名稱；A是模型的屬性集合；K是關(guān)鍵標(biāo)識(shí)集合，且K?A；Q是用于查詢的字段集合，且Q?A，K?Q;f是映射函數(shù)f:(a)→(x′,a′)的集合。例如，老人血糖模型，其中：A=[idCard,testTime,sugarValue,nurseId,testType,checkId]依次為老人身份證號(hào)、測試時(shí)間、血糖值、測試人員編號(hào)、測試類型、測試編號(hào)；K=[idCard,testTime,testType]，即根據(jù)老人身份證號(hào)，測試時(shí)間和測試類型能夠唯一確定某個(gè)老人的血糖數(shù)據(jù)；Q=[idCard,testTime,testType,nurseId]，表示這些屬性在構(gòu)成實(shí)例時(shí)不可或缺，在查詢時(shí)能夠找到相應(yīng)的數(shù)據(jù)，老人血糖模型中的nurseId將會(huì)映射關(guān)聯(lián)到測試人員模型中，映射關(guān)系為f:(nurseId)→(x′,nurseId),表示兩個(gè)模型通過nurseId進(jìn)行關(guān)聯(lián)。

2.1 語義元數(shù)據(jù)與統(tǒng)一數(shù)據(jù)建模

當(dāng)前的醫(yī)療、養(yǎng)老系統(tǒng)具有不同的數(shù)據(jù)模型定義，需要事先使用語義元數(shù)據(jù)進(jìn)行統(tǒng)一的數(shù)據(jù)建模，原有系統(tǒng)的數(shù)據(jù)模型也使用語義元數(shù)據(jù)進(jìn)行描述，并把原有的數(shù)據(jù)模型與統(tǒng)一的模型在語義層面進(jìn)行關(guān)聯(lián)。例如針對老人基礎(chǔ)模型，f的一個(gè)函數(shù)可以是原系統(tǒng)老人基礎(chǔ)模型的“姓名”屬性映射轉(zhuǎn)換到統(tǒng)一模型的“name”屬性。

考慮到當(dāng)前大部分醫(yī)療、養(yǎng)老系統(tǒng)基于關(guān)系型數(shù)據(jù)進(jìn)行建模和存儲(chǔ)，需要找到原數(shù)據(jù)與模型之間的關(guān)系，如算法1所示。

算法1 數(shù)據(jù)模型適配算法

輸入：cur_rules:語義元數(shù)據(jù)規(guī)則集合

data:需要匹配的數(shù)據(jù)

輸出：adapt_rules:適合此數(shù)據(jù)的語義元數(shù)據(jù)規(guī)則集合

for rule in cur_rules

data_keys=data.keys()

needed_keys=rule.Q

if data_keys.length

Continue

check_rule_flag=true

for key in needed_keys

if data_keys.index(key)<0

check_rule_flag=false

break

if check_rule_flag==true

adaptive_rules.add(rule)

該算法不僅能夠給數(shù)據(jù)找到適合的模型，而且能夠把數(shù)據(jù)按照模型進(jìn)行劃分，這在實(shí)際工程實(shí)踐中具有重要意義。因?yàn)閭鹘y(tǒng)的應(yīng)用系統(tǒng)一般以關(guān)系型的形式存儲(chǔ)相關(guān)數(shù)據(jù)，具有完善的模型之間關(guān)系，該算法能夠捕捉這種模型之間的關(guān)系并把數(shù)據(jù)任意組合到相關(guān)模型中，如針對老人的詳細(xì)信息，通過算法可以切分為老人基本信息、健康信息、生活信息，這非常便于存儲(chǔ)和檢索。

2.2 語義元數(shù)據(jù)與數(shù)據(jù)清洗和融合

數(shù)據(jù)清洗和融合的主要步驟包含：模式對齊、實(shí)體識(shí)別、沖突消解及數(shù)據(jù)追蹤。利用語義元數(shù)據(jù)對清洗和融合規(guī)則進(jìn)行定義，并通過執(zhí)行該規(guī)則達(dá)到清洗和融合的目的。

針對清洗和融合規(guī)則，使用五元組定義，x=“cleanandfusion”，A=[id,name,description,condition,operation,from_model,to_model,connect_model,script,type],K=[id],Q=[id,name,condition,operation,type,script],f=[],其中：id是規(guī)則編號(hào)，具有唯一性；name是該處理規(guī)則的名稱；description是該規(guī)則的描述信息；condition是該規(guī)則的執(zhí)行條件；operation是該規(guī)則對應(yīng)的操作，如：模式對齊、實(shí)體識(shí)別、沖突消解和數(shù)據(jù)追蹤；from_model是指該規(guī)則對應(yīng)來源數(shù)據(jù)的模型；to_model是處理完成后返回的數(shù)據(jù)的模型；connect_model是處理時(shí)所需要的額外的數(shù)據(jù)模型；script中定義了怎么進(jìn)行處理相關(guān)操作的腳本；type是該腳本的類型，目前可支持JavaScript腳本。

往往一個(gè)數(shù)據(jù)完成清洗和融合操作，需要經(jīng)過多次清洗和融合規(guī)則處理，需要保證不同規(guī)則之間處理順序，借助語義元數(shù)據(jù)可以實(shí)現(xiàn)不同規(guī)則之間的鏈?zhǔn)教幚?，即在五元組f中指定下一步清洗和融合的規(guī)則id。如果滿足規(guī)則中condition的條件則執(zhí)行編號(hào)為id的規(guī)則，不斷重復(fù)上述步驟便可實(shí)現(xiàn)鏈?zhǔn)綀?zhí)行。例如，如圖1所示，從物聯(lián)網(wǎng)設(shè)備中采集的缺省身份證號(hào)碼的血壓數(shù)據(jù)，在script1中通過與connect_model指定的老人基本信息模型關(guān)聯(lián)操作，并把補(bǔ)充了身份證號(hào)信息的血壓數(shù)據(jù)輸出到to_model指定的統(tǒng)一血壓數(shù)據(jù)模型中；同理執(zhí)行script2便可以把統(tǒng)一血壓模型的數(shù)據(jù)更新到老人最新健康數(shù)據(jù)模型中。

圖1 缺省身份證號(hào)的血壓數(shù)據(jù)處理過程

2.3 語義元數(shù)據(jù)與數(shù)據(jù)可視化和訪問

數(shù)據(jù)可視化和數(shù)據(jù)訪問需要對數(shù)據(jù)進(jìn)行查詢，并把結(jié)果以可視化或者接口的形式呈現(xiàn)出來。使用語義元數(shù)據(jù)，對數(shù)據(jù)可視化和數(shù)據(jù)訪問過程進(jìn)行建模。

數(shù)據(jù)可視化定義為五元組,A=[dataSource,chartTitle,chartSeries,querySql,chartId],K=[chartId],Q=[chartId]，f函數(shù)集在這里表示A中屬性的類型，其中,dataSource、chartTitle、chartSeries、querySql、chartId分別表示數(shù)據(jù)來源、圖表標(biāo)題、圖表系列、查詢語句、圖表編號(hào)。以血糖來源占比情況的餅圖為例，A中的類型依次為SugarType(血糖的統(tǒng)一模型名稱)、字符串、表格圖例類型(此處是對血糖類型的標(biāo)注)、字符串、字符串。querySql是指針對dataSource數(shù)據(jù)進(jìn)行查詢的sql語句，在此例中執(zhí)行querySql=“SELECT COUNT(*) from SugarType GROUP BY testType”，即可查詢出需要展示的數(shù)據(jù)。然后把查詢的數(shù)據(jù)與chartSeries數(shù)據(jù)進(jìn)行合并，并通過前端技術(shù)展示出來。

數(shù)據(jù)訪問定義為五元組,A=[queryId,dataSource,query_param,query_type,result_model,querySql],K=[queryId],Q=[queryId]，f函數(shù)集在這里表示查詢結(jié)果與請求接收數(shù)據(jù)的模型的映射。A集合中含義依次為：查詢編號(hào)，查詢源，查詢參數(shù)，查詢類型，查詢結(jié)果模型，查詢語句。當(dāng)執(zhí)行查詢請求時(shí)，首先解析出查詢需要的參數(shù)query_param并注入到querySql中，到dataSource指定的源中執(zhí)行查詢，并通過f函數(shù)把結(jié)果轉(zhuǎn)換為第三方系統(tǒng)支持的result_model模型并返回。

3 系統(tǒng)實(shí)現(xiàn)和驗(yàn)證

3.1 系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

本文系統(tǒng)根據(jù)實(shí)際項(xiàng)目情況，選用SpringCloud作為基礎(chǔ)框架進(jìn)行開發(fā)，使用kafka作為消息通信隊(duì)列，使用redis進(jìn)行緩存，使用mongdb存儲(chǔ)語義元數(shù)據(jù)，使用mysql存儲(chǔ)用戶數(shù)據(jù)，使用vue2.0和echarts.js、d3.js作為前端框架。在部署和測試時(shí)采用10臺(tái)阿里ECS云服務(wù)器[19]，其配置全部為4核CPU、16 GB內(nèi)存、200 GB普通硬盤。

本文系統(tǒng)的架構(gòu)如圖2所示，共分為三層：接入層，清洗融合層，應(yīng)用層，各層之間通過消息隊(duì)列進(jìn)行通信。接入層主要負(fù)責(zé)各系統(tǒng)的數(shù)據(jù)接入、數(shù)據(jù)與語義元數(shù)據(jù)模型之間的轉(zhuǎn)化。清洗和融合層主要用來根據(jù)用戶設(shè)定的語義元數(shù)據(jù)模型對數(shù)據(jù)進(jìn)清洗、融合和數(shù)據(jù)存儲(chǔ)。清洗和融合模型中的script是在腳本引擎中進(jìn)行執(zhí)行。應(yīng)用層主要提供數(shù)據(jù)可視化和數(shù)據(jù)訪問服務(wù)，以及提供界面供用戶設(shè)計(jì)基于語義元數(shù)據(jù)的數(shù)據(jù)模型、清洗融合策略、可視化和訪問方式。

圖2 醫(yī)養(yǎng)數(shù)據(jù)融合系統(tǒng)架構(gòu)

在數(shù)據(jù)進(jìn)行清洗和融合時(shí)，為提高系統(tǒng)的靈活性和擴(kuò)展性，使用腳本引擎鏈?zhǔn)綀?zhí)行相關(guān)的腳本。Nashorn是Java語言中最新的腳本引擎，用于取代Rhino，相比于后者具有較好的執(zhí)行效率[20]。本文使用Nashorn作為清洗融合腳本的執(zhí)行器，同時(shí)又在此基礎(chǔ)上封裝了相關(guān)的數(shù)據(jù)清洗、融合、存儲(chǔ)等方面的API，用于簡化清洗融合的開發(fā)，其架構(gòu)如圖3所示，主要包含三層：引擎層、擴(kuò)展層和腳本層。引擎層主要包含能夠執(zhí)行Javascript腳本的Nashorn引擎。擴(kuò)展層主要是把存儲(chǔ)、模型轉(zhuǎn)化、清洗、融合和過程控制等功能封裝成相應(yīng)的語義元數(shù)據(jù)模型，并提供腳本API，供上層的腳本層調(diào)用。腳本層主要是使用者編寫的腳本，用以進(jìn)行數(shù)據(jù)清洗和融合以及過程的控制，其編寫的腳本對應(yīng)清洗融合模型中的script。使用者編寫的腳本可以使用擴(kuò)展層提供的API，進(jìn)行數(shù)據(jù)關(guān)聯(lián)、數(shù)據(jù)模型之間的轉(zhuǎn)化、數(shù)據(jù)處理和過程控制操作。為了提高模型轉(zhuǎn)換效率，對相關(guān)模型轉(zhuǎn)換的結(jié)果進(jìn)行緩存，已經(jīng)緩存的模型在執(zhí)行時(shí)無需再次轉(zhuǎn)換。

圖3 清洗融合引擎架構(gòu)

3.2 應(yīng)用案例

本系統(tǒng)能夠滿足醫(yī)養(yǎng)數(shù)據(jù)融合的需求，在全國多個(gè)區(qū)域進(jìn)行了試用，已經(jīng)接入各類系統(tǒng)二十余個(gè)，能夠靈活地對醫(yī)養(yǎng)數(shù)進(jìn)行建模，涵蓋了老人、養(yǎng)老機(jī)構(gòu)、醫(yī)療等多種類型的數(shù)據(jù)，為政府機(jī)構(gòu)提供了實(shí)時(shí)的數(shù)據(jù)可視化和查詢服務(wù)。

圖4為對老人睡眠數(shù)據(jù)進(jìn)行建模的界面，說明該系統(tǒng)能夠動(dòng)態(tài)對數(shù)據(jù)模型進(jìn)行擴(kuò)展。圖中屬性名對應(yīng)語義元數(shù)據(jù)中的A集合，Q集合元素對應(yīng)在是否必須列打勾的，K集合元素對應(yīng)是否為主鍵列打勾的，其余的備注、類型、最大最小值、默認(rèn)值則設(shè)定到f中。

圖4 老人睡眠數(shù)據(jù)模型

圖5展示的是缺省老人身份證號(hào)的老人血壓模型的清洗和融合的腳本。圖中首先到connect_model中查找身份證號(hào)碼，然后形成帶有身份證號(hào)的血壓數(shù)據(jù)并返回。

圖5 補(bǔ)充身份證編號(hào)的融合腳本

圖6是統(tǒng)計(jì)某市養(yǎng)老機(jī)構(gòu)性質(zhì)占比圖，只需配置數(shù)據(jù)的來源。圖中對可視化模型的來源、類型、圖例等進(jìn)行了配置，配置完成后即可查看到相關(guān)的可視化界面，如圖7所示。

圖6 機(jī)構(gòu)性質(zhì)占比可視化模型

圖7 機(jī)構(gòu)性質(zhì)占比

3.3 綜合性能對比

首先對比了本文設(shè)計(jì)的系統(tǒng)與傳統(tǒng)硬編碼系統(tǒng)(HardCode)在功能上的區(qū)別，傳統(tǒng)的硬編碼系統(tǒng)由研發(fā)人員根據(jù)項(xiàng)目需要，參照文獻(xiàn)[11]，基于Hadoop和Storm進(jìn)行編碼實(shí)現(xiàn)。如表1所示，本文系統(tǒng)支持融合規(guī)則的動(dòng)態(tài)修改、數(shù)據(jù)清理規(guī)則的動(dòng)態(tài)修改、動(dòng)態(tài)修改數(shù)據(jù)可視化等功能，但傳統(tǒng)硬編碼系統(tǒng)不支持。

表1 功能對比

另外，為了滿足系統(tǒng)在數(shù)據(jù)接入、清洗和融合以及數(shù)據(jù)訪問在數(shù)據(jù)接入量較大時(shí)的實(shí)時(shí)性，需要保證系統(tǒng)在處理大數(shù)據(jù)量時(shí)具有較小的響應(yīng)時(shí)間。因此對系統(tǒng)不同數(shù)據(jù)量下的響應(yīng)時(shí)間進(jìn)行了實(shí)驗(yàn)，結(jié)果如圖8所示。

圖8 不同數(shù)據(jù)量響應(yīng)處理時(shí)間統(tǒng)計(jì)

本次測試的數(shù)據(jù)來自江蘇某市2018年1月到2018年6月間的老人健康數(shù)據(jù)、生活數(shù)據(jù)、護(hù)理記錄數(shù)據(jù)共8.34 GB。數(shù)據(jù)采集方式有三種：第一種通過可穿戴設(shè)備直接采集錄入；第二種是第三方醫(yī)療、養(yǎng)老系統(tǒng)通過對接進(jìn)行數(shù)據(jù)收集；第三種是護(hù)士、醫(yī)生、護(hù)工等手工錄入。

本次實(shí)驗(yàn)使用了開源的Apache JMeter測試工具編寫測試腳本進(jìn)行響應(yīng)時(shí)間的測試。分別隨機(jī)選取真實(shí)的老人健康數(shù)據(jù)500條、1 000條、1 500條、2 000條測試信息處理響應(yīng)時(shí)間(單位為s)。由圖8可知，隨著數(shù)據(jù)量的增加，數(shù)據(jù)處理響應(yīng)時(shí)間緩慢增加，在處理2 000條數(shù)據(jù)的數(shù)據(jù)量時(shí)響應(yīng)時(shí)間未超過2 s。本文設(shè)計(jì)的系統(tǒng)響應(yīng)時(shí)間在處理較少數(shù)據(jù)量時(shí)響應(yīng)時(shí)間高于硬編碼系統(tǒng)的響應(yīng)時(shí)間，因?yàn)樾枰M(jìn)行語義元數(shù)據(jù)模型轉(zhuǎn)換，而在數(shù)據(jù)量較多時(shí)，響應(yīng)時(shí)間接近甚至少于硬編碼系統(tǒng)的響應(yīng)時(shí)間，當(dāng)數(shù)據(jù)量較多時(shí)，本文平臺(tái)可以發(fā)揮緩存模型的優(yōu)勢。綜合來看，本文設(shè)計(jì)的系統(tǒng)能夠滿足平臺(tái)在區(qū)域內(nèi)數(shù)據(jù)融合響應(yīng)時(shí)要求。

4 結(jié) 語

本文通過對醫(yī)養(yǎng)數(shù)據(jù)融合中面臨的問題進(jìn)行分析，基于語義元數(shù)據(jù)對數(shù)據(jù)建模、清洗和融合、數(shù)據(jù)訪問和可視化進(jìn)行研究，形成靈活性好、可擴(kuò)展的醫(yī)養(yǎng)數(shù)據(jù)融合系統(tǒng)，并通過相關(guān)實(shí)驗(yàn)驗(yàn)證了該系統(tǒng)能夠滿足醫(yī)養(yǎng)數(shù)據(jù)融合中對大數(shù)據(jù)量響應(yīng)時(shí)間的要求。本文順應(yīng)醫(yī)療、養(yǎng)老數(shù)據(jù)不斷融合的大趨勢，為醫(yī)療、養(yǎng)老機(jī)構(gòu)更好地服務(wù)老人提供技術(shù)層面支撐，同時(shí)為涉老醫(yī)療監(jiān)管，民政養(yǎng)老監(jiān)管提供數(shù)據(jù)支持。隨著大數(shù)據(jù)分析技術(shù)的發(fā)展，同時(shí)考慮到監(jiān)管機(jī)構(gòu)對數(shù)據(jù)分析決策的需求，下一步將在清洗融合數(shù)據(jù)的基礎(chǔ)上，重點(diǎn)研究基于醫(yī)養(yǎng)融合的數(shù)據(jù)分析技術(shù)，并與本文系統(tǒng)進(jìn)行結(jié)合，進(jìn)一步提高支撐監(jiān)管機(jī)構(gòu)決策的智能化的水平。