Configure cabeçalhos HTTP personalizados para registos de auditoria

Esta página explica como concluir as seguintes tarefas:

  1. Configure cabeçalhos HTTP personalizados em pedidos à Cloud Healthcare API.

  2. Use os registos de auditoria do Cloud para pesquisar pedidos e os respetivos cabeçalhos HTTP personalizados correspondentes para fazer o seguinte:

    • Veja quem enviou um pedido e quando.
    • Simplifique a implementação e a depuração ao descobrir que pedido causou um erro específico.

Para mais informações sobre a utilização dos registos de auditoria do Cloud na Cloud Healthcare API, consulte o artigo Ver registos de auditoria do Cloud.

Métodos configuráveis

Pode configurar cabeçalhos HTTP personalizados para os métodos da Cloud Healthcare API nos seguintes recursos REST:

Configure cabeçalhos HTTP personalizados

Existem dois tipos de cabeçalhos HTTP personalizados que pode especificar em pedidos da Cloud Healthcare API e ver nos registos de auditoria. Pode usar cada tipo exclusivamente ou combiná-los.

  • Registo de IDs personalizados. Pode especificar o X-Request-Idcabeçalho HTTP personalizado para atribuir a cada pedido o seu próprio ID personalizado e, em seguida, pesquisar nos registos de auditoria um pedido que contenha o ID. Para fornecer um ID personalizado, especifique o cabeçalho HTTP personalizado no seguinte formato:

    X-Request-Id: REQUEST_ID

    Especifique um valor único para REQUEST_ID em cada pedido.

    A maioria das linguagens de programação tem uma forma de gerar IDs aleatórios que pode usar para criar o ID do pedido. Por exemplo, o módulo Python uuid tem uma função uuid.uuid4() que pode usar para gerar IDs automaticamente para cada pedido. A Cloud Healthcare API não gera IDs de pedidos.

  • Registo de metadados. Pode incluir informações de metadados adicionais em cabeçalhos HTTP personalizados através do cabeçalho X-Goog-Healthcare-Audit-IDENTIFIER. O cabeçalho identifica de forma exclusiva o tipo de informações de metadados.

    Os metadados são armazenados no registo de auditoria para cada pedido. Para fornecer informações de metadados, especifique um ou mais cabeçalhos HTTP personalizados no seguinte formato:

    X-Goog-Healthcare-Audit-IDENTIFIER: VALUE

    Substitua IDENTIFIER por um identificador legível por humanos. Substitua VALUE por um valor para os metadados. Pode especificar vários valores numa lista separada por vírgulas através da seguinte sintaxe:

    X-Goog-Healthcare-Audit-IDENTIFIER: VALUE_1, VALUE_2, VALUE_n ...

    Por exemplo:

    X-Goog-Healthcare-Audit-MyIdentifier: Value1, Value2, Value3

    Também pode especificar vários cabeçalhos HTTP personalizados com os seus próprios valores únicos:

    X-Goog-Healthcare-Audit-MyIdentifier1: Value1, Value2
X-Goog-Healthcare-Audit-MyIdentifier2: Value3

Veja os registos de auditoria nos registos de auditoria na nuvem

Consulte Ver registos.

Exemplo

O exemplo seguinte demonstra um cenário em que especifica cabeçalhos HTTP personalizados num pedido fhir.create.

Suponhamos que está a executar um estudo e tem uma aplicação para dispositivos móveis para pacientes denominada PatientApp. Os pacientes no estudo estão divididos em duas coortes: Cohort1 e Cohort2. Para identificar cada pedido de Cohort1 com um ID exclusivo e o nome da aplicação para dispositivos móveis, especifique os seguintes cabeçalhos HTTP personalizados em cada pedido:

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

Os cabeçalhos HTTP personalizados são apresentados no campo metadata do registo de auditoria de cada pedido nos registos de auditoria na nuvem.

O exemplo seguinte mostra como usar curl para criar um novo recurso Patient num FHIR store. O pedido contém os seguintes cabeçalhos HTTP personalizados:

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

Antes de enviar o pedido, substitua o seguinte:

  • PROJECT_ID: o ID do seu Google Cloud projeto
  • LOCATION: a localização do conjunto de dados
  • DATASET_ID: o conjunto de dados principal do FHIR store
  • FHIR_STORE_ID: o ID da loja FHIR
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"

O resultado é o seguinte:

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

Se pesquisar o pedido nos registos de auditoria do Cloud, o registo de auditoria tem o seguinte aspeto:

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