A Model-Driven Approach to Interoperabilityand Integration in Systems of Systems

Gareth TysonAdel Taweel

Steffen ZschalerTjeerd Van Staa

Brendan Delaney

King's College LondonGeneral Practice Research Database

Overview

Focus on Systems of Systems (SoS)– Interoperability Issues

• Integrating services and data Present a case-study: ePCRN-IDEA

– Real-time recruitment system for clinical trials– Model-driven development

Discuss research challenges and issues Present conceptual model-driven architecture

Background

Systems of Systems (SoS)

“A collection of systems both technical and socio-technical which pool their abilities to present a more complex system, whilst retaining their individual autonomy.” [Lock'10]

Interoperability

Technical Interoperability This refers to the compatibility of the underlying

technologies used to perform interactions (e.g. protocols).

Semantic Interoperability This refers to the ability of each party to understand

and interpret the data of others (e.g. data formats). – Process Interoperability This refers to the compatibility of the different

processes undertaken by each party (e.g. Task A should be performed after Task B).

Case-Study: ePCRN-IDEA

Overview of ePCRN-IDEA

Aim Intends to improve patient recruitment

Approach Enables real-time identification of eligible patients Presents practitioners (e.g. GPs) with pop-ups during

consultations Recruitment can be performed instantly via the web

Technology Requires a number of systems to cooperate Share data, services...

Use of models– Data within this system is all formally modelled

Clinical Trials

What is a clinical trial? “Set of procedures in medical research conducted to

allow safety and efficacy data to be collected for health interventions”

Recruitment Process Patient databases Newspaper and radio advertisements Posters Personal recruitment

Problems Slow Costly

Systems in ePCRN-IDEA

Vision Electric Healthcare Record System (EHR) Database used to store health records Managed by company, InPS

General Practice Research Database (GPRD) Data repository for health records Managed by governmental body

Local Eligible Patient Identification Service (LEPIS)

Software agent co-located with Vision Managed by KCL

Systems in ePCRN-IDEA

Central Control Service (CCS) Stores and manages trials centrally Managed by KCL

Random Clinical Trial Website Web interface used to register interested patients Managed by private company

Systems in ePCRN-IDEA

Models within ePCRN-IDEA

All systems must exchange data– E.g. Trial information must be passed from the

CCS to LEPIS instances All data adheres to shared data models

– These are distributed to all systems• Via email as XML schemas

– Generally used to generate code Allows each party to interpret data correctly

Models within ePCRN-IDEA

Trial Description– Description of the trial

Eligibility Criteria– Computable criteria for patient eligibility

Recruitment Model– Information regarding the recruitment process

Consultation Model– Information about patient consultations

Example: Eligibility Criteria

Issues and Research Challenges

Issues and Research Challenges

Data Integration and Heterogeneous Sources– Necessary to bridge multiple data formats– Often not possible to convert data stored in

different systems into single standard• Difficult to optimise underlying storage• Difficult to place in shared repository

– Difficult to extend system to include new systems• Due to design-time model definition

Issues and Research Challenges

Sub-System Process Changes– Changes within one system can affect other

systems– Interactions might need to be modified

Issues and Research Challenges

Model Evolution– Changes to models can be required after

deployment– Performing translations between different versions

of the model– Need to version control models– Need to distribute models to appropriate parties

Issues and Research Challenges

System-wide Consistency– Possible for sub-systems to hold inconsistent

views of the system as whole– Especially difficult for handling semantic

inconsistencies

A Conceptual Architecture

Requirements

All interactions must be formally captured and understandable by all parties– Not just at the data-layer

Models should also exist during runtime with the ability to evolve and change

Secure infrastructure must be available to handle these processes

Systems using different model versions must remain compatible

A Dynamic Model-Driven Framework

Service Repository– Each system must register its offered services as

well as the data models it consumes and produces

Model Repository– All models must be centrally registered and

accessible– This can be separated into local and central

repositories Terminology Service

– Different terminologies must be mappable

A Dynamic Model-Driven Framework

A Dynamic Model-Driven Framework

All systems register the service and data models they support– Inc. versions

During runtime each system then retrieves its required models– Either from LMR or CMR

Models can then be reified into code If incompatible models are interconnected

– Mappings must be acquired

Conclusion

Conclusion

Investigated the use of model-driven engineering in designing Systems of Systems (SoS)

A model-driven case-study has been examined Key outcomes

– Complexity and cost of data mappings– Problems during process change– Difficulties of model evolution– Risks of system-wide

A conceptual architecture has been outlined– Future work is realising this