A look at two different models of data consumption
There’s more integration via web services in healthcare taking place today than ever before. It’s clear that a real market shift is underway.
As more providers and vendors use native APIs to connect with major EMRs, the market of mobile devices such as wearables continues to grow, and early FHIR implementations show some legitimate promise, it appears the shift may only speed up.
Web services bring many benefits to the table, but for this post I’m going to focus on just one: web services give you more control over the data you consume.
To give some context to the above somewhat ambiguous statement, let’s consider the how data is consumed in the majority of HL7 implementations.
Broadcast vs Query:
Typically, when a health information system sends you an HL7 message, it contains some information that your receiving application is interested in and even more that it’s not. You are then tasked with filtering the messages that are not applicable and/or isolating the information that you and your application want. This hardly seems like an optimal way to exchange information.
Think about it: Why exchange huge CDA documents in their entirety when your application only uses a small fraction of it?
Using RESTful web services (albeit depending on the quality of the APIs), you can query for just the data you need at any given time, reducing the amount of patient data that travels over external connections and limiting the amount of filtering that you must do.
Another drawback of the broadcast model is the potential for lost data. When a system goes down or even when it’s just restarting, you might be missing critical information. Remember everything is happening in real-time. So, it’s like watching TV without the ability to record, pause or rewind. If you step away for any reason, you simply miss part of the story.
Using web services, a typical workflow involves querying for the latest information since a defined time frame. So, if you had a system go offline, the next time you establish a connection and query for information, you’re able to get access to everything that’s happened since your downtime. Nothing is missed or lost.
A shift does not signify an end.
If you haven’t already, you’re going to see more and more integration via web services in healthcare, but that doesn’t mean an abrupt end to other transport methods.
Just as you can’t always control what data standard is used, you can’t always control what transport mechanism is used either. You often have to simply work with what you’re given.
So, to best position your organization for success when it comes to integration, you should be able to handle web services just as easily as you can handle LLP implementations.
It’s true that integration is much more than just transport. But, it’s a potentially costly mistake to under-estimate its importance.
