Cloud Healthcare API は、さまざまな理由でリソースの使用を制限しています。たとえば、割り当て量を制限して予期しない使用量の急増を防ぐことで Google Cloud ユーザーのコミュニティを保護しています。Google Cloud では無料トライアルの割り当ても用意しています。この割り当て量制限により、Google Cloud（Cloud Healthcare API を含む）を試しているユーザーは、制限付きでアクセスできます。
Cloud Healthcare API の割り当ては、リージョン単位とマルチリージョン単位のいずれかでプロジェクトによって適用されます。単一のリージョンの割り当てが枯渇しても、他のリージョンでの Cloud Healthcare API の使用には影響しません。
割り当てと使用量を確認する
割り当てとは、ストレージの上限（上り上限とも呼ばれる）とオペレーションの制限のことです。
プロジェクトで利用できるリソースの割り当て量は、Google Cloud コンソールの [割り当て] ページで確認できます。
Cloud Healthcare API の割り当てのみを表示するには、[テーブルをフィルタリング] プルダウン リストから [サービス] を選択し、[Cloud Healthcare API] を選択します。
割り当て量はすべてのプロジェクトで同じとは限りません。Cloud Healthcare API の使用が多くなるに伴い、割り当てが増加する可能性があります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの [割り当て] ページから割り当て量の調整をリクエストできます。割り当ての増加リクエストを行っても課金されません。料金が発生するのは、リソースの使用量が増えたときのみです。
リソースの上限
Cloud Healthcare API は、リクエストのコンテンツのサイズを制限します。たとえば、DICOM リクエストの X 線画像のサイズなどが制限されます。リソース上限の変更はリクエストできません。ただし、状況によっては、インポート オペレーションを使用して、リソース上限よりも大きなコンテンツをインポートできます。
以下のリソース上限が適用されます。また、これらは変更される可能性があります。
| モダリティ | リクエスト サイズの上限 |
|---|---|
| DICOM |
|
| FHIR |
|
| HL7v2 | 10 MB |
関連するリソース上限を超えるコンテンツを処理しようとすると、エラーが発生します。
FHIR executeBundle のサイズの上限
fhir.executeBundle メソッドを使用すると、1 つの API リクエストで複数の FHIR オペレーションを実行できます。オペレーションの数は、バッチまたはトランザクション バンドルのエントリ数によって異なります。この方法は、オペレーションごとに個別の API 呼び出しを行うよりも効率的です。
fhir.executeBundle リクエストの処理時間は、バンドルのエントリ数に応じて増加します。リソース競合（多くのトランザクション バンドルの一部として同じリソースを並行して更新するなど）などの要因もパフォーマンスに影響する可能性があります。リソース競合が発生するタイミングと、エラーの発生を防ぐ方法については、データ スループットに関するベスト プラクティスをご覧ください。大きなバンドル（特に 1,000 件を超えるエントリを含むバンドル）は、タイムアウトして完了できない場合があります。
処理が正常に行われ、処理が遅れないようにするには、fhir.executeBundle リクエストを送信する際に次の上限を考慮してください。
- トランザクション バンドル: タイムアウトを防ぐため、エントリ数が 4,500 を超えるバンドルは直ちに拒否されます。トランザクション バンドルでは、すべてのオペレーションが成功する必要があります。
- バッチバンドル: エントリ数の上限はありませんが、バンドルが大きいほどタイムアウトのリスクが高くなります。タイムアウトが発生すると、一部のエントリのみが処理され、処理が部分的に成功することがあります。
リソース上限を超えるコンテンツへのインポート オペレーションの使用
インポート オペレーションにより、関連するリソース上限を超えるコンテンツを処理できます。インポート オペレーションのコンテンツ サイズは、個々のオブジェクトに対する Google Cloud の最大ストレージ サイズである 5 TB によってのみ制限されます。インポート オペレーションは、インポート オペレーションにかかる時間を決定するストレージの割り当てに影響を受けます。たとえば、DICOM ストアに多くの DICOM インスタンスを格納する必要があり、リクエスト サイズの上限による影響を受けたくない場合は、インポート オペレーションを使用することをおすすめします。利用可能なストア トランザクション メソッドを使用してインスタンスをアップロードする代わりに、インスタンスを Cloud Storage バケットにアップロードしてから、DICOM ストアにインポートできます。
インポート オペレーションを使用して DICOM データをインポートするための詳細な手順については、DICOM データのインポートとエクスポートを参照してください。
インポート オペレーションを使用して FHIR リソースをインポートするための詳細な手順については、FHIR リソースのインポートとエクスポートを参照してください。
インポート オペレーションを使用して HL7v2 メッセージをインポートするための詳細な手順については、Cloud Storage から HL7v2 メッセージをインポートするをご覧ください。
割り当ての変更をリクエストする
割り当て量の変更をリクエストするには、serviceusage.quotas.update 権限が必要です。この権限は、事前定義ロール（オーナー、編集者、割り当て管理者）にはデフォルトで含まれています。
[割り当て] ページに移動します。
[割り当て] ページで、変更する割り当てを選択します。Cloud Healthcare API の割り当てのみを表示するには、フィルタ テーブルプルダウン リストからサービスを選択し、次に Cloud Healthcare API を選択します。
編集する割り当てのチェックボックスをオンにします。
ページ上部にある [割り当てを編集] ボタンをクリックします。
フォームに記入し、[次へ] をクリックします。
リクエストする上限を入力し、[次へ] をクリックします。
[リクエストを送信] をクリックします。
割り当てを減らすリクエストは、デフォルトでは拒否されます。割り当て量を減らしたい場合は、要件の説明を記載してサポートメールに返信してください。サポート担当者が対応いたします。
リクエストの送信後、24～48 時間以内に Cloud Healthcare API チームから返信いたします。
リクエストの完了に十分な時間が確保されるように、少なくとも数日前に追加のリソースを計画してリクエストしてください。
位置情報の割り当てリクエスト
Cloud Healthcare API の割り当て増加は、特定のリージョンまたはマルチリージョン ロケーションでリクエストできます。
1 つのリージョンで割り当ての増加をリクエストするには、割り当ての増加リクエストでリージョンを指定します。
マルチリージョンのロケーションで割り当ての増加をリクエストするには:
usマルチリージョンの割り当てを増やす場合は、割り当てが「US メタ リージョン」向けであることをリクエストに記載します。euマルチリージョンの割り当てを増やす場合は、割り当てが「EU メタ リージョン」向けであることをリクエストに記載します。
割り当て上限
以降のセクションでは、Cloud Healthcare API のデータストアとオペレーションに関連する割り当てについて説明します。
DICOM の割り当て
次の表に、DICOM ストアと DICOM オペレーションに関連付けられた Cloud Healthcare API の割り当てを示します。
| 指標名 | 表示名 | 説明 |
|---|---|---|
dicomweb_ops |
1 分間、1 リージョンあたりの DICOMweb オペレーション数 | 以下のメソッドが含まれます。
|
dicom_structured_storage_bytes |
1 分間、1 リージョンあたりの上り（内向き）の構造化 DICOM ストレージ（バイト） | DICOM タグと関連するメタデータの形式で、dicomweb_ops オペレーションの処理中に Cloud Healthcare API に送信される構造化バイト。 |
dicom_store_ops |
1 分間、1 リージョンあたりの DICOM ストア オペレーション数 | DICOM データではなく、DICOM ストアに対するオペレーション。以下のメソッドが含まれます。 |
dicom_store_lro_ops |
1 分間、1 リージョンあたりの DICOM ストアの長時間実行オペレーション数 | 長時間実行オペレーションを返す、DICOM データではなく、DICOM ストアに対するオペレーション。以下のメソッドが含まれます。 |
dicom_structured_storage_operations_bytes |
1 分間、1 リージョンあたりの、長時間実行オペレーションのための上り（内向き）の構造化 DICOM ストレージ（バイト） | DICOM タグと関連するメタデータの形式で、dicom_store_lro_ops オペレーションの処理中に Cloud Healthcare API に送信される構造化バイト。 |
FHIR の割り当て
次の表に、FHIR ストアと FHIR のオペレーションに関連付けられた Cloud Healthcare API の割り当てを示します。
| 指標名 | 表示名 | 説明 |
|---|---|---|
fhir_read_ops |
1 分間、1 リージョンあたりの FHIR 読み取りオペレーション数 | ユニットで測定されます。ここで、1 つのユニットは個々の FHIR リソースに対する 1 つの読み取りリクエストです。 次のメソッドが含まれます。 v1beta1: v1: |
fhir_write_ops |
1 分間、1 リージョンあたりの FHIR 書き込みオペレーション数 | ユニットで測定されます。ここで、1 ユニットは、個々の FHIR リソースに対して 1 つの作成、更新、削除リクエストです。 次のメソッドが含まれます。 v1beta1: v1: |
fhir_search_ops |
1 分間、1 リージョンあたりの FHIR 検索オペレーション数 | ユニットで測定されます。ここで、1 つのユニットは、_include が使用されている場合を除き、検索で参照を解決する必要がない FHIR リソースタイプに対する検索リクエストです。たとえば、Observation?subject:Patient.identifier=system|value 検索では 2 つの fhir_search_ops 割り当てユニットを消費します。1 つは Observation リソースに対して、もう 1 つは Patient リソースに対する検索として、subject を参照として使用するためです。次のメソッドが含まれます。 v1beta1:
|
fhir_storage_egress_bytes |
1 分間、1 リージョンあたりの下り（外向き）の FHIR ストレージ（バイト） | ユニットで測定されます。ここで、1 つのユニットは Cloud Healthcare API が fhir_read_ops オペレーション、fhir_write_ops オペレーションおよび fhir_search_ops オペレーションの処理中にストレージから読み取る 1 バイトです。 |
fhir_storage_bytes |
1 分間、1 リージョンあたりの上り（内向き）の FHIR ストレージ（バイト） | fhir_write_ops オペレーションの処理中に Cloud Healthcare API に送信されるバイト数。 |
fhir_store_ops |
1 分間、1 リージョンあたりの FHIR ストア オペレーション数 | FHIR データではなく、FHIR ストアに対するオペレーション。 次のメソッドが含まれます。 |
fhir_store_lro_ops |
1 分間、1 リージョンあたりの FHIR ストアの長時間実行オペレーション数 | 長時間実行オペレーションを返す、FHIR データではなく FHIR ストアに対するオペレーション。 次のメソッドが含まれます。 |
fhir_storage_operations_bytes |
1 分間、1 リージョンあたりの、長時間実行オペレーションのための上り（内向き）の FHIR ストレージ（バイト） | fhir_store_lro_ops オペレーションの処理中に Cloud Healthcare API に送信されるバイト数。 |
マルチオペレーション検索
1 つのリクエストで複数の割り当てユニットを消費できます。たとえば、検索パラメータとして Observation?subject:Patient.identifier=system|value を使用する GET 検索リクエストは、2 つの fhir_search_ops 割り当てユニットを消費します。subject を参照として使用し、2 つの検索オペレーションが実行されます。1 つは Observation リソースに対して、もう 1 つは Patient リソースに対して実行されます。
検索条件として Observation?status=canceled を使用する条件付き削除リクエストが 6 つの Observation リソースを検索して削除すると、次の割り当てユニットが消費されます。
- 1 つの
fhir_search_ops割り当てユニット。GET検索リクエストの実行対象は、特定のタイプの FHIR リソース（Observation リソース）に限定されるためです。このリクエストは、検索条件に一致するすべての Observation リソースを返します。 - 6 つの
fhir_write_ops割り当てユニット。削除された Observation リソースには合計 6 つのDELETEオペレーションがあるため。
バンドルの割り当て消費を実行する
バンドル実行リクエストを送信するには、リクエストが消費する割り当てに関係なく、次に示す割り当てごとに Google Cloud プロジェクト内に 1 つ以上のユニットが必要になります。
fhir_read_opsfhir_write_opsfhir_search_ops
これらの割り当てを利用できない場合、バンドル実行リクエストは失敗します。
たとえば、100 個の POST オペレーションを含むトランザクション バンドルがある fhir.executeBundle リクエストを送信する場合、それぞれが FHIR リソースを作成し、Cloud Healthcare API はまず、fhir_read_ops、fhir_write_ops、fhir_search_ops に対して少なくとも 1 つの割り当てユニットが利用可能であることを確認します。検証が成功すると、Cloud Healthcare API はバンドルを実行し、FHIR リソースを作成します。これは合計 100 個の fhir_write_ops 割り当てユニットを消費します。
次のトランザクション バンドルについて考えてみましょう。このバンドルは条件付き参照を使用して、reference が存在する場合、Observation リソースを作成します。
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"request": {
"method": "POST",
"url": "Observation"
},
"resource": {
"resourceType": "Observation",
"subject": {
"reference": "Patient?identifier=a1b2c3d4e5"
}
}
}
]
}
バンドルを実行すると、Cloud Healthcare API はまず、fhir_read_ops、fhir_write_ops、fhir_search_ops に対して少なくとも 1 つの割り当てユニットが利用可能であることを確認します。検証が成功すると、Cloud Healthcare API はバンドルを実行します。次の割り当てユニットが消費されます。
- 新しい Observation リソースを作成する 1 つの
fhir_write_ops。 - 1 つの
fhir_search_ops。1 回の検索オペレーションがPatient?identifier=a1b2c3d4e5リファレンスに対して実行されるため。
ベスト プラクティス
Cloud Healthcare API の割り当てを管理する際のベスト プラクティスについては、割り当て管理のベスト プラクティスをご覧ください。