Making Meaningful Use of Electronic Medical Records at Cleveland Clinic

1. Making Meaningful Use of Electronic Medical Records at Cleveland Clinic • Christopher Pierce (Cleveland Clinic) • David Booth (Cleveland Clinic contractor) • Chris Deaton (Cycorp) • Cambridge Semantic Web Interest Group Meeting • 11-May-2010

2. Outline • What is “meaningful use” and why care • Current state of electronic health data • Cleveland Clinic semantic initiative and strategies • Cleveland Clinic experiences implementing this initiative

3. Motivation for Meaningful Use of Electronic Medical Data • 2009 Federal stimulus package (ARRA) provided $19B to encourage adoption of electronic medical records (EMR) systems • Medical practices that have EMRs and put them to “meaningful use” will get higher reimbursement from the government (Medicare and Medicaid)

4. Meaningful Use according to ARRA and CMS (Medicare & Medicaid) • Many initiatives with these objectives: • Improve health care cost, effectiveness, and safety through use of electronic medical data • Improve health data portability and accessibility • Provide electronic reporting of health care quality and performance metrics • Ensure adequate privacy and security for personal health information

5. Current Electronic Health Data • Enterprise EMRs:Mostly narrative content with comprehensive scope • Lab databases:Restricted scope and locally defined terms • Billing/Claims databases:Standard terms of limited clinical relevance • Research data registries:Variable scope and locally defined terms • Reporting databases:Scope and terms defined by entity requiring report

6. Current Electronic Health Data Ecosystem

7. How to Accomplish Meaningful Use? • Infrastructure needed for meaningful use: • Localized control of data collection • Centralized control of data definitions • Machine and human readable definitions of all data elements • Structured data amenable to machine processing Semantic web technology can help!

8. Cleveland Clinic Semantic Initiative • Goal: Reduce barriers to use of electronic medical data by • Increasing data interoperability:data in one system accessible and useable by others • Increasing data reusability:data useful for multiple and novel purposes • Reducing data silos:data accessible from centralized source(s) • Reducing data redundancy:data collected once and usable by all

9. Cleveland Clinic Semantic Strategies • Centralized/federated semantic data repository • Define and collect stable core data elements and clinical facts • Define RDF data models augmented by domain and upper ontologies • Link RDF instance data with ontologies and rules to support inference, query, and derived views

10. Why a semantic data repository? • Easier semantic data federation and integration than with relational • Removes syntactic barriers • Provides robust framework for reconciling semantic discrepancies

11. Cleveland Clinic Semantic Initiative • TimeLine: • 1997-2002 – Proof of concept studies • 2003 – Development project launched • 2008 – Live production system released • 2010 – Migrate to commercial RDF database • Short-term Goals: • Improve reporting on patient care quality • Facilitate outcomes research

12. Ad Hoc Query SPARQL & Natural Language with Cyc Domain Model DataMason Experience: Semantic Data Repository SemanticDB Facilitated Data Entry XMLTemplates User InterfacePlan Report Templates ScreenCompiler Stored Queries Data Entry RDFDatabase OWLOntology XMLSchema XSLT XMLPatientRecords ‘Throttled’ Dual Representation

13. Experience: Semantic Data Repository • Strengths • Data stored as both XML and RDF usable by services and applications that handle either format (e.g., forms-based processing of XML vs. inference-based processing of RDF) • RDF allows for explicit semantics not restricted to implicit XML hierarchical or RDB relational semantics • Data model extensibility • Easy data integration and federation

14. Experience: Semantic Data Repository • Challenges • Query performance • Model change control and propagation for application-data alignment • Incremental update of RDF from XML • Generation of XML from RDF • Exporting data to other formats

15. Experience: Core Data Elements • Why core data elements? • Data relativity - view of data dependent on frame of reference • Temporal perspective:what is a pre-procedural risk factor from one point in time may be a post-procedural complication from another • Definitional perspective:definitions for the same term can vary among uses and over time (e.g., current smoker) • Version perspective:model/data versions

16. Experience: Core Data Elements • How to define core data elements? • Event model: Most medical data can be easily organized into temporal discrete events with associated properties • Fuzzy time: Timing of medical events can be fuzzy for many reasons. Need to embrace this fuzziness • Pragmatic definitions: must find balance between infinitely reusable atomistic detail and special purpose definitions with limited reusability

17. Experience: Core Data Elements • Strengths • Multiple uses of the same data • No need to collect and store the same data multiple times in different repositories for different purposes

18. Experience: Core Data Elements • Challenges • Poor alignment with current practice • Clinical practice is to document patient conditions anew with each encounter • Clinical documentation is part of legal record and cannot be changed once codified in patient medical record • Past patient history • data usually collected by clinicians from the perspective of the current encounter and often lacks sufficient precision to convert to core data elements

19. Experience: Data Models and Ontologies Three semantic layers: Domain data models: RDF versiongenerates basic patient record OWL ontology Patient view abstraction layer: aligns domain ontologies with term standards found in upper-level ontologies Ontology of medicine: reference ontology of medical terms and relationships

20. Experience: Data Models and Ontologies

21. Experience: Data Models and Ontologies

22. Experience: Data Models and Ontologies

23. Experience: Data Models and Ontologies • Strengths • Provides a stable layer of terms through which to access instance data • Supports different views of the same data Challenges • Lack of strong upper-level ontologies in medicine • Maintenance of ontology alignments in the face of model changes

24. Experience: Inference, Query and Views • Using inference to enhance queries and views • Forward inference: • Inference run before query time • Either for persistence or on-the-fly use • Backward inference: • Inference run at query time Used to facilitate query formulation, data exporting, and report generation

25. Cycupper ontology SemanticDataFederation Ontology of Medicine Gene Ontology (GO) SQL,SPARQL Domain-specific Ontologies Data-source Ontologies Experience: Inference, Query and Views User interfaces Ontologies Cyc natural language processing Patient Data Entry Natural languagequery SPARQL interface Structured query Semantic wiki Data-source adaptors Instance data Patient-centric systems Patientregistry Geneticpatientregistry Tagged literature, e.g., PUBMED . . . . . .

26. Experience: Inference, Query and Views

27. Experience: Inference, Query and Views • Strengths • Queries can be asked using terms not present in the instance data • Caching and periodic refreshing of different views of the data (e.g., an STS view, a SNOMED view, etc.) • Allows maintaining different versions of the same view

28. Experience: Inference, Query and Views • Challenges • Inference performance bottlenecks: forward inference is slow and degrades significantly as the number of graphs and the number of events per graph increase • Maintaining semantic alignment: different version of instance data, rules and ontologies must be kept in alignment as changes occur

29. Questions?