En esta página se describe cómo registrar datos de usuario con la API Consent Management.
Los elementos de datos se registran en la API Consent Management y se conectan a los consentimientos mediante asignaciones de datos de usuario. Los datos de usuario nunca se almacenan en la API Consent Management.
Las asignaciones de datos de usuario, representadas como recursos UserDataMappings, incluyen los siguientes elementos:
- Un ID de usuario que identifica al usuario. Este ID coincide con el que la aplicación proporcionó a la API Consent Management al registrar el consentimiento.
- Un ID de datos que identifica los datos de usuario almacenados en otro lugar, como enGoogle Cloud o en las instalaciones. El ID de datos puede ser un ID opaco, una URL o cualquier otro identificador.
- Atributos de recurso, que describen las características de los datos de usuario mediante valores de atributos de recurso configurados para el almacén de consentimiento mediante definiciones de atributos. Por ejemplo, los datos podrían incluir el
attribute_definition_iddata_identifiablecon el valorde-identified.
En el siguiente diagrama se muestra el flujo de datos para crear asignaciones de datos de usuario:

Registrar asignaciones de datos de usuario
Para crear una asignación de datos de usuario, usa el método projects.locations.datasets.consentStores.userDataMappings.create. Envía una solicitud POST y especifica la siguiente información en ella:
- Nombre del almacén de consentimientos principal
- Un
userIDúnico y opaco que representa al usuario con el que está asociado el elemento de datos. - Identificador del recurso de datos de usuario, como la ruta REST a un recurso único.
- Conjunto de atributos
RESOURCEque describen el elemento de datos - Un token de acceso
curl
En el siguiente ejemplo se muestra una solicitud POST que utiliza curl:
curl -X POST \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/consent+json; charset=utf-8" \ --data "{ 'user_id': 'USER_ID', 'data_id' : 'DATA_ID', 'resource_attributes': [{ 'attribute_definition_id': 'data_identifiable', 'values': ['de-identified'] }] }" \ "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/consentStores/CONSENT_STORE_ID/userDataMappings"
Si la solicitud se realiza de forma correcta, el servidor devuelve una respuesta similar a la siguiente en formato JSON:
{
"name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/consentStores/CONSENT_STORE_ID/userDataMappings/USER_DATA_MAPPING_ID",
"dataId": "DATA_ID",
"userId": "USER_ID",
"resourceAttributes": [
{
"attributeDefinitionId": "data_identifiable",
"values": [
"de-identified"
]
}
]
}
PowerShell
En el siguiente ejemplo se muestra una solicitud POST que utiliza Windows PowerShell:
$cred = gcloud auth application-default print-access-token $headers = @{ Authorization = "Bearer $cred" } Invoke-WebRequest ` -Method Post ` -Headers $headers ` -ContentType: "application/consent+json; charset=utf-8" ` -Body "{ 'user_id': 'USER_ID', 'data_id' : 'DATA_ID', 'resource_attributes': [{ 'attribute_definition_id': 'data_identifiable', 'values': ['de-identified'] }] }" ` -Uri "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/consentStores/CONSENT_STORE_ID/userDataMappings" | Select-Object -Expand Content
Si la solicitud se realiza de forma correcta, el servidor devuelve una respuesta similar a la siguiente en formato JSON:
{
"name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/consentStores/CONSENT_STORE_ID/userDataMappings/USER_DATA_MAPPING_ID",
"dataId": "DATA_ID",
"userId": "USER_ID",
"resourceAttributes": [
{
"attributeDefinitionId": "data_identifiable",
"values": [
"de-identified"
]
}
]
}
Configurar IDs de datos
El campo data_id del recurso de asignación de datos de usuario contiene una cadena especificada por el cliente que describe los datos a los que hace referencia el recurso de asignación de datos de usuario. Se permite cualquier cadena, como un ID opaco o un URI.
Los IDs de datos pueden ser tan granulares como requiera tu aplicación. Si los datos que va a registrar se pueden describir a nivel de tabla o de contenedor, defina data_id como la ruta REST a ese recurso.
Si los datos que vas a registrar requieren más granularidad, puedes especificar filas o celdas concretas. Si tu aplicación usa recursos conceptuales, como acciones permitidas o clases de datos, debes definir data_id con una convención que admita esos casos prácticos.
Estos son algunos ejemplos de data_id que describen los datos almacenados en diferentes servicios y con varios niveles de granularidad:
Objeto de Google Cloud Storage
'data_id' : 'gs://BUCKET_NAME/OBJECT_NAME'
Objeto de Amazon S3
'data_id' : 'https://BUCKET_NAME.s3.REGION.amazonaws.com/OBJECT_NAME'
Tabla de BigQuery
'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID'
Fila de BigQuery (no hay ninguna ruta REST para una fila de BigQuery, por lo que necesitas tu propio identificador. A continuación, se muestra un enfoque posible).
'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID/myRows/ROW_ID'
Celda de BigQuery (no hay ninguna ruta REST para una celda de BigQuery, por lo que necesitas tu propio identificador. A continuación, se muestra un enfoque posible).
'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID/myRows/ROW_ID/myColumns/COLUMN_ID'
Recurso FHIR
'data_id' : 'https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/Patient/PATIENT_ID'
Representación conceptual
'data_id' : 'wearables/fitness/step_count/daily_sum'