A Model-Driven Approach to Interoperability and Integration in Systems of Systems

1. Gareth Tyson Adel Taweel Steffen Zschaler Tjeerd Van Staa Brendan Delaney King's College London General Practice Research Database A Model-Driven Approach to Interoperabilityand Integration in Systems of Systems

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

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

25. Conclusion

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