HL7 v2X和v3數據建模

Question

我工作的公司在HL7開始了一項新計划，我們正在交易v2X和v3（CDA專用）消息。 我正處於能夠接受，驗證和確認我們從貿易​​伙伴那里收到的消息並開始為所述消息的后端存儲創建數據模型的地步。 經過大量的考慮和研究后，我在MS SQL Server 2008 R2中找到最佳方法。

目前我的想法是直接從我的集成引擎（BizTalk）將數據加載到數據倉庫中，並在前面提供支持的規范化操作數據庫。 我已經根據v2.7規范為v2X消息設置了數據庫，因為所有版本的HL7 v2都是向后兼容的（我可以在同一個數據庫中存儲任何以前的版本）。 我的初始設計有一個每個段的表，它將綁定到一個帶有我正在生成並在運行時存儲的guid的頭表。 這種方法的最大問題是每個表中的列數量，這是我沒有經驗的。 例如，PV1段有569列，以容納所有可能的數據。 除此之外，我需要使所有列varchar並使它們足夠大以容納來自我們供應商的任何可能的定制方案。 我打算使用varchar（1024）來實現這一目標。 很多這些列（大多數可能）都是NULL，所以我會使用SPARSE列。 這對我來說是一個糟糕的設計，但是對這些表進行完全規范化需要在BizTalk和SQL服務器上進行大量工作，而且我不確定這樣做會得到什么。 我正努力務實，因為我有一個截止日期。

如果完全標准化，我基本上必須創建具有大量參數的存儲過程，或者將這些消息拆分到第n度，以便將單個負載分配到較小的子表中，並確保它們都與原始guid相關聯。 我還想維護ACID處理，這可能會變得棘手並導致BizTalk中的大量開銷。 我想第三個選擇是使用nHapi從我可以與Entity Framework綁定的消息中創建對象，但是nHapi似乎是一個死的項目，我現在沒有使用Entity Framework的經驗。

我基本上處於虧損狀態，需要一些具有HL7數據建模經驗的行業專業人士的幫助。 完全規范表格是否值得付出額外的努力？ 如果我使用這些具有數百列的非規范化段表（大多數列對於每一行都是NULL），SQL端的性能是否會很糟糕？ 我不是DBA所以我試圖理解每種方法的缺陷。 我也看過RIMBAA但HL7 RIM對我來說似乎是一個外語，作為一個HL7新手，將翻譯v2消息轉換為RIM可能需要比我完成這個項目更長的時間。 我希望我能過度思考這個問題，並且有一個更簡單的解決方案讓我盯着我。 希望這個問題不是太開放。

Answer 1

HL7不是“嚴格”的標准輸入，預期輸出會根據您所使用的系統而有所不同。 在這種情況下，在Mirth，Rhaposdy或BizTalk等經紀人中添加是一個非常好的主意。

您使用的解決方案確保您可以應對“非標准”輸入和輸出，因為您很快就會發現各種不同。 在HL7版本2X和3上，請注意很少有醫院的版本3仍然運行2X。

我一直在使用一個試圖遵循HL7結構的數據庫，它可以工作，但這需要時間和精力。 鑒於你有一個緊張的死線可能會打破你需要搜索的數據位並有字段（例如，PID段3是患者ID將有用）其余的可以進入你的varchar。 此外，如果您沒有對列進行索引，則可以使用varchar（max）。

至於數據庫中的Guids，這可以正常工作，但要注意不要使用Guid對任何索引進行聚類，因為這會碎片化您的數據。 在這里做你的研究，如果有疑問，請選擇身份專欄。

我也會推薦實體框架，優秀的ORM，非常值得學習。

所以我的總體建議。 現在就去混合動力車，打破你需要的東西。 期望它隨着時間的推移而發展，根據需要將HL7的各個部分分解到他們自己的區域。 寫一個通用的HL7解析器（我已經做過幾次並不太困難）並保持靈活性。 但是大多數人都希望HL7在結構上有所不同，不要將規格視為100％的真相，你會得到變化。

Answer 2

在大多數情況下，嘗試創建規范化的關系數據模型以保留HL7 V2或V3數據是浪費時間。 我建議只將整個消息或文檔存儲為單個XML列值。 然后使用SQLXML和/或XQuery進行查詢。 所有現代關系數據庫現在支持這一點。

Answer 3

我只能根據個人經驗評論CDA（以及一些非常有限的HL7v2）方面。

我們從外部供應商（以及內部系統 - 以及下面的系統）接收和發送包含在HL7v3包裝中的CDA文檔。 包裝器包含發送/接收系統/日期和其他高級數據之類的元數據。 非常有限的消息元數據被剝離並存儲在消息數據存儲庫中。 在包裝器內部，是實際的CDA，然后將其作為XML數據類型存儲在SQL數據庫中。

使用此模型，我們可以在元數據級別進行搜索，但也可以使用Xpath查詢基於CDA縮小范圍。 它使數據庫變得更加簡單......我甚至無法想象基於CDA模式創建列。

至於讓客戶遵循CDA架構，作為項目的一部分，我們已經創建了一個實施指南，如果客戶希望接受他們的消息，他們必須遵循該指南。

使用實施指南+ schematron + BizTalk和XSD驗證，我們只接受遵循CDA架構的消息。 然后，我們使用schematron驗證檢查一些數據字段，如果其中任何一個失敗，則拒絕。 使用HL7v3消息將其轉發給發件人，並使用特定錯誤消息和/或無效字段將其發送回發件人。 這是消息將存儲在數據庫中的點。

這一切都在BizTalk / SQL Server中完成。 由於CDA模式由HL7組預先定義，因此您可以使該系統的使用者遵循模式。 這與我在HL7v2中看到的不同，人們似乎只是根據需要彎曲架構。

對於HL7v2方面，我99％肯定“我們”（如“我的公司”）以相同的方式存儲消息。 除了因為HL7v2架構如此開放，我們不會驗證並只是接受/存儲所有消息。 已編寫HL7v2解析器以使用我們了解的模式的變體來解析HL7v2。

在我的項目中，我們從我們的HCIS發送HL7v - > Mirth - > BizTalk，然后遵循實施指南+ CDA Schema以及XSLT轉換將HL7v2映射到CDA然后將其提交給OTHER BizTalk CDA提交服務好像是外部供應商。

這是現在的大量閱讀，所以請提問，因為我想談談它。

Answer 4

在HL7上建模可能很痛苦。

我會做以下事情;

• 使用HL7中描述的標准用於登台表，即使你有varchar（1024）並且它們為null也不會傷害你
• 根據您已強制執行或將強制執行的標准，創建要從登台表填充的實際表。

這意味着你有超過500列的消息，但只有10或50有意義，你需要只為你的50建模。是的，這有一個lopside，明天你想要更多的意義然后它會從50增加到75 ，歷史信息不會有信息; 這很好，但你需要考慮到設計。

Answer 5

在任何情況下，我都不會嘗試使用HL7 v3 RIM進行任何建模。 原因是這種模式非常通用，將大部分元數據推遲到消息本身。 你熟悉EAV表嗎？ RIM就是這樣。

另一方面，HL7 v2應該是數據庫模式的一個相當簡單的基礎。 您可以圍繞段類型創建表，並圍繞字段名稱創建列。

我認為拉入一切的問題會導致項目失敗，你不應該這樣做。 通常情況下，HL7 v2消息占據了整體的一小部分，因此構建整個內容將是一種完全的浪費，而且會非常混亂。

此外，您建模的v2版本會顯着影響您的模式，對於更高版本，越來越多的字段將成為重復字段，您的連接關系將發生變化。

我建議你把賭注放在沙子里並從v2.4開始，這比實際使用的大多數界面都要簡單但更復雜。 專注於幾個細分和幾個領域。 MSH和PID優先。

添加EAV表以捕獲表中尚未存在的內容。 然后，您可以查看隨着時間推移進入此表的內容，並使用它來決定下一步要構建的內容。 您的EAV可能看起來像MSG_ID，SEGMENT，SET_ID，FIELD_NAME，FIELD VALUE。 只需存儲字段值的未解析的HL7內容。