designing real world electronic health record systems n.
Skip this Video
Loading SlideShow in 5 Seconds..
Designing Real-World Electronic Health Record Systems PowerPoint Presentation
Download Presentation
Designing Real-World Electronic Health Record Systems

Loading in 2 Seconds...

play fullscreen
1 / 26

Designing Real-World Electronic Health Record Systems - PowerPoint PPT Presentation

  • Uploaded on

Designing Real-World Electronic Health Record Systems. Kenneth S. Rubin Enterprise Architect, EDS Presentation Overview. Introduction The role of Health Databases Operational systems EHR Analytics EHRs: A Look at Functional and Technical Requirements

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Designing Real-World Electronic Health Record Systems' - kyne

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
designing real world electronic health record systems

Designing Real-World Electronic Health Record Systems

Kenneth S. Rubin

Enterprise Architect, EDS

presentation overview
Presentation Overview
  • Introduction
  • The role of Health Databases
    • Operational systems
    • EHR
    • Analytics
  • EHRs: A Look at Functional and Technical Requirements
  • Designing an EHR
presentation overview1
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. 
a little personal background
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

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

First, a little about VHA*

*statistics taken from May 2004 Fact Sheet, U.S. Dept of Veterans Affairs

are health databases different
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
judge for yourself
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)
matching database types to needs
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!
matching database types to needs1
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!
let s role play
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?
your requirements
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
by the way
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
Solving the problem:

Key Solution Elements

parsing the problem space
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
overall design approach
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
role of an information model
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
computable data
“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
maximizing the use of standards
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
archetypes as units of composition
“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 (

physical design based on anticipated use
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
selecting the appropriate persistence construct
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
  • VHA Website:
  • VHA HIA Website:
  • HL7 Website:
  • OpenEHR Website: