LLUMC Clinical Data Repository

1
LLUMC Clinical Data Repository

• AAMC Group on Information ResourcesMay 2, 2008

2
(No Transcript)
3
Loma Linda University Medical Center

• Academic Medical Center
• 650 residents and fellows in gt 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

4
Loma Linda University Medical Center

• 800 Licensed beds
• University Hospital
• Childrens Hospital
• East Campus Hospital Rehab, Ortho, Neuro
  Specialty
• Separately licensed 89 bed Behavioral Medicine
  Center
• Institutes - Cancer, Heart, and Transplant
• Proton Treatment Center

5
Loma Linda University Medical Center

• University Hospital (163 Adult ICU Beds)
• Cardiothoracic ICU
• Medical/Surgical ICU
• Cardiac ICU
• Neurosurgery/Trauma/Surgery ICU
• Organ Transplantation
• Childrens Hospital
• 57 Pediatric ICU beds
• 84 NICU beds
• East Campus Hospital
• 8 Adult ICU

6
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 RD
• Focus on Core Vendors

7
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

8
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

9
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

10
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 RD track that was aligned with
  our needs
• So linked W. Herbert White Co. and Park
  Street Solutions (Chicago) as development partners

11
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

12
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

13
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

14
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

15
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

16
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

17
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

18
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
• CDRs data structures support the abstraction of
  temporal concepts, providing a clinical view of
  patient state over time

19
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
• CDRs 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

20
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

21
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

22
Knowledge Models in CDR

• Industry Standards
• ICD-9 diagnosis codes
• CPT-4 procedure codes
• DRGs / APR DRGs
• 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

23
Knowledge Base Features

• Park Streets 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

24
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

25
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

26
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

27
CDR Data Architecture
Dimensions
Built-InDimensions
Virtual Dimensions (Knowledge Base)
DimensionExtensions
SNOMED-CT

• Indirect
• Findings
• Procedures

• Direct
• Product
• Substance

• Other
• Body part
• Social context
• Other

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

• Patient visit
• Time

IndustryStandard
LLUMCSpecific

• ICD-9
• CPT-4

• Location
• Phase
• Doctor

Facts
Clinical Facts(Longitudinal Patient Record)
Fact Extensions
28
Detailed Data Architecture
Knowledge Structures
ICD-9
SNOMED
Locations
Patient Event Data
Patient A
Encounter 1
Encounter 2
Visit 1
Visit 1
Event 1
Event 2
Event 1
Event 2
29
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

30
Soft Schema Design

• CDRs 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

31
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

32
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

33
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

34
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

35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
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 IDs,
  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

39
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

40
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

41
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

42
State Map In The Database
43
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

44
CAPS LOCK State Machine
Initial State
State Machine
CAPSLOCK OFF
State

• Controls other actions
• CAPS LOCK OFF - lower case
• CAPS LOCK ON - upper case

Events
(2)
(1)
Actions
Button Pushed
CAPSLOCK ON

• Associated with transitions
• Turn Light On
• Turn Light Off

Transition
State
45
State Machines in CDR
State
Hierarchical State Machine
DontKnow

• Controls other actions
• Other state machines for patient

Confirmed
Events
Suspected
Actions

• Clinical Events
• Observations
• Procedures
• Medications

Chronic
Acute

• Associated with transitions
• Write to patient state map in database

Sub-states
46
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

47
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

48
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

49
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 AEs over time
  as a measure of effective improvement in patient
  safety and quality

50
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 lt7 at 5 min
• Rising BUN or serum creatinine, gt2x baseline

51
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

52
Phase II Project Objectives

• Develop queries around positive triggers to glean
  preliminary info for human reviewer.
• If PTT gt100 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)

53
Sepsis

• CDR query for sepsis was for us a BHAG1
• 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
• Its often not the infection, but the response of
  the patients immune system that causes death.
• Its a clinical diagnosis, and intervention must
  begin before culture results are available

1 Big Hairy Audacious Goal from Collins and
Porras, Building Your Companys Vision, 1996
54
Sepsis Spectrum

• SIRS ---gt Sepsis ---gt Severe Sepsis ---gt Septic
  Shock
• SIRS Two or more of the following
• Temp gt 100.9 F or lt 96.8 F
• Heart Rate gt 90
• Resp Rate gt20 or PaCO2 lt 32 mmHg
• WBC gt 12K, lt 4K or gt 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
  (SBPlt90 after 1 liter)

55
About Sepsis

• gt750,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
56
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
57
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
58
(No Transcript)
59
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

60
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

61
Sepsis State Machine
DontKnow
(8)
(1)
(3)
(2)
SIRS
NoProblem
Septic Shock
Sepsis
Severe Sepsis (Low)
SevereSepsis(High)
(2)
(7)
(6)
(4)
(5)
(1)

• 3 negative
• 2 or more criteria positive
• 3 dont know
• Positive cultures
• Lactate 2 mmol/L
• Lactate 4 mmol/L
• SPB lt 90 after one liter IV fluid
• Decay (48 hours)

Issue Time Zero Event
62
For Each Time Zero

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

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

• Presence maps
• Fluids
• Vasopressor
• Insulin
• Steroids
• Drotrecogin alfa (Xigris)

63
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

64
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

65
Questions?