醫療保健資料解決方案中 DICOM 資料轉換的使用注意事項
本文概述了在使用 DICOM 資料轉換功能之前需要查看的關鍵注意事項。 了解這些因素可確保您的醫療保健資料解決方案環境中的順利整合和作業。 此資源還可以幫助您有效地應對該功能的一些潛在挑戰和限制。
擷取檔案大小
目前，ZIP 檔的邏輯大小限制為 8 GB，本機 DCM 檔的邏輯大小限製為 4 GB。 如果您的檔案超出這些限制，您可能會遇到更長的執行時間或擷取失敗。 我們建議將 ZIP 檔案分割成較小的區段 (小於 4 GB) 以確保成功執行。 對於大於 4 GB 的本機 DCM 檔，請確保根據需要擴展 Spark 節點 (執行程式)。
DICOM 標籤擷取
我們優先推廣 銅牌湖存放庫 ImagingDicom delta 表中 的 29 個標籤，原因如下：
- 這 29 個標籤對於 DICOM 資料的一般查詢和探索至關重要，例如影像檢查方式和側別。
- 這些標籤對於在後續執行步驟中產生和填寫銀層 (FHIR) 和金層 (OMOP) Delta 表是必需的。
您可以擴展和推廣您感興趣的其他 DICOM 標籤。 但是，DICOM 數據轉換筆記本不會自動識別或處理您添加到 銅牌湖存放庫中的 ImagingDicom delta 表中的任何其他 DICOM 標記列。 您需要獨立處理額外的資料行。
Bronze Lakehouse 中的附加模式
所有新攝取的 DCM (或 ZIP) 檔都附加到 銅牌湖存放庫的 ImagingDicom delta 表中。 對於每個成功攝取的 DCM 檔，我們在 ImagingDicom delta 表中創建一個新的記錄條目 。 在 Bronze Lakehouse 層級沒有合併或更新作業的商務規則。
ImagingDicom delta 表反映了 DICOM 實例級別的每個提取的 DCM 檔，應被視為如此。 如果將同一 DCM 檔再次提取到 Ingest 資料夾中，我們將向同一檔的 ImagingDicom delta 表添加另一個條目 。 但是，由於 Unix 首碼時間戳記，檔案名稱有所不同。 根據攝取日期，檔可能會放置在不同的 YYYY\MM\DD 資料夾中。
OMOP 版本和成像擴充功能
Gold Lakehouse 目前的實作是基於觀察性醫療保健結果合作夥伴關係 (OMOP) Common Data Model 5.4 版。 OMOP 尚無支援成像資料的標準擴充功能。 因此，該功能實作了基於成像觀察研究的醫學成像資料標準化開發：OMOP Common Data Model 擴充功能中提出的擴充功能。 此次擴展是 2024 年 2 月 5 日發佈的成像研究領域的最新提案。 目前版本的 DICOM 資料轉換功能僅限於 Gold Lakehouse 中的 Image_Occurrence 表。
Spark 中的結構化串流
結構化串流是基於 Spark SQL 引擎建構的可擴展且容錯的串流處理引擎。 您可以像表達靜態資料的批次運算一樣表達串流運算。 該系統通過檢查點和預寫日誌確保端到端的容錯保證。 要了解有關結構化串流的更多資訊，請參閱結構化串流編程指南 (v3.5.1)。
我們使用 ForeachBatch 來處理增量資料。 此方法套用任意作業，並將邏輯寫入串流查詢的輸出。 此查詢對串流查詢的每個微批次的輸出資料執行。 在 DICOM 資料轉換功能中，結構化串流程用於執行以下步驟：
| 執行步驟 | 檢查點資料夾位置 | 追蹤物件 |
|---|---|---|
| 將 DICOM 中繼資料擷取到銅牌湖倉中 | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_metadata_extraction |
銅牌湖存放庫下的 Files\Process\Imaging\DICOM\YYYY\MM\DD DCM 檔。 |
| 將 DICOM 中繼資料轉換為 FHIR 格式 | healthcare#.HealthDataManager\DMHCheckpoint\medical_imaging\dicom_to_fhir |
Delta 表 ImagingDicom 在銅牌湖存放庫。 |
| 將資料擷取到銅湖倉的 ImagingStudy 增量表中 | healthcare#.HealthDataManager\DMHCheckpoint\<bronzelakehouse>\ImagingStudy |
銅牌湖存放庫下的 Files\Process\Clinical\FHIR NDJSON\YYYY\MM\DD\ImagingStudy FHIR NDJSON 檔。 |
| 將資料擷取到銀湖倉的 ImagingStudy 增量表中 | healthcare#.HealthDataManager\DMHCheckpoint\<silverlakehouse>\ImagingStudy |
Bronze Lakehouse 中的 Delta 表 ImagingStudy。 |
提示
您可以使用 OneLake 檔案總管查看表中所列的檔案和資料夾的內容。 有關詳細資訊，請參閱使用 OneLake 檔案總管。
Bronze Lakehouse 中的群組模式
當您將新記錄從 銅牌湖存放庫的 ImagingDicom delta 表提取到 銅牌湖存放庫的 ImagingStudy delta 表時，將應用組模式。 DICOM 資料轉換功能按研究級別對 ImagingDicom delta 表中的所有 實例級記錄進行分組。 它為每個 DICOM 研究建立一筆記錄作為 ImagingStudy，然後將該記錄插入 Bronze Lakehouse 中的 ImagingStudy Delta 表中。
在 Silver Lakehouse 中的更新 Upsert 模式
upsert 操作根據以下 {FHIRResource}.id因素比較青銅色和銀色湖倉一體之間的 FHIR 增量表：
- 如果識別到匹配，則 Silver 層的記錄將使用新的 Bronze 層記錄進行更新。
- 如果未識別到匹配，則會將 Bronze 層的記錄作為新記錄插入到 Silver Lakehouse 中。
我們使用此模式在銀色湖存放庫 ImagingStudy 表中創建資源。
ImagingStudy 的限制
當您在同一批執行中從相同 DICOM 研究中擷取 DCM 檔案時，upsert 作業將會如預期般運作。 但是，如果您稍後攝取更多 DCM 檔 (來自不同批次)，這些文件屬於之前攝取到銀牌湖存放庫中的同一 DICOM 研究，則攝取會導致插入 操作。 該進程不執行 Update 操作。
發生此 Insert 操作是因為筆記本在每次批處理執行中為 ImagingStudy {FHIRResource}.id 創建一個新 操作。 此新 ID 與上一批中的 ID 不符。 因此，您會在 Silver 表中看到兩個具有不同 ImagingStudy.id 值的 ImagingStudy 記錄。 這些 ID 與其各自的批次執行相關，但屬於同一個 DICOM 研究。
作為解決方法，完成批次執行並根據唯一 ID 的組合合併 Silver Lakehouse 中的兩個 ImagingStudy 記錄。 但是，請勿使用 ImagingStudy.id 來進行合併。 相反，您可以使用其他 ID (如 [studyInstanceUid (0020,000D)] and [patientId (0010,0020)] ) 來合併記錄。
OMOP 追蹤方法
healthcare#_msft_omop_silver_gold_transformation 筆記本使用 OMOP API 來監控 silver 湖存放庫 delta 表中的更改。 它標識需要更新插入到 Gold Lakehouse Delta 表中的新修改或新增的記錄。 此過程稱為浮水印。
OMOP API 會比較 {Silver.FHIRDeltatable.modified_date} 和 {Gold.OMOPDeltatable.SourceModifiedOn} 之間的日期和時間值，以決定自上次筆記本執行以來修改或新增的增量記錄。 然而，這種 OMOP 追蹤方法並不適用於 Gold Lakehouse 中的所有 Delta 表。 以下表格不是從 Silver Lakehouse 的 Delta 表中擷取的：
- 接受
- concept_ancestor
- concept_class
- concept_relationship
- concept_synonym
- fhir_system_to_omop_vocab_mapping
- 詞彙
這些黃金 delta 表使用範例數據部署 OMOP 中包含的詞彙數據進行填充。 此資料夾中的詞彙資料集使用 Spark 中的結構化串流進行管理。
在 Gold Lakehouse 中的更新 Upsert 模式
Gold Lakehouse 的 upsert 模式與 Silver Lakehouse 不同。 OMOP healthcare#_msft_omop_silver_gold_transformation 筆記本使用的 API 為黃金湖存放庫的增量表中的每個條目創建新 ID。 API 會在擷取或將新記錄從 Silver Lakehouse 轉換為 Gold Lakehouse 時建立這些 ID。 OMOP API 還會維護新建立的 ID 與其在 Silver Lakehouse Delta 表中對應的內部 ID 之間的內部對應。
API 的運作原理如下：
如果將記錄從 Silver 層轉換到 Gold 層 Delta 表，並且是第一次轉換，則會在 OMOP Gold Lakehouse 中生成一個新的 ID，並將其對應到 Silver Lakehouse 中的原始新 ID。 然後，它會將該記錄使用新生成的 ID 插入到 Gold Delta 表中。
如果 Silver Lakehouse 中的相同記錄經過修改並再次擷取到 Gold Lakehouse 中，OMOP API 會根據對應資訊識別 Gold Lakehouse 中的現有記錄。 然後，它會使用先前產生的相同 ID 更新 Gold Lakehouse 中的記錄。
Gold Lakehouse 中新產生的 ID (ADRM_ID) 與每個 OMOP Delta 表中原始 ID (INTERNAL_ID) 之間的對應關係，會儲存在 OneLake 的 Parquet 檔案中。 您可以在以下檔案路徑找到 Parquet 檔案：
[OneLakePath]\[workspace]\healthcare#.HealthDataManager\DMHCheckpoint\dtt\dtt_state_db\KEY_MAPPING\[OMOPTableName]_ID_MAPPING
您也可以查詢 Spark 筆記本中的 Parquet 檔案以查看對應。
銀色的 ImagingMetastore 設計湖存放庫
單個 DICOM 檔最多可包含 5,000 個不同的標籤，這使得在銀色湖存放庫中為所有這些標籤映射和創建字段效率低下且耗費大量資源。 但是，保留對完整標籤集的訪問許可權對於防止數據丟失和保持靈活性至關重要，尤其是當您需要的數據模型中提取和表示的 29 個標籤之外的標籤時。 為了解決這個問題，銀色湖存放庫 ImagingMetastore delta 表將所有 DICOM 標記 metadata_string 存儲在列中。 這些標籤以字串化的 JSON 格式表示為鍵值對，從而可以通過 SQL 分析端點進行高效查詢。 這種方法與管理白銀湖存放庫中所有欄位中的複雜 JSON 數據的標準做法一致。
從銅牌湖存放庫中的 ImagingDicom 表到 銀牌湖存放庫中的 ImagingMetastore 表，轉換不執行任何分組。 資源在兩個表中都表示在實例級別。 但是，它 {FHIRResource}.id 包含在 ImagingMetastore 表中。 此值允許您通過引用特定研究的唯一 ID 來查詢與特定研究關聯的所有實例級物件。
與 DICOM 服務整合
目前 DICOM 資料轉換功能和 Azure 健康資料服務 DICOM 服務之間的整合僅支援建立和更新事件。 您可以創建新的成像研究、系列和實例，甚至可以更新現有研究、系列和實例。 但是，集成尚 不支援 Delete 事件。 如果您刪除 DICOM 服務中的研究、影像序列或執行個體，DICOM 資料轉換功能不會反映此變更。 成像資料將保持不變且不會刪除。
表警告
每個湖存放庫中的所有表都會顯示警告，其中一個或多個列使用複雜的面向對象的數據類型來表示數據。 在 ImagingDicom 和 ImagingMetastore 表中，該 metadata_string 列使用 JSON 結構將 DICOM 標記映射為鍵值對。 此設計適應了 Fabric SQL 終端節點的限制，這些終端節點不支援複雜的數據類型，例如結構、陣列和映射。 您可以使用 SQL 端點 (T-SQL) 以字串形式查詢這些列，也可以使用 Spark 處理其本機類型 (結構、陣列、映射)。
