Redox

Why you should visit Redox if you’re visiting interface engine or EHR vendor booths at HIMSS

Posted March 5, 2018
By Nick Hatt

A few years ago, I wrote a post titled Why the world needs a new kind of interface engine. My message was about developer empowerment, over what I saw (and still see) in the interface engine world: bloated, hard to use, overpriced products that have long been “good enough” at solving the problems they are purchased for.

Since I wrote that post, we’ve partnered with hundreds of organizations who see the value in a platform like ours. We’ve turned a belief into a rapidly evolving reality and yet my core message, that the world needs a new kind of interface engine, has never been truer.

As the healthcare community descends on Las Vegas for HIMSS18 to discover what new developments are available to them, I want to revisit my original thesis and articulate why it should matter to you.

First, Redox is not just another interface engine. It turns out, the world needed something more than a cloud-based interface engine—it needed a platform that re-aligns all the incentives around integration.

To understand the healthcare integration landscape, and it’s current interoperability woes, it helps to think of it like an electric grid.

  • HL7 is the standards body—they set the gauge of transmission lines, voltage, building code, etc.
  • Vendor APIs are the solar panels of the world—they need special equipment to put data back onto the grid.
  • Traditional interface engine vendors make wiring. They may be the best, least resistant wires in the world, but you still have to install and maintain them yourself.
  • Interface teams at health systems are electricians.
  • The government is the government (unfortunately).
  • Redox is the utility company—we actually go out to the everybody’s house, give them the wires for free, and connect to whatever they may have (solar panels, old electrical wiring, a Don Quixote style windmill, etc.).

The reason the healthcare industry hasn’t had traction in interoperability is because up until now, no one has had the knowledge or the tools to make a utility company.

Interface engines developed because early HL7 adoption was not standard. They stopped at just being wires because building a network is a daunting business problem and they’re doing just fine selling appliances.

Networks like Commonwell and Carequality have a great mission and network, but they don’t provide the distribution infrastructure.

Vendor APIs are great, and in a lot of ways they are the future, but if you’re just charging your own Tesla with them, you’re not realizing the full value. You need something that is universally compatible.

Many people see efforts from HL7 and think that standards like FHIR solve this problem. It’s important to remember though that they only make the standards—they don’t offer any physical product outside of documentation and some sample code that they make.

The government can mandate that people follow HL7’s rules, but adoption takes time. Unlike electricity, slight variations from the standard don’t cause fires, they go unnoticed until you end up with a world where each instance of an EHR has slightly different FHIR implementations and we’re no closer to true healthcare interoperability than we are today with V2.

There’s a better way to share health data.

You may have arrived at HIMSS looking for a new interface engine solution or details on what APIs EHR vendors have recently made available, but the problem you want to solve is one we’re already solving at a much larger scale.

So if you’re going to check out the newest offerings from Intersystems, Corepoint, etc. or are looking to learn about the APIs available from Allscripts, Nextgen, etc. you should visit Redox’s booth (Hall A, #1275).

We’ve taken on the challenge of building healthcare’s first data utility company. Come learn what that means for you.