1. 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

2. 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

3. Background

4. 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]

5. 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).

6. Case-Study: ePCRN-IDEA

7. 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

8. 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

9. 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

10. 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

11. Systems in ePCRN-IDEA

12. 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

13. 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

14. Example: Eligibility Criteria

15. Issues and Research Challenges

16. 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

17. Issues and Research Challenges Sub-System Process Changes –Changes within one system can affect other systems –Interactions might need to be modified

18. 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

19. 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

20. A Conceptual Architecture

21. 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

22. 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

23. A Dynamic Model-Driven Framework

24. 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

25. Conclusion

26. 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