Esta página foi traduzida pela API Cloud Translation.

Configurar cabeçalhos HTTP personalizados para registros de auditoria

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

Configure cabeçalhos HTTP personalizados em 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 e fazer o seguinte:
- Veja 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

Há dois tipos de cabeçalhos HTTP personalizados que podem ser especificados em solicitações da API Cloud Healthcare e visualizados em registros de auditoria. É possível usar cada tipo exclusivamente ou combiná-los.

Registro de ID personalizado. É possível especificar o cabeçalho HTTP personalizado X-Request-Id para dar a cada solicitação um ID personalizado e pesquisar nos registros de auditoria 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.
Registro de metadados. É possível incluir mais 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 de informação 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 para humanos. Substitua VALUE por um valor para os metadados. É possível especificar vários 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 valores exclusivos:
```
X-Goog-Healthcare-Audit-MyIdentifier1: Value1, Value2
X-Goog-Healthcare-Audit-MyIdentifier2: Value3
```

Ver os registros de auditoria nos Registros de auditoria do Cloud

Consulte Ver registros.

Exemplo

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

Suponha que você esteja conduzindo um estudo e tenha um aplicativo para dispositivos móveis para pacientes chamado PatientApp. Os pacientes no estudo são divididos em duas coortes: Cohort1 e Cohort2. Para identificar cada solicitação de Cohort1 com um ID exclusivo e o nome do aplicativo 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 aparecem 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 recurso de paciente em um armazenamento 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 projeto 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 será semelhante a este:

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