OpenNCP Roadmap (to be updated)

Goal

Clearly identify within the Technical Committee (and possibly the Steering Committee) the main improvements/requirements for OpenNCP, along with the related information:
- their status;
- type (new feature; improvement; bug fix;);
- business value;
- estimated effort;
- timeline.

Background and strategic fit

Important to define what must be taken in consideration until the end of 2015 (before the Hand-Over), and to propose new improvements/requirements for 2016.

Assumptions

Based on to the Roadmap Analisys Meeting of the Technical Committee (here), the following matrix has been created and filled both by Steering and Technical Committee.

Functional Requirements

#	Requirements	Status	Short description	Type*	Effort needed (in days)	Proposed Timeline (2015 or 2016)	Obs.
1	Non-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	Tentatively: DB: 2 Impl: 2 UI: 2	2015	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?
2	eID 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?
3	SMP Integration with OpenNCP (from e-SENS).	In Specification	Integration of Service Metadata Publishing (SMP) building block with OpenNCP.	New Feature		2016	Implication with LAM ?
4	CTS2 compliance in: tsam sync, tsam export;	In RoadMap	Modification 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.
5	Centralised GUI - for invoking epsos services like: tsam sync, tsam export;	In RoadMap	The 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 notified	New Feature		-	To be better described. We need to define about component separation respecting trust zone model.
6	Centralised GUI - configuration properties change (GUI for epsodb)	In RoadMap	In 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 database	New Feature		-	To be better described. We need to define about component separation respecting trust zone model.
7	Centralised log for all the epsos activities (possible extension of audit logs), and UI for browsing this log	In 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.
8	eADC (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.
9	TSAM 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.

*Type: New feature; Improvement; Bug Fix;

Beyond Patient Summary and ePrescription use cases

#	Requirements	Short description	Proposed Timeline (2015 or 2016)
1	PAC - Patient Acces (epSOS 2 Services)	(XDM functionality, what means to export the cda documents in a folder according to IHE standards, and also view this by uploading to OpenNCP Portal)	2016
2	HCER - Health Care Encounter Report (epSOS 2 Services)	User Interface for HCER to support all sections of Patient Summary	2016
3	MRO - Medication Related Overview (epSOS 2 Services)		2016
4	Enable the exchange of LABORATORY requests and results		2016
5	Enable the exchange of IMAGIOLOGY related information (images and reports)		2016

*Type: New feature; Improvement; Bug Fix;

Non-Functional Requirements

#	Requirements	Short description	Type*	Proposed Timeline (2015 or 2016)	Obs.
1	Refactoring of nomenclature of packages and components, replacing epSOS (and other companies) specific wording toward generic eHealthNCP	Class names and package names which are currently contain project specific naming like epSOS or information about the companies which implemented, will be harmonized to generic terms and a possible refactoring of the package structure may be done.	Improvement	2016	This does not break the licensing constraints (GPL V3) this only consist on changing nomenclature by normalised naming.
2	Extension of epSOS services to be used by mobile devices. The services have to be REST ready and will help other applications to adapt OpenNCP gateway for usage beyond epSOS	In order to use epsos services a rest api has to be built above client connector to give the possibility to mobile developers create mobile apps for using epsos services. This API will use the existing functions of OpenNCP portal and expose some of these with the REST architecture, to reduce complexitiy of usage by third party applications.	New feature	2016	Use-cases, components and functionality to be exposed by REST interfaces must be defined in more detail.
3	Performance optimization	Invoke eADC, Audit Manager and XCPD/XCA/XDS Validator in an asynchronous mode to increase response time of servers	Improvement	2015
4	Preparation of ready to use OpenNCP images using Docker or other alike technologies for easier installation	To help new countries/users to have an easier way to start using OpenNCP. In addition to the revised installation documentation.	Improvement	2015	Are we really in the situation in 2015 to provide this? We know Alexandre worked heavily on Docker. What is the current state? Do we include something to easier interconnect with other instances?
5	Stress testing of OpenNCP components to assure that they can handle significant number of concurrent users		Improvement	2016	Shouldn´t it be a part of the default testing strategy of deployments?
6	Security tests of OpenNCP bundle to assure that they are ready for LIVE DATA		Improvement	2015	* Markus will provide results Which tests are performed, test scenario description per service would be necessary.

*Type: New feature; Improvement; Bug Fix;