8/25/ :09 PM Designing Real-World Electronic Health Record Systems Kenneth S. Rubin Enterprise Architect, EDS Kenneth S. Rubin Enterprise Architect, EDS

Page 2 Presentation Overview Introduction The role of Health Databases –Operational systems –EHR –Analytics EHRs: A Look at Functional and Technical Requirements Designing an EHR

Page 3 Presentation Overview This session will focus on the design and implementation of an electronic health record. EHR systems face a number of challenges atypical from other system implementation activities. The systems must be capable of supporting day-to-day clinical decision-making, yet maintain relevance and viability for extended periods of time. In addition, EHR systems must feed analytic data sources such as warehouses for epidemiology and development of clinical practice guidelines. Perhaps most importantly, EHR systems do not live in a vacuum--they must be capable of interoperating with peer EHR systems as part of the delivery of care to the beneficiaries for whom data is stored. This session will explore these topics, focused on the tradeoffs and implementation approaches capable of addressing these concerns. To be discussed are areas such as clinical terminologies, information and data modeling, representation and structure of complex clinical concepts for persistence in the EHR, interoperability and the affect it has on design, impacts of data longevity, data versioning, and encapsulation. The emphasis of the session will favor the architectural and design aspects affecting implementations over database technology details.

Page 4 IntroductionIntroduction

Page 5 A little personal background… Over 15 years of IT experience; 8 years in health informatics Current role of Health Information “Application” Architect for the Veterans Health Administration 8 years involvement in Health Level Seven (HL7) and Object Management Group (OMG) Standards Communities Senior advisor to VHA Health Data Repository and Health Information Modeling teams *slide adapted from 2004 ITC Presentation on VHA Common Services

Page 6 First, a little about VHA* Business View –Largest care provider in the US –158 hospitals/medical centers –854 outpatient clinics –132 long-term care facilities –42 rehabilitation facilities –Affiliated with 107 of 125 medical schools in the US Healthcare Statistics (2003) –7.2M beneficiaries enrolled –4.8M treated –49.8M outpatient visits Operational View –180k VHA employees –13k physicians, 49k nurses –85k health professionals trained annually –USD $29.1B Budget for 2004 Technical View –VistA (EHR) for over 20 years –Software portfolio exceeds 140 applications –Reengineering effort is based upon a services architecture *statistics taken from May 2004 Fact Sheet, U.S. Dept of Veterans Affairs

Page 7 The Role of Health Databases

Page 8 Are health databases different? A typical database… –Supports the need for persistence –Is designed to meet performance requirements –Supports concurrency, scalability –Is designed by a DBA in conjunction with a project team –Are closely coupled with the application it supports –Has a usable system life of 2-10 years

Page 9 Judge for yourself… Health databases… –Play an active part in clinical decision-making and care-giving –Contain health information that must be maintained for the lifetime of the patient (or significantly longer!) –Have extreme high-availability requirements –Require near-real-time performance expectations –Must be capable of integrating content from external sources –Must maintain information durability over time –Have significant privacy and sensitivity considerations (HIPAA)

Page 10 Matching Database Types to Needs There is an ecosystem of database types –Transactional Systems –Operational Data Stores –Data Warehouses –Data Marts The purpose and role of a system is crucial in choosing the right construct Do not multi-purpose a database Optimization is not multi-axial Principle: Match the construct to the system role!

Page 11 Matching Database Types to Needs There is an ecosystem of database types –Transactional Systems –Operational Data Stores –Data Warehouses –Data Marts The purpose and role of a system is crucial in choosing the right construct Do not multi-purpose a database. Optimization is not multi-axial Principle: Match the construct to the system role!

Page 12 EHRs: A look at Functional and Technical Requirements

Page 13 Let’s Role-Play… You are now the chief architect/database designer for VHA’s Electronic Health Record Following are a set of business and design objectives How will you meet these needs?

Page 14 Your requirements… The system must be optimized for clinical decision-making Your system must be capable of integrating data from our business partners and patients themselves Data from business partners must maintain consistency in its meaning You will manage approximately 3000 unique data elements in 14 functional domains (laboratory, pharmacy, vitals, demographics, encounters, radiology/nuclear medicine, etc.) You must support the application’s need to provide alerts for approximately 500k drug-drug and drug-allergy interactions and contraindications

Page 15 By the way… Care providers expect responses in fewer than 7 seconds Data from business partners cannot lose its meaning The physical hardware platform on which you are running will change in 18 months Data must be available and usable for at least 75 years Your database will have one national and 22 concurrent federated “local” deployments Local updates must appear nationally with a near-real-time latency By the way, these are actual requirements of VHA’s EHR

Page 16 Solving the problem: Key Solution Elements Solving the problem: Key Solution Elements

Page 17 Parsing the problem space… Differentiating requirements: –Which are functional requirements (e.g., affecting database data design)? –Which are “non-functional” requirements (e.g., performance and platform)? –What are the implications of the requirements? Use cases: not just for systems developers… –Leverage this technique to understand the purpose and role of the system –The provide valuable insight into how data will be used –Prioritize them to understand how and what to optimize

Page 18 Overall Design Approach Design for the complex case: every time you cut corners you get burned Steal whatever you can. Good ideas are meant to be shared. Garbage in, garbage out. Establish quality conformance criteria for data entering the database Support deployment flexibility: recognize implications of centralized, federated, and peer-to-peer Ensure transactional and referential integrity Recognize the increasing role that individuals are playing in their personal health

Page 19 Role of an Information Model The need to harmonize and standardize semantics Determines bindings to relevant terminologies Consistent information representation To depict structure and semantic relationships Provides guidance for logical database design Clarify data typing

Page 20 “Computable” Data Not all data representations are created equal Content stored as strings without an underlying terminology cannot be used for clinical reasoning, alerts, interactions, epidemiology A simple example: how many genders are there? A VHA example: getting to Yes The effort and importance of knowledge engineering and terminology cannot be overstated

Page 21 Maximizing the use of Standards Open standards promote interoperability and longevity Proprietary solutions are no longer an option. Eventually every organization must deal with business partners. Standards either exist or are emerging to address almost every aspect of Health IT: interfaces, messaging, DDL, terminology, and so on

Page 22 “Archetypes” as units of Composition An “archetype” is a unit of expression containing structure, associations, data types, terminology, and semantic “wholeness” Archetypes have self-contained and durable meaning Archetypes are composable Archetypes can be versioned and registered Figure courtesy of Deep Thought Informatics (

Page 23 Physical Design based on Anticipated Use Optimization cannot be multi-axial: optimize for the mainstream Use-case analysis will give valuable insight into how the system will be used Performance is of paramount importance Use proprietary DBMS functionality, but with care

Page 24 Selecting the appropriate persistence construct Use online-transactional (OLTP) constructs for support and ancillary systems Use an operational data store (ODS) for the EHR itself Migrate analytics data from the ODS to an enterprise warehouse Extract data from the warehouse into data marts for epidemiology, study, trending, etc. Do not perform analytics on the EHR directly Consider enterprise data as an integrated “eco-system”, with each constructing having a purpose and role

Page 25 References VHA Website: VHA HIA Website: HL7 Website: OpenEHR Website:

Page 26 DiscussionDiscussion