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

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

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)

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

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

Current Electronic Health Data Ecosystem

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!

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

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

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

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

Experience: Semantic Data Repository Ad Hoc Query SPARQL & Natural Language with Cyc SemanticDB Domain Model Facilitated Data Entry Data Mason XML Templates User Interface Plan Report Templates Screen Compiler Stored Queries Data Entry RDF Database OWL Ontology XML Schema XSLT XML Patient Records ‘Throttled’ Dual Representation

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

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

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 If GRDDL is used, new XML formats do not even need to be known to the service in advance.

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

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

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

Experience: Data Models and Ontologies Three semantic layers: Domain data models: RDF version generates 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

Experience: Data Models and Ontologies

Experience: Data Models and Ontologies

Experience: Data Models and Ontologies

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

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

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

Experience: Inference, Query and Views

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

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

Questions?