Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Developed by Ain Aaviksoo (Estonian Telecommunications Union), Benjamin Balder Bach (fmly Danish Tax & Revenue), Lal Chandran (MyData Global, iGrant.io), Philippe Page (MyData Global, Human Colossus Foundation). And advisors Dr. P. S. Ramkumar (ITU), Max Carlson (GovStack), Sasikumar Ganesan (MOSIP)
This section links to any external documents that may be relevant, such as standards documents or other descriptions of this Building Block that may be useful.
A historical log of key decisions regarding this Building Block.
A list of topics that may be relevant to future versions of this Building Block.
This section provides context for this Building Block.
The Consent Building Block enables services for individuals to approve the use of their personal data by defining the principles, functions, and architecture of an information system. For organisations that process personal data, it provides the ability to know the individual's will and legitimately process such personal data. The Consent Building Block is a process-oriented GovStack Building Block facilitating auditable bilateral agreements within a multi-agent environment that integrates with most other Building Blocks.
This specification has used several available and recognised open standards below and legal frameworks (such as the GDPR) for laying the groundwork for its approach to consent.
Kantara Initiative - Consent Specification
ISO 29184: 2020: Online Privacy Notices and Consent
ISO/IEC 29100:2011: Privacy Framework
ISO/TS 17975:2015 Health informatics — Principles and data requirements for consent in the Collection, Use or Disclosure of personal health information
ISO/IEC TS 27560 — Consent record information structure (under development)
In the GovStack context, consent is understood as a voluntary declaration by an individual to approve the processing of their Personal data. It is one specific justification for personal data processing that is assumed to be required by legal or ethical conditions. It assumes that the person can decide on processing their personal data, managed in and by other GovStack Building Blocks, and also that the person is free to withdraw their consent at any time.
Some examples of such consent are:
allowing a healthcare provider to fetch socio-demographic data from a government-run population registry to provide adequate primary healthcare services.
allowing a government official to fetch relevant data from other/multiple government-run registries to analyse the eligibility for a social benefit programme.
allow a government official to send personal data to a bank for cash transfers on behalf of the government.
The use of consent should be avoided in cases as below, which are not part of this specification:
When a person is simply informed of the processing of the data by the organisation as part of the service provided under contract or by an authority.
When consent does not have to be obtained in a situation where the entity does not identify or cannot identify people with reasonable effort.
Lays out the pre-conditions needed for anyone to use the Consent Building Block.
Data Disclosure Agreements between organisations are already in place. For example, a healthcare organisation has already got the required authorisation to use the citizen data registry.
To link a Consent Agreement with the specific Individual, Consent Building Block assumes the authentication and authorization to be handled in a trusted manner outside of it (see below).
Within the early scope of the Consent Building Block, the act of delegating is kept outside the scope of the Consent Building Block. It is assumed that the authorisation to act on behalf of someone else is already resolved.
It is the organization's (a Data Provider or a Data Consumer) obligation to manage and implement internal policies toward its employees relating to their responsibilities for Personal data processing integrity, specifying it in the employment contract or by other means.
The life cycle of a consent agreement starts and ends within the organisation responsible for the information system. The organisation knows the context in which the information system operates and the intended purpose of the service. The rules and regulations to be applied for a given level of assurance define the functional framework for consent management.
Consent Building Block deals with transparency on data usage in a given context. Thus privacy-by-design of the system's actors is often an excellent guiding principle for interpreting international, national, and organisational policies and governance principles to implement the functional consent framework. A tangible outcome from a Data Protection Impact Analysis (DPIA) is a structured approach that can deliver the input for the actual implementation of the Consent Building Block.
Individual consent is captured within the context of digital interaction. This interaction is composite of all the information systems involved, not solely the Consent Building Block. Thus, the legal and ethical boundaries of consent are defined in the entirety of the interaction. In particular, consent, as defined by ISO/TS 17975:2015(E), should be seen as a "set of agreements and constraints" that an informed and knowledgeable [individual] agrees to apply to their data processing. This definition, not based on the purpose of the data usage, can lead to a consent management framework also incorporating authorisations or unrelated constraints of the system. For example, in health information and healthcare service delivery, consent is also the process whereby a set of constraints is agreed upon so that information may be collected and used or disclosed. However, it is also the outcome of the process. As a rule of thumb, limiting unintended secondary usage of data is helpful to separate "consent" for a purpose from "consent" as an agreement to constraints and authorisation imposed by the system's functional requirements.
As a result, the organisation responsible for the information system is the driver of the definition of the functional consent management framework. It is also the function of the organisation to design the workflow for obtaining and processing the consent in a way that is purposeful, but not annoying for individuals or data processors with unnecessary bureaucratic overhead. From this framework, the Consent Building Block achieves its purpose by employing Consent Agreements that contain the following:
A data policy that could be reused across multiple consent agreements (for example, based on the General Data Protection Regulation or any specific regulation)
The purpose of consent, processed data attributes
Signatures
A consent agreement life-cycle has four main phases[^2], as illustrated in the figure below:
Definition: In this phase, the organisation (a Data Provider or a Data Consumer) adopts and defines a Data Policy that applies to the industry or sector-specific data usage as a template. While this phase is considered a “black box” to the Consent Building Block, it is an essential reference point for configuration and compatibility checks in all following phases.
Preparation: In this phase, the organisation (Data Provider or Data Consumer) that intends to process personal data configures the Consent Agreement and relevant rules for its use. An organisation could use personal data for third-party data sharing, as an example.
Capture: In this phase, the Individual can review the Consent Agreement and, once agreed upon, it is captured in a Consent Record by the organisation and stored for verification. This allows an auditor to check and ensure records are in place to process the individual's personal data. In the future, this phase could also encompass delegation and other individual use cases.
Proof: In this phase, an organisation (A Data Provider or a Data Consumer) can demonstrate that a valid record exists for performing data processing within itself or with other organisations. This allows for internal usage and for an auditor to verify and ensure records are in place to process the individual's personal data.
Consent Building Block enables interaction between three (3) distinct user categories, which in combination create the necessary trust framework for the integrity of personal data processing. The actors are defined via distinct human roles to be performed in various consent life-cycle phases:
Individual as the subject of personal data processing;
Administrator of the information system exchanging the personal data;
Data Processing Auditor maintaining independent oversight of the data processing.
Below is the graphical depiction of the actors and their interactions; a more detailed description of the Consent Building Block capabilities is provided in Chapter 4 - Key Digital Functionalities.
It is important to realise that while the actors are defined via human roles, the consent-related interactions between such roles can be executed in machine-to-machine workflows performing tasks in the interest of the respective actor.
The overall relationship diagram is shown below.
The table below summarises the key relationships consumed during a consent transaction.
This section lists the technical capabilities of this Building Block.
The functional requirements section lists the technical capabilities that this Building Block should have. These requirements should be sufficient to deliver all functionality that is listed in the Key Digital Functionalities section. These functional requirements do not define specific APIs, they provide a list of information about functionality that must be implemented within the Building Block. These requirements should be defined by subject-matter experts and don’t have to be highly technical in this section.
Agreement Configuration Requirements.
It shall be possible to create a consent agreement, either based on an existing or new data policy template. Each consent agreement shall be under version control (REQUIRED)
It shall be possible to view an existing consent agreement (REQUIRED)
It shall be possible to update an existing consent agreement (REQUIRED)
It shall be possible to terminate an existing consent agreement (REQUIRED)
It shall be possible to capture and sign all changes to Consent Agreements, Consent Policies and Consent Records in tamper-proof Revisions (REQUIRED)
It shall be possible to subscribe to enable or disable a change notification towards users (REQUIRED)
It shall be possible to trigger a change notification when there are changes done to an existing consent agreement (RECOMMENDED)
The Building Block shall log all administrative functions (REQUIRED)
It shall be possible to view the associated consent agreement if it exists (REQUIRED)
It shall be possible to agree or opt-in or sign a consent agreement (REQUIRED)
It shall be possible to opt-out of a previously signed or agreed consent agreement (REQUIRED)
All individual consent actions shall be logged (REQUIRED)
It shall be possible to enable or disable consent change notification (REQUIRED)
It shall be possible to trigger a consent agreement change notification towards individuals (RECOMMENDED)
All consent logs shall be tamperproof, Audit logging (REQUIRED)
It shall be possible to view and verify a shared consent agreement (REQUIRED)
It shall be possible to view and verify a shared consent agreement (REQUIRED)
It shall be possible to filter and sort all objects’ revision histories can be filtered and sorted (REQUIRED)
Within the scope of Consent Building Block version 1.0, the required components are as given.
Consent Agreement Configuration Handler: handles the creation, updation & deletion of consent agreements for organisations. Organisations can be Data Providers or Data Consumers.
Consent Record Handler: enables Individuals to view data usage and consent record.
Notification Handler: handles all notification configurations and notifications requested by different subscribers.
Administrative User Interface and Client Software Development Kit: these are readily available components that can configure and use the services offered, making integration easy and low code.
RESTful APIs: All APIs are exposed as RESTful APIs. These are categorised into Organisation APIs, Individual APIs, and Auditing APIs.
This section provides a reference for APIs that should be implemented by this Building Block.
This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.
The GovStack non-functional requirements document provides additional information on how 'adaptors' may be used to translate an existing API to the patterns described here. This section also provides guidance on how candidate products are tested and how GovStack validates a product's API against the API specifications defined here.
The tests for the Consent Building Block can be found in this GitHub repository.
The following is an automated rendition of our latest OpenAPI YAML specification.
Key Digital Functionalities describe the core (required) functions that this Building Block must be able to perform.
The Consent Building Block enables organisations to enforce Data Policies that require signed consent by Individuals for the use of their personal data. Its key purpose is to allow individuals to view Consent Agreements and sign or withdraw their consent on what personal data is used and accessible to organisations. It also clarifies the Data Policy applied, such as the purpose, retention period, jurisdiction, third-party data sharing, etc.
The Consent Building Block implements the key functionalities described in the consent management lifecycle. It includes the ability to configure consent agreements by an organisation admin, present consent requests towards individuals, capture consents, enable queries if consent exists, or not, and enable independent audit of consents.
The functionalities are derived from the consent agreement lifecycle and categorised according to the Actors described above. While the consenting workflows (as described above) are implicitly considered the centrepiece of the Consent Building Block, it is important to realise that the integrity of consent management can only be achieved if robust configuration before and auditing after the Consent Agreement signing and Consent Record verification activities are in place. Hence, the functionalities are described following the logical sequence of the consent agreement lifecycle and they are all equally important components of the Consent Building Block.
The Consent process (creating and signing Consent Agreements and Consent Records) is initially managed in the application provided by the Organisation that is legally required to collect the consent. Since it can be either a Data Consuming organisation or a Data Providing organisation, the Consent Building Block allows both to be able to verify their conformance with the underlying Data Policy, both organisations must be able to access and use the application.
While the Actors generally fall in line with the categories of the functionalities, it is important to realise that “auditing” functions in the narrow sense, verifying if data processing is being (or has been) processed according to the Data Policy requiring a consent, is relevant to various entities involved in the data processing. For this reason, the generic “verification” activity may be executed as part of various workflows satisfying the needs of different actors.
Following is the first core set of key functionalities of the Consent Building Block. For potential future developments of the specification follow the work in progress at GovStack confluence page.
The Administrator (Data Provider or Data Consumer Admin) configures the Consent Building Block on behalf of the organisation. For simplicity, it is foreseen that one organisation involved in the data processing transaction (that is either Data Provider or Data Consumer) takes the responsibility for the configuration of the Data Policy and respective Consent Agreements(s), and so that the organisation’s Administrator maintains the required configurations.
The main Administrator actions expected to perform via Consent Building Block are:
configuring Data Policies, requesting and signing Consent Agreements with Individuals;
viewing (reading, exporting) the Consent Agreements and relevant reports;
event-driven (opt-in or opt-out) subscription to (notifications of) changes in Consent Agreements;
logging and maintaining an auditable overview of all personal data transactions according to Consent Agreements as well as configuration versions.
The table below summarises the key use cases identified for an organisation's Administrator. Organisations can be Data Consumers or Data Providers, i.e. the organisations legally delegated the responsibility for collecting consent for the systems handling personal data processing.
The capabilities for individuals that Consent Building Block supports are:
viewing and understanding Data Policies applying to their personal data processing;
agreeing and disagreeing with and toggling between the conditions of personal data use as described in the Consent Agreement;
obtaining copies of their Consent Agreement(s);
delegating their consent rights (out-of-scope for current technical release).
The scope for version 1.0 of Consent Building Block assumes that the Individual is acting for themselves. Ultimately the Consent Building Block will include in the Consenting Process the capacity to sign a Consent Agreement in the name of another individual - to act as the Delegate, which is used as the criterion for technical implementation. However, the Delegate and the Individual relationship is expected to be maintained outside of the Consent Manager, which assumes that the person signing the Consent Agreement (i.e. Consenter) has been authorised to do so.
The table below summarises the key use cases identified for the Individuals.
Important note: In the Consent Building Block, we define the Data Processing Auditor's role (see 1.3 Terminology and 1.5.3 Actor definition) as an organisation's auditor implementing the Consent Building Block. The auditor role will most probably be akin to a Data Protection Officer (DPO), possibly from an external third-party organisation and involve activities outside of the Consent Building Block.
To avoid ambiguity, we use the precise term Data Processing Auditor to stress the specificity of tasks to be performed by and for the Consent Building Block; all other actions not within the Consent Building Block's scope are considered as an external prerequisite and as a “black box” activity. With respect to audit, this role is distinguished from the data policy auditor.The Data Processing Auditor relies on an audit universe defined by the control and risk management of the specific project and context (i.e. outside the Consent Building Block). “Who needs to consent to what” is the outcome of a DPIA (Data Protection Impact Analysis), ensuring that the data policies are compliant with the relevant data protection regulations for the project.
The main actions a Data Processing Auditor (or Data Protection Officer, DPO) is expected to perform via Consent Building Block are:
auditing tracking the consents (opt-in/opt-out);
auditing tracking Data Policy changes and configuration conformance with it;
viewing (reading, exporting) the Consent Agreements and relevant reports in a verifiable form.
For the implementation of a specific use case, it is important to distinguish the Data Processing Auditor, an actor described here, from a data policy auditor, an actor of the risk organisation. It is expected that the two roles are coordinated in the risk management process. Within the Consent Building Block, the Data Processing Auditor performs the tasks that will allow a data policy auditor to confirm that the implemented system complies with existing regulations demanding consent.The table below summarises the key use cases identified for the Data Processing Auditor.
Also to consider: “READ CONSENT STATUS” use-case is also used by any workflow (and Actor) that requires verification of the consent status (for example, before executing the data transfer from Data Providing System to the Data Consuming System).
As described above under Universal Consenting Workflows, there may be an unlimited number of business processes that require consent. The following scenarios are but a few examples illuminating how appropriate access to data can and should be handled when processing or consuming data with the support of Consent Building Block functionalities.
This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block.
The cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the architecture specification document. Any implementation MUST adhere to all requirements from GovStack Security Requirements.
Personal data MUST be kept private and never shared with any parties, except where specific authorisation has been granted. The Consent Building Block shall follow the privacy principles as laid out in the GovStack architecture.
Logs MUST be kept in a database of all created, updated, or deleted records. Logs MUST include timestamps and identify the user and affiliation that performed the transaction.
In general, the Consent Building Block shall follow the authentication and authorisation requirements as laid out in the . For clarity, Consent Building Block's API endpoints are invoked with a client-supplied API key which must defer to the Identification and Verification Building Block in order to verify the role and/or scope of the API key matches the API endpoint to which it is supplied. This is mentioned here, as this definition is drafted without clear guidance in the OpenAPI specification for the handling of roles and scopes.
In general, the Consent Building Block shall follow the authentication and authorisation requirements as laid out in the Govstack architecture. For clarity, Consent Building Block's API endpoints are invoked with a client-supplied API key which MUST defer to the Identification and Verification Building Block in order to verify the role and/or scope of the API key matches the API endpoint to which it is supplied. This is mentioned here, as this Definition is drafted without clear guidance in the OpenAPI spec for the handling of roles and scopes.
This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.
A workflow provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases. This section lists workflows that this Building Block must support. Other workflows may be implemented in addition to those listed.
The Workflow Building Block triggers the need for consent as part of the general business flow. The assumption is that a consenting process never exists outside of a purposeful comprehensive business process. Hence, it is important to define and control the data processing activities as part of a holistic data service. This section lays out key universal consent workflows that can be re-used within the various use cases (see Workflow Building Block). This enforces the best practices for organisations to adhere to personal data processing standards in any given context and jurisdiction. In these sequences, we have removed the Digital Registries Building Block in the sequence for simplicity. It will store all persistent consent data.
The first and somewhat unique use case is related to the need for consent when the Individual is not yet provisioned in the System processing the data. In such cases, the workflow requires the creation of a valid and trusted Foundational ID to be linked with the Consent Record. Below is shown how a pre-registration use of Consent's Workflow works.
In more frequent situations, when the Individual is already provisioned in the System (post-registration), the consent workflow uses the existing ID tokens, and only the Consent Record is to be created. The following diagram shows how a generic post-registration use of consent works:
The third universal workflow is about verifying if a valid Consent Record exists or not for a given data processing event within a business process. This may be the immediate continuation of a consenting workflow by the same System that acquired the Consent Record or it may be used by a separate business process by a different Application or at a different moment in time. The same verification workflow may be also used for auditing purposes. The following diagram shows how a generic verification for valid Consent works:
This section provides information on the core data structures/data models that are used by this Building Block.
The resource model shows the relationship between data objects that are used by this Building Block. Data objects are ultimately modelled as OpenAPI schemas, however as the relational model isn’t easy to understand from OpenAPI specification, we start by presenting two high-level Resource Models.
When an individual gives consent, it is implied that the Organisation from one side and the Individual from the other side digitally sign a Consent Agreement and a respective Consent Record is created. The alternative scenario may be that signing takes place offline on a paper, but in this case, for the Consent Building Block to function properly, it is the responsibility of the Organisation to digitise (e.g. scan) the signed document and create digitally signed artefact to represent the Consent Record.
This Consent Record is a digital instance referencing the Agreement which is consented to or subsequently has consent withdrawn from.
This model expands the relationships between resources.
Revisions are maintained for Consent Records + Agreements and Data Policies, together with cryptographic signatures. This means that all changes are captured for auditability.
For a configured Agreement, data elements requiring consent are individually specified as Agreement Data. Agreement Data is not directly relatable to processes and internals of an external system. This architectural choice gives the consent model flexibility and greatly simplifies the architecture and consent lifecycle, but it does not contradict any additional features, allowing for relations to external systems.
Individual changes Consent Record.
Individual withdraws/revokes Consent Agreement.
Consent Record expires.
Consent Record expiry date changes.
Organisation replaces Consent Agreement.
Organisation replaces Data Policy.
Individual gives access to citizen data, using a third-party user interface (Consumer’s user interface). Example: COVID passports.
The following standards are applicable to data structures in the Registration Building Block:
All dates should follow ISO 8601.
RFC 7159 - The JavaScript Object Notation (JSON).
OpenAPI Version 3.1.0.
RESTful APIs follow TM Forum Specification: “REST API Design Guidelines Part 1” (requirement derived from GovStack Architecture and Nonfunctional Requirements).
This specification is seen as a minimum requirement, all further implementations may add more structure but should not compromise the minimal integrity laid out. All property types are generic, and a concrete implementation may add further specificity to these models.
The OpenAPI definition file is maintained in YAML format, and OpenAPI schemas may be interactively explored in the next section.
Following are four use-case descriptions required for Data Processing Auditor functionalities
| ID | UC-C-PIC-AT-001 |
|---|
Following are the use-case descriptions required for individual consent service operations: viewing, giving, withdrawing and verification of consent as well as getting notifications about changes.
Context: Postpartum and infant care
| ID | UC-C-PIC-I-001 |
|---|
Diagram Source
There are three alternatives possible for giving consent:
The above are detailed in the subsequent chapters.
Note: Here, the sequence shows the case for assisted registration flow. The same applies also for self-registration.
Diagram Source
Following are the use-case specifications required by the organisation IT administrators for updating Data Policies required for an identified Consent Agreements (within postpartum and infant care)
The following sequence diagrams details the role of the Independent Authority and the DPIA (Data Protection Impact Assessment) as the document upon which the postpartum infant care program can rely to parametrise the healthcare application for interacting with the consent management BB.
The version history table describes the major changes to the specifications between published versions.
| Version | Authors | Comment |
|---|
| Building Block | Relationship description |
|---|---|
| ID | UC-C-PIC-AT-002 |
|---|
| ID | UC-C-PIC-AT-003 |
|---|
| ID | UC-C-PIC-AT-004 |
|---|
| ID | UC-C-PIC-I-002A |
|---|
| ID | UC-C-PIC-I-002B |
|---|
| ID | UC-C-PIC-I-002C |
|---|
| ID | UC-C-PIC-I-003 |
|---|
| ID | UC-C-PIC-I-004 |
|---|
Identity Building Block
It is assumed the Consent Building Block has already obtained requisite access tokens.
Digital Registries Building Block
This is used to store any consent agreement, individual consent receipts etc.
Workflow Building Block
Manages the workflow and rules associated with requiring or not requiring consent to use personal data.
Scheduler Building Block
Provides an engine for time-based triggers to various events of an automated business process, which might also require consent.
Information Mediator Building Block
The information mediator Building Block provides a gateway for exchanging data related to consenting workflows; it also provides logs for auditing purposes.
Consent use-cases
Link(s) to the UCS
CREATE CONSENT AGREEMENT - Here, an organisation Administrator creates a Consent Agreement based on the Data Policy requirements.
UPDATE CONSENT AGREEMENT - Here, an organisation Administrator updates the Consent Agreement based on the Data Policy requirements.
READ CONSENT AGREEMENT - Here, an organisation Administrator reads the Consent Agreement.
DELETE CONSENT AGREEMENT - a special case of consent agreement update.
CONSENT AGREEMENT CHANGE NOTIFICATION - Notifications for Data Providing and Data Consuming Systems, as well as Individuals upon changes to Agreement or Policy configuration.
Consent use-cases
Link to the UCS
VIEW CONSENT - Here, the Individual views the Consent Agreement and the conditions for personal data processing (with adequate clarity for informed understanding). This includes obtaining copies of the consent agreement.
GIVE CONSENT - Here, the Individual signs a Consent Agreement during a data sharing workflow. Note that this can also happen offline without data sharing in place.
WITHDRAW CONSENT - Or update existing consent
Consent agreement change notification
Consent use-cases
Link to the UCS
AUDIT CONSENT - Query the Consents related to individuals or policies (opt-in/opt-opt)
MONITOR POLICY UPDATE- Tracking Data Policy changes and configuration conformance with it;
READ CONSENT STATUS - Viewing (reading, exporting) the Consent Agreements and relevant reports in a verifiable form
VERIFY CONSENT INTEGRITY - Ability to check the integrity of the signed agreements
Scenario
Source Building Block
Target Building Blocks
Description
1.1 Querying: Which Consent Agreement is needed for specified data processing/ consumption?
Any
Workflow Building Block
Consent Building Block does have knowledge or state to resolve which Data Consumer or Data Producer requires consent. Everything regarding consent has a precondition that a decision is made and manifested in the Workflow Building Block or any other Data Consumer.
1.2 Data processing/ consuming system stores/fetches data with consent + prompts the user if none exists
Any
Consent Building Block
Given an Agreement ID and a User ID, the Consent Building Block can resolve if consent exists and possibly prompt the user. Workflow Building Block is especially inappropriate here because of User Interface integration and a blocking and sequential call stack.
1.3 Data processing/ consuming system stores/ fetches data with consent, no halts operations without consent
Any
Workflow
Given an Agreement ID and a User ID, the Workflow Building Block can complete an atomic action requiring consent. Operations shall not proceed if consent does not exist.
1.4 Data processing/ consuming system stores/ fetches data with consent, consent is prompted asynchronously
Any
Workflow
The Workflow Building Block may halt operations and asynchronously prompt the user for consent if none exists (or is invalid). After fetching consent, the Workflow Building Block should revert to the targeted data consuming/ processing operation.
1.5 Appropriate access to data that does not require consent
Any
Workflow
Not necessarily related to Consent Building Block.
1.2-1.4 Side effects
Workflow
Any attempt to read consent and process/consume data is logged and auditable.
2.1 Inappropriate access: Data processing/consuming system inappropriately stores/fetches data without consent
Any
N/a
Any consent-requiring data access is assumed logged.
Auditing of inappropriate data access is only possible when a log trace exists.
3.1
Workflow
Consent
Given an Individual, query if active Consent Records exist (for instance, to spot if other external data needs to be kept).
4.1
Any
Consent
Fundamental individual rights (General Data Protection Regulation/ Data Protection Act/ Right to be Forgotten/etc.)
4.2
Any
Consent
Fundamental individual rights (General Data Protection Regulation/Data Protection Act/etc.)
Name | Consent - Postpartum and infant care (Audit - MONITOR POLICY UPDATE) |
Description | The use case implements the tasks required to be performed when a Data Policy change occurs. This MAY require an update of the Consent Agreement and/or information to the Individual (jurisdiction dependent) |
Trigger (the event that triggers the use case) | The MONITOR POLICY UPDATE use case is triggered each time the Data Policy receives a modification. The Data Policy Auditor needs to identify consent records that require a modification of the consent agreement. |
Preconditions (list of conditions that MUST be met for the use case to be successful) | The use case assumes that the Data Policy Auditor is authorised to perform the audit. Therefore the Data Policy Auditor has all the necessary, but limited, access rights to access the information. This can be done either with a specific component of the Application that allows these access to a person outside the organisation/department owning the application or by an authorised employee of the organisation operating under the instruction of the Data Policy Auditor (whose legitimity is specified in the Audit Framework). The Organisation provides the Application Administrator with the new policy and the system updates to be done. This includes potential actions on existing consent records or communication to consentees. This use case assumes that the policy change has been processed by the organisation maintaining the system..
Same preconditions as UC-C-PIC-AT-001 AUDIT CONSENT
|
Data inputs |
And same data inputs as UC-C-PIC-AT-001 AUDIT CONSENT
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
|
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) | --- |
Data output | Audit files (incl. Supporting information) |
Post-Conditions (the success criteria) | Audit information available for further audit of the information system. |
Exceptions (error situations) | An escalation process is to be put in place if, for any reason, the Data Policy Auditor can not perform his work.. |
Related BBs (working groups related to that particular use case) | Same as UC-C-PIC-AT-001 Audit Consent |
Name | Consent - Postpartum and infant care (Audit - READ Consent status) |
Description | READ CONSENT STATUS - Viewing (reading, exporting) the Consent Agreements and relevant information from the Consent Records in a verifiable form |
Trigger (the event that triggers the use case) | For a given population of Individuals, an authorised Data Policy Auditor wants to read their Consent Record. |
Preconditions (list of conditions that MUST be met for the use case to be successful) | Application is configured. At least one Consent Record attached to a Consent Agreement for an Individual is present (ie. Consent BB is active). The use case assumes that the Data Policy Auditor is authorised to perform the audit. Therefore the Data Policy Auditor has all the necessary, but limited, access rights to access the information. This can be done either with a specific component of the Application that allows these access to a person outside the organisation/department owning the application or by an authorised employee of the organisation operating under the instruction of the Data Policy Auditor (whose legitimity is specified in the Audit Framework). |
Data inputs | The population of individuals for which the authorised Data Policy Auditor wants to read the status. |
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
|
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) | There is no Alternative Course of action. Should, for any reason, the Normal Course of action not be terminated successfully. The Data Policy Auditor MUST raise an audit finding. The Audit Framework is responsible to handle audit finding (not the application) |
Data output | Audit files (incl. Supporting information) that can be imported in the Data Policy Auditor’s system |
Post-Conditions (the success criteria) | Audit information available to the Data Policy Auditor for further audit of the Application. |
Exceptions (error situations) | An escalation process is to be put in place if, for any reason, the Data Policy Auditor can not perform his work.. |
Related BBs (working groups related to that particular use case) | Same as UC-C-PIC-AT-001 Audit Consent. |
Name | Consent - Postpartum and infant care (Audit - VERIFY Consent Integrity) |
Description | VERIFY CONSENT INTEGRITY - Ability to check the integrity of the signed agreements.
Important note: To verify the INTEGRITY, the Data Policy Auditor does not need to receive the INFORMATION in the Consent Record. For example, the names of the individual or any other personal or sensitive information do not need to be disclosed to the Data Policy Auditor for the purpose of Integrity verification. The cryptographic signature should be sufficient. Nevertheless, the auditor must receive sufficient supporting information to certify and record that this Consent Record for this agreement was signed and this time and not tempered with. The Auditor will record this information that may be used later in the audit process.nAccessing the content itself of is a different use case. This note helps to clarify a simple verification process that could be automated from a more indepth process where access to sensitive information
|
Trigger (the event that triggers the use case) | For a given Consent Record, an authorised Data Policy Auditor wants to verify the integrity of the consent.. |
Preconditions (list of conditions that MUST be met for the use case to be successful) | Application is configured. The Consent Record under investigation is already in the Application. The Consent BB is active. The use case assumes that the Data Policy Auditor is authorised to perform the audit. Therefore the Data Policy Auditor has all the necessary, but limited, access rights to access the information. This can be done either with a specific component of the Application that allows these access to a person outside the organisation/department owning the application or by an authorised employee of the organisation operating under the instruction of the Data Policy Auditor (whose legitimity is specified in the Audit Framework). |
Data inputs | The Consent Record for which the authorised Data Policy Auditor wants to verify the integrity.. |
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
|
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) | There is no Alternative Course of action. Should, for any reason, the Normal Course of action not be terminated successfully. The Data Policy Auditor MUST raise an audit finding. The Audit Framework is responsible to handle audit finding (not the application) |
Data output | Audit files (incl. Supporting information) that can be imported in the Data Policy Auditor’s system |
Post-Conditions (the success criteria) | Audit information available to the Data Policy Auditor for further audit of the Application. |
Exceptions (error situations) | An escalation process is to be put in place if, for any reason, the Data Policy Auditor can not perform his work.. |
Related BBs (working groups related to that particular use case) | Same as UC-C-PIC-AT-001 Audit Consent. |
Name | Consent - Postpartum and infant care (Give consent) |
Description | The use case allows an end-user to consent to fetch data from existing sources (possibly external to the application) or to manually fill in details during new mother registration.
In this option, the patient is doing a self-registration without any help of a healthcare assistant |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) |
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
|
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output |
|
Post-Conditions (the success criteria) |
|
Exceptions (error situations) |
|
Related BBs (working groups related to that particular use case) |
|
Name | Consent - Postpartum and infant care (Give consent) |
Description | The use case implements end-user to consent to fetch data from existing sources or to manually fill in details during new mother registration.
In this option, the patient is assisted by a healthcare assistant |
Trigger (the event that triggers the use case) | Same as UC-C-PIC-I-002A |
Preconditions (list of conditions that MUST be met in order for the use case to be successful) | Same as UC-C-PIC-I-002A |
Data inputs |
Rest same as UC-C-PIC-I-002A |
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Rest same as UC-C-PIC-I-002A |
Normal Course (what happens if the event is triggered and the preconditions have been met)
|
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output | Same as UC-C-PIC-I-002A |
Post-Conditions (the success criteria) |
|
Exceptions (error situations) |
|
Related BBs (working groups related to that particular use case) | Same as UC-C-PIC-I-002A |
Name | Consent - Postpartum and infant care (Give consent) |
Description | The use case implements end-user to consent to fetch data from existing sources or to manually fill in details during new mother registration.
In this option, the patient is using a physical or digital document or data card as a data source that is verifiable |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) | Same as UC-C-PIC-I-002A |
Data inputs | Same as UC-C-PIC-I-002A |
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) | Same as UC-C-PIC-I-002A or UC-C-PIC-I-002B
|
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output |
|
Post-Conditions (the success criteria) |
|
Exceptions (error situations) |
|
Related BBs (working groups related to that particular use case) | Same as UC-C-PIC-I-002A |
Name | Withdraw or update existing consent - Postpartum and infant care |
Description | The use case implement the withdrawal or updating of existing signed consent agreements. |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) |
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Optionally: a data intermediary or a data operator. |
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output | NA |
Post-Conditions (the success criteria) |
|
Exceptions (error situations) |
Related BBs (working groups related to that particular use case) |
|
Name | Consent agreement change notification- Postpartum and infant care |
Description | The use case implement the Consent agreement change notification for existing consent agreements |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) |
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Optionally: a data intermediary or a data operator. |
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output | NA |
Post-Conditions (the success criteria) |
|
Exceptions (error situations) |
Related BBs (working groups related to that particular use case) |
|
ID | UC-C-PIC-002 |
Name | Postpartum and infant care (Configuration UPDATE) |
Description | Here, an organisation Administrator updates Consent Agreement based on the Data Policy requirements.. |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) |
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Optionally: a data intermediary or a data operator. |
Normal Course (what happens if the event is triggered and the preconditions have been met) | TBD |
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output |
|
Post-Conditions (the success criteria) |
|
Exceptions (error situations) | (TBD - Should align with other error scenarios.) |
Related BBs (working groups related to that particular use case) |
|
0.1 | Ain Aaviksoo | Draft content created |
0.5 | Lal Chandran, Ain Aaviksoo | Ready for consent team review |
0.8 | Ain Aaviksoo, Lal Chandran, Benjamin Balder Bach, Philippe Page, Dr. P. S. Ramkumar | Ready of GovStack internal review |
0.9 RC1 | Ain Aaviksoo, Lal Chandran, Benjamin Balder Bach, Philippe Page, Dr. P. S. Ramkumar | Ready for the Technical Advisory Committee Review |
0.9 RC2 | Ain Aaviksoo, Lal Chandran, Benjamin Balder Bach, Philippe Page, Dr. P. S. Ramkumar, Sille Sepp Technical Reviewers: Tony Shannon, Saša Kovačević, Riham Moawad, Riham Fahmi, Aare Laponin, Manish Srivastava, Palab Saha, Surendra Singh Sucharia, Arvind Gupta, Gayatri. P., Shivank Singh Chauhan, Gavin Lyons Reviewer: Amy Darling | Updated according to the Technical Advisory Committee review feedback |
1.0 RC1 | Lal Chandran , Sille Sepp | Ready to be published |
1.0 | Wesley Brown, Steve Conrad, Valeria Tafoya | Final edits to align content to specification template for GovStack 1.0 release |
Name | Consent - Postpartum and infant care (Audit - AUDIT CONSENT) |
Description | The use case implements the tasks required to track the opt-in/out consent by an Individual and formalised in a Consent Agreement. This results in a new entry in a registry that will record the Individual, his/her decision and the specific Consent Agreement as well as other necessary meta-data to subsequently manage the consent (e.g. dates, Consent Agreement version, …). |
Trigger (the event that triggers the use case) | The AUDIT CONSENT use case is triggered each time a Consent Record is modified.
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) | The use case assumes that the Data Policy Auditor is authorised to perform the audit. Therefore the Data Policy Auditor has all the necessary, but limited, access rights to access the information. This can be done either with a specific component of the Application that allows these access to a person outside the organisation/department owning the application or by an authorised employee of the organisation operating under the instruction of the Data Policy Auditor (whose legitimity is specified in the Audit Framework).
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Optionally: a data intermediary or a data operator. |
Normal Course (what happens if the event is triggered and the preconditions have been met)
(See Sequence diagrams below) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output |
|
Post-Conditions (the success criteria) |
|
Exceptions (error situations) | An escalation process is to be put in place if, for any reason, the Data Policy Auditor can not perform his work.. |
Related BBs (working groups related to that particular use case) |
|
Name | View agreements - Postpartum and infant care |
Description | The use case implements the viewing and understanding consent agreements, data policies applied to personal data processing. This includes obtaining copies of the consent agreement. |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) |
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Optionally: a data intermediary or a data operator. |
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
The individual is able to withdraw consent or update existing consents as the next step of viewing all consent agreements at one place. |
Data output | None |
Post-Conditions (the success criteria) |
|
Exceptions (error situations) |
Related BBs (working groups related to that particular use case) |
|
ID | UC-C-PIC-001 |
Name | Postpartum and infant care (Configuration CREATE) |
Description | The use case implements configuration of a consent agreement towards infant care use case scenarios. This results in a saved configuration to be issued to all mothers requiring infant care. |
Trigger (the event that triggers the use case) |
|
Preconditions (list of conditions that MUST be met in order for the use case to be successful) |
|
Data inputs |
|
Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both) |
Optionally: a data intermediary or a data operator. |
Normal Course (what happens if the event is triggered and the preconditions have been met) |
|
Alternative Course (links to other use cases in case there are different ways how to solve the same use case) |
|
Data output |
|
Post-Conditions (the success criteria) |
|
Exceptions (error situations) | (TBD - Should align with other error scenarios.) |
Related BBs (working groups related to that particular use case) |
|
Terminology used within this specification.
Term
Description
Configuration
technical implementation of all the content and process conditions as defined by the Data Policy for Consent Agreement creation, reading, updating and deletion, as well as for providing all necessary actors with the required operations
Consent Agreement
is the agreement to be signed by the Individual and the Data Controller as prescribed by Data Policy, based on which the Data Providing System may transmit the data to the Data Consuming System for the purposes described in the Consent Agreement.
Consent Record
is created when an individual signs a consent agreement. It represents a signed consent agreement.
Consent Reference
a unique identifier used to locate and verify the validity of the Consent Agreement.
Data Providers
is a legal entity that stores and provides access to an Individual's data, which requires the Individual's consent for processing (outside of its primary purpose/location).
Data Consumers
is a legal entity that requires the Individual's data from the Data Providers according to the consent of the Individual.
Data Disclosure Agreements
a Data Disclosure Agreement (DDA) exists between two organisations where one organisation acts as a Data Provider and the other as a Data Consumer. The DDA captures how data is shared between the two organisations and what role and obligation each party has.
Data Policy
is a formal description of the purpose, nature and extent of consent-based personal data processing, covering the configuration needs by Data Providing System and Data Consuming System and the conditions defined by law.
Data Processing Auditor
is an entity (a person or an organisation) verifying the legitimacy of personal data processing by Data Controllers and Data Processors based on the Data Policies and performed tasks. The entity is not to be confused with a data policy auditor that is independent of the actors involved in the operations of consent management and can engage directly with the Consent BB service operator.
Delegate
the person giving consent (signing Consent Agreement); on behalf of the Individual,
Individual
is a person about whom the personal data is stored in an information system (a.k.a. “Data Subject”) and who agrees or not with the use of this data outside of its primary purpose/location.
Legal Entity
is an organisation (public or private) that has the rights and obligations to define standards for personal data processing. E.g. a public health authority
Personal data
is any information that (a) can be used to identify the Individual to whom such information relates, or (b) is or might be directly or indirectly linked to the Individual (ISO(IEC 29100:2011)
Regulations
are broadly defined as rules followed by any system: could be laws, bylaws, norms or architectures (Defintion inspired by Lessig’s modalities of regulation: https://lessig.org/images/resources/1999-Code.pdf) that regulates a given system.
DELETE - Cascading delete operation for Right To Be Forgotten, deletes all Consent Records that shall not be retained and have a "forgettable" Agreement. May also delete an unsigned Consent Record, for instance in cases where the user exits the signing process. Individual ID supplied as HTTP header.
READ - Fetch an Individual in the Consent system
Unique ID of an object
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""LIST - lists individuals in the system
Requested index for start of resources to be provided in response requested by client
Requested number of resources to be provided in response requested by client
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""CREATE - Creates an Individual in the Consent system
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""UPDATE - Updates an Individual in the Consent system
Unique ID of an object
Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""LIST - returns the current Policy
Unique ID of an object
Requested index for start of resources to be provided in response requested by client
Requested number of resources to be provided in response requested by client
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data Agreements.
""Name of the policy
""Version of the policy
""Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""""""""""""LIST - Fetches list of readable Policy objects
An object with id revisionId
Requested index for start of resources to be provided in response requested by client
Requested number of resources to be provided in response requested by client
A list of Policy objects readable for the current session's credentials.
""Name of the policy
""Version of the policy
""Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""""""""""""READ - get a Policy object + latest Revisio
Unique ID of an object
An object with id revisionId
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data Agreements.
""Name of the policy
""Version of the policy
""Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""""""""""""A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
""This was previously called "schema" but for technical reasons should be called "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (SHA-1)
""Timestamp of when revisioning happened
""Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""Reference to an admin user that has created this revision
""A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
Tamper-resistent artifact from previous record, copied from serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""CREATE - Creates a new Policy object and returns the new object and a PolicyRevision
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data Agreements.
""Name of the policy
""Version of the policy
""Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""""""""""""A set consisting of the new Policy object created, together with the initial Revision object.
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data Agreements.
""Name of the policy
""Version of the policy
""Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""""""""""""A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
""This was previously called "schema" but for technical reasons should be called "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (SHA-1)
""Timestamp of when revisioning happened
""Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""Reference to an admin user that has created this revision
""A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
Tamper-resistent artifact from previous record, copied from serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""READ - fetches the latest version of a Policy and the presented revisionId of an associated Agreement
Unique ID of an object
An object with id revisionId
A policy governs Data Agreements in the realm of an organisation that is often referred to as "data controller" (GDPR) and owner of referencing Data Agreements.
""Name of the policy
""Version of the policy
""Permanent URL at which this very version of the Policy can be read, should not be allowed to change over time.
""""""""""""A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
""This was previously called "schema" but for technical reasons should be called "schemaName"
""The PK of the object that was serialized.
""Indicates that objectId was left blank in serializedSnapshot when calculating serializedHash. objectId may be subsequently filled in.
""Revisioned data (serialized as JSON) as a dict {objectData: {...}, schemaName: ..., objectId: ..., signedWithoutObjectId: ..., timestamp: ..., authorizedByIndividual: ..., authorizedByOther: ...}. It contains all the fields of the schema except id, successor, predessorHash and predecessorSignature.
""Hash of serializedSnapshot (SHA-1)
""Timestamp of when revisioning happened
""Shallowly models an Individual which may reference some instance in an external system (registration system, functional ID, foundational ID etc). An Individual instance of this model is not to be mistaken with a unique natural individual. It is up to the system owner to decide if this record permits mapping to a natural individual and/or if a single Individual row can map to several consent records.
The unique ID of an Individual row.
""Reference to another foundational/functional ID, which is likely PII
""External id type specifier. A string. For instance "email" or "foundational id". Can be used in later queries.
""This could be an FK, but for now we do not have a mapping of identity providers. IDBB may have more requirements.
""Reference to an admin user that has created this revision
""A generic revision model captures the serialized contents of any shema's single row. This is then subject to 1) cryptographic signature and 2) auditing.
Aside from "successor" column, a revision should be considered locked.
Tamper-resistent artifact from previous record, copied from serializedHash
""Tamper-resistent artifact from previous record (we don't know if the previous record was signed or not)
""
