このページでは、次のタスクを行う方法について説明します。
- Cloud Healthcare API へのリクエストのカスタム HTTP ヘッダーを構成する。
Cloud Audit Logs を使用して、リクエストとそれに対応するカスタム HTTP ヘッダーを検索し、次の操作を行います。
- リクエストを送信したユーザーと日時を確認する。
- 特定のエラーの原因となったリクエストを特定して、デプロイとデバッグを簡素化する。
Cloud Healthcare API で Cloud Audit Logs を使用する方法については、Cloud Audit Logs の表示をご覧ください。
構成可能なメソッド
次の REST リソースで、Cloud Healthcare API メソッドのカスタム HTTP ヘッダーを構成できます。
projects.locations
projects.locations.datasets
projects.locations.dicomStores
projects.locations.dicomStores.studies
projects.locations.dicomStores.studies.series
projects.locations.dicomStores.studies.series.instances
projects.locations.dicomStores.studies.series.instances.frames
projects.locations.datasets.fhirStores
projects.locations.datasets.fhirStores.fhir
projects.locations.datasets.hl7V2Stores
projects.locations.datasets.hl7V2Stores.messages
projects.locations.datasets.operations
カスタム HTTP ヘッダーを構成する
2 種類のカスタム HTTP ヘッダーがあり、Cloud Healthcare API のリクエストで指定して監査ログに表示できます。それぞれのタイプを排他的に使用することも、組み合わせて使用することも可能です。
カスタム ID ロギング。
X-Request-Id
カスタム HTTP ヘッダーを指定して、各リクエストに独自のカスタム ID を設定し、その ID を含むリクエストを監査ログから検索できます。カスタム ID を設定するには、次の形式でカスタム HTTP ヘッダーを指定します。X-Request-Id: REQUEST_ID
各リクエストで REQUEST_ID に一意の値を指定します。
ほとんどのプログラミング言語には、リクエスト ID の作成に使用できるランダムな ID を生成する方法が用意されています。たとえば、Python
uuid
モジュールには、リクエストごとに ID を自動生成するために使用できるuuid.uuid4()
関数があります。Cloud Healthcare API では、リクエスト ID は生成されません。メタデータ ロギング。
X-Goog-Healthcare-Audit-IDENTIFIER
ヘッダーを使用して、カスタム HTTP ヘッダーに追加のメタデータ情報を含めることができます。ヘッダーにより、メタデータ情報のタイプが一意に識別されます。メタデータは、各リクエストの監査ログに保存されます。メタデータ情報を設定するには、次の形式で 1 つ以上のカスタム HTTP ヘッダーを指定します。
X-Goog-Healthcare-Audit-IDENTIFIER: VALUE
IDENTIFIER は、人が判読できる形式の識別子に置き換えます。VALUE はメタデータの値に置き換えます。複数の値をカンマ区切りのリストで指定するには、次の構文を使用します。
X-Goog-Healthcare-Audit-IDENTIFIER: VALUE_1, VALUE_2, VALUE_n ...
例:
X-Goog-Healthcare-Audit-MyIdentifier: Value1, Value2, Value3
一意の値を持つ複数のカスタム HTTP ヘッダーを指定することもできます。
X-Goog-Healthcare-Audit-MyIdentifier1: Value1, Value2 X-Goog-Healthcare-Audit-MyIdentifier2: Value3
Cloud Audit Logs で監査ログを表示する
ログを表示するをご覧ください。
例
次の例は、fhir.create
リクエストでカスタム HTTP ヘッダーを指定するシナリオを示しています。
ある研究を実施していて、PatientApp
という名前の患者用のモバイルアプリがあるとします。この研究の患者は、Cohort1
と Cohort2
という 2 つのコホートに分けられます。Cohort1
からのリクエストをそれぞれ一意の ID とモバイルアプリの名前で識別するために、各リクエストで次のカスタム HTTP ヘッダーを指定します。
X-Request-Id: REQUEST_ID X-Goog-Healthcare-Audit-AppName: PatientApp X-Goog-Healthcare-Audit-CohortName: Cohort1
Cloud Audit Logs では、カスタム HTTP ヘッダーは各リクエストの監査ログの metadata
フィールドに表示されます。
次のサンプルは、curl
を使用して FHIR ストアに新しい Patient リソースを作成する方法を示しています。リクエストには次のカスタム HTTP ヘッダーが含まれます。
X-Request-Id: 123
X-Goog-Healthcare-Audit-AppName: PatientApp
X-Goog-Healthcare-Audit-CohortName: Cohort1
リクエストを送信する前に、次のように置き換えます。
- PROJECT_ID: Google Cloud プロジェクトの ID
- LOCATION: データセットの場所
- DATASET_ID: FHIR ストアの親データセット
- FHIR_STORE_ID: FHIR ストア ID
curl -X POST \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json; charset=utf-8" \ -H "X-Request-Id: 123" \ -H "X-Goog-Healthcare-Audit-AppName: PatientApp" \ -H "X-Goog-Healthcare-Audit-CohortName: Cohort1" \ --data '{ "name": [ { "use": "official", "family": "Smith", "given": [ "Darcy" ] } ], "gender": "female", "birthDate": "1970-01-01", "resourceType": "Patient" }' "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/Patient"
次のような出力が表示されます。
{ "birthDate": "1970-01-01", "gender": "female", "id": "PATIENT_ID", "meta": { "lastUpdated": "YYYY-MM-DDTHH:MM:SS+ZZ:ZZ", "versionId": "VERSION_ID" }, "name": [ { "family": "Smith", "given": [ "Darcy" ], "use": "official" } ], "resourceType": "Patient" }
Cloud Audit Logs でリクエストを検索した場合、監査ログは次のようになります。
{ logName: "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_write" protoPayload: { @type: "type.googleapis.com/google.cloud.audit.AuditLog" metadata: { X-Request-Id: [123] X-Goog-Healthcare-Audit-AppName: ["PatientApp"] X-Goog-Healthcare-Audit-CohortName: ["Cohort1"] } ... } ... }