Health-e-Child Konstantin Skaburskas Based on presentations made by HeC partners.

Health-e-Child

Konstantin SkaburskasBased on presentations made by HeC partners

2 Health-e-Child 07. November 2006

• Establish Horizontal and Vertical integration of data, information and knowledge • Develop a grid-based biomedical information platform, supported by sophisticated and

robust search, optimisation, and matching techniques for heterogeneous information, • Build enabling tools and services that improve the quality of care and reduce its cost by

increasing efficiency• Integrated disease models exploiting all available information levels

• Database-guided decision support systems

• Large-scale, cross-modality information fusion and data mining for knowledge discovery

• A Knowledge Repository?

Project Objectives


Instrument: Integrated Project (IP) of the Framework Program FP6

Project Identifier: IST-2004-027749

Coordinator: Siemens AG, Dr. Jörg Freund Partner: 14 European (companies, hospitals,

institutions) Timetable: 01-Jan-06 to 31-Dec-09 (4 years) Total cost: 16.7 Mio. € EC funding: 12.2 Mio. €

Web page: http://www.Health-e-Child.org

Project General Info


GOSH

NECKER

UWE

CERN

IGG

SIEMENS

ASPER

UOA

INRIA

Project Map

LYNKEUS

UCL

EGFFGG

MAAT


Clinical Context Diseases

• Heart diseases (Right Ventricle Overload, Cardiomyopathy), • Inflammatory diseases (Juvenile Idiopathic Arthritis), and • Brain tumours (Gliomas)

Clinical Institutions• I.R.C.C.S. Giannina Gaslini (IGG), Genoa, Italy • University College London, Great Ormond Street Children’s Hospital

(GOSH), London, UK • Assistance Publique Hopitaux de Paris – NECKER, Paris, France

Clinical Departments• Cardiology• Rheumatology• (Neuro-)Oncology• Radiology• Lab (Genetics, Proteomics, Lab)• Administration


Data Integration Challenge (1)• 3 Hospital Nodes

• Integration of data stored in Hospital’s IS + fresh new data to be acquired

• Acquisition of large samples of Imaging data • 3 diseases X 300 cases X 2 modalities X 300 images

– i.e. at most 540000 images ~ 270 GB

• A Distributed Platform for sharing, manipulating and inferring data

• Decision Support System• Disease Modelling• Knowledge Discovery / Data Mining• Image Processing

• Automatic segmentation of right ventricle – to determine volume, ejection fractions etc for

cardiac MR and ultrasound images • Brain tumour segmentation/registration to determine

volume, location etc• Volume of synovial fluid in wrist MR scans

• Grid technology as the enabling infrastructureHeC Components


• A1: Project Management

• WP1 – Project management

• A2: User Requirements Specifications

• WP2 – User requirements specifications

• A3: Ethical, Legal and Social Issues

• WP3 – Legal, ethical, and regulatory issues

• WP4 – Privacy and security

• A4: Platform Development, Vertical Data Integration and Knowledge Representation

• WP5 – Grid platform (Maat, CERN, UWE, Siemens)

• WP6 – Medical vertical knowledge representation

• WP7 – Data management layer and data integration mechanisms

• WP8 – Medical query processing• A5: Data Collection, Annotation and Knowledge Gathering

• WP9 – Data collection

• WP10 – Ground truth (annotated data) and clinical knowledge gathering

• A6: Disease Modelling, Decision Support and Knowledge Discovery based on Integrated Biomedical Information

• WP11 – Integrated disease modelling

• WP12 – Decision support systems

• WP13 – Biomedical knowledge discovery

• A7: System Integration

• WP14 – Deployment of the data management system and Grid gateway• A8: Dissemination Policy and Broader Impact

• WP15 – Training

• WP16 – Dissemination

Activities and Work Packages


WP5 Objectives• To provide a Grid-aware infrastructure on which

the Health-e-Child applications can operate

• To develop appropriate APIs for applications to invoke Grid services

• To provide education to application developers on the use and operation of the Grid infrastructure

• To ensure that updates and releases of the Grid platform are available as the infrastructure evolves


Challenges

• Security:• Strong authentication

• VOMS based authorization to all Grid resources

• Fine-grained data sharing/access. Granularity:• File

• DB views, tables, table rows


Early Faced IssuesMainly Non-Functional since project has just started

• Selecting grid m/w services wrt project requirements• Lots of services/functionalities available• Different implementations with different levels of maturity

• Clustering grid m/w services• To reduce the h/w requirements & maintenance (1 server / Hospital)• To facilitate deployment (3 clinical sites + at least 5 institutional sites)

• Decentralisation of grid m/w services• Sites need to be as much as possible autonomous

• “Griddification” of Applications• Some of the HeC applications might be “gridified”

• Griddification has to be balanced against runtime and development complexity criteria


Current Investigations• Selecting grid m/w services wrt project requirements

=> Services selection based on URS + Grid Questionnaire

• Clustering grid m/w services=> “Xenification” of OSs + clustering services wrt functionality

• Decentralisation of Grid Services=> Dependent on gLite developments, but already some possibilities with Master/Slave

configurations

• “Griddification” of Applications=> Introduced a classification of applications. Grid Questionnaire will certainly help in

making decisions

• Grid Access=> Abstracting grid access through dedicated service


Remaining Challenges

• Data Integration in Hospitals (post phase 2)• What mechanisms to use? What will be the limitations (in particular with proprietary

systems?

• Patient Data Distribution & Sharing• What technology/implementation?

• Patient Image Files Sharing• Enabling the sharing of large files over the internet

• MRI @ GOSH = 500MB/patient• CT @ NECKER = 3.5GB/patient …raises bandwidth problems

• Griddification of Applications• Appears relevant for computation heavy algorithms or batch processing

• However many clinical algorithms have short runtime (e.g. image processing, since clinicians need almost instantaneous results)


Non-functional Requirements• Hospital Sites should be autonomousautonomous

• Sites should not depend on any central services• Hardware requirements remain too high for Hospitals

• Getting access to the grid through one boxone box would be ideal• e.g. 1 Server per Hospital1 Server per Hospital

• Fine-grained security mechanism for accessing data (at the record level?)

Functional Requirements• PseudonymisationPseudonymisation as a native middleware service?• Native StreamingStreaming facilities for sharing large DICOM files• [ Native patient-centricpatient-centric data model(s)

• (flexibility) Optionally data model could be selected from existing standards (e.g. HL7…) or even created from scratch

• (interoperability) Optionally a native commodity for exporting/exposing data through different data models would be nice (model-driven)

• (interoperability) Optionally a data model (schema) discovery mechanism could help• Native connectors to external backends for batch data integration ]

1. Are HealthGridsHealthGrids likely to become the enabling infrastructure for Distributed PACSDistributed PACS?2. Is the GridGrid likely to become the enabling infrastructure for Knowledge RepositoriesKnowledge Repositories?

Middleware Requirements


HeC Platform

HeC Server

GOSHHeC Server

Clinicians Laptops/Desktops

WorkstationIGG

NECKER

• One server per Hospital• Single entry point to HeC Platform

• One workstation per Department• For complex tasks a dedicated user dedicated user

interfaceinterface is used

• Generic computers on Intranet• Most functionalities accessible from

generic web browsersweb browsers

Clinician’sHeC Identity

Approach (1)


HeC Platform Centralized


HeC Platform DeCentralized


Approach (2)• An intermediary access layer: the HeC Gateway

• To decouple client applications from the complexity of the grid and other computing resources

• Towards a platform independent implementation• Domain Specific Functionality exposed in the HeC Gateway• Grid mainly used as a Distributed & Federated PACS

• Different modalities of images to be anonymised and shared • Clinical Reports• Misc. Files


Gateway Architecture


Platform Use Cases

Local & GlobalRequires high responsiveness View Case

Global--Maintain Grid

Global--Knowledge Mining

Local & GlobalRequires high responsivenessFind Similarity

Local & GlobalRequires high responsivenessQuery

Local--Data Acquisition

Local & Global--Data Annotation

Global--Manage Sharing

Global--Maintain VO

Global--Maintain Tools

Local & Global--Maintain Information Schema

Local--Maintain Patient Database

3. Maintain Platform

Local & GlobalRequires high responsivenessUse Disease Models

Local & GlobalRequires high responsivenessUse Decision Support System

2. Retrieve & Exploit Information

1. Collect Information

ScopeComment(high-level) Use Case


1st Technical Accomplishments

• Establishment of a Common Development Environment• Indispensible to synchronise partners and leverage synergy

• Creation of the Health-e-Child Virtual Organisation (VO)• Establishment of a Certificate Authority (55 certs delivered so far)• HeC VO (10 users) Structure in place, being tested

• 1st gLite Test-bed deployed in May 2006 on HeC dedicated servers• ~20 computers involved• Being refined according to project requirements

• HeC gateway (prototype version)• Authentication Client Application & Grid Service (VOMS enabled)• HeC Portal & Factory (exposing domain specific functionality)


• What has been achieved, practically speaking?

• T4.2 Health-e-Child Certificate Authority• Redundant & Secured OpenCA Repositories

• 2 repositories synchronized by a USB stick• 1 repository exposing non-sensitive data• 1 repository installed in a secure computer

• 56 certificates delivered so far• Being used by all the services in the infrastructure from gLite to

gateway to common development environment

• T4.3 Security Prototype• Gateway service container and security policy in place• Authentication Client & Service

– Improved GSI & PKI model

• Logging Web-Portal– Featuring all facilities to browse gateway logs

» Can process statistics on gateway usage/reliability» Users Operations can be traced efficiently & real-time» Based on G

• LogAppender for Java– Asynchronous logger, therefore almost no computation cost– Log appended in a G DBMS

• VO Configured and under Test• Infrastructure Protected by Firewalls

– respecting the security rules defined for gateways

WP4 – Security & Privacy


WP5 – Grid Platform

• What has been achieved?• T5.1 EGEE gLite Evaluation (M1-6 / 4MM)

• OK. Done via gLite Test-bed deployment at CERN & MAAT– Report should be appended to D5.1

• T5.2 Education / Training (M1-9 / 4MM)• OK. Done, undertaken several gLite tutorials until recently

• WP5 Team might be interested in having further technical tutorials

• T5.3 API Development (M6-12 / 10MM)• UP. API Information Collection completed

– Functionality wrapping is under process

• T5.4 gLite Test-bed (M9-15 / 14MM)• OK. First Test-bed, so-called « Roma »… demonstrated end May 2006

• 1 Central Site• 3 Local Sites (mimicking hospitals)

• T5.5 Prototype Testing (M15-18 / 3MM)• NS. However:

• Trying out some test suites for gLite

• Started Feedback to EGEE through CERN

• Milestones and Deliverables• D5.1 Report on delivered Grid prototype (due date: Month18)

• M5.1 Prototype Grid Platform (due date: Month18)

NS: Not Started yet

UP: OnGoing

OK: Done


• What has been achieved, practically speaking?• T5.2 Education / Training

• 2006-02-27 gLite Tutorial @ CERN• 2006-09-26 gLite Tutorial @ CERN• 2006-10-10 gLite Tutorial @ CERN

• T5.3 API Development• Delivered HeC Infrastructure Requirements QuestionnaireHeC Infrastructure Requirements Questionnaire

• Collected all filled-in questionnaires (by 23-Oct. 2006)

• Questionnaires now have to be processed

• API integration scheme has been selected according to last tutorial results• API development has been split

• Already some embryo functionality can be tested through the HeC Shell (bundled in the Authentication Client Application for sysadmins)

• T5.1 & T5.4 gLite Test-bed• Test-bed, so-called « Roma »… demonstrated end May 2006• Test-bed now features:

• 1 Central site @CERN• 3 Hospital-like sites (2@CERN, 1@MAAT)• 1 Development G/W @ CERN

• For a total of 15 VMs~6 Servers15 VMs~6 Servers



Infrastructure Outlook

Node dedicated to “Xenification” tests of gLite services. Temporary site, should disappear later.

OKCERN3 / 1Test SiteLocalCERN

Production Site

Production Site

Production Site

Development Site to train DSS connected to Grid

Mimicking a Hospital site. Could become a public Gateway for external clinicians/hospitals get access

Infrastructure should expand to 20 servers gradually

Mimicking a Hospital site. Temporary site, should disappear later.

Health-e-Child CA

Running core gLite services

Note

NSGOSHLondon

4 / 2Hospital SiteLocalGOSH

NSNECKERParis

4 / 2Hospital SiteLocalNECKER

NSIGGGenova

4 / 2Hospital SiteLocalIGG

OKMAAT Madrid

4 / 1Hospital / Development Site

LocalMAAT

UPMonth?

SIEMENSMunich

4 / 2Development SiteLocalSIEMENS

Computational Site

Hospital / Test Site

VO

VO

Sub-Type

UPMonth12

UWE Bristol

4 / 2LocalUWE

OKCERN2 / 2LocalCERN

OKCERN1 / 1CentralMAAT

OKCERN6 / 1CentralMAAT

StatusLocation# of VM / Servers

TypeOwner


26

Health-e-Child 07, November 2006

WP14 – Connectivity Deployment

NS: Not Started yet

UP: OnGoing

OK: Done

• Milestones and Deliverables• D14.1 Report on Deployed Prototype (due date: Month18)

• What has been achieved?• UP. T14.1 Deployment of the Connection (M5-10 / 8MM)

• To speed up the process, MAAT is planning to: – 1. Order servers for Hospitals – 2. Batch install them– 3. Ship them to Hospitals and– 4. Finalize deployment onsite

• Currently preparing the deployment logistic– MAAT delivered recently Hospitals servers specs proposal– Deployment Team constituted and ready to proceed

• NS. T14.2 Linkage to DSS (M11-18 / 4MM)• NS. T14.3 Browsing of Data through Specified Ontologies (M11-18 / 2MM)

27


• What has been achieved, practically speaking?

• Test-bed used as a learning environment to perfect up-coming deployment• Deployment recently exercised through installation of a “Hospital-like” site

@ MAAT

• Server Pricing for Hospitals• Got proposal from DELL Spain (good prices ~ 1K€ lower than public prices)

• Deployment will be documented. Procedures are being properly described• Deployment Procedure Documentation• Hardware Test Report (1 per server delivered to Hospitals)

– For properly assessing the servers to be deployed in Hospitals• Software Test Report (1 per Hospital Site)

– For properly validating a site installation

• All Reports to be appended to D14.1


28


• What is planned?• Servers preparation phase to last 3 months (once orderedonce ordered)

• Targeted 1st Hospital: IGG (GOSH 2nd & Necker last)• Ideal Objective would be to order h/w before the end of November 2006

(Month11)• Deployment in Hospitals to start at Month12

• “Ideal” Objective is to deploy one Hospital before European Review (Month14)

• Where do you foresee problems, risks and/or delays?• WP14 Description not relevant for T14.2 & T14.3 (deserves amendment)• Deployment already delayed• Hardware deprecation – Servers should be ordered no later than December

2006• Servers integration in Hospitals

• What could be the counter measures to avoid the problems, risks and delays?• Amend WP14 for the DoW2• Order the h/w at Month11/12• Tight interaction with Hospitals’ IT Departments

• might require a pre-deployment visitpre-deployment visit at each Hospital


Health-e-Child Konstantin Skaburskas Based on presentations made by HeC partners.

Documents

data integration challenge

vertical integration

fresh new data

heterogeneous information

diseases x

project objectives

modalities x

integrated project ip