A Model-Driven Approach to Interoperability and Integration in Systems of Systems Gareth Tyson Adel Taweel Steffen Zschaler Tjeerd Van Staa Brendan Delaney King's College London General 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 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

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

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

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