Microsoft Fabric の医療データ ソリューションにおけるデータ アーキテクチャと管理

医療データ ソリューション フレームワークは、特定のメダリオン アーキテクチャ を使用して、データの編成と処理を合理化します。 この設計により、データの品質と構造が継続的に改善され、医療データをより効果的に管理できるようになります。 この記事では、このアーキテクチャの主な機能と利点について説明し、このフレームワーク内でデータを管理する方法の包括的な概要を示します。

メダリオン レイクハウスの設計

ソリューション アーキテクチャ で説明したように、医療データ ソリューションでは、メダリオン レイクハウス アーキテクチャを使用して、複数のレイヤーにわたってデータを整理および処理します。 データが各レイヤーを移動すると、その構造と品質は継続的に改善されます。 医療データ ソリューションにおけるメダリオン レイクハウスの設計は、その中核として次の主要なレイクハウスで構成されます:

• ブロンズ レイクハウス: ロー ゾーンとも呼ばれるブロンズ レイクハウスは、ソース データを元のファイル形式で編成する最初のレイヤーです。 ソース ファイルを OneLake に取り込んだり、ネイティブ ストレージ ソースからショートカットを作成したりします。 また、ソースからの構造化データと半構造化データを、デルタ テーブル (ステージング テーブルとも呼ばれます) に格納します。 これらのテーブルは、効率的な変換とデータ処理をサポートするために圧縮され、列インデックスが作成されます。 通常、このレイヤーのデータは追加専用で不変です。

  ブロンズ レイクハウス内のファイル (持続であれショートカットであれ) は、信頼できるソースとして機能します。 これらは、医療データ ソリューションのデータ資産全体にわたるデータ系列の基盤を構築します。 ブロンズ レイヤーのステージング テーブルは、通常、いくつかの列で構成され、各データ モダリティと形式を 1 つのテーブル (例: ClinicalFhir や ImagingDicom テーブルなど) に保持するように設計されています。 次の理由により、ブロンズ レイクハウスのこれらのステージング テーブルに対する依存関係を拡張、カスタマイズ、または構築しないでください:

  • 内部実装: ステージング テーブルは、Microsoft Fabric の医療データ ソリューションに固有の内部実装です。 そのスキーマは医療データ ソリューション用に構築されたもので、業界やコミュニティのデータ標準には準拠していません。
  • 一時ストア: データが処理され、ブロンズ レイクハウスのステージング テーブルからシルバー レイクハウスのフラット化および正規化されたデルタ テーブルに変換されると、ブロンズのステージング テーブル データはパージする準備ができていると見なされます。 このモデルは、コストとストレージの効率を確保し、ブロンズ レイクハウスのソース ファイルとステージング テーブル間のデータ冗長性を軽減します。

• シルバー レイクハウス: エンリッチ ゾーンとも呼ばれるシルバー レイクハウスは、ブロンズ レイクハウスからデータを精製します。 これには、検証チェックとエンリッチメント手法が含まれ、ダウンストリーム分析のデータ精度を向上させます。 ブロンズ レイヤーとは異なり、シルバー レイクハウスのデータは、決定論的な ID と変更タイムスタンプに基づくルールを使用して、レコードの挿入と更新を管理します。

• ゴールド レイクハウス: キュレーション ゾーンとも呼ばれるゴールド レイクハウスは、シルバー レイクハウスからのデータをさらに絞り込み、特定のビジネス要件と分析要件に対応します。 このレイヤーは、包括的な分析と分析情報の抽出の準備が整った高品質の集約データセットの主要なソースとして機能します。 医療データ ソリューションでは、展開ごとに 1 つのブロンズと 1 つのシルバー レイクハウスを展開しますが、複数のゴールド レイクハウスを持つことで、さまざまなビジネス ユニットやペルソナに対応できます。

• 管理レイクハウス: 管理レイクハウスには、BusinessEvent テーブルに格納されたグローバル構成と検証エラーなど、レイクハウス レイヤー全体のデータ ガバナンスとトレーサビリティのためのファイルが含まれています。 詳細については、管理レイクハウス を参照してください。

統合フォルダー構造

医療や生命科学のお客様は、さまざまなソース システムからの膨大な量のデータを、次のファイル形式を含む複数のデータ モダリティとファイル形式で処理します:

• 臨床モダリティ: FHIR NDJSON ファイル、FHIR バンドル、HL7。
• 画像モダリティ: DICOM、NIFTI、NDPI。
• ゲノミクス モダリティ: BAM、BCL、FASTQ、VCF。
• 請求: CCLF および CSV。

ここで:

• FHIR: 高速ヘルスケア相互運用性リソース
• HL7: Health Level Seven International
• DICOM: 医療におけるデジタル画像と通信
• NIFTI: Neuroimaging Informatics Technology Initiative
• NDPI: Nano-dimensional Pathology Imaging
• BAM: Binary Alignment Map
• BCL: ベース コール
• FASTQ:生物学的配列とそれに対応する品質スコアを保存するためのテキスト ベースの形式
• VCF Variant Call Format
• CCLF: 請求および請求明細フィード
• CSV: コンマ区切り値

Microsoft Fabric の OneLake は、組織に論理データ レイクを提供します。 Microsoft Fabric の医療データ ソリューションは、さまざまなモダリティや形式でデータを整理するのに役立つ統合フォルダー構造を提供します。 この構造により、ブロンズ レイクハウスのソース ファイル レベルとソース システム レベルでデータ系列を維持しながら、データ インジェストと処理が合理化されます。

最上位の 6 つのフォルダーには、次のものが含まれます:

• 外部
• 失敗
• 取り込み
• プロセス​​
• 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\DD
• Files\Process\[DataModality]\[DataFormat]\[Namespace]\YYYY\MM\DD

フォルダーの説明

• 名前空間 (必須): 受信ファイルのソース・システムを識別します。ソース・システムごとの ID の一意性を確保するために重要です。

• 取り込みフォルダー: ドロップ フォルダーまたはキュー フォルダーとして機能します。 このフォルダーでは、取り込むファイルを適切なモダリティおよび形式のサブフォルダーにドロップできます。 インジェストが開始されると、ファイルはそれぞれの プロセス フォルダー、あるいは失敗の場合には 失敗 フォルダーに転送されます。

• プロセス フォルダー: 各モダリティと形式の組み合わせ内で、正常に処理されたすべてのファイルの最終目的地。 このフォルダーは、処理日に基づいて YYYY/MM/DD パターンに従います。 フォルダーのパーティション分割は、Azure Data Lake Storage を使用するためのベスト プラクティス に準拠しており、整理、フィルター検索、自動化、および潜在的な並列処理が強化されます。

• 外部フォルダー: Bring Your Own Storage (BYOS) ショートカット フォルダーの親フォルダーとして機能します。 既定の展開では、請求、臨床、ゲノミクス、画像の各モダリティに対して示唆的なフォルダー構造を提供します。 画像モダリティと臨床モダリティには、Azure Health Data Services で DICOM および FHIR サービスをサポートするように構成された既定の形式と名前空間があります。 この形式は、データを OneLake にショートカットする場合にのみ適用されます。 Microsoft Fabric の医療データ ソリューションは、これらのショートカット フォルダー内のファイルに読み取り専用でアクセスできます。

• 失敗フォルダー: 取り込み または プロセス フォルダー内のファイルの移動または処理中にエラーが発生した場合、影響を受けたファイルは、モダリティと形式の組み合わせに対応する 失敗 フォルダーに移動します。 エラーは、管理レイクハウスの BusinessEvent テーブルに記録されます。 このフォルダーは、処理/失敗の日付に基づいて YYYY/MM/DD パターンを使用します。 このフォルダー内のファイルはパージされず、同じ初期インジェスト パターンを使用して修正し、再取得するまで、ここに残り続けます。

• サンプル データ フォルダー: 合成、参照、および/またはパブリックのデータセットが含まれます。 既定の展開では、展開後のノートブックとパイプラインの即時実行を容易にするために、いくつかのモダリティと形式の組み合わせに対してサンプル データが提供されます。 このフォルダーには、YYYY/MM/DD サブフォルダーは作成されません。

• 参照データ フォルダー: パブリックまたはユーザー固有のソースからの参照データセットと親データセットが含まれます。 このフォルダーには、YYYY/MM/DD サブフォルダーは作成されません。 既定の展開では、OMOP (Observational Medical Outcomes Partnership) ボキャブラリ用の推奨フォルダー構造が提供されます。

データ インジェスト パターン

前述の統合フォルダー構造に基づいて、Microsoft Fabric の医療データ ソリューションは 2 つの異なるインジェスト パターンをサポートします。 どちらの場合も、ソリューションは Spark の構造化ストリーミングを使用して、それぞれのフォルダー内の受信ファイルを処理します。

取り込みパターン

このパターンは、取り込むファイルを適切なモダリティ、形式、名前空間の下で 取り込み フォルダーにドロップするという単純なアプローチです。 インジェスト パイプラインは、新しくドロップされたファイルに対してこのフォルダーを監視し、処理のために対応する プロセス フォルダーに移動します。 ブロンズ レイクハウス ステージング テーブルへのファイル データのインジェストが成功すると、処理がいつ発生したかに基づいて YYYY/MM/DD パターンに従い、ファイルは圧縮され、タイムスタンプのプレフィックス付きで プロセス フォルダーに保存されます。 このプレフィックスにより、ファイル名が一意になります。 必要に応じて、圧縮を構成または無効にできます。

ファイル処理が失敗した場合、失敗したファイルは、モダリティとフォーマットの組み合わせごとに 取り込み フォルダーから 失敗 フォルダーに移動され、エラーが管理レイクハウスの BusinessEvent テーブルに記録されます。

このインジェスト パターンは、毎日の増分インジェストや、Azure Data Lake Storage または OneLake にデータを物理的に移動する場合に適しています。

Bring Your Own Storage (BYOS) パターン

データやファイルが Azure や他のクラウド ストレージ サービスにすでに存在し、それらのファイルへの既存のダウンストリーム実装や依存関係がある場合があります。 医療や生命科学の分野では、特に医療画像やゲノミクスなど、データ量が数テラバイトからペタバイトに達することがあります。 これらの理由により、直接的なインジェスト パターンは実現できない場合があります。

S3 プロトコルをサポートする Azure またはその他のクラウドおよびオンプレミスのストレージで既に大量のデータを利用できる場合は、履歴データ インジェストに BYOS パターンを使用することをお勧めします。 このパターンでは、Fabric の OneLake ショートカット とブロンズ レイクハウスの 外部 フォルダーを使用して、ソース ファイルのインプレース処理を有効にします。 これにより、ファイルを移動またはコピーする必要がなくなり、エグレス料金やデータの重複が回避されます。

BYOS インジェスト パターンによって効率性がもたらされますが、以下の点に注意する必要があります:

• インプレース ファイル更新 (ファイル内のコンテンツ更新) は監視されません。 インジェスト パイプラインは新しいファイルのみを監視するため、すべての更新に対して新しいファイル (別の名前) を作成する必要があります。 この制限は、Spark の構造化ストリーミングに関連しています。
• データ圧縮は適用されません。
• BYOS パターンでは、YYYY/MM/DD パターンに基づいて最適化されたフォルダー構造は作成されません。
• ファイル処理が失敗した場合、失敗したファイルは 失敗 フォルダーに移動されません。 ただし、エラーは、管理レイクハウスの BusinessEvent テーブルに記録されます。
• ソース データは読み取り専用であると見なされます。
• インジェスト後のソース データの系列や可用性を制御することはできません。

データ圧縮

Microsoft Fabric の医療データ ソリューションは、メダリオン レイクハウスの設計全体で設計による圧縮をサポートしています。 メダリオン レイクハウスを横断してデルタ テーブルに取り込まれたデータは、parquet ファイルを使用して圧縮された列形式で格納されます。 取り込みパターンでは、ファイルが 取り込み フォルダーから プロセス フォルダーに移動すると、処理が成功した後に既定で圧縮されます。 必要に応じて、圧縮を構成または無効にできます。 画像と請求の機能については、インジェスト パイプラインで ZIP 圧縮形式の raw ファイルを処理することもできます。

Healthcare Data Model

メダリオン レイクハウスの設計 で説明されているように、ブロンズ レイクハウスのステージング テーブルは、医療データ ソリューション専用のテーブルを内部的に実装し、業界やコミュニティのデータ標準には準拠していません。

シルバー レイクハウスの医療データ モデルは、FHIR R4 標準に基づいています。 データ アナリスト、データ サイエンティスト、開発者が協力して、患者の転帰とビジネス パフォーマンスを改善するデータ主導のソリューションを構築するための共通データ言語を提供します。 臨床、管理、財務、ソーシャルなど、さまざまな医療分野のデータをサポートします。 医療データ モデルは、FHIR 標準で定義されたデータをキャプチャし、レイクハウス内のテーブルと列を使用して FHIR リソースを組織化します。

FHIR データを delta parquet テーブルにフラット化することで、T-SQL や Spark SQL などの使い慣れたツールを使用して、データの探索と分析を行うことができます。 FHIR の範囲外の非臨床データについては、Azure Synapse データベース テンプレートのスキーマを使用します。 この実装により、患者エンゲージメント データなどの非臨床情報を患者プロファイルに統合できます。

シルバー レイクハウスの医療データ モデルは、部署や研究分野にまたがる医療データについてエンドツーエンドのエンタープライズ ビューを表すように設計されています。

データ系列とトレーサビリティ

レコードとファイル レベルで系列とトレーサビリティを確保するために、医療データ モデル テーブルには次の列が含まれています:

列	プロパティ
msftCreatedDatetime	レコードがシルバー レイクハウスで最初に作成されたときのタイムスタンプ。
msftModifiedDatetime	レコードに対する最終変更のタイムスタンプ。
msftFilePath	ブロンズ レイクハウスのソース ファイルへのフル パス (ショートカットを含む)。
msftSourceSystem	統合フォルダー構造 で指定された Namespace に対応する、レコードのソース システム。

フィールドが正規化、フラット化、または変更された場合、元の値は {columnName}Orig 列に保持されます。 たとえば、シルバー レイクハウスの 患者 テーブルには、次の列があります:

列	プロパティ
meta_lastUpdatedOrig	元の値を raw 形式 (文字列または日付) で保持し、datetime として格納します。
idOrigおよびidentifierOrig	シルバー レイクハウスで統一された ID と識別子。
birthdateOrigおよびdeceasedDateTimeOrig	元の日付値を異なるタイムスタンプ形式で保持します。

列がフラット化 (例: meta_lastUpdated) または文字列 (例: meta_string) に変換される場合は、アンダースコア (_) で始まるサフィックスを使用して示します。

更新処理

新しいデータがブロンズからシルバー レイクハウスに取り込まれると、更新操作によって、受信レコードとシルバー レイクハウスのターゲット テーブルが、リソースとテーブルの種類ごとに比較されます。 シルバー レイクハウスの FHIR テーブルの場合、この比較では、{FHIRResource}.id 値と {FHIRResource}.meta_lastUpdated 値の両方が、ClinicalFhir ブロンズ レイクハウス ステージング テーブルの id および lastUpdated 列と照合されます。

• 一致が識別され、受信レコードが新しい場合、シルバー レコードが更新されます。
• 受信レコードが古い場合、シルバー レコードは無視されます。
• 一致するものが見つからない場合は、新しいレコードがシルバー レイクハウスに挿入されます。

管理レイクハウス

管理レイクハウスは、Microsoft Fabric の医療データ ソリューションに関するクロス レイクハウス構成、グローバル構成、状態レポート、および追跡を管理します。

グローバル構成

管理レイクハウスの system-configurations フォルダーは、グローバル構成パラメーターを一元化します。 3 つの構成ファイルには、すべての医療データ ソリューション機能の既定の展開用に事前構成された値が含まれています。 機能のサンプル データまたはデータ パイプラインを実行するために、これらの値を再構成する必要はありません。

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: 画像モダリティ テーブルの Fabric パス(展開されている場合)。 •bronze_imaging_table_schema_path: 画像モダリティ スキーマの Fabric パス(展開されている場合)。 •omop_lakehouse_id:ゴールド レイクハウス識別子(展開されている場合)。
healthcare#_msft_fhir_ndjson_bronze_ingestion に関するアクティビティ	•source_path_pattern: プロセス フォルダーへの 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: 取り込んだ raw ファイルの拡張子。
healthcare#_msft_bronze_silver_flatten に関するアクティビティ	•source_table_name: ブロンズ レイクハウスの臨床インジェスト テーブルの名前。 •config_path: フラット化された構成ファイルへの OneLake パス。 •source_tables_path: ブロンズ レイクハウスのソース デルタ テーブルへの OneLake パス。 •target_tables_path: シルバー レイクハウスのターゲット デルタ テーブルへの OneLake パス。 •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 ショートカットを介して外部ストレージの場所から供給されるかどうかを決定するフラグ。 この場合、ファイルはほかの場合のように、プロセス フォルダーに移動されません。 •external_source_path: ブロンズ レイクハウスのショートカット 外部 フォルダーの OneLake パス。 •process_source_path: ブロンズ レイクハウスの プロセス フォルダーの 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: プロセス フォルダーへの OneLake パス。 •avro_schema_path: シルバー スキーマ フォルダーの OneLake パス。 •dicom_to_fhir_config_path: DICOM メタタグから FHIR ImagingStudy リソースに構成をマッピングするための OneLake パス。 •checkpoint_path: チェックポイント フォルダーの OneLake パス。 •max_records_per_ndjson: 各実行で 1 つの NDJSON ファイル内で処理されたレコードの数。 •subject_id_type_code: DICOM メタデータにおける患者の医療番号に対する値コード。 既定値は、FHIR の Medical Record Number に対応する、MR に設定されています。 •subject_id_type_code_system: DICOM メタデータにおける患者の医療番号に対するコード システム。 •subject_id_system: DICOM メタデータにおける患者の医療番号に対するコード システムのオブジェクト ID。
healthcare#_msft_omop_silver_gold_transformation に関するアクティビティ	•vocab_path: OMOP ボキャブラリ データセットが保存されているブロンズ レイクハウスにおける参照データ フォルダへの OneLake パス。 •vocab_checkpoint_path: チェックポイント フォルダーの OneLake パス。 •omop_config_path:シルバー レイクハウスからゴールド OMOP レイクハウスに構成をマッピングするための OneLake パス。

BusinessEvents テーブル

BusinessEvents デルタ テーブルは、インジェストおよび変換プロセス中に発生する可能性のあるすべての検証エラー、警告、およびその他の通知または例外をキャプチャします。 このテーブルは、システム ログ レベルだけでなく、ユーザー レベルと機能レベルの両方でインジェスト実行の進行状況を監視するために使用します。 たとえば、インジェスト中に検証エラーや警告が発生した raw ファイルを識別します。 システム レベルのログと、すべてのレイクハウスでの Apache Spark アクティビティの監視には、Azure Log Analytics を統合するオプションと共に Fabric 監視ハブ を使用できます。

次のテーブルに、BusinessEvent テーブルの列の一覧を示します:

列	プロパティ
id	テーブルの各行に対する一意識別子 (GUID)。
activityName	エラーや検証エラーまたは警告を生成したアクティビティ/ノートブックの名前。
targetTableName	イベントを生成したデータ アクティビティのターゲット テーブル。
targetFilePath	イベントを生成したデータ アクティビティのターゲット ファイルに対するパス。
sourceTableName	イベントを生成したデータ アクティビティのソース テーブル。
sourceLakehouseName	イベントを生成したデータ アクティビティのソース レイクハウス。
targetLakehouseName	イベントを生成したデータ アクティビティのターゲット レイクハウス。
sourceFilePath	イベントを生成したデータ アクティビティのソース ファイルに対するパス。
runId	イベントを生成したデータ アクティビティの実行 ID。
severity	イベントの重要度レベル。次の 2 つの値のいずれかになります: Error または Warning。 Error は、データ アクティビティを続行する前に、このイベントを解決する必要があることを示します。 Warning は受動的な通知として機能し、通常は即時のアクションを必要としません。
eventType	検証エンジンによって生成されたイベントと、ユーザーが生成した汎用イベント、またはユーザーが BusinessEvent テーブルに表示する未処理/システム例外を区別します。
recordIdentifier	ソース レコードの識別子。 この列は、BusinessEvents テーブルにおける各イベントの新しい一意識別子を表すため、id 列とは異なります。
recordIdentifierSource	ソース レコードの識別子に対するソース システム。 たとえば、ソース システムが EMR の場合、EMR 名または URL がソースとして機能します。
active	イベント (エラーまたは警告) が解決されたかどうかを示すフラグ。
message	イベント エラーまたは警告を説明するメッセージ。
exception	未処理/システム例外メッセージ。
customDimensions	検証または例外のソース データが、テーブルの個別の列ではない場合に適用されます。 たとえば、ソース データが 1 つの列内の文字列として保存された JSON オブジェクト内の属性である場合、完全な JSON オブジェクトがカスタム分析コードとして提供されます。
eventDateTime	イベントまたは例外が生成するタイムスタンプ。

データ検証

Microsoft Fabric における医療データ ソリューション内のデータ検証エンジンは、生データがブロンズ レイクハウスにインジェストされる前に、事前定義された基準を満たしていることを保証します。 検証ルールは、ブロンズ レイクハウス内のテーブルと列レベルで構成できます。 現在、これらのルールは、生ファイルからブロンズ レイクハウスのデルタ テーブルまで、インジェスト プロセス中にのみ実装されます。

生ファイルが処理されると、検証ルールがインジェスト レベルで適用されます。 検証には、Error と Warning の 2 つの重要度レベルがあります。 検証ルールが Error に設定されている場合、ルールに違反するとパイプラインは停止し、問題のあるファイルは 失敗 フォルダーに移動します。 重要度が Warning に設定されている場合、パイプラインは処理を続行し、ファイルは プロセス フォルダーに移動します。 どちらの場合も、エラーまたは警告を反映したエントリが、管理レイクハウス内の 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 パスを表すオプションの値。 この値は、検証のソース データが、テーブルの個別の列ではない場合に適用されます。 たとえば、ソース データが 1 つの列に文字列として格納されている JSON オブジェクト内の属性である場合、JSON パスはレコード識別子として機能する特定の属性に移動します。

関連情報

• Microsoft Fabric の医療データ ソリューションに関する概要
• Microsoft Fabric ソリューション アーキテクチャの医療データ ソリューションに関する概要