次の方法で共有


ヘルスケア データ ソリューションにおけるDICOMメタデータ変換 マッピング

この記事では、医療データ ソリューション環境がさまざまなレイクハウス レベルにわたって DICOM メタデータが抽出および変換する方法について説明します。 また、エンドツーエンドのメタデータ変換プロセスについて学習し、各レベルでの変換マッピングを理解することもできます。

画像インジェスト パイプラインによるメタデータ変換プロセスは、次の 3 つの連続したステージで構成されます:

  1. DICOM メタデータの抽出とブロンズ デルタ テーブルへの変換
  2. ブロンズからシルバー デルタ テーブルへのメタデータ変換
  3. シルバーからゴールド デルタ テーブルへのメタデータ変換

次のセクションでは、各ステージの変換マッピングについて詳しく説明します。

DICOM メタデータからブロンズ デルタ テーブルへの変換マッピング

ベンダー固有のプライベート タグを含め、DICOM 標準で定義される DICOM タグは 5000 を超えます。 このセクションでは、どのタグを取得するかを特定し、ブロンズのレイクハウスでの抽出プロセスについて説明します。

タグ抽出および ImagingDicom デルタ テーブル作成プロセスには、次のアクションが含まれます。

  1. DICOM ファイルからの抽出: ブロンズ レイクハウスの最適化されたフォルダー構造にある DICOM (DCM) ファイルからすべてのタグのコレクションを抽出します。

  2. ピクセル データ タグの除外: DICOM ピクセル データ タグ (7FE0,0010) と 画像ピクセル データ モジュール属性 をコレクションから除外します。 DICOM ピクセル データ タグには、画像/ピクセル レベルの詳細が含まれます。

  3. JSON マッピング: 抽出されたすべての DICOM タグを、次のスキーマのキーと値のペアの JSON 構造にマップします。

    METADATA_JSON_DICT_SCHEMA = MapType
       (
          StringType(),
          StructType([
                       StructField("vr", StringType(), True),
                       StructField("Value", ArrayType(StringType(), True), True)
                     ])
       )
    

    これらのキーと値のJSONペアは、bronzeレイクハウス ImagingDicom デルタ テーブルの メタデータ 列に書き込まれます。

    ヒント

    Fabric SQLエンドポイントは構造体、配列、マップなどの複雑なデータ型をサポートしていないため、 metadata_string 列にはメタデータも文字列として保存されます。 SQLエンドポイント (T-SQL) を使用してこれらの列を文字列としてクエリしたり、Sparkを使用してネイティブ タイプ (構造体、配列、マップ) を操作したりできます。

  4. 抽出と マッピング からブロンズ レイクハウス への変換: さらに次の29個のDICOMタグを抽出し、 ImagingDicom deltaテーブルの各宛先列に書き込みます。

    ソース DICOM タグ 宛先列 Required
    (0020,000D) [studyInstanceUid]
    (0010,0010) [patientName] いいえ
    (0010,0040) [patientSex] いいえ
    (0010,0020) [patientId]
    (0010,0030) [patientBirthDate] いいえ
    (0008,0050) [accessionNumber]
    (0008,0090) [referringPhysicianName]
    (0008,0020) [studyDate]
    (0008,1030) [studyDescription]
    (0020,000E) [seriesInstanceUid]
    (0008,0060) [modality]
    (0008,0061) [modalitiesInStudy]
    (0040,0244) [performedProcedureStepStartDate] いいえ
    (0008,1090) [manufacturerModelName] いいえ
    (0008,0018) [sopInstanceUid]
    (0008,0030) [studyTime]
    (0008,0201) [timezoneOffsetFromUtc]
    (0020,1206) [numberOfStudyRelatedSeries]
    (0020,1208) [numberOfStudyRelatedInstances]
    (0020,0011) [seriesNumber]
    (0008,103E) [seriesDescription]
    (0020,1209) [numberOfSeriesRelatedInstances]
    (0018,0015) [bodyPartExamined]
    (0020,0060) [laterality]
    (0008,0021) [seriesDate]
    (0008,0031) [seriesTime]
    (0008,0016) [sopClassUid]
    (0020,0013) [instanceNumber]
    (0042,0010) [documentTitle]

    ヒント

    • これらの特定の 29 個の DICOM タグをプロモートする理由の詳細については、DICOM タグ抽出を参照してください。

    • 取り込みパターン (追加) の詳細については、ブロンズ レイクハウスのパターンを追加するをご覧ください。

    • Fabric SQLエンドポイントは構造体、配列、マップなどの複雑なデータ型をサポートしていないため、 modalitiesInStudy_string 列には modalitiesInStudy タグも文字列として保存されます。 SQLエンドポイント (T-SQL) を使用してこれらの列を文字列としてクエリしたり、Sparkを使用してネイティブ タイプ (構造体、配列、マップ) を操作したりできます。

  5. DCMファイル パスの保存: DCMファイルの完全なファイル パスが、 filePath ImagingDicom デルタ テーブルの列に書き込まれます。

  6. 変更時間のログ記録: DCMファイルがソースで変更された最新のタイムスタンプが、 sourceModifiedAt ImagingDicom デルタ テーブルの 列に書き込まれます。

  7. 名前空間の保存: 名前空間の値は、 sourceSystem ImagingDicom デルタ テーブルの列に書き込まれます。 この値は、統合フォルダー構造内のフォルダー名から派生します。

    • 通常の取り込みの場合、名前空間の値は Files\Process\Imaging\DICOM の後のフォルダー名になります。
    • Bring Your Own Storage (BYOS) 取り込みの場合、名前空間の値は Files\External\Imaging\DICOM の後のフォルダー名になります。
  8. 実行時間のログ記録: ノートブックの実行日時が、 createdDatetime ImagingDicom デルタ テーブルの列に書き込まれます。

ブロンズからシルバー デルタ テーブルへの変換マッピング

次の表は、ブロンズ レイクハウス ImagingDicom デルタ テーブルからシルバー レイクハウス の ImagingMetastore および ImagingStudy デルタ テーブルへのDICOMメタデータの変換に関する完全な マッピング を説明しています。 ImagingMetastore デルタ テーブルには、各DCMファイルのDICOMタグがメタデータ列内のJSONキーと値のペアとして保存されます。 すべてのメタデータをブロンズからシルバーの レイヤー にコピーすると、レイヤー間でデータの整合性が維持されます。 ImagingStudy デルタ テーブルには、FHIR標準フィールドを持つ 位置合わせ 用に選択された29個のDICOMタグが含まれています。 また、データの追跡と系統をサポートするためのフィールドも追加されています。

ImagingDicomのソース列 ImagingMetastoreの宛先列 マッピング詳細
なし msftModifiedDatetime シルバー レイヤー 内のすべてのテーブルに適用される共通のデルタ マージ ロジックを通じて組み込まれます。
studyInstanceUid studyInstanceUid 1対1の関係でマッピングを直接操作します。 ソース列の各値は、宛先の対応する単一の値に直接マップされます。
seriesInstanceUid seriesInstanceUid 1対1の関係でマッピングを直接操作します。
sopInstanceUid sopInstanceUid 1対1の関係でマッピングを直接操作します。
sourceSystem msftSourceSystem 1対1の関係でマッピングを直接操作します。
metadata metadata 1対1の関係でマッピングを直接操作します。
metadata_string metadata_string 1対1の関係でマッピングを直接操作します。
filePath filePath 1対1の関係でマッピングを直接操作します。
sourceModifiedAt sourceModifiedAt 1対1の関係でマッピングを直接操作します。
なし id Python UUID モジュールを使用して生成された GUID。
なし msftCreatedDatetime シルバー レイヤー 内のすべてのテーブルに適用される共通のデルタ マージ ロジックを通じて組み込まれます。
ImagingDicomのソース列 ImagingStudyの宛先列 マッピング詳細
なし msftModifiedDatetime シルバー レイヤー 内のすべてのテーブルに適用される共通のデルタ マージ ロジックを通じて組み込まれます。
なし id Python UUID モジュールを使用して生成された GUID。
なし resourceType "ImagingStudy"
sourceSystem msftSourceSystem 直接的な マッピング ではありません。 DICOMデータ変換機能は、生成されたNDJSONファイルを sourceSystem Process フォルダーに書き込むときに、ブロンズ レイクハウス の 列を使用して Namespace フォルダーを作成します。 名前空間 フォルダーの詳細については、「 統合フォルダー構造: フォルダーの説明」を参照してください。 この段階では、臨床ブロンズ摂取サービスは、 名前空間 フォルダー名を使用して、シルバーの レイクハウス の msftSourceSystem 列に入力します。

たとえば、 sourceSystem 値が MyPACSsystem ブロンズ ImagingDicom テーブルで次のように定義されている場合、イメージングブロンズ取り込みサービスは、新しく作成されたNDJSONファイルを次のフォルダー構造に書き込みます: Process\Clinical\FHIR-NDJSON\MyPACSsystem\YYYY\MM\DD\ImagingStudy-<timestamp>.ndjson。 臨床ブロンズ取り込みがこれらのファイルを取得すると、フォルダー構造から msftSourceSystemMyPACSsystem が自動的に入力され、同じ値がシルバー レイヤー に伝播されます。
なし msftFilePath フォルダー内に生成された ImagingStudy NDJSONへのファイル パス。 Process\Clinical\FHIR-NDJSON\DICOM-HDS
filePath extension "extension": [{"url": "lit('file_path')", "valueUrl": "col('FilePath')"}]

FilePath の値は、この ImagingStudy の一部であるすべてのインスタンス レベルの DCM ファイルの OneLake の ABFS ファイル パスを含みます。
なし meta "meta": {"lastUpdated":"current_timestamp()"}
studyInstanceUid
accessionNumber
identifier ImagingStudy.identifier.where(system = 'urn:dicom:uid') =>StudyInstanceUID

ImagingStudy.identifier.where(type.coding.system = 'http://terminology.hl7.org/CodeSystem/v2-0203' および type.coding.code = 'ACSN')) =>"AccessionNumber"
なし status "available"
modalitiesInStudy modality modality = List{code = col('ModalitiesInStudy')}
patientId subject ""subject"": {""identifier"": {""type"": {""coding"": [{""system"": ""lit('http://terminology.hl7.org/CodeSystem/v2-0203')"",""code"": ""lit('MR')""}]},""value"": ""col('PatientID')""},""type": ""lit('Patient')""},"
patientName
patientBirthDate
patientSex
subject "subject": {"extension": [{"url": "lit('name')", "valueString": "col('PatientName')"}, {"url": "lit('birthDate')", "valueDateTime": "col('PatientBirthDate')"}, {"url": "lit('gender')", "valueCode": "col('PatientSex')"}]}
studyDate
studyTime
timezoneOffsetFromUtc
started concat_ws(' ', col('StudyDate'), col('StudyTime'), col('TimezoneOffsetFromUTC'))
numberOfStudyRelatedSeries numberOfSeries col('NumberOfStudyRelatedSeries')
numberOfStudyRelatedInstances numberOfInstances col('NumberOfStudyRelatedInstances')
studyDescription description col('StudyDescription')
seriesInstanceUid
seriesDate
seriesTime
timezoneOffsetFromUtc
modality
laterality
bodyPartExamined
numberOfSeriesRelatedInstances
seriesDescription
seriesNumber
sopInstanceUid
sopClassUid
instanceNumber
documentTitle
series {"series": [{"uid": "col('SeriesInstanceUID')", "started": {"tag": "SeriesDate,SeriesTime,TimezoneOffsetFromUTC", "calc": "concat_ws(' ', col('SeriesDate'), col('SeriesTime'), col('TimezoneOffsetFromUTC')).cast(TimestampType())"}, "modality": {"code": "col('Modality')", "system": "lit('https://dicom.nema.org/resources/ontology/DCM')"}, "laterality": {"display": "col('Laterality')"}, "bodySite": {"display": "col('BodyPartExamined')"}, "numberOfInstances": "col('NumberOfSeriesRelatedInstances')", "description": "col('SeriesDescription')", "number": "col('SeriesNumber')", "instance": [{"uid": "col('SOPInstanceUID')", "sopClass": {"code": "col('SOPClassUID')"}, "number": "col('InstanceNumber')", "title": "col('DocumentTitle')", "extension": [{"url": "lit('file_path')", "valueUrl": "col('FilePath')"}]}]}]}
なし meta.lastupdated Currenttimestamp()
なし msftCreatedDatetime シルバー レイヤー 内のすべてのテーブルに適用される共通のデルタ マージ ロジックを通じて組み込まれます。

ヒント

  • サフィックス Orig を持つ列は、シルバー レイクハウス に作成され、ブロンズ レイヤー から取得されたフィールドの元の値を保存します。 この標準的な方法では、 ImagingStudy テーブルに次の列が含まれます: meta_lastUpdatedOrigidentifierOrigidOrig、および startedOrig

  • _string サフィックスが付いた列には、複雑なJSONデータを含むフィールドの文字列化されたバージョンが格納され、SQL分析 エンドポイント を介したクエリが可能になります。 この方法は、シルバーの レイクハウス のすべてのテーブルに適用され、 ImagingStudy テーブルの次の列が含まれます: meta_stringtext_stringcontained_stringidentifier_stringmodality_stringsubject_stringencounter_stringbasedOn_stringreferrer_stringinterpreter_stringendpoint_stringprocedureReference_stringprocedureCode_stringlocation_stringreasonCode_stringreasonReference_stringnote_stringseries_string、および identifierOrig_string

  • ImagingStudy テーブルの一部フィールドは、FHIR ImagingStudy スキーマを使用して 位置を合わせる に生成されます。 ただし、ブロンズ レイヤー はこれらのフィールドに正確に対応するデータをDCMファイルから抽出しないため、シルバー テーブルの関連列は空のままになります。 その結果、 ImagingStudy テーブルの次の列にnull値が含まれます: implicitRuleslanguagetextcontainedencounterbasedOnreferrerinterpreterendpointprocedureReferenceprocedureCodelocationreasonCodereasonReferencenote

シルバーからゴールド デルタ テーブルへの変換マッピング

次の表は、シルバーの レイクハウス ImagingStudy デルタ テーブルのDICOMデータをゴールドの レイクハウス のObservational Medical Outcomes Partnership (OMOP) Image_Occurrence デルタ テーブルに変換するための完全な マッピング を説明しています。

ImagingStudyのソース列 OMOP Image_Occurrenceの宛先列 データ型 マッピング詳細
series.started image_occurrence_date 日にち 撮像手順 (シリーズ) 発生日。
series.modalityseries.modality.codeseries.modality.systemの組み合わせ) modality_concept_id string concat_ws('<->', exp_series.modality.code, exp_series.modality.system)
なし SourceTable string 'ImagingStudy_FHIR'
id msftSourceRecordId string ソース レコードのシステム生成ID。
identifier['studyInstanceUid'] image_study_uid string DICOM研究UID。
subject person_id 整数 記録されたプロシージャーに関連付けられた個人の個人 ID。
辞書の値の配列。キーは instance.uid 、値は instance.extension[0].valueUrl local_path string to_json(transform(exp_series.instance, x -> map('instanceid', x.uid, 'local_path', from_json(x.extension, 'array<struct<valueUrl:string,url:string>>')[0].valueUrl)))
なし SourceModifiedOn datetime レコードの変更日。
resourceType msftSourceTableName string 'Imaging Study'
msftModifiedDatetime msftModifiedDatetime datetime 1対1の関係でマッピングを直接操作します。
series.uid image_occurrence_id string 画像検査記録に付与される一意のキー。
series.modality.code modality_source_value string シリーズのモダリティ。

ヒント

ゴールド テーブルの一部のフィールドは、 OMOP Image_Occurrence スキーマを使用して 位置を合わせる に生成されます。 ただし、ブロンズの レイヤー はこれらのフィールドに正確に対応するデータを抽出しないため、ゴールド テーブル内の関連する列は空のままになります。 その結果、 Image_Occurrence テーブルの次の列にはnull値が含まれます: visit_occurrence_idprocedure_occurrence_id、および anatomic_site_concept_id