In the next five years, healthcare interoperability will change dramatically. New standards for data exchange promise significant benefits: less expense, lower staffing fees, less lost in translation, and faster response through web APIs.

But when 90-percent of your legacy data is using HL7 v. 2, the future state may seem inaccessible. Will you be ready when the new standards are adopted? What is the best way to implement solutions without disrupting existing data?

The time to prepare is now. Here are four steps to evaluating your interoperability readiness so you can start taking advantage of all the benefits new healthcare interoperability standards have to offer.

STEP 1: Find Conversion Opportunities

What systems can be converted to support the new standard? Evaluate your current state and discover your system capabilities and evaluate opportunities to convert old, message-based formats to receiving APIs.

Some systems are leveraging HL7’s FHIR standard, others are shifting to a proprietary API. You’ll need to evaluate the direction of each of your vendor patterns and make some decisions.

STEP 2: Evaluate Highest Potential Value

Where will you see productivity gains and value adds first upon converting? Locating the low-hanging fruit will help you make the most of the interoperability readiness challenge. Conduct interviews with your vendor points of contact to determine whether their API offerings will increase the amount or quality of data being exchanged.

You may have multiple vendors targeting FHIR-based APIs in the future and leveraging a common platform to translate your messages into FHIR. API calls will provide a dramatic lift in efficiency versus multiple proprietary APIs.

Some of the message-based formats like HL7 version 2 and delimited files offer a strict dataset that might be expanded by leveraging an API. Determine which of your file-based formats are lacking in either content, frequency, or reliability, and supplement with API interfaces. Many of today’s most promising integration engines like Mirth, Corepoint, or Interoptex’s own integration platform can convert message-based formats to API calls.

STEP 3: Measure Performance and Value

Once you’ve begun making API calls to supplement your message formats, manage and measure the performance of the new data coming in. Are you seeing gains in the content, frequency, or reliability of the data being exchanged? Are your API-based interfaces more or less finicky than your message-based formats? Try and test, then re-evaluate if you are not realizing the value.

STEP 4: Develop Your Long-term Integration Roadmap

Based on your early trials, develop your long-term plan for adopting the new interoperability standard and re-evaluate annually. This is a marathon, not a sprint, and the release of new legislation or a new standard requires you to be flexible.

A Few Watch Points

When making the transition, watch out for these potential stumbling blocks:

  • Make sure your new integration initiatives are performing reliably – and you’re proactively reporting failures and altering code
  • Don’t write proprietary API code without a definitive value. Coding to a small system’s API when they offer messaging formats that use existing standards like HL7 or C-CDA could be wasted effort
  • Keep an eye on new legislation. For instance, Meaningful Use 3 is “proposing the use of APIs that could enable the development of new functionalities to build bridges across systems and provide increased data access.” This specific push for interoperability may shift the direction of many vendors, though we likely won’t see the same adoption as MU2 due to the lack of government incentives for compliance.

Finally

When you’re thinking about interoperabililty and how to address the new standards, consider the capabilities of your platforms and internal resources, and don’t forget to reach out to Interoptex for help.

 

Seth Hobgood is CTO at Interoptex.