All of a sudden, APIs are the flavor of the month in healthcare integration?
It’s simple: since true integration has never actually been delivered in the healthcare space, vendors serving other verticals—like hospitality, financial services, and gaming—are trying to position APIs as the integration “easy button” we’ve all been waiting for.
There’s only one problem: there is no integration easy button in healthcare.
In healthcare, where a hospital could have hundreds of software systems, an easy button isn’t possible. If it was, the industry wouldn’t have the multitude of regulatory and integration challenges it has today.
But in industries like hospitality, financial services, and gaming, where an enterprise may have only ten different software systems—and far fewer demands and integration challenges—APIs can be an effective tool.
So you can see how the confusion and misinformation is perpetuated, and why the myth around APIs persists: with APIs, the story goes, we can rest assured that we’ve found the way to integrate disparate systems, and that we’re always going to integrate systems this way, and via the same standard.
We’ve heard that before, haven’t we? Wasn’t that the promise of HL7 v2 and v3?
Yet isn’t it true that although v2 is still the prevailing standard, it’s never implemented the same way by every application software vendor?
And doesn’t it follow, then, that APIs, even if they’re 100 percent open-standard compliant, won’t be able to accommodate all the nuances and differences that are bound to crop up from countless implementations? Where will that leave anyone who doesn’t have those new APIs, but who nevertheless must connect flat and batch files, X12s, HL7 v2, and more?
Here are the facts:
- APIs are extremely attractive to the marketplace because they’re pre-built, pre-packaged, commoditized connectors that are easy to understand and use.
- Health IT software systems come in all shapes and sizes, and their vendors adhere to many different iterations of standards and data formats.
If you accept these facts, it becomes easy to recognize why the notion that a healthcare organization could buy a one-size-fits-all connector is flawed: everybody has a different data format.
So, you might ask, why don’t we just create an API that fits all of the formats?
Because it’s not possible. Not only is the number of formats essentially infinite, but vendors’ products aren’t static—they’re ever-evolving and constantly moving on to different iterations.
Now, let’s define the “last mile.”
In healthcare, there is a vast disparity between data formats. No two healthcare software systems speak exactly the same language—at most, they speak dialects of the same language. To adjust for this, most application vendors use commercial integration engines that resolve all the unique nuances among the various data-format dialects, and those integration engines are informed by the work of an actual human being who not only adapts one vendor’s data-format dialect to another’s dialect, but performs maintenance on that adaptation as the various vendors’ software products are revised.
That’s the last mile! And an API alone—with its fixed, rigid, static nature—simply can’t deliver the level of integration that last mile requires.
After taking in all of this, isn’t it clear why healthcare is different from every other industry, and how vendors serving other verticals are misleading their customers when they position APIs as the “easy button” we’ve all been waiting for?
Don’t buy into that fantasy.
Instead, recognize that APIs are just connectors, while integration—true integration—is something much more: the ability to connect anything to anything and convey any data, whether structured or unstructured, regardless of standards.
Does the vendor you’re considering as the steward of your last-mile integration challenge know this? Or are they hoping that you don’t know to ask about it?
