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_id
data_identifiable
con 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
RESOURCE
que 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'