Author: Kevin Roy

Does innovation start with standards?

With interfacing and interoperability, there’s an unspoken assumption that innovation starts with standards. It seems like we wait for standards organizations, industry associations, and government edict to point the way. Someday, somehow, They will give us The Rules to make interoperability happen.

Instead of waiting, what if we, as vendors and providers, stepped in?

This is an amazing competitive opportunity for vendors and consultant that step in now. Today, the hourly rate business model is the bread and butter of HIT consulting firms. Too many firms see their only options as increasing billable hours or increasing rates — or facing margin squeeze. Based on where we see the market going, those are the firms that are going to get left behind.

Here’s what the frontrunners are doing:  they’re innovating by commoditizing interfaces.

Commoditize interfaces, not team members

Interfaces are hard work and they require expert analysts and developers. The best analysts and developers are stuck with an outdated interfacing methodology that is slowing them down. They’re using trial and error, picking through small data samples and building interfaces manually.  All of these things add up to project overruns and misunderstood processes that are draining money from providers and vendors. These are things that managers don’t bring to the C-suite but that show up on the bottom line as the cost of doing business.

Interfacing is ripe for service innovation. Let process and technology free analysts and developers to spend time on value-added work, more cost-effectively. Focus on understanding data before building the interface. Save time by testing.

The smartest organizations are now looking at how to build more interfaces by removing the friction in the interfacing lifecycle, so the complexity they might encounter in legacy health information systems is no longer an issue. They’re breaking down silos, so analysts and developers share assets with support reps.

If we innovate here, all those things we dream about in healthcare IT become possible: real-time alerts, predictive analytics, clinical effectiveness research, and so much more. Information flow enabled by interfacing is at the core of so much of what we want to do in healthcare – more effective care and improved patient outcomes, accountable care, error reduction. Based on an IBM study  (PDF; registration required),  51.2 percent of medical error might be prevented if we have the right information at the right time. 

Competitive Advantage

The firms that commoditize interfacing first will have an enormous competitive advantage. They’ll be competing on value and collaboration. Instead of a technical deliverable, they’ll be working on a business deliverable. And the demand is there: 90% of provider CIOs see integration as a major priority.

We’d all be better if vendors and consultants competed beyond the tired hourly rate business model and left The Rules behind.

The frontrunners aren’t waiting for The Rules.

Your Comments

What are your thoughts? Let me know in the comments below.

“Interfacing costs? They’re too high.”

We hear that a lot. The cost is frustrating, especially to physicians who need to implement EMRs for Meaningful Use. First there are the license fees. Then you find out you need an interface. Or two. Or six. That number can expand with the interoperability requirements in Meaningful Use Stage 2.

Software Packages vs. Software Programs

Here’s why I think interfacing costs are frustrating. After 30 years of PC use and now BYOD smartphones and tablets, we’re used to thinking in terms of software packages and applications. Think Office 2010 for business productivity. A nice little set of apps on your Android phone. Even cloud applications like Salesforce are basically software packages. They’re (mostly) intuitive. They work (more or less) out of the box.

What we have in healthcare IT are programs, not packages.

EMRs and related systems are software programs that must be configured. Workflows have to change in order to get value out of the software. The programs must be enticed to play well together and accurately communicate the information they harbor to those that need it, when they need it. Rinse and repeat for every application, clinical or otherwise, that you need to integrate.

So let’s break down the costs. When you buy an EMR, you buy the hardware, licenses, maintenance, implementation, and training. It takes time to get the EMR up and running. It’s not plug and play. Rinse and repeat for every application, clinical or otherwise, that you need to integrate.

Ikea vs. a Custom Wood Shop

Here’s another way to approach the costs. It’s like thinking you’re buying your furniture from Ikea (some assembly required), but in reality you’re working with a Maine craftsman in a custom wood shop. We’re still in the custom wood shop stage with healthcare IT. You might have the wood all dried and ready to plane, you might have some basic designs to leaf through in a catalog, but there are still a thousand decisions to make. Wood stain, upholstery, seating style… that’s just the beginning. Even then, once the furniture is built if you don’t take care of it, make sure there is enough humidity in your environment, it just might crack.

You’d think that because an EMR vendor had interfaced with a lab system run by ten other clients, the vendor would just copy their interfacing code and reuse it with their next client. But that’s not how it works. Because we lack standards, because we’re dealing with complex data, because the delivery of care is complex – because of all these things, sharing that data is complex. As the volume of data increases and regulatory compliance demands interoperability and security, that complexity rapidly grows.

If we break down the costs of interfacing, there’s an enormous amount of custom work. It’s not uncommon to spend upwards of 40 hours just on coding an interface. And gap analysis? Days of intricate HL7 pipe- counting. Testing? Are you working with real de-id’ed data so you know your validation cycle is clean? Or will you be picking through code searching for needles in that haystack as you watch your project timeline go down the drain and costs rise just to get it done? That’s the environment that the EMR vendor’s analysts and developers are facing.

This sounds like an apology for high prices and charging-just-because-we-can. But the reality is: this is the state of our industry. Personally, I think we can do better. If we can turn interfacing and interoperability into a viable commodity – if we can drive down the cost, imagine what we could do in healthcare.

Where Should Interfacing and Interoperability Go?

Tell us some of your answers to this question. Where does your experience, knowledge and creative imagination take you?

Meaningful Use, the changeover to ICD-10, the 2013 HIPAA Final Omnibus Rule, among other drivers, makes it clear that integration is an essential, critical process. How do hospital CIOs and healthcare information exchange (HIE) leaders find cost-effective ways to develop the HL7 interfacing that underlies such critical integration projects?

No matter what the bells and whistles of an integration engine or integration technology, if you cannot accurately scope the interfaces that need to be built, you’ll find yourself behind the eight ball and rolling rapidly downhill. Poor scoping can lead to painful consequences such as extended go-live periods with a rapidly inflating price tag, significant maintenance at increased cost, and unhappy clinician end-users who are unable to access the data they need for appropriate patient care.

Gap Analysis and HL7 Flexibility

Fundamentally, when you’re building an interface, you’re bridging gaps. Gaps – which drive the need for mapping and configuration – occur because the HL7 standard was designed for flexibility. HL7 was built to fit multiple healthcare environments, from hospitals and integrated delivery networks (IDNs), to labs and physician offices, to payer systems. This choice has some advantages. For instance, messaging is independent of system architecture – a huge interoperability plus.  With this flexibility, the HL7 standard not only provides a recommended exchange format, but also provides a framework for powerful capabilities to extend and adapt the standard to real-world use.

100% HL7-Compliant?

But there is a major drawback:  even if two systems are 100% HL7-compliant, they still might not be able to exchange data. These are the data exchange gaps that must be bridged through an interface. HL7 interfaces always require some degree of customization – which is why scoping and mapping are required.

Fortunately, there’s a way to get a handle on gap analysis and its ramification on accurate scoping.  You can automate gap analysis and scoping through interface management software.

And you can help your stakeholders understand why gap analysis and scoping are important to get right. That’s where our white paper, Rethinking HL7 Integration: Start with the Gaps, comes in. Here’s what it covers:

• The interfacing lifecycle and why scoping is critical
  • Examine the entire interfacing lifecycle
  • The critical role of scoping in the preparatory phase of scoping
  • Interfacing architectures
• Why gaps occur and what to do about them
  • Why are there gaps?
  • Why they are important
• The 4 gap types
  • Data structure
  • Data tables
  • Data semantics
  • Z-segments
• How to conduct a gap analysis
  • Obtain vendor documentation
  • Obtain customer spec/log
  • Document gaps
  • Deliver specification
• Gap analysis pitfalls and how to avoid them

Integration Governance Goes Beyond the Choice of Interface Engine

With today’s renewed emphasis on integrating the clinical enterprise, healthcare leaders need a thorough understanding of the complete interfacing lifecycle. Good interfacing governance goes beyond the choice of interface engine or integration technology. Today’s volume of interfacing projects requires improved interface management, from the scoping stage onwards.

Download the entire white paper: Rethinking HL7 Integration: Start with the Gaps