using electronic medical record data for clinical workflow and analysis: a single center experience

A

T

t

h

v

Trrcrmrstt

ahvwtptuapdcsasehtl

t

EMm

2

N EXPERT ROUNDTABLE CONFERENCE BOSTON, MA, NOVEMBER 7-9, 2003

Using Electronic Medical Record Data for Clinical Workflow andAnalysis: A Single Center Experience

Mary Wagner and Beverly Collins

m

s

t

his paper focuses on the use of data from an elec-

ronic medical record (EMR) within a multi-facility

ealth care organization. It describes how health pro-

ider workflow is enhanced by extracting data from ©

taaotdpposlirdstt

cvateapyina

lc

doi:10.1016/j.jcrc.2004.09.003

34 Journa

ultiple sources in a near real-time fashion and pre-

enting it to the user in ways that are unavailable in

he electronic medical record applications.

2004 Elsevier Inc. All rights reserved.

he health industry today is focused on inte-grated electronic medical record (EMR) and

evenue cycle systems. Computer-based patientecords’ long-standing promise has been to in-rease efficiency and reduce costs. The expectedesult is improved quality of care. By extension,any of the efficiencies derived from electronic

ecords also help reduce errors and ensure patientafety.1 EMR systems are patient centered ratherhan department, management or financial cen-ered.

Allina Hospitals & Clinics, based in Minne-polis Minnesota, is a non-profit network of 11ospitals, 42 clinics and other health care ser-ices providing care throughout Minnesota andestern Wisconsin. Allina has worked with elec-

ronic medical records systems in both their hos-itals and clinics since 1993. While currently inhe process of replacing their legacy EMR prod-cts with an integrated electronic medical recordnd revenue cycle system that serves both hos-itals and clinics, Allina learned many thingsuring their previous experience. This paper fo-uses on Allina’s hospital EMR experience. Itpeaks to using a patient centered EMR for an-lytical data analysis, some common data pre-entation issues, and the need to integrate dataven when systems are not integrated. It explainsow Allina addressed these concerns and what itook, and gives some concrete examples of prob-ems and their resolutions.

From the Department of Information Services, Allina Hospi-als and Clinics, Minneapolis, MN.

Address reprint requests to Mary C. Wagner, MS, RNC,xcellian Project Team, Reporting, 225 S. Sixth St, Suite 1000,ail Stop 41020, Minneapolis, MN 55402; E-mail:[email protected]© 2004 Elsevier Inc. All rights reserved.0883-9441/04/1904-0007$30.00/0

ANALYTICAL DATA ANALYSIS—GETTING THEDATA OUT

Data in an analytical database is static, meaninghat the data is never (or at least rarely) modifiednd the information reflected by the database ispplicable to a specific point in time.2 The purposef an analytical database in a healthcare setting iso analyze and improve health care and healthcareelivery processes across a group of patients. Theurpose of the electronic medical record is to sup-ort efficient, effective, and safe patient care forne patient at a time. Designing a single databaseystem that optimally meets both purposes is chal-enging. The computer processing in each situations different and conflicting and often results inesponse time issues. For this reason, the EMRatabase and the analytical database often are twoeparate physical databases. Allina used both da-abases in conjunction for real-time data presenta-ion and analysis.

An effective EMR system needs to be patiententered to be efficient in its processing. Differentendors prefer different database technologies, butll EMRs are in their essence object oriented andhe primary object is the patient. They are veryfficient in processing data about that object. Thenalytical database is focused not on the individualatient but on answering questions and data anal-sis across a group of patients. The objects ofnterest are different. The data from the EMReeds to be transformed before it populates thenalytical database (Fig 1).

Planning and configuring of the EMR and ana-ytical databases need to happen in harmony. Keyonsiderations Include:

• Database content. Will both contain the samedata? This largely depends on the nature of thedata in the electronic medical record. Allow-ing free-form text entry of data gives individ-uality of expression when documenting in the
EMR. However, it limits the data’s value for
l of Critical Care, Vol 19, No 4 (December), 2004: pp 234-242

meacetdtrth

D

AitpuI

htotrstsdubaei

C

bvrcsbmmcd

AtlcpuotnidbS

PA

arA1o

ELECTRONIC MEDICAL RECORD DATA 235

analytical inquiry as well as takes up a lot ofspace in the database.

• Timing of data transformation from the EMRto the analytical database. This depends on thenature, purpose and role of the queries beingasked. To provide the greatest flexibility in theuse of the analytical database, the transforma-tion should occur as near to the time it isadded to the EMR as possible.

• Data Retention. There is a lot to consider.How pertinent is the data for decision makingover time? How quickly do queries need torun? Remember, the more data there is toprocess, the longer it will take to get an an-swer. Is there a mechanism to bring data backinto one database from the other?

Allina decided to use structured data (data thatust be picked from a drop-down list) in the EMR

verywhere except within notes. Note topics whichre structured are also brought over while noteontent is not. The data transformation happensvery five minutes. Data is retained permanently inhe EMR and for 3 to 4 years in the analyticalatabase. Every January, data is purged that ishree years old or older. There is a method toeload an entire patient record from the EMR intohe analytical database if the data is required butas been purged.

ata Presentation

In the course of the hospital EMR project, thellina EMR team was challenged to present data to

ndividuals and groups who need to see subsets ofhe electronic medical record data for limited pur-oses or at remote locations. The EMR product inse could not mix data time frames on one screen:

Fig 1. Data transformation.

&O 24 hour totals for the last 3 days, every four a

our vitals signs in reverse chronological order forhe last 2 days, abnormal lab results for the lengthf stay for example. It also could not secure data onhe field level. So, if the data entry person inespiratory care needed to see when oxygen wastarted and was in use for a patient but did not needo see the chart or even the entire respiratory flow-heet, the analytical database was used for alternateata presentation. And, because the mechanismssed for this alternate data presentation ran under arowser, these alternate data presentations werevailable on workstations that did not have thelectronic medical record product or were locatedn a remote location.

reating Integration

In the past, Allina had a tradition of purchasingest of breed products. The hospital EMR used oneendor’s product. The clinic ambulatory patientecord used another. Order entry, patient billing,hart abstracting, and on and on all used differentystems. There were times when the data needed toe pulled together either for presentation of infor-ation on one patient or for analytical analysis forultiple patients. Allina used the infrastructure

reated for the analytical database and for alternateata presentation to meet this need.To access multiple databases for a single report,

llina created an environment that emulates a dis-ributed database. Native report structured queryanguage (SQL) was wrapped in a C program thatonnected to each database using each native Ap-lication Programming Interface (API). Allinased APIs to connect to multiple databases insteadf ODBC (Open Database Connectivity) connec-ions because APIs reduce the number of compo-ents required to access the database, thus enhanc-ng the query speeds. This method of connectingatabases is limited to relational database products,ut has been successful with Sybase, Oracle andQL Server.

ersonnel Required for Clinical Workflownalysis

The alternate data presentations, reports gener-ted from multiple databases, and many frequentlyun analytical reports are accessed via the web.llina healthcare providers generate between0,000 and 16,000 actual web reports (not just hitsf the website) monthly. Physicians have anecdot-
lly said that the alternate data presentations can

shaiihc

imwqswcpwpLucaw

agaar

ke

ocdtmct

Rl

ioc

tptspila

236 WAGNER AND COLLINS

ave them from 20 minutes to an hour a day duringospital rounds. Clinical researchers save time inccessing multiple databases at once when review-ng a research subject. Managers of hospital nurs-ng units have better compliance when they can seeow complete documentation is on all of theirurrent patients with a single report.

The project is inexpensive. The only expensesncurred were in personnel. Although there areany report writing tools, Allina has chosen torite native SQL. This allows optimization of theueries for speed (most reports run in less than 15econds). The website uses Apache software (soft-are freely available at http://www.apache.org). C

ode is compiled using an open software utilityrovided by Free Software Foundation (http://ww.fsf.org). Screen presentations and printed re-orts use HTML (Hypertext Markup Language).DAP (Lightweight Directory Access Protocol) issed to connect to Allina’s Novell network se-urely while role driven table records within thenalytical database determine which reports andhich variables the user may request.Staffing for the initative includes a project man-

ger, half time database administrator and a pro-rammer with both C and SQL expertise. Twodditional SQL programmers create ad hoc reportss requested. Clinical data can be very complex toetrieve and assess. Programming staff must have

Fig 2. Real-Time anti-infec

nowledge of inpatient workflows for maximumfficiency.

REPORTS ILLUSTRATING UTILITY OF REAL-TIME AGGREGATE PATIENT DATA

Several examples of how Allina has resolvedrganizational issues using the analytical databasereated from the EMR are presented here. They areivided into two categories: reports requiring real-ime data, and reports requiring the linkage ofultiple databases. The key to success in both

ases is a fast response. Clinicians will not usehem otherwise.

eal Time Data (all reports run in 10 seconds oress)

1. Problem: One of the Allina hospitals had annitiative to reduce multiple and/or ineffective usef antibiotics with the outcome of better patientare at a lower cost.

Resolution: The hospital hired one of the infec-ious disease physicians that frequented their hos-ital to assist with this initiative. Also assigned tohe team were a pharmacist and clinical nursepecialist. Rounds were made daily by the team onatients who were currently on an oral (PO) orntravenous (IV) anti-infective agent totaling ateast 24 hours. If more than one anti-infectivegent was used, there could be no more than a

tive report by unit.

9aT

e PO to


6-hour time lapse between doses of the differentnti-infectives.he report listed (Fig 2):

• Patient name, identifier, bed• For each medication: medication name, time

Fig 3. Real-tim

Fig 4. Real-Time identifying patients at ris

of start dose, time of last dose given, hours onthe medication

• Total hours on anti-infectives if the patientreceived more than one

• Last temperature value and time

IV conversion.

k for hospital-acquired pneumonia.

ita

T

rn cen


• Last WBC and time• Last Creatinine and time• Cultures done—if there had been culture, a

drill down to the results was available

From this initiative, the hospital saved $248,000n medication charges. One hundred percent ofhe inpatient population was evaluated and staffnd time intensive processes were avoided.

2. Problem: Another hospital wanted to monitorthe compliance and timeliness of their IV to POPharmacy Conversion Protocol.Resolution: An aggregate report was createdthat lists patients currently on one or more of thefollowing IV antibiotics: gatifloxacin, ceftriax-one, azithromycin.

Fig 5. Real-Time newbo

he report listed the following (Fig 3):

• Patient name, identifier, bed• Medication name, time of first and last doses• If patient is NPO (nothing by mouth) and the

time placeed on NPO• Maximum temperature in the last 18 hours• Maximum heart rate in the last 18 hours• Other PO (by mouth) meds received in the last

18 hours? Yes/No• Criteria met? Yes/No; a “Yes” is displayed in

this field if the patient is NOT NPO and all ofthe other criteria are met.

3. Problem: Infection Control staff wanted areport so they could monitor those patients atrisk for nosocomial pneumonia more closely.Resolution: A report was created that lists pa-

sus by physician group.

tients in the intensive care unit (ICU) � 72

I

D

isit se


hours and on a ventilator � 24 hours and re-mained in the ICU or it had been � 72 hourssince discharge from the ICU. Links are avail-able to drill down to more specific informationin an individual data category.

ncluded in the report was (Fig 4):

• Patient name, identifier, bed. Drill down takesthe user to an individual patient synopsis re-port that takes information from a variety ofdatabases and displays the results seamlesslyin a coherent fashion.

• ICU admit time and length of stay in hours• Ventilator start, stop (if applicable), hours on

ventilator, last documented mode of ventilation• Last documented description of secretions and

number of times the patient has been suc-tioned. Drill down informs the user of thecolor, consistency, route (ie, endotrachealtube, tracheotomy, nasal)

4. Problem: Pediatricians and Family Practicephysicians requested a report that listed theirgroup’s newborns with pertinent data that wouldhelp them prioritize their rounds.Resolution: A report was created that allows thephysician to select their group from a drop downmenu.

isplayed in table format are the following (Fig 5)

• Bed, baby’s last name, sex• Last feeding method documented• Birth time and type (Cesarean Birth or Vagi-

Fig 6. V

nal)

• Age in hours at the time of the report• Birth weight, current weight, weight the day

prior to the current date• % change in weight (�/-) from birth weight at

time of report• Number of babies in the selected physician

group census• In addition, space was provided under each

baby for the physician to jot down additionalinformation.

REPORTS COLLECTING DATA FROMMULTIPLE DATABASES

5. Problem: Researchers for a hospital-basedheart program needed to access multiple appli-cations to gather study data or to wait until thepatient’s paper record was processed, request itand gather the information. Some of the dataresides in Oracle databases, some in Sybase, andsome in SQL Server.Resolution: A Research Report was developedthat accessed five separate databases with a sin-gle request: on-line documentation, transcribedreports, radiology reports, cardiac system re-ports and the Allina Data Warehouse. The re-searchers are able to look up patients by usingthe social security number, medical record num-ber, patient name and/or selecting current pa-tients from a unit roster. Once the patient isselected, a list of the patient’s visits is displayed.

lection.

This allows the researcher to select the visit they


Fig 7. Sample patient research synopsis.

TamMd

adi

TiI


want to investigate. The report takes between 20and 30 seconds to run (Fig 6).

he report generated is shown below. Hyperlinksllow for drill down to more specific data. Infor-ation comes from AIM (Analytical Informationanager), which is the name of the analytical

atabase fed by the documentation (Fig 7).

MEDICAL LOGIC MODULES THAT CONTAINDATA FROM MULTIPLE DATABASES

The Eclipsys application Sunrise Clinical Man-ger (SCM) contains Computerized Physician Or-er Entry (CPOE), rules and alerts (MLMs—Med-cal Logic Modules).

6. Problem: SCM has 2 types of alerts: 1) asynchronous rule that is generated with orderentry and 2) asynchronous which assess resultsas they are entered into the system and thengenerates the alert. Most MLM’s return a singlevariable, such as the latest potassium resultwhen ordering gentamicin. We wanted to makesure we were successful with both types of alertsas well as bring back multiple variables from theAIM database.Resolution: SCM has not been implemented atAllina, so for testing purposes, we used a testSCM database and entered a test patient into ourproduction AIM database. When deciding whatvariables to bring over for AIM, we wanted tobring over multiple variables from some of the

Fig 8. Synchronous rule: CT order with contrast.

largest AIM tables. In practice you may not wantthis extent of information returned, but we weretrying to maximize the challenge.

o test the synchronous rule, we entered an ordern the SCM system for a CT of the abdomen withV contrast. The alert ran in 1.125 seconds and

Fig 9. Synchronous rule: CT order with contrast.

Fig 10. Asynchronous rule: Elevated digoxin level.

wF

bldsa

Eaccifr

P


ould appear in the SCM application as shown inigures 8 and 9. The alert integrates 3 results:

• Last Creatinine level and time (from SCM)• Intake and Output totals for the last 2 days and

Fig 11. A synchronous rule: Elevated digoxin level.

the current day (from AIM) a

REFERENC

atient Safety. Health Data Management 2003, pp 34-40 i

• Patient’s initial weight, latest weight and thechange (from AIM)

We tested the asynchronous rule on a test patienty using a laboratory result (elevated Digoxinevel) from SCM and displaying it with pertinentocumentation from AIM. The alert ran in 1.109econds and would appear in the SCM applications shown in Figures 10 and 11. The alert displays:

• Digoxin and K� levels and time (from SCM)• Last dose given (from AIM)• Latest heart rate, rhythm, ectopy and time

(from AIM)

CONCLUSION

We believe that the reporting capabilities or ourMR achieved by using both the patient-centerednd analytical databases are technically robust andlinically meaningful. The challenge for the clini-ian is to vision the capabilities for clinical report-ng. The challenge for system designers is to trans-orm the clinical data into relational data on aeal-time basis. These two things in combination
re what make an EMR powerful.
ES

1. Bridges B: Electronic Records: Protection on the Road to
2. Hernandez MJ: Database Design for Mere Mortals. Read- ng, MA, Addison Wesley Developers Press, 1997, pp 4-20

using electronic medical record data for clinical workflow and analysis: a single center experience

Documents