Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Cette page explique comment enregistrer des données utilisateur à l'aide de l'API Consent Management.
Les éléments de données sont enregistrés auprès de l'API Consent Management et connectés aux autorisations à l'aide des mappages de données utilisateur. Les données utilisateur ne sont jamais stockées dans l'API Consent Management.
Les mappages de données utilisateur, représentés par des ressources UserDataMappings, comprennent les éléments suivants :
Un ID utilisateur qui identifie l'utilisateur. Cet ID correspond à l'ID fourni par l'application à l'API Consent Management lors de l'enregistrement de l'autorisation.
Un ID de données qui identifie les données utilisateur stockées ailleurs, par exemple surGoogle Cloud ou sur site. L'ID de données peut être un ID opaque, une URL ou tout autre identifiant.
Les attributs de ressource, qui décrivent les caractéristiques des données utilisateur à l'aide des valeurs d'attributs de ressource configurées pour le magasin d'autorisations, à l'aide de définitions d'attributs. Par exemple, les données peuvent inclure attribute_definition_iddata_identifiable avec la valeur de-identified.
Le schéma suivant illustre le flux de données utilisé pour créer des mappages de données utilisateur :
Le champ data_id de la ressource de mappage de données utilisateur contient une chaîne spécifiée par le client qui décrit les données auxquelles la ressource de mappage de données utilisateur fait référence. Toutes les chaînes sont autorisées, par exemple un ID ou un URI opaque.
Les ID de données peuvent être aussi précis que requis par votre application. Si les données que vous enregistrez peuvent être décrites au niveau de la table ou du bucket, définissez data_id comme chemin REST vers cette ressource.
Si les données que vous enregistrez nécessitent davantage de précision, vous pouvez spécifier des lignes ou des cellules spécifiques. Si votre application utilise des ressources conceptuelles, telles que des actions ou des classes de données autorisées, vous devez définir data_id avec une convention qui supporte ces cas d'utilisation.
Voici quelques exemples de data_id décrivant des données stockées dans différents services et à différents niveaux de précision :
Ligne BigQuery (Il n'existe pas de chemin REST pour une ligne BigQuery. Votre propre identifiant est donc nécessaire. Vous trouverez ci-dessous une approche possible)
Cellule BigQuery (Il n'existe pas de chemin REST pour une ligne BigQuery. Votre propre identifiant est donc nécessaire. Vous trouverez ci-dessous une approche possible)
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[[["\u003cp\u003eThis page explains the process of registering user data with the Consent Management API, which involves creating user data mappings without storing the actual user data in the API.\u003c/p\u003e\n"],["\u003cp\u003eUser data mappings contain a user ID, a data ID, and resource attributes that describe the characteristics of the user data, all stored elsewhere.\u003c/p\u003e\n"],["\u003cp\u003eTo create a user data mapping, you must use the \u003ccode\u003eprojects.locations.datasets.consentStores.userDataMappings.create\u003c/code\u003e method and provide necessary details like the parent consent store name, user ID, data ID, resource attributes, and an access token.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003edata_id\u003c/code\u003e field in user data mapping can be any string, such as an opaque ID or a URI, and should describe the referenced data's location and granularity, like a Google Cloud Storage object or a BigQuery row.\u003c/p\u003e\n"],["\u003cp\u003eThe provided examples demonstrate the proper way to register data from multiple sources, such as Amazon S3 objects, BigQuery elements, or even conceptual representations.\u003c/p\u003e\n"]]],[],null,["# Registering user data\n\nThis page describes how to register user data with the Consent Management API.\n\nData elements are registered with the Consent Management API and connected to\nconsents using user data mappings. User data is never stored in the\nConsent Management API.\n\nThe user data mappings, represented as [`UserDataMappings`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.consentStores.userDataMappings)\nresources, include the following elements:\n\n- A user ID that identifies the user. This ID matches the ID the application provided the Consent Management API when registering the consent.\n- A data ID that identifies user data stored elsewhere, such as on Google Cloud or on-premises. The data ID can be an opaque ID, a URL, or any other identifier.\n- Resource attributes, which describe the characteristics of the user data using resource attribute values configured for the consent store using attribute definitions. For example, the data could include the `attribute_definition_id` `data_identifiable` with the value of `de-identified`.\n\nThe following diagram shows the data flow for creating user data mappings:\n\nRegistering user data mappings\n------------------------------\n\nTo create a user data mapping, use the\n[`projects.locations.datasets.consentStores.userDataMappings.create`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.consentStores.userDataMappings/create)\nmethod. Make a `POST` request and specify the following information in the\nrequest:\n\n- The name of the parent consent store\n- A unique and opaque `userID` that represents the user with whom the data element is associated\n- An identifier for the user data resource, such as the REST path to a unique resource\n- A set of `RESOURCE` attributes that describe the data element\n- An access token\n\n### curl\n\nThe following sample shows a `POST` request using `curl`: \n\n```bash\ncurl -X POST \\\n -H \"Authorization: Bearer $(gcloud auth application-default print-access-token)\" \\\n -H \"Content-Type: application/consent+json; charset=utf-8\" \\\n --data \"{\n 'user_id': '\u003cvar class=\"edit\" translate=\"no\"\u003eUSER_ID\u003c/var\u003e',\n 'data_id' : '\u003cvar class=\"edit\" translate=\"no\"\u003eDATA_ID\u003c/var\u003e',\n 'resource_attributes': [{\n 'attribute_definition_id': 'data_identifiable',\n 'values': ['de-identified']\n }]\n }\" \\\n\"https://healthcare.googleapis.com/v1/projects/\u003cvar class=\"edit\" translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/locations/\u003cvar class=\"edit\" translate=\"no\"\u003eLOCATION\u003c/var\u003e/datasets/\u003cvar class=\"edit\" translate=\"no\"\u003eDATASET_ID\u003c/var\u003e/consentStores/\u003cvar class=\"edit\" translate=\"no\"\u003eCONSENT_STORE_ID\u003c/var\u003e/userDataMappings\"\n```\n\nIf the request is successful, the server returns a response similar to the\nfollowing sample in JSON format: \n\n```\n{\n \"name\": \"projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/consentStores/CONSENT_STORE_ID/userDataMappings/USER_DATA_MAPPING_ID\",\n \"dataId\": \"DATA_ID\",\n \"userId\": \"USER_ID\",\n \"resourceAttributes\": [\n {\n \"attributeDefinitionId\": \"data_identifiable\",\n \"values\": [\n \"de-identified\"\n ]\n }\n ]\n}\n```\n\n### PowerShell\n\nThe following sample shows a `POST` request using Windows PowerShell: \n\n```bash\n$cred = gcloud auth application-default print-access-token\n$headers = @{ Authorization = \"Bearer $cred\" }\n\nInvoke-WebRequest `\n -Method Post `\n -Headers $headers `\n -ContentType: \"application/consent+json; charset=utf-8\" `\n -Body \"{\n 'user_id': '\u003cvar class=\"edit\" translate=\"no\"\u003eUSER_ID\u003c/var\u003e',\n 'data_id' : '\u003cvar class=\"edit\" translate=\"no\"\u003eDATA_ID\u003c/var\u003e',\n 'resource_attributes': [{\n 'attribute_definition_id': 'data_identifiable',\n 'values': ['de-identified']\n }]\n }\" `\n -Uri \"https://healthcare.googleapis.com/v1/projects/\u003cvar class=\"edit\" translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e/locations/\u003cvar class=\"edit\" translate=\"no\"\u003eLOCATION\u003c/var\u003e/datasets/\u003cvar class=\"edit\" translate=\"no\"\u003eDATASET_ID\u003c/var\u003e/consentStores/\u003cvar class=\"edit\" translate=\"no\"\u003eCONSENT_STORE_ID\u003c/var\u003e/userDataMappings\" | Select-Object -Expand Content\n```\n\nIf the request is successful, the server returns a response similar to the\nfollowing sample in JSON format: \n\n```\n{\n \"name\": \"projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/consentStores/CONSENT_STORE_ID/userDataMappings/USER_DATA_MAPPING_ID\",\n \"dataId\": \"DATA_ID\",\n \"userId\": \"USER_ID\",\n \"resourceAttributes\": [\n {\n \"attributeDefinitionId\": \"data_identifiable\",\n \"values\": [\n \"de-identified\"\n ]\n }\n ]\n}\n```\n\n\u003cbr /\u003e\n\nConfiguring data IDs\n--------------------\n\nThe `data_id` field of the user data mapping resource contains a\ncustomer-specified string that describes the data that the user data mapping resource\nrefers to. Any string is permitted, such as an opaque ID or URI.\n\nData IDs can be as granular as is required by your application. If\nthe data you are registering can be described at the\ntable or bucket level, define `data_id` as the REST path to that resource.\nIf the data you are registering requires more granularity,\nthen you may want to specify specific rows or cells. If your application uses conceptual resources, such as permitted actions or classes of data, you should\ndefine `data_id` with a convention that supports those use-cases.\n\nExamples of a `data_id` that describes data stored in different services and at\nvarious levels of granularity include, but are not limited to, the following:\n\nGoogle Cloud Storage object\n\n\u003cbr /\u003e\n\n```\n 'data_id' : 'gs://BUCKET_NAME/OBJECT_NAME'\n \n```\n\n\u003cbr /\u003e\n\nAmazon S3 object \n\n```\n 'data_id' : 'https://BUCKET_NAME.s3.REGION.amazonaws.com/OBJECT_NAME'\n \n```\n\nBigQuery table\n\n\u003cbr /\u003e\n\n```\n 'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID'\n \n```\n\n\u003cbr /\u003e\n\nBigQuery row (there is no REST path for a BigQuery row, so your own identifier is necessary - one possible approach is below)\n\n\u003cbr /\u003e\n\n```\n 'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID/myRows/ROW_ID'\n \n```\n\n\u003cbr /\u003e\n\nBigQuery cell (there is no REST path for a BigQuery cell, so your own identifier is necessary - one possible approach is below)\n\n\u003cbr /\u003e\n\n```\n 'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID/myRows/ROW_ID/myColumns/COLUMN_ID'\n \n```\n\n\u003cbr /\u003e\n\nFHIR resource\n\n\u003cbr /\u003e\n\n```\n 'data_id' : 'https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/Patient/PATIENT_ID'\n \n```\n\n\u003cbr /\u003e\n\nConceptual representation\n\n\u003cbr /\u003e\n\n```\n 'data_id' : 'wearables/fitness/step_count/daily_sum'\n \n```\n\n\u003cbr /\u003e"]]
