Benutzerdefinierte HTTP-Header für Audit-Logs konfigurieren

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

  1. Benutzerdefinierte HTTP-Header in Anfragen an die Cloud Healthcare API konfigurieren

  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.
    • Vereinfachen Sie die Bereitstellung und das Debugging, indem Sie ermitteln, welche Anfrage einen Fehler verursacht hat. Fehler.

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

Konfigurierbare Methoden

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

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 exklusiv verwenden oder beides 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 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. Zum Beispiel hat die Python- Das Modul uuid wurde ein uuid.uuid4() , mit der Sie IDs für jede Anfrage automatisch generieren können. Die Cloud Healthcare API generiert keine Anfrage-IDs.

  • Metadaten-Logging: Sie können zusätzliche Metadateninformationen in ein benutzerdefiniertes HTTP- mithilfe von X-Goog-Healthcare-Audit-IDENTIFIER Header. Der Header identifiziert eindeutig den Typ der Metadateninformationen.

    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 menschenlesbare 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 ansehen

Weitere Informationen finden Sie unter Logs ansehen.

Beispiel

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

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

Das folgende Beispiel zeigt, wie Sie mit curl eine neue Patientenressource in einem FHIR erstellen. speichern. 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 vor dem Senden der Anfrage Folgendes:

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