1. Meaningful Use of Electronic Medical Records through Semantic Technologies: The Cleveland Clinic Experience
Christopher Pierce, Ph.D. (Cleveland Clinic)
David Booth, Ph.D. (Cleveland Clinic contractor)
Chris Deaton (Cycorp)
Semantic Technology Conference
25-June-2010
Latest version:

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
Lab databases
Billing/Claims databases
Research data registries
Reporting databases

6. Enterprise EMRs
A complete record of patient encounters including demographics, medical history, medications, tests, images, treatments, etc.
Benefits
Comprehensive scope for enterprise
Accessible to human users across the enterprise
Challenges
Mostly narrative content
Structured content often inaccessible for significant periods of time, and difficult to retrieve

7. Lab Databases
Patient data captured during specific medical tests and treatments including indications, methods, results, and complications.
Benefits
Mostly structured content amenable to use by computers
Challenges
Restricted scope to specific procedure
Locally defined terms
Limited accessibility

8. Billing/Claims Databases
Data collected to support billing for specific procedures and diagnoses for patients
Benefits
Use of national and international standard codes and terms
Structured data with enterprise-wide scope
Challenges
Terms of limited or misleading clinical relevance
Can be difficult to access

9. Research Data Registries
Patient data collected to support outcomes research in specific domains
Benefits
Structured data
Consistent, longitudinal data vetted through use in studies
Challenges
Restricted scope
Locally defined terms
Data silos with limited accessibility

10. Reporting Databases
Patient data collected for specific reporting to regional and national quality monitoring groups
Benefits
Term definitions consistent across enterprises
Structured data
Challenges
Restricted scope
Definitions of the same terms vary among reporting databases

11. Electronic Health Data Ecosystem

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

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

14. Cleveland Clinic Semantic Strategies
Build 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

15. Why a Semantic Data Repository?
Easier semantic data federation and integration than with relational
Removes syntactic barriers
Provides robust framework for reconciling semantic discrepancies

16. Cleveland Clinic Semantic Initiative
TimeLine:
– Small proof of concept studies
2003 – Development project launched
2008 – Live production system released
2010 – Migrate to commercial RDF database
Short-term Goals:
Improve reporting of quality metric
Facilitate outcomes research

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

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

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

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

21. Experience: Core Data Elements
How to define core data elements?
Event model: Most medical data can be easily organized into temporally 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

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

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

24. Experience: Data Models & 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

25. Experience: Data Models & Ontologies

26. Experience: Data Models & Ontologies

27. Experience: Data Models & 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

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

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

30. Experience: Inference, Query and Views

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

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

33. Questions?