访问权限判定请求由应用发出,该应用需要知道拟议用途是否被允许访问某个特定数据元素、与某个用户关联的所有数据元素或整个数据存储区。Consent Management API 会评估是否存在为指定数据和拟议用途授予权限的有效许可,从而判定是否允许请求。Consent Management API 会按以下方式执行此评估:
Consent Management API 收到访问权限判定请求,其中包含拟议用途的请求特性值以及目标资源(或由用户 ID 或资源特性值描述的目标资源范围)。
如果指定了目标资源范围,Consent Management API 会确定与该范围相匹配的资源。例如,如果您定义了某个范围的资源特性值,则该范围内的所有资源都会用在访问权限判定请求中。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003eThe Consent Management API securely manages user consent and privacy, storing user consent information and tracking permitted data usage.\u003c/p\u003e\n"],["\u003cp\u003eApplications interact with the Consent Management API by creating consent records, registering data locations, and querying for access determination based on user consents.\u003c/p\u003e\n"],["\u003cp\u003eThe API serves as a policy decision point, storing consent policies, evaluating data access queries, and enforcing consent policies for authorized applications.\u003c/p\u003e\n"],["\u003cp\u003eThe Consent Management API supports various policy enforcement patterns, including enforcement by trusted applications, customer middleware, and resource servers.\u003c/p\u003e\n"],["\u003cp\u003eConsent records, including consent artifacts and consent resources, are stored within the API, alongside user data mappings to track data stored in different locations.\u003c/p\u003e\n"]]],[],null,["# Consent and privacy overview\n\nThis page describes the Consent Management API and how to use it to manage user\nconsent and privacy.\n\nThe Consent Management API is a component of your consent and privacy architecture\nand provides scalable and secure management of your user's consent\nand data privacy. The Consent Management API stores the consent information you\nreceive from users, keeps track of what data is permitted for each use case, and\nhelps your application utilize data only as directed by your users.\n\nConsent Management API information flow\n---------------------------------------\n\nThe flow of consent and privacy information within the Consent Management API is as\nfollows:\n\n1. Your application presents privacy options to a user, then creates or revises a consent record within the Consent Management API to represent that user's decision.\n2. As your application writes data to its various data stores, your application registers the location and characteristics of that data with your Consent Management API instance.\n3. When an application needs to determine whether data is consented for a particular use case, it makes a request to the Consent Management API with the requested data and the proposed use.\n4. The Consent Management API compares the requested data and proposed use to the stored consents and returns a positive response if a valid consent exists. A negative response is returned if a valid consent doesn't exist.\n\nThe following diagram shows the Consent Management API information flow:\n\nFor more information on how consent data is organized within the\nConsent Management API, see\n[Consent Management API data model](/healthcare-api/docs/concepts/consent-model).\n\nPolicy decision point\n---------------------\n\nThe Consent Management API acts as the policy decision point within your consent and\nprivacy architecture as follows:\n\n1. Stores the consent policies granted by your applications' users.\n2. Accepts data access queries made by authorized client applications.\n3. Evaluates access queries against the stored consent policies.\n4. Makes access determinations to enforce consent policies for client applications.\n\nPolicy enforcement\n------------------\n\nThe Consent Management API supports policy enforcement within your consent and\nprivacy architecture as follows:\n\n1. Processes access determination queries made by applications or policy enforcement points.\n2. Evaluates if a resource can be accessed for a specified purpose.\n3. Determines all the resources that can be accessed for a specified purpose.\n4. Links resources to attributes and consent policies so enforcement points only need to specify request attributes and an optional resource name.\n5. Returns access determinations using the current consent state, even as consents are added, updated, or revoked.\n\nYou can implement more than one policy enforcement pattern using the\nConsent Management API within your consent and privacy architecture. The following\nlist shows examples of policy enforcement patterns:\n\n- **Enforcement by trusted applications**. Applications that have verified a user's identity and qualifications can forward the relevant properties to the Consent Management API. This allows users to submit or update consents and allows applications, with verified qualifications, to access only the consented information for their use case.\n- **Enforcement by customer middleware**. Applications that require the verification of a user's identity and qualifications can use the Consent Management API to determine whether access is allowed for a given request.\n- **Enforcement by resource servers**. Resource servers can use a user's identity to retrieve qualifications from other applications, if necessary, and then call the Consent Management API to determine access before fulfilling requests.\n\nPolicy representation\n---------------------\n\nConsent policies within the Consent Management API are composed of a set of resource\nattribute values that define what data that policy applies to and an\nauthorization rule that defines the conditions under which that policy is valid.\n\nWhen multiple values are specified for a single resource attribute, the policy\napplies to data matching any of those values. When multiple resource\nattributes appear in a policy, each of those resource attributes must match for\nthe policy to apply.\n\nAuthorization rules use a [constrained variation](/healthcare-api/docs/how-tos/consent-creating#creating_a_consent)\nof the Common Expression Language (CEL) to flexibly describe the relationships\nbetween request attributes values that permit access to the relevant data. For\nmore information on CEL, see\n[Common Expression Language](https://github.com/google/cel-spec/blob/master/doc/intro.md).\n\nConsent resources can contain multiple consent policies that could represent a\npositive response to consent questions presented to a user. Consent policies\ncould also be used to represent entire consent forms or organizational\nand administrative decisions.\n\nThe following diagram shows how policies are represented in the\nConsent Management API:\n\nThis diagram shows how to construct simple consent policies using resource\nand request attributes. More complex policies can be constructed by combining\ntwo or more policies.\n\nConsent records\n---------------\n\nThe Consent Management API stores the following types of consent records:\n\n- **Consent artifacts**: store the documents that were accepted or signed by the user. These records can contain PDFs or images of the screens shown to the user during the consent process. They can also be used to store signatures, timestamps, and other important information that document the consent process.\n- **Consent resources**: describe the consent that was given by the user in terms of the configured consent attributes. The Consent Management API evaluates these records to determine whether data is consented for a use case. Consent resources contain the granted consent and the consent status. These records can also be linked to the corresponding consent artifacts.\n\nFor more information on consent records, see\n[Creating and updating user consents](/healthcare-api/docs/how-tos/consent-creating).\n\nData management\n---------------\n\nThe Consent Management API can manage data stored in your own schemas on Google Cloud,\non-premises, or with another cloud provider as long as the data can be described\nusing a string. The Consent Management API uses user data mappings to track the\nmanaged data without that data needing to be stored within the service itself.\n\nEach user data mapping contains a data ID, a user ID, and a set of resource\nattribute values. The data ID is a string that uniquely identifies the data\nrepresented by the user data mapping. The user ID is an opaque identifier that\nlinks that data to a user. The resource attribute values describe the\ncharacteristics of the data using a vocabulary defined by the attribute\ndefinition resources.\n\nThe following are common storage locations for consent-managed data:\n\n- FHIR stores\n- BigQuery\n- Cloud Storage\n\nFor more information on creating user data mappings, see\n[Registering user data](/healthcare-api/docs/how-tos/consent-registering-user-data).\n\nAccess determination\n--------------------\n\nAccess determination requests are made by applications that need to know if the\nproposed use is permitted to access a specific data element, all data elements\nassociated with a user, or whole data stores. The Consent Management API determines\nif a request is permitted by evaluating whether or not there is a valid consent\nthat grants permission for the specified data and proposed use. The\nConsent Management API performs this evaluation as follows:\n\n1. The Consent Management API receives an access determination request with request attribute values for the proposed use and either a target resource or a range of target resources described by user IDs or resource attribute values.\n2. If a range of target resources is specified, the Consent Management API determines the resources that match the range. For example, if you define a range of resource attribute values, all resources within this range are used in the access determination request.\n3. Consents for all matched resources are identified.\n4. The proposed use is evaluated against the authorization rules of the relevant consents.\n5. If any of the authorization rules permit this combination of request attribute values, a positive access determination is returned for each resource evaluated.\n\nBy default, access determination is only made on active consents. Consents in\nthe draft state can be included in the access determination by specifying them\ndirectly in the access determination request. Consents that are expired,\nrevoked, or in the rejected state are ignored in all access determination requests.\n\nFor more information on making access determination requests, see\n[Making access determinations](/healthcare-api/docs/how-tos/consent-access-determination)."]]