Configurar cabeçalhos HTTP personalizados para registros de auditoria

Nesta página, explicamos como concluir as seguintes tarefas:

Configurar cabeçalhos HTTP personalizados nas solicitações para a API Cloud Healthcare.
Use os Registros de auditoria do Cloud para pesquisar solicitações e os cabeçalhos HTTP personalizados correspondentes para fazer o seguinte:
- Conferir quem enviou uma solicitação e quando.
- Simplifique a implantação e a depuração descobrindo qual solicitação causou um erro específico.

Para mais informações sobre como usar os Registros de auditoria do Cloud na API Cloud Healthcare, consulte Como visualizar registros de auditoria do Cloud.

Métodos configuráveis

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

Configurar cabeçalhos HTTP personalizados

É possível especificar dois tipos de cabeçalhos HTTP personalizados nas solicitações da API Cloud Healthcare e ver nos registros de auditoria. Você pode usar cada tipo exclusivamente ou combiná-los.

Geração de registros de ID personalizado. Especifique o cabeçalho HTTP personalizado X-Request-Id para atribuir um ID personalizado a cada solicitação e, em seguida, pesquise nos registros de auditoria de uma solicitação 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 exclusivo para REQUEST_ID em cada solicitação.

A maioria das linguagens de programação tem uma maneira de gerar IDs aleatórios que podem ser usados para criar o ID da solicitação. Por exemplo, o módulo Python uuid tem uma função uuid.uuid4() que pode ser usada para gerar IDs automaticamente para cada solicitação. A API Cloud Healthcare não gera IDs de solicitação.
Geração de registros de metadados. É possível incluir outras informações de metadados em cabeçalhos HTTP personalizados usando o cabeçalho X-Goog-Healthcare-Audit-IDENTIFIER. O cabeçalho identifica exclusivamente o tipo das informações de metadados.

Os metadados são armazenados no registro de auditoria de cada solicitação. 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. Substitua VALUE por um valor para os metadados. É possível especificar diversos valores em uma lista separada por vírgulas usando a seguinte sintaxe:
```
X-Goog-Healthcare-Audit-IDENTIFIER: VALUE_1, VALUE_2, VALUE_n ...
```
Exemplo:
```
X-Goog-Healthcare-Audit-MyIdentifier: Value1, Value2, Value3
```
Também é possível especificar vários cabeçalhos HTTP personalizados com os próprios valores exclusivos:
```
X-Goog-Healthcare-Audit-MyIdentifier1: Value1, Value2
X-Goog-Healthcare-Audit-MyIdentifier2: Value3
```

Acesse os Registros de auditoria do Cloud

Consulte Ver registros.

Exemplo

No exemplo a seguir, demonstramos um cenário em que você especifica cabeçalhos HTTP personalizados em uma solicitação fhir.create.

Imagine que você esteja realizando um estudo e tenha um aplicativo para dispositivos móveis com o nome PatientApp para pacientes. Os pacientes no estudo estão divididos em duas coortes: Cohort1 e Cohort2. Para identificar cada solicitação de Cohort1 com um ID exclusivo e o nome do app para dispositivos móveis, especifique os seguintes cabeçalhos HTTP personalizados em cada solicitação:

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

Os cabeçalhos HTTP personalizados são exibidos no campo metadata do registro de auditoria de cada solicitação nos Registros de auditoria do Cloud.

O exemplo a seguir mostra como usar curl para criar um novo recurso de paciente em um armazenamento de FHIR. A solicitação 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 a solicitação, substitua o seguinte:

PROJECT_ID: o ID do seu projeto do Google Cloud;
LOCATION: o local do conjunto de dados;
DATASET_ID: o conjunto de dados pai do armazenamento de FHIR
FHIR_STORE_ID: o ID de armazenamento de 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"

A saída é esta:

{
  "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 você pesquisar a solicitação nos Registros de auditoria do Cloud, o registro de auditoria terá a seguinte aparência:

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