Health-e-Child: A Grid Platform for European Paediatrics On behalf of the Health-e-Child Consortium (& with thanks to David Manset Maat-G) CHEP07 3 rd September 2007, Victoria, CA Richard McClatchey, UWE-Bristol UK

Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions

3 Motivation for the Project Clinical demand for integration and exploitation of heterogeneous biomedical information vertical dimension – multiple data sources horizontal dimension – multiple sites Need for generic and scalable platforms (Grid?) integrate traditional and emerging sources – in vivo and in vitro provide decision support ubiquitous access to knowledge repositories in clinical routine connect stakeholders in clinical research Need for complex integrated disease models build holistic views of the human body early disease detection exploiting in vitro information personalized diagnosis, therapy and follow-up

4 Objectives of Health-e-Child Build enabling tools & services that improve the quality of care and reduce cost with Integrated disease models Database-guided decision support systems Cross modality information fusion and data mining for knowledge discovery Establish multi-site, vertical, and longitudinal integration of data, information and knowledge Develop a GRID based platform, supported by robust search, optimisation and matching Healthy Child Decision Support Systems Integrated Disease Modeling Knowledge Discovery Augment Guidance Guidance Enrich Real-time alert On-line learning Observation Process Sensors Imaging Genomics Lab Data Proteomics Demographics Physician Notes Life Style Time Organ Tissue Cell Molecule Population Individual Vertical Data Integration Integrated Medical Database

5 Focus on Paediatric Diseases Three Paediatric Diseases with at least partly unknown cause, classification and/or treatment outcomes Heart diseases (Right Ventricular Overload, Cardiomyopathy) Inflammatory diseases (Juvenile Idiopathic Arthritis) Brain tumours (Gliomas) Many Clinical Departments Cardiology Rheumatology (Neuro-)Oncology Radiology Lab (Genetics, Proteomics) Administration, IT Main Modalities / Data Sources Imaging (MR, US/echocardiography, CT, x-ray) Clinical (Patient information, Lab results etc) Genetics & Proteomics

6 GOSH NECKER UWE CERN IGG SIEMENS ASPER UOA INRIA LYNKEUS UCL EGF FGG MAAT A Geographically Distributed Environment Introduction Clinical Site R&D Site

7 Applications Integration Challenge Introduction IGG NECKER GOSH Highlights Networks - Different Networks: LANs, WANs, Internet Security - Security Constraints: Local & National Regulations Bandwidth - Bandwidth Limitations: LAN/WAN & Internet uplinks … Highlights Networks - Different Networks: LANs, WANs, Internet Security - Security Constraints: Local & National Regulations Bandwidth - Bandwidth Limitations: LAN/WAN & Internet uplinks …

8 Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions

9 HeC System Overview Grid Infrastructure databases, resource and user management, data security HeC Gateway HeC specific models and Grid services like query processing, security Heart Disease Applications Inflammatory Diseases Applications Brain Tumour Applications Common Client Applications user interface for authentication, viewing, editing, similarity search

10 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Services Our building blocks are Services Our Gateway is a SOA Existing blocks are available in the community WSRF Containers: Globus Toolkit4, Tomcat, WSRF::Lite… Data Access Layers: OGSA-DAI, AMGA… File Transfer facilities: gridFTP… Applies to other distributed systems Our approach is to efficiently reuse and combine blocks to satisfy our requirements Building blocks might be enhanced, i.e. HeC Authentication Service Data Management & Integration The Health-e-Child Gateway

11 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Gateway The HeC Gateway An intermediary access layer to decouple client applications from the complexity of the grid Towards a platform independent implementation To add domain specific functionality not available in Grid middleware Status √ SOA architecture and design √ implementation of privacy and security modules

12 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Our Approach Workstation Gateway User Hospital X Highlights Simplicity - Simplicity, “all-in-one box” Modularity & Scalability - Modularity & Scalability, “off-the-shelf” components State-of-the-art - State-of-the-art Approaches Highlights Simplicity - Simplicity, “all-in-one box” Modularity & Scalability - Modularity & Scalability, “off-the-shelf” components State-of-the-art - State-of-the-art Approaches One Access Point Per Institution One Key To enter the system

13 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Platform & Grid Middleware The Health-e-Child Access Point One Access Point Hosting Domain 1 Stable & Secure Environment Hosting Domain 2 Stable & Secure Environment Security & Registration Job Managnt HeC Gateway Storage HeCScheduling Monitoring Info System Computation Unit Data Unit HeCDBMS 200GB50GB1TB Health-e-Child EGEE gLite HeC Gateway Virtualization…

14 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 The Platform The Health-e-Child Gateway (1) Inside the box… Client Applications One Access Point HeC Gateway Computing Resources Functionality Access Infrastructure Abstraction

15 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 The Platform The Health-e-Child Gateway (2 ) Secur ity GT4 Inside the box… One Access Point HeC Gateway

16 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Platform & Grid Middleware The Health-e-Child Gateway (3) Grid GT4 Inside the box… One Access Point HeC Gateway

17 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 The Platform The Health-e-Child Gateway (4) Client Connectivity GT4 Inside the box… One Access Point HeC Gateway

18 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 The Platform The Health-e-Child Gateway (5) Client Applications Inside the box… One Access Point HeC Gateway Data Integration

19 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions

20 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Grid Grid technology (gLite 3.0) as the enabling infrastructure A distributed platform for sharing storage and computing resources HeC Specific Requirements Need support for medical (DICOM) images Need high responsiveness for use in clinical routine Need to guarantee patient data privacy:  access rights management  storage of anonymized patient data only Status √ Testbed installation since Mai 2006 √ HeC Certificate Authority √ HeC Virtual Organisation √ Security Prototype (clients & services) √ Logging Portal & Appender

21 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 EGEE gLite - Grid Middleware to be used in HeC is EGEE gLite (DoW) - gLite provides several modules, 1 module encompassing 1 or * services/software  Selected the minimal set of services for enacting a Test-bed: - Core Services (services accessed by all sites following a centralised architecture) - Top BDii: Berkeley Database Information Index. Grid Information System Database - VOMS: Virtual Organisation Membership Service - PX: Proxy - LFC: File Catalogue - WMSLB: Workload Management System - Site Services (services installed at each site) - Site BDii: Berkeley Database Information Index. Top BDii replica. - gLiteSE/DPM: Storage Element - gLiteCE/Torque: Computing Element - WN: Worker Node - UI: User Interfaces. Grid API & Clients - However… Limited Resources  Virtualisation of OSs & m/w Services clustering - Modular Grid Access Points:  Virtual machines can be spread over the infrastructure Grid Platform Grid Middleware - Adopted Solution

22 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Grid Platform Grid Month18 Virtualization Applied 2 nd Test Node Deployed Being deployed

23 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Solution Facts & Conclusion Grid Platform Installed & Tested - Test-bed Installed & CERN Middleware Architecture - Validated the Middleware Architecture (V1.0) to be installed at the different Sites centralized - However: Architecture still too centralized (VOMS, LFC…) - Being addressed in the second planning period Installed & Tested - Test-bed Installed & CERN Middleware Architecture - Validated the Middleware Architecture (V1.0) to be installed at the different Sites centralized - However: Architecture still too centralized (VOMS, LFC…) - Being addressed in the second planning period CERN

24 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Grid Platform Current HeC gLite Interface covers: Proxies Management, File(s) & Catalog Management, Workload Management, File Transfer Management Proxy File & CatWorkloadFile Transf Grid Info Solution Facts & Conclusion (2) Highest priority was File & Catalog functionality Highlights - Fast prototyping and integration - Fast prototyping and integration of grid functionality autumn Test-bed is ready since autumn 2006 Modular - Modular architecture (virtualization) resource limitations - Satisfies Hospitals’ IT resource limitations Highlights - Fast prototyping and integration - Fast prototyping and integration of grid functionality autumn Test-bed is ready since autumn 2006 Modular - Modular architecture (virtualization) resource limitations - Satisfies Hospitals’ IT resource limitations

25 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Common Client Applications Status √ authentication (certificate-based single sign-on) √ simple browsing and viewing USB key solution authentication basic functionality + applications that do not require specific resources available from any PC supporting USB in the hospital without SW installation autorun from Windows XP Supports basic functionality browsing, viewing, editing patient data safety, security, privacy, anonymisation similarity search

26 Health-e-Child Technical Review Meeting, Paris, 17 January 2007 Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions

27 Vertical Levels Split the domain into vertical levels Data/Information from multiple levels Implicit semantics connecting these levels. Vertical Integration in applications Data models should provide seamless access to all the infor- mation stored in HeC Vertically Integrated Modelling Coherently integrate information from different levels (instances) Provide integrated view of the data to the users (concept-oriented views, etc) Queries against the integrated knowledge Topics Vertical Integration along the longitudinal axis in pediatrics Semantics of relevance for presenting clinical data Fragment extraction, alignment and integration from biomedical knowledge sources Vertical Integration PopulationIndividualOrganTissueCellMolecule

28 Data and knowledge modelling Requirements Data Acquisition Protocols (WP9) Users Requirements Specifications (WP2) Modelling with Domain Experts (WP6) Integrated Data Modelling Applications DSS Similarity Knowledge Representation - ontologies Query HeC-universal Application specific

29 Data and knowledge representation approaches in the medical domain relational schemas, e.g. traditional DB + well-understood and robust method for representing data + performant persistent data management implementations - no intuitive modeling of hierarchically structured objects, e.g. biological entities semi-structured data, e.g. XML + more natural modeling of biological entities (e.g. by using the features like nesting) - it is still difficult to model complex (non-tree) relationships ontologies + can represent declarative and procedural knowledge and arbitrarily complex relations - can be cumbersome for simple schemata - non-performant storage + provides reasoning over distributed knowledge resources + best suited for medical data

30 Knowledge Representation: Ontologies and Data Models Ontologies generic and task-independent (universal) represent knowledge that formally specifies agreed logical theories for an application domain provide the basis for reusability, reliability, shareability, portability, and interoperabiltity can be easily extended and combined expressive domain rule languages lead to a more correct and precise conceptualisation of a domain (integrated reasoning support) Data Models task-specific schemata, implementation oriented represent structure and integrity of the data elements conceptualisation and vocabulary of the data model are not to be shared extension of the data model is limited less expressiveness

31 Ontologies in Health-e-Child Reuse existing medical knowledge to structure our feature space Working with established knowledge Linkage to “live” knowledge base(s) Saves effort on validating the models with domain experts Non-domain specific conceptualization (upper level ontologies): reusing these, we establish shareable/shared knowledge Ontological modelling of paediatric medicine Integration of information – resolving semantic heterogeneity Different countries, hospitals, protocols Research potential OWL DL representation of paediatrics medical knowledge, identification of knowledge patterns Decision-support systems Similarity metrics and query enhancement. Alignment of ontologies that overlap over the Health-e-Child domain

32 Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions

33 Clinical and Application Roadmap Phase I (- 06/06) Phase II (07/ /07) Phase III (07/ /08) Study Design and Approval Phase IV (2009) Clinical Validation Refinement of Models and Algorithms Dissemination Data acquisition, genetic tests, ground truth annotations User Requirements State of the Art Reports Knowledge Discovery Methods Segmentation/Registration Feature Extraction from Imaging Disease Model Development generic  subtype specific  patient and treatment specific Integrated decision support Classifiers Based on Genetics

34 Future Work – Decentralized Architecture Grid Platform Working out a possible alternatives to decentralize key components of the grid middleware  Autonomous Sites

35 Ontology layer in the data management architecture HeC Ontology Ontological Layer Ontology-Data Model Mappings Query Processing Engine GUI Semantics Rules External public DBs External Biomedical ontologies Hospitals’ DBs Applications (e.g.DSS) HeC-External Ontologies Mappings

36 Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions

37 HEP vs. BioMed - Comparison Number & location of sites, Job vs. Interactive processing, Data distribution & governance, Nature of applications, skills sets of users, Data Types & lifetimes, Data Replication Middleware-centric vs. Operating system-centric Vs.

38 Obstacles for Biomed Users Grid Middleware is difficult to set up, configure, maintain and use. New skills needed. Support for non-scientific applications is limited. Hierarchical environments favoured, largely client-server, inflexible in nature - no support for P2P. Grid software has concentrated on job-oriented (batch-like) computing rather than interactive computing. Cannot share the cpu (CE) or storage capabilities (SE) with the Grid : all or nothing for the resourcing.  We need out-of-the-box Grid functionality for biomedical end-users.

39 Conclusions HeC Gateway designed and implementation progressing through Grid platform decided – EGEE gLite BUT Grid is not yet mature in non-HEP settings Biomedical communities are very different to HEP communities. So no one-size-fits-all Future must be towards user-participation in Grids – what about a Grid OS ?