Health IT vendors wishing to partner with electronic health records giant Epic Systems should understand that the closely held, Verona, Wis.-based company does things differently than many of its competitors.
Epic does not purchase any other development nor does it embed others’ software into its systems. It does not have third-party resellers, either, in part because Epic’s architecture is complex. “We are not looking to outsource any work,” Epic Vendor Relations Specialist Tim Thompson said this month at the first-ever Start Me Up Emerging Healthcare IT Meetup Day, a precursor to the 11th annual WTN Media Digital Health Conference in Madison.
In fact, “partner” means something different at Epic than entrepreneurs might be used to. Epic’s partners are its customers. “They are the only partners that we have,” Thompson said. He explained that corporate partnerships can get in the way of customer relationships, so Epic does not have that kind of partnership.
“The big reason why aren’t purchasers of technology and we don’t go out and buy other people’s products is that we have confidence that we have the vision and we have the customer input and we have the source [code] and the history to be able to find the solutions ourselves,” Thompson said. “Maybe it’s ego, maybe it’s history,” he added, then suggested it might be a bit of both.
What Epic will do with third-party vendors is interface with their technology – but only if it makes sense for Epic customers and only if the other vendors follow established industry standards.
“Your best path to selling to this large customer pool is to develop to standards and sell your solution to them, not to us,” Thompson said, noting that Epic currently has 294 healthcare organizations as customers, about 280,000 physician users and records on 147 million to 180 million people. “If you are trying to make a sale, sell to your customer. Your customers are the same as ours. Sell to them,” Thompson advised the entrepreneurs in the audience.
“We are all about supporting our customers. That’s our goal. We are partners with vendors on behalf of our customers, and we should not think of each other as partners in a traditional corporate sense,” said Thompson, a nine-year veteran of Epic who actually was making his first presentation to any health IT conference.
“What we should think of each other as are partners in a way that we can do the best for the customers that serve the patients that need the help. That’s our goal. We serve customers so they can serve their patients,” he added.
Epic’s policy in working with other vendors is that it’s agnostic, according to Thompson. This provides healthcare organizations and entrepreneurs the freedom to innovate, he said – and potentially offers them access to Epic’s huge customer base.
“If they’re developing to standards, we can easily adopt those things and make that available not only to that [first] customer, but to all of our customers,” according to Thompson. “It makes it easier for you to sell. It makes it easier for us to integrate. It makes it easier for the customers to use and to support.”
He called the framework for health data exchange, integration, sharing and retrieval developed by Health Level Seven International (HL7) Epic’s “favorite standards.”
Thompson said Epic regularly reaches out to its customers to let them know what new technology might be available for them, and that Epic has a “huge amount” of APIs and Web services that may be able to health systems better care for patients. “But they’re not necessarily a perfect fit for every vendor, every time, which is why we need this to be an individual relationship and a conversation between a vendor, between us and between our customers to make sure that these differences are nullified,” Thompson said.
Still, this may not be enough to satisfy some developers out there, as Epic CEO Judith Faulkner heard a day later during the main Digital Health Conference. One attendee, Dr. Scott Jens, CEO of Health Innovation Technologies, maker of the optometry-specific RevolutionEHR, expressed frustration with trying to integrate his product with enterprise systems such as those from Epic, Cerner, GE Healthcare, Meditech and Siemens, and called on Epic to release its source code to the programming community.
Faulkner said Epic does provide its code to customers and will train its customers’ programmers on building interfaces and applications. “What we don’t do is open it to vendors because they don’t have special relationships with us,” Faulkner said.
According to Thompson, Faulkner is not the one to go to about outside software development anyway. When one vendor in attendance asked about getting even 10 minutes with Faulkner, Thompson said that his boss would delegate the responsibility to him anyway. “Believe me, 10 minutes of time with Judy will result in her saying, ‘Have you met Tim?'” Thompson said.
“It really doesn’t matter, the scope, the size, the number of places you’re doing business, how incredible your product is,” Thompson said. “Judy is not going to listen because she is focused on our customers, always, always, always.”
Thompson also noted that he frequently gets asked if Epic has a software development kit. “If you’re developing to standards and those standards are very well-defined, there’s no need for SDKs,” he said. “There is no need for us to look at your code, or you to look into ours. What we need to do is if we don’t have an API that works, if we don’t have an interface that’s already existing, we need to make one.”
He also emphasized that Epic frowns on custom-built software. “Custom code hurts. It’s hard to maintain. It’s hard to build on top of. It’s hard to upgrade customers to your new versions and their dependent on code that’s 10 years old and was written just to get one job done once. Standards are what it’s all about, and communicating directly with your customers is the key,” Thompson advised.