1. The role of data standards and ontologies in supporting a Learning Health System.
Brendan Delaney
Chair in Medical Informatics and Decision Making
Imperial College London

2. What is a Learning Health System?
ACT
PLAN DO
STUDY
Deming 1950
Friedman 2014

3. What should the LHS achieve?
The LHS is a major socio-technical endeavor that links science with knowledge translation using a digital infrastructure. Includes: Big Data Precision/stratified/personalized medicine Decision support And does this at SCALE, utilizing LEGACY systems and learning for the FUTURE

4. The implications of SCALE for Learning
Every patient, every encounter an opportunity
Outcomes measurement needs to be:
More precise
More accurate
Fewer missing data
Include data direct from patients about their experience
Include economics
Interventions need capturing in detail
Heterogeneity
Co-morbidity

5. The implications of SCALE for Knowledge Translation
Knowledge needs curating
A digital representation of knowledge at its finest level of granularity
Can be combined
Can be versioned
Can be traced (provenance)
Clinical heterogeneity needs to be represented in order to individualize the knowledge
Clinical systems need to support sufficient detail of phenotyping to drive decision support

6. The implications of LEGACY
Aside of the legal, ethical and data protection issues the capacity of many legacy systems with respect to interoperability is limited
Granularity of coding / terminologies
Structural capture of context (eg separate tables for clinical observations, results etc)
Capacity of API – If any
Digital maturity is critical
Most maturity indices are very high level
I~HD has established an interoperability asset register that has explicit and detailed criteria across domains.
ISO18864 draft standard for clinical models

7. The implications of FUTURE
Whilst encompassing legacy systems the LHS also needs to be able to be extensible
Establishment of TRUST via robust provenance is needed
Challenges
New classifications
New standards
New uses
New types of data

8. What parts of the LHS infrastucture already exist?
EHR systems Clinical Data Repositories Administrative/ Billing Data Repositories Research Networks Research Organisations Clinical Standards Organisations Patient Networks Pharmaceutical Industry, CROs, and supports Regulatory Agencies Data Privacy Agencies Informatics Standards Bodies

9. What Data standards exist?
Classifications,Terminologies and Vocabulary services
Ontologies
Clinical models
High level – BRIDG, HL7
Domain level, PCROM
Detailed Clinical Models, ISO13606, CDASH, FHIR Resources
Repositories of clinical models and interoperability - CIMI
Data transport standards
Document based (CDA) v model based (FHIR, ODM)
HL7 FHIR v CDISC ODM
Are we in the clinical world looking at research or in the research world looking at clinical data? – A false dichotomy.
The basic building block in FHIR is a Resource. All exchangeable content is defined as a resource. Resources all share the following set of characteristics:
A common way to define and represent them, building them from data types that define common reusable patterns of elements
A common set of metadata
A human readable part

10. Clinical Information Modelling Initiative
Huff 2016 (

11. Data standards for Trials: www.cdisc.org

12. Examples from : www.transformproject.eu
€9M from European Commission
March 2010-Nov 2015
Funded under the Patient Safety Work Program of FP7
To support clinical diagnosis
To support clinical trials
As part of a ‘Rapid Learning Healthcare System’

13. What would an LHS infrastructure look like? (example – diagnosis)

14. High level TECHNICAL architecture (example: research)

15. Limitations of existing CDISC standards for clinical trials
Operational Data Model (ODM) operates as a holder and can contain a wide variety of content. Clinical meaning and context can vary between clinical and research domains in unpredictable ways. CDASH offers a means of assembling libraries of well-defined forms, but does not implicitly translate to a clinical setting SHARE provides a repository of models, standards and data elements

16. ODM in TRANSFoRm – introducing an ontology

17. Why ontologies?
We need a ‘model of meaning’ for the research and clinical views Separate from the USE and IMPLEMENTATION Ontologies allow for a constant, extensible framework to represent meaning Reasoning for the LHS can be supported A critical decision needs to be made at domain level on the dividing line between ontological representation and the EHR/terminology

18. A ‘research’ side example: requirements
Prevalent and incident case identification from live EHR systems in primary care Real time alerting via EHR Pre-population of CRFs displayed “within” the EHR Data capture in EHR (eSource) PROMS data in EHR for Safety monitoring Data provenance – towards compliance with 21 CFR Part 11 and European regulation Full evaluation in 5 EU member states and real world RCT

19. TRANSFoRm technical requirements
To use ontologies to maintain models of meaning for the LHS (CRIM, CDIM, Provenance)
To use CDISC foundational standards ODM, SDM
To enable connection to multiple country, multiple language, multiple vendor systems with MINIMAL vendor input – No ‘hackathons’
Vendor requirements:
Standard Terminology used in EHR (LexEVS)
Sample EHR data set
Represent local database metadata as a model (DSM) and map to TRANSFoRm Clinical Data Integration Model (ontology)
API and a demo installation for testing

20. ODM xml

21. SystmOne pop up

22. SystmOne Consent

23. Data from patients: User Interface Extension to ODM
ODM extended with GUI elements When an ODM is created, the QuestionType attribute is added to every ItemDef object in ODM Platform-agnostic, rendered appropriately for each device

25. An implementation side example: Diagnostic ontology

26. xml

27. From ontology to client API

28. The interface for diagnosis driven by that ontology

29. Implementation side of the LHS : Interventions
Model based representations of guidelines (90’-00’)s: Oxford University (Fox): PROforma Stanford University (Musen): ATHENA (hypertension guideline) Flexible, elemental, transactional payloads with wrapper (2014-): University of Michigan (Friedman): Digital Knowledge Objects Based on FEDORA and utilizing APIs for interoperability

30. In summary
The LHS requires a world-changing approach to the creation, management and curation of well-defined digital artefacts and the tools needed to enable these to learn and guide practice in the context of a rich human-led socio-technical system.
We can already see the bones of this system developing via:
modern model-based extensible transfer standards
repositories of clinical data elements and information models needed to translate them
International collaborations (and a NEW journal!) “Learning Health Systems”

31. The Journal Open access First issue Jan 2017 online now
EIC: Prof Charles Friedman

32. I~HD

33. Thank you Brendan Delaney www.transformproject.eu