Just for fun, imagine you are, say, the customs agent at a 19th Century Italian port city. It’s your job to oversee the import and export of goods—and all the information surrounding those goods (shipping manifests, inspection logs, quarantine requirements, tariff assessments, etc.). Imagine you had taught French to your 50 clerks, as a common tongue, so that they could read and write foreign documents, and participate productively in the exchange and proliferation of all the metadata surrounding the various goods going in and out of the city.
Now, imagine the lingua franca changed on you, and you suddenly had to teach all your 50 clerks to speak English, instead. And not just to exchange greetings and pleasantries; but to engage in the highly technical jargon of commerce, carpentry, and warehouse management.
Health Benefit Consultants, Share Your Expert Insights in Our Survey
Miles Romney and RJ Gomez Miles David Romney is Co-Founder, CTO, and On-Staff Futurist at eVisit, leading the Product, Engineering, and Cybersecurity groups, and driving the company along an ambitious roadmap to 2050. RJ Gomez serves as Director of Solutions Architecture for eVisit where he oversees integrations with customer and third-party systems.
In migrating from HL7 v2 (or a proprietary format) to FHIR, your IT or engineering group will be doing just that: they’ll be teaching a dozen different systems to speak a new, highly technical language.
“HL7” is an international-standards developing organization—it’s the author of the FHIR standard. It is also the author of the standard that FHIR replaces: HL7 v2. FHIR, or Fast Healthcare Interoperability Resources, can most easily be understood as a data encoding standard—analogous to HTML (for example), but built specifically for formatting (or “encoding”) health data. Visualize an HTML page where every element is describing something about a person’s identity, health history, clinical encounter, diagnosis, chart, prescription, or (literally—by design) any other aspect of healthcare relating to a person. That’s FHIR.
HL7 v2 is a “columnar” format—like a spreadsheet. HL7 v3, or “CDA,” is far more advanced, with features that columnar formats just can’t deliver. FHIR expands on the capabilities of HL7 v3. FHIR is comprehensive and extremely versatile.
The FHIR formatting standard can be expressed either as XML (which you’ve likely heard of) or JSON (which maybe you haven’t). In either case, a collection of FHIR-formatted data makes up a “document,” just as you might think of an HTML “document,” or even a Microsoft Word “document” (which, incidentally, has its own XML-based data encoding format).
A Deep-dive Into Specialty Pharma
A specialty drug is a class of prescription medications used to treat complex, chronic or rare medical conditions. Although this classification was originally intended to define the treatment of rare, also termed “orphan” diseases, affecting fewer than 200,000 people in the US, more recently, specialty drugs have emerged as the cornerstone of treatment for chronic and complex diseases such as cancer, autoimmune conditions, diabetes, hepatitis C, and HIV/AIDS.
FHIR powers real-time
Those FHIR documents can be exchanged over web services. And that’s what a “FHIR API” does—exchange FHIR documents. But, where the interchange of HL7 documents was largely asynchronous (meaning, immediate responses were not required or expected), FHIR web services are typically synchronous. This allows for a new level of sophistication in data validation, and serialized requests (where a response may immediately trigger a follow-on request). Which, in turn, allows for a more selective, contextual, packaging of data.
Instead of sending a whole encyclopedia (and then relying on the recipient to extract the data that’s actually needed), you can send just a basic set of data, then allow the recipient to synchronously request whatever additional data is needed—and in the common expressions of XML or JSON, which are widely understood and supported. The application ecosystem widens, as a result, allowing for a diversified range of applications to participate securely in healthcare workflows.
Going back to our Italian port analogy, this means that you wouldn’t just be teaching your clerks English instead of French. You would also be equipping them with, let’s say, a telegraph: a device that materially improves their ability to validate and correlate information, faster than before.
FHIR APIs perform the same function that HL7 v2 interfaces do—they simply do it better.
Standardization is at the heart of civilization. Imagine standing in a circle with a dozen other people, each one of you speaking a different language. Without a common tongue, each of you would need to learn all the other languages or break into subgroups to selectively learn a few languages each, and engage in cross-translation—complex, and prone to error.
Consider instead, a standard language, which everyone in your circle learns; then each of you can act as a translator from your native language to the common tongue.
FHIR, as a successor to HL7 v2, is the common tongue of healthcare data encoding. Every EHR and health-tech tool can store data in whatever proprietary format it likes, so long as it translates to and from HL7 v2 or FHIR when it comes time to exchange that data with other systems. FHIR is the unifying tech layer—every system that would otherwise have to be multilingual, can be mono-lingual!
So then, let’s all do it, eh? Let’s migrate to FHIR and make the world a little better. Why not? Well, there are reasons.
The first among them is this: a lot of our healthcare systems are likely operating pretty well on HL7 v2. So, while a switch to FHIR is a “want-to-have,” it isn’t yet a “must-have.”
Because HL7 v2 is still so prevalent, many in our industry have kicked this can down the road, opting to stay with older formats “just a little longer.” This isn’t a wrong tactic, or even a poor one: prioritization of technical initiatives is its own brand of triage. But every dollar you spend maintaining an old format is a dollar lost.
Migration to FHIR is more than a change in vocabulary
Moving from HL7 v2 to FHIR isn’t just a shift in vocabulary, it’s a fundamental grammatical change, with implications to many healthcare data workflows. This will require, in many cases, redesigning those data workflows.
If you’re going to teach 50 French-speaking Italians to speak English instead, and to use a telegraph, you need to have the right people and the right resources, and you need to give them time.
In migrating, a great place to start is with the clinical staff and health IT application SMEs. Rather than just porting your HL7 v2 interfaces, take a step back and understand what your workflows are meant to achieve, then work backwards from there to identify the most efficient technical pathways—using the improved tools that FHIR puts at your service.
If you have capable IT professionals, then give them the mandate, give them the time and resources they need to master FHIR themselves, and then the space to implement it. Or turn to one of the many qualified specialist shops to design your migration for you. In either case, it will nearly always be worth the cost of engaging a specialist, at least as another set of eyes to review your migration plans. And if you find the time and cost estimates from your internal team to be much lower than one you receive from a specialist, lean conservative.
For some time to come, many of us will be supporting both. It would be lovely if we all, as one, could define a unified migration timeline, and all make the plunge at once. Alas, that is not the world we live in.
Progress may be hard, and costly, and inconvenient. But it’s worth it. And the day will come when a transition to FHIR is no longer optional, and more than that, it’s time sensitive. Don’t wait for that day.
Dive in, learn more, build in-house FHIR expertise, and engage contract specialists. FHIR has the power to birth a new generation of health and wellness applications, and a renaissance of health-data exchange.
Photo: sdecoret, Getty Images
Miles David Romney is Co-Founder, CTO, and On-Staff Futurist at eVisit, leading the Product, Engineering, and Cybersecurity groups, and driving the company along an ambitious roadmap to 2050.
RJ Gomez serves as Director of Solutions Architecture for eVisit where he oversees integrations with customer and third-party systems.
