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:
- Saber 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 nos registros de auditoria. Você pode usar cada tipo de forma exclusiva ou combiná-los.

Registro de ID personalizado. É possível especificar o cabeçalho HTTP personalizado X-Request-Id para dar a cada solicitação o próprio ID personalizado e, em seguida, 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 dos 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 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 de informações de metadados.

Os metadados são armazenados no registro de auditoria para cada solicitação. Para fornecer informações de metadados, especifique um ou mais cabeçalhos HTTP personalizados no formato a seguir:
```
X-Goog-Healthcare-Audit-IDENTIFIER: VALUE
```
Substitua IDENTIFIER por um identificador legível por 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
```

Acessar os registros de auditoria nos Registros de auditoria do Cloud

Consulte Acessar 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 realizando um estudo e tenha um aplicativo para dispositivos móveis chamado PatientApp para pacientes. 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 novo recurso de paciente em uma loja 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 vai ser parecido com 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"]
    }
    ...
  }
   ...
}