Benutzerdefinierte HTTP-Header für Audit-Logs konfigurieren

Auf dieser Seite wird erläutert, wie Sie folgende Aufgaben ausführen:

Benutzerdefinierte HTTP-Header in Anfragen an die Cloud Healthcare API konfigurieren
Mit Cloud-Audit-Logs können Sie nach Anfragen und den zugehörigen benutzerdefinierten HTTP-Headern suchen und Folgendes tun:
- Sehen, wer wann eine Anfrage gesendet hat
- Vereinfachen Sie die Bereitstellung und das Debugging, indem Sie herausfinden, welche Anfrage einen bestimmten Fehler verursacht hat.

Weitere Informationen zur Verwendung von Cloud-Audit-Logs in der Cloud Healthcare API finden Sie unter Cloud-Audit-Logs ansehen.

Konfigurierbare Methoden

Sie können benutzerdefinierte HTTP-Header für die Cloud Healthcare API-Methoden in den folgenden REST-Ressourcen konfigurieren:

Benutzerdefinierte HTTP-Header konfigurieren

Es gibt zwei Arten von benutzerdefinierten HTTP-Headern, die Sie in Cloud Healthcare API-Anfragen angeben und in Audit-Logs ansehen können. Sie können jeden Typ ausschließlich verwenden oder beide Typen kombinieren.

Benutzerdefiniertes ID-Logging: Sie können den benutzerdefinierten HTTP-Header X-Request-Id angeben, um jeder Anfrage eine eigene benutzerdefinierte ID zuzuweisen, und dann in Audit-Logs nach einer Anfrage suchen, die diese ID enthält. Wenn Sie eine benutzerdefinierte ID angeben möchten, geben Sie den benutzerdefinierten HTTP-Header im folgenden Format an:
```
X-Request-Id: REQUEST_ID
```
Geben Sie in jeder Anfrage einen eindeutigen Wert für REQUEST_ID an.

In den meisten Programmiersprachen gibt es eine Möglichkeit, Zufalls-IDs zu generieren, mit denen Sie die Anfrage-ID erstellen können. Das Python-Modul uuid hat beispielsweise eine uuid.uuid4()-Funktion, mit der Sie IDs für jede Anfrage automatisch generieren können. Die Cloud Healthcare API generiert keine Anfrage-IDs.
Metadaten-Logging: Mit dem Header X-Goog-Healthcare-Audit-IDENTIFIER können Sie zusätzliche Metadateninformationen in benutzerdefinierte HTTP-Header aufnehmen. Der Header identifiziert eindeutig den Typ der Metadateninformationen.

Die Metadaten werden für jede Anfrage im Audit-Log gespeichert. Zum Bereitstellen von Metadateninformationen geben Sie einen oder mehrere benutzerdefinierte HTTP-Header im folgenden Format an:
```
X-Goog-Healthcare-Audit-IDENTIFIER: VALUE
```
Ersetzen Sie IDENTIFIER durch eine visuell lesbare ID. Ersetzen Sie VALUE durch einen Wert für die Metadaten. Sie können mehrere Werte in einer durch Kommas getrennten Liste mithilfe der folgenden Syntax angeben:
```
X-Goog-Healthcare-Audit-IDENTIFIER: VALUE_1, VALUE_2, VALUE_n ...
```
Beispiel:
```
X-Goog-Healthcare-Audit-MyIdentifier: Value1, Value2, Value3
```
Sie können auch mehrere benutzerdefinierte HTTP-Header mit eigenen eindeutigen Werten angeben:
```
X-Goog-Healthcare-Audit-MyIdentifier1: Value1, Value2
X-Goog-Healthcare-Audit-MyIdentifier2: Value3
```

Audit-Logs in Cloud-Audit-Logs ansehen

Weitere Informationen finden Sie unter Logs ansehen.

Beispiel

Das folgende Beispiel zeigt ein Szenario, in dem Sie in einer fhir.create-Anfrage benutzerdefinierte HTTP-Header angeben.

Angenommen, Sie führen eine Studie durch und haben eine mobile App für Patienten mit dem Namen PatientApp. Die Patienten in der Studie werden in zwei Kohorten unterteilt: Cohort1 und Cohort2. Damit jede Anfrage von Cohort1 mit einer eindeutigen ID und dem Namen der mobilen App identifiziert werden kann, geben Sie in jeder Anfrage die folgenden benutzerdefinierten HTTP-Header an:

X-Request-Id: REQUEST_ID
X-Goog-Healthcare-Audit-AppName: PatientApp
X-Goog-Healthcare-Audit-CohortName: Cohort1

Die benutzerdefinierten HTTP-Header werden im Feld metadata des Audit-Logs für jede Anfrage in Cloud-Audit-Logs angezeigt.

Das folgende Beispiel zeigt, wie Sie mit curl eine neue Patientenressource in einem FHIR-Speicher erstellen. Die Anfrage enthält die folgenden benutzerdefinierten HTTP-Header:

X-Request-Id: 123
X-Goog-Healthcare-Audit-AppName: PatientApp
X-Goog-Healthcare-Audit-CohortName: Cohort1

Ersetzen Sie Folgendes, bevor Sie die Anfrage senden:

PROJECT_ID ist die ID Ihres Google Cloud-Projekts
LOCATION ist der Standort des Datasets
DATASET_ID: das übergeordnete Dataset des FHIR-Speichers
FHIR_STORE_ID: die FHIR-Speicher-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"

Die Ausgabe sieht so aus:

{
  "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"
}

Wenn Sie in Cloud-Audit-Logs nach der Anfrage suchen, sieht das Audit-Log so aus:

{
  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"]
    }
    ...
  }
   ...
}