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 は生成されません。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2024-12-24 UTC。"],[[["\u003cp\u003eThis guide outlines how to configure custom HTTP headers in requests to the Cloud Healthcare API for tracking and debugging purposes.\u003c/p\u003e\n"],["\u003cp\u003eYou can utilize either \u003ccode\u003eX-Request-Id\u003c/code\u003e for unique request identification or \u003ccode\u003eX-Goog-Healthcare-Audit-IDENTIFIER\u003c/code\u003e for additional metadata, or a combination of both, within your requests.\u003c/p\u003e\n"],["\u003cp\u003eCustom HTTP header information is viewable in Cloud Audit Logs, which is helpful for identifying who sent a request, when it was sent, and determining which request caused an error.\u003c/p\u003e\n"],["\u003cp\u003eWhile custom HTTP header data is stored in Cloud Audit Logs, it is suggested that you avoid including any protected health information (PHI) in them due to visibility constraints and retention periods, which by default are 30 days.\u003c/p\u003e\n"],["\u003cp\u003eCustom HTTP headers can be configured across various REST resources within the Cloud Healthcare API, including locations, datasets, DICOM stores, FHIR stores, and HL7v2 stores.\u003c/p\u003e\n"]]],[],null,["# Configure custom HTTP headers for audit logs\n\nThis page explains how to complete the following tasks:\n\n1. Configure custom HTTP headers in requests to the Cloud Healthcare API.\n2. Use Cloud Audit Logs to search for requests and their matching custom\n HTTP headers to do the following:\n\n - See who sent a request and when.\n - Simplify deployment and debugging by finding out which request caused a particular error.\n\n| **Caution:** As shown in [Logs retention periods](/logging/quotas#logs_retention_periods), information in custom HTTP headers is retained in Cloud Audit Logs by default for 30 days. You can modify the retention period by [configuring a custom retention period](/logging/docs/buckets#custom-retention). The minimum retention period is 7 days. Anyone who has permission to view Cloud Audit Logs logs can view the information in the custom HTTP headers. Therefore, we recommend that you don't include protected health information (PHI) in the custom HTTP headers.\n\nFor more information\non using Cloud Audit Logs in the Cloud Healthcare API, see\n[Viewing Cloud Audit Logs](/healthcare-api/docs/how-tos/audit-logging).\n\nConfigurable methods\n--------------------\n\nYou can configure custom HTTP headers for the Cloud Healthcare API methods in\nthe following REST resources:\n\n- [`projects.locations`](/healthcare-api/docs/reference/rest/v1/projects.locations#methods)\n- [`projects.locations.datasets`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets#methods)\n- [`projects.locations.dicomStores`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores#methods)\n- [`projects.locations.dicomStores.studies`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores.studies#methods)\n- [`projects.locations.dicomStores.studies.series`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores.studies.series#methods)\n- [`projects.locations.dicomStores.studies.series.instances`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores.studies.series.instances#methods)\n- [`projects.locations.dicomStores.studies.series.instances.frames`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores.studies.series.instances.frames#methods)\n- [`projects.locations.datasets.fhirStores`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores#methods)\n- [`projects.locations.datasets.fhirStores.fhir`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores.fhir#methods)\n- [`projects.locations.datasets.hl7V2Stores`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.hl7V2Stores#methods)\n- [`projects.locations.datasets.hl7V2Stores.messages`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.hl7V2Stores.messages#methods)\n- [`projects.locations.datasets.operations`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.operations#methods)\n\nConfigure custom HTTP headers\n-----------------------------\n\n| **Caution:** Using custom HTTP headers in a web browser triggers a CORS preflight security check. The Cloud Healthcare API might not approve your custom header during this check, which will cause the browser to block your request.\n\nThere are two types of custom HTTP headers that you can specify on Cloud Healthcare API\nrequests and view in audit logs. You can use each type exclusively or combine them.\n\n- **Custom ID logging.** You can specify the `X-Request-Id` custom HTTP header\n to give each request its own custom ID, and then search through audit logs\n for a request containing the ID. To supply a custom ID, specify the custom\n HTTP header in the following format:\n\n ```none\n X-Request-Id: REQUEST_ID\n ```\n\n Specify a unique value for \u003cvar translate=\"no\"\u003eREQUEST_ID\u003c/var\u003e in each request.\n\n Most programming\n languages have a way to generate random IDs that you can use to\n create the request ID. For example, the Python\n [`uuid`](https://docs.python.org/3/library/uuid.html) module has\n a [`uuid.uuid4()`](https://docs.python.org/3/library/uuid.html#uuid.uuid4)\n function that you can use to generate IDs automatically for each request.\n The Cloud Healthcare API doesn't generate request IDs.\n- **Metadata logging.** You can include additional metadata information in custom HTTP\n headers using the `X-Goog-Healthcare-Audit-`\u003cvar translate=\"no\"\u003eIDENTIFIER\u003c/var\u003e\n header. The header uniquely identifies the type of metadata information.\n\n The metadata is stored in the audit log for each request. To\n supply metadata information, specify one or more custom HTTP headers in\n the following format: \n\n ```none\n X-Goog-Healthcare-Audit-IDENTIFIER: VALUE\n ```\n\n Replace \u003cvar translate=\"no\"\u003eIDENTIFIER\u003c/var\u003e with a human-readable identifier.\n Replace \u003cvar translate=\"no\"\u003eVALUE \u003c/var\u003e with a value for the metadata.\n You can specify multiple values in a comma-separated list using the following syntax: \n\n ```none\n X-Goog-Healthcare-Audit-IDENTIFIER: VALUE_1, VALUE_2, VALUE_n ...\n ```\n\n For example: \n\n ```none\n X-Goog-Healthcare-Audit-MyIdentifier: Value1, Value2, Value3\n ```\n\n You can also specify multiple custom HTTP headers with their own unique values: \n\n ```none\n X-Goog-Healthcare-Audit-MyIdentifier1: Value1, Value2\n X-Goog-Healthcare-Audit-MyIdentifier2: Value3\n ```\n\nView the audit logs in Cloud Audit Logs\n---------------------------------------\n\nSee [View logs](/healthcare-api/docs/how-tos/audit-logging#viewing_logs).\n\nExample\n-------\n\nThe following example demonstrates a scenario where you specify custom HTTP\nheaders in a\n[`fhir.create`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.fhirStores.fhir/create)\nrequest.\n\nSuppose that you're running a study and you have a mobile application\nfor patients named `PatientApp`. The patients in the study are divided into\ntwo cohorts: `Cohort1` and `Cohort2`. To identify each request\nfrom `Cohort1` with a unique ID and the name of the mobile application,\nspecify the following custom HTTP headers in each request: \n\n```none\nX-Request-Id: REQUEST_ID\nX-Goog-Healthcare-Audit-AppName: PatientApp\nX-Goog-Healthcare-Audit-CohortName: Cohort1\n```\n\nThe custom HTTP headers display in the `metadata` field of each request's audit log\nin Cloud Audit Logs.\n\nThe following sample shows how to use `curl` to create a new Patient resource in a FHIR\nstore. The request contains the following custom HTTP headers:\n\n- `X-Request-Id: 123`\n- `X-Goog-Healthcare-Audit-AppName: PatientApp`\n- `X-Goog-Healthcare-Audit-CohortName: Cohort1`\n\nBefore sending the request, replace the following:\n\n- \u003cvar class=\"edit\" scope=\"PROJECT_ID\" translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e: the ID of your Google Cloud project\n- \u003cvar class=\"edit\" scope=\"LOCATION\" translate=\"no\"\u003eLOCATION\u003c/var\u003e: the dataset location\n- \u003cvar class=\"edit\" scope=\"DATASET_ID\" translate=\"no\"\u003eDATASET_ID\u003c/var\u003e: the FHIR store's parent dataset\n- \u003cvar class=\"edit\" scope=\"FHIR_STORE_ID\" translate=\"no\"\u003eFHIR_STORE_ID\u003c/var\u003e: the FHIR store ID\n\n```bash\ncurl -X POST \\\n -H \"Authorization: Bearer $(gcloud auth application-default print-access-token)\" \\\n -H \"Content-Type: application/json; charset=utf-8\" \\\n -H \"X-Request-Id: 123\" \\\n -H \"X-Goog-Healthcare-Audit-AppName: PatientApp\" \\\n -H \"X-Goog-Healthcare-Audit-CohortName: Cohort1\" \\\n --data '{\n \"name\": [\n {\n \"use\": \"official\",\n \"family\": \"Smith\",\n \"given\": [\n \"Darcy\"\n ]\n }\n ],\n \"gender\": \"female\",\n \"birthDate\": \"1970-01-01\",\n \"resourceType\": \"Patient\"\n }' \"https://healthcare.googleapis.com/v1/projects/\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/locations/\u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e/datasets/\u003cvar translate=\"no\"\u003eDATASET_ID\u003c/var\u003e/fhirStores/\u003cvar translate=\"no\"\u003eFHIR_STORE_ID\u003c/var\u003e/fhir/Patient\"\n```\n\nThe output is the following: \n\n```\n{\n \"birthDate\": \"1970-01-01\",\n \"gender\": \"female\",\n \"id\": \"PATIENT_ID\",\n \"meta\": {\n \"lastUpdated\": \"YYYY-MM-DDTHH:MM:SS+ZZ:ZZ\",\n \"versionId\": \"VERSION_ID\"\n },\n \"name\": [\n {\n \"family\": \"Smith\",\n \"given\": [\n \"Darcy\"\n ],\n \"use\": \"official\"\n }\n ],\n \"resourceType\": \"Patient\"\n}\n```\n\nIf you search for the request in Cloud Audit Logs, the audit log\nlooks like the following: \n\n```json\n{\n logName: \"projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_write\"\n protoPayload: {\n @type: \"type.googleapis.com/google.cloud.audit.AuditLog\"\n metadata: {\n X-Request-Id: [123]\n X-Goog-Healthcare-Audit-AppName: [\"PatientApp\"]\n X-Goog-Healthcare-Audit-CohortName: [\"Cohort1\"]\n }\n ...\n }\n ...\n}\n```"]]