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

Transcription

1 Project Number: Project Acronym: FP PONTE Project Title: Efficient Patient Recruitment for Innovative Clinical Trials of Existing Drugs to Other Indications Instrument: Thematic Priority: STREP ICT for integration of clinical research and clinical care D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component design WP3 Task 3.1 Due Date: PONTE Platform Architecture Specification of the PONTE Architecture M09 Submission Date: 30/11/2010 Start Date of Project: 01/03/2010 Duration of Project: Organisation Responsible for the Deliverable: 36 months ICCS/NTUA Version: 1.0 Status Final Author(s): Efstathios Karanastasis Vassiliki Andronikou Efthymios Chondrogiannis Tassos Tagaris Giorgos Karkalis Nikolas Georgoudelis Philippe Massonet ICCS/NTUA ICCS/NTUA ICCS/NTUA ICCS/NTUA ICCS/NTUA ICCS/NTUA CETIC

2 Reviewer(s) Joseph Roumier Rainer Winnenburg Michael Schroeder Heiko Dietze Fabrice Estiévenart Kostas Giokas CETIC TUD TUD TUD CETIC ICCS/NTUA Project co-funded by the European Commission within the Seventh Framework Programme Dissemination Level PU Public X PP RE CO Restricted to other programme participants (including the Commission) Restricted to a group specified by the consortium (including the Commission) Confidential, only for members of the consortium (including the Commission) 2010 PONTE Page 2 of 68

3 Version History Version Date Comments, Changes, Status Authors, contributors, reviewers /07/2010 First draft version of the deliverable stucture Efstathios Karanastasis Efstathios Karanastasis Vassiliki Andronikou Efthymios Chondrogiannis Tassos Tagaris /07/ /11/2010 Various contributions and updates by all authors. Giorgos Karkalis Nikolas Georgoudelis Philippe Massonet Joseph Roumier Rainer Winnenburg Michael Schroeder Heiko Dietze /11/2010 Integrated version for internal review Efstathios Karanastasis /11/2010 Completed version integrating reviewers comments, submitted to EC Efstathios Karanastasis Vassiliki Andronikou 2010 PONTE Page 3 of 68

4 Table of Contents 1. EXECUTIVE SUMMARY 7 2. INTRODUCTION PURPOSE GLOSSARY OF ACRONYMS 8 3. TECHNICAL REQUIREMENTS ANALYSIS TECHNICAL ANALYSIS OF PONTE USE CASES UC1: Login UC2: Set Test of Hypothesis UC3: Select Cooperating Hospitals UC4: Set Clinical Trial Protocol Parameters UC5: Perform Intelligent Search UC6: View Clinical Trial Protocol UC7: Save Intermediate Version of Clinical Trial Protocol UC8: Update Clinical Trial Protocol UC9: Submit Clinical Trial Protocol UC10: Request for Patient Selection UC11: View List of Patients for Recruitment SUMMARY OF PONTE TECHNICAL REQUIREMENTS User authentication User database User interface Authorisation of user actions and content control CTP parameter repository Knowledge repository List of all hospitals Repository of predefined questions Decision support Access local and remote data sources Semantic mapping Searching data sources Access EHRs of cooperating hospitals Mapping of EHR data Patient data pseudonymisation OVERALL PONTE PLATFORM ARCHITECTURE SEMANTIC REPRESENTATION LAYER COMMUNICATION WITH HOSPITAL EHRS ACCESS CLINICAL / NON-CLINICAL FINDINGS SECURITY Authentication and Access Control Securing Data Source Access Security Policy based Management of PONTE Anonymisation/ De-Identification of EHR Data PONTE PLATFORM COMPONENTS PONTE Page 4 of 68

5 5.1 PONTE AUTHORING TOOL Overview Architectural description DIRECT AUTHENTICATION & ACCESS CONTROL Overview Architectural description DECISION SUPPORT Overview Architectural description EHR COMMUNICATION Overview Architectural description PONTE ONTOLOGY & CTP REPOSITORY Overview Architectural description ONTOLOGY MANAGEMENT Overview Architectural description SEMANTIC MAPPER Overview Architectural description ONTOLOGY-BASED SEARCH ENGINE Overview Architectural description CONCLUSION REFERENCES PONTE Page 5 of 68

6 List of Figures D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component 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 Figure 6: Workflow of the semantic search engine approach as stand-alone application showing the main components and their interactions 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 Figure 25: Search results for query Thyroid hormone receptor limited to specific sites PONTE Page 6 of 68

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. Section 6, finally, presents a summary of the deliverable PONTE Page 7 of 68

8 2. Introduction D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component 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 WP Glossary of Acronyms Acronym AJAX API ATC CA CT CTP D DB DoW DS EHR GUI HTTP ICD LDAP LOINC MeSH MVC OBSE OWL Definition Asynchronous JavaScript and XML Application Programming Interface Anatomical Therapeutic Chemical Classification System Certification Authority Clinical Trial Clinical Trial Protocol Deliverable Database Description of Work Decision Support Electronic Health Record Graphical User Interface Hypertext Transfer Protocol Overview International Classification of Diseases Lightweight Directory Access Protocol Logical Observation Identifiers Names and Codes Medical Subject Headings Model-View-Controller Ontology-Based Search Engine Web Ontology Language 2010 PONTE Page 8 of 68

9 PAP PAT PDP PEP PIP RDF REST SNOMED-CT SOA SOAP SPARQL SQL SRL TH UC WP WS XACML XML Policy Administration Point PONTE Authoring Tool Policy Decision Point Policy Enforcement Point Policy Information Point Resource Description Language Representational State Transfer architectural style Systematised Nomenclature of Medicine -- Clinical Terms Service Oriented Architecture Simple Object Access Protocol SPARQL Protocol and RDF Query Language Structured Query Language Semantic Representation Layer Thyroid Hormone Use Case Work Package Web Service OASIS extensible Access Control Markup Language Extensive Markup Language 2010 PONTE Page 9 of 68

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 UC1: Login 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 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) UC2: Set Test of Hypothesis Use case description 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 Technical Requirements The technical requirement stemming from this use case is a user interface, giving the end 2010 PONTE Page 10 of 68

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 UC3: Select Cooperating Hospitals Use case description 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 Technical Requirements 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 UC4: Set Clinical Trial Protocol Parameters Use case description 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 2010 PONTE Page 11 of 68

12 navigate through the results for taking into account published knowledge Technical Requirements 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 subsection 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 UC5: Perform Intelligent Search Analysis of Use Case The objective of this use case is to allow the authorised users to manually perform study PONTE Page 12 of 68

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 Technical Requirements 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 UC6: View Clinical Trial Protocol 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) Technical Requirements 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 of the content available to the various users PONTE Page 13 of 68

14 3.1.7 UC7: Save Intermediate Version of Clinical Trial Protocol Analysis of Use Case 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 Technical Requirements 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 UC8: Update Clinical Trial Protocol Analysis of Use Case 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 Technical Requirements 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 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 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 UC9: Submit Clinical Trial Protocol Analysis of Use Case 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 PONTE Page 14 of 68

15 Technical Requirements 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 UC10: Request for Patient Selection Analysis of Use Case 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 Technical Requirements 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 content available to the various users, depending on the user s exact role PONTE Page 15 of 68

16 UC11: View List of Patients for Recruitment Analysis of Use Case 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 Technical Requirements 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 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 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 platform PONTE Page 16 of 68

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 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 PONTE Page 17 of 68

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 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 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 PONTE Page 18 of 68

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 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 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 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 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 UC 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 PONTE Page 19 of 68

20 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 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) 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 PONTE Page 20 of 68

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, 2010 PONTE Page 21 of 68

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 PONTE Page 22 of 68

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 PONTE Page 23 of 68

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 eventual risks for the study outcome and the patient health PONTE Page 24 of 68

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 2010 PONTE Page 25 of 68

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 PONTE Page 26 of 68

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 PONTE Page 27 of 68

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 PONTE Page 28 of 68

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. 4.4 Security 2010 PONTE Page 29 of 68

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 deidentified 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 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 PONTE Page 30 of 68

31 1. Request access 6. Access PONTE Interface PONTE API X.509 X XACML Response with PERMIT access CA User DB Direct Authentication 2. Verify user s credentials Figure 10: Authentication and Access Control 3. XACML Request Access Control 4. Evaluate the XACML Request With the policy 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 2010 PONTE Page 31 of 68

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 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 WSsecurity. 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 PONTE Page 32 of 68

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 As described in section 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 PONTE Page 33 of 68

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 D for more information regarding the legal aspects) PONTE Page 34 of 68

35 5. PONTE platform components 5.1 PONTE Authoring Tool Overview Objectives The PONTE Authoring Tool (PAT) is a user friendly Web application that provides the end user access to the PONTE system. The Authoring Tool will help the user fill in each section of the protocol by providing useful information wherever possible, in order to ensure protocol consistency and patient safety Functional capabilities The end users setting up a Clinical Trial (CT) and requesting for patient recruitment can interact with the PONTE system by means of the PAT. The PAT is able to guide them through the process of forming the CT protocol via an advanced GUI and makes it easy for them to recruit eligible patients. User authentication to the PONTE platform is also performed through the interface of the PAT. Additionally, the PAT supports a variety of user roles, as identified in D2.1.1 and discussed in Section 3. Figure 14: Screen layout of the PAT 2010 PONTE Page 35 of 68

36 Figure 14 presents an overview of a possible main screen layout of the PAT. The screen is divided into five (5) main areas. The protocol area on the left side consists of three (3) main tabs, each representing a different View of the protocol. o o o The Successive View displays the different protocol sections in their correct order. The user can choose a section and fill it in with the information required, with the help of the system. In the Dependencies View the protocol sections are categorised according to their dependencies. There can be several sections in a protocol dependent to each other or containing similar information. The section dependencies are predefined in the CTP Ontology (see Section 5.5). The Semantic View presents the semantic dependencies in the CTP, i.e. the occurrences of the same semantic term in different sections of the CTP. This information is also predefined in the CTP Ontology. In the search area, on the right side of the screen, the PAT offers to end users the ability to perform custom queries, utilising all or selected underlying data sources, through the direct invocation of the Ontology-based Search Engine component (see Section 4.3). The PONTE area is the place where the information retrieved by the PONTE system is displayed. o o In the Successive View this area presents the predefined questions which are automatically retrieved for each protocol section from the Decision Support component (see section ). The user can select which questions to perform, in order to be presented with the resulting information. In the Dependencies or Semantic View the PONTE area presents the other sections or parameters of the CT protocol which the currently selected section or term has dependencies with correspondingly. The structured area is displayed to the end user for the CTP sections that it is applicable. In this area, the end user can fill in a set of predefined parameters in a structured manner, according to the specific CTP section being edited. This allows the PONTE platform to easily identify and process the input data, e.g. perform various consistency checks on it. In the text area the end user can compose the content of the current protocol section in plain text. The total of the plain text blocks aggregated from the different protocol sections are going to form the final CTP generated by the doctor with the aid of PONTE. The values of the structured data (visible on the STRUCTURED area above) can be filled in by the PAT in order to avoid user mistakes and inconsistencies Non-functional capabilities Accessibility The PAT is the main means of interaction with the PONTE platform. Thus it should comprise an advanced Web-based Graphical User Interface (GUI) environment, 2010 PONTE Page 36 of 68

37 D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component which can be displayed in any Web browser, offering easy accessibility from different locations. User friendliness The PAT user interface should be easy to navigate for all end users. The provided functionality should be self-explanatory and appropriate messages should be presented to the users whenever required. Additionally, it is expected that even users not familiar with similar applications can easily learn how to use it, without the need for special training. Responsiveness The PAT should respond immediately to any user interaction, as long as this is possible given the responsiveness of the other components of the PONTE system. Unnecessary reloading of a page should be prevented. Only the necessary information should be loaded, and only the necessary changes on the current page should be made. This will reduce waiting times and waste of bandwidth. The above requirements will be evaluated and enforced through testing, quality assurance and usability testing Architectural description Component architecture Figure 15: Architecture of the PAT 2010 PONTE Page 37 of 68

38 The Authoring Tool architecture and components are depicted in Figure 15. It consists of the following layers: The PAT Web Client is the part of the application running on the web browser. It contains a JavaScript library component (PAT Web Client Library) implementing the presentation logic of the application, providing rich user interaction capabilities and communicating with the server-side components. The PAT Web Server Application running on a web server host implements the core functionality of the Authoring Tool and communicates with the rest PONTE platform. It encapsulates the user interface rendering logic and the orchestration of user actions and business workflows. The PAT Local Storage contains a local database which provides persistence services for the needs of the PAT Web Server Application. All CTP parameters are persisted on the local storage throughout the authoring lifecycle. The Authoring Tool architecture is based on the Model-View-Controller (MVC) [9] design pattern. The PAT Web Server Application contains the Request Handler component which receives requests from the browser (PAT Web Client), invokes the appropriate actions on the PAT Business Logic component, creates the corresponding user interface elements from the UI Controls Library component and renders the response back to the browser. The Request Handler is also responsible for communicating with the Authentication / Authorisation module in order to establish a security context for the execution of the request handling. The PAT Business Logic component is implementing the core application logic and is responsible for interacting with the other PONTE components such as the Decision Support and the Ontology Manager components. The Business Logic component also uses the PAT Local Storage component to temporarily store the CTP parameters filled in by the users and other application state information Involved technologies The PAT Web Client will make extensive use of JavaScript technology in order to provide a rich user-friendly browser based interface. This is the purpose of the PAT Web Client Library which will utilise the jquery library [10], an advanced and widely used JavaScript library facilitating web development and Ajax [11] programming. Ajax will also be used in order to create a more interactive and dynamic interface Dependencies and interactions The PAT is the only means by which the end user can interact with the PONTE system. The PAT interacts directly with the following components of the PONTE architecture: The Direct Authentication components evaluate the user credentials provided through the PAT in order to grant or deny the user access to the PONTE platform. The Access Control component checks the user roles and enforces specific access rights in the various pages of the PAT, and the underlying PONTE services accordingly PONTE Page 38 of 68

39 D3.1.1 Initial Overall PONTE Architecture - Interface definition and Component The Decision Support component serves various requests received from the PAT. These requests regard the provision of CTP-section-specific predefined queries, CTP parameter dependency checks, patient population information, or subjects eligible for recruitment along with profiling. The Ontology-based Search Engine component can be invoked directly through the PAT interface, if the user wishes to perform a manual search in the underlying data sources. The Ontology Manager component is invoked to access the CTP Repository in order to store and retrieve the CTP instances edited by the users. Also the Ontology Manager is called by the PAT to retrieve the CTP structure, as well as its section and semantic dependencies, in order to facilitate the presentation of the different Views of the protocol. The PAT also interacts indirectly with a number of components, such as the Ontologybased Search Engine and the EHR Communication through the Decision Support. These interactions are transparent to the end user Evaluation scenario The evaluation of the PONTE Authoring Tool will be based on the thyroid hormone therapy scenario and the use cases described in Section3. The evaluation for the PAT Web client user interface consists of the following scenarios: The PAT interacts with the Ontology Management component to loads the CTP structure and parameters (in case of a new CTP, the parameter values are null) and stores them in the PAT Local Storage. Based on the specific protocol structure, the user can navigate the protocol by selecting one of the three possible Views. The user selects a protocol section and the parameters contained in the section are retrieved from the PAT Local Storage and presented on the DOCTOR area of the screen. Also a set of predefined queries is shown in the PONTE area of the screen. The user edits a protocol section and the CTP parameter values are sent to the PAT server to be stored in the PAT Local Storage. The user chooses to save the latest version of the protocol. The PAT transfers the CTP parameters residing in the PAT Local Storage to the Ontology Management component, to be stored in the CTP Repository. The user selects a protocol section. The PAT makes a request to the Decision Support component for the predefined questions regarding the specific section. The DS returns the available questions to the PAT. The user chooses one of the predefined questions, which is subsequently executed against the data sources and the results are presented in the PAT user interface. The user selects the Dependencies or Semantic view and the sections which are dependent or semantically linked to the selected section are presented on the PROTOCOL area of the screen. The user selects to execute a custom query and the Ontology-based Search Engine 2010 PONTE Page 39 of 68

40 interface is shown. 5.2 Direct Authentication & Access Control Overview Objectives The Direct Authentication and Access Control components checks the user identity and checks if a user has access to the PONTE platform and which actions are allowed to be performed based on his role in the system. The access control policies are enforced, accordingly Functional capabilities The access control components aim to provide role based access control capabilities for achieving confidentiality requirements within PONTE. The will allow to control access requests to PONTE resources from PONTE users. The authentication component aims to issue digital certificates certifying identity and role of a subject with a public key. This will allow third parties to rely on identity and role signatures made by the private key that corresponds to the public key Non-functional capabilities The access control and authentication servers must themselves be secured Architectural description Component architecture Evaluate(Request) PEP Evaluate(Request) PDP GetAttributes() PIP GetPolicies() PAP Security Policy DB LDAP Figure 16: Access Control Component Architecture 2010 PONTE Page 40 of 68

41 Figure 16 shows the access control component architecture. The Policy Enforcement Point (PEP) component intercepts and evaluates all resource access requests. The PEP is responsible for enforcing access control decisions. The PEP has a method to build an access control request based on descriptions of the subject, resource and the requested action on the resource. The PEP can request an access control decision from the Policy Decision Point (PDP) and can also request to generate audit records of past decisions by the PDP. The PDP is responsible for making an access control decision, and returning an allow or deny decision. To make this decision the PDP needs to be able to request attribute values from the policy information point (PIP). The PIP is responsible for managing the attribute values that are needed for evaluating policies for PONTE. These attributes are information about the state of the application that is necessary for evaluating the security policies. The PDP can request a list of applicable security policies from the Policy Administration Point (PAP). It can also request the policies from the PAP. The PAP is responsible for managing the security policies. The security policies may be stored in a database, a file or a LDAP [12] server. The PAP can create, modify and delete policies, list the policies, determine the list of applicable policies, notify of policy changes, and configure auditing behaviour. The PAP may also generate audit records, if needed. The above described access control architecture can be extended into a usage control architecture by replacing the access control PDP with a usage control PDP. The policy language to be used for describing security policies will be different, and will be a usage control policy language instead of an access control policy language. User CA Add(), Delete(), Modify() CreateCertificate() VerifyCertificate() PDP User DB Figure 17: Direct Authentication Component Architecture Figure 17 shows the Direct Authentication component architecture that aims to provide authentication of identity and role of PONTE users. In this architecture the Certification Authority (CA) is responsible for issuing X509 certificates with identity and role attributes, and managing the list of users so that verifications can be made against an identity and role store PONTE Page 41 of 68

42 The main function of the CA is creating user certificates based on an identifier, name, organisation and address information. The second function is a verification function that given a user certificate verifies it against the identity and role store. The CA can add, delete and modify user certificates in the User DB Dependencies and interactions The Direct Authentication component will interact with the end user who may request a certificate, and the PDP who can request certificate attribute verifications from the CA. The CA will manage a database of user credentials it has issued. All access to the user database will be from the CA. The Access Control component will mostly interact with the PAT and the PONTE API. The Access Control components will intercept all calls to the PONTE API and enforce the PONTE security policies. This interaction allows protecting the external PONTE interfaces. Future work will involve analysing interactions within PONTE, and securing those interactions to provide internal security. Additional interactions between the Access Control component and other components will then be identified Evaluation scenario There are several important access control scenarios. The main one is requesting an access control decision. In this scenario the requestor attempts to access a resource and presents his credentials. The PDP then starts the evaluation of the access request. Once he has identified the relevant security policies from the PAP, he interacts with the PIP to obtain attributed values, e.g. current date and time, and starts the evaluation. The allow or deny decision is returned to the requestor. Another scenario is a user who requests the security policies. In this scenario, the user sends a request directly to the PAP. The PAP then calls the PDP to verify that the user is authorised to ask for the security policies. If he is authorised, the PAP returns that security policies to the requestor. The same scenario can be extended to the list of applicable security policies. The PAP then has to determine the list of applicable security policies. 5.3 Decision Support Overview Objectives The purpose of the Decision Support (DS) component is to help the end user of the PONTE platform make the correct decisions, by automatically retrieving and presenting relevant data from various data sources, as well as performing reasoning tasks on them. It thus addresses the user needs with existing and newly inferred knowledge, as depicted in Figure PONTE Page 42 of 68

43 Figure 18: Inference Knowledge The purple ellipsis represents the knowledge acquired directly from the data sources through the execution of queries. The blue ellipsis represents the knowledge acquired through the application of rules on the previous knowledge (purple ellipsis). In this manner, the available knowledge is extended Functional capabilities Predefined Queries For selected sections of the CTP, the DS component automatically provides a set of predefined questions which have the aim to help the end user retrieve information relevant to the section that he is currently editing. By means of the PONTE Authoring Tool (PAT), the end user can chose among those questions and view the query results on the PAT screen. CTP Parameter Dependency Check The DS component is responsible for checking direct or indirect dependencies between parameters of the various sections of the CTP and notifying the end user in case there are inconsistencies, through the PAT. These dependencies, which have been identified and described in the PONTE requirements analysis document (D2.1.1), can be checked by the application of appropriate rules. Patient Population In the CTP section regarding inclusion/exclusion criteria, the DS component appraises how the patient population is affected by the specification of particular inclusion or exclusion criteria. The pool of patients evaluated is stemming from the EHRs of total of the hospitals being part of the specific CT. The information of patient population is provided to the end user via the PAT, so that he can consider changing any non-critical (in terms of patient safety) inclusion/exclusion criteria in order to raise the number of recruitment candidates. Eligible Subjects Profile During the patient recruitment phase, the DS component builds a patient profile for each of the subjects who fulfil the CTP and are eligible for recruitment, i.e. satisfy the CTP 2010 PONTE Page 43 of 68

44 inclusion/exclusion criteria. The profiles are based towards patient safety. For example, the DS checks for the therapies that each subject is following and the possible interactions between those and the drugs to be administered during the CT. In case that such interactions pose a possible risk for are subject s health, the subject receives a lower rating compared the others. The user can view the subjects rating through the PAT, as well as an explanation of each rating, before finally deciding which subjects to recruit Non-functional capabilities Rule Correctness The rules used for the deduction of conclusions and the inference of new knowledge must be carefully selected in order to always lead to correct results. Applicability of Rules across Clinical Trials The same core rules should be able to serve the purposes of different clinical trials. Data Integration The DS component provides to the end user of PONTE services that utilise knowledge existing in different data sources (EHRs, Clinical/Non-Clinical data, etc.). However, the end user receives the resulting data in a unified manner, as if they were stemming from a single knowledge base Architectural description Component architecture Figure 19 depicts the architecture of the DS component and how it interacts with the other components of the PONTE Architecture PONTE Page 44 of 68

45 Figure 19: Decision Support System Architecture DS Manager The DS Manager is responsible for handling the incoming requests from the PONTE Authoring Tool according to their type and performing the appropriate actions in order to satisfy them. If there is the need for reasoning, the DS Manager invokes the Reasoner PONTE Page 45 of 68

46 In cases when the incoming request concerns the provision of predefined questions for a specific CTP section, the questions are loaded directly from the questions database and returned to the PAT for presentation to the end user. Also, whenever there is a request for obtaining the patients population, the DS Manager gathers the required data and directly invokes the EHR Communication component. Subsequently, it returns the resulting data to the PAT for presentation to the end user. In order to handle more complicated requests, such as checking CTP parameter dependencies or building the eligible subjects profile, the Reasoner needs to be invoked. Reasoner The Reasoner is responsible for formulating new conclusions from existing knowledge, and is invoked whenever reasoning functionality is required. It consists of the following basic elements, which are further detailed below: Rules, Rule Engine and Knowledge Aggregator. Rules The logic of the Reasoner is expressed as a set of Rules which are separated from the application code so that they are clear and easily updatable. The rules have the following format: IF <precondition> THEN <action> and consist of two parts: the precondition part ( IF statement), which specifies one or more checks to be executed, and the action part ( THEN statement), which determines the action(s) to be performed in case that the precondition(s) are satisfied. The consequence of a performed action can be the modification of some data values or the addition of new external data to the set of existing ones, acquired by means of the Knowledge Aggergator. Rule Engine The Rule Engine is responsible for handling the Rules, and producing new knowledge based on the existing one by executing the Rules as appropriate. This is done in accordance with the following data-driven process: - Based on the existing state (values) of the data it finds all the rules that are eligible for execution, i.e. all the rules whose precondition happens to be true. - Based on the conflict resolution policy in use, it selects the most appropriate rule to be executed. - It executes the selected rule, thus updating the data values. This process is repeated until there is no appropriate Rule to be executed anymore. The result of the process is an updated data set values, i.e. a list of new facts inferred from the previous knowledge. Knowledge Aggregator The Knowledge Aggregator is invoked whenever an action is executed, which asks for data from external sources. In such cases, the Knowledge Aggregator functions 2010 PONTE Page 46 of 68

47 as an interface which facilitates the connection with the external data sources, as needed. Regarding the aforementioned functionality of the PONTE DS component, useful data for the Reasoner resides in the hospital EHRs, the PONTE Ontology, and the other Clinical/Non-Clinical data sources. The data found in external data sources and collected by the Knowledge Aggregator is returned to the Rule Engine, which in turn updates the data set in order to be used for further processing, i.e. the application of another Rule on it Involved technologies Resource Description Framework [13] (RDF) / Extensive Mark-up Language (XML) [14] The responses received from the Ontology Based Search Engine component will be an RDF/XML Document Dependencies and interactions The Decision Support component interacts directly with the following components of the PONTE architecture: The PONTE Authoring Tool component communicates a specific request along with the appropriate parameters to the DS component. In order to serve each incoming request, the DS performs a number of tasks and sends the resulting data back to the PAT for presentation to the end user. The DS component connects directly with the List of Predefined Questions in order to fetch the appropriate questions, whenever a request for predefined questions is received. The Ontology-based Search Engine component supplies the DS with the structured data results of performed searches, in order for them to be evaluated / filtered or just returned back to the PAT, depending on the occasion. The Ontology Management component provides the DS with data and data structures stemming from the CTP Repository and the PONTE Ontology, as required. For example, when requested to perform dependency check on CTP parameters, the DS component retrieves the corresponding parameter values from the CTP Repository and performs reasoning actions on them. The EHR Communication component provides the DS with patient data stemming from the EHRs of cooperating hospitals, in two cases: When the DS requests a list of subjects eligible for recruitment and when it requests the patient population Evaluation scenario The DS component receives a request from the PAT for provision of predefined questions, along with the identifier of the CTP section that the request stands for. The DS Manager evaluates the type of the request and automatically retrieves the section-specific questions from the predefined questions database. Additionally, it interacts with the Ontology Management component and receives from the CTP Repository the relevant CTP parameters, in order to customise each question so that 2010 PONTE Page 47 of 68

48 it reflects the current CTP. Subsequently, it sends the CTP-specific questions back to the PAT, in order to be displayed on the user interface screen. The next request from the PAT is about executing a specific question that the user has clicked on. The DS Manager receives the question s identifier and subsequently invokes the Ontology-based Search Engine for query execution. After the successful retrieval of the query results the DS Manager passes them back to the PAT for presentation to the end user. The DS component receives from the PAT a request for dependency checking a specific CTP parameter. The DS Manager recognises the type of request and invokes the Reasoner in order to fulfil the request. The Reasoner performs a number of Rules on the CTP parameter under investigation. Some of these Rules may include fetching other CTP parameters from the CTP Repository for comparison. Such actions are executed by the Knowledge Aggregator in interaction with the Ontology Manager. Any inconsistency inferred is returned back to the PAT for the end user to be properly informed. The DS component receives from the PAT a request for patient population. The DS manager recognises the type of request and interacts with the Ontology Manager in order to retrieve from the CTP Repository the inclusion and exclusion criteria of the current CTP. It subsequently propagates the request to the EHR Communication component, which is responsible for interacting with the EHRs of the participating hospital(s) in order to retrieve the number of patients that fulfil the specific inclusion/exclusion criteria. The answer is returned back to the PAT and presented to the end user. The DS component receives from the PAT a request for patient recruitment. The DS Manager loads the inclusion / exclusion criteria from the CTP Repository by means of the Ontology Manager. It then invokes the EHR Communication component for retrieving the pseudonymised list of eligible patients, along with their EHR data, form all cooperating hospitals. As soon as the data is collected back at the DS component, the DS Manager invokes the Reasoner. The Reasoner follows the appropriate Rules to build the safety profile for each of the eligible subjects. It additionally assigns to each profile a safety ranking, along with an explanation of that ranking. The list of subjects, also containing the inferred information, is returned to the PAT for presentation to the end user. 5.4 EHR Communication Overview Objectives This component serves as a single point for communication with the hospital EHRs. It is also responsible for collecting the query response data stemming from the EHRs of the various hospitals connected to the PONTE platform and delivering them in a common and aggregated manner Functional capabilities EHR Communication primarily receives EHR-related requests from the Decision Support 2010 PONTE Page 48 of 68

49 sub-system and properly forwards them to the EHR-systems of the hospitals which will participate in the clinical trial being designed through PONTE platform. In this version of the PONTE Architecture, the EHR-related requests include: Estimation of patient population available for recruitment while setting the inclusion/exclusion criteria List of patients who are eligible to participate in the clinical trial, i.e., who satisfy the CTP inclusion/exclusion criteria Non-functional capabilities EHR structure transparency The EHRs at the hospitals have a different structure and representation of data, thus the EHR Communication needs to present the collected results from the different EHR-systems in a unified manner both at structural and at semantic (coding schemas used) manner. Scalability The EHR Communication component needs to be able to enable communication with an increasing number of hospitals with their EHRs having different coding schemas and structures, which is achieved through the combination of a web service-enabled communication and the use of semantic mapping services from the SRL Architectural description Component architecture The core sub-component of the EHR Communication component is the EHR Aggregator, which deals with receiving any EHR-related requests, preparing the requests towards the hospital EHR systems based on the latter s specific connection details and adopted coding systems as well as aggregating the returned results and sending them to the Decision Support component. In order for the EHR Aggregator to communicate with the EHR-systems at the hospitals, it contacts with the SRL (more specifically the latest Clinical Trial Protocol instance in the Clinical Trial Protocol Repository) through the CTP Parameters Interface in order to get the list of the hospitals the Principal Investigator has set as cooperating ones with the current Clinical Trial. For each one of these hospitals, the EHR Communication contacts the local Hospital database through the Hospital Parameters Interface in order to retrieve the information such as the type of connection with the specific hospital EHR and the coding schema used within each EHR concerning several data types such as diseases, drugs, geographical location, etc. The EHR Aggregator contacts the SRL (the latest Clinical Trial Protocol instance in the Clinical Trial Protocol Repository) through the CTP Parameter Interface in order to retrieve the Inclusion and the Exclusion Criteria of the CTP. For those hospitals for which it has received their connection details, the EHR Aggregator checks if they are using a local or a standard coding. In the first case, a dictionary mapping the local coding to the standard coding will have been formulated and set at the hospital, so the EHR Aggregator sends the request to the EHR-system PONTE Page 49 of 68

50 In the second case, the EHR Aggregator selects the annotated Inclusion and Exclusion Criteria for which the coding used in the hospital EHR is different from the PONTE coding, and sends a request to the SRL (and more specifically the Semantic Mapper) in order for the latter to map them into the PONTE coding. The SRL (Semantic Mapper) sends back the Inclusion and Exclusion parameters into the hospital standard coding system and through a WS sends the request to the EHR-system at the hospital. In case the available patient population is requested, then the EHR system of each hospital returns the number of patients satisfying these criteria. The EHR Aggregator gathers the returned information from the hospitals EHR systems, sums it up and sends it back to the Decision Support. In case the requested information is the list of patients eligible to participate in the Clinical Trial, each hospital returns a de-identified list of information on patients satisfying the Inclusion and the Exclusion Criteria of the CTP. The EHR Aggregator then gets the patient list with the EHR information from each hospital and through the Mapping Request Interface sends a request to the SRL (Semantic Mapper) in order to map the hospital coding schemas back to the PONTE coding system. Then, the EHR Aggregator needs to aggregate this information for each hospital and send it to the Decision Support. Figure 20: EHR Communication Hence, the major sub-components of the EHR Communication component include: - EHR Aggregator, which comprises the core EHR Communication sub-component. It focuses on gathering the CTP Parameters (inclusion and exclusion criteria, hospitals 2010 PONTE Page 50 of 68

51 selected in the clinical trial), requesting a mapping from the PONTE coding system to the hospital coding system (and vice versa), forwarding the requests to the EHR systems at the side of the hospitals and aggregating the results from them in order to send them to the Decision Support - CTP Parameters Interface, which is responsible for requesting the Inclusion and the Exclusion Criteria as well as the list of hospitals that the Principal Investigator has selected from the SRL (Ontology Manager) - Mapping Request Interface, which focuses on requesting a mapping between the PONTE coding system to the hospital coding system (and vice versa) and providing it to the EHR Aggregator - Hospital Parameters Interface, which retrieves information on the type of connection required for the EHR Aggregator to communicate with the hospital EHRsystems as well as the adopted coding systems on the hospital side Involved technologies Buffer: the EHR Communication is expected to receive the responses from the EHRsystems in an asynchronous manner. Hence, while it is waiting for all the hospitals to send their respond (either number or list of patients), it should be buffering the received data. Data integration: data integration mechanisms will be applied in order to combine the data received from the different EHR-systems Dependencies and interactions The EHR Communication component interacts with the following components of the PONTE architecture: The Semantic Representation Layer (SRL) and more specifically the Semantic Mapper which is responsible for translating between the coding systems used within the hospital communicated with and the PONTE platform and the Clinical Trial Protocol Repository for retrieving the requested parameters from the latest Clinical Trial Protocol instance The Decision Support (DS) component provides the list of inclusion/exclusion criteria based on which the EHR data at the hospitals will be queried for retrieving either the number of patient population available at the hospital records in order to get an indication of the available population or the list of patients which could serve as potential candidates for participating in the specified clinical trial. The WS of the Hospital EHR systems which responds to requests for the number of patients satisfying the current inclusion/exclusion criteria and to requests for providing the list of patients that satisfy the CTP inclusion/criteria for recruitment within the clinical trial Evaluation scenario Since the EHR Communication may receive two different EHR-related requests, this 2010 PONTE Page 51 of 68

52 component can be evaluated through two different cases. The first one deals with a request on providing an estimation of the patient population available for recruitment based on the current inclusion/exclusion criteria and takes place during the CTP design process. Thus, the investigator has set a new inclusion (or exclusion) criterion and requests for an estimation of the available patient population satisfying the current set of criteria in the CTP. The EHR Communication will thus contact the EHR-systems connected to the PONTE platform and will request for the number of patients in each one of them that satisfies these criteria. Each hospital should respond with such a number. The EHR Communication will aggregate these numbers and sum them up. In the second case, the request will regard providing the list of patients who are eligible to participate in the clinical trial. Thus, the EHR Communication will retrieve the inclusion and the exclusion criteria of the clinical trial which (among others) in this case are: patients with ischaemic heart failure and obesity and diabetes patients with heart failure alone female with hypothyroidism male with hypothyroidism, patients with mild heart failure (NYHA I-II) patients with severe heart failure (NYHA III-IV) Exclusion criteria: previous myocardial infarction, previous evidence of compromised left ventricular function (Ejection Fraction< 40%), hemodynamic instability, cardiogenic shock, decompensated heart failure (NYHA IV class) at admission, pregnant or breast-feeding women, The EHR Communication should retrieve the list of patients satisfying these criteria from the hospital EHR systems. 5.5 PONTE Ontology & CTP Repository Overview Objectives The aim of this dual component is to organise the existing knowledge about drugs, diseases, etc. and to model and store the Clinical Trial Protocol instances. The CTP Repository is in charge of the latter and integrated in the PONTE Ontology. As a result, both are described in the same component section. PONTE Ontology PONTE integrates e-health data sources that have various origins, data sources. It also has its own Clinical Trial Protocol model. The upper layer encompasses all the PONTE domains. The middle level is modular and linked to the upper layer concepts PONTE Page 52 of 68

53 The modules are also linked with the main links involved in the CTP. The lower level integrates existing ontologies. These ontologies are linked with the middle layer modules. Relevant links between modules, such as clinical trials and patient medical data are created according to the Specification Language developed during the project. Clinical Trial Protocol Repository The users can store and retrieve the CTP instances they designed or are designing. These instances of the CTP are a series of parameters filled by the users in the PONTE Authoring tool. The CTP repository is part of the PONTE Ontology Functional capabilities The PONTE Ontology and the CTP repository are modelling components, and the functional capabilities are: Integrating health related models, coding, protocols and data sources. The platform integrates a new relevant source or element to the existing PONTE Ontology using ontology editing tools. Interlinking health related models, coding, protocols and data sources. The platform uses the Clinical Trial oriented Specification Language for interlinking heterogeneous relevant sources, using ontology editing tools Non-functional capabilities Semantic Interoperability The PONTE Ontology ensures that the messages, concepts and data exchanged between the different components of the PONTE Architecture are understandable from both human and machine providing semantic interoperability. Data Integration The PONTE Ontology facilitates the integration of different data sources to the PONTE platform by hiding the semantic variations of the different data sources. Maintenance/Versioning Any change in the existing ontologies (except from the PONTE Ontology) should not affect the other components. Coverage The PONTE Ontology covers all the concepts and relationships required to design CTPs and collect information from the selected data sources. The coverage will broaden during the project. Quality The PONTE Ontology integrates existing ontologies, data sources and protocols when they are found to be relevant for the project and validated by professional use. The quality of the ontology ensures that there is no logical inconsistency and limited redundancy PONTE Page 53 of 68

54 Evolvability The structure of the PONTE Ontology is proposed to ensure easier evolution of the ontologies. The top layer is kept thin i.e. a small number of concepts - and the middle layer modular. The expressive power of the logical structure of the SRL is kept as much as possible within the reasoning capabilities of the state of the art reasoners. The upper ontology concepts can be directly used by other components of the PONTE Architecture, hiding the complexity of the existing ontologies used in PONTE Architectural description Component architecture PONTE Ontology This ontology is the pivot of the platform. It covers all the semantic description aspects of the project. It is queried to get descriptions of the domain, verify the consistency of a new element with the platform, helps semantic interoperability between different data sources, and so on. It has several sub-layers (see Figure 21) that go from the most generic, high level concepts, to the most specific, application related ones: - Top layer is a generic description of the clinical trial design domain. It has to cover only the main concepts, and to limit the number of sub-concepts to the minimum. Main concepts are: patient, disease, treatment, symptoms, disease mechanism, clinical trial, drug, etc. It has to be small and stable. - Middle layer describes the generic concepts. The main idea is to identify as much as possible autonomous modules in order to facilitate their evolution. Also, it must avoid any dependency with specific implementations. - Bottom layer is the application level. It connects the higher levels to existing data models developed for applications such as the Clinical Trial Protocol model implemented in PONTE, openehr, KMEHR, Epoch, etc. Figure 21: PONTE Ontology and CTP Repository The different imported ontologies are semantically linked when they deal with the same 2010 PONTE Page 54 of 68

55 concept according to different point of views, origins, modelling frameworks. As a result, a series of assumptions are semi-automatically made on the levels and concepts of the PONTE Ontology the imported ontologies concepts have to be linked. For example, when an imported ontology provides a concept for Patient or Clinical Trial, the task to be done is to choose in the PONTE Ontology where to state that these concepts are integrated. CTP Repository This ontology is semantically linked with the PONTE Ontology and provides the formal context for the CTP design task, including the CTP model and the dependencies between the various CTP sections and parameters, as well as storage for the instances created by the end users, i.e. the CTP parameters filled in through the PAT during the design phase Involved technologies The 3-layer PONTE Ontology and the CTP Repository are developed based on OWL (Web Ontology Language) and RDF (Resource Description Framework). These technologies are used to integrate the models, links between the models and the instances imported or created within PONTE Dependencies and interactions The CTP Repository is integrated into the PONTE Ontology. As they are static semantic descriptions they are not really interacting with other components. The PONTE Ontology and the CTP Repository depend on the Ontology Management component that provides all the storage/retrieval mechanisms needed. The Decision Support depends on the PONTE Ontology and the CTP Repository to load the current CTP parameters as required in each case, and as the underlying heuristic to check CTP parameter dependencies and evaluate the queries results, if needed. The Ontology-based Search Engine depends on the PONTE Ontology to ensure semantic interoperability, filter and annotate the search results as well as query relevant linked data sources. The Semantic Mapper component depends on the PONTE Ontology to provide mapping between different standard coding schemas and thus ensure semantic interoperability of PONTE and the hospital EHRs. The PONTE Authoring Tool communicates directly with the PONTE Ontology, and in specific the CTP Repository, in order to retrieve the CTP structure and store / load the CTP parameters Evaluation scenario The evaluation on the PONTE Ontology and the CTP Repository is performed following the PONTE thyroid hormone therapy use case: Coverage is validated if the PONTE ontology is able to model the CTP according to 2010 PONTE Page 55 of 68

56 the requirements document and is able to integrate the data sources, ontologies and protocols found relevant for the project. The interaction with the PONTE Authoring Tool is validated if the CTP can be stored and retrieved from the CTP Repository, and the different views of the CTP presented according to the information stored in the CTP Repository. The interaction with the Ontology-based Search Engine is validated if the ontologies elements (concepts, relations, instances) searched for are retrieved from the PONTE Ontology. Semantic interoperability is validated if the Semantic Mapper successfully uses the PONTE Ontology to provide semantic interoperability to the platform. 5.6 Ontology Management Overview Objectives The PONTE platform provides both semantic querying and direct download of data models as well as data. The Ontology Management component performs storage/retrieval of Clinical Trial Protocol instances. It also provides direct download access to the PONTE Ontology and to predefined modules of the PONTE Ontology. Finally, it is able to perform semantic querying on it Functional capabilities File Storage and Direct Download Some of the techniques involved in the project, such as OWL (Web Ontology Language), include import mechanisms for ontologies that are based on direct download over http of ontologies as static files. Semantic Storage The advent of an increasing volume of semantic data production led to the creation of specialised databases, often called triplestores. The Ontology Management component uses it to store the PONTE Ontology. Semantic Querying The project requires the retrieval of specific chunks of data that correspond to a series of semantic constraints e.g., all the instances of a given concept. This is possible through a SPARQL endpoint that is connected to the PONTE Semantic Storage functionality Non-functional capabilities Availability The PONTE platform is data-model centric. As a result, any failure to access the PONTE Ontology or the CTP Repository ends with total unavailability of the platform. The Ontology Management component should be available when needed and 2010 PONTE Page 56 of 68

57 downtime should be limited. Response time Semantic queries can be a heavy task and reduce the usability of the PONTE platform. If response time issues are detected during the PONTE platform implementation, solutions such as distributing the load could be adopted Architectural description Component architecture Figure 22: PONTE Ontology Management Involved technologies Web server A legacy most probably Apache httpd web server is used in the project to provide http download access to ontologies and other data. SPARQL endpoint SPARQL endpoints are the semantic frontend of semantic storage systems. The 2010 PONTE Page 57 of 68

58 solution will be chosen according to the expressive power required by the models and data used in PONTE. Triplestore Triplestores are databases dedicated to semantic data, which is stored in the triplestore natively as RDF or exposed via a middleware Dependencies and interactions The PONTE Ontology is stored in the Ontology Management component and is queried using the SPARQL endpoint. Modules of the PONTE Ontology can be downloaded directly via the web server. The CTP Ontology is stored in the Ontology Management component and is queried using the SPARQL endpoint. The Semantic Mapper imports modules of the PONTE Ontology via the interfaces provided by the Ontology Management to perform mappings between several coding schemes and the inner PONTE coding. The Ontology-based Search Engine queries the PONTE Ontology through the SPARQL endpoint. The Decision Support queries the PONTE Ontology and imports relevant modules of the PONTE Ontology through the SPARQL endpoint. The PONTE Authoring Tool stores and retrieves from the CTP Repository through the SPARQL endpoint the Clinical Trial Protocols instances as well as information to help fill the CTP protocol forms and present different views of the protocol to the end user Evaluation Scenario Evaluation of the Ontology Management component is performed by ensuring that file and semantic storage is efficient, that each communication interaction with the other components is feasible, and by reporting the response time. The adequacy of the SPARQL endpoint chosen is evaluated by verifying also that it provides the expressive power required to improve Clinical Trials efficacy. 5.7 Semantic Mapper Overview Objectives Concepts (drugs, diseases, etc.) are represented in different coding systems in the EHR databases of various hospitals. For example, the same disease can be represented with use of an ICD-9, ICD-10 code or SNOMED-CT identifier. The scope of the Semantic Mapper component is to map each code to the unique concept used for the representation of that concept within the PONTE platform. It is thus responsible for the translation of an identifier from/to the standard coding systems used in the various 2010 PONTE Page 58 of 68

59 hospital databases so that semantic interoperability can be achieved. For example, the Semantic Mapper component is able to provide the corresponding ICD-9 code(s) of an ICD- 10 disease code that is used as input. Some systems provide encodings in various languages. The Semantic Mapper handles it using a concept-oriented multilingual terminology Functional capabilities The Semantic Mapper has a series of functional capabilities: Mapping EHR codes to PONTE concepts In order to perform mappings between different coding systems, the Semantic Mapper maps a given coding to the PONTE concepts. Mapping different coding systems Receiving data and codes in a given language from an Information System as well as the targeted Information System, the Semantic Mapper identifies the corresponding code and - when needed - modifies the data to deliver it in coherence with the targeted Information System. Receiving and Sending data The Semantic Mapper provides an interface to communicate with the EHR Communication component Non-functional capabilities The Semantic Mapper has a series of non-functional capabilities: Coverage of the different EHR systems The project has access to several partners hospitals EHR systems. Coverage of these different systems and their various standardised coding schemes is necessary to be able to follow the PONTE Use Cases, recruit patients, and avoid unfeasible Clinical Trial Protocols. Reliability PONTE focuses on improving efficacy of the Clinical Trials, based on deep analysis of the data already collected during previous Clinical Trials, the data provided by the partners EHR systems, the structured data provided by other stakeholders. As a result, the mappings provided by the Semantic Mapper have to be accurate and reliable Architectural description Component architecture In order to implement the functional capabilities described the Semantic Mapper is composed of two main components: the EHR / PONTE Mapper and the Concept-oriented Multilingual Terminology. They interact with each other and with the Ontology Management and the EHR Communication components as described in the following schema PONTE Page 59 of 68

60 Involved technologies Figure 23: Semantic Mapper Component Architecture The EHR / PONTE Mapper is implemented in JAVA and communicates with the PONTE Ontology using both Direct Download and Semantic Querying provided by the Ontology Management component. It also provides Web Services in order to reply to the queries coming from the EHR Communication module. The Concept-oriented Multilingual Terminology is implemented in JAVA and XML Dependencies and interactions The Semantic Mapper is a subcomponent of the Semantic Representation Layer and interacts directly with the following components of the PONTE architecture: The PONTE Ontology that contains formally described knowledge with information about various concepts (drugs, diseases, etc.). The Semantic Mapper component communicates with it via the Ontology Management component in order to retrieve the concept identifiers and provide the mapping functionality. The EHR Communication component interacts with the Semantic Mapper whenever it needs to translate an outgoing or incoming EHR term and modify accordingly the data transmitted Evaluation scenario The evaluation of the Semantic Mapper is performed following the PONTE thyroid hormone therapy use case, and accepted when mapping from the PONTE partners EHR systems coding to the PONTE Ontology and the reverse mapping are implemented successfully. The multilingual cases are taken into account PONTE Page 60 of 68