If you have been involved at any level with Electronic Health Records, ancillary information systems or revenue cycle management solutions in the healthcare setting over the last decade, you probably have had a negative experience with an applications interface along the way. HL/7 is no more a guarantee of moving information from point A to point B than a politician’s words are guaranteed to be true. It’s just data right, so why does it have to be so doggone hard?
About now, you are expecting me to say, “It doesn’t have to be this way,” or “just hire me,” or “buy ABC software and all your problems will go away”. Well, sorry to disappoint but that’s not the focus of my rambling here. The truth is interfaces do suck and will continue to for a while. To pile on to the sentiment, here are some completely unconfirmed but widely shared statistics via public domain that highlight the problem:
- About 80% of all serious medical errors involve miscommunication during care transitions
- Patient charts cannot be found for 30% of visits
- Providers fill out an average of 20,000 forms per year and its said that doctors spend over 2/3 of their time filling out “paperwork” or EHR documentation.
- Patients still have to repeat the same information multiple times per visit and / or fill out multiple forms for each encounter and this requirement increases exponentially when visiting multiple care settings.
I know I’m preaching to the choir here, so I’m going to give you two reasons interfaces suck so much, along with a suggestion for what you can do about each. No, I’m not contradicting my earlier statement. The solutions aren’t quick, free or easy, but there are some steps we can take now to make it suck less and do our part to contribute to the future demise of sucky interfaces.
1. Application vendors are terrible at sharing.
Here’s how the typical “point to point” interface conversation goes between application vendor A and application vendor B.
- Salespeople of both vendors to customer: “Sure we can do that as long as Other Vendor is HL/7 compliant. Have them send us their specs and well get right on it… (they either don’t know better or are lying or both) …after you send us $15,000.” (not lying)
- Customer to vendor A’s interface specialist 60 days later: “Why isn’t my interface done yet?”
- Interface specialist for vendor A: “I don’t know, I sent vendor B an e-mail and never got a response – our side is pretty much complete.”
- Customer to vendor B’s interface specialist: “Why didn’t you reply to vendor A’s e-mail?”
- Interface specialist for Vendor B: “I did, we told them they had to change one field, then they never replied”
This continues like the 20 minute delays at the airport for about six months until you finally give up and create a work around. Notice that the vendor sales reps never call back to ask how well the interface is working. (Can you say plausible deniability?)
What can you do about it? BUY AN INTERFACE ENGINE! You have to take the interface interpretation out of the individual application vendor’s hands. Insert this middle-ware so you can say yes to both vendors on their formatting preferences. There are other benefits an interface engine provides and over time, it might actually put some money back in your pocket too. But here again, you can’t just buy software and “poof”, your problems are solved.
This is a complex technology design effort that takes a fair amount of planning to address properly even with an interface engine. This is where IT Analysts must facilitate timely and purposeful work sessions with end users and the vendors to bring about the optimal outcomes, which brings me to my second reason for sucky interfaces.
2. Interface requirements are rarely defined by the end users that are actually using the information.
It is also rare for end users to truly understand their role in a “clean” interface transaction. Let me illustrate why/how this happens.
You decide to interface two systems because you want to eliminate duplicate entry and save steps. Great idea. But, if the first action you take is to call the vendors and ask, “Have you interfaced with SoandSo Vendor before?” You are asking for trouble. Let’s play that out.
- End User: “Hello Vendor A Salesrep, have you interfaced with SoandSo Vendor before?”
- Salesrep guaranteed answer: “Sure! (I smell money)”
Right here is where the requirements definition transfers from the end users to the vendors. The next thing you know, the interface requirements become whatever the two vendors THINK they can do rather than what you really need.
Let’s unpack this problem a bit further. Consider the idea of sharing Medication Lists across a healthcare enterprise (maybe from Ambulatory system to Acute care system or ED System). What if Dr. Smith is using generic medication names and Dr. Jones is using name brands? What if Dr. Smith defines the frequency as “4 times daily” Dr. Jones refers to it as “QID”? What if Dr. Smith uses medication reconciliation to perfection and Dr. Jones does not? An interface engine will not fix these data gaps. It’s the old adage of “garbage in = garbage out”. We have to standardize the inputs before we will ever get the system to perfectly transfer data to another system.
So, how can we change the game? We have to BEGIN the interface conversation by following a process for mapping workflow, which ultimately leads to requirements determination. It’s akin to the process for writing software and if you think about it, interfacing really is a programming exercise. The Lean A3 method is a great tool to use to facilitate this process. Map the workflow and optimize it using Lean and then translate that into interface requirements, which ultimately drive your approach to connecting the applications. This insures that the requirements are born out of the best workflows. Then the subsequent requirements definition document you create during the Lean event will insure that you have the right target defined for your interface project.
I realize that requirements definition processes like SDLC, workflow diagramming exercises like Lean A3 and interface programming aren’t what the typical healthcare person wakes up wanting to do in the morning, so this might be time to get some outside help.
I guarantee that while it might feel like you are adding time and money to the solution; it will be time and money that pays dividends far beyond the data transfer. If that isn’t enough to convince you, tally up how much you have spent in the past on interfaces that failed to deliver the desired outcomes. What’s that worth? What’s the value of the time that was wasted by your staff working with bad information? What’s the risk to patient safety or patient satisfaction?
The infamous manager of the Chicago Cubs is quoted on T-shirts as having said “Try not to suck!” (the proceeds for these T-shirts actually benefit Cubs Charities) At the time of this writing, his team has won the World Series for the first time in 108 years, so maybe that slogan isn’t such a bad motivator. Consider the steps above when interfacing and… Try not to suck!