LLUMC Clinical Data Repository

1. LLUMC Clinical Data Repository AAMC Group on Information ResourcesMay 2, 2008

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

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

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 • Children’s 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 R&D • 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 R&D 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 • CDR’s 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 • 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

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. 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 Models in CDR

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

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 Virtual Dimensions (Knowledge Base) Built-InDimensions SNOMED-CT DimensionExtensions • 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 • 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

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

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

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. 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 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 Don’tKnow • 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 AE’s over time as a measure of effective improvement in patient safety and quality

50. http://www.ihi.org/IHI/Results/WhitePapers/IHIGlobalTriggerToolWhitePaper.htmhttp://www.ihi.org/IHI/Results/WhitePapers/IHIGlobalTriggerToolWhitePaper.htm 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