Page tree
Skip to end of metadata
Go to start of metadata

1. Introduction

To support MS in gaining experience with the reference implementation for the NCPeH (National contact point for eHealth), to be prepared for the CEF eHealth DSI, the idea of a Boot Camp has been proposed.

  • Aim is to provide technical experts of participating Countries a first hands-on session for the installation/configuration of the OpenNCP components.

1.1. Date

The Boot Camp is intended to be a 3 days event, to be held in Brussels in January 2017. The event may have a second edition in 2018 if there is the need for it.

  • to , 09:00 to 17:00

1.2. Venue

  • City: Brussels, Belgium
  • VENUE Address: Philippe Le Bon, 31000 - Bruxelles
  • Room: PLB3 room 1.4 (100 person room)

Table of Contents

2. Programme

DAYSESSIONTUTOROUTCOMES (TOPICS)

D1 morning

 09:00 to 12:30

A.1) Understand the Architecture of the OpenNCP

Understand the role of each Central Service and OpenNCP component and their relationships.

  • The history towards the Open Source reference implementation
  • The rationale behind the Global architecture
  • The rationale behind the NCP architecture
  • The NCP Components architecture
  • The purpose of each component in the architecture
  • The main information flows and audit logs
    • Related IHE profiles.

D1 afternoon

 

13:30 to 17:00

A.2) Learn how to install the OpenNCP

Have the OpenNCP components installed in your local environment.

  • How to prepare the OS environment to proceed with the install of OpenNCP
  • Hot to get/check if the right JAVA (JDK/JRE) is installed
  • How to get the applications servers up and running
  • How to get the data base servers up and running
  • Where to get the OpenNCp components
  • How to deploy/install the OpenNCP Components

D2 morning

 

09:00 to 12:30

B.1) Learn how to configure the OpenNCP

Have a better understanding of what can / has to be configured or tuned in the OpenNCP installation.

  • How to set up each component individually (with initial content)
  • How to integrate components
  • How to configure the connection with other NCPs
    • How to configure the VPN
  • How to configure the Local Terminology Repository
  • How to configure a Portal (NCP B)

D2 afternoon

 13:30 to 17:00

B.2) Understand the test plan and learn to gather the test evidence

Basic knowledge of the IHE Gazelle tools for testing. Learn where to get the evidences that have to be provided to Gazelle in order to document tests results.

  • Test rational and strategy
  • Test Types
  • Tooling
  • Test Plan
    • Patient Summary related
    • ePrescription related
  • How to generate evidence
  • How to collect and submit evidence
  • How to read the test results and act upon them (correct, improve, fine-tune)

 18:30

Social Event  

D3 morning

 09:00 to 12:30

C.1) Be familiar with the source code and ways to contribute to it

OpenNCP → Open source, open community: new contributors are welcome!

  • Tooling
  • Release Cycle and release process
  • Technology Roamap
  • Components structure
  • Code conventions
  • How to get the source code
  • How to change source code
  • How to submit source code changes

D3 afternoon

 13:30 to 17:00

C.3) Be familiar with the source code for the National Connector

Understand the way the NC works and see how the mock NC can serve as a template for your own NC.

  • NC basic "template" (APIs out of the box)
  • Mock CDAs mode vs. NI connected mode
  • Operations performed
  • ?? Patient Consent check mechanism?? (it depends on national Legislations)
  • Sound Experience from different countries about their experience implementing the National Connector.

 

 

 

 

 

 

2.1 Participants

COUNTRY

CONFIRMATION
(by )

Participant 1Participant 2
Luxembourg

CONFIRMED

Heiko ZIMMERMANN 

Sweden

CONFIRMED

Stefan NILDÉNMagnus WALLIN

Czech Republic

CONFIRMED

Jaroslav Krotky

Milan Lysa

Germany

CONFIRMED

Maid EROVIC 

Belgium

CONFIRMED

Pablo D'Alcantara

Cyprus 

CONFIRMED

Ioannis CONSTANTINOUEleftheria Giorgitsi

Switzerland

CONFIRMED

Reinhold Sojer

Croatia

CONFIRMED

Neven Rački

Malta

CONFIRMED

Jonathan CASSAR 

Hungary

CONFIRMED

Gergely HéjaDr. Lajos Horváth

Finland

CONFIRMED

Konstantin HYPPÖNENTero Mäyränen

Poland

CONFIRMED

Paweł MasiarzKrzysztof BUGAJSKI
Portugal

CONFIRMED

Rúben Botelho
Ireland

CONFIRMED

Eamon COYNEMartin TULLY
France

CONFIRMED

Clemence MARTIN

Italy

CONFIRMED

Giacomo LEZZIERO
Estonia

CONFIRMED

Aarne Roosi
Greece

CONFIRMED

Ioannis ASPROLOUPOSAntiopi Panou
Austria

CONFIRMED

Peter Holzer

David Köckeis

EU (eHDSI SP)

CONFIRMED

TUTORS  
SUPPORT 
 TOTAL PARTICIPANTS44 people

 

2.2 Room Organisation (proposal)

PHOTO LOG 

  • No labels

4 Comments

  1. DAY 3 - COMMUNITY BRAINSTORM

    • PLEASE REPLY TO THIS COMMENT BY ADDING A QUESTION YOU WOULD LIKE TO SEE DISCUSSED BY THE OpenNCP Community?
      • e.g. Why we do "this" this way? (driver por possible answers to gather during the brainstorm: Why not doing "this" way?)
  2. Proposal of subject for discussion in the session on "Testing":

     

    Some teams would like to address the testability in the context of the “assertions” you need to access the various SOAP services. In order to test services in a more isolated and narrow fashion, it should be possible to generate test assertions (access tokens) directly “into” the test tools (eg SoapUI).

     

    Various discussions came up with the idea to bundle the required methods into a JAR that can be included an test projects. The JAR would be invoke when an assertion/token is needed. At the same time, we could have the JAR implementing the SoapUI extension API to even simplify more the usage.

    1. I agree this is a good topic, and one I know our test team back home in Sweden would like to hear more about (smile)

      /Magnus

  3. In some cases we need to change properties in a ready-to-deploy-artifact and the only way to do it is to download the artifact, unpack it, change what needs to be changed and create the artifact again. For example in the client-connector we changed the transportReceiver http & https ports.

    It would ease our configuration management a lot if this could externalized into property files or similar.