...
...
...
...
1. Vision of the software will be developed (purpose of the project)
The Evidence Emitter Architectural Building Block enables National Contact points to generate and emit electronic evidence used for non-repudiation purposes, based on each domain respective regulations and technological need.
...
[3] See e.g., epSOS D3.4.2, Section 4.5.6 Audit Trail Data for Non-Repudiation
2. Stakeholders (role description)
- Health Professional: information system/information service user;
- Patient: service beneficiary;
- National Authority: national responsible for the eHealth National Contact Point;
- Data Controller: responsible for and must put in place processing contracts with their 'data processors'.
- Data Processor: actor processing personal data in a specific context and with regard to specific sets of data or operations.
3. Users (need of each user)
Why non-repudiation is needed? When NCPs exchange messages, they should produce enough evidence for further investigation in case of disputes. Here are some examples of the cases when this might be needed:
...
In these cases, the contents of the documents exchanged by the NCPs should be available for later examination during dispute resolution.
4. Features that will be developed (from here we will create jira issues)
- When in the workflow there is the need to send an audit trail, instead of directly calling the method that creates the audit, the framework is invoked, by passing the message and the context (e.g., TLS, datetime) as parameters. The framework decides which evidence emitter to trigger
5. Features that will NOT be developed (very important in order to be easily found what decided not to be developed for further reference)
Action Items:
-
person - task -date