Assist and resolve any support issues that may arise;
Handover to (DG-SANTÉ) for long term sustainability organisation;
FROM PREVIOUS MEETING:
Since we could not have the full Technical Committee on 3rd August (Stephane on holidays) no decisions were taken beyond the following guidelines:
a) During August, consolidate as much as possible the three open epics with e-SENS (NonRP, eID Level 1, SMP assessment), no new epics should be taken on board.
b) Meet as soon as everyone is back from holidays: September 2nd, 13h00 CEST.
MEETING NOTES
0.1. Overarching Vision
MISSION
Along epSOS:
Open group of people orchestrated by an agile software development methodology conducting effort on designing, coding, testing and delivering OpenNCP software
Beyond epSOS:
Open group of people orchestrated by common principles, conducting effort on designing, coding, testing and delivering eHealth Interoperability technology
VISION
Along epSOS:
Design and develop a set of Open Source Components (OpenNCP) that can be adopted by Participating Nation, to build their local implementation of the epSOS NCP.
Beyond epSOS:
Design, develop and sustain a set of open source components (OpenNCP) that can be adopted by anyone, to build an eHealth Information Exchange Point.
0.2. Development Roadmap
NATURE
NEW FEATURES
CONSOLIDATION (fix improvements)
Perspectives of discussions:
What MUST be ready by the end of 2015;
What SHOULD be included in 2016 roadmap;
RELEASE
ONLY 1 BRANCH...no different versions to be maintained.
In my understanding what OpenNCP tries to follow is the epSOS Trsut Model... And all this architecture available in the deliverables was the agreed approcach for the OpenNCP...
We all know what the architecture is...
Implementation used is not the architecture defined in epSOS project.
We are seeing that we have only one server/VM running everything... Portal, NCP, OpenATNA...
I was thinking on the architecture known from epSOS, what is going towards OP in OpenNCP, and this was the reason I raised these issues.
As for the tech part - I think the direct use to DB is possible as long as the OpenATNA DB is running on same environment of the NCP. But we have the Portal "problem"...
The Portal was a mean to have the implementation to access to the OpenNCP and workflows...
The Portal shouldn't have direct access to OpenNCP (DBs) or OpenATNA
This Portal (corner 1) needed to emmit evidences...
We can go for a shortcut, when we're talking about the current implementation of the OpenNCP, but we have to see if the current OpenATNA webservice has the capability to receive messages, (client to store on OpenATNA) or if we need to find another solution to store on OpenATNA. Also how can we access info on OpenATNA webservice is another thing to discuss in the future...
It might be necessary to change something in OpenATNA. We'll have time to understand the source code, after to change and implement... ON other side: efforts from OpenNCP to build more clients if needed. Must be studied before to analyze impact.
We have to add two tables to DB and then have on the OpenNCP side instead of the methods we have...
Timeframe: going to direct access is quickest and certainly we can have it for December...
If we go to the solution of OpenATNA webservices, they are implementing client-side security w/certificates...
Markus (Unlicensed): The question is the time, and if there's the December EXPANDATHON, we should go for the quickest solution, but in long term, we should go for the other one...
Heiko Zimmermann: We should inform Stephane and Kostas with both solutions. And get their opinion, as we can't decide now without them. But we take this position...
Heiko Zimmermann: Kostas was the one working on this, but now I'm not sure anyone is working on it.
Marcello Melgara: Needs to be changed with new MVC... For the next release and to test in EXPANDATHON. We already addresses to Kostas as GNOMON is the author...
Alexandre Santos: Kostas changed the version of Portal in the last release... Was these the changes?