Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


#RequirementsStatusShort descriptionType*

Business Value

(0-lower 5-higher)

Effort needed

(in days)

Proposed Timeline

(2015 or 2016)

Timeline Expectation

(2016 or 2016)

1Non-­Repudation (from e-SENS) token creation, integrate with a repository to keep these records and build also a UI for viewing and exporting them.In Progress

The non-repudiation token are being created during all IHE requests (XCPD, XCA) and portal (NCP-B) requests and for now being stored in filesystem.

Tokens will be stored in database, in a separate schema which has to be modelized. Schema shall contain extraction of attribute parts and full xml token.

Provide an easy way to administrators to browse and search or export them (Web interface, Portlet)

New Feature/Improvement 


DB: 2

Impl: 2

UI: 2


Needed a CLEAR PICTURE on what to implement. Specification must be done. Security constraints must be taken into account (like e.g. trustzones). Is the storage and accessibility of that data out of scope of eSens specs?

2eID Patient Identification (from e-SENS)In Progress

Integration with OpenNCP Level 1 (LARMS) and Level 2 (LAM).

New Feature  2015 Level 2, is there an impact on core components of OpenNCP, as e.g. the TRC-STS module?
3SMP Integration with OpenNCP (from e-SENS).In SpecificationIntegration of Service Metadata Publishing (SMP) building block with OpenNCP.New Feature  2016 Implication with LAM ?

CTS2 compliance in:

  • tsam sync, 
  • tsam export;
In RoadMapModification of Terminology synchronization modules to be compliant to access CTS-2 Terminology server interface.New Feature  2016 Is there an implication on the data representation in local terminology database, to be clarified. Tsam export may only be affected by modification of LTRDB.

Centralised GUI - for invoking epsos services like:

  • tsam sync, 
  • tsam export;
In RoadMapThe TSAM Sync and TSAM export are epsos utilities that only can be run from command line. It would be easier to create a contol center from which all these activities could be executed and logged. We could keep some execution details such as execution date, user has started the execution, result of execution. We could also add notification services for the status of the execution in order the administrator to be notifiedNew Feature   - To be better described. We need to define about component separation respecting trust zone model.
6Centralised GUI - configuration properties change (GUI for epsodb) In RoadMapIn the current situation the configuration parameters (epsosdb) is being changed by getting access to mysql. We should create a small application/portlet for CRUD operations in epsosdb database and also keep log of changes being made in this databaseNew Feature   - To be better described. We need to define about component separation respecting trust zone model.
7Centralised log for all the epsos activities (possible extension of audit logs), and UI for browsing this logIn RoadMap It is in relation with previous (point 6) of roadmap. If we manage to handle all epsos activities from a gui, then it would be useful to have a centralized log to see the status of all executed services and the heartbeat of the services.New Feature   -  To be better described. We need to define about component separation respecting trust zone model.
8eADC (Automatic Data Collecter) improvements to keep useful information. It needs to be revised what is kept now and maybe be extended
  • Centralised GUI for browsing and searching eADC data

  • Main purpose of this component was "Secondary Use of data and in second place statistics"
In RoadMap eADC, is a component made for keeping statistics about transactions made from/to countries. It has to be rescheduled in order to keep valuable data like: Home Country, Remote Country, Type of Query/Action, role of the user made the action, duration of the query. We have to think if we want to keep data of the queries made (such as patient data and documents data). This is much related the purpose of the statistics.Improvement   2016 We need to check with the requirements from Expand/CEF in terms of data collection and the privacy protection of patients.
9TSAM Synchronization Refactoring (it needs a number of hours for a synchronisation)In RoadMap 

Performing the synchronization of the LTRDB with the centralized terminology server takes often too much time. Goal is to optimize the synchronization to reduce time.


Improvement   2015 

It has to be analyzed what is the reason for that. Code review necessary. Maybe output in logs should be extended to provide feedback about the current state of the synchronization process.

Since the timeline foreseen for the implementation of CTS-2 compliant interface is not the same as for the refactoring to ensure better performance, we expect the refactoring performed until end of this year.