Skip to content Skip to navigation

First, We kill all the Interfaces!

Printer-friendly version

We all know what we want:

-Eliminate silly and excessive patient forms

-We want to exchange demographics

-We want to participate in RHIO’s

-We just want all our applications to play nicely in the same san-box (pun intended).

So why are we not able to purchase a “Best of Breed” imaging solution and have a system prompt come up: “Epic has finished installing the software for this device.” It’s those darn interfaces! My friend George Gides (the OBE-WAN of interfaces) will kill me for this, but we need to think outside the interfaces.

HL7 was supposed to be the conduit for all integration across systems. The industry really thought that vendors would seamless adopt a clean way of talking to each other. We now have a cottage industry of interface engines and George Gides is busy untangling the spaghetti diagrams of organizational interfaces. There are some vendors that are trying to provide alternatives, such as InterSystems Ensemble. But at the end of the day, it’s just trying to patch information through.

Interfaces has become the hidden cost of doing business when you consider adding something new. I think most vendors consider it a penalty fee for purchasing outside their suite of products. They are quick to tell you that their price does not include the integration with “other” systems. Can you imagine the lawsuits if Microsoft charged a fee for every non-Microsoft product you installed on “its” system?

Interfaces has become the hidden cost of doing business when you consider adding something new. I think most vendors consider it a penalty fee for purchasing outside their suite of products.

Comments

Here at M. D. Anderson Cancer Center, we've built our EMR in-house fully utilizing an SOA. While we still use HL7 for some point to point needs, we are committed to leaving data in the originating system whenever possible, not moving it into a central repository, which gives us "one source of truth", and a "virtual" clinical data repository. It is ironic that we are today trying to solve interoperability problems with a 20 year old technology, when other industries have moved on. Of course, when the majority of clinical system vendors rely on this same architecture, and most healthcare providers rely on those commercial vendors to provide their systems, and the cost of "re-architecting" is high, we should not be surprised at the momentum behind trying to keep moving data from one place to anothereven as the complexity and volume of that data keeps increasing. Healthcare seems to have completely missed out on the real value of Internet tools and technologythe ability to access and consume data without moving it. I worry that at some point, absent a true commitment to SOA, we simply won't be able to met our customers' expectations for accessig the data they need to do their jobs, and patients will lose out on new treatments protocols, etc. Services wrappers for legacy systems are actually not that complicatedif you are willing to do the work and recognize that in the long run the best solution across the industry to not to standardize on a single system or vendor, but to build environment that can access data when it is needed, from whatever source happens to have it, whether hospital, physicians office, drugstore clinic, etc.

Pete,
There's no question that almost any vendor, or rational actor for that matter, would rather invest a scarce dollar in their own boat, rather than upgrading the port for all boaters equally.

In part, that's why the boat model has left us with a gnarly harbor.

SOA has the potential to transcend that, selling passage rather than boats. If you need a water taxi service for a dozen people, or an infrequent dinner cruise, you really don't want or need a boat.

The market isn't necessarily fixed, however, by moving to services. Today, services are still largely connecting transaction or "edge" systems.

The beautiful but sad thing to me about HL7 is that massive amounts of work have been done by extremely gracious, smart volunteers. Work that could and should lead to clean PNP. The HL7 work {information model, reference terminology, CDDS, and other workgroups} been very inefficiently translated into true industry progress. My points above about HL7v3 speak to that. I hate to see good work that's not well utilized.

As someone that was heavily involved in HL7 at the 1.0 level and subsequently became the Product Manager for STC/SeeBeyond's DataGate and eGate, I can attest to the 'cottage' interface engine industry that HL7 created. As Wes Rishel said many years ago, 'when you've seen one interface, you've seen one interface' and 'the great thing about standards is there are so many to choose from.' Bottom-line as Pete points out is that there are too many competing interests. If data was easily shared, all products would be evaluated stictly on their functionality. Unfortunately, for most vendors, that's scary. And interfaced is not integrated. The key for me has always been the semantics and understanding the relationships between the data. I pretty-much 'bailed' on HL7 in the V2 phase seeing as Dr. Bormel points out that we weren't making a real impact. Since then I've gone the 'easy' route of being a CIO and trying to find a single vendor with a complete-enough (integrated?) solution that I could 'live with' and afford to maintain. But most of the top products are developed with yesteryear tools and technologies. Adding an SOA label isn't that easy. I guess if we really want to "kill the interfaces," we probably need to be willing to kill some vendors too.

Agreed Joe. However, I fear that unless there is a government mandate to do it (Y2K, HIPAA), the resources will not be allocated to achieve a PNP solution in our industry. Don't you think there is just too much competing interest?

Agreed Joe. Although I believe that SOA is the way to go. I see what the V.A. is doing with this software architecture and I think that is the only way we will get to something close to plug-and-play.
HL7 has been around for a long time, and looking at it from the consumer perspective I would think that more effort would be placed in designing a GUI portal into each application. I truly believe that vendors don't want to consider a client's need to interface because it suggests that their product offering does not meet all the client's needs.

You're all right! Boy, an I non-confrontational today!

My understanding is, to use SOA well, you've got to get the granularity of the services matched to the needs of the service consumers. For instance, if you a page worth of patient list, say 25 patients, the service should return 25, not 5,000. (And, of course, the right 25!)

Similarly, if your application or capability requires cache'ing all of a patient's relevant data in order to effectively "reason over it" and provide real-time decision support, then use SOA to "move all the data" (as infrequently as logically necessary.)

Lynn, do you agree with that, or is it more complicated?

Great post Ben. I too am frustrated with the "yesteryear tools and technologies." Maybe we can convince Apple to go into the healthcare software market.

Pete "Shakespeare" Rivera,

You mentioned HL7. Personally, I'm waiting HL7v4. HL7v2 presumed that interfaces could be sufficiently perfect-able. As you pointed out, that didn't get us to the plug-and-play we want.

HL7v3 overcame one of the previously invisible problems: the underlying information models in v2 connected systems logically precluded plug-and-play.

HL7v3 had it's own, new invisible problems. Folks much smarter than I on such things, specifically Wes Rishel, explained that in detail to the Gartner clients, as well as anyone who would listen during the NHIN meetings. HL7v3 presumed that enough of the right people could understand and harmonize with "the spirit of the RIM," and the business value of doing so would have made HL7v2.x obsolete by now. Didn't happen.

I'm not yet convinced that the services architecture approach (SOA) with clinical document objects will transcend the interface problem at the core of your post. It's clearly necessary in order to carry enough context, including arbitrary act_relationships.

And, although I understand and acknowledge the vendor suite incentive argument, I haven't met a hospital CIO who has reported that their vendor is capable of delivering a high-performance, integrated solution that truly scales (12+ large hospitals and the geography of a medium sized city, retaining sub-second screen flips of predictably common data elements categories). I have deep visibility inside several of the largest HCIT vendors. As trite as it may sound, this stuff really is hard, and the problems really are wicked.

I raise my glass to you Lynn. Well said. Maybe some of the larger legacy systems have become like supertankers trying to turn in a harbor. While in-house development runs circles around them using the latest technologies.