FierceHealthcareFierceHealthITFierceHealthFinanceFierceEMRHospital ImpactFierceMobileHealthcare   FierceCIO

Epic's Faulkner steals the show at CHIME

Tools
Tags
data exchange
College of Healthcare Information Management Executives
CHIME 09
Systems Integration
Kaiser Permanente
Judith Faulkner
interoperability
Geisinger Health System
Epic Systems
David Blumenthal


Dr. David Blumenthal may have been the featured speaker at last week's College of Healthcare Information Management Executives Fall CIO Forum, but he wasn't the most sought-after attendee at the meeting in Indian Wells, Calif. No, that honor would have to go to Judy Faulkner, founder and CEO of Epic Systems, the Verona, Wis.-based EMR vendor that's celebrating its 30th anniversary this year.

As a company, privately held Epic tries to keep a low profile. It doesn't issue press releases or tout its contract wins, even though it's landed some huge customers, most notably Kaiser Permanente. Look for executive bios on the company's website and you'll be disappointed.

That image belies the fact that Faulkner is an outsize personality. She may shun the spotlight, but run into her at a meeting and she'll happily chat about her passion, computerizing medical records--highlighting the accomplishments of Epic customers rather than the company itself.

Faulkner was true to form at CHIME, holding court for a rapt audience at her table during an informal networking luncheon, then later taking some time to sit down with FierceHealthIT.

Faulkner clarified some rather eye-opening comments from earlier this year about the problems with interfacing systems from multiple vendors. "It doesn't work when you mix and match vendors....It has to be one system, or it can be dangerous for patients," she said in an April 23 BusinessWeek story. She was referring to compatibility issues between an Epic computerized physician order entry application, and another company's pharmacy database that caused multiple errors in a psychiatric unit at Geisinger Health System in Pennsylvania.

"It is difficult to do a good meds reconciliation if you have different information coming in," Faulkner explained to FierceHealthIT. "You need discrete data to trigger alerts."

Indeed, discrete data--or, more specifically, the lack of it--is one of Epic's toughest challenges, as the EpicCare EMR can contain somewhere in the range of 100,000 data elements, and competing systems have similar complexity. "It's taken years to standardize a few of them," Faulkner notes. "It will take ages to do them all." And until that happens, interfacing systems will remain a time-consuming proposition.

It is partially for this reason that Epic won't sell a free-standing pharmacy or ED system, Faulkner says, though she notes that Epic does not offer a PACS and thus must help each customers interface with another vendor's imaging repository.

This also explains why health information exchanges have been fairly limited to date. While there are standards for patient summaries such as the Continuity of Care Record and Continuity of Care Document, "Clinical summaries don't trigger discrete things," Faulkner says. They simply provide a summary that each new recipient must manually act on. With health information exchange, Faulkner adds, "You will either have to deal with discrete data or use in read-only mode."

And thus the quest for interoperability continues. - Neil

Bookmark and Share
Get Your FREE FierceHealthIT Email Newsletter:
Comments (7) | Post a comment

Comments

Oh my... another propaganda piece. Kaiser had to pay Epic to change its EpicCare product so there would be two separate fields for the drug dosage and drug name (until then they were both in 1 field). Mind you, this "change order" was placed in 2004 or 2005, so think about how dangerous the ASCII sort of said drugs would have been for any provider to choose the correct dosage.

Also, one of EpicCare's biggest criticisms in medical informatics circles is its utterly unstructured data in "notes" (where much of the data about any encounter is entered and stored) as well as EpicCare's lack of using structured terminologies/vocabularies.

Finally if want a glimpse of a wildly dangerous place to get care, try googling "sentinel event" and "Kaiser Santa Teresa". The body count really added up fast there. Guess who their vendor was...

Another tired refrain from an EMR vendor on how it's all got to be in the same system sharing the same data bases...Never heard of HL7? I watched my own former company cook the books to go with the Cerner ED system - ignoring the obvious flaws and touting how it will all be integrated - because ..."it's all Cerner and First Net will be completely integrated..." Just made the patient management system slower - Never had a downtime Solution - except an archaic - read-only snap shot - Epic sells their own proprietary - interface application - Same as Cerner - Don't they know of the advances in system integration in health care...yes they do, but they want the whole pie...unfortunately to many CIO's and application directors don't really want to do the work and understand how things work and should fit together - it's easier to to echo the Vendor line and not take responsibility for the product the hospital delivers . With the advances in integration platforms and the maturing of SOA concepts - any health-care organization that allows it self to become vendor dependent is doing a disservice to it's patients and the organization.

Why are so many folks interface phobic? A modern health-care organization should architect it's systems with some systems tightly integrated and some systems loosely integrated - based on systems and care delivery options - it's not more complicated, it gives better options - and it's best of all - cheaper...

You clearly have never tried to achieve "interoperability"... we have 3 EHRs (Inpatient, Outpatient and Physician group) as a best-of-breed shop. It's not just about HL7 interfaces. The EHRs used different drug reference databases (not consistent), reference labs (no LOINC codes), data must be bi-directional from all EHRs to all other EHRs, Outpatient EHRs don't want all Inpatient information (just the "relevant" info...), and I could go on and on.

It's not just about pushing all data everywhere. Physicians do not want data fatigue - they want the same meaningful roll-up of data that they would see in their own EHR (discharge summaries, clinic notes, etc).

After years of working on this, there is no way I believe that this option is "cheaper". It is a huge fallacy that needs to be evaluated in your total cost of ownership. I agree with Judy, on a more vendor agnostic level. What you lose in funcionality in having one vendor who can't do everyhting perfectly, you gain in integration. I used to be a Best-of-breed snob, but I've changed my thinking.

Sorry to disagree - I'm not a best of breed advocate - I'm an advocate of whats best - And I clearly have worked on interoperability - but you'll need to differentiate between interoperable and integrated. Loosing a little functionality to achieve a better integration is fine - heaping more apps - whether they work together well or not, is another. I don't think I want Judys' mumps coders working on a bedside - bio-med system - simply to avoid an interface - Too often - the vendors claims far exceed their reach - but if you buy the line - it's part of our system so it will be integrated...well I guess there is one born everyday - and "oh too bad about the patients that got sicker because the integrated system wasn't really"...)
In your stated example you say you have 3 EHR's - sounds like you have 3 HIS systems dedicated to different areas of Practice/care. I could question the reasoning for that - would not be the best approach if you had designed from the beginning. However I know how that sort of thing happens, unfortunately you are relaying that you have looked at interfaces to solve poor design decisions. Which is all to often the case - "Uh fellas we decided to keep this system and get this system and you'll have to make it work..."( and the comment about pushing all data everywhere...please any decent 2nd generation interface engine can handle and transform discretely - most all the issues you raised) without mentioning Web Services and query and control integrations with DB to DB transfer)

If you pay vendors to build you ill conceived point to point or limited hub and spoke interfaces with the vendor calling the shots - it can be expensive - But a decent integration team with a couple of decent integration products will consistently be cheaper - short run and long run - will give you more future flexibility and better options. I've done it, can prove it - so it's not a fallacy. The point is simple, design with some thought, don't put everything in the vendor's lap - and hold them accountable to the standards.

It's one thing to get wiser another to just get lazy and let the vendor do it...

You heard it from Judy, Epic is anti-interoperability. The problem is that even Epic cannot interop with another Epic installation. It is all about profits, not patients. Funny that the nation's pharmacies have figured out how to manage all their customer's prescriptions. Epic is why the $18 billion in stinulus funds for archiac EMRs is a mistake. Take the money and build a national EMR system that is paid for once and made freely available. Stop wasting patient dollars on outrageous profits for these obsolete EMR products. Patients are paying over and over for little that benefits tham or an integrated national healthcar system. Take a look at the palatial digs that Epic has built in Verona with scarce patient dollars..

EPIC = the next bubble? EMR bubble? how can a 300 bed hopsital afford 120 million?

The elephant in the room here is the economics of interoperability. We have managed to get the WWW and email to work quite well, why not medical records? Ask yourself who benefits from interoperability, and perhaps more importantly, who loses?
The answer to this question might explain why progress has been so slow in Health IT.

Post new comment

The content of this field is kept private and will not be shown publicly.

More information about formatting options

To combat spam, please enter the code in the image.