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.

Harmonizing the non-repudiation requirements for all the different e-SENS domains is a challenging task. Every domain has a vertical specialization (both from a technical and from a regulatory standpoint) with respect of the non-repudiation services. The White Paper on Non Repudiation Services[1][2] highlighted a path towards a common set of cross-border and cross-sector interoperable non-repudiation services using a per-hop (e.g., per-corner) evidence-based mechanism. The mechanism allows for a generic, horizontal, and legally stable technology used to emit and store evidence guaranteeing both interoperability and the per-domain specific needs.

The core of the abovementioned mechanism is the Evidence Emitter ABB, which can run in any corner of the e-SENS model. By inspecting the incoming (or outgoing) message, it provides a mechanism to guess the application domain (e.g., eProcurement, eHealth, eJustice) and triggers the emission of the specific set of evidence, by evaluating a previously agreed security policy. The expected set of evidence emitted is the domain-specific one (e.g., IHE ATNA) and the generic, interoperable one (e.g., ETSI REM) and it may be signed according to the domain needs.

For the detailed discussion of the non-repudiation aspects in the 4-corner model, please refer to [1].

The current epSOS specifications tackle non repudiation aspects in [3] by further specifying the the audit trails. However these recommendations are not inlined with the ISO 13888 standard neither with the ETSI REM standard, which is selected as the target architecture for the eDelivery CEF building block.

The non-repudiation framework proposed by e-SENS aims at providing a cross-sector technology that selects and feeds the correct evidence emitter for the specific domain. For instance, by the usage of a policy evaluation outcome, the obligations contain the necessary data to be used to feed the audit trail emitter in parallel with the ETSI REM. The Non Repudiation implementation is an instance of the well known Message Inspector and Secure Session Façade Core Security Patterns.

[1] http://wiki.ds.unipi.gr/display/ESENS/SAT+-+Non+Repudiation

[2] http://wiki.ds.unipi.gr/display/ESENS/Whitepaper+-+Non+Repudiation

[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 ePrescription, the patient returns to the home country and claims reimbursement of 3 packages of the drug purchased abroad. The dispensation only shows that 1 package was dispensed. The organization of NCP A now needs to prove that erroneous information was received from NCP B and was not generated while processing the dispensation information in the NCP or NI software. A similar case arises when the patient claims they only purchased 1 package out of 3, and there should be still some available amount on the prescription. The NCP A needs to show that the information received from NCP B was wrong.
In Patient Summary, a drug is administered to the patient, and the patient suffers a severe allergic reaction. The allergy to the drug was mentioned on the patient summary, but the doctor claims that this information was not delivered and shown to them. Now NCP B wants to demonstrate that this information was indeed not received from Country A.

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)

Related Meetings

Reference

[1] http://wiki.ds.unipi.gr/display/ESENS/SAT+-+Non+Repudiation

[2] http://wiki.ds.unipi.gr/display/ESENS/Whitepaper+-+Non+Repudiation

[3] See e.g., epSOS D3.4.2, Section 4.5.6 Audit Trail Data for Non-Repudiation

Other Documents:

20150303_Non-rep.pptx - Notes and some questions about the Non-Rep. BB, provided by Konstantin Hyppönen.
Files provided by Heiko Zimmermann:

Provided by Massimiliano Masi about the DICOM Audit Message Format:
- IHE_ITI_TF_Vol2a.pdf - see line 3940.
UML from Massimiliano Masi about the analysis with ETSI:
- ETSI_UML.pdf

Action Items:

person - task -date

Browser not supported