Nutzerdaten registrieren

Auf dieser Seite wird das Registrieren von Nutzerdaten über die Consent Management API beschrieben.

Datenelemente werden bei der Consent Management API registriert und mithilfe von Nutzerdatenzuordnungen mit Einwilligungen verbunden. Nutzerdaten werden nie in der Consent Management API gespeichert.

Die Nutzerdatenzuordnungen, dargestellt als UserDataMappings-Ressourcen, enthalten folgende Elemente:

• Eine Nutzer-ID zur Identifizierung des Nutzers. Diese ID stimmt mit der ID überein, die die Anwendung bei der Registrierung der Einwilligung über die Consent Management API bereitgestellt hat.
• Eine Daten-ID zur Identifizierung von an anderer Stelle gespeicherten Nutzerdaten, z. B. in Google Cloud oder lokal. Die Daten-ID kann eine intransparente ID, eine URL oder eine beliebige andere Kennung sein.
• Ressourcenattribute, die die Merkmale der Nutzerdaten mithilfe von Ressourcenattributwerten beschreiben, die mit Attributdefinitionen für den Einwilligungsspeicher konfiguriert wurden. Beispielsweise können die Daten das attribute_definition_id data_identifiable mit dem Wert de-identified enthalten.

Das folgende Diagramm zeigt den Datenfluss zum Erstellen von Nutzerdatenzuordnungen:

Nutzerdatenzuordnungen registrieren

Verwenden Sie die Methode projects.locations.datasets.consentStores.userDataMappings.create, um eine Nutzerdatenzuordnung zu erstellen. Stellen Sie eine POST-Anfrage und geben Sie die folgenden Informationen in der Anfrage an:

• Der Name des übergeordneten Einwilligungsspeichers
• Ein einmaliges und undurchsichtiges userID-Element, das den Nutzer darstellt, mit dem das Datenelement verknüpft ist
• Eine Kennung für die Nutzerdatenressource, z. B. der REST-Pfad zu einer eindeutigen Ressource
• Eine Reihe von RESOURCE-Attributen, die das Datenelement beschreiben
• Ein Zugriffstoken

curl

Das folgende Beispiel zeigt eine POST-Anfrage mit 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"

Wenn die Anfrage erfolgreich ist, gibt der Server eine Antwort wie die folgende im JSON-Format zurück:

{
  "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

Das folgende Beispiel zeigt eine POST-Anfrage mit 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

Wenn die Anfrage erfolgreich ist, gibt der Server eine Antwort wie die folgende im JSON-Format zurück:

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

Daten-IDs konfigurieren

Das Feld data_id der Ressource für die Nutzerdatenzuordnung enthält einen vom Kunden angegebenen String, der die Daten beschreibt, auf die sich die Nutzerzuordnungsressource bezieht. Jeder String ist zulässig, z. B. eine intransparente ID oder ein URI.

Die von Ihrer Anwendung benötigten Daten-IDs können beliebig detailliert sein. Wenn die Daten, die Sie registrieren, auf Tabellen- oder Bucket-Ebene beschrieben werden können, definieren Sie data_id als REST-Pfad zu dieser Ressource. Wenn die Daten, die Sie registrieren, mehr Granularität benötigen, können Sie bestimmte Zeilen oder Zellen angeben. Wenn Ihre Anwendung konzeptionelle Ressourcen wie zulässige Aktionen oder Datenklassen verwendet, sollten Sie data_id mit einer Konvention definieren, die diese Anwendungsfälle unterstützt.

Beispiele für data_id, in denen in verschiedenen Diensten gespeicherte Daten auf verschiedenen Detaillierungsgraden beschrieben werden:

Google Cloud Storage-Objekt

  'data_id' : 'gs://BUCKET_NAME/OBJECT_NAME'
  

Amazon S3-Objekt

  'data_id' : 'https://BUCKET_NAME.s3.REGION.amazonaws.com/OBJECT_NAME'
  

BigQuery-Tabelle

  'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID'
  

BigQuery-Zeile (Es gibt keinen REST-Pfad für eine BigQuery-Zeile. Daher ist Ihre eigene Kennzeichnung erforderlich – ein möglicher Ansatz ist unten aufgeführt.)

  'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID/myRows/ROW_ID'
  

BigQuery-Zelle (Es gibt keinen REST-Pfad für eine BigQuery-Zelle, daher ist Ihre eigene Kennzeichnung erforderlich – ein möglicher Ansatz ist unten aufgeführt)

  'data_id' : 'bigquery/v2/projects/PROJECT_ID/datasets/DATASET_ID/tables/TABLE_ID/myRows/ROW_ID/myColumns/COLUMN_ID'
  

FHIR-Ressource

  'data_id' : 'https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FHIR_STORE_ID/fhir/Patient/PATIENT_ID'
  

Konzeptionelle Darstellung

  'data_id' : 'wearables/fitness/step_count/daily_sum'