Microsoft Fabric 中的醫療保健資料解決方案中的資料架構和管理
醫療保健資料解決方案框架使用專門的徽章架構來簡化資料組織和處理。 這種設計可確保資料品質和結構的持續改進，使您能夠更有效地管理醫療保健資料。 本文探討了此架構的主要功能和優勢，全面概述如何在此框架內管理資料。
獎章湖倉設計
正如解決方案架構中所解釋的，醫療保健資料解決方案使用獎章湖倉架構來跨多個層組織和處理資料。 隨著資料在每一層中的移動，其結構和品質不斷改進。 醫療資料解決方案中的獎章湖倉設計的核心由以下關鍵湖倉組成：
銅湖倉：也稱為原始區域，銅湖倉是以原始檔格式組織源資料的第一層。 它將來源檔案提取到 OneLake 中和/或從本機儲存來源建立捷徑。 它還將來自來源的結構化和半結構化資料儲存在增量表 (也稱為暫存資料表) 中。 這些表經過壓縮和列索引，以支援高效的轉換和資料處理。 該層中的資料通常是僅附加且不可變的。
銅湖倉中的文件 (無論是持久的還是快捷方式) 都是事實的來源。 它們為醫療保健資料解決方案中整個資料資產的資料沿襲奠定了基礎。 銅層中的暫存表通常由幾列組成，旨在將每種資料模式和格式儲存在單一表中 (例如，ClinicalFhir 和 ImagingDicom 資料表)。 由於以下原因，您不應擴展、自訂或建立對銅湖倉中這些臨時資料表的依賴關係：
- 內部實作：暫存表是針對 Microsoft Fabric 中的醫療保健資料解決方案在內部實現的。 他們的架構是專門為醫療保健資料解決方案構建的，不遵循任何行業或社區資料標準。
- 暫時儲存：在資料經過處理並從銅湖倉臨時表轉換為銀色湖倉中的扁平化和標準化增量表後，銅臨時表資料被視為已準備好清除。 該模型確保了成本和儲存效率，並減少了銅湖倉中原始檔案和臨時表之間的資料冗餘。
銀色湖倉：又稱富集區，銀色湖倉從銅湖倉提煉資料。 它包括驗證檢查和豐富技術，以提高下游分析的資料準確性。 與銅層不同，銀色湖倉資料使用基於確定性識別碼和修改時間戳記的規則來管理記錄插入和更新。
金湖倉：也稱為精選區，金湖倉進一步細化銀色金湖倉的資料，以滿足特定的業務和分析要求。 此層是高品質彙總資料集的主要來源，可用於全面性分析和深入解析擷取。 雖然醫療保健資料解決方案每次部署部署一個銅和一個銀色湖倉，但您可以擁有多個金湖倉來為不同的業務部門和角色提供服務。
管理湖倉：管理湖倉包含用於跨湖倉層的資料治理和可追溯性的檔案，包括存儲在 BusinessEvent 表中的全域設定和驗證錯誤。 若要深入了解，請參閱管理員湖倉。
統一資料夾結構
醫療保健和生命科學客戶處理來自各種來源系統、多種資料模式和文件格式的大量資料，包括以下文件格式：
- 臨床模式：FHIR NDJSON 檔案、FHIR 套裝和 HL7。
- 影像學檢查方式：DICOM、NIFTI 和 NDPI。
- 基因體學模式：BAM、BCL、FASTQ 和 VCF。
- 索賠：CCLF 和 CSV。
其中：
- FHIR：快速醫療保健互操作性資源
- HL7：健康七級國際
- DICOM：醫學中的數位成像和通訊
- NIFTI：神經影像資訊學技術倡議
- NDPI：納米維病理成像
- BAM：二進位對齊圖
- BCL：基本調用
- FASTQ：一種基於文字的格式，用於存儲生物序列及其相應的品質分數
- VCF：變異體呼叫格式
- CCLF：索賠和索賠換行
- CSV：逗點分隔值
Microsoft Fabric 的 OneLake 為您的組織提供邏輯資料湖。 Microsoft Fabric 中的醫療保健資料解決方案提供了統一的資料夾結構，有助於組織各種模式和格式的資料。 這種結構簡化了資料內嵌和處理，同時在銅湖倉中的來源檔案和來源系統層級維護資料沿襲。
六個頂級資料夾包括：
- 外部
- 已失敗
- 內嵌
- 處理
- ReferenceData
- SampleData
子資料夾的組織方式如下：
Files\Ingest\[DataModality]\[DataFormat]\[Namespace]Files\External\[DataModality]\[DataFormat]\[Namespace]\[BYOSShortcutname]\Files\SampleData\[DataModality]\[DataFormat]\[Namespace]\Files\ReferenceData\[DataModality]\[DataFormat]\[Namespace]\Files\Failed\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DDFiles\Process\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD
資料夾描述
命名空間 (必需)：標識接收到的文件的來源系統，這對於確保每個來源系統的識別碼唯一性至關重要。
內嵌資料夾：用作卸除或佇列資料夾。 此資料夾可讓您將要擷取的檔案放入適當的模式和格式子資料夾中。 內嵌開始後，檔案將傳輸到對應的 Process 資料夾或失敗的 Failed 資料夾。
處理資料夾：每個模式和格式組合中所有成功處理的檔案的最終目的地。 該資料夾遵循基於處理日期的
YYYY/MM/DD模式。 資料夾分區遵循用於改進組織、篩選搜尋、自動化和潛在並行處理 Azure Data Lake Storage 的最佳做法。外部資料夾：作為自帶儲存 (BYOS) 快捷方式資料夾的上層資料夾。 預設部署為索賠、臨床、基因組學和成像模式提供了提示性資料夾結構。 影像和臨床模式具有配置為支援 Azure 健康資料服務中的 DICOM 和 FHIR 服務的預設格式和命名空間。 僅當您打算將資料快捷方式放入 OneLake 時，此格式才適用。 Microsoft Fabric 中的醫療保健資料解決方案對這些快速資料夾中的檔案具有唯讀存取權。
失敗資料夾：如果在移動或處理內嵌或處理資料夾中的檔案時發生故障，受影響的檔案將移動到與其模式和格式組合相對應的失敗資料夾中。 錯誤將記錄到管理員湖倉中的 BusinessEvent 資料表中。 該資料夾遵循基於處理/失敗日期的
YYYY/MM/DD模式。 此資料夾中的檔不會清除並繼續保留在此處，直到您使用相同的初始引入模式修復並重新引入它們。範例資料資料夾：包括合成資料集、參考資料集和/或公共資料集。 預設部署提供多種模式和格式組合的範例資料，以便於部署後立即執行筆記本和管道。 該資料夾不會建立任何
YYYY/MM/DD子資料夾。參考資料資料夾：包含來自公共或使用者特定源的參考資料集和上層資料集。 該資料夾不會建立任何
YYYY/MM/DD子資料夾。 預設部署為 OMOP (觀察醫療結果合作夥伴關係) 詞彙表提供建議的資料夾結構。
資料整合模式
基於前面概述的統一資料夾結構，Microsoft Fabric 中的醫療保健資料解決方案支援兩種不同的內嵌模式。 在這兩種情況下，解決方案都使用 Spark 中的結構化流來處理對應資料夾中的傳入檔案。
內嵌模式
此模式是一種簡單的方法，其中要內嵌的檔案被放入適當模式、格式和命名空間下的內嵌資料夾中。 內嵌管道監視此資料夾中是否有新刪除的文件，並將它們移至對應的程序資料夾中進行處理。 如果成功將文件資料引入銅湖倉暫存資料表，則會按照處理發生時間的 YYYY/MM/DD 模式，壓縮檔並使用時間戳首碼儲存在程序資料夾中。 此首碼可確保檔案名稱唯一。 您可以根據需要配置或停用壓縮。
如果檔案處理失敗，失敗的檔案將從每種模式和格式組合的嵌入資料夾移至失敗資料夾，並將錯誤記錄到管理員湖倉中的 BusinessEvent 表中。
此內嵌模式非常適合每日增量內嵌或將資料實際移至 Azure Data Lake Storage 或 OneLake 時。
自帶儲存 (BYOS) 模式
有時，資料和檔案可能已存在於 Azure 或其他雲端儲存服務中，並且現有下游實作和對這些檔案的依賴關係。 在醫療保健和生命科學領域，資料量可以達到數 TB 甚至 PB，特別是對於醫學成像和基因組學。 由於這些原因，直接內嵌模式可能不可行。
當 Azure 或支援 S3 協定的其他雲端和本機儲存體中已有大量可用資料時，我們建議使用 BYOS 模式進行歷史資料引入。 此模式使用 Fabric 中的 OneLake 捷徑以及銅湖倉中的外部資料夾來啟用原始檔案的就地處理。 它消除了移動或複製檔的需要，並避免了產生傳出費用和資料重複。
儘管 BYOS 引入模式提供了效率，但應注意以下注意事項：
- 不會監視就地檔更新 (檔案中的內容更新)。 需要為任何更新建立一個新檔 (具有不同的名稱)，因為引入管道僅監視新檔。 此限制與 Spark 中的結構化流相關。
- 不應用資料壓縮。
- BYOS 模式不會基於
YYYY/MM/DD該模式建立任何最佳化的資料夾結構。 - 如果檔案處理失敗，失敗的檔案不會移至失敗資料夾。 但是，錯誤將記錄到管理員湖倉中的 BusinessEvent 資料表中。
- 假定來源資料是唯讀的。
- 內嵌後無法控制來源資料的沿襲或可用性。
資料壓縮
Microsoft Fabric 中的醫療保健資料解決方案支援跨獎章湖倉設計的設計壓縮。 內嵌到徽章湖倉的增量表中的資料使用 parquet 檔案以壓縮的柱狀格式儲存。 在內嵌模式中，當檔案從內嵌資料夾移至程序資料夾時，成功處理後預設會進行壓縮。 您可以根據需要配置或停用壓縮。 對於映像和聲明功能，引入管道還可以處理 ZIP 壓縮格式的原始檔。
醫療保健資料模型
如同徽章湖倉設計中所述，銅湖倉暫存表在內部實現了醫療保健資料解決方案的專用表，並且不遵循任何行業或社區資料標準。
銀湖苑中的醫療保健資料模型基於 FHIR R4 標準。 它為資料分析師、資料科學家和開發人員提供了一種通用的資料語言，以協作和建立資料驅動的解決方案，從而改善患者的治療結果和業務績效。 它支援跨不同醫療保健領域的資料，例如臨床、行政、財務和社會。 醫療保健資料模型捕獲 FHIR 標準定義的資料，並使用湖倉中的表和列組織 FHIR 資源。
透過將 FHIR 資料展平為 delta parquet 表，您可以使用 T-SQL 和 Spark SQL 等熟悉的工具進行資料探索和分析。 對於 FHIR 範圍之外的非臨床資料，我們使用 Azure Synapse 資料庫範本中的架構。 該實施允許將非臨床資訊 (例如患者參與資料) 整合到患者檔案中。
銀色湖倉中的醫療保健資料模型旨在代表跨業務部門和研究領域的醫療保健資料的端到端企業檢視。
資料沿襲和可追溯性
為了確保記錄和文件層級的沿襲和可追溯性，醫療保健資料模型表包括以下列：
| 資料行 | 描述 |
|---|---|
msftCreatedDatetime |
銀色湖倉首次建立記錄的時間戳記。 |
msftModifiedDatetime |
上次修改記錄的時間戳記。 |
msftFilePath |
銅湖倉中源文件的完整路徑，包括快捷方式。 |
msftSourceSystem |
記錄的來源系統，對應於統一的資料夾結構中指定的 Namespace。 |
如果欄位被標準化、展平或修改，原始值將保留在 {columnName}Orig 資料行中。 例如，在銀色湖倉患者資料表中，您可以找到以下列：
| 資料行 | 描述 |
|---|---|
meta_lastUpdatedOrig |
以原始格式 (字串或日期) 保留原始值，並將其存儲為日期時間。 |
idOrig 和 identifierOrig |
銀色湖倉中的識別碼和標識符是一致的。 |
birthdateOrig 和 deceasedDateTimeOrig |
使用不同的時間戳格式保留原始日期值。 |
如果列變平 (例如 meta_lastUpdated) 或轉換為字串 (例如 meta_string)，我們使用以下劃線 (_) 開頭的後綴來表示它。
更新處理
當新資料從銅擷取到銀色湖倉時，更新操作會將傳入記錄與銀色湖倉中的每種資源和表格類型的目標表進行比較。 對於銀色湖倉中的 FHIR 表，此比較根據 ClinicalFhir 銅銀色湖倉暫存表中的 {FHIRResource}.id 和 {FHIRResource}.meta_lastUpdated 列檢查 id 和 lastUpdated 值。
- 如果識別出匹配且傳入記錄是新的，則銀牌記錄將被更新。
- 如果傳入的記錄是舊的，則銀記錄將被忽略。
- 如果未找到匹配項，則將新記錄插入到銀湖倉中。
管理湖倉
管理湖倉管理 Microsoft Fabric 中醫療保健資料解決方案的跨湖倉設定、全域設定、狀態報告和追蹤。
全域設定
管理湖倉系統設定 資料夾集中了全域設定參數。 這三個設定檔包含所有醫療保健資料解決方案功能的預設部署的預先設定值。 您無需重新設定任何這些值即可執行任何功能的範例資料或資料管道。
DeploymentParametersConfiguration.json 檔案包含 activitiesGlobalParameters 下的全域參數以及 activities 下的筆記本和管道的特定於活動的參數。 相應的功能指南涵蓋了每個功能的特定配置詳細資訊。 validation_config.json 檔案參數在資料驗證中進行了解釋。
下表列出了所有全域設定參數。
| 章節 | 設定參數 |
|---|---|
activitiesGlobalParameters |
•administration_lakehouse_id：管理湖倉識別碼。• bronze_lakehouse_id：銅湖倉識別碼。• silver_lakehouse_id：銀湖倉識別碼。• keyvault_name：與 Azure Marketplace 產品一起部署時的 Azure Key Vault 值。• enable_hds_logs：啟用日誌記錄；預設值設定為 true。• movement_config_path：file_orchestration_config 檔案的路徑。• bronze_imaging_delta_table_path：成像模態表的結構路徑 (如果已部署)。• bronze_imaging_table_schema_path：成像模態結構描述+的結構路徑 (如果已部署)。• omop_lakehouse_id：金色湖倉標識碼 (如果已部署)。 |
| healthcare#_msft_fhir_ndjson_bronze_ingestion 活動 | •source_path_pattern：Process 資料夾的 OneLake 路徑。• move_failed_files_enabled：用於確定失敗檔是否應從內嵌資料夾移動到失敗資料夾的標誌。• compression_enabled：用於確定原始 NDJSON 檔在處理後是否會被壓縮的標誌。• target_table_name：銅湖倉的臨床內嵌表名稱。• target_tables_path：銅湖倉中所有三角洲表的 OneLake 路徑。• max_files_per_trigger：每次執行處理的檔案數。• max_structured_streaming_queries：可以並行執行的處理查詢數。• checkpoint_path：檢查點資料夾的 OneLake 路徑。• schema_dir_path：銅結構描述資料夾的 OneLake 路徑。• validation_config_key：上層等級驗證設定。 如需更多資訊，請見資料驗證。• file_extension：內嵌的原始檔案的副檔名。 |
| healthcare#_msft_bronze_silver_flatten 的活動 | •source_table_name：銅湖倉的臨床內嵌表名稱。• config_path：扁平化設定檔的 OneLake 路徑。• source_tables_path：OneLake 通往銅湖倉中源三角洲表的路徑。• target_tables_path：OneLake 通往銀湖倉中目標 Delta 表的路徑。• checkpoint_path：檢查點資料夾的 OneLake 路徑。• schema_dir_path：銅結構描述資料夾的 OneLake 路徑。• max_files_per_trigger：每次執行處理的檔案數。• max_bytes_per_trigger：每次執行中處理的位元組數。• max_structured_streaming_queries：可以並行執行的處理查詢數。 |
| healthcare#_msft_imaging_dicom_extract_bronze_ingestion 活動 | •byos_enabled：確定銅湖倉中 DICOM 成像資料集的引入是否通過 OneLake 快捷方式從外部存儲位置獲取的標誌。 在這種情況下，檔案不會像其他情況那樣移動到 Process 資料夾。• external_source_path：銅湖倉中捷徑外部資料夾的 OneLake 路徑。• process_source_path：銅湖倉中 Process 資料夾的 OneLake 路徑。• checkpoint_path：檢查點資料夾的 OneLake 路徑。• move_failed_files：用於確定失敗檔是否應從內嵌移動到失敗資料夾的標誌。• compression_enabled：用於確定原始 NDJSON 檔在處理後是否會被壓縮的標誌。• max_files_per_trigger：每次執行處理的檔案數。• num_retries：發生錯誤之前每個文件處理的重試次數。 |
| healthcare#_msft_imaging_dicom_fhir_conversion 活動 | •fhir_ndjson_files_root_path：Process 資料夾的 OneLake 路徑。• avro_schema_path：銀結構描述資料夾的 OneLake 路徑。• dicom_to_fhir_config_path：用於將設定從 DICOM 元標記對應到 FHIR ImagingStudy 資源的 OneLake 路徑。• checkpoint_path：檢查點資料夾的 OneLake 路徑。• max_records_per_ndjson：每次執行中單個 NDJSON 檔中處理的記錄數。• subject_id_type_code：DICOM 中繼資料中患者醫療編號的值代碼。 預設值設定為 MR，對應於 FHIR 中的 Medical Record Number。• subject_id_type_code_system：DICOM 中繼資料中患者醫療編號的值代碼系統。• subject_id_system：DICOM 中繼資料中患者醫療編號的值代碼系統物件識別碼。 |
| healthcare#_msft_omop_silver_gold_transformation 活動 | •vocab_path：OneLake 路徑，指向存儲詞彙資料集的銅湖倉 OMOP 中的參考資料資料夾。• vocab_checkpoint_path：檢查點資料夾的 OneLake 路徑。• omop_config_path：OneLake 路徑，用於對應從銀湖倉到金 OMOP 湖倉的設定。 |
BusinessEvents 資料表
BusinessEvents 增量表捕獲引入和轉換過程中可能發生的所有驗證錯誤、警告和其他通知或異常。 使用此表在使用者和功能級別監視引入執行進度，而不僅僅是在系統記錄等級。 例如，它可以識別哪些原始檔案在內嵌過程中引入了驗證錯誤或警告。 對於系統層級日誌並監視所有 Lakehouse 中的 Apache Spark 活動，您可以使用 Fabric 監視中心，並可以選擇整合 Azure Log Analytics。
下表列出了 BusinessEvent 資料表中的欄位：
| 資料行 | 描述 |
|---|---|
id |
資料表中資料列的唯一識別碼 (GUID)。 |
activityName |
生成失敗和/或驗證錯誤或警告的活動/筆記本的名稱。 |
targetTableName |
生成事件的資料活動的目標表。 |
targetFilePath |
產生事件的資料活動的目標檔案的路徑。 |
sourceTableName |
產生事件的資料活動的來源表。 |
sourceLakehouseName |
產生事件的資料活動的來源湖倉。 |
targetLakehouseName |
產生事件的資料活動的目標湖倉。 |
sourceFilePath |
產生事件的資料活動的來源檔案的路徑。 |
runId |
產生事件的資料活動的執行識別碼。 |
severity |
事件的嚴重性級別，可能具有以下兩個值之一：Error 或 Warning。 Error 表示必須先解決此事件，然後才能繼續執行資料活動。 Warning 用作被動通知，通常不需要立即執行操作。 |
eventType |
區分驗證引擎生成的事件和使用者生成的一般事件或使用者要顯示到 BusinessEvent 表的未處理/系統異常。 |
recordIdentifier |
來源記錄的識別碼。 此列與列 id 不同，因為它表示 BusinessEvents 資料表中每個事件的新的唯一標識碼。 |
recordIdentifierSource |
來源記錄標識符的來源系統。 例如，如果來源系統是 EMR，則 EMR 名稱或 URL 將用作源。 |
active |
指示事件 (錯誤或警告) 是否已解決的標誌。 |
message |
事件錯誤或警告的描述性消息。 |
exception |
未處理/系統異常消息。 |
customDimensions |
當驗證或異常的來源資料不是表中的離散列時適用。 例如，當來源資料是儲存為單列中字串的 JSON 物件中的屬性時，完整的 JSON 物件將作為自訂維度提供。 |
eventDateTime |
事件或異常產生的時間戳記。 |
資料驗證
醫療保健資料解決方案中 Microsoft Fabric 的資料驗證引擎可確保原始資料在內嵌到青銅湖倉之前滿足預定義的條件。 您可以在銅湖倉內的資料表和欄位配置驗證規則。 目前，這些規則僅在內嵌過程中實施，從原始文件到銅湖倉中的增量表。
處理原始檔時，驗證規則將在內嵌等級應用。 驗證有兩個嚴重性級別：Error 和 Warning。 如果驗證規則設為 Error，則當違反規則時管道將停止，並且有問題的檔案將移至失敗資料夾。 如果嚴重性設為 Warning，管道將繼續處理，並且檔案將移至 Process 資料夾。 在這兩種情況下，都會在管理湖倉內的 BusinessEvents 表中建立反映錯誤或警告的條目。
BusinessEvents 資料表擷取醫療保健資料解決方案中任何活動、筆記本或資料管道的所有湖倉的業務級記錄和事件。 但是，目前設定僅在擷取期間強制執行驗證規則，這可能會導致 BusinessEvents 資料表中的某些欄位仍未填入驗證錯誤和警告。
您可以在管理湖倉的 validation_config.json 檔案中設定資料驗證規則。 預設情況下，銅湖倉的 ClinicalFhir 表中的 meta.lastUpdated 和 id 資料行是根據需要設定的。 這些列對於確定如何在銀湖倉中管理更新和插入至關重要，如更新處理 中 所述。
下表列出了資料驗證的設定參數：
| 設定類型 | 參數 |
|---|---|
| 湖倉 | bronze：驗證和記錄識別碼節點的範圍。 在本例中，該值設置為青銅湖倉。 |
| 驗證 | •validationType： exists 驗證類型檢查原始檔 (源資料) 中是否提供了已配置屬性的值。• attributeName：正在驗證的屬性的名稱。• validationMessage：描述驗證錯誤或警告的消息。• severity：指示問題的級別，可以是 Error 或 Warning。• tableName：正在驗證資料表的名稱。 星號 (*) 表示此規則適用於該湖倉範圍內的所有表。 |
recordIdentifier |
•attributeName：來源/原始檔案的記錄識別碼位於 BusinessEvent 表中的 recordIdentifier 資料行。• jsonPath：可選值，表示要放置在 BusinessEvent 表中的 recordIdentifier 資料行的資料行或屬性的 JSON 路徑。 當驗證的來源資料不是表中的離散列時，請套用此值。 例如，如果來源資料是作為字串儲存在單列中的 JSON 物件中的屬性，則 JSON 路徑將定向到充當記錄標識符的特定屬性。 |