Designing Real-World Electronic Health Record Systems

04/20/23 19:59

Designing Real-World Electronic Health Record SystemsDesigning Real-World Electronic Health Record Systems

Kenneth S. RubinEnterprise Architect, EDS

[email protected]

Kenneth S. RubinEnterprise Architect, EDS

[email protected]

Presentation OverviewPresentation Overview

• Introduction

• The role of Health Databases

– Operational systems

– EHR

– Analytics

• EHRs: A Look at Functional and Technical Requirements

• Designing an EHR

Presentation OverviewPresentation 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.

IntroductionIntroductionIntroductionIntroduction

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

The Role of Health Databases The Role of Health Databases The Role of Health Databases The Role of Health Databases

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

EHRs: A look at Functional and EHRs: A look at Functional and Technical RequirementsTechnical RequirementsEHRs: A look at Functional and EHRs: A look at Functional and Technical RequirementsTechnical Requirements

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: Solving the problem:

Key Solution ElementsKey Solution Elements

Solving the problem: Solving the problem:

Key Solution ElementsKey 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 (http://www.deepthought.com.au)

Physical Design based on Anticipated UsePhysical 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 constructSelecting 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

ReferencesReferences

• VHA Website:

• http://www.va.gov

• VHA HIA Website:

• http://www.va.gov/vha-ita/ita-p.html

• HL7 Website:

• http://www.hl7.org

• OpenEHR Website:

• http://www.openehr.org

DiscussionDiscussionDiscussionDiscussion

Designing Real-World Electronic Health Record Systems

Documents

Transcript of Designing Real-World Electronic Health Record Systems