跳轉到主要內容
工程的博客

燃燒通過電子健康記錄實時悶燒

瑞安DeCosmo
弗蘭克·奧斯汀諾莎福特
通過瑞安DeCosmo和弗蘭克·奧斯汀諾莎福特

2021年1月28日, 在工程的博客

分享這篇文章

檢查解決方案加速器下載筆記本在這個博客。

在以前的博客,我們看兩個單獨的工作流處理病人數據的電子健康記錄(EHR)。在這些流程中,我們專注於一個曆史批電子健康檔案數據的提取。然而,在現實世界中,數據不斷輸入成電子健康檔案。對許多重要的預測醫療分析用例,膿毒症的預測或ER過度擁擠,我們需要使用流經EHR的臨床資料。

數據實際上流經一個EHR如何?一般來說,有幾個通過細化。在一些EHR實現,數據首先土地以接近實時的方式到NoSQL風格經營商店。一天後,新數據在這個NoSQL存儲從操作存儲到規範化和SQL存儲空間。其他EHR的實現有不同的數據庫實現,但是,通常有一個延遲之前最後一個“曆史”EHR的記錄數據可用於批量分析。在實時分析臨床資料,我們需要訪問了基於推的HL7消息源或基於FHIR API端點。這些提要和端點包含各種健康信息的數據。例如,承認/放電/轉移(ADT)消息可以用來跟蹤當病人之間或移動單位,而訂單輸入(ORM)消息/修改/取消訂單,如給病人氧或運行一個特定的實驗室測試。通過提要和資源結合在一起,我們可以得到一個全麵的查看我們的病人和醫院。

醫療團隊和臨床醫師麵臨的問題在構建實時分析係統的電子健康檔案數據:我應該使用FHIR或HL7嗎?我該如何解析記錄?我該如何存儲和合並數據?在這個博客中,我們引入悶燒,操縱電子健康檔案數據使用Apache的開源庫引發™。悶燒提供Spark-native數據加載器和api將HL7消息轉換為SQL DataFrames Apache火花™。為了簡化操作、驗證和重新映射的內容信息,悶燒添加SQL函數來訪問消息字段。最終,這使得它可以構建流媒體管道來攝取和分析HL7數據在幾分鍾內,同時提供一個易於使用的聲明性語法,就不需要學習底層庫像哈皮神。這些管道可以實現近實時延遲,同時實現數據統一在醫療數據來源通過利用開源標準三角洲湖

流程圖顯示數據流到三角洲湖,然後到儀表板

在這個博客的其餘部分,我們將使用悶燒庫EHR近實時的數據分析來確定患者保健利用率高。首先,我們將做一個深潛水的HL7v2標準它是如何工作的,它意味著什麼。然後,我們將討論悶燒的設計原則指導我們的發展。最後,我們將展示如何將數據加載到三角洲湖在實時通過使用Apache火花的結構化流api,和悶燒圖書館。我們將使用這些數據來驅動一個儀表板,幫助我們識別實時我們高端應用的病人在醫院係統的地方。

使用HL7消息

HL7v2
HL7代表Health Level 7國際標準組織,定義了醫療的互操作性標準。他們維護多個著名的標準,如新興FHIR醫療數據交換標準定義REST api和JSON模式交換醫療數據,基於xml的(合並)臨床文檔體係結構(CDA和C-CDA)標準,原HL7v2標準。這些標準有不同的目的:FHIR定義了用於應用程序開發的API端點,C-CDA定義標準,是最好的用於交換曆史有關病人的信息,和HL7v2消息方言,捕獲實時更新狀態和數據,存在於一個電子健康檔案。雖然有很多最近的興趣FHIR對於應用程序開發,HL7v2通常是最合適的標準用於分析由於其廣泛采用。目前大多數機構遺留係統利用HL7提要。因此,更容易進入更大的數據量,創造更豐富的基礎分析,無需等待每個係統支持FHIR。同時,HL7提要本身通常是基於TCP / IP的數據流,而網格基於事件流體係結構非常幹淨。

MSH | ^ ~ \ & | | | | | 20201020150800.739 + 0000 | | ADT ^ A03 ^ ADT_A03 | 11374301 | P | 2.4犯| A03 | 20170820074419 - 0500PID | | | d40726da-9b7a-49eb-9eeb-e406708bbb60 | |海勒^ Keneth | | | | | | 140 Pacocha套件52 ^ ^馬薩諸塞州北安普頓^ ^ ^厄爾pv | |的| ^ ^ ^迪金森醫院公司動態| | | | | 49318 f80-bd8b-3fc7-a096-ac43088b0c12厄爾的^ ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 20170820074419 - 05 \00

代碼:這是一個HL7消息。這個消息是一個ADT_A03消息,它提供了信息病人出院了。我們生成此消息使用開源Synthea醫療記錄模擬器。

HL7v2以來我們已經談妥,讓我們先看一個HL7v2消息的內容。上圖顯示了單個HL7v2消息,多行,管分隔。還有一個規範的XML版本。FHIR模式是一種基於json規範。對於每個消息類型和部分指定的類型是HL7v2規範。消息一段的每一行,第一列是“段描述符,它告訴我們什麼是模式的部分。當我們解析ADT_A03消息上麵,我們有兩個部分;“PID”段標識符包含病人的身份信息和“發現”部分包含有關病人的信息訪問他們退出。在病人的身份,第二個字段的ID是病人,第四個字段名稱,等等。

所以,你如何使用這些數據?我們幫助多個客戶攝取HL7數據轉換成磚使用Apabeplay体育app下载地址che的火花的流媒體功能。從曆史上看,我們看到客戶之間建立一個渠道EHR和流媒體beplay体育app下载地址服務Apache卡夫卡™️、運動或EventHubs。然後他們連接其中一個流公交車到Apache火花,收益率DataFrame的消息文本。最後,他們解析本文使用手寫的解析器或低級庫哈皮神。

雖然這種方法對一些客戶,需要手工編寫解析庫,或者依靠圖書館像哈皮神這樣的開銷,會beplay体育app下载地址造成挑戰。湖的數據的一個關鍵好處是能夠延遲驗證管道。我們通常談論這是銅層,這是攝取的數據並存儲在它的原始狀態。這使您可以靈活地保持觀察到的曆史數據,而無需做任何選擇數據的大小和形狀。

這是特別有用,當你要做之前曆史驗證和分析麵向業務用例。例如,考慮的情況下驗證初級保健提供者(PCP)領域。如果你發現一個醫療係統交換的卡式肺囊蟲肺炎不同醫生對護理團隊,你會想要在所有這些記錄追溯糾正這個錯誤。悶燒的設計、訂閱這個範式。

不像哈皮神,悶燒將消息分為結構沒有嚐試驗證之外是一個有效的HL7消息。這使我們能夠獲取觀測數據,同時還使它可以查詢和填充我們的銀層。

設計悶燒,使用HL7在Apache的開源庫火花

我們開始開發悶燒提供一個易於使用的係統,可以實現近實時延遲處理HL7v2消息很大的生態係統,使這些數據可訪問數據科學可視化的工具。為此,我們采用了以下的方法:

  • HL7消息變成DataFrames一行代碼:DataFrames廣泛應用在數據科學無論是通過熊貓,R,或火花,可以通過使用易於被像SQL聲明性編程框架。如果我們能HL7消息加載到DataFrame一行代碼,大大增加了下遊的地方我們可以使用HL7消息。
  • 使用簡單的聲明性api從消息中提取數據:雖然圖書館像哈皮神為處理HL7v2消息提供api,這些api是複雜的,麵向對象的,並且需要很多知識HL7v2消息格式。如果我們可以給人們一行sql函數,它們可以HL7消息中有意義的數據,而不需要學習一種新的和複雜的API。
  • 有一個一致的模式和語義HL7消息,無論來源:悶燒既支持的直接攝入HL7v2消息,以及攝入HL7v2消息來自另一個流源文本,是否像一個開源工具Apache卡夫卡或特定於雲服務,如AWS的動作或Azure的EventHubs。無論源,信息總是被解析成相同的模式。再加上Apache火花的結構化流語義我們實現便攜式,平台無關的代碼,可以很容易地驗Beplay体育安卓版本證和運行同樣在批處理或流媒體數據處理。

最終,這種方法使得悶燒一個輕量級的圖書館,很容易學習和使用,它可以支持sla要求大量的HL7消息。現在,我們將深入悶燒的api和如何構建一個儀表板分析住院模式。

解析使用悶燒HL7消息

Apache火花™的結構化流API允許用戶流程流數據通過使用火花的SQL api的擴展。加上悶燒庫時,您可以加載到DataFrame HL7v2消息,要麼使用悶燒讀取批生HL7v2消息,或者通過使用悶燒解析HL7v2消息文本,從另一個流源。例如,如果你有一批消息加載,隻需調用hl7讀者:

scala > val df = spark.read.format (“hl7”).load (“路徑/ / hl7消息”)df: org.apache.spark.sql。DataFrame =[信息:字符串段:數組<結構> >)< /結構>

模式包含消息中的消息頭列返回。消息部分嵌套的部分列,這是一個數組,其中包含兩個嵌套的字段:細分的字符串id(例如,PID病人識別部分)和部分字段的數組。

悶燒也可以用來解析原始消息文本。這可能發生,如果你在一個中間有一個HL7消息喂養土地來源(例如,卡夫卡流)。要做到這一點,我們可以使用悶燒的parse_hl7_message helper函數。首先,我們開始DataFrame包含HL7消息文本:

scala>val textMessageDf=…textMessageDf: org.apache.spark.sql.DataFrame=(價值字符串):scala>textMessageDf.show ()+- - - - - - - - - - - - - - - - - - - - - - +|價值|+- - - - - - - - - - - - - - - - - - - - - - +|MSH|^~\&| || ||2020年。。。|+- - - - - - - - - - - - - - - - - - - - - - +

然後,我們可以導入com.databricks.labs.smolder parse_hl7_message消息。函數對象和應用列我們想解析:

scala >進口com.databricks.labs.smolder.functions.parse_hl7_message進口com.databricks.labs.smolder.functions.parse_hl7_messagescala > val parsedDf = textMessageDf.select (parse_hl7_message(美元)“價值”)。作為(“消息”))parsedDf: org.apache.spark.sql。DataFrame =[信息:struct>>>]

這個收益率相同的模式作為我們的hl7數據來源。

提取數據從HL7v2消息段使用悶燒

而悶燒HL7消息提供了一個易於使用的模式,我們還提供在com.databricks.labs.smolder輔助函數。函數來提取消息段的分支學科。例如,假設我們想要得到病人的名字,這是第五場在病人ID (PID)。我們可以提取這個segment_field函數:

scala>進口com.databricks.labs.smolder.functions.segment_field進口com.databricks.labs.smolder.functions.segment_fieldscala>val nameDf=df.select (segment_field (“PID”,4).alias(“名字”))nameDf: org.apache.spark.sql.DataFrame=(名稱:字符串)scala>nameDf.show ()+- - - - - - - - - - - - - +|的名字|+- - - - - - - - - - - - - +|海勒^Keneth|+- - - - - - - - - - - - - +

如果我們想讓病人的名字,我們可以使用分區功能:

scala>進口com.databricks.labs.smolder.functions.subfield進口com.databricks.labs.smolder.functions.subfieldscala>val firstNameDf=nameDf.select(子域(“名字”美元,1).alias (“firstname”))firstNameDf: org.apache.spark.sql.DataFrame=(firstname:字符串)scala>firstNameDf.show ()+- - - - - - - - - - - - +|firstname|+- - - - - - - - - - - - +|Keneth|+- - - - - - - - - - - - +
  • 銅層包含原始消息源(例如,一個表/ ADT飼料,ORM, ORU,等等)
  • 銀層骨料這信息表用於下遊應用程序(比如,一個縱向病人記錄,聚集醫院資源)
  • 金層包含應用程序級的數據(例如,醫院擁擠報警係統,占用每病房醫院)

為什麼建立三角洲湖上?首先,三角洲是一個開放的格式,確保數據便於從許多分析係統,其數據科學的生態係統是否通過Apache火花或數據倉庫係統突觸。此外,三角洲湖是為了支持級聯流,這意味著數據可以通過銅層,流到銀,最後金層。此外,三角洲湖提供了大量的方法優化我們的表來提高查詢性能。例如,我們可能想查詢迅速在病人ID和一個日期,因為這些是常見的字段查詢:正如我們在以前的博客中討論,我們可以使用z值。三角洲湖支持z值做多維數據集群和提供良好的性能在這兩種查詢模式。

開始建立一個健康三角洲湖悶燒

在這個博客中,我們介紹了悶燒,一個Apache 2許可庫加載EHR的患者數據。你可以開始了閱讀我們的項目文檔,或創建一個叉的存儲庫今天開始貢獻代碼。了解更多關於使用三角洲湖存儲和處理臨床數據集,我們的下載免費電子書使用真實的臨床數據。您還可以使用筆記本電腦今天開始免費試用解決方案加速器。

免費試著磚
開始
看到所有工程的博客的帖子
Baidu
map