UC-C-PIC-AT: Data Processing Auditor Use Cases (AUDIT)

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.

1. MUST be triggered for each consent management event:

2. 1. CREATE new consent

   2. UPDATE existing consent

   3. WITHDRAW existing consent

3. MAY be triggered for the following events if one wants to also register/log the access to the Consent Registery even if no modification of the Consent Record is made.:

4. 1. READ CONSENT STATUS

   2. VERIFY CONSENT INTEGRITY

   3. MONITOR POLICY UPDATE

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).

1. An audited healthcare policy allowing consent-based data exchange is based on existing data laws for healthcare;

2. An overall audit methodology exists;

3. Use case configuration UC-C-PIC-A-001 has been successfully invoked;

4. Data Policies and Consent Agreements are available;

5. Access rules to Consent Records have been implemented. The Auditor has been registered in the system, and his access right is given

Data inputs

1. Consent Registry (i.e. access to Consent Records);

2. Access to Data Policies and validated Data Agreements templates

3. Auditing tools/script and logs.

Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)

1. Audit Framework: A process defined by the independent organisation responsible to audit the application. The Audit Framework defines the scope and details of the audit process.

2. Data Policy Auditor: A human, usually employee of the organisation responsible to audit the application. The Data Policy Auditor MUST demonstrate independence from the organisation owning the application being audited.

3. Application: The application using GovStack architecture.

4. Consent_BB: The GovStack Consent Building Block.

5. Workflow_BB: The GovStack Workflow Building Block.

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)

1. The authorised Data Policy Auditor is able to invoke the AUDIT CONSENT workflow;

2. The Data Policy Auditor can verify that the Consent Management BB configuration conforms to the approved configuration

3. The authorised Data Policy Auditor can

4. 1. Verify that Data Policies have been signed off and have access to relevant details;

   2. Query the Consent Registry to perform any audit investigation or produce audit reports (ad hoc requests and an automated report);

5. Audit reports and query results can be recorded by the chosen audit methodology.

6. All individual data sharing must be related to a valid Consent Record. This information will have to be made available for audits of data usage in other building blocks.

Alternative Course (links to other use cases in case there are different ways how to solve the same use case)

1. Consent Record error scenarios;

2. Data usage error scenarios;

3. Data configuration error scenarios.

Data output

1. Audit files (incl. Supporting information)

Post-Conditions (the success criteria)

1. The Consent Registry meets the audit requirement;

2. Faulty Consent Record trigger correction scenarios;

3. Audit information is 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)

1. Identity BB (Required for acquiring authentication token)

2. Workflow BB - workflow management

3. Registries BB - stores the data agreement data,

4. Information Mediator BB - providing interfaces

5. Security BB - supervision

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..

1. The Data Policy Auditor has been informed of a policy change and the impacts on Consent Agreements have been defined.

Same preconditions as UC-C-PIC-AT-001 AUDIT CONSENT

1. A new audited healthcare policy allowing consent-based data exchange exists based on existing data laws for healthcare;

2. An overall audit methodology defines the specific audit activities.

3. Use case configuration UC-C-PIC-A-001 and track changes UC-C-PIC-AT-001 has been successfully invoked;

4. Data Policies and Consent Agreements are available;

Data inputs

1. New Data Policies and updated Data Agreements;

2. List of approved actions (i.e communication to system users and individuals) ;

And same data inputs as UC-C-PIC-AT-001 AUDIT CONSENT

1. Consent Registry (i.e. access to Consent Records);

2. Access to Data Policies and validated Data Agreements templates

3. Auditing tools/script and logs.

Actors (a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)

1. Audit Framework: A process defined by the independent organisation responsible to audit the application. The Audit Framework defines the scope and details of the audit process.

2. Data Policy Auditor: A human, usually employee of the organisation responsible to audit the application. The Data Policy Auditor MUST demonstrate independence from the organisation owning the application being audited.

3. Application: The application using GovStack architecture.

4. Consent_BB: The GovStack Consent Building Block.

5. Workflow_BB: The GovStack Workflow Building Block.

Normal Course (what happens if the event is triggered and the preconditions have been met)

1. The authorised Data Policy Auditor confirms with the Administrator that the new policy Configuration has been implemented.

2. The Data Policy Auditor performs an audit of Consent Agreements (see UC-C-PIC-AT-001 Audit Consent for further details)

3. 1. Review list of Consent Agreements and identify the ones requiring an action (as per Audit Framework list of action)

   2. Update Consent Agreement as per list of action (use case dependent)

   3. Record update of Consent Agreement

4. For each Consent Agreement updated, the Data Policy Auditor performs an audit of Consent records (see UC-C-PIC-AT-001 Audit Consent for further details)

5. 1. Review list of Consent Records and identify the ones requiring an action (as per Audit Framework list of action)

   2. Update Consent Records as per list of action (use case dependent)

   3. Record update of Consent Records.

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)

1. Audit Framework: A process defined by the independent organisation responsible to audit the application. The Audit Framework defines the scope and details of the audit process.

2. Data Policy Auditor: A human, usually employee of the organisation responsible to audit the application. The Data Policy Auditor MUST demonstrate independence from the organisation owning the application being audited.

3. Application: The application using GovStack architecture.

4. Consent_BB: The GovStack Consent Building Block.

Normal Course (what happens if the event is triggered and the preconditions have been met)

1. For audit purposes, the authorised Data Policy Auditor receives the instructions to read information from the Consent Records of a fixed population of Individuals.

2. The Data Policy Auditor receives the information and records it as part of its audit workflow to be analysed.

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)

1. Audit Framework: A process defined by the independent organisation responsible to audit the application. The Audit Framework defines the scope and details of the audit process.

2. Data Policy Auditor: A human, usually employee of the organisation responsible to audit the application. The Data Policy Auditor MUST demonstrate independence from the organisation owning the application being audited.

3. Application: The application using GovStack architecture.

4. Consent_BB: The GovStack Consent Building Block.

Normal Course (what happens if the event is triggered and the preconditions have been met)

• For audit purposes, the authorised Data Policy Auditor receives the instructions to verify the integrity of a Consent Record.

• The Data Policy Auditor formulate the request to the Application

• The Application returns:

• • The confirmation that the Consent Record exist and has been adequately signed (i.e. Consent Record has not been tampered with)

  • The audit supports information that should include: the reference to the Consent Record object, the attached Consent Agreement and a proof of signature.

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.