LLUMC Clinical Data Repository

AAMC Group on Information ResourcesMay 2, 2008

Loma Linda University Medical Center Academic Medical Center

650 residents and fellows in > 40 programs Affiliated with Loma Linda University Affiliated with Faculty Practice Plan

650 faculty physicians in 60 mile radius Only Level 1 Trauma Center for approximately 26%

of California 4th largest Hospital in California

Loma Linda University Medical Center 800 Licensed beds

University Hospital Children’s Hospital East Campus Hospital – Rehab, Ortho, Neuro Specialty

Separately licensed 89 bed Behavioral Medicine Center

Institutes - Cancer, Heart, and Transplant Proton Treatment Center

Loma Linda University Medical Center University Hospital (163 Adult ICU Beds)

Cardiothoracic ICU Medical/Surgical ICU Cardiac ICU Neurosurgery/Trauma/Surgery ICU Organ Transplantation

Children’s Hospital 57 Pediatric ICU beds 84 NICU beds

East Campus Hospital 8 –Adult ICU

Informatics Strategy

Efforts of last three years Retire in-house developed applications Retire specialty applications Move computer operations to established ASP

environments Reliance on Vendors for support and R&D Focus on “Core Vendors”

Core Vendor Strategy

Cerner: Patient Care support and Revenue Cycle Support

McKesson: Financials, Materials, Other Operational Support

GE/IDX: Clinic Management and Receivables Management

Oracle/PeopleSoft: Human Resources and Payroll Management

Electronic Medical Records

Work in Progress Current EMR functions include:

Nursing and Ancillary Department Documentation Drug and Supply Administration Management Lab, Radiology and other results management ICU Record Management Document Management (scanning paper documents) PACS and other Image Management Periops and Anesthesia Information Management

Electronic Medical Record (Continued)

Planned EMR Functions Physician Documentation Care Plans Order Sets CPOE Conversion from current Document Management data into

product integrated into Cerner system

Clinical Data Repository

Reviewed Products of Several Major Vendors None fully developed None provided robust decision support functionality that

was desired All closely integrated with other products of that vendor,

making difficult use for other information None were on an R&D track that was aligned with our

needs

So: linked W. Herbert White & Co. and Park Street Solutions (Chicago) as development partners

Project Objectives

Address the needs of all functional areas requiring access to historical clinical data Executive management, operational management,

physicians and care providers, quality managers, researchers and academics, data analysts and report developers

Provide accurate, comprehensive data to drive improvements in quality of care, enhance patient safety, and streamline clinical processes

Support the development of an analytic culture, enabling LLUMC to become a leader in knowledge-based decision making and evidence-based medicine

Strategy

Make reporting and analysis on clinical data practical, simple, fast, and secure

Support user needs with a single, general data repository

Create a patient-focused data warehouse that… Integrates clinical data from multiple sources Transforms data to a common structure and format Filters and cleanses data to assure accuracy Organizes data for reporting and analysis Enhances data to extend its value for reporting purposes Supports unpredictable ad hoc queries and unknowable

future reporting requirements

Tactical Challenges

Clinical requirements are poorly addressed by standard approaches Common data warehouse design practices Off-the-shelf business intelligence tools

Challenges result from The nature of clinical data Special requirements of clinical analysis Details of the technical environment

A unique feature set is required to respond to these challenges

Challenges: Nature of Clinical Data Requires combining highly disparate data into a

simple, general data warehouse structure Utilizes highly complex classification systems and

mappings to organize events Necessitates development of a useful clinical

perspective based upon reimbursement-oriented data Means accommodating very high data volume

Challenges: Nature of Clinical Analysis Emphasizes counting and correlation rather than

“slice and dice” Involves querying multiple discrete event types,

rather than simple additive facts Focuses on use of complex criteria to identify patient

cohorts and subsets thereof Concerned with intervals of time, simultaneity, and

sequences of states Constrained by privacy concerns, user access rights,

and audit requirements

Challenges: Technical Environment Requires obtaining data from 50+ sources Involves overcoming deficiencies in source systems

Barriers to acquiring snapshot extracts Lack of time-stamped event history

Requires accommodating a mixture of structured and unstructured data

Necessitates support for concepts related to Natural Language Processing Negation, uncertainty

Clinical Data Repository (CDR)Key Features CDR is a patient-focused clinical data warehouse,

comprising a longitudinal record of patient events Events in the patient record are organized by an

integrated knowledge base manages complex structures, vocabularies, and systems of

classification represents mappings supports efficient traversal of multiple relationships

More Key Features

CDR is driven principally by real-time data sources The HL7 data stream, in particular Other real-time and batch data sources are supported as well

Patient events in CDR are ADT-enhanced Remapped to a clinically relevant encounter structure Context added for patient location, encounter phase, and

acuity of care

CDR’s data structures support the abstraction of temporal concepts, providing a clinical view of patient state over time

More Key Features

“Soft-schema” design provides an open content model that accommodates the widest variety of data and will allow the addition of entirely new dimensions without altering the core database design

CDR’s architecture is HIPAA-aware from the outset, providing a fully de-identified data warehouse for most needs, with the ability to link to Protected Health Information as required

Data Warehouse

Engineered for flexibility and generality Performance is a crucial but secondary objective

Support for all potential application types Report-writing (using tools like Crystal Reports) Extracts Business intelligence/OLAP Data mining and statistical analysis (SPSS/SAS) Dashboards Visualization Third-party tools (quality/best practices/EBM)

Relational database technology throughout Data marts using other technologies expected and

encouraged

Longitudinal Patient Record

The longitudinal patient record constitutes the central point of the CDR data architecture

Scope includes all clinical events happening to any patient, or to clinical data about the patient: Admission, Discharge, Transfer events Laboratory and Pharmacy Orders Laboratory Test Results Medication Administration Events Observations, Assessments, and Chart Notations Diagnoses and Procedures Physician Associations Documents, Transcriptions, and Images

Knowledge Models in CDR

Industry Standards

ICD-9 diagnosis codes CPT-4 procedure codes DRG’s / APR DRG’s LOINC MULTUM SNOMED-CT UMLS/MESH Mappings!

LLUMC-Specific

Org charts: corporate, physicians, locations

Financial classes Drug formularies Cerner codesets Payers Encounter structure Protocols and processes Standards, policies, rules

Knowledge Base Features

Park Street’s knowledge base technology is used to represent and manage these structures

Includes a complete toolset for representing, querying, and maintaining knowledge models

Based entirely in standard relational technology Represents classes, instances, and relationships among them

as data Supports efficient, declarative, non-recursive traversal of

hierarchies and networks Allows the effective use of knowledge models in common

enterprise technology architectures

Relational Technology and the Knowledge Base When knowledge model data is stored in relational

database systems, we get: A highly efficient, flexible language for expressing queries

(SQL) Extraordinarily robust query optimization capabilities (30+

years and billions invested) A superior execution environment for ad hoc queries Sophisticated tools for data management Seamless joins to existing data Opportunity to leverage existing technology, common skill-

sets, and off-the-shelf software

Unique Query Capabilities

Sophisticated structural queries are supported Using only standard SQL Without recursion

Examples of such queries include: Tree and poly-hierarchy traversal Path enumeration and shortest path determination Neighborhood analysis Multi-step semantic network navigation

Integrated Knowledge Base

CDR represents all dimension data as elements of the knowledge base

The knowledge base permits the representation of relationships between any knowledge model entities Part-of, has-ingredient, due-to… Mappings to other coding systems or prior versions

Each patient event is characterized by a dimension entity and an associated dimension

Dimensions themselves are represented by nodes in the knowledge base Allows structure and relationships among dimensions to be

incorporated into queries

CDR Data Architecture

Dim

en

sions

Facts

Fact Extensions

Clinical Facts(Longitudinal Patient Record)

Built-InDimensions

Virtual Dimensions (Knowledge Base)

DimensionExtensions

SNOMED-CT

IndustryStandard

LLUMCSpecific

•Patient visit•Time

•ICD-9•CPT-4

•Location•Phase•Doctor

•SNOMED•RX-NORM•LOINC•IMO Problem-IT•IMO Procedure-IT•LLUMC Doctors

Indirect•Findings•Procedures

Direct•Product•Substance

Other•Body part•Social context•Other

Knowledge Structures

Patient Event Data

ICD-9 SNOMED Locations

Patient A

Encounter 1

Event 1 Event 2

Encounter 2

Event 1

Visit 1

Event 2

Visit 1

Detailed Data Architecture

Challenges of Disparate Data

It is difficult to conform detailed clinical data to a single structure The nature of clinical events varies broadly Even when events are similar, data arising in different

processes or systems may be captured differently, or in differing levels of detail

With time (or during phased implementation), new data items will become available

Systems and data sources change constantly, and new data items will become available frequently

Soft Schema Design

CDR’s “soft-schema” design provides an integrated repository for disparate data All dimension entities (other than Patient and Time) are

represented by nodes in the knowledge base Dimension Extension tables allow storage of dimension

data associated with dimension entities And address the problem of slowly-changing dimensions

Fact Extension tables provide for storage of detailed data particular to a patient event

Open Content Model

CDR easily accommodates new data as it becomes available, without physical reorganization or schema modification New dimensions and dimension changes are executed

simply by adding entries to the KB and, sometimes, adding new Extension tables

New kinds of facts can simply be added, without modifying the structure of existing fact data

Support for future data concepts is built-in Negation and uncertainty for data obtained via Natural

Language Processing

Real-Time Data Acquisition

Advantageous to view the real-time data stream… Understand patient status Track the history of events Provide greater timeliness in the data warehouse

…especially when real-time data appears in HL7 format Standard formats Pre-scrubbed and normalized

CDR is built to support real-time data acquisition Message Queuing architecture HL7 mapping and translation Provision for “trickle-posting”

ADT Enhanced

Maps are built based on ADT events A mapping from incoming financial structures to a

common, clinically-oriented model of the patient encounter A map of patient location at each point in the encounter A map of the phases of care the patient passes through

(outpatient, pre-hospital, emergency, inpatient)

The maps are used to enhance each patient event as it is loaded into the CDR, tagging it with An entry in the patient-encounter-visit dimension An entry in the location Dimension An entry in the phase Dimension

Data Warehouse Operations

Acquire data from multiple data sources Real-time HL7 data from the Interface Engine Scheduled data pulls and unscheduled pushes

Cleanse, code, and reformat data Driven by models in the knowledge base

Store in repository Maintenance of identified patient data Efficient posting of data warehouse content

Manage data integrity errors and exceptions Alerts, reporting, and analysis Data correction and transaction reprocessing

Awareness of the HIPAA Privacy Rule

CDR is designed to support compliance with HIPAA privacy rules

Physically distinct storage is be provided for: De-identified data Limited data set (no patient identity) Fully identified

De-identified data complies fully with HIPAA rules Transformation of patient keys (patient ID’s, medical record

numbers) to randomized record identifiers Transformation of identifiable data (Zip Codes, dates, ages)

to de-identified form Limited granularity for time values Transformation of uncommon data elements to more

general forms via knowledge base

HIPAA Audit Trail

CDR provides facilities to Record permissions granted to users and user roles Maintain an audit trail that tracks all access to CDR

resources by user, role, and purpose Report on data access history

“Permission slip” concept All data access using CDR tools must be conducted under

the authority of a permission slip Describes authority under which access to data is obtained

The Problem of Time

Clinical analysis requires the ability to investigate time-based relationships between facts Must understand patient state at any given time

With respect a given condition, state may … Driven by any number of event streams Spawn any number of sub-states

State depends upon the sequence of events, not just their most recent values Time-stamped data by itself is insufficient!

CDR consists of time-stamped patient events Not a suitable foundation for general clinical queries

Representation of Time

To support meaningful clinical analysis… Event streams must be transformed to properly represent

patient state The resulting representation must support query and

analysis using standard relational tools

State Maps Represent patient states during intervals of time Characterize state by Name, Value, Direction, Velocity,

Pattern Designed to support relational queries, in terms of both ease

of construction and efficient execution

State Map In The Database

Start Time

1/1/0001 00:00:00

3/1/2008 12:30:28

3/1/2008 12:51:07

3/1/2008 14:24:19

3/1/2008 15:05:09

End Time

3/1/2008 12:30:28

3/1/2008 12:51:07

3/1/2008 14:24:19

3/1/2008 15:05:09

9/9/9999 00:00:00

Name Not Admitted Don't know High Normal Discharged

Value NULL NULL 101.3 98.6 NULL

Direction NULL NULL Decreasing Stable NULL

Velocity NULL NULL Fast Stable NULL

Pattern NULL NULL NULL NULL NULL

State Machines

A “state machine” is a computational model of the behavior of an object over time Define the rules for transforming one or more series of

time-stamped events (“event streams”) into state maps Intuitive and easy to manage for system users Precise from a computational perspective Accommodate issues of sequence

State maps in the CDR database are generated by State Machines

CAPS LOCK State Machine

CAPSLOCKOFF

CAPSLOCKON

Events

Button Pushed

State

Actions

Associated with transitions

1. Turn Light On

2. Turn Light Off

Controls other actions

•CAPS LOCK OFF - lower case

•CAPS LOCK ON - upper case

State Machine

Transition

State

(2) (1)

Initial State

State Machines in CDR

Events

Clinical Events

•Observations

•Procedures

•Medications

State

Actions

Controls other actions

•Other state machines for patient

Associated with transitions

•Write to patient state map in database

Don’tKnow

Confirmed

Suspected

Chronic Acute

Hierarchical State Machine

Sub-states

CDR Applications

Phase I applications for CDR Intended to demonstrate and validate system capabilities

CMS Core Measures IHI Global Trigger Tool LLUMC specific STOP Sepsis Bundle

CMS Core Measures

Quality indicators that will drive reimbursement (P4P, denial of claims)

One element of one core measure (Acute MI time to aspirin administration)

Simple query using time zero as admit to ED and admin of ASA from eMAR

Institute for Healthcare Improvement (IHI) “An independent not-for-profit organization

helping to lead the improvement of health care throughout the world.”

Motto: “Closing the Quality Gap” IHI.org

IHI Global Trigger Tool

Tool to help an institution identify adverse events

Methodology to improve efficacy of locating adverse events that actually do patient harm via random retrospective chart audits

“Not meant to identify every single adverse event in a patient record” but to track AE’s over time as a measure of effective improvement in patient safety and quality

IHI Global Trigger Tool for Measuring Adverse Events 54 “Triggers” in 4 modules to be looked for

in any one chart during a 20 min review by clinically trained personnel (mid-level providers) If present, secondary analysis done by reviewer

Examples: Transfusion or use of blood products Readmission to ICU Apgar score <7 at 5 min Rising BUN or serum creatinine, >2x baseline

http://www.ihi.org/IHI/Results/WhitePapers/IHIGlobalTriggerToolWhitePaper.htm

Phase I Project Objectives

Automate search of selected charts for readily obtainable triggers out of CDR (50% in phase I)

Compare computer results against human search results and report differences.

Reduce time spent on raw review and shift to analysis/process improvement

Phase II Project Objectives

Develop queries around positive triggers to glean preliminary info for human reviewer. If PTT >100 seconds, was heparin also present?

Expand automated search to include less easy triggers: “Pneumonia Onset” (an ICU Module Trigger) “Pathology report normal or unrelated to

diagnosis” (a Surgical Module Trigger) “Healthcare-associated infection of any kind” (a

Cares Module trigger)

“Sepsis”

CDR query for “sepsis” was for us a “BHAG”1

Sepsis is a serious medical condition characterized by a body-side inflammatory state caused by infection

Has a spectrum of clinical manifestations from minor to catastrophic

It’s often not the infection, but the response of the patient’s immune system that causes death.

It’s a clinical diagnosis, and intervention must begin before culture results are available

1 “Big Hairy Audacious Goal” from Collins and Porras, “Building

Your Company’s Vision”, 1996

Sepsis Spectrum

SIRS ---> Sepsis ---> Severe Sepsis ---> Septic Shock SIRS = Two or more of the following:

Temp > 100.9 F or < 96.8 F Heart Rate > 90 Resp Rate >20 or PaCO2 < 32 mmHg WBC > 12K, < 4K or > 10% Bands

Sepsis = SIRS plus infection or suspected infection Severe Sepsis = Sepsis plus evidence of bodywide

inflammatory reaction (+ lactate blood test plus organ failure) Septic Shock = Severe Sepsis plus low blood pressure

unresponsive to a bolus of IV fluid (SBP<90 after 1 liter)

About Sepsis

>750,000 annually in US Retrospective cohort study 14 ICUs in 10 US and

Canada hospitals 2,731 septic shock pts 44.4% present to ED Median time to Abx 6 hours

after low blood pressure started

56.2% overall mortality

Kumar A et al. Crit Care Med 2006

About Sepsis

Every hour delay in administration of appropriate antibiotics within the 1st 6 hours of septic shock is associated with a decrease in survival of 7.6%.

Kumar A et al. Crit Care Med 2006

Sepsis Bundle

Early appropriate intervention can cut mortality of septic shock by ~ 20%

A “bundle” is a method of implementing clinical guidelines that lead to better outcomes

Involves a group of choreographed interventions Loma Linda Champion: Dr. Bryant Nguyen

Leader in the field of early sepsis intervention Loma Linda specific sepsis bundle developed and

implemented in 2003 in ED and 2005 house wide

Rivers, Nguyen et al. NEJM, 2001

http://lomalindahealth.org/common/legacy/llumc/emergency/patientcare/documents/patientcare-sepsis.pdf

Sepsis Bundle Analysis

CDR objectives for sepsis Track incidence of sepsis Investigate co-morbidity and other correlated factors Monitor compliance with Sepsis Bundle Analyze outcomes when Sepsis Bundle is applied vs not

applied Measure effectiveness of existing compliance management

processes

Relevant Event Streams

Event categories that drive the diagnosis of sepsis and categorize its severity

For selected patient visits, track: Temperature Heart rate Blood Pressure Respiratory rate Carbon dioxide pressure White blood count Lactate Cultures

Sepsis State Machine

SIRSNo

ProblemSepticShock

SepsisSevereSepsis(Low)

SevereSepsis(High)

Don’tKnow

Issue Time Zero Event

(1)

(7)

(8)

(6)(2)

(4) (5)

(2)

1. 3 negative

2. 2 or more criteria positive

3. 3 don’t know

4. Positive cultures

5. Lactate ≥2 mmol/L

6. Lactate ≥4 mmol/L

7. SPB < 90 after one liter IV fluid

8. Decay (48 hours)

(1)

(3)

For Each Time Zero

Measurement maps CVP MAP/SBP ScvO2 Glucose Pplateau (vent pressure) ∆ Cortisol Apache assessment

Presence maps Fluids Vasopressor Insulin Steroids Drotrecogin alfa (Xigris)

Bundle initiation is expected! Spawn sub-maps for the time zero event to track:

The Future

CDR will never be “finished” Remain primarily used for Medical Center decision

support needs Expand to Faculty Practice Plan decision support

needs Expand to other enterprise mission arms

Students (Medical Informatics Elective in SOM) Pure academicians (Research)

Collaboration

Thank you!

To the audience for allowing us to share our story with you

To W. Herbert White & Co. for its strategic vision and leadership in this CDR project

To the team at Park Street Solutions for their brilliance in making really hard things look easy

To Dr. H. Bryant Nugent for his clinical expertise and willingness to share his wisdom

Questions?