Shared publicly  - 
Epic Systems Highlighted in NYT Article

Epic has certainly grown dramatically with 5100 employees & wants to add 1000 more this year. Ten years ago they had 575 employees. They have a total of 260 large customers (like Kaiser Permanente since 2003), including 35 new contracts last year. They claim their systems will cover 127 million patients with active electronic health records by July 2013. They have built an incredible 5,000-square-foot data center among the other interesting components of their new campus.

But there are a lot of complaints about interoperablility and their walled garden approach to electronic health records. I think Ms. Faulkner's claim that privacy is the primary cause for difficulty in sharing data with Epic systems is a bit fallacious. I believe there are more technical barriers than policy constraints in most cases. What do you think?
Chris King's profile photoBingyang Li's profile photoVille Oksanen's profile photoVille Hautakangas's profile photo
I do have to give them HUGE kudos for their work on the Direct Project (Janet rocks! :)
Definitely Tech barriers exist -- starting with the fact that it isn't exactly easy to discretely transfer data between disparate systems. That said, with Epic's CareEverywhere product, separate Epic sites are able to transfer patient data (like in MN: But even for Epic to Epic transfers, by far the longest and most time-consuming part of the process are security/privacy/legal concerns expressed by compliance and legal teams at health systems and not the actual technical infrastructure or connectivity.
They also have a "Care Elsewhere" set up for transfer between Epic-non-Epic sites. Sounds like OCHIN might be using this to exchange with AllScripts based systems (
There is definitely room to grow to make interoperability easier, but at the same time, peeling that onion is easier said than done! :-)
You raise some great points +Krishna Ramachandran. But by only allowing exchange using the the CareEverywhere (everywhere there is Epic :) and CareElsewhere they do seem to be promoting a walled garden approach... I'd be interested in hearing how difficult it may be for interfaces to be set up to third party HIE vendors.
Always love a good puff piece... I'd actually been working on a post about this after seeing it last night....

It's strikes how the revisionist history is beginning to seep into Epic's narrative. The biggest re-write? Judy Faulkner, known far and wide for her views on health IT "interoperability", generally meaning "interoperability amongst Epic modules", as opposed to "interoperability amongst others in the healthcare system who may or may not have Epic". When we look at the whole of what Epic seems to be up to, it seems like the copy of the article is right out of Epic's PR department.

For instance take Faulkner's statements to Bloomberg News in 2009 that sharing medical records "doesn't work when you mix and match vendors. ... It has to be one system, or it can be dangerous for patients...", cited in a Washington Examiner about her curious appointment to the Federal health Policy comittee:

The statement was also cited in an article, quoted by +Neil Versel from a BusinessWeek article, regarding Geisinger's woes with an Epic pilot, where full implementation of Epic was put on hold because of trouble ultimately traced to incompatibility between a common pharmacy database and Epic’s system.

I do give Epic a lot of credit for their work advancing the state of the art in health IT, but let's be honest about it... they are not necessarily in it for the good of the patients nor the system.

They are getting major adoption in the places where arguably the bulk of healthcare happens, in the ambulatory settings. This is knowledge, thanks to open approaches to sharing data, like CMS' attestation data you, yourself +Brian Ahier have been so deftly sharing:

... Great competitors, or preferential treatment? You Decide...
Interesting detail of the politics and "follow the money" can also be seen in the Washingtoon Examiner article I cite above:

"Since Obama's accolades and Faulkner's appointment to the policy committee, Epic has received a $14 million contract to implement new electronic medical record software for the Coast Guard. It is also vying for a contract for a massive expansion of the Veterans Administration's electronic medical records.

The VA is adamant that the resulting system be open source and interoperable, but five members of Wisconsin's congressional delegation recently wrote a letter to the VA's chief information officer stressing the importance of single-vendor electronic health record systems -- i.e., the type that Epic provides."
Now set it against the backdrop of the VA, VistA and OSEHRA, the new custodial agent which is workign to create an open source community around improvign and supporting VistA. The VA could be considered the most important pioneers of health IT, and the new OSEHRA project, truly turning VistA into an open source project and a viable Government-wide EHR for all of the stakeholders who need it (Military, Dept. of State, etc.), creates a viable competitor and Epic knows this. Otherwise why would the do whatever they can to torpedo it? In a Marcher 2011 article on by Bob Brewin on, brought to my attention thanks to Open Health News and +Roger A. Maduro:

"Five members of the Wisconsin congressional delegation asked the Veterans Affairs and Defense departments to consider using a single commercial system for their new electronic health records, a move that could benefit one of the state's largest employers, software company Epic Systems Corp.

VA said it plans to stick with the open source approach it announced last month, but experts say the lawmakers' query could potentially delay the new system.

In a Feb 7 letter, the lawmakers asked top executives of the two departments if the benefits of a commercial system had received "appropriate consideration" in the modernization and integration of their electronic health records.

"Some experts believe that commercial EHRs show significant potential to provide a state-of-the-art replacement quickly and at a reasonable cost," wrote Wisconsin's two senators, Democrat Herb Kohl and Republican Ron Johnson, Republican representative Paul Ryan and Democratic representatives Ron Kind and Tammy Baldwin, whose district includes Verona, where Epic has its headquarters.
The letter added that single-vendor EHRs help protect patient safety by using one consolidated database. A commercial approach also could cut development and installation time, said the letter, which was addressed to Roger Baker, VA chief information officer, and George Peach Taylor of Defense."

I think the whole thing raises questions, and it strikes me that the NY Times article is just so much PR puffery as to not warrant the ink nor electrons of which it has been rendered.
I'll let you know later this year. We'll be implementing an HIE and have a community partner with Epic that will need to feed the HIE. This should be interesting.
I can appreciate that, but talking about what? I don't think an unresearched article does any justice to the conversation, especially an article with such a slant from a respected publication like the +New York Times

It's almost as if Milt Freudenheim avoided doing any research. It borders on contradicting anything that people who are actually work with Epic, as a company or as part of their workflow, will tell you about their experience. I know that Epic has their fanboys and girls, but come on... Really?

I'd be interested to hear what +Neil Versel thinks of the article. Hopefully he'll pipe up eventually.
The article says it draws programmers that might otherwise take jobs at Google, Microsoft or Facebook. I can't imagine there are many of those. Let's see, work on MUMPS in Wisconsin or some newer technology in the Bay area. Yeah, I'm not seeing many making that choice.

I also love that it says that Epic is sharing data with other systems. I'd love to see examples of this. I hear that Epic will have a spot in the interoperability showcase at HIMSS. Maybe we'll find out more there.
Yeah, it's complete BS, just read Glassdor reviews for about 2 minutes and remove the posts from the shills...

It's well-know that it's a dead-end from a tech perspective. Epic want's to pretend that it looks like Google to outsiders, but it's farcical to even suggest it. It's a big reason why I think the article is disingenuous at best.
I was going to write a post but apart from all the good things about Epic, the 4 things Milt Freudnehim doesnt know that would have made a balanced article
1) technology is old and laughable outside HC (MUMPS or Ruby on Rails--you be the judge)
2) Competition is pathetic (Cerner is the best.....McKesson? IDX/GE? pah)
3) Buyers are America's dumbest corporations (hospitals) who like overpaying and overcharging. (The West Virginia story referenced in the last goog+ chat here is very true)
4) Epic doesnt even interoprate with Epic & there;s no such thing as a standard install, My daughter's pediatrician in the Sutter System has Epic--NO Consumer access. Whereas at Palo Atlo Medical Foundation, which is Sutter AND has Epic, you can view your own record. Do you really think you cold move data from one to the other? Where;s the Blue Button?

I guess the sad thing about American health IT is that this -- so far-- is the best we got
Ahier has it right, this is a puff piece for the general reader. For me, thread is a much more interesting read. Patient record security is the most tangible and therefore the most emotionally powerful area to write about for the general reader. Helping the public understand the benefits of sharing medical information is tricky and the primary aim of the article is to introduce Epic as a major player in the EHR ecosystem.
I'd have to second +Matthew Holt 's comments. How much did Northern California Kaiser go over budget on their Epic implementation? $3 billion? Epic has the big dumb hospital/foundation players by the short hairs and is milking it for all they can. And they have no intention of playing nice with other technologies or even their own kludgy systems.

Of COURSE they argue that monopoly is the only valid solution... just like a privately-held corporation with a highly proprietary, closed-source solution should.
Interesting side note: Judy Faulkner stated is 2002 that the company motto is ""Do good, have fun, and make money." ( Not a bad slogan, and they are certainly achieving the third part...
btw - +e-Patient Dave deBronkart reminded me of this classic talk he gave in 2010 which applies somewhat to this conversation:

“Over My Dead Body”: Why System Usability Matters

"It’s widely rumored that a health IT industry executive was unhappy about suggestions that systems have to be usable in the eyes of employees who use them while caring for us. (Us. The patients. Your mother.)

According to the rumor, the exec said “Over my dead body.” As if s/he ran the agency.

Whether or not the rumor’s true it’s not funny. So when I was asked to represent the patient perspective in a keynote June 3 in Washington (details below), I used that phrase as my title.

Here are my slides, with a few changes to make it work better standalone. (If you’ve seen my talks before, skip through the familiar slides.) The “dead body” part starts at #48."
Brian - - Epic did truly great work on the Direct project, not just Janet, who totally rocks, but also Vassil. The article is wonderful as a puff piece. It's nice to see success, but it remains to be seen if an ascendant enterprise data service can remain relevant when the next disruptive paradigm takes over (e.g., see Matthew and Vince's comments). As the operator of an HIE service I can attest to that giant sucking sound of electronic patient data disappearing from the community when a facility migrates behind the Epic curtain. It's just too quaint how Epic pretends that unsolicited push messages that originate outside of Epic do not exist in the clinical data workflow. On the other hand, it is not impossible to interoperate with Epic data, just difficult. Our HIE does a bit now, and with some excellent help from Epic we are gradually re-establishing the types of interoperability that disappeared from the community. With regard to making progress on the ground, patients and clinicians need access to data whether or not EHRs cooperate (i.e., Epic is not the only EHR vendor to obfuscate interoperability). And to give Direct credit where it is due, I think Cerner (especially Greg Meyer) has been amazing at pushing the Direct Project into production.
To be clear, I've never found an on the record "over my dead body" statement. However, the May 19, 2010 HIT Policy Committee meeting does have a discussion on usability in which Judy says:

"To me, there’s a morphing from the original purpose of the group, which was the three workgroups for HIE, meaningful use, and adoption and certification. What I think there appears to be a slant, as I read this, and I am nervous about it and worried about it is that it’s morphing a little bit into potential committee, government control of the development of EHRs. I think we have to decide. Is that accurate or not accurate? Is that what you want to do or not, and make it clear which direction.
In looking at some of these, I think, such as in the first objective, 1.1, it says enhance the – and included in there is the functionality and utility. Functionality, if in fact this is interpreted to mean that the functionality of where electronic health records go is going to be defined through this process here, I get really worried that it won’t be as good as leaving it to the open markets to define functionality because any small group, rather than thousands and thousands of pieces of feedback back that’s going to influence each vendor’s decision of what do I have to do next is not going to be, in my opinion, as good.
As I read through it, there are various sentences in here that could easily be interpreted that way. I just feel that it leads us to a dangerous thing because sometimes I see people who want their job to be, I want to define what the EHR is going to be, just an individual. I think it’s interesting because I say, okay. And what will you do for the other 360 days of the year because, within just a few days, you can keep the vendors busy for years. And so my worry is that if in fact this becomes heavily the functionality definition of what’s going to happen to EHRs, there may not be time left to do anything that’s coming from the users themselves in addition to what is here, and I think that has to be addressed and handled."
Thanks +will ross for reminding us of the other unsung heroes of Direct :-) I'll be very interested in seeing what Epic demonstrates at the interoperability showcase during HIMSS this year...
Indeed, +Brian Ahier I usually like to pull out that "alleged" statement referenced in the following, but it's didn't seem germane to this current Pollyanna view of Epic under discussion, but on second thought...

"From Tabula Rosa: “Re: EMR usability. At one of the ONC Policy Committee meetings, [founder and CEO] Judy Faulkner of Epic supposedly declared that ‘usability would be part of certification over her dead body.’ I wonder if she has similar sentiments about making software accessible to people with disabilities?” Unverified. This inspired my new poll question – keep reading below. "
As an interesting aside, check out how Epic works to make a Las Vegas-like experience at their HUGE campus with the funds that COULD be allocating to improve the underlying technology and interoperability of their system...

You could argue that other companies have many similar trappings as a tool for attracting talent, but most of those others are not building software that is so intimately tied to life and death decisions.
+Nathan DiNiro I agree with you, but the argument could be made that we need the trappings to attract the best talent because we only want the best developing software tied to life and death decisions. But then one could counter, do we really want our best spending time on such archaic architecture? Hmmm...
After decades of solving, and trying to solve, interoperability issues, primarily by getting small entrepreneur companies medical devices and clinical software to work with the large corporations applications and/or platforms (e.g., Epic, GE, McKesson, MEDITECH, SIEMENS); I came to a conclusion that unless an outlier (as per Malcolm Gladwell's "Outliers" definition) arises during 2012 we will have simply wasted a ton of tax payers money ($19 billion) and simply end up with more robust monopolies in the healthcare IT space.

Try a simple exercise by calling any these companies and tell them that you simply want to integrate your X product with their Y product. Contact me in a year to let me know about your frustration. Yes, it can take over a year to get any simple integration with any of these companies products.

No matter how much HL7, DICOM, IHE, or whatever new story is out there that you know and use, it is almost impossible to get anything done in a reasonable amount of time due to the unintentional existing red tape. Believe me, all these companies have invested huge fortunes in solving the interoperability riddle. They all participate in the standards committees, have departments devoted to solving this while spending hundreds of millions of dollars combined.

The arising outlier is not yet in his/her thirties, according to what I have read in Malcolm's book, so it's probably not many of you nor me. It's neither an outlier of the past. We have just witnessed one of the biggest succesful software companies of the world say "Take this job and shove it! I ain't working here no more", that is they ain't working in Health IT no more. But then are we ending up with a very interoperable company? Who will they be interoperable with? The products they purchase and put under their huge umbrella?

Interoperability is too big of a mess to fix! Everyone has tried and success has been meager.

Now, who created the interoperability riddle? The answer is the same one that is pouring $19 billion dollars to make it just more complex than what it is.

Maybe the interoperability riddle is good for the economy. We are adding tens of thousands to the HealthIT worforce to make it more complex and cumbersome.

Love it +S Silverstein!

"Details on contrary strands of evidence that could reasonably have been expected to appear in evidential text are absent."

Out of curiosity, have any of you visited, a new service for the creation and storage of advance medical directives? It is completely cloud-based, so it is EMR platform agnostic, and following up on the insightful comment by +Vince Kuraitis , there would seem to be no system more patient-centric than one like MyDirectives that focuses on end-of-life medical treatment (many would argue that this is the only part of an EMR that has any relevance whatsoever for the largest majority of the population) and that is interoperable with any EMR/EHR/PHR system. I'd be curious to know everyone's thoughts . . .
While these numbers aren't perfect due to some duplication in the raw data from CMS (which I'm still trying to get my brain around) there is no doubt that Epic is still behind Cerner and Meditech in the number of hospital EHR Incentive Program attestations. This is only in number of attestations so I have a feeling due to the size of their customers, in actual dollars Epic is leading. Epic is bar far the leader in number of ambulatory attestations.

I love data :-)
Joe got it mostly right, but the data was released on behalf of CMS and ONC by the OSTP in the Whitehouse. There is actually no report from ONC, just raw data on
It seems like just about everything that can be has been said about Epic in this great stream, except, perhaps, that they're doing so well because they do precisely what their customers want them to do, and for the price their customers are willing to pay. They are not reforming health care, improving care coordination, or championing interoperability, because those are not the tasks they are being "hired" to do. What they're doing is delivering a product that is dependable and improves incrementally year after year, and that is making a lot of money for their customers based on the payment system(s) we have in this country. If and when there are business models that turn a profit on lowering the costs of health care while improving quality, rather than increasing utilization, I'd bet that Epic would figure out how to be successful in that market, too. The technologies are quite ready and available to help provider organizations improve productivity and lower costs dramatically, but there is absolutely no reason to deploy them if it will lead to lower revenues and profits to one's health system, hospital, pharmaceutical or medical device company, or medical practice.
David, I would respectfully disagree, and I would say that it's quite the opposite.

Epic dictates who can buy and how things get implemented. Here's just one example, albeit from what the author of the article proclaims is a "rumor mill". However, it's a story which gets told over and over, and forms some of the basis of my position that the NYT article is PR puff. I can personally attest to knowledge of their tactics from an extremely good source. I have been sitting on the evidence, but perhaps it's time i do that series of posts bringing their other anti-competitive activities to light.

'From Mavrikg41: “Re: Epic. [hospital name omitted] was rejected by Epic in the evaluation process because Epic thought [CIO name omitted] was ‘going to get in the way of the success of the implementation.’ They called that out in the report to the hospital’s executives as to why Epic would not be a good fit at [hospital name omitted].”'

I can go on...

Anecdotes from folks like this abound. Of course, since Epic preempts any expression of anything which calls their system or expertise into question, I look forward to the day when actual customers, consultants and users felt they are able to express the truth without fear of legal action.
It's a free market and Epic has done well. They are obviously selling something that their customers want...
I'm just curious: how many people posting here have i) used Epic to care for patients, ii) been deeply involved with an Epic build/installation, iii) have tried to use Epic to facilitate critical reporting tasks that support billing for the various parties that need to get paid in the course of providing health care or support administrative oversight?

My guess is that those 3 filtering questions have likely narrowed this list of posters down to maybe 2 or 3. Anyone who has done all 3 of the above and knows something about technology architecture, database design, UI design can only conclude the following: Epic's data model is unwieldy and difficult to navigate with significant consequences for critical administrative and clinical reporting tasks, the user interface is kluge and unnecessarily complicated, the pre-built clinical content is mediocre despite having many clinicians work on the product, data bleeds across encounters in unimaginably stupid ways, the application is buggy even now despite so many patients and likely billions of clinical encounters. Net net, the utility obtained by having digitized records in Epic appears to be far below the cost of implementation, deployment, and support.

And that's the unfiltered truth.
+Ram Duriseti and +Nathan DiNiro make good points, and I know there are many Epic users who are unhappy, especially physicians. A friend, not a physician but an administrator, left a dream job after less than a year because she was so unhappy with the health system's choice of Epic and the difficulty it caused her day after day. But this dissatisfaction notwithstanding, Epic is definitely delivering value to the decision makers and major stakeholders in the organizations that have chosen to buy and use their products. I can't be disparaging about a company that is as successful as they have been and continue to be, even if I believe the underlying economics and morality of the system that creates the demand for their products is corrupt and wasteful. To people outside health care, Epic's success is probably an indicator of the "progress" health care is making in computerization, which was the tone of the NYT piece. And I do think that Epic's leaders and most of their employees are smart and experienced enough to be able to offer disruptively innovative products should there be a change in health care financing that would reward such innovation. In fact, I think they might be able to lead that innovation, given the eminence of their large health system customers around the country.
Yep, just like McDonalds and WalMart, Brian... or CountryWide and the mortgage giants and financial industry, eh? MU feature/function certification should be enough to insure that the system is safe, right? I mean, if the data is "right" in terms of billing Medicare, then it's a safe enough system to insure that it won't affect patient care negatively?

Markets, as we've so painfully been reminded, are based on trust. If, due to health IT's complexity, I am forced to trust that the systems selected by my provider to manage my care are built by trustworthy organizations, and that my tax dollars are being used to subsidized their acquisition, shouldn't they be compelled to be transparent and act in my interests?
+Ram Duriseti Put me in the "recovering Epic consultant" column. What's worse is that, because I have to feed my family, I spend a fair portion of my days feeling dirty as I recruit talent to work on largely Epic community connect implementations. And believe me, I wouldn't be doing if I didn't almost become homeless trying to advance the cause of openness, transparency and interoperability. Unfortunately, our society is being continually conditioned to believe that the markets, unchecked, are the savior of anything and everything which ails us. Considering what I do for a living, my positions could be considered heretical and career-limiting, and I make no apologies to anyone for having them.

+David C. Kibbe if you knew the truth about how broken their system is, and how perilously malignant the company is in it's operations and behavior, you might take a very different position. I mean, if I told you that they utilize many of the same and even more egregious tactics that MS was found guilty of in terms of anti-competitive behavior, what would you say?
+S Silverstein Considering your position on the untested and experimental nature of the current state of the art in health IT, I'm curious about your position on the VA and VistA. They have over 25 years of experience utilizing VistA, and there is literature which suggests they have managed to control costs and improve patient care. Is their example relevant in the context of their "single-payer" system as opposed to the public fee-for-service based system?

I'd also say that we should consider what's underneath the surface in terms of driving health IT and meaningful use... and economic stimulus act which was intended to spur economic activity, not necessarily improvement in healthcare. While we can dress the activity in systemic improvement clothing, it's still founded in policy driven by a desire to create jobs and instigate spending. While I stand with everyone else here who hopes that it will improve the system, but the laws of unintended consequences are surely at work, and the scientific scrutiny you suggest is most certainly a barrier to the race to meet MU.
+S Silverstein Let's not even get into "putting the system on trial"... ;)

For further fun, check out this Ignite! Government session I hosted at the Government Open Source Convention 2010... Lou is an interesting guy, and has an interesting point about simplifying the law... but I digress :)
I had meant to ask before as I'm curious; who sent you the comment and why didn't that just post it here?
Apparently posting an anonymous is a REALLY dumb thing to do... Oh well, at least we got don't pretty interesting discussion.
Absolutely, it's a conversation that I think will be ongoing.
1,000 new hires? I sure hope those folks are about services to installed customers. It's hard to imagine how Judy and Carl could get "their patient tally" a whole lot closer to 300 million.
Well, yesterday I was being a litlle facetious about interoperability in general since it was a one of the topics of Epic's success thus far.

Other than simplistic integrations with Epic via Clarity I have yet to see anything significant being shared between Epic and other source systems. Maybe I haven't yet been exposed to an integration challenge that will force me to further deepen my experience. Also, in any integration project with Epic one of the biggest challenges is to find someone that understands Epic. Most customers have vague understanding of it and most self-claimed experts would always respond with uncertainty and ambiguity of how to solve an integration riddle.

The previous paragraph brings me to today's comment on the other major topic of the NYC article: the growth and hiring of 1000 more people.

I guess they can hire people, that's not a problem, what I find difficult is for them to hire healthcare IT specialists, needless to say is to hire healthcare IT specialists with Epic knowledge.

Healthcare IT specialists were a rare breed even before the HITECH bandwagon started rolling. Right now we are even scarcer or stretched out to the point of ripping into pieces.

Also, Epic has created its own barriers in being able to grow with ease. I recall that a couple of years ago I wanted to learn more about integrating with their products and they told me that they only trained customers and not consultants. So, they missed out on preparing a resource for the near future, the NOW.

I find it very odd that in an era of Internet openness where most companies openly share their knowledgebase that a company in healthcare IT would be so secluded and restrictive.

Finally, where can they obtain the 1000 qualified people they need to meet their growth agenda this year? From their customer base? From ex-employees?

I get approximately 15-20 daily requests from desperate recruiters seeking Epic specialists.

If they decide to train the new hires when would these be ready to perform as effective consultants in the field?

Sorry folks, but there is no growth strategy in place. It's just hot air.

The more I think about it the more hogwash the article appears to be.

With the health IT market the way it is shaping up 1,000 new employees is going to be tough to find...
Often we over focus on the technology and miss the business case (thanks David Kibbie) and the profound impact that organizational culture an even change management plays when we implement a new technology. Is it an electronic pencil or a transformational tool? Does it save lives or drive us into the wall faster? Is it Epic that fails to play nice with its neighbors or merely the identified patient in a dysfunctional health care system?

As a former Epic Implementation consultant at Group Health (the only EHR where we gave patients read write access FIRST before our providers), Sutter Health (strategic plan) and Stanford who now works on patient centered design (multi-state ONC funded Direct project) the culture and business models are often the real drivers behind EHR interoperability.

This is hardly a new topic of discussion as most of us were involved in research into interopablity back in the early 2000's ( HHS 2004 report Case Study of EHR's in post acute settings "no area is this more apparent than in the lack of standards for messaging, vocabularies, and documents."

As David pointed out Epic is simply doing what its customers are asking it to do (very effectively as 1 in 4 providers will be using Epic when all current roll outs are finished and it could be the defacto National HIE if you could get Epic clients to trade) -Even though we shifted from provider to payer as primary customer (where are the patients btw?) we haven't seen any improvement in interoperability yet. Instead expensive exclusive applications like Epic are being used to consolidate market share and control the value chain in some regions.

We all know there is rarely business case to be made to exchange data on the hospital levels (vs community) but the third rail of health care is payment reform. Here in Seattle, we have Epic at Swedish, Group Health (no hospitals), University of Washington, Multi-Care and going in at Valley General (which affiliated with the UW to get the contract ) Northwest Hospital (another new UW affiliate), Overlake and now Providence which is doing a jv with Swedish to share their IT.

Even though most of the CIO's (Group Health, Providence, Overlake, Childrens') of these systems all sit on the HIMSS- WA board with me it is clear that they will probably exchange data via our State HIE (thin client) Like any "business" the goals are to drive income and not to share data per se.

For example Epic will not sell to smaller hospitals and clinics but once you have a critical mass of ancillary staff trained on one system in a region it makes sense to adopt it. Swedish (5 hospitals) is using Epic to control the value chain and control referral patterns by offering their version of Epic to critical access hospitals similar to the one that Brain works in that are too small for Epic to sell to.

FYI - As antiquated as MUMPS/Cache are (Vitsta is also MUMPS) they scream when you want to deliver records (when you have millions of patients like Kaiser) in real time (you don't have to query data-bases and populate fields you just pull the entire patient record) and surgeons will tell you even a second delay to deliver data on their screen is too long. When a client customizes their Epic implementation or a site customizes their VA modules (a huge value add to end users) it makes it challenging to share the data (more complex then simply remapping fields).

Just as history - Epics original clients were large ambulatory systems and only later did they market to hospitals and that is why you will see multiple ways to perform the same task. It also is the reason that interfaces are so challenging. The data isn't actually in what most of us think of as a database or OLAP cube. How the tool is used however is driven by the existing culture (patient centered Group Health was vastly different then academic driven Stanford). Group Health has moved to 50% of primary care visits online or on the phone, real time mobile apps that tell you the shortest wait times for labs and RX, patients full acces to their clinical records (including imaging results) because their payment system is integrated.

Epic's original clients - doctors and clinics simply don't have a business interest in reducing redundant labs or sharing patient data. The classic example here in Washington (2004) was in Whatcom county at Peace Health - using a patient designed EHR combined with nurse case managers was so successful at keeping people with chronic conditions out of the hospital that when the RWJF funding ended the doc's opted out of the program.

Sorry I went so long - I realize most of you are used to me talking in short 140 character bursts but there is a gentle thoughtful Medical Informaticist who is passionate about the power of health IT to transform health care into a high quality, affective, affordable, accessible patient centered system behind those tweets. btw I of course might be totally wrong and so I am open to feedback and disagreement.

Your analysis is right on the spot.

Your WA hospital ecosystem description is exactly what I experienced during my tenure in that state.

One question, I'm under the understanding that UW is a Cerner shop. Has this changed recently?

From a physician's perspective, after working w/ several EHRs over the last 8 years, I have to say EPIC is one of the worst - very non-intuitive interface, learning curve is steep and long (I have colleagues who took 8+ months to just learn to use it, create templates, etc). It looks and feels like a product manufactured by IT experts, with very little sense of the actual flow in charting and medical documentation in a physician's office.

In 5 years my EHR will be in my Universal card-key which will also be my key to everything else.

I'll also be able to walk into an airport and get past express-security without being frisked or going through x-rays, arrive at the car rental and pickup whatever is on the parking lot without ever having made a reservation, check-in my hotel room in the same fashion, etc., etc.

Oh and the predominant technology will be Approid.


+The EHR Guy , in five years we will all have a Google+ chip in implanted our brains :-)
Inpatient or Outpatient Cerner?

I used Inpatient version of Cerner for 3 years, not very happy w/ it but it does the job. I liked most the customizable caresets, where you could bundle together a bunch of admission orders for certain common conditions, worked great when I was on call.

I've seen a demo of Cerner outpatient, and my employer is actually going to update us to that in next year. I think they've come a long way lately w/ the outpatient product, though it is still behind what I've seen at Amazing Charts and others in terms of user-friendliness. They also have an iPad version of the outpatient ehr, you can download it for free from the AppStore, but it is poorly designed, in my opinion, as it supports only portrait mode and you have to tap your way back and forth between different sections that could have been made much more accessible w/ a left-sided menu like a lot of other apps have (see Gmail for iPad) and save you a lot of time (and finger cramps). Anyways, I look forward to the transition.
+Brian Turner I have been a programmer for a Cerner system for 5+ years now. There are definitely limitations, but we are typically able to find solutions. One thing to keep in mind is that the system where I work does have a large IS department and we are extremely customized in comparison to a lot of Cerner clients (or so we've been told).
Yesterday my editorial team (at was trying to explain to my sales and marketing team, most of which has worked with other IT "beats" before moving to health IT, why interoperability hasn't happened in health care IT. I repeatedly said interop (as defined by application developers, at least) in health IT is a pipe dream, and even standards-based EHR integration is a long way off.

I thought I was stretching the truth a bit, but this conversation makes me think I wasn't too far off. As +Vince Kuraitis said, an open IT architecture will be needed for this to happen. While Epic is largely the topic of this conversation, it certainly isn't the only vendor that's guilty of this.

Like +John Lynn, I look forward to seeing how the major EHR vendors participate in the Interoperability Showcase and, critically, whether what they are discussing is actually interoperability. I understand that standards as easy to use as HTML can't be readily applied to EHRs containing patient data as they can be to websites containing cat photos, but a similar philosophy -- whether it comes from the Direct Project or elsewhere -- will have to be widely embraced before progress can be made.
Great insights, discussion is very much appreciated.

My take, as a software person who has worked in many domains and who has now been working with Healthcare IT for the past few years, is that the state of the art in software for healthcare is years behind the rest of the world. Proprietary interfaces where vendors can charge large fees to generate an interface is a practice that is unheard of in most industries. Public APIs are understood to help grow market share for your product, not the opposite, as it generates more and more diverse and robust uses for your product. Your browser autofills your "demographic" information at every web site you go to, regardless of which browser you are using and what website you navigated to. Interop is taken for granted -- built-in from the get-go.

I have also been astonished at what end-users are willing to put up with in Healthcare IT. I see a CT tech having to click through 8 pages just to mark a study as "complete" in their RIS. The clinical devices are all shiny and Star-Trek, but the non-clinical tools seem to be only recently moving out of the DOS era (ok, an exaggeration to make a point...). It is almost as if the users feel they have no choice and no voice, that they just have to put-up with whatever software products they are handed.

VistA (IMHO) has a long way to go. But the emphasis on open-source is an educated gamble. Are there folks out there who see certain issues with the software and think that they can do it better? Bravo -- have at it, make it better. I'm optimistic, but time will tell how well that works in practice.

Epic, to me, is gaining market share in large part simply because it is gaining market share. There comes a point where the IT staff must justify why they are NOT picking the 1000lb gorilla in any market niche. And MUMPS was developed when I was an undergraduate (long ago and far way...). I don't find many users who actually like it or feel that it meets their needs, but those I meet who do like it, are genuinely and very strongly positive about it.

Looking forward to hearing comments on my somewhat controversial reflections.

And again, thanks for this forum -- very enlightening.
In doing some research for an upcoming talk, I found that Siemens purchased Shared Medical Systems, SMS as it was known, in 2000 for $73 a share, when SMS had sales of $1.2 billion and 7,600 employees, roughly equivalent to the size that EPIC is now. Interestingly, SMS was a company that failed to keep up with the technological times, and which struggled once competitors moved into the health IT market. It's a sad story, although the company has since been reorganized and is doing pretty well now under new leadership, including that of John Glaser. As one commentator put it at the time, "The deal ended an odd period for SMS, which actually pioneered the application service provider (ASP) industry in the late 1960s (although it wasn't called that then) by letting health-care organizations that didn't want their own computer systems and data centers to run programs on systems hosted by SMS." SMS was never able to compete with vendors who offered on-site enterprise systems that were NOT shared, losing business in the 1990s to Cerner, GE, and Eclipsys. One has to wonder if we're now into another cycle which will favor remotely-hosted, shared systems in the cloud over high maintenance cost enterprise products. As the world turns....
+David C. Kibbe As the world turns indeed. Many of those who have been around the block look at hosted solutions and cloud-based apps and chuckle a bit. Timesharing on steroids...
I always tend to "cringe" when I read about comparisons between Health IT, medical devices and other healthcare related software with respect to other verticals (e.g., finance, insurance, retail).

Why compare?

Saying that the financial industry is many "light years" ahead is extremely inaccurate. Comparing the processing of debits, credits, interests, etc. with medical information and imagery is like comparing apples to guanabanas (a tropical fruit found worldwide near the Equator).

Healthcare is definitely more complex than other verticals therefore it has complex interoperability issues.

The reason healthcare has interoperability challenges is because it has to deal with extremely complex workflows, scenarios and data. It also faces other regulatory constraints that hinder sharing of data between diverse organizations that interact with the same patients. State local laws also hinder as well.

Healthcare is the number 1 trail-blazer for technology.

Many technologies currently used by other verticals had their birth in trying to solve medical problems; companies in order to survive the regulatory red-tape (read FDA) diverted their attention to applying their inventions to other areas. For example, the CAD (Computer Aided Detection) for health anomalies would modify their products to serve other areas such as security and defense.

Healthcare has provided quite good interoperability solutions to the world. DICOM is ubiquitous in the radiology sub-domain of healthcare. HL7 has been quite successful for exchanging patient data between various source systems. X12 is also a standard for exchanging information between providers and payors.

SQL and MUMPS are of the same technological era.

Great minds from the Massachusetts General Hospital contributed to the creation of MUMPS. MUMPS was created near 1967 and SQL in 1970, so if we want to compare them based on age they are both post-baby-boomers.

SQL may have conquered more market but that does not necessarily mean that it's better. In technology like any other space the consumer trend has nothing to do with quality. If the opposite were the case then there would be more Apples than PCs. Intersystems Cache is an example of vanguard technology.

Excerpt from Wikipedia: "The European Space Agency announced on May 13, 2010 that it will use MUMPS (InterSystems Caché) to support the Gaia mission. This mission aims to map the Milky Way with unprecedented precision.'

Why didn't the agency choose SQL? Obviously there is a big reason. Maybe it's because SQL has no way of meeting the high-bar of unprecedented precision.

We should try to stop blaming technology for the US healthcare problems. Most of these problems root-causes stem from poor policies, savage competition between providers, imprisonment of the patient data, organizational silos, etc.
AHH! Now we get to some interesting discussions about fundamentals. Just what I was hoping my comments (and others’) might lead to.

+The EHR Guy you were one of the first people I followed, as I respect your experience and your insights. Allow me to now respectfully disagree with some of your points.

First, let me be more precise about some of the things I said. +The EHR Guy you are correct: MUMPS’ age is not the basic issue. The fact that it pre-dates relational databases (as +Jeff Brandt said) is more precisely the point -- so its age is the symptom, not the problem.

And let me now try to add some precision to one of your points. IMHO it is not the complexity of healthcare workflows that creates issues, it is the variability. Manufacturing workflows can be orders of magnitudes more complex. Also, in manufacturing, as in healthcare, you have decision points which can change the flow (e.g., inspections which create a re-work branch). The difference is that in most cases you know the expected duration for each of the steps ahead of time. In healthcare, most often you can’t know the durations. A cardiologist images a vessel, and only then knows if, or how many stents will be needed. So the time needed in the Cath Lab cannot not always be easily estimated beforehand.

The variability in Healthcare does cause issues, but I don’t agree that the variability of the workflows in healthcare is the main obstacle to HIE. IMHO it is the lack of public APIs. With a public API, the vendor can use HL7, XML, or whatever they choose, but the insertion or retrieval of that data, and its formatting, are understood by all. That enables any developer anywhere to write an interface to that system. Unfortunately, in Healthcare today we have proprietary interfaces, closely held by vendors, which require a custom interface anytime any data needs to be exchanged.

One other note. You say above,
“Excerpt from Wikipedia: "The European Space Agency announced on May 13, 2010 that it will use MUMPS (InterSystems Caché) to support the Gaia mission. This mission aims to map the Milky Way with unprecedented precision.”

“Why didn't the agency choose SQL? Obviously there is a big reason. Maybe it's because SQL has no way of meeting the high-bar of unprecedented precision.”

Well, actually, ESA DID choose SQL. From Wikipedia:

“InterSystems Caché is a commercial object database management system from InterSystems Corporation. It provides object and SQL access to the database, as well as allowing direct manipulation of Caché’s underlying data structures.”

There are apparently some hierarchical data structures in InterSystems that are the same as used in MUMPS, and this seems to be an excellent example of the use of MUMPS at the implementation level, while allowing access to the data structures as objects and SQL.

And YES, very much looking forward to continuing the discussion at HIMSS12. I will be there Mon-Wed. Any pointers to HCsm or HIE events, discussions, etc., are appreciated.
Epic claims that over 1/3 of US population is served by hospitals & clinics using their software:

Stephen Dickmann, chief administrative officer at Epic, spoke to about 160 people at the recent Wisconsin Innovation Network luncheon meeting.
Dear Don Rosenthal,

Please apologize if my sense of humor came across as arrogance or in an inflammatory way; sometimes this happens, unintentionally.

When I read a comment about healthcare technology lagging other industries, due to my background in radiology, which is highly technical and constantly innovative, I tend to be a bit surprised. Radiology, regulations limiting, read (FDA), is a highly advanced technological discipline where great scientific and technological minds come together to create amazing devices and software. This sub-domain tends to be an example for other domains and it's always in the vanguard position.

It is true that *IS (e.g., HIS, RIS, LIS) always lag everything and it's unfortunate but it's not always the vendor's fault. The ludicrous politics in healthcare provider organizations is one of the main culprits of this. Transforming mindsets in hospitals is very difficult to not say downright impossible. Sorry but true.

I have an interesting anecdote about a Texan surgeon, yep, wearing boots and a cowboy hat, at a hospital in Phoenix. While I was trying to explain to him how to use Single-Sign-On and CCOW so he could log into all the applications at once and if he selected one patient in one application (e.g., MEDITECH) then all the other applications would synchronize to the same patient. He starred at me with a bizarre look on his face and he said: "You just put this damn computer so that it works like I've been using it for the past three years or I'll go to the CIO and tell him to take this job and shove it up his ......".

He didn't seem to understand why we took away from him what he had learned during the past 3 years. Sorry but true.

Radiology also seems to be insulated a bit from the politics and certain mindsets because it's a pay-per-click model. Yes, radiologists get paid for clicking and going through images or ROI overlays, believe it or not. But, try to add one click to the workflow and you will have made a lifetime enemy out of them. Sorry but true.

What we should do is turn EHRs and EMRs into pay-per-click applications in alignment with CMS and the adoption rate would tenfold what the ARRA/HITECH is currently doing. CMS chose a pay-per-savings model; let's wait and see how that works! My analytical and mathematical mind says that something is wrong in that model. But well, what can we expect from politicians and bureaucrats?

Warmest regards,


No worries! Nothing offensive, or inflammatory inferred from any of your comments.

Interesting that you have a background in Radiology. Looks like we may have a lot to talk about. I've spent the last mumblety-mumble years developing AI tools to manage patient flow in hospitals, and specifically started in Radiology, because (one of many reasons) Radiology is often the most technologically advanced of the hospital departments. I'm not talking here about the clinical side, but the clerical side. We get the order information electronically the RIS, and reallocate resources and repair the schedule as disruptions occur. Other areas often don't even have an electronic scheduling or ordering system.


One of the biggest issues I've encountered in hospital IT systems (including Radiology) is the use of proprietary HL7 interfaces. These are closely guarded by each vendor as they know they can charge +/- $50K per interface. Other industries have for years being using publicly published APIs, which allow applications to freely interoperate. Those vendors understand that this makes their software more valuable to their customers, and can also become a passive revenue stream. Salesforce does 300MM (!) API transactions daily:

So when I make controversial statements about HIT being lightyears behind other industries, I am remarking on experiences like the use of proprietary HL7 interfaces when I have been used to public APIs. Our customers would love to deploy our software today, but the backlog for interfaces is swamping their IT departments and delaying the deployments -- whereas, if there were APIs for the EMR systems, we could deploy with minimal effort on the part of the hospital's overworked IT people.


The European Space Agency probably chose MUMPS over SQL because relational databases (which use SQL) do not work well in domains with many complex relationships. Trying to "normalize" a database schema in rich domains leads to database records where the keys are larger than the data payload. In an object-oriented database such as MUMPS, for example, a Patient is an object with many parts including diagnoses, procedures, billings etc. With a relational database, to load a Patient object requires joining records from many tables linked together with keys. Perhaps because the relational model turns entities and relationships "inside out", exposing relationships with keys, they are much more amenable to mathematical analysis and optimization than object-oriented databases. This is why relational databases are dominant in our information systems. In complex domains such as health care and perhaps space exploration, however, the object-oriented approach is a better fit.

That said, I recently applied for a job at a rural hospital struggling with Epic a year after go-live. The IS staff there describe a long and steep Epic learning curve -- from 6 to 12 months for a new hire to even be useful. The Epic Assessment test that they had me take, meanwhile, was loaded with "what does this convoluted code do?" problems. Almost a celebration of complexity perhaps, in striking contradiction with the principles of software engineering which are all about achieving simplicity and clarity.

To reduce the Epic learning curve and facilitate an evolution towards a robust system, it seems to me that an open source community meta-model of Epic data relationships would be invaluable. For example, it would be possible to document Epic using description logic ontologies -- the same knowledge representation technology proposed for the semantic web. I would be pleased to discuss this idea further with anybody interested.

Thanks, Peter
Does anyone know about Epic's Lucy format and if it will meet interoperable CDA clinical summary under MU2 requirements which take effect in Q1 2014?  Thank you, Seth 
Great question Seth. I'm sure that Epic is planning to have their product certified as a complete EHR, but it would be good to know specifically in terms of interoperability.
Amazed and happy that well over a year after Brian started this thread, there continues to be great discussion on the topic.
+Peter Weinstein Epic: "Almost a celebration of complexity perhaps, in striking contradiction with the principles of software engineering which are all about achieving simplicity and clarity." Wow...Might be because historically, in order to fit into the very tight memory confines of the 60s and 70s, MUMPS commands were abbreviated down to one or two letters, making the code extremely hard to follow.

Peter, my understanding is that MUMPS utilizes a hierarchical DB, not an object-oriented DB.
From Wikipedia; "The MUMPS language provides a hierarchical database made up of persistent sparse arrays, which is implicitly "opened" for every MUMPS application." 
Is that information outdated?
+Don Rosenthal I believe hierarchical is the proper term.  However, the way data is stored/retrieved in a hierarchical variable is analogous to an object in an object-oriented language.  This is why MUMPS is considered to be in the class of NoSQL DBs which are essentially object/document stores.
So, here we are in 2013.  Does Epic still have no API/Web Services/XML that can be easily extracted for use in other systems?  For what it's worth,  I have been using RESTful Web Services with Cerner Millennium for a while now, quite well.  No security or performance issues.  When will Epic follow suit?
I have a sign in my office that reads: Health IT would be interoperable if you would just do it my way". I think it applies here.
Brian, completely agree!  Since moving over to doing Java and .Net work with Cerner, I am impressed with Cerner.  Millennium Objects (with it's flaws and potential lack of future support) has been leaps and bounds better than EPIC.  I have portal and mobile apps I've built that integrate with Cerner.  Apps that EPIC will not build.  it's a shame.  You'd think EPIC would learn from MS and Apple, proprietary is a four letter word!
Add a comment...