翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
データ変換機能
以下の各機能は、その機能、仕組み、C-CDA ソースと CSV ソースの違い、使用時期とともに文書化されています。
変換プロファイルとバージョニング
変換プロファイルは、ソース形式が FHIR R4 にどのように変換されるかを再利用可能な定義です。変換ロジック (C-CDA の速度テンプレート、CSV の YAML マッピング設定) を保持し、一度作成され、アカウント内のすべてのデータストアと変換ジョブで再利用されます。定義 (プロファイル) を実行 (ジョブ) から分離すると、変換を一度作成してテストし、同じ公開バージョンを任意の数のジョブに適用できます。
プロファイルの作成
プロファイルは、次の 3 つの方法のいずれかで作成します。
-
スターターまたはベースプロファイルから: 空のプロファイルではなく、作業プロファイルから開始します。C-CDA の場合、 AWS スタータープロファイルは事前構築済みの AWS 定義プロファイルで、一般的な C-CDA ドキュメント形式をすぐに処理できます。CSV の場合、プロファイルの作成時に Amazon S3 でサンプルファイルを指定し、AI エージェントを呼び出して分析し、YAML マッピング設定を生成します。
-
クローン作成: 既存のプロファイルを新しいプロファイルの開始点としてクローンします。
-
raw マッピングから: Velocity テンプレート (C-CDA) または YAML マッピング (CSV) を直接指定します。これは、CI/CD パイプラインを介してバージョン管理プロファイルをデプロイするためのパスです (「」を参照SDK と の開始方法 AWS CLI)。
重要
SampleData で CSV プロファイルを作成すると、サンプルの場所が登録されますが、AI エージェントは実行されません。YAML マッピングを生成するには、作成後に UpdateProfileWithAgent を呼び出す必要があります。エージェントはその時点でサンプルファイルを分析し、ベースプロファイルを生成します。
バージョンライフサイクル
プロファイルには、最大 1 つのドラフトと最大 99 の公開バージョンを含めることができます。
-
新しいプロファイルはドラフト (バージョン 0) として始まります。これは、自由に編集できる変更可能な作業コピーです。
-
ドラフトを発行すると、変更不可能な番号付きバージョン (v1、v2 など、v99 まで) が作成されます。公開されたバージョンは変更されません。
-
変換ジョブは、常に最新の公開バージョンに対して実行されます。ドラフトは別個であるため、本番稼働用ジョブが最後に公開されたバージョンに対して引き続き実行される間は編集を続けることができます。進行中の編集は、実行中の変換には影響しません。
-
公開されたバージョン以降の未公開の編集があるプロファイルは、未公開の変更状態になります。公開されたバージョンは、再度公開するまでライブのままになります。
比較とロールバック
公開されたバージョンはすべて保持されるため、バージョン履歴で変換ロジックがどのように変更されたかを正確に確認できます。ロールバックしても何も削除されません。以前のスナップショットから新しいバージョンが作成されるため、完全な履歴と監査証跡が保持されます。
バージョニングを使用するタイミング
本番稼働用ジョブを実行する前にバージョンを発行し、ジョブがレビューロジックに固定されるようにします。変更が予期しない出力を生成する場合はロールバックを使用し、変更が実際にどのような変更を行ったかを比較して確認します。
データ変換 AI エージェント
データ変換 AI エージェントは、FHIR マッピングの作成と保守の手動作業を排除します。変換ロジックを手動で記述する代わりに、必要な結果を記述し、エージェントが基盤となるロジックである CSV の YAML マッピング設定である C-CDA の速度テンプレートを生成または更新します。エージェントは のプロファイルエディタに埋め込まれ AWS Management Console ており、UpdateProfileWithAgent API および MCP ツールとしても使用できるため、、コード AWS Management Console、または MCP 互換 IDE から操作できます。
エージェントが行うこと
-
データから変換ロジックを生成します。CSV の場合、エージェントはプロファイルの作成時に指定したサンプルファイルを分析してベースプロファイル を生成します。ターゲットの FHIR リソースとフィールドを推測するため、空白のプロファイルではなく作業中のドラフトから開始します。C-CDA では、スタータープロファイルを AWS ドキュメントに合わせて調整します。
-
自然言語からの変換ロジックを編集します。プレーン言語の変更を記述すると、エージェントは基盤となるテンプレートまたはマッピングを更新します。例えば、次のようになります。
-
「薬剤リソースのマッピングを追加します」
-
「患者の希望する言語を languageCommunication セクションからマッピングします。」
-
「患者リソースのデフォルト状態をワシントンに設定します。」
-
「RACE_CD 列を FHIR 拡張機能にマッピングします」
-
「ステータスがentered-in-error。」
-
-
適用する前に説明とレビューを行います。エージェントは、提案された変更を、影響を受けるテンプレートまたはマッピングの相違点として提示し、承認後にのみ適用します。公開されたプロファイルでは何も変更されず、エージェントはドラフトバージョンのみを変更します。
-
反復的に絞り込みます。複数のターンにわたってエージェントと連携して、変換された出力が正しいまでマッピングを調整し、同期変換 API でターン間のサンプルデータに対する結果をプレビューします。
C-CDA ワークフロー (速度テンプレート)
エージェントは、C-CDA セクションが FHIR リソースにどのようにマッピングされるかを定義する Velocity テンプレートを編集します。リソースマッピングの追加、セクションの解釈方法の変更、デフォルト値の設定、ドキュメントのバリエーションの処理を依頼し、テンプレートを更新して差分を返します。公開する前に、サンプルの C-CDA ドキュメントに対して変換をプレビューします。
CSV ワークフロー (YAML マッピング)
サンプルファイルを使用して CSV プロファイルを作成し、エージェントを呼び出すと、ファイルのヘッダー、サンプル値、データパターンを分析し、以下を含む YAML マッピング設定を提案します。
-
column-to-FHIR フィールドマッピング、
-
日付形式の検出と FHIR 日付/時刻形式への再フォーマット
-
値変換 (M → 男性、INPATIENT → IMP など）、
-
テーブル間のプライマリ/外部キー関係、
-
子テーブルの行を親リソースの FHIR 配列に分割する集計ルール。
-
エージェントが行った仮定とデータに関する質問。
提案された各マッピングを承認、拒否、または絞り込み、エージェントにさらなる調整を求めることができます。エージェントは、完全なデータセットではなくファイルのサンプルからマッピングを推測するため、データを表すサンプルを提供し、大規模な変換前に提案されたマッピングを確認します。
エージェントが受け入れる入力
自然言語入力でエージェントと通信できます。組み合わせには、次のようなものがあります。
-
手順、
-
サンプルソースデータ (C-CDA セクションまたは CSV スキーマ)
-
スキーマドキュメント、
-
以前の変換からの FHIR 検証エラー。
手動編集
エージェントを使用する必要はありません。Velocity テンプレートと YAML マッピングはいつでも直接編集でき、手動編集を同じプロファイルのエージェント作成の変更と組み合わせることができます。
同期 (リアルタイム) 変換とプレビュー
同期変換は単一の入力を変換し、Amazon S3 経由で非同期ジョブを実行するのではなく、すぐに FHIR 結果を返します。プロファイルの作成中にプロファイルをテストし、リクエスト/レスポンスフローで小規模なインタラクティブ変換を実行するという 2 つの目的があります。
仕組み
-
プロファイルに対して 1 つの入力 (C-CDA ドキュメントまたは一連の CSV ファイル) を送信し、変換された FHIR リソースを FHIR バンドルとしてレスポンスで受け取ります。
-
オペレーションは REST API を介してのみ使用できます。 AWS CLI または SDK コマンドとして公開されません。「データ変換エージェントへのアクセス」を参照してください。
-
同期呼び出しでドリフト検出を有効にするには、DriftDetectionEnabled を true に設定して、レスポンスでプロファイルがまだキャプチャしていないソース要素を確認できます。マッピングの反復に役立ちます。
サイズ制限
同期変換は、リクエストごとに最大 1 MB の C-CDA 入力と最大 1 MB の CSV 入力の組み合わせを受け入れます。大規模なデータセットの場合は、一括変換ジョブを使用します。
の「プレビュー AWS Management Console」
でプロファイルを作成すると AWS Management Console、同期変換によってライブプレビューが強化されます。一方の側にはソース、もう一方には変換された FHIR 出力が表示され、マッピングを絞り込むとプレビューが更新されます。公開する前に出力が正しいことを確認するために使用します。
同期とバルクを使用するタイミング
同期変換を使用して、代表的なドキュメントに対してプロファイルを検証し、到着時にドキュメントを変換するライブフィードなど、リクエストごとにレイテンシーの影響を受けやすい変換を検証します。大規模なデータセットと HealthLake データストアに直接取り込むには、一括変換ジョブ (以下) を使用します。
一括 (非同期) 変換ジョブ
一括変換ジョブは、公開されたプロファイルを使用して Amazon S3 から大きなデータセットを変換し、進行状況のモニタリング中に非同期的に実行されます。これは、移行と HealthLake データストアへのデータのロードの本番パスです。IAM アクセス許可の設定については、このページを参照してください。
仕組み
-
ソースファイルの Amazon S3 プレフィックスにジョブをポイントし、公開されたプロファイルを選択し、出力先を選択します。ジョブは入力をスキャンし、各ファイル (C-CDA) または行のセット (CSV) を変換し、結果を書き込みます。
-
プロビジョニングするインフラストラクチャはありません。ジョブは自動的にスケーリングされます。
出力モード
-
スタンドアロン: 変換された FHIR を Amazon S3 の場所に書き込みます。StartDataTransformationJob API を使用します。
-
複合 (変換および取り込み): ソースファイルを変換し、結果の FHIR リソースを 1 つのステップで HealthLake データストアに直接取り込むため、データはすぐにクエリできます。ProfileId、InputFormat、およびオプションで DriftDetectionEnabled パラメータで StartFHIRImportJob API を使用します。データストアは ACTIVE 状態である必要があります。完全な例については、「ステップ 7: HealthLake データストアに変換して取り込む」を参照してください。
猶予的な障害処理
不正な形式の入力はバッチに失敗するのではなくスキップされてログに記録されるため、1 つの不正なファイルが大きなジョブを停止することはありません。失敗した入力は、入力ファイルパスとエラーメッセージを含む JSON エラーファイルとして書き込まれるため、確認して再処理できます。
出力レイアウト
サービスは、ジョブ ID を使用して、出力 Amazon S3 URI の下にジョブスコープフォルダを作成します。そのフォルダ内:
-
converted/: FHIR NDJSON 出力ファイル (入力ファイルごとに 1 つ。例: converted/patient-record.ndjson)。
-
ERROR/: 失敗した入力のエラーの詳細 (inputFile フィールドと errorMessage フィールドを含む JSON ファイル、例: ERROR/bad-file.json)。
-
Manifest.json: 集計メトリクス (スキャン、変換、失敗、生成されたリソース) を含むジョブの概要。
-
jobLevelDriftResult.json: ドリフト検出が有効になっている場合のジョブの集計ドリフトレポート。
-
driftDetectionPerFileResults/: ドリフト検出が有効になっている C-CDA ジョブの場合、ファイルごとのドリフトレポート (driftDetectionPerFileResults/patient-record_driftMetrics.json など）。これにより、ジョブレベルの集計だけでなく、個々のソースファイルのカバレッジを検査できます。
モニタリング
ジョブの詳細ページまたは DescribeDataTransformationJob API を使用して実行中の AWS Management Console ジョブを追跡します。ステータス、処理されたファイル (CSV の行）、生成されたリソース、および失敗です。ジョブメトリクスとログは Amazon CloudWatch でも使用できます。
検証
データ変換エージェントは変換ライフサイクルの複数の時点で検証するため、問題は変換の失敗や非準拠の出力になる前に検出されます。
-
ソース検証: は、C-CDA 入力が適切な形式であり、C-CDA 仕様に準拠していることを確認します。エラーには場所の詳細と修復ガイダンスが含まれるため、大規模なジョブを実行する前にソースの問題を修正できます。ValidateSource オペレーションは、REST API を介して事前に入力をスクリーンできます。
-
テンプレート/マッピングの検証: は、プロファイルの Velocity テンプレート (C-CDA) または YAML マッピング (CSV) をデータとは無関係に検証するため、ジョブを公開または実行する前に変換ロジックの形式が適切であることを確認します。
-
出力 FHIR 検証: 生成されたリソースが FHIR R4 に準拠していることをチェックするため、ダウンストリーム FHIR APIsとデータストアは出力を受け入れます。
これらを合わせると、回避可能な理由でジョブが失敗する頻度が低くなります。ソース検証は不正な入力をキャッチし、マッピング検証は不正なロジックをキャッチし、出力検証は結果が標準に準拠していることを確認します。
OID-to-URIマッピング
C-CDA ドキュメントOIDs (オブジェクト識別子) を使用してコードシステムを識別します。これは2.16.840.1.113883.6.1、 (LOINC) などのレガシー数値識別子です。FHIR は、 などの最新のシステム URIshttp://loinc.org。OIDs がマッピングされていない場合、結果のシステム値は相互運用できず、ダウンストリームの FHIR ツールではコードを解決できません。データ変換エージェントは、変換中にそれらをマッピングします。
-
構築済みマッピング: 一般的な医療 OIDs (LOINC、SNOMED CT、ICD-10、RxNorm など) のマッピングは、設定なしで自動的に適用されます。
-
カスタムマッピング: ソースに固有のコードシステムに独自の OID-to-URIへのマッピングを追加するため、独自のシステムまたはローカルシステムが正しく解決されます。
これは、OIDs がコードシステムを識別するネイティブな方法である C-CDA ソースに適用されます。
プロビナンス
規制されたヘルスケアワークフローは、「このデータはどこから来たのか、どのように生成されたのか」と答える必要があります。任意のリソースの 。ジョブで出典を有効にすると、データ変換エージェントは変換ごとに FHIR Provenance リソースを生成し、各出力リソースにクエリ可能な完全な系統をソースに戻します。
出典チェーン
Provenance → DocumentReference → ソースファイル。Provenance リソースは、ソースファイルの Amazon S3 URI と SHA-1 チェックサムを記録する DocumentReference を参照します。チェックサムを使用すると、出力が特定の変更されていないソースファイルから派生したことを証明できます。その情報が必要な場合は、 AWS HealthLake データ変換をエンティティとして表すデバイスリソースも提供されます。
レコードレベルのロケーター
Provenance はソースファイルだけでなく、その中の正確な場所に解決され、ロケーターはソース形式によって異なります。
-
C-CDA: リソースが派生したソース要素を指す XPath。
-
CSV: ソースレコードのテーブル名、プライマリキー、行番号。
キャプチャされたフィールド
各 Provenance リソースは、ソースファイルの URI とチェックサム、変換に使用されるプロファイルバージョン、タイムスタンプ、およびレコードレベルのロケーターを記録します。
準拠と使用
Provenance リソースは US Core Provenance プロファイルに準拠しているため、米国 Core 対応ツールと相互運用されます。コンプライアンスの監査可能性が必要な場合、または疑わしい出力リソースを生成した正確なソース要素まで追跡する必要がある場合は、出典を有効にします。Provenance はデフォルトで有効になっています。ProvenanceEnabled を false に設定して無効にします。
ドリフト検出
変換は、プロファイルがまだマッピングしていないソースデータをサイレントに削除している間に成功する可能性があります。そのギャップがあるドリフト検出面。これはレポートです。有効にすると、ソースに含まれるものとプロファイルが実際に生成したものを比較し、残ったものを記録します。
レポートの内容
-
変換の全体的なカバレッジレート。
-
マッピングされていないソースセクションと要素のランク付けされたリスト。最も影響の大きいギャップを優先できます。
-
生成されなかった予想されるリソース。
-
ソースファイルと要素の場所 (C-CDA の場合はファイル名と OID、CSV の場合は行) への完全なトレーサビリティ。
ドリフト検出の使用方法
ドリフト検出は両方の変換モードで利用できるため、1 つのファイルで反復処理するか、データセット全体を検証するかに関係なく使用できます。
-
同期 (リアルタイム): TransformData リクエストで DriftDetectionEnabled を true に設定して、単一のファイルでドリフト検出を実行し、結果を API レスポンスに返します。これは、プロファイルの作成中にカバレッジを確認する最も速い方法です。1 つの代表的なドキュメントを変換し、プロファイルが見逃した内容を正確に確認し、マッピングを絞り込んで、もう一度試してください。
-
一括 (非同期): 変換ジョブでドリフト検出を有効にして、データセット全体のカバレッジを測定します。レポートは、ジョブの Amazon S3 出力場所に jobLevelDriftResult.json として書き込まれます。 Amazon S3 C-CDA ジョブの場合、ファイルごとのドリフトレポートは driftDetectionPerFileResults/ フォルダにも書き込まれるため、個々のソースファイルのカバレッジギャップを特定できます。
MCP アクセス
Model Context Protocol (MCP) は、データ変換エージェントを呼び出し可能なツールとして IDE ベースの AI エージェントに公開するため、デベロッパーは に切り替えることなく、IDE のアシスタントからプロファイルの作成、変換の実行、障害の調査を行うことができます AWS Management Console。
-
プロファイルとジョブ管理 APIs: すべての Data Transformation Agent プロファイルとジョブ管理 APIsは MCP ツールとして利用できるため、任意の MCP 互換クライアントからジョブを作成、編集、公開、実行できます。
-
任意の MCP クライアント: Kiro や Cursor などの MCP 互換 IDEs とアシスタントで動作します。
-
耐久性のあるセッション: はマルチターンセッションをサポートしているため、デバッグまたは作成会話にはコンテキストが保持されます。
注記
同期変換オペレーション (TransformData) とソース検証 (ValidateSource) は REST 専用であり、MCP ツールとして表示されない場合があります。エージェントはユーザーに代わって REST 呼び出しを構築して実行できます。「ステップ 3: リクエスト形式の同期変換でテストする」を参照してください。
MCP はプロファイルおよびジョブオペレーションの AWS CLI および SDKs と同じ API 表面を共有するため、IDE での作業とコードまたは での作業の間に、これらのワークフローの機能ギャップはありません AWS Management Console。セットアップとワークフローの例MCP の開始方法については、「」を参照してください。
