Benutzerdefinierte HTTP-Header für Audit-Logs konfigurieren

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

  1. Konfigurieren Sie benutzerdefinierte HTTP-Header in Anfragen an die Cloud Healthcare API.

  2. Mit Cloud-Audit-Logs können Sie nach Anfragen und den zugehörigen benutzerdefinierten HTTP-Headern suchen, um Folgendes zu tun:

    • Sie können sehen, wer eine Anfrage gesendet hat und wann.
    • Sie können die Bereitstellung und Fehlerbehebung vereinfachen, 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 einzeln verwenden oder sie kombinieren.

  • Protokollierung der benutzerdefinierten ID Sie können den benutzerdefinierten HTTP-Header X-Request-Id angeben, um jeder Anfrage eine eigene benutzerdefinierte ID zuzuweisen, und dann in den Prüfprotokollen nach einer Anfrage mit der ID suchen. Wenn du eine benutzerdefinierte ID angeben möchtest, gib 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.

    Die meisten Programmiersprachen bieten eine Möglichkeit, zufällige IDs zu generieren, mit denen Sie die Anfrage-ID erstellen können. Das Python-Modul uuid enthält beispielsweise die Funktion uuid.uuid4(), mit der Sie IDs automatisch für jede Anfrage generieren können. Die Cloud Healthcare API generiert keine Anfrage-IDs.

  • Metadatenprotokollierung Mit dem X-Goog-Healthcare-Audit-IDENTIFIER-Header können Sie zusätzliche Metadateninformationen in benutzerdefinierte HTTP-Header einfügen. Die Kopfzeile identifiziert den Metadatentyp eindeutig.

    Die Metadaten werden für jede Anfrage im Audit-Log gespeichert. Wenn du Metadaten angeben möchtest, gib einen oder mehrere benutzerdefinierte HTTP-Header im folgenden Format an:

    X-Goog-Healthcare-Audit-IDENTIFIER: VALUE

    Ersetzen Sie IDENTIFIER durch eine visuell lesbare Kennung. Ersetzen Sie VALUE durch einen Wert für die Metadaten. Sie können mehrere Werte in einer durch Kommas getrennten Liste mit 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 aufrufen

Weitere Informationen finden Sie unter Logs ansehen.

Beispiel

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

Angenommen, Sie führen eine Studie durch und haben eine mobile App für Patienten namens PatientApp. Die Patienten in der Studie sind in zwei Kohorten unterteilt: Cohort1 und Cohort2. Um jede Anfrage von Cohort1 mit einer eindeutigen ID und dem Namen der mobilen Anwendung zu identifizieren, 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 jeder Anfrage in Cloud Audit-Logs angezeigt.

Im folgenden Beispiel wird gezeigt, 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 die folgenden Werte, bevor Sie die Anfrage senden:

  • PROJECT_ID: 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"]
    }
    ...
  }
   ...
}