I hear, and personally experience instances where the insurance company does not understand (or at least can explain to us…
Readers Write: Your Interfaces Suck Because You Want Them To
Your Interfaces Suck Because You Want Them To
By T. Ruth Hertz
Your interfaces suck because you want them to. Yup, that’s the stone cold reality.
I am looking at you Mr. /Ms. CIO. You may talk all day about interoperability, data normalization, HIEs, standards, etc. but unless the right data in the right format gets to the right place at the right time, you are wasting time and money and possibly risking patient safety.
But wait, you say. We insist that all applications have HL7 interfaces – we even put it in the contract! Yes, maybe you do, but do you take the time to get and review detailed specifications before you sign the contract? Do you require the vendors to demonstrate interfacing their application with the ones you already have? Not just give you a list of other clients that have “the same systems as you” but actually connect their system to your engine and downstream application test environments? How well would the physicians at your institution react to being given a list instead of a demo and / or site visit?
Do you let your interface experts ask the tough questions during due diligence? If you do, does it matter when the answers are wrong or evasive? Or do you just accept it when the vendor says, “You can fix it in the engine?” Do the interface experts get to go on the site visit, see the interface in action, and talk to the folks that have had to actually make the interface work?
Let’s face the facts:
- It is in the application software vendor’s best interest to not interface well with other vendors’ apps. Selling a suite of apps that work well together but not well with others makes buying their products as a set look like the smart thing to do.
- Application software vendors can make their interfaces work. They have the source code and the underlying database. They just need a very good reason to do so – like “no sale” if they don’t.
- Your interface staff time isn’t free. All the time spent on analyzing, designing, and building workarounds to compensate for deficiencies in the sending and/or receiving applications costs hard money. That time is also time lost from other projects.
It’s time that the decision-makers who buy healthcare apps put a stop to this madness and insist that true interoperability be delivered by the software vendors – or no sale.
Great article and right on point. Too much expense and no getting everything you need to make your business(hospital) better and compliant.
My perspective from the vendor side:
1. It is in our interest to interface well with everyone, period. Otherwise it is a drain of our support resources, hurting all of our customers and leading to higher support costs for the customers. We don’t make margin on support, and an unhappy customer will hurt our sales.
2. Interfaces are a three-way street – us, the hospital, and the other vendor’s system. We need clear and accurate communication from everyone to ensure that we are all on the same page. If one of the party makes a change and doesn’t tell the other two then something will break and there will lots of finger pointing. A simple email or phone call is all it takes to keep everyone informed.
3. Sorry, but the workarounds I’ve seen are always caused by the hospital because they their environment is ‘unique’ and following the standards won’t work for them. There is no reason in the world why a software vendor would willingly create workarounds unless the customer insisted upon it.
I think the article is blending mulitple issues, and in fact the writer has errored in stating that its in the application vendors best interest not to interface well with other vendor apps. The entire OEM line of business would not exist for integration engine vendors if this were true. There’s a long list of vendors who have migrated from building point to point brittle interfaces to outright purchasing commercial integration engines for this very purpose.
Even companies who have their own legacy integration engine have sunsetted in favor of buying so they can focus on core product/application development, and preferred to source IE’s and ESB’s to companies that sell commericial integration engines.
There are vendors that are more proprietary than others, Meditech, Epic, but they are the exceptions. Fact is there is more overhead in vendor build strategy than to buy, so its easier, faster, cheaper, and compliant with all the regulations like HIPAA, MU.
The market is far more mature today than it was 5 years ago in terms of vendor’s procuring middleware and integration engines.
This author’s premise is flawed because vendors have and continue to consider and weigh the pros and cons of embedding integration engines. Reasons are broad and always include competitive pressures and customer demands, contrary to this authors premise.
I’m not aware except for Meditech and Epic, of a major acute care EMR vendor who does not use a commerical integration engine, and many physician EMR vendors have purchased as well. Not the case however in departmental apps like Radiology, Lab, Cardiology, but they are moving in that direction.
One of the unique advantages we always give for selecting Rhapsody is our ability to facilitate and easily enable to collaboration between hospital IT integration staff and the vendor staff in the coordinating and alignment of data feeds. This is relatively painless for customers with the advanced capabilities within Rhapsody. This speaks directly to cost of ownership, time to value, improved operational efficiency with staff and systems. We usually get oohs and aahs on this one.
Speaking as someone who works in data integrations, perhaps I can offer an alternate perspective.
For the record, we would LOVE to build/architect something once and have it communicate/function with EVERY system out there, but the likelihood of that happening is probably 0%. The reasons are:
1. The specs for any one company’s systems are likely out of date by the time they are published; systems constantly change, whether for legal/governmental requirements or simply the client with the deepest pockets suggesting a change they want to pay to have. So good luck coding your system to anyone’s “specs”.
2. The government’s ever-increasing participation in Healthcare throws a monkey wrench into every Development staff; in order to be MU compliant, systems were forced to re-tool or face being one of the [applications in the market that did not offer that benefit. Whether or not their clients want to use it, not offering it puts you on the list of software vendors rarely considered viable. Another fine example is being able to provide ICD-10 and eventually SNOMED codes; this is not a simple proposition.
3. Even when you have specs that are SUPPOSED TO BE ironclad, such as HL7, everyone has their own twist or flavor–837’s being a good example. The 4010 version was supposed to allow for some customization, but the 5010 version was not—yet even 5010 versions of 837’s have fields serving multiple uses, requiring custom code to handle them. Multiply that out by the number of clients, then the various endpoints they send claims to, and that aspect alone can become a fulltime job.
The example you cite is the old Apple model, and while any software company would KILL to be as successful as Apple even Apple has moved away from the business model where only their software worked together. Their value has endured and even expanded by becoming able to work with even Microsoft Office products, and it shows that appealing to as wide an audience as possible only increases your viability and value in the marketplace.
We all wish we could interface seamlessly with every software out there, but the scope of doing so makes this dream challenging to say the least. Yeah, it “sucks” that we can’t just plug and play with everyone–but you can be sure it’s not by design.
Re: The riff on CIO’s not getting interface functionality because they don’t prioritize it.
This is both true… and not true. The major flaw in this argument is that the CIO is in “control” of this process. While that may be true in some organizations it is not true in all. And the business best practices say that it should not be true, not ever.
Here’s a reality check from 10 years ago. My company went through just such a system acquisition, and put it through a pretty normal RFP process.
This RFP used weighted scoring. Every affected department got to assess the system components that were “theirs”. This means that IT is aligned with the business which is how HBR and all the rest say things ought to be structured. However this also means that there are no “deal breakers”. No one gets a veto, not over anything. This point becomes important as we shall see.
Now I’ll posit that interfaces are one of those issues that will likely fall to IT ownership. So the responsibility for interface functionality won’t be assumed by any of the business departments. However what was the total IT input to the RFP? It was about 15%. And that 15% includes ALL IT issues, not just interfaces.
So the majority of the RFP outcome is determined by business issues, business departments. In in the clinical realm, that means that core clinical functionality dominates. And the number of issues that must be examined for a large, general purpose hospital system from one of the major vendors, well it likely numbers into the thousands!
That’s the problem with the article. Ultimately selecting a system is an exercise in compromise. There are no perfect systems and no perfect vendors. Everyone has gaps in their product offering and even discovering those gaps takes time, determination and bringing the right people to the table. Certainly the vendors will do everything in their power to look good and avoid looking bad.
So are interfaces weak, and a hot topic of the day? Sure they are. However in an evaluation where perhaps EVERY vendor has weak interfaces, what’s to differentiate the offerings? And when every attribute must be measured and assessed, and there are no ‘deal breaking’ issues or ‘rainmaker’ decision makers, but responsbility is truly shared, how do you change vendor behaviour and product development direction?
Another vendor perspective:
The article makes good points and the first 5 comments above are all excellent.
I disagree with the notion that you limit your vetting to vendors that can demonstrate interfaces with systems you use. That is a provider-instituted form of creating obstacles to both interoperability and innovation. Sharing data between two systems in an X12/HL7 standard is easy. It’s making sense of the data to make sure the two systems are communicating accurately that requires customization. Every connection is unique to your business and your data. Nobody but the vendor you’re replacing can demonstrate they’ve been there.
A good example is the healthcare payment. The X12/835 healthcare payment transaction has probably been in use longer than any other standard transaction. Many providers receive an electronic 835 transaction only to print it out and post it manually. Why? Because the denial codes, contractual adjustment codes and reason codes that it contains don’t always mean the same thing to every payer and provider. Sometimes the codes may have clear meaning but the payer doesn’t use them correctly. There is a translation element to the data in the standard format that is unique to that payer/provider exchange. Providers that want to automate the payment posting process need a vendor that can implement a rapid/dynamic rules based interface that can handle the translations unique to the source and destination of each transaction.
The data in these standard formats are as dynamic and customized as the business relationships between the parties or departments involved. The vetting process shouldn’t be based on a list of existing connections, but rather how the vendor deals with customizations. That will narrow the field quickly. Many vendors charge hourly rates and significant fees to customize an interface. That’s generally an indication of an outdated interface engine.
Oh no HL7 is a perfectly good. What could possibly be wrong with a 1873 page standard (v2.5.1). A standard like SOAP can’t hold a candle to to Hl7. And we all know SOAP doesn’t suck right. Every vendor gets tries to get along perfectly when implementing a standard. Vendors would never try to extend a standard in their favor and vendors absolutly never try to manipulate the standard to gain more market share. I mean that would be just unheard of.