D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component design

(1)

Project Number:

FP7-247945

Project Acronym:

PONTE

Project Title:

Efficient

Patient

Recruitment

for

Innovative Clinical Trials of Existing

Drugs to Other Indications

Instrument:

STREP

Thematic Priority:

ICT for integration of clinical research

and clinical care

D3.1.1 – Initial Overall PONTE

Architecture - Interface

definition and Component design

WP3 PONTE Platform Architecture

Task 3.1 Specification of the PONTE Architecture

Due Date: M09

Submission Date: 30/11/2010

Start Date of Project: 01/03/2010

Duration of Project: 36 months

Organisation Responsible for the Deliverable: ICCS/NTUA

Version: 1.0

Status Final

Author(s): Efstathios Karanastasis

Vassiliki Andronikou Efthymios Chondrogiannis Tassos Tagaris Giorgos Karkalis Nikolas Georgoudelis ICCS/NTUA ICCS/NTUA ICCS/NTUA ICCS/NTUA ICCS/NTUA ICCS/NTUA

(2)

Joseph Roumier Rainer Winnenburg Michael Schroeder Heiko Dietze CETIC TUD TUD TUD

Reviewer(s) Fabrice Estiévenart

Kostas Giokas

CETIC ICCS/NTUA

Project co-funded by the European Commission within the Seventh Framework Programme

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission)

RE Restricted to a group specified by the consortium (including the Commission)

(3)

Version History

Version Date Comments, Changes, Status Authors, contributors,

reviewers

0.1 09/07/2010 First draft version of the deliverable

stucture Efstathios Karanastasis

0.2 - 0.14 28/07/2010 - 26/11/2010

Various contributions and updates by all authors. Efstathios Karanastasis Vassiliki Andronikou Efthymios Chondrogiannis Tassos Tagaris Giorgos Karkalis Nikolas Georgoudelis Philippe Massonet Joseph Roumier Rainer Winnenburg Michael Schroeder Heiko Dietze

0.15 26/11/2010 Integrated version for internal review Efstathios Karanastasis

1.0 30/11/2010 Completed version integrating _{reviewers‟ comments, submitted to EC} Efstathios Karanastasis Vassiliki Andronikou

(4)

3.2.10 Access local and remote data sources _____________________________ 19 3.2.11 Semantic mapping ____________________________________________ 19 3.2.12 Searching data sources ________________________________________ 19 3.2.13 Access EHRs of cooperating hospitals _____________________________ 20 3.2.14 Mapping of EHR data __________________________________________ 20 3.2.15 Patient data pseudonymisation ___________________________________ 20

4. OVERALL PONTE PLATFORM ARCHITECTURE ___________________________ 21

4.1 SEMANTIC REPRESENTATION LAYER ______________________________ 23 4.2 COMMUNICATION WITH HOSPITAL EHRS ____________________________ 24 4.3 ACCESS CLINICAL / NON-CLINICAL FINDINGS ________________________ 26 4.4 SECURITY ______________________________________________________ 29

4.4.1 Authentication and Access Control __________________________________ 30

4.4.2 Securing Data Source Access _____________________________________ 32

4.4.3 Security Policy based Management of PONTE ________________________ 33

4.4.4 Anonymisation/ De-Identification of EHR Data _________________________ 34

(5)

5.1 PONTE AUTHORING TOOL ________________________________________ 35

5.1.1 Overview ______________________________________________________ 35

5.1.2 Architectural description __________________________________________ 37 5.2 DIRECT AUTHENTICATION & ACCESS CONTROL _____________________ 40

5.2.1 Overview ______________________________________________________ 40 5.2.2 Architectural description __________________________________________ 40 5.3 DECISION SUPPORT _____________________________________________ 42 5.3.1 Overview ______________________________________________________ 42 5.3.2 Architectural description __________________________________________ 44 5.4 EHR COMMUNICATION ___________________________________________ 48 5.4.1 Overview ______________________________________________________ 48 5.4.2 Architectural description __________________________________________ 49 5.5 PONTE ONTOLOGY & CTP REPOSITORY ____________________________ 52

5.5.1 Overview ______________________________________________________ 52 5.5.2 Architectural description __________________________________________ 54 5.6 ONTOLOGY MANAGEMENT________________________________________ 56 5.6.1 Overview ______________________________________________________ 56 5.6.2 Architectural description __________________________________________ 57 5.7 SEMANTIC MAPPER ______________________________________________ 58 5.7.1 Overview ______________________________________________________ 58 5.7.2 Architectural description __________________________________________ 59 5.8 ONTOLOGY-BASED SEARCH ENGINE _______________________________ 61

5.8.1 Overview ______________________________________________________ 61

5.8.2 Architectural description __________________________________________ 63

6. CONCLUSION _______________________________________________________ 67

(6)

List of Figures

Figure 1: The PONTE SOA approach ...21

Figure 2: The Overall PONTE Architecture ...22

Figure 3: SRL architecture ...24

Figure 4: Detailed view of communication with hospital EHRs ...25

Figure 5: Workflow of the semantic search engine approach as an internal service integrated with the decision support component. ...27

Figure 6: Workflow of the semantic search engine approach as stand-alone application showing the main components and their interactions. ...27

Figure 7: Querying Linked Data Sources ...28

Figure 8: Illustrating Data Sources Interlinking ...29

Figure 9: General Security Architecture ...30

Figure 10: Authentication and Access Control ...31

Figure 11: Secure Data Source Access ...32

Figure 12: Security Policy based Management ...33

Figure 13: Anonymisation / De-Identification of EHR Data ...34

Figure 14: Screen layout of the PAT ...35

Figure 15: Architecture of the PAT ...37

Figure 16: Access Control Component Architecture ...40

Figure 17: Direct Authentication Component Architecture ...41

Figure 18: Inference Knowledge ...43

Figure 19: Decision Support System Architecture ...45

Figure 20: EHR Communication ...50

Figure 21: PONTE Ontology and CTP Repository ...54

Figure 22: PONTE Ontology Management ...57

Figure 23: Semantic Mapper Component Architecture ...60

Figure 24: Top-level architecture of the Ontology-based Search Engine ...63

(7)

1. Executive summary

This deliverable presents the initial PONTE platform architecture related to the first iteration of the PONTE project. It starts from the basis of the main user cases and requirements identified in the PONTE deliverable D2.1.1 “Initial User Requirements Report” and elicits a number of relevant technical requirements for the PONTE system to fulfil. It then identifies the components needed in order to capture the identified functionality and presents their interactions as well as their detailed architecture.

Section 2 serves as an introductory section, providing a brief explanation of the purpose of the deliverable and a list of acronyms used throughout the document.

Section 3 presents the analysis and summary of the PONTE technical requirements for the first phase of the PONTE project, based on the needs expressed in the main PONTE Use Cases. Each Use Case is tackled dependently in Section 3.1 and the resulting technical requirements are summarised in Section Error! Reference source not found..

Section 4 discusses the overall approach followed in the PONTE architecture, but also presents a more detailed overview of how specific important aspects are dealt with, i.e. semantic representation of information and semantic interoperability (Section 4.1), communication with hospital EHRs (Section 4.2), access to clinical and non-clinical findings (Section 4.3), and security (Section 4.4). The analysis of these aspects includes the identification of the components required to address the specific needs.

Section 5 focuses on each PONTE component separately, by going into more detail about its objectives, the functional and non-functional capabilities, as well as its architecture, the involved technologies and its interaction and dependencies with other components of the PONTE platform. Additionally, a high-level evaluation scenario is presented for the validation of each component‟s functionality.

(8)

2. Introduction

2.1 Purpose

This deliverable aims at presenting and specifying the overall PONTE Architecture for the first iteration of the PONTE project, which includes the definition and technical analysis of its key building blocks, in order to cover the user requirements identified and analysed in the D2.1.1 PONTE deliverable (“Initial User Requirements Report”). PONTE interfaces with external data sources are analysed, whereas the PONTE components are further specified including their objectives, internal architecture and interactions/dependencies with other components. Focus has been also set on the security and privacy mechanisms to be incorporated in order to cover the respective requirements identified in WP2 (D2.1.1). This deliverable will form the basis for the technical development within WP4 and WP5.

2.2 Glossary of Acronyms

Acronym Definition

AJAX Asynchronous JavaScript and XML API Application Programming Interface

ATC Anatomical Therapeutic Chemical Classification System CA Certification Authority

CT Clinical Trial

CTP Clinical Trial Protocol

D Deliverable

DB Database

DoW Description of Work

DS Decision Support

EHR Electronic Health Record GUI Graphical User Interface

HTTP Hypertext Transfer Protocol Overview ICD International Classification of Diseases LDAP Lightweight Directory Access Protocol

LOINC Logical Observation Identifiers Names and Codes MeSH Medical Subject Headings

MVC Model-View-Controller

(9)

PAP Policy Administration Point PAT PONTE Authoring Tool PDP Policy Decision Point PEP Policy Enforcement Point PIP Policy Information Point

RDF Resource Description Language

REST Representational State Transfer architectural style

SNOMED-CT Systematised Nomenclature of Medicine -- Clinical Terms SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SPARQL SPARQL Protocol and RDF Query Language SQL Structured Query Language

SRL Semantic Representation Layer

TH Thyroid Hormone

UC Use Case

WP Work Package

WS Web Service

XACML OASIS eXtensible Access Control Markup Language XML Extensive Markup Language

(10)

3. Technical Requirements analysis

3.1 Technical analysis of PONTE Use Cases

D2.1.1 presents and analyses the PONTE user requirements of the first phase, as elicited by WP2 in close interaction with the end users of the PONTE platform. Based on these user requirements a number of main use cases were presented, covering the user interaction with the PONTE system.

This section aims at identifying the technical requirements which need to be covered by the PONTE platform, in order for it to successfully address the user requirements as described in the aforementioned use cases. Thus the first-phase use cases are analysed one-by-one in the following subsections and the technical requirements stemming from them are elicited.

3.1.1 UC1: Login

3.1.1.1 Use case description

This use case describes the login procedures that need to be carried out by all end users before they are able to access the system.

3.1.1.2 Technical Requirements

The main technical requirement is a user database storing the list of users and their details, as well as parameters that will be used for other purposes, such as the user type (or role), which can be used in a role-based access system to define the user privileges within the PONTE platform (also see section 4.4).

There is also the requirement for user authentication, checking the validity of the user credentials and allowing them access to the user interface and the PONTE platform.

Regardless of the type of authentication in place, a user interface is required, presenting the login form and the corresponding error messages whenever needed.

Right after login, the user will be presented with the introductory page of the PONTE user interface. That page may differ depending on the privileges of the user or role. Thus, there is the need for controlling the content available to the different users (authorisation).

3.1.2 UC2: Set Test of Hypothesis

This use case is about setting the test of hypothesis. Specifically, the user enters to the PONTE system the following introductory parameters: (a) the investigational active substance and (b) the study disorder, (c) the drug target.

(11)

user the ability to input the aforementioned parameters through an appropriate form.

A Clinical Trial Protocol (CTP) consists of a collection of sections and section parameters. These parameters, which are filled in by the end user, should be stored in a repository. Thus there is the requirement for a CTP parameter repository, which allows for the parameters input to the system via the aforementioned form to be automatically saved in a structured manner.

Only a Principal Investigator is allowed to access this page and set the test of hypothesis. Thus, there is the need for authorisation of user actions and control of the content available to the various users.

A knowledge repository containing available active substances and disorders, which will aid the end user by making propositions for automatically filling the form fields, and check the validity of the input data.

3.1.3 UC3: Select Cooperating Hospitals

In this use case the end user selects the hospitals that will participate in the current CT. The EHRs of these hospitals will be used by the PONTE platform for the retrieval of anonymous patient statistics and recruitment of patients.

First of all, a list of all hospitals connected at the PONTE system should be available. This list should also include information regarding the type of communication between the PONTE platform and the specific hospital. The list of hospitals that are connected with the PONTE platform must be saved in a structured manner in a database, file or ontology.

A user interface is also needed for the user interaction with the PONTE platform. The user interface should be able to present to the end user the list of all relevant hospitals which can be selected for the specific CT, and let the user chose which of those to include in the current CTP. The list should include all the hospitals for which official agreements for participation at the particular CT have been established.

A CTP parameter repository is another technical requirement storing the list of hospitals

participating at the specific CT.

Only a Principal Investigator is allowed to access this page and set the cooperating hospitals. Thus, there is the need for authorisation of user actions and control of the content available to the various users.

3.1.4 UC4: Set Clinical Trial Protocol Parameters

The objective of this use case is to allow the end users to go through the clinical trial protocol and specify the clinical trial parameters. The user must be able to navigate through the clinical trial protocol and select a section to fill in. During this process, the user can select among section-specific pre-defined queries offered by the PONTE platform which aim at facilitating this process. Moreover, the user can form subsection-specific queries and

(12)

navigate through the results for taking into account published knowledge.

A repository of predefined questions which cover the information retrieval needs for the various CTP sections must be available. These questions are to be enriched with the basic CTP parameters stemming from UC2, to form queries which reflect the current CTP.

There is also the need for decision support functionality, which, based on the CTP sub-section the investigator is working on, will provide appropriate questions related to the clinical trial parameters in this sub-section in order to more efficiently guide the researchers when filling in the respective section. The researcher thus will be able to choose the questions for which they which to retrieve information from the connected data sources and navigate through the results. Decision support mechanisms need to also be in place for making automatic checks regarding the CTP sections and their content.

The CTP parameters must be stored automatically in a CTP parameter repository, in order to prevent accidental loss. Additionally, before performing a search, the relevant CTP parameters should be loaded from the CTP parameter repository, in order to enrich the predefined questions and form queries which reflect the actual current CTP.

Accessing local and remote data sources is a key requirement for the PONTE system to

perform predefined queries to those data sources and retrieve the resulting data. A list of relevant queries is presented to the end user, who then selects the most appropriate ones according to their own criteria. Given the variety of data structures and terminologies within the various data sources involved, there is the need for semantically mapping them into a core set of concepts implemented by the system.

Searching the attached data sources using specific terms and criteria is required for

retrieving relevant data.

The end users should interact with the PONTE system through a user interface, which should provide simple and easy navigation through the CTP. The users should be able to select the CTP section, see the information retrieved automatically by the PONTE system and fill in the parameters of that CTP section with the appropriate data, in a structured manner wherever applicable. The users should also be able to input a textual description of each CTP section.

A mechanism of decision support is additionally required to help the end user when filling in the parameters of the CTP in order to ensure consistency between the various CTP parameters. This mechanism should be based on rules to be applied on specific CTP parameters which have already been set into the system.

Only specific users should be able to interact with the different sections of the CTP. Thus, there is the need for authorisation of user actions and control of the content available to the various users.

3.1.5 UC5: Perform Intelligent Search

(13)

related intelligent searches within the data sources that are attached to the PONTE platform. The users should additionally be able to prioritise the search results and filter them according to pre-defined categories.

A user interface is required in order for the users to be able to set and submit their queries, as well as select the attached data sources to be included in the search and/ or the concepts that will be used for semantic filtering of the resulting information.

Accessing local and remote data sources is an important requirement for the successful

implementation of this use case, so that the end user queries can be performed on those data sources and the resulting data be retrieved.

Searching the attached data sources according to the terms and criteria set by the user is

required for retrieving relevant data.

A knowledge repository is needed, which includes the data sources to be searched, as well as all the concepts that will be used for semantic filtering of the resulting data.

Authorisation of user actions and control of the content available to the various users is

another fundamental technical requirement, so that only specific users are able to perform searches and indirectly access the underlying data sources, if the latter require authentication.

3.1.6 UC6: View Clinical Trial Protocol

3.1.6.1 Analysis of Use Case

The objective of this use case is to allow the user to view the current version of the clinical trial protocol as well as select among different ways of display according to their preferences. The user may wish to view the different protocol sections one after another according to their numbering (consecutive), or view the parameters of other protocol sections that a specific protocol section may be related to (dependencies) or the occurrences of a specific term within the various protocol sections (semantic).

There must be a CTP parameter repository, from which the current CTP can be retrieved. A user interface is required in order to present the CTP sections to the end user. The user interface is also responsible for handling the various presentation forms (views) of the CTP according to the end user‟s preferences.

A knowledge repository is needed, which will hold the predefined dependencies between CTP sections and CTP sections / parameters, as well as between semantic terms and CTP sections / parameters.

Only specific users should be able to view the different sections of the CTP and the subsystems involved. Thus, there is the need for authorisation of user actions and control

(14)

3.1.7 UC7: Save Intermediate Version of Clinical Trial Protocol

This use case is about permanently saving the intermediate versions of the CTP they are preparing and keeping a record (versioning) of the previously saved CTPs.

There is the need for a user interface, allowing for the specific action to be performed, e.g. the presence of a “Save Protocol” button.

There must be a CTP parameter repository, where the current CTP will be stored. This also includes the requirement of adding a date/time identifier, as well as an updated version number to the stored CTP.

Only specific users should be able to save the CTP. Thus, there is the need for

authorisation of user actions and control of the content available to the various users.

3.1.8 UC8: Update Clinical Trial Protocol

The objective of this use case is to allow the end user who is authorised to load and view previously saved versions of the Clinical Trial Protocol, and edit the chronologically latest version of the Protocol in order to make updates in some of its sections.

First of all, there is the need for a user interface allowing the end user to select a specific previously saved version of the CTP and load it for viewing purposes (also see section 3.1.6 – UC6). However, these versions must be flagged as non-editable, i.e. the user is not able to make any changes to them. Only the chronologically latest version of the Protocol can be edited (see section 3.1.4 – UC4).

The desired CTP will be retrieved from a CTP parameter repository, which holds all the previously saved versions of the CTP.

Only specific users should be able to load a previously saved CTP. Thus, there is the need for authorisation of user actions and control of the content available to the various users.

3.1.9 UC9: Submit Clinical Trial Protocol

Once its editing has been completed, the end user selects the latest version of the Clinical Trial Protocol, finalises it and submits it to the system. Accordingly, the user downloads the Protocol at their computer in a predefined format.

(15)

A user interface through which the aforementioned actions can be performed is required. Specifically, the user interface supports the user selecting the latest version of the CTP and finalising it, as well as loading that version and converting it to a predefined format, which is made available to the end user for download.

A flag in the CTP parameter repository is updated, which changes the status of the latest CTP version to “finalised”.

Only a Principal Investigator user is allowed to finalise and submit a CTP. Thus, there is the need for authorisation of user actions and control of the content available to the various users.

3.1.10 UC10: Request for Patient Selection

The objective of this use case is that the user be able to request a list of proposed patients from the cooperating hospitals, who are eligible to participate at the clinical trial. The patient selection will be made according to the current Clinical Trial Protocol.

A user interface which allows the end user to make the request for patient selection is needed.

The relevant CTP parameters that are used for patient selection, as well as the list of specific hospitals participating at the very CT, must be retrieved from the CTP parameter

repository.

A list of all hospitals connected at the PONTE system should be available, which also includes information regarding the communication details between the PONTE platform and the specific hospital as well as the different coding schemas used within each hospital‟s EHR system.

Accessing EHR(s) of the cooperating hospital(s) in order to make request(s) for eligible

patients is another requirement.

A decision support mechanism which will build a safety profile for every patient based on

predefined rules is required. This profile will move the selection beyond the satisfaction of

the inclusion/exclusion criteria and encapsulate EHR information not included in the inclusion/exclusion criteria but might affect the patient‟s safety during clinical trial implementation. Additionally, given the variety of data coding schemas, terms and structures used in the EHRs across healthcare providers, there is the need for mapping the core set of concepts and coding schemas handled by the PONTE system into the ones used by the hospital EHR(s).

Only a Principal Investigator or Site Coordinator user is allowed to request for patient selection. Thus, there is the need for authorisation of user actions and control of the

(16)

3.1.11 UC11: View List of Patients for Recruitment

This use case is about presenting the list of patients eligible for recruitment to the end user. The list is resulting from the request made in UC10 and includes pseudonymised patient details and a justification of their selection, along with prioritisation based on an estimation of the safety of participation of each patient at the specific clinical trial. In a second phase, it should be also possible to prioritise the patients according to the expected efficacy as well as the cost incurring from patient participation at the clinical trial or other criteria.

There is the need for patient data pseudonymisation at the hospital‟s side, before the relevant data are pushed to the PONTE platform. This is handled at the hospital side, but PONTE can provide support for achieving this technical requirement.

Accessing EHR database(s) of the cooperating hospital(s) in order to receive the data of

selected patients is another requirement.

Given the variety of data coding schemas, terms and structures used in the EHRs across healthcare providers, there is the need for mapping them into the core set of concepts and coding schemas handled by the PONTE system, in order for them to be identifiable and processable inside of PONTE.

A user interface which displays and allows navigation in the resulting patient list, the details of the selected patients, and the justification of selection is further needed. The user is further able to sort the list according to different prioritisation criteria.

Only a Principal Investigator or Site Coordinator user is allowed to request to view and navigate through the patient list. In addition, a Site Coordinator may have the right to view the full data sets of patients from his own hospital. Thus, there is the need for authorisation

of user actions and control of the content available to the various users, depending on

the user‟s exact role.

3.2 Summary of PONTE technical requirements

This section summarises the technical requirements identified in Section 3.1.

3.2.1 User authentication

User authentication is a requirement identified in UC1. It is needed for checking the validity of the user credentials and allowing them access to the user interface and the PONTE platform.

3.2.2 User database

As identified in UC1, a user database is required for storing the list of users and their details, as well as parameters that will be used for other purposes, e.g. the user type (or role), which can be used in a role-based access system to define the user privileges within the PONTE

(17)

3.2.3 User interface

The need for a user interface for the interaction of the end users with the PONTE platform is identified in all of the above Use Cases. The user interface should offer the following minimal functionality:

 present the login form

 provide the ability to provide as input some introductory parameters (the investigational active substance, the study disorder and the drug target) through an appropriate form

 present the list of all relevant hospitals which can be selected for the specific CT, and let the user choose which of those to include in the current CTP

 provide simple and easy navigation through the CTP, and in specific:

- handle a number of different presentation forms (views) of the CTP according to the end user‟s preferences

- allow the user to select the CTP section to be edited, and fill it in a structured manner, whenever applicable, as well as input a textual description of each CTP section

- display the information retrieved automatically by the PONTE system for the current CTP section

 allow the user to set and submit custom queries, as well as select the attached data sources to be included in the search and/ or the concepts that will be used for semantic filtering of the resulting information

 allow the user to save the current CTP and select a previously saved version of the CTP to load

 select the latest version of the CTP and finalise it, as well as convert it to a predefined format and download it

 request for patient selection and then display and allow navigating (including sorting according to different criteria) the resulting patient list, the details of the selected patients, and the justification of selection.

 present the appropriate error messages whenever needed

3.2.4 Authorisation of user actions and content control

This technical requirement, which is relevant to security, was also identified in all of the above Use Cases and is about presenting different content on the user interface, as well as authorising different actions in a lower level, depending on the privileges/ role of the end users. In specific:

 Only a Principal Investigator is allowed to set the test of hypothesis or the cooperating hospitals.

 Only specific users should be able to interact with the different sections of the CTP and the subsystems involved.

(18)

 Only specific users are able to perform searches and thus access the underlying data sources, if the latter require authentication

 Only specific users should be able to load a previously saved CTP  Only a Principal Investigator user is allowed to finalise and submit a CTP

 Only a Principal Investigator or Site Coordinator user is allowed to request for patient selection

 Only a Principal Investigator or Site Coordinator user is allowed to request to view and navigate through the patient list.

 A Site Coordinator may have the right to view the full data sets of patients from his own hospital.

3.2.5 CTP parameter repository

The need for storing and retrieving the parameters of the Clinical Trial Protocol is identified in

UC2, UC3, UC4, UC6, UC7, UC8, UC9 and UC10. The functionality covered under this

technical requirement includes:

 store the introductory CTP parameters forming the test of hypothesis to the PONTE system, as well as the list of hospitals participating at the specific CT

 automatically store the CTP parameters

 manually store versions of the CTP, including a date/time identifier  allow for indicating the status of the latest CTP version (final / not final)  load/retrieve the relevant CTP parameters:

- before performing a search, in order to enrich the predefined questions and form queries which reflect the actual CTP

- to be used for patient selection, as well as the list of specific hospitals participating at the very CT

3.2.6 Knowledge repository

This technical requirement is identified in UC2, UC5 and UC6. It should keep information about the following areas:

 Available active substances and disorders, for making propositions for automatically filling of form fields, and checking the validity of the user‟s input.

 Data sources to be searched.

 Concepts that will be used for semantic filtering of the resulting search data.

 Dependencies between CTP sections and CTP sections / parameters, as well as between semantic terms and CTP sections / parameters.

(19)

3.2.7 List of all hospitals

The need for a list of all the hospitals connected at the PONTE system is identified in UC3

and UC10. The list should be saved in a structured manner in a database, file or ontology

and include, amongst others, information regarding connection between the PONTE platform and each one of the hospitals as well as the coding schemas they use.

3.2.8 Repository of predefined questions

This is a requirement according to UC4. The database of predefined questions should cover the information retrieval needs for the various CTP sections.

3.2.9 Decision support

The requirement for decision support is identified in UC4 and UC10. Decision support should cover the following specific requirements:

 Provide appropriate questions regarding a CTP section and/or CTP parameter and perform them.

 Make automatic checks regarding the CTP sections and their content for checking on their consistency based on their dependencies with other CTP parameters.

 Based on set rules applied on CTP parameters, facilitate the end user when filling in other CTP parameters, thus ensuring consistency between the various CTP parameters.

 Build a safety profile for every patient eligible for recruitment, in order to move the selection beyond the satisfaction of the inclusion/exclusion criteria and encapsulate EHR information not included in the inclusion/exclusion criteria which might affect the patient‟s safety during clinical trial implementation.

3.2.10 Access local and remote data sources

Accessing local and remote data sources including information about drugs and diseases, published clinical and non-clinical findings is a technical requirement identified in UC4 and

UC5. This is required in order to be able to perform custom or predefined queries to those

data sources and retrieve the resulting information.

3.2.11 Semantic mapping

Given the variety of data structures and terminologies within the various data sources involved in the PONTE system, the need for semantically mapping of data into a core set of concepts implemented by PONTE was identified in UC4.

3.2.12 Searching data sources

This is a requirement identified in UC4 and UC5. In order to facilitate searching the various data sources and retrieving the relevant information, predefined or user-defined terms, concepts and criteria should be used.

(20)

3.2.13 Access EHRs of cooperating hospitals

In UC10 and UC11 the requirement to retrieve information from the Electronic Health Record(s) of the cooperating hospital(s) in order to request and receive the list of patients eligible to participate at a clinical trial along with their pseudonymised data is identified.

3.2.14 Mapping of EHR data

This need was identified in UC10 and UC11. Given the variety of data coding schemas, terms and structures used in the EHRs across healthcare providers, there is the need for

mapping the outgoing and incoming information from / into the core set of concepts and

coding schemas handled by the PONTE system into / from the concepts and coding schemas used by the various hospital EHR(s).

3.2.15 Patient data pseudonymisation

There is a requirement for pseudonymisation of patient data stemming from the hospital EHR(s) identified in UC11, which, for security reasons, should be tackled at the hospital‟s side.

(21)

4. Overall PONTE platform Architecture

The aim of this section is to present the basic principles and concepts of the PONTE architecture, identify the components needed in order to realise the PONTE functionality and briefly explain the component interactions.

Figure 1: The PONTE SOA approach

Figure 1 above depicts the high-level Service Oriented Architecture (SOA) for the PONTE platform. In a SOA, the various system components interact with each other by means of Web Services (WS) [1]. These WSs can be either SOAP or REST, depending on the specific communication needs and the implementation. All components are independent from each other and hence easy to develop, update and manage, but at the same time able to interoperate seamlessly. Additionally, the various components can be deployed on different servers / machines, which greatly helps distribute the system load and the individual requirements for available memory and processing power.

This system architecture further allows for easily exposing a collection of services through an API, in order for them to be accessible by the outside world. The PONTE API also functions as a broker, hiding the underlying services exposed by the PONTE Core Components for facilitating internal communication, as well as their deployment location, and only allowing access to a number of selected services realising the communication with the outside world. The PONTE platform interacts with both humans and machines. On the left side of the figure the PONTE User Interface (a.k.a. PONTE Authoring Tool / PAT) is to be seen, which serves as the interface through which end users of various roles access the system. The PAT or authorised third parties who only wish to use specific Core PONTE functionality can connect to the Core PONTE platform via the PONTE API.

On the picture‟s right side the external data sources which are used by the PONTE platform for facilitating its scopes are visible. These vary between hospital Electronic Health Records (EHRs) and Clinical / Non-clinical Data Findings. The connection with these data sources is discussed in more detail in the following sections. The SOA approach allows for straightforward integration of new data sources to the PONTE platform.

Figure 2 presents a more detailed overview of the overall PONTE Architecture, including the Core Components and their interactions. The Core Components include the Decision Support, Extended Ontology-based Search Engine and EHR Communication components,

(22)

as well as the Semantic Representation Layer (SRL), which in turn consists of a number of components presented in more detail in Section 4.1. Red arrows represent communication with the SRL. Each “WS” box on the figure represents the communication via Web Services, as required in each case. The reader should note that this representation does not take into account the existence of the PONTE API; it rather presents the real interactions between components of the PONTE Architecture.

Figure 2: The Overall PONTE Architecture

According to the two figures above, The PONTE API would expose to the outside world selected services of the Decision Support, Extended Ontology-based Search Engine and Semantic Representation Layer, also including security services for the authentication of users and authorisation of their actions.

The PONTE security approach is not represented on Figure 2 for reasons of figure readability. However, security is a highly important issue, as it ensures that the PONTE system and the important data moved and processed within it remain uncompromised and protected. Access to the various services of the PONTE platform is restricted to the appropriate users. Security is not only limited to authentication (login) and authorisation procedures, but does also cover the communication between the various components and subsystems of the PONTE platform. The security topic is analysed in detail in Section 4.4. The following sections present a more detailed overview of how specific important aspects of the PONTE architecture are dealt with.

(23)

4.1 Semantic Representation Layer

Modelling in the medical and pharmaceutical fields has a long history. As a result, many interesting and often complex information systems have been set up in different places over the world. Moreover, even if they all deal with medicine, they are specialised, focused on a sub-domain: patients, diseases, drugs, clinical trials, etc.

PONTE will deal with this intrinsic heterogeneous nature with help of the Semantic Representation Layer (SRL).

As presented in Figure 3, the SRL is composed of several components:  PONTE ontology

This ontology is the pivot of the platform. It covers most of the semantic description aspects of the project, based partly on the Specification Language for linking clinical trials and patient medical data developed during the project. It is queried to get descriptions of the domain or a subdomain, to verify the consistency of a new element with the platform, and is a support to semantic interoperability between different data sources and Information Systems.

 Clinical Trial Protocol Repository

The CTP Repository is an ontology that is part of the PONTE ontology and provides the formal context for Clinical Trial Protocol design tasks as well as storage for the instances being developed by the users of the PONTE Authoring Tool.

 Ontology Management

Access to the ontologies is provided via two different systems: direct download from a web server for the whole ontology or predefined subparts of it, and semantic querying when only precise information is required. For example, a semantic query is needed to obtain a set of instances of a given concept.

 Semantic Mapper

Concepts (drugs, diseases, etc.) are represented in the different information systems and data sources used by different coding systems. Interoperability issues are dealt within this component. A key feature of the component is the semantic integration of the hospitals EHR databases.

The Semantic Representation Layer is the central semantic component of PONTE and is queried by almost all the components of the platform.

The ontology is queried using a semantic query language. The semantic query language is SPARQL, which is the prominent language to query semantic data. The Web Services are SOAP and REST. Legacy HTTP services are also used.

(24)

Figure 3: SRL architecture

4.2 Communication with Hospital EHRs

The communication between the PONTE system and the Electronic Health Record (EHR) database of each hospital participating at the PONTE platform is presented in more detail in Figure 4.

In order to facilitate the communication with the hospital EHRs, the EHR Communication component is invoked. That component is responsible for communicating a specific question stemming from the Decision Support component to the relevant hospital EHRs, then aggregating the response data and returning it back to the Decision Support in a common format (for more details please refer to Sections 5.3 and 5.4). Thus there is only a single interface used for communicating with the various hospital EHRs.

The different EHR databases contain patient related data (e.g. various drugs and substances, symptoms and diseases, etc.) encoded with the use of unique identifiers in different coding schemas. Some make use of international standard coding schemas (e.g., SNOMED CT, ICD10/9, ATC, LOINC), while others make use of custom ones. In some cases there are even no coding used at all, but the data is entered in the database by using words stemming from the native spoken language.

On the other hand, as detailed in section 4.1, all data used and processed within the PONTE platform are modelled and uniquely identified in the PONTE Semantic Representation Ontology.

Thus, there is the need for mapping between the data stored in the various EHR databases and the data modelled and used within PONTE. This is an important aspect that needs to be tackled with special care, since wrong mapping could cause faulty patient selection with

(25)

PONTE deals with this issue with a two-level mapping providing the best flexibility and the safest mapping for the various hospitals connected to the platform. On one level, PONTE is responsible for a semantic mapping by using an appropriate service offered by the Semantic

Representation Layer (SRL), as mentioned in Section 4.1. This applies to the case when all

the data in the EHR of a connected hospital comply with well-known standards. Then, they can be translated automatically and no further mapping is needed.

However, if the data in a hospital does not comply with a standard, there is the need for another level mapping with the use of a custom dictionary attached at the side of the hospital, which is responsible for translating the terms used within the specific EHR database to one of the available standards. The resulting data can then be translated automatically by the PONTE Semantic Mapper.

This way, ambiguous mapping is avoided, while hospital EHRs that make use of standards can be connected easily to the PONTE platform.

Figure 4: Detailed view of communication with hospital EHRs

A list of all hospitals connected to the PONTE platform is attached to the EHR Communication component, which, amongst others, contains information about the type of connection with the specific hospital EHR and the coding schema used for the identification of concepts within each EHR.

The EHR Communication component also interacts with the PONTE Security Layer, in order to perform the required authentication and/or authorisation tasks required for accessing

(26)

the various hospital EHRs.

The Web Services (WS) at the end of each hospital are responsible for receiving a standard PONTE question and asking the EHR for the required data; then, sending the resulting data (provided by the hospital) back to the PONTE system in the PONTE predefined format. Thus these WSs are implementing the queries for that EHR database and are dealing with its specific structure, which the PONTE platform is not aware of.

4.3 Access Clinical / Non-Clinical Findings

Clinical and non-clinical research findings are disseminated in the biomedical literature and in specialised databases. Innovative semantic data mining techniques for retrieving data on protein-drug-disease relations from literature and available databases will be implemented. A possible architectural realisation is based upon an existing semantic search approach (GoWeb) [2]. However, the GoWeb approach will be extended and adapted to the two possible use cases within PONTE. First, the search engine as an internal Web Service integrated with the Decision Support component will be motivated. Second, the workflow of the semantic search engine approach as Stand-alone application will be described. In both scenarios, access to the various data sources will be established using the Semantic Representation Layer and in particular the PONTE Ontology.

Figure 5 displays the workflow of the semantic search engine approach as an internal service integrated with the decision support component. The workflow starts with the user choosing one of the pre-defined questions suggested from the Decision support component (1). The

search engine component contains extracted research findings from textual sources and

from relevant linked data sources that are linked to terms from the PONTE Ontology. The documents in the document store are indexed with the relevant ontology terms using text mining (2). The text indexes are created whenever new documents are added to the clinical and non-clinical data repository in order to speed up the literature retrieval task. On

incoming queries, the search engine component selects from the indexed document store

those documents that are annotated with the relevant terms from the PONTE ontology and with links to entities of external data sources from the Linked data store and returns a list of results (3). On the basis of the identified ontology entities and their annotations, the

reasoning component provides decision support utilizing the semantics of the PONTE

Ontology (4) and returns the results to the PONTE Authoring Tool (5). The annotated documents on which the decision support is grounded will be presented to the user to provide the highest possible transparency.

(27)

Figure 5: Workflow of the semantic search engine approach as an internal service integrated with the decision support component.

Figure 6: Workflow of the semantic search engine approach as stand-alone application showing the main components and their interactions.

(28)

The second use case for the search engine as a stand-alone application used by the doctor for general research on the clinical trial topic is shown in Figure 6 above. The figure displays the workflow of the semantic search engine approach as stand-alone application showing the main components and their interactions. The workflow starts with the user submitting a

query via the search input field from the search engine started from the PONTE Authoring Tool (1). The search engine component selects from the indexed document store (2) - a

subset of the clinical and non-clinical data sources (3) - those documents that are annotated with the relevant terms from the PONTE Ontology (4). Depending on the preferences the user may have selected via the PONTE Authoring Tool, the whole PONTE Ontology, only certain parts, or only terms from specific underlying ontologies, such as GO and MeSH, are considered. The search keywords and the identified entities form the annotation are highlighted in the search results. Then the results are rendered and sent back to the search engine‟s front end started from the PONTE Authoring Tool (5). Based on the annotations and the ontology structure the tree representation is induced; top concepts are selected and sent to the front end (6).

Some of the information will come from Linked Data sources [3], which are semantic data sources accessible through Web Services using a semantic query language (see Figure 7). The origin of that data will be displayed to the end user so that he/she can evaluate it according to the trust he/she has in its origin.

Figure 7: Querying Linked Data Sources

Various data sources dealing with the same resource (drug, disease, clinical trial, etc.) are interlinked following linked data principles. It becomes possible for a piece of software to programmatically collect information about the resource coming from various data sources. The best example comes from the interlinking between the Diseasome [4] and Drugbank [5] linked data sources (see Figure 8):

- Diseasome deals with diseases. As part of the relevant information about a disease is found the property “diseasome:possibleDrug” that leads to a Drugbank item.

- Drugbank deals with drugs. As part of the relevant information about a drug is found the property “drugbank:possibleDiseaseTarget” that leads to a Diseasome item.

(29)

Figure 8: Illustrating Data Sources Interlinking

The result of this interlinking process is the possibility to retrieve precise information about a drug in a dedicated drug data source through querying a disease-oriented data source. Using the same interlinking mechanism it is possible to retrieve information about clinical trials where a given drug was used.

An extended scenario is when Linked Data sources are queried and new links to other Linked Data sources are found. They are then automatically queried in order to collect more and not previously searched for information.

The mechanisms involved in querying Linked Data sources are implemented in the

Ontology-based search engine and demand a series of specific treatments:

 From the Authoring Tool point of view, information collected from Linked Data sources is presented along with the name of the source, in order for the end user to be able to evaluate the level of trustworthiness of the content / source.

 Linked Data sources found while querying already identified Linked Data sources are added at the bottom – application specific – layer of the Semantic Representation

Layer, automatically linked when possible to the relevant concepts.

 Information coming from Linked Data sources is semantically annotated and linked to the PONTE ontology, but sometimes it consists of quite large text fragments. Rules are defined in the Ontology-based Search Engine in order to decide when to annotate and index such text fragments the same way other textual documents are in order to facilitate their re-use. E.g.: DrugBank provides text fragments for drugs that do not separate inclusion criteria from exclusion criteria.

(30)

Figure 9: General Security Architecture

Figure 9 shows the general PONTE security architecture. The first component that needs to be secured is the PONTE Authoring Tool and the PONTE API. It is a public access point to PONTE, and all users must be authenticated and their access rights controlled. The second part of the PONTE architecture that needs to be secured is the access to the remote data sources. Each data source will likely have its own authentication and access control mechanism. PONTE will have to access these remote data sources in a secure manner, verify that the data sources are the ones they claim to be, verify that communications are encrypted. The third part of PONTE architecture that needs to be secure is internal management: access to internal PONTE components should respect general security policies. The fourth part of PONTE that needs to be secured is the anonymous or de-identified access to the EHR data. The specific aspects of the PONTE security are described in more detail in the following sections.

For each clinical trial design there will be one principal clinical investigator responsible for the entire trial design. He will be responsible for assigning the appropriate clinical trial roles to all personnel involved in the clinical trial design.

There will be one role for the PONTE system administrator that is responsible for the overall management of the PONTE system. He will be authorised to give rights to the Principal Investigator user role.

4.4.1 Authentication and Access Control

Regarding authentication, three alternative designs have been considered: 1. Login/password

2. Authentication with a X509 [6] certificate provided by an existing certification authority 3. Authentication with a X509 certificate provided by an dedicated certification authority The first option is the easiest to implement. However, given the high level of confidentiality that is required in clinical trial design, and the liability related to safety issues with the clinical trial, a login/password solution provides too weak authentication.

In the second design that has been considered users must present a valid X509 certificate issued by a recognised certification authority such as VeriSign [7]. Advantage is that authentication is stronger than the previous solutions, yet remains flexible in the sense that the user can use an existing certificate that he may already have. If he does not already have an X509 certificate, he is also free to select the certification authority that he wishes.

The third option is also certificate based, but a specific certificate is required from a PONTE certification authority. This certification authority is responsible for providing roles and authorisations to users, and signing them, thus providing a high level of trust in the roles that users can play. This approach can be combined with the previous approach. If the two approaches are combined a user must then present two certificates: one to prove his identity, and another one to prove his authorised role.

This third option has been selected for PONTE because it provides both strong authentication, and strong authorisation, and will allow controlling usage of PONTE resources by all users during the entire clinical trial design process.

(31)

X.509

1. Request access 5. XACML Response with PERMIT access

PONTE

API

PONTE

API

6. Access PONTE Interface 6. Access PONTE Interface

CA

3. XACML Request 2. Verify user’s credentials 2. Verify user’s credentials 4. Evaluate the XACML Request

With the policy

X.509

X.509 Access

Control

User DB Direct Authentication

Figure 10: Authentication and Access Control

Figure 10 shows the different components for the authentication and access control of the PONTE system. First of all, any user requesting access needs to authenticate himself with the PONTE user interface and API. In order to guarantee that the PONTE Authoring Tool (PAT) is the real user interface, and not an impersonation, the user and the PAT will be required to perform mutual authentication. For the user, this implies that he must obtain an X509 certificate before accessing the PAT. Once he has obtained his certificate, he can submit it to the PAT. The PAT will then verify the user‟s credentials, as well as verify that the certificate has not been revoked. Once the user and the PAT have finished mutual authentication, the access request along with the certificate is passed to the Access Control. To support various user roles in the clinical trial design process, the recruitment process, etc., role based access control is an adequate solution. The access request is intercepted by the Policy Enforcement Point (PEP) and an XACML [8] access request is created. XACML has been selected as the security policy language because it supports well role based access control and is an accepted industrial standard. The request is then passed to the Policy Decision Point (PDP) that evaluates the request with respect to security policies. The PDP returns a permit or deny answer to the PEP. If a permit was returned then the request is passed to the respective PONTE component.

An alternative to role based access control has been considered: usage control of PONTE resources. The main difference between access control and usage control is that in the case of usage control, resource usage is continuously monitored and enforced. In access control, credentials and access rights are verified at the enforcement point. The main advantage of usage control is that usage control policies can be enforced in a continuous manner. The main disadvantage of usage control is the performance overhead that is involved in continuous monitoring and enforcement of the usage control policies. At this phase of the project, it is not clear if access control or usage control is necessary. This will depend on the

(32)

detailed security policies that must be enforced for clinical trial design. The architecture is being designed in such a way that the access control architecture can be upgraded to a usage control architecture if necessary.

4.4.2 Securing Data Source Access

Figure 11: Secure Data Source Access

PONTE must search and retrieve data from different data sources. Each data source will have its own access and security technology. The aim of this security aspect is to access the PONTE data sources in a secure manner. This requires utilising the security mechanisms used by the different data sources: some data sources will have no authentication and access control technology, others will rely on a simple login/password, while others might rely on the exchange of certificates.

The PONTE architecture makes the assumption that the data sources will be accessed via Web Service (WS) (SOAP or REST technology). Hence, access should be also secured using the different Web Services security standards.

In order for PONTE to access a data source, authentication can be performed between PONTE and a given data source using WS-trust, and an encrypted communication channel can be established. PONTE requests can be securely sent to data sources using WS-security. The data source is responsible for performing access control.

In cases where private data is involved then privacy policies can be better enforced using WS-privacy. This would be the case when eligible patients have accepted to participate in the trial and have thus given their consent to PONTE for the trial. In that case their personal data would be subject to privacy policies restricting the use of the data. For example, the privacy policy could specify that their address can only be used to communicate with them about the clinical trial they are involved in and could not use it for any other purpose.

(33)

4.4.3 Security Policy based Management of PONTE

Figure 12: Security Policy based Management

Figure 12 shows that the security policies to be enforced internally within PONTE will be managed by a Policy Administration Point (PAP). The security policies will define the different roles that are involved in the design of the clinical trial, patient recruitment, etc. For example, once the inclusion/exclusion criteria have been validated with respect to the safety objectives, the inclusion/exclusion criteria will no longer be able to be modified. Of course if the principal investigator allows the inclusion/exclusion criteria to be modified, then the inclusion/exclusion criteria will have to be validated again. Access control policies will have to secure all major steps in the clinical design process to maintain consistency of the clinical trial design. The components that will be used to implement the role based access control were described in section 4.4.1.

As described in section 4.4.1 access requests to the PAT and API will be intercepted by the Policy Enforcement Point, and passed as XACML requests to the PDP. The access request will be evaluated by the PDP with respect to the security policies and the role associated with the request. The permit or deny decision made by the PDP will be returned to the PEP. All access decisions will be logged for audit purposes. The format of the audit log will include a time stamp, the subject, the resource and the type of access request.

Use of WS-security will be considered for securing internal WS communication. However, performance issues will have to be taken into account when selecting the security mechanisms.

(34)

4.4.4 Anonymisation/ De-Identification of EHR Data

Figure 13: Anonymisation / De-Identification of EHR Data

Anonymous EHR data is sufficient to validate the selected inclusion/exclusion criteria during a clinical trial design. At the same time, de-identified EHR data is needed for patient recruitment. The EHR data will come from different hospital sources.

The hospitals are responsible for anonymising or de-identifying the patient data before making it accessible to PONTE. Some hospitals have anonymisation/de-identification procedures, whereas others might have to develop or adapt them.

Access to EHR data by PONTE can be upon request if the hospital does not wish to provide data via an automated procedure. In this case, hospitals will anonymise/de-identify patient data and make it available to PONTE. If hospital policies allow them to provide the anonymised/de-identified patient data via an automated procedure, then Web Service technology can be used to access that patient data upon request. The architecture for accessing anonymised/de-identified patient data via web services is shown in Figure 13. This has been discussed in more detail in section 4.2. The main advantage of a Web Service access to patient data is that the data can be accessed at any time.

With respect to the European data protection directive, anonymisation techniques is the required approach in Europe. However, in the United States de-identification techniques are also accepted. The use of de-identification techniques however does not respect the European data protection directive, and will not be used in PONTE (please refer to PONTE deliverable D2.1.1. for more information regarding the legal aspects).

D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component design

Project Number:

FP7-247945

Project Acronym:

PONTE

Project Title:

Efficient

Patient

Recruitment

for

Innovative Clinical Trials of Existing

Drugs to Other Indications

Instrument:

STREP

Thematic Priority:

and clinical care

D3.1.1 – Initial Overall PONTE

Architecture - Interface

definition and Component design

Version History

Table of Contents

List of Figures

1. Executive summary

2. Introduction

2.1 Purpose

2.2 Glossary of Acronyms

3. Technical Requirements analysis

3.1 Technical analysis of PONTE Use Cases

3.2 Summary of PONTE technical requirements

4. Overall PONTE platform Architecture

4.1 Semantic Representation Layer

4.2 Communication with Hospital EHRs

4.3 Access Clinical / Non-Clinical Findings

X.509

X.509

PONTE

API

PONTE

API

CA

CA

X.509

X.509

Access

Control