salus d8.3.2 tud v1.0 - i~hdfp7-287800 salus salus-fp7-287800• d8.3.2_tud - version 1.0- november...

FP7-287800 SALUS

SALUS-FP7-287800• D8.3.2_TUD - Version 1.0- November 24, 2014 of 26

SALUS “Scalable, Standard based Interoperability Framework for

Sustainable Proactive Post Market Safety Studies”

SPECIFIC TARGETED RESEARCH PROJECT PRIORITY Objective ICT-2011.5.3b Tools and environments enabling the re-use of electronic health records

SALUS D.8.3.2 - Deployment of SALUS Pilot Application – R2

Due Date: October 31, 2014 Actual Submission Date: November 24, 2014 Project Dates: Project Start Date : February 01, 2012

Project End Date : April 30, 2015 Project Duration : 36 months

Deliverable Leader: Technische Universitaet Dresden (TUD), Germany

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

Dissemination Level

PU Public X PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)

FP7-287800 SALUS

SALUS –FP7-287800 • D8.3.2_TUD - Version 1.0 – November 24, 2014 of 26

Document History: Version Date Changes From Review

V0.1 October 24, 2014 Creation of the first version TUD UKD (TUD)

V0.2 October 27, 2014 Update from UKD TUD SRDC, AGFA

V0.3 November 11, 2014 Input from SRDC SRDC -

V0.5 November 18, 2014 Updates from SRDC SRDC -

V0.6 November 19, 2014 Review from OFFIS OFFIS -

V0.7 November 20, 2014 Updates from AGFA AGFA SRDC

V0.8 November 20, 2014 Updates from TUD TUD SRDC

V1.0 November 24, 2014 Updates from SRDC SRDC SRDC

Contributors (Benef.) TUD, SRDC, AGFA, OFFIS, INSERM

Responsible Author Dheban Srirangan Email [email protected]

Beneficiary TUD Phone +493514586046

FP7-287800 SALUS


SALUS Consortium Contacts:

Beneficiary Name Phone Fax E-Mail SRDC Gokce Banu Laleci Erturkmen +90-312-2101763 +90(312)2101837 [email protected] EUROREC Georges De Moor +32-9-2101161 +32-9-3313350 [email protected] UMC NiklasNorén +4618656060 +46 18 65 60 80 [email protected] OFFIS WilfriedThoben

+49-441-9722131

+49-441-9722111

[email protected]

AGFA Dirk Colaert +32-3-4448408 +32 3 444 8401 [email protected] ERS Gerard Freriks +31 620347088 +31 847371789 [email protected] LISPA Davide Rovera +390239331605 +39 02 39331207 [email protected] INSERM Marie-Christine Jaulent +33142346983 +33153109201 marie-

[email protected] TUD Peter Schwarz +49 351 458 2715 +49 351 458 7319 Peter.Schwarz@uniklinikum-

dresden.de ROCHE Jamie Robinson +41-61-687 9433 +41 61 68 88412 [email protected]

FP7-287800 SALUS


EXECUTIVE SUMMARY In SALUS project, two consecutive development cycles are envisioned. In parallel with this, deployment activities are also planned to be executed in two phases. Upon the delivery of first set of SALUS prototypes at Month 18, after integration and testing, the initial deployment activities have been started to be coordinated starting at Month 20. As these initial prototypes are deployed and tested at pilot sites, second prototypes have been developed in parallel with these activities. SALUS pilot applications deployed at pilot sites were planned to be ready at Month 30 for clinical validation. This planning has been executed in LISPA pilot site with some minor delays. In TUD pilot site the deployment has been postponed due to delay in obtaining the Hospital management board agreement for clinical data access. During June 2014 the Hospital board signed the agreement and deployment activities started. This deliverable reports the second release of D8.3.1 which was delivered to EU commission at month 22. D8.3.1 was a unique document including first prototype deployment description for both pilot sites (LISPA and TUD). As far as the deployment activities has been delayed in TUD, the consortium agreed to split D8.3.2 in two separate documents: one for LISPA and one for TUD. This deliverable includes a general overview of SALUS deployment activities including the timing of deployment activities execution. The physical deployment architectures are recalled for completeness including hardware specifications required for SALUS pilot deployments and non-SALUS software requirements. Although the UKD board signed the agreement to give access to data in June, the technical arrangements on TUD took some time for establishing the secure authentication mechanisms for remote access and establishment of the connection between SALUS server and TUD’s TST1 database which includes a copy of TUD’s production database. Deployment of the SALUS tools has actively started within September 2014 – after the summer period – and intensely continued until November. After a technical deployment meeting held within TUD premises during 4-6 November, deployment of all SALUS tools are completed. Technical team of SALUS is continuously monitoring the bugs and instantly fixing the deployments with the established secure remote connection to the SALUS server at TUD. It has been decided that the Research Zone partners should also use a secure VPN machinery to access the tools deployed at TUD during the validation. Therefore, UMC and Roche have received authentication credentials from TUD for a separate VPN channel for validation activities. Based on this same security aspect, all tools have been deployed to TUD Server machine, hence into Care Zone; however the Research Zone applications are still separate web applications served from the same server. Involvement of the partners in Tasks 8.3 is presented in the following table together with the established deliverable action plan:

FP7-287800 SALUS


TABLE OF CONTENTS Executive Summary ................................................................................................................................ 4!1! Purpose and Outline ....................................................................................................................... 6!2! Reference Documents ..................................................................................................................... 6!

2.1! Definitions and Acronyms ...................................................................................................... 6!3! Pilot Deployment: Overview .......................................................................................................... 8!4! Pilots Physical Architecture ........................................................................................................... 8!

4.1! TUD pilot physical architecture .............................................................................................. 8!4.2! TST1 – TUD EHR Database for SALUS ............................................................................... 9!

5! Hardware and Software Specifications ........................................................................................ 11!5.1! Hardware Requirements ........................................................................................................ 11!

5.1.1! Servers - TUD pilot site ................................................................................................ 11!5.2! Software requirements .......................................................................................................... 11!

5.2.1! Operating system ........................................................................................................... 11!5.2.2! Database management system ...................................................................................... 11!5.2.3! Other tools for system development and deployment ................................................... 11!

6! Deployment Profiles ..................................................................................................................... 13!6.1! Deployed SALUS Components ............................................................................................ 13!6.2! Deployment Scripts ............................................................................................................... 15!6.2.1! Prerequisites ...................................................................................................................... 15!6.2.2! Deployment process .......................................................................................................... 15!6.2.3! Deployed Components ...................................................................................................... 15!

7! Pilot Time Plan ............................................................................................................................. 16!8! Report of deployment activities in LISPA ................................................................................... 18!

8.1! TUD Deployment Phase I ..................................................................................................... 18!8.2! TUD Deployment Phase II .................................................................................................... 24!

9! Deployment Status and Conclusions for TUD pilot site .............................................................. 25!10! Appendix A – Screencasts of SALUS TOOLS ............................................................................ 26!

FIGURES LIST Figure 1 - SALUS architecture for in house scenario ............................................................................. 9!Figure 2 - SALUS architecture for research scenarios ........................................................................... 9!Figure 3 – Pilot time plan draft ............................................................................................................. 17! TABLES LIST Table 1 - List of Abbreviations and Acronyms ....................................................................................... 7!Table 2 - EHR Fields available in TUD EHR System .......................................................................... 10!Table 3 - Deployed SALUS components to TUD ................................................................................ 13!Table 4 - Server deployable components in TUD ................................................................................. 13!Table 5 - Corresponding source code modules for the SALUS components ....................................... 14!

FP7-287800 SALUS


1 PURPOSE AND OUTLINE

The purpose of this document is to describe the deployment process of SALUS pilot in TUD. This document briefly gives an overview of the deployment activities. Then the physical deployment architecture designed in D8.2.1 for TUD site is presented in Section 4, as these will be referenced in the later sections. Section 5 presents the hardware specifications of the server that is used in TUD deployment settings. The specifications for the non-SALUS software required for SALUS deployments are also described in this section. Section 6 describes the deployment profiles, i.e. easily executable Maven commands, to download and deploy all SALUS components from SALUS GIT repository. Section 7 presents an overview of the Pilot Plan, covering deployment activities. Finally the results of deployment at TUD site as of Month 33 are presented in Section 8. Deployment scripts are also presented as appendices. In addition to this, screencasts demonstrating the usage of CSCT, ANT and IRT have been prepared by the technical team and also presented as an appendix of this deliverable.

2 REFERENCE DOCUMENTS

The following documents were used or referenced in the development of this document: • SALUS D8.2.1: Design of SALUS Pilot Application (LISPA and TUD) • SALUS D8.3.1: Deployment of SALUS Pilot Application – R1 • SALUS D6.3.1 Integrated SALUS Components – R1 • SALUS D6.3.2 Integrated SALUS Components – R2

2.1 Definitions and Acronyms

Abbreviation/ Acronym DEFINITION

ADE Adverse Drug Event ADR Adverse Drug Reaction ANT Ade Notification Tool CDE Common Data Element CSC Tool Case Series Characterization Tool E2B(R2) Electronic Transmission of Individual Case Safety Reports Message Specification EHR Electronic Health Record FE Front End GP General Practitioner HP Health Professional ICD10GM The International Classification of Diseases, German Version ICSR Individual Case Safety Report IRT Individual case safety reporting tool OMOP Observational Medical Outcomes Partnership PH Tool Patient History Tool PMSS Tool Post Marketing Safety Study Tool PSN Pseudonym QED Query for Existing Data SPARQL SPARQL Protocol and RDF Query Language SSO Single Sign On SIDS Semantic Interoperability Data Service SIL Semantic Interoperability Layer TAS Tool Temporal Association Screening Tool TIL Technical Interoperability Layer

FP7-287800 SALUS


TLS Transport Layer Security TPC Tool Temporal Pattern Characterization Tool XML eXtensible Markup Language

Table 1 - List of Abbreviations and Acronyms

FP7-287800 SALUS


3 PILOT DEPLOYMENT: OVERVIEW A Pilot phase is essential for testing new components. As one cannot have prior knowledge of the performance of the components concerning both technical as well as in this case clinical issues, carrying out pilot scenarios is vital to detect and eliminate difficulties arising during test scenarios. Hence, four scenarios have been conceptually designed to test the SALUS components in TUD premises. 1. Enabling Semi-automatic Notification of Suspected ADEs and Reporting ADEs within a Hospital: a. Enabling Notification of Suspected ADEs (ADE notification) b. Enabling Semi-automatic ADE Reporting (ICSR) 2. Supporting Clinical Evaluation of a Potential Signal through Accessing the EHRs: a. Characterizing the cases and contrasting them to a background population (CSC) b. Temporal pattern characterization (TPC) 3. Running Exploratory Analysis Studies over EHRs for Signal Detection: a. Temporal association screening on EHRs (TAS) b. Manual clinical review of relevant medical history 4 Using EHRs as secondary use data sources for Post Marketing safety studies: a. Estimate incidence rates of chronic heart failure (CHF) in diabetic patients with a recent acute coronary syndrome (ACS) event on different diabetic medications These pilots have been deployed at the university hospital of Dresden. The pilots are fully based on the hospital information system of university hospital and are customized according to their workflow. During the pilot deployment all necessary SALUS components have been installed and their technical validation has been carried out. Then the clinical validation will take place which means that TUD physicians will give feedback on the SALUS tools to let us further refine the components.

4 PILOTS PHYSICAL ARCHITECTURE In this chapter the physical architectures for TUD pilot are summarized according to the detailed description provided in D8.2.1.

4.1 TUD pilot physical architecture The deployment reported in this deliverable describes how each SALUS component is installed and tested on TUD pilot site on the basis of the physical architecture design. Moreover, the database used for SALUS purposes will be described in more detail.

FP7-287800 SALUS


Figure 1 - SALUS architecture for in house scenario

Figure 2 - SALUS architecture for research scenarios

4.2 TST1 – TUD EHR Database for SALUS All data needed for the SALUS scenarios are stored in a test database (TST1) that has been created exclusively for the SALUS project. This data is copied from the production database KHV. Using the

FP7-287800 SALUS


test database we extract only relevant data fields for SALUS purposes. As the test database is a complete copy of the current production system it contains information from more than 3 million patients. The following table is derived from the deliverable 8.1.1 and contains all data elements that can be served by the SILDS implementation of TUD and are processed by the SALUS tools.

Table 2 - EHR Fields available in TUD EHR System

EHR Fields Required attributes Demographics Date of Birth

Gender

Address (region or city) [To check the neighbourhood of industry, heavy metals, pollution]

Problem list including active problems and past medical history

Problem description

• Coded representation of the “Problem” by using an international or a local Code System

• Problem Start Date

• Problem Date of Entry

Medications

Medication Name

Medicinal product package name

Active ingredient name

• Coded representation of the active ingredient name

Strength1

Pharmaceutical Form (of administration)

Dose (daily dose)2

Route

Start Date and Time3

Lab results Observation name (such as Platelet Count measurement)

• Coded representation of observation name Observation Result

Observation Unit

Observation date of data entry

Observation reference range

1 Amount of pharmaceutical product per product unit 2 Could be interesting to have the maximal daily dose and the minimal daily dose within the reported period of care 3 May be important to have the time of (first) administration… as element in evaluation of the link between product and reaction

FP7-287800 SALUS


Procedures Procedure Name

Coded representation of the procedure type Coded representation of the procedure Date of data entry

Responsible healthcare professional

Target Site Code

5 HARDWARE AND SOFTWARE SPECIFICATIONS On the basis of physical architecture and technical components sheet provided by SALUS technical partners, the TUD pilot site built the necessary infrastructure to carry out the planned activities.

5.1 Hardware Requirements

5.1.1 Servers - TUD pilot site In TUD pilot the following server is required for pilot activities:

OS: Windows 2008 R2 CPU: 8 core RAM: 16 GB HD: 1 TB

5.2 Software requirements The required software for the pilot infrastructure is described as follow.

5.2.1 Operating system TUD Windows 2008 R2 Standard

5.2.2 Database management system TUD Oracle: 11 Vesion 0.2

5.2.3 Other tools for system development and deployment TUD There are a number of software requirements for the deployment of SALUS components. A list of this software is given below which need to be installed to the server machines and client machines on which the safety analysis tools will be run. Please note that, each software may require configuration in addition to basic installation. These are given along with each tool below.

! JDK (1.7.X) o Environment variables to be set: JAVA_HOME

" Test: From a Windows Command Prompt execute the following and see the path to the directory where JAVA_HOME is set

• echo %JAVA_HOME% o Environment variables to be updated: PATH

FP7-287800 SALUS


" Test: From a Windows Command Prompt execute the following and see the JDK version

• javac–version ! Apache Maven (3.1.X)

o Environment variables to be updated: PATH " Test: From a Windows Command Prompt execute the following and see the

Maven version • mvn --version

! Git (1.8.X) o Environment variables to be updated: PATH

" Test: From a Windows Command Prompt execute the following and see the Maven version

• git --version ! Virtuoso Open-Source Edition (for Windows 64-bit)

o Environment variables to be updated: VIRTUOSO_HOME " Test: From a Windows Command Prompt execute the following and see the

path to the directory where VIRTUOSO_HOME is set. • echo %VIRTUOSO_HOME%

o Test: Go to the database directory under %VIRTUOSO_HOME% and run the following command

• virtuoso-t -f ! Apache Tomcat (7.X)

o Environment variables to be updated: CATALINA_HOME " Test: From a Windows Command Prompt execute the following and see the

path to the directory where CATALINA_HOME is set. • echo %CATALINA_HOME%

o Test: Run Tomcat by “startup.bat” script in its “bin” directory. From a browser, go to “localhost:8080” and see the welcome page of Apache Tomcat. And then stop the execution by “shutdown.bat” script.

o Since SALUS components have been designed as standalone web applications, it is possible to deploy each component to different containers and hosts. In order to remove any effect that may occur because of a crash of a component to other components, some of the SALUS web applications are grouped together and deployed to two different Tomcat instances.

" TUD SALUS Server: 2 Tomcat instances • Instance 0: athena, silds, atom, terminologyserver, atna • Instance 1: ant, irt, csct, pht, pmsst, tpt, safetyanalysisquerymanager

There are some other software tools that are required to only in the server machines. These are: R: Is used to execute statistical analysis rules of composed of R scripts on the patient data. TAS/TPC Tool includes analysis routines implemented with R for the temporal association screening and pattern characterization algorithms. SAS: Although SAS is installed on LISPA servers and the integrated environment is in place in LISPA deployment, SAS is not installed on TUD servers. The reason is that UKD Board accepted to share the PMSST data (deidentified and anonymized) and TUD will send the results of PMSST to Roche upon each execution on PMSST.

FP7-287800 SALUS


6 DEPLOYMENT PROFILES

6.1 Deployed SALUS Components In the design phase of the project, we had identified the SALUS components which were presented in the D8.3.1 with their unique identifiers. These components have been developed, integrated and deployed. All components deployed in TUD server are listed in the following table:

Table 3 - Deployed SALUS components to TUD

ID# Component#Name#[S$3]! SIL![S$3.1]! EHR!RDF!Service![S$3.2]! SIL$DS![S$3.2.1]! Semantic!Reasoning!Service![S$3.3]! ADE!Notification!Manager![S$3.4]! ICSR!Notification!Manager![S$4]! De$identification!Service![S$5]! ADE!Notification!Tool![S$5.1]! ADE!GUI![S$6]! ICSR!Reporting!Tool![S$6.1]! ICSR!GUI![S$7]! ICSR!Report!Generator![S$8]! TILDS![S$9.1]! Safety!Analysis!Query!Manager![S$9.2]! Safety!Analysis!Subscription!Manager![S$9.3]! Converter!and!Formatter!Services![S$9.4]! Query!Result!Calculator!Service![S$10]! Temporal!Pattern!Association!Method![S$11]! Temporal!Pattern!Characterization!Method![S$12]! Audit!Record!Repository&!GUI![S$13]! Case!Series!Characterization!Tool![S$14]! Temporal!Pattern!Characterization!Tool![S$15]! Temporal!Pattern!Association!Tool![S$16]! Patient!History!Tool![S$17]! Post!Market!Safety!Analysis!Tool![S$18]! Terminology!Server!

Although we have identified all of the components, only some of them are server deployable. The others are simple modules that are used by the server deployable components. For example authentication component will not be deployed standalone because it is a module, but it will be deployed along with sat.csct which is a service component. We have listed all of the server deployable components in the following table:

Table 4 - Server deployable components in TUD

ID# Component#Name#

FP7-287800 SALUS


[S$3.2]! SIL$DS![S$3.2.1]! Semantic!Reasoning!Service![S$4]! De$identification!Service![S$5]! ADE!Notification!Tool![S$6]! ICSR!Reporting!Tool![S$9.1]! Safety!Analysis!Query!Manager![S$13]! Case!Series!Characterization!Tool![S$16]! Patient!History!Tool![S$17]! Post!Market!Safety!Analysis!Tool![S$18]! Terminology!Server!

There were not one-to-one mappings between the components identified in the design phase and the ones included in the SALUS code base. This is because, some of the components from the design phase have been implemented in multiple actual software modules e.g. [S-9]. On the other hand, some design phase components were merged into a single software module e.g. [S-5] and [S-5.1]. In the following table, we have mapped the numbers of the components identified in the design phase to the software modules located in the source code by mainly considering the server deployable components and some other generic components e.g. salus.parent, salus.configuration.

Table 5 - Corresponding source code modules for the SALUS components

ant: ADE Notification Tool [S-5] [S-5.1] common athena [S-3] [S-9] eye [S-3] [S-9] ontmalizer [S-3] salus.configuration [All components] salus.parent [All components] information-model common-information-model [S-3] [S-9] e2b-model [S-7] irt: ICSR Reporting Tool [S-6] [S-6.1] [S-7] sat.csct: Case Series Characterization Tool security-privacy authentication deidentification [S-4] semantic-services qrc: Query Result Calculator [S-9] saqm: Safety Analysis Query Manager [S-9] sil: Semantic Interoperability Layer converter: orbis-to-cimv2 ers: EHR RDF Service silds.tud: Following methods of this API will be deployed {SILDS_ROOT}/patient {SILDS_ROOT}/eligiblepatients terminology-server: Terminology Server [S-18] salus.integration-tests [All components]

One important point is that all components have been deployed into the Care Zone of TUD according to the security rules dictated by TUD administration. The access to the services deployed at TUD has been secured through a special VPN system in order to add one more security level on top of the already secured services of SALUS. Hence, it is not possible to access the tools deployed on TUD

FP7-287800 SALUS


without first authenticating the dedicated VPN service of TUD. The necessary credentials have been provided to UMC and Roche and they can access the SALUS TUD server accordingly.

6.2 Deployment Scripts Although the SALUS team has developed dedicated deployment scripts, the extra security precautions made that hard to use the automatic deployment scripts on top of the SALUS source code. Therefore, deployment of the tools has been managed by the two technical partners, namely AGFA and OFFIS through special secure VPN channels.

6.2.1 Prerequisites Hardware and software requirements that are required to execute the deployment process on TUD server are already specified in Section 5.

6.2.2 Deployment process According to the security rules of TUD, SALUS server in TUD has been accessed by AGFA and TUD through a dedicated VPN channel. Deployment has been made by transferring the deployable WAR files to the server and directly deploy under the Tomcat instances. AGFA has mainly been responsible with the deployment of athena, pavo, orbis (SPARQL endpoint), generic-endpoint, silds and atom web components to the Tomcat Instance 0 in the SALUS TUD server. The necessary configuration files of the different components have been arranged and the components have been locally tested on the SALUS TUD server. OFFIS has mainly been responsible with the deployment of ant to the Tomcat Instance 1 in the SALUS TUD server. Apart from the components listed above, there are web component which need to be deployed and those components are managed by SRDC. Since SRDC is not allowed to access the SALUS TUD server, AGFA and OFFIS helped deployment of the remaining components. These are terminology-server, safetyanalysisquerymanager, csct, tpt and pmsst components. Apart from that, the initial OMOP import operation and the necessary local tests have also been performed by AGFA and OFFIS in communication with SRDC. In addition, the deployment of the irt has been managed with the collaboration of SRDC, AGFA and OFFIS.

6.2.3 Deployed Components The deployed SALUS web applications in terms of WAR files to the 2 different Tomcat instances are as follows: Web application name (WAR)

Tomcat Instance 0

athena silds atom pavo orbis generic-endpoint

Tomcat Instance 1

ant irt csct pmsst pht tpt safetyanalysisquerymanager

FP7-287800 SALUS


semanticmdr deidentification terminology-server

Apart from the 2 Tomcat instances, the Virtuoso Open-Source edition has also been deployed to the SALUS TUD server.

7 PILOT TIME PLAN The Piloting process consists of three unique phases:

- Deployment - Training - Running/Testing

The deployment consists of all relevant actions that needed to carried out to prepare the pilot site for installation and running SALUS prototypes. Then the End Users needed to be prepared to enable easy usage of the SALUS tools which was done using the training phase. The Running and Testing phase will be carried out during the last two months of the initial project duration plus three months of extension. During this phase all selected scenarios will be validated. Two technical took place in Dresden in order to start implementing and checking SALUS prototypes at the pilot site as well as for initiating the Training phase in Nov. 2013/2014.

FP7-287800 SALUS


Task Activities Project months

19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Deployment

Hw procurement Pre-required software installation SALUS components installation: prototype 1

Testing prototype 1 installation Review of prototype 1 components SALUS components installation: prototype 2

Testing prototype 2 installation Review of prototype 2 components

Training Training preparation (manual, planning,..)

Training execution Running/testing

Test cases creation Pilot running Pilot validation

Figure 3 – Pilot time plan draft

FP7-287800 SALUS


8 REPORT OF DEPLOYMENT ACTIVITIES IN LISPA

8.1 TUD Deployment Phase I In TUD pilot site all the installation process is performed during the technical deployment meeting held in November 2013 in TUD premises by SALUS technical partners. The 1st deployment was only on the fake database since the UKD Board had not signed the agreement by that time. The process included the following:

- Preparation of SALUS hardware - Installation of prerequired software (as mentioned in section 5) - Installation of sample data:

Testing different components and the first evaluation of the deployment will be performed on sample data. The purpose here is to see that all components are successfully running on TUD. Current data in TUD may not have the sufficient cases to be used in the full evaluation of the deployed components. For example, ANT may not be able to detect any ADEs during deployment evaluation. Therefore, technical team has prepared sample patient data to be installed to TST2 in TUD.

- Installation of SALUS components After installing the non-SALUS software, SALUS Components are deployed as in the following order. Each deployment action also includes the associated tests with that specific component. 1. terminology-server

Deployment None. This component will be remotely accessed. Test Each REST method exposed by this component will be tested. cURL tool can be used

for this purpose. cURL will be shipped by Git installation by default.

2. athena Deployment Will be deployed to Tomcat Test Each REST method exposed by this component will be tested. Sample messages can

be used to be sent with cURL during testing.

3. silds.tud ! TUD ORBIS SPARQL Endpoint

Deployment Will be deployed to Tomcat Deployment-Guide

1. The SPARQL endpoint war file, named as orbis84.war, will be copied to the $CATALINA_BASE/webapps folder of the installed Tomcat server. 2. Setup the SPARQL endpoint configuration On Windows systems orbis84 will search for configurations files in %HOMEDRIVE%%HOMEPATH%\orbis. On Linux/Unix systems, by default the application will search for configurations files in the directory $HOME/orbis, where $HOME is the home directory of the user which is used to run tomcat. If Tomcat is set up to run as a daemon, it is usually executed using a dedicated system UID. In that case it is recommended to change the default configuration directory. The location of the configuration directory can be changed by adding a orbis84.xml file in $CATALINA_BASE/conf/Catalina/localhost:

<?xml version="1.0" encoding="UTF-8"?> <Context reloadable="false" crossContext="false"> <Parameter description="The root configuration directory of Orbis" name="ORBIS_HOME" value="<An absolute path to the configuration directory>"/>

FP7-287800 SALUS


</Context>

Unpack the orbis configuration zip file in the chosen ORBIS_HOME directory. 3. A folder named as /config will be created in the location stated in the context file. The configuration file specifies the location of the ORBIS ontology (orbis.n3), the mapping file (orbis_mapping.xml) and database connection file (db.properties). 4. The aforementioned three files will be copied to the said location. The db.properties file will be modified to provide the correct JDBC connection as well as the prefix of the class instances returned from the SPARQL endpoint.

Test " Inspect log files and test REST method exposed by this component. " A set of ORBIS DDO queries will be executed, and returned results will be

checked. " The integration of the SPARQL endpoint in the silds will also be tested.

Test-Guide AGFA will test the DDO queries: Open a web browser to: http://localhost:8080/orbis84/ Execute the mentioned DDO queries on the test page and verify the results. AGFA will test calling the SPARQL endpoint from silds

! Argus

Deployment Will be deployed to Tomcat Deployment-Guide

1. Install argus.war in $CATALINA_BASE/webapps. 2. Setup the Argus configuration

On Windows systems Argus will search for configurations files in %HOMEDRIVE%%HOMEPATH%\argus. On Linux/Unix systems, by default the application will search for configurations files in the directory $HOME/argus, where $HOME is the home directory of the user which is used to run tomcat. If Tomcat is set up to run as a daemon, it is usually executed using a dedicated system UID. In that case it is recommended to change the default configuration directory. The location of the configuration directory can be changed by adding a argus.xml file in $CATALINA_BASE/conf/Catalina/localhost: <?xml version="1.0" encoding="UTF-8"?> <Context reloadable="false" crossContext="false"> <Parameter description="The root configuration directory of Argus" name="ARGUS_HOME" value="<An absolute path to the configuration directory>"/> </Context> Unpack the argus configuration zip file in the chosen ARGUS_HOME directory.

Test Inspect log files and test REST method exposed by this component. Test-Guide 1. Inspect the logfile $CATALINA_BASE/logs/argus.log to

check if Argus reads its configuration from ARGUS_HOME. 2. From a Windows Command Prompt execute each command and see the results.

Command: curl -X GET “http://localhost:8080/argus/endpoints?target=http://www.salusproject.eu/v2”

FP7-287800 SALUS


Result: An RDF file describing a SPARQL service Command: curl -X GET “http://localhost:8080/argus/endpoints/0/void.ttl” Result: An RDF file describing the Orbis SPARQL endpoint and its dataset. Command: curl -X GET “http://localhost:8080/argus/endpoints/0/rules?target=http://www.salusproject.eu/v2” Result: An N3 rules file, containing conversion rules from the Orbis DDO to the Salus CIM version 2 ontology set.

Agenda AGFA will perform the installation using remote access.

! Pavo Deployment Will be deployed to Tomcat Deployment-Guide

1. Install pavo.war in $CATALINA_BASE/webapps. 2. Setup the Pavo configuration

On Windows systems Pavo will search for configurations files in %HOMEDRIVE%%HOMEPATH%\pavo. On Linux/Unix systems, by default the application will search for configurations files in the directory $HOME/pavo, where $HOME is the home directory of the user which is used to run tomcat. If Tomcat is set up to run as a daemon, it is usually executed using a dedicated system UID. In that case it is recommended to change the default configuration directory. The location of the configuration directory can be changed by adding a pavo.xml file in $CATALINA_BASE/conf/Catalina/localhost: <?xml version="1.0" encoding="UTF-8"?> <Context reloadable="false" crossContext="false"> <Parameter description="The root configuration directory of Pavo" name="PAVO_HOME" value="<An absolute path to the configuration directory>"/> </Context> Unpack the pavo configuration zip file in the chosen PAVO_HOME directory.

Test Inspect log files and test REST method exposed by this component. Test-Guide 1. Inspect the logfile $CATALINA_BASE/logs/pavo.log to

check if Pavo reads its configuration from PAVO_HOME. 2. From a Windows Command Prompt execute each command and see the results.

Note that the results are depended on the data returned by the SPARQL endpoint and that some query parameters might need to be adapted to see any results. Command: curl -X GET “http://localhost:8080/pavo/entities/www.salusproject.eu/v2/medication?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing medications.

FP7-287800 SALUS


Command: curl -X GET “http://localhost:8080/pavo/entities/www.salusproject.eu/v2/condition?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing medical conditions. Command: curl -X GET “http://localhost:8080/pavo/entities/www.salusproject.eu/v2/lab_result?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing lab test results. Command: curl -X GET “http://localhost:8080/pavo/entities/www.salusproject.eu/v2/procedure?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing medical procedures. Command: curl -X GET “http://localhost:8080/pavo/entities/www.salusproject.eu/v2/immunotherapy?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing immunizations. Command: curl -X GET “http://localhost:8080/pavo/entities/www.salusproject.eu/v2/adverse_event?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing adverse events.


! Generic SPARQL endpoint Deployment Will be deployed to Tomcat Deployment-Guide

1. Install generic-endpoint.war in $CATALINA_BASE/webapps.

Test Inspect log files and perform a sample query. Test-Guide 1. Inspect the logfile $CATALINA_BASE/logs/generic-endpoint.log for errors.

2. From a Windows Command Prompt execute each command and see the results. Command: curl -X GET “http://localhost:8080/generic-endpoint/sparql” Result: An RDF file describing a SPARQL service Command:

FP7-287800 SALUS


curl -X GET -H "Accept: application/sparql-results+xml" “http://localhost:8080/argus/ http://aca.agfa.net/generic-endpoint/sparql?default-graph-uri=http%3A%2F%2Faca.agfa.net%2Fargus%2Fendpoints%2F0%2Fvoid.ttl&query=select+*+where+{+%3Fs+%3Fp+%3Fo+}+limit+10” Result: A SPARQL query result set. Command: curl -X GET “http://localhost:8080/argus/endpoints/0/rules?target=http://www.salusproject.eu/v2” Result: An N3 rules file, containing conversion rules from the Orbis DDO to the Salus CIM version 2 ontology set.


! SILDS Deployment Will be deployed to Tomcat Deployment-Guide

1. Install silds.war in $CATALINA_BASE/webapps. 2. Setup the SILDS configuration

On Windows systems silds will search for configurations files in %HOMEDRIVE%%HOMEPATH%\silds. On Linux/Unix systems, by default the application will search for configurations files in the directory $HOME/silds, where $HOME is the home directory of the user which is used to run tomcat. If Tomcat is set up to run as a daemon, it is usually executed using a dedicated system UID. In that case it is recommended to change the default configuration directory. The location of the configuration directory can be changed by adding a silds.xml file in $CATALINA_BASE/conf/Catalina/localhost:

<?xml version="1.0" encoding="UTF-8"?> <Context reloadable="false" crossContext="false"> <Parameter description="The root configuration directory of silds" name="SILDS_HOME" value="<An absolute path to the configuration directory>"/> </Context>

3. Unpack the silds configuration zip file in the chosen SILDS_HOME directory. 4. Edit SILDS_HOME/config/silds.properties

# Base uri for constructing entity uris silds.baseUri=http://<hostname:port>/pavo/entities/www.salusproject.eu/v2/ # Begin date for constructing entity uris silds.beginDate=2011-01-01T00:00:00 # End date for constructing entity uris silds.endDate=2013-12-31T23:59:59 # The URI of the SPARQL endpoint for executing queries, when omitted the service will download datasets and execute the queries locally silds.sparqlServiceUri=http://<hostname:port>/generic-endpoint/sparql

FP7-287800 SALUS


# The URI of the terminology server for mapping coded values, when omitted no terminology mappings will be done silds.terminologyServiceUri=http://srdc.salusproject.eu:8080/terminologyserver/

Test Inspect log files and test REST method exposed by this component. Test-Guide 1. Inspect the logfile $CATALINA_BASE/logs/silds.log to

check if silds reads its configuration from SILDS_HOME. 2. From a Windows Command Prompt execute each command and see the results.

Note that the results are depended on the data returned by the SPARQL endpoint and that some query parameters might need to be adapted to see any results. Command: curl -X GET “http://localhost:8080/silds/medication?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing medications. Command: curl -X GET “http://localhost:8080/silds/condition?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing medical conditions. Command: curl -X GET “http://localhost:8080/silds/lab_result?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing lab test results. Command: curl -X GET “http://localhost:8080/silds/procedure?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing medical procedures. Command: curl -X GET “http://localhost:8080/silds/immunotherapy?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing immunizations. Command: curl -X GET “http://localhost:8080/silds/adverse_event?begin_date=2012-08-01&end_date=2012-09-01” Result: An RDF file describing adverse events.

3. With a web browser, go to http://localhost:8080/silds/ and execute the default query. The data of patients satisfying the criteria in the query is returned.


FP7-287800 SALUS


4. semantic-services.saqm Deployment Will be deployed to Tomcat Test Each REST method exposed by this component will be tested. Sample messages can


5. security-privacy.deidentification Deployment Will be deployed to Tomcat Test Each REST method exposed by this component will be tested. Sample messages can


6. sat.csct Deployment Will be deployed to Tomcat Test " Basic GUI testing

o Eligibility query definition o Integration with terminology server while preparing the eligibility

queries o Statistical configurations on results

# Enable/disable some of the result items # Select different terminology system levels while grouping

the results o Presentation of the results after running the query

# Filtering the presented results according to the configurable thresholds

7. ant Deployment Will be deployed to Tomcat Test " ADE detection by interacting with silds.tud: Sample data will be installed to

TST2 so that an ADE can be detected and the workflow of ant can be presented.

" Basic GUI testing " Triggering irt – Integration with irt

8. irt

Deployment Will be deployed to Tomcat Test " Basic GUI testing

" Auto-population testing – integration with silds.tud " Term selection – Integration with terminology-server " Being triggered by ant – Integration with ant " Integration with de-identification service

9. salus.configuration

Deployment None. All parameters inside the salus.conf should be configured according to the deployment characteristics of the related components.

Test None.

8.2 TUD Deployment Phase II Once the UKD Board has signed the agreement the SALUS TUD server has been given access to the TST1 database. As mentioned earlier TST1 database is a SALUS specific copy of the TUD’s

FP7-287800 SALUS


production database. Since the technical arrangements on TUD to establish the secure connections took some time, deployment and performance test of the SILDS components started in mid July, and deployment of the other SALUS tools has actively started within September 2014 – after the summer period – and intensely continued until November. After a technical deployment meeting held within TUD premises during 4-6 November, deployment of all SALUS tools are completed. Technical team of SALUS is continuously monitoring the bugs and instantly fixing the deployments with the established secure remote connection to the SALUS server at TUD.

9 DEPLOYMENT STATUS AND CONCLUSIONS FOR TUD PILOT SITE

Because of the lack of the connection to the real data in TUD settings, the 1st deployment phase could not manage to test the tools on top of the real data. Some of the problems and bugs can only be observed when the systems come across the real data (i.e. missing fields, amount of data etc.). Therefore, the SALUS technical teams have spent major effort to establish a successful deployment in TUD settings. During the validation activities, the technical teams will continuously monitor the reported bugs and problems and try to fix as soon as possible in order not to cause any interruption in the validation activities.

FP7-287800 SALUS


10 APPENDIX A – SCREENCASTS OF SALUS TOOLS Screencasts have been captured and created for the components which have a GUI. The following screencasts are available at the following links: ADE Notification Tool (ANT) http://www.salusproject.eu/screencast/ant ICSR Reporting Tool (IRT) http://www.salusproject.eu/screencast/irt Case Series Characterization Tool (CSCT) http://www.salusproject.eu/screencast/csct Common Data Element Repository (CDE Repository) http://www.salusproject.eu/screencast/mdr/1 http://www.salusproject.eu/screencast/mdr/2 http://www.salusproject.eu/screencast/mdr/3 http://www.salusproject.eu/screencast/mdr/4 Post Marketing Safety Study Tool (PMSST) http://www.salusproject.eu/screencast/pmsst/1 http://www.salusproject.eu/screencast/pmsst/2 http://www.salusproject.eu/screencast/pmsst/3 Temporal Association Screening/Temporal Pattern Characterization Tool (TAS/TPC Tool) http://www.salusproject.eu/screencast/tpt/ Screencasts are recorded in pilot settings to show the graphical user interface and to provide hints for using the available tools.