このページは Cloud Translation API によって翻訳されました。

FHIR インポートオプション

このページでは、大規模な FHIR データのバッチを Cloud Healthcare API に保存するオプションについて説明します。

FHIR リソースをインポートする

fhirStores.import メソッドを使用して、Cloud Storage から Cloud Healthcare API に FHIR リソースを読み込みます。このメソッドは、他のアプリケーションの干渉を受けることなく空の FHIR ストアにデータを読み込む場合に最適です。

fhirStores.import を呼び出すには、Cloud Storage を使用した FHIR リソースのインポートとエクスポートをご覧ください。

fhirStores.import メソッドを使用するかどうかを決定する際は、次のプロパティを考慮してください。fhirStores.import がアプリケーションに適していない場合は、fhir.executeBundle メソッドを使用してデータを読み込むことを検討してください。fhir.executeBundle を呼び出す方法については、FHIR バンドルを使用した FHIR リソースの管理をご覧ください。

fhirStores.import メソッドは、fhir.executeBundle の 50 MB の上限を超えるバンドルを受け入れます。ただし、バンドル内の各リソースのサイズは 10 MB に制限されています。
fhirStores.import を使用すると、次のような大規模な FHIR バンドルの実行における複雑さがなくなります。
- FHIR バンドルを小規模なバンドルに分割する
- 複数のバンドルのスケジュールを管理する
- リソースレベルまたはバンドルレベルで再試行される可能性のある一時的なエラーを管理する
多くの場合、このようなメリットはバンドルを使用するメリットを上回ります。
入力の各リソースには、クライアントが提供する ID を含める必要があります。各リソースは、FHIR ストアへの enableUpdateCreate 設定に関係なく、指定された ID を使用して保存されます。
インポートプロセスでは、FHIR ストアの disableReferentialIntegrity 設定に関係なく、参照整合性が適用されません。参照整合性が適用されないと、グループ化や順序付けを考慮することなく、任意の相互依存関係を持つリソースをインポートできます。入力データに無効な参照が含まれている場合や、一部のリソースをインポートできない場合は、FHIR ストアの状態が参照整合性に違反している可能性があります。
任意の ID のリソースがすでにストアに存在する場合、新しい履歴バージョンを作成せずにリソースの直近のバージョンが上書きされます。この上書きは、FHIR ストアの disableResourceVersioning 設定に関係なく行われます。インポート中に一時的なエラーが発生した場合は、正常にインポートされたリソースが複数回上書きされる可能性があります。
ID が同じで、コンテンツが異なる複数の有効なリソースが入力データに含まれていない場合、インポートオペレーションはべき等です。この場合、インポートが完了すると、ストアには各 ID を持つリソースが 1 つだけ含まれます。ただし、重複するエントリにはあらゆるバージョンのコンテンツを含めることができます。たとえば、同じ ID を持つ 100 万件のリソースをインポートすると、1 つのリソースだけがストアに書き込まれます。
オペレーションの結果カウンタでは、重複 ID がエラーとして計上されません。入力内の各リソースは 1 回の成功として計上されます。その結果、FHIR ストアのリソース数よりも成功数が大きくなる場合があります。これは、多くの場合、Patient-everything により生成されたバンドルに整理されたデータのインポート時に発生し、各バンドルには、多くの患者リソースが参照する可能性のあるリソースの独自のコピー（Practitioner など）が含まれています。
解析エラーなどによりリソースをインポートできない場合、正常にインポートされたリソースはロールバックされません。たとえば、100 個のリソースのうち 5 個をインポートできない場合、残りの 95 個のリソースが FHIR ストアにインポートされます。
BUNDLE 形式を使用する場合、インポートメソッドは history の Bundle.type を持つバンドルを拒否します。インポートメソッドは、バッチまたはトランザクションバンドルにバンドル処理セマンティクスを適用しません。fhir.executeBundle とは異なり、トランザクションバンドルは単一のトランザクションとして実行されず、バンドル内部の参照は書き換えられません。バンドルは、Bundle.entry.request を無視して、Bundle.entry.resource で提供されるように書き込まれるリソースのコレクションとして扱われます。たとえば、FHIR 検索または Patient-everything オペレーションによって生成された検索セットバンドルをインポートできるようになります。

FHIR バンドルを使用する

FHIR バンドルの概要については、FHIR バンドルをご覧ください。

FHIR バンドルを使用するケース

fhir.executeBundle メソッドを FHIR リソースの保存に使用するかどうかを決定する際は、次の特性と利点を考慮してください。

課金やネットワーク帯域幅の点でコストが高すぎる場合は、Cloud Storage にデータを保存してから、fhirStores.import を使用してデータをインポートするパイプラインをビルドするために、fhir.executeBundle を使用します。
バンドルを実行するときに、トランザクションの整合性を適用できます。
バンドルを実行するときに、FHIR プロファイル検証を適用できます。
FHIR の作成、更新、削除オペレーションが発生したときに Pub/Sub 通知を送信する必要がある場合は、fhir.executeBundle を使用します。fhirStores.import を使用して FHIR リソースがインポートされた場合、Pub/Sub 通知は送信されません。
特定の FHIR リソースを処理しなければならない時間が秒単位または分単位である場合は、fhir.executeBundle を使用します。特定の FHIR リソースを処理しなければならない時間が時間単位または日単位である場合は、fhirStores.import を使用します。
Google Cloud プロジェクトに、他のタスクを実行する既存の長時間実行オペレーション（LRO）が多数存在する場合、fhirStores.import よりも fhir.executeBundle を使用すると、パフォーマンスが向上する場合があります。
fhirStores.import オペレーションを管理するアプリケーションに、以下を行うための適切な戦略がない場合は fhir.executeBundle を使用します。
- エラーの一括処理
- FHIR リソースのサブセットまたはバッチ全体のエラー処理

FHIR バンドルを使用すべきでないケース

fhir.executeBundle を FHIR リソースの保存に使用するかどうかを決定する際は、次の制限事項を考慮してください。

バンドルでは、バンドル外でオペレーションが実行される場合と同様の割り当てと請求が、バンドル内のオペレーションに適用されます。たとえば、バンドルに 10 個の POST オペレーション、5 個の GET オペレーション、1 個の DELETE オペレーションがある場合、バンドルに適用される割り当てと請求はそれらのオペレーションが個別に実行された場合と同様のものになります。

そのため、fhirStores.import ではなくバンドルを使用しても、割り当ての上限と FHIR オペレーションコストの節約にはなりません。
大規模なトランザクションバンドルでは、トランザクション競合が発生し、データ競合やオペレーションの失敗につながる可能性があります。これらの問題が発生する原因と解決方法については、429 Resource Exhausted operation_too_costly エラーを防ぐをご覧ください。
一括バンドルを使用して高いデータスループットを達成し、維持できます。これにより、データ競合を回避できます。ただし、バッチバンドルには、参照整合性などのトランザクション整合性機能はありません。
バンドルサイズが大きい場合は、バッチバンドルであっても、データスループットが低下する可能性があります。詳細については、大規模なトランザクションバンドルを回避するをご覧ください。