Skip to content Skip to navigation

Optimizing EHR Implementation Through “Pre-Load Services”: Temple Physicians’ Experience

September 3, 2013
by Mark Hagland
| Reprints
Temple University Physicians turns to EHR pre-load services to optimize implementation

Temple University Physicians, a 400-physician (salaried) academic faculty practice plan whose members are faculty members of the Temple University School of Medicine, and affiliated with the Temple University Health System (TUHS), a four-hospital system in Philadelphia, has been moving forward on a number of fronts when it comes to electronic medical record/electronic health record (EMR/EHR) implementation. One of the areas in which Frank Erdlen, vice dean of information technology for Temple University School of Medicine and CIO of Temple University Physicians, felt the need for assistance, was in the area known as EMR pre-load services. He and his colleagues have been working with the Green Bay, Wis.-based IOD Incorporated to implement their services in the organization, in order to optimize EHR/EMR implementation.

Erdlen spoke recently withHCI Editor-in-Chief Mark Hagland regarding the need for pre-load services and what he and his colleagues at Temple have been doing recently. Below are excerpts from that interview.

What are EMR pre-load services?

Temple University is the organization that Temple University Physicians, the faculty practice plan, lives in. And most of the physicians are clinical faculty members with significant teaching responsibilities.

And we’ve been implementing the Epicare System from Epic [the Verona, Wis.-based Epic Systems Incorporated]. TUH and Episcopal Hospitals don’t have an EHR, but are beginning to implement Epic; and Jeanes Hospital and Fox Chase Hospital use Soarian [from the Malven, Pa.-based Siemens Healthcare].

We’ve been live since January 2012. So we brought up 100 practices in about 13 months.

So tell us about the need for pre-loading in situations like this?

Yes, we brought up over 100 practices in 12-13 months; and we have a staff of 38 people. And this is an important consideration, from a CIO perspective, since we had been using paper medical records. So we needed a way to be able to pull forward the key clinical information for established patients, and populate the EMR with clinical information; and that’s what IOD helped us do. So the high-level description, and we can drill down on any piece of this, is that we worked with our physicians and had them identify the information they felt was most important for them per patients, as we brought them up on Epic. And some of that involved scanning, taking certain kinds of reports and certain progress notes from the paper record, and scanning those into the Epic system to be available to the physicians.

And there was some other information they wanted in a discrete fashion, just as scanned documents. The discrete data—things like allergies, medication lists, problem lists, immunization lists, needed to be taken from the paper record and typed into Epic. You can use a medical record clerk to do the scanning work, because they understand what’s in a record and can be taught how to index that information in the record. For abstraction, you need a little more skill; and most organizations would go to medical coders for that purpose.

So it was really a two-part process: the first would be documents that would be required by our physician advisers… We had a group of physicians, champions…  Documents required by our physician advisers would be identified in the chart. So they would take the documents identified by the physician advisory group, find them in the chart, take them out of the paper chart, scan them into Epic, and would index them. It was people from IOD who were credentialed HIM [health information management] professionals and RNs. They go a bit beyond what a coder would be doing in terms of expertise: data integrity and increased efficiency, are very important.

So that happened first?

Yes, and then once the document scanning was done, these higher-level folks whom Dori described would go in and identify the discrete data—again, allergies, problem lists, diagnoses, immunization histories, medications, and would actually enter those into the appropriate place as a discrete data element in the Epic system.

How long did that whole double process take?

Our initial go-live for our first set of practices was November 9, 2010—that date is etched in my brain. After we did the haggling to get the contract terms executed, IOD was able to start their work three weeks before then, mid-October. The goal for us… we had an implementation cycle pretty much every month that included anywhere from four to six more practices, so we rolled this out over 13 months, so we had a schedule that had multiple practices scheduled to start using Epic each month. So we used the patient appointment scheduling system to let us know who was coming into that practice, so we knew what paper records to pull to let IOD do their thing.

So we tried to maintain a two-week window, a two-week cushion, so IOD would be working on inputting data into the EHRs at least two weeks in advance. And we said we would do 12 months of this work for each practice, and we figured that would cover at least 80 percent or more of their established patients, based on estimating that people would come in at least once a year. So this process was completed by October 2011. And it was completed.

And basically, everything ran smoothly?