330 likes | 423 Views
Health-e-Child: A Grid Platform for European Paediatrics On behalf of the Health-e-Child Consortium (& with thanks to David Manset Maat-G). Richard McClatchey, UWE-Bristol UK. CHEP07 3 rd September 2007, Victoria, CA. Contents. Project Objectives & Challenges Health-e-Child Gateway
E N D
Health-e-Child: A Grid Platform for European PaediatricsOn behalf of the Health-e-Child Consortium (& with thanks to David Manset Maat-G) Richard McClatchey, UWE-Bristol UK CHEP07 3rd September 2007, Victoria, CA
Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions
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
Real-time alert On-line learning Decision Support Systems Knowledge Discovery Healthy Child Guidance Vertical Data Integration Guidance Enrich Augment Integrated Disease Modeling 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 Time Imaging Lab Data Population Genomics Integrated Medical Database Individual Observation Process Sensors Proteomics Organ Demographics Tissue Physician Notes Cell Life Style Molecule
Introduction A Geographically Distributed Environment ASPER UCL GOSH UWE SIEMENS CERN Clinical Site NECKER IGG R&D Site FGG EGF UOA INRIA MAAT LYNKEUS
Applications Integration Challenge IGG NECKER GOSH Introduction Highlights - Different Networks: LANs, WANs, Internet - Security Constraints: Local & National Regulations - Bandwidth Limitations: LAN/WAN & Internet uplinks …
Contents • Project Objectives & Challenges • Health-e-Child Gateway • The HeC Grid architecture • Data Integration & Ontologies • Futures • Conclusions
HeC System Overview Heart Disease Applications Inflammatory Diseases Applications Brain Tumour Applications Common Client Applications user interface for authentication, viewing, editing, similarity search HeC Gateway HeC specific models and Grid services like query processing, security Grid Infrastructure databases, resource and user management, data security
Data Management & Integration The Health-e-Child Gateway • 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
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
Our Approach One Key To enter the system One Access Point Per Institution Highlights - Simplicity, “all-in-one box” - Modularity & Scalability, “off-the-shelf” components - State-of-the-artApproaches Hospital X User Gateway Workstation
One Access Point EGEE gLite Health-e-Child Platform & Grid Middleware The Health-e-Child Access Point HeC Scheduling Job Managnt Info System Monitoring Computation Unit Hosting Domain 1 Stable & Secure Environment HeC Gateway HeC Gateway HeC DBMS Storage Security & Registration Data Unit 200GB 50GB 1TB Hosting Domain 2 Stable &Secure Environment Virtualization…
Client Applications Functionality Access One Access Point Infrastructure Abstraction The Platform The Health-e-Child Gateway (1) HeC Gateway Computing Resources Inside the box…
One Access Point The Platform The Health-e-Child Gateway (2) Security HeC Gateway GT4 Inside the box…
One Access Point Platform & Grid Middleware The Health-e-Child Gateway (3) HeC Gateway Grid GT4 Inside the box…
One Access Point The Platform The Health-e-Child Gateway (4) Client Connectivity HeC Gateway GT4 Inside the box…
One Access Point The Platform The Health-e-Child Gateway (5) Client Applications HeC Gateway Data Integration Inside the box…
Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions
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
Grid Platform Grid Architecture @ Month18 Virtualization Applied Being deployed 2nd Test Node Deployed
Solution Facts & Conclusion Grid Platform - Test-bed Installed & Tested @ CERN • - Validated the Middleware Architecture (V1.0) to be installed • at the different Sites • - However: Architecture still too centralized (VOMS, LFC…) • - Being addressed in the second planning period CERN
Contents Project Objectives & Challenges Health-e-Child Gateway The HeC Grid architecture Data Integration & Ontologies Futures Conclusions
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 informationfrom 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
Data and knowledge modelling Application specific Applications DSS Query Similarity HeC-universal Integrated Data Modelling Knowledge Representation - ontologies Requirements Data AcquisitionProtocols (WP9) Users Requirements Specifications (WP2) Modelling with Domain Experts (WP6)
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
Contents • Project Objectives & Challenges • Health-e-Child Gateway • The HeC Grid architecture • Data Integration & Ontologies • Futures • Conclusions
Clinical and Application Roadmap Phase I (- 06/06) Phase II (07/06 - 06/07) Phase III (07/07 - 12/08) Phase IV (2009) Study Design and Approval Data acquisition, genetic tests, ground truth annotations Clinical Validation Refinement of Models and Algorithms Dissemination Disease Model Development generic subtype specific patient and treatment specific Knowledge Discovery Methods User Requirements State of the Art Reports Classifiers Based on Genetics Integrated decision support Feature Extraction from Imaging Segmentation/Registration
Future Work – Decentralized Architecture Grid Platform Working out a possible alternatives to decentralize key components of the grid middleware Autonomous Sites
Ontology layer in the data management architecture HeC Ontology Applications (e.g.DSS) GUI External Biomedical ontologies HeC-External Ontologies Mappings Ontological Layer Semantics Rules External public DBs Query Processing Engine Ontology-Data Model Mappings Hospitals’ DBs
Contents • Project Objectives & Challenges • Health-e-Child Gateway • The HeC Grid architecture • Data Integration & Ontologies • Futures • Conclusions
HEP vs. BioMed - Comparison Vs. 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
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.
Conclusions • HeC Gateway designed and implementation progressing through 2007-2008 • 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 ?