The most significant gaps in interoperability
I recently returned from a quick personal trip to London. It was a jolly good time, filled with new friends and familiar experiences. Perhaps the only downside was the weather, but you can't ask for much in a city that's closer to the Arctic than the tropics.
If you've ever visited the home of Big Ben, you've likely taken the Tube and heard the unceasing refrain to "mind the gap between the train and the platform." This phrase, which originated in the 1960s, can be particularly helpful when the gap is rather large and dangerous. Thankfully, the chasms rarely cause anyone harm.
This naturally led the nerd in me to wonder, which gaps should we be paying mind to in healthcare interoperability? Interoperability isn't new, but its progress has been uneven and that has led to real-life disparities, both technological and practical. Interoperability's significant holes may not be as obvious as the empty space at Tube stations, but they are worth knowing and, more importantly, closing.
Webhooks are wanting
If you aren't familiar with webhooks, I plan to cover them in greater detail in a future post. For now, suffice it to say that webhooks are like push notifications in the world of APIs. Just like you might get an alert on your phone when there's a new email in your inbox, webhooks allow software system A to alert software system B when something new has occurred. A webhook message can be very simple, sometimes as little as the ID of the entity that was created or changed, or it can be more verbose and include details on what specifically changed, when, and by whom.
Webhooks are critical to full interoperability because they make APIs usable in event-based workflows, but sadly, webhooks have near-nonexistent support within healthcare IT. Among the major EHRs, none of them support true webhooks; athenahealth comes closest with its changed data subscriptions, but these differ from actual webhooks and are only available for athenahealth's proprietary APIs. The lack of webhooks means healthcare today must rely on clunkier non-API technologies, such as HL7v2 interfaces, to support event-based workflows like diagnostic orders and results. This makes it much harder for developers to innovate in specialties that rely on event-driven workflows.
Bulk is too basic
Sample any EHR's integration capabilities, and you will find the vast majority are designed for single-patient transactions. Epic, for instance, provides a wide range of integration capabilities, from HL7v2 interfaces to FHIR APIs to specialized web services for printing and device integration. When you need to retrieve or upload data across an entire population, however, the road becomes more arduous. You could try Bulk FHIR, but you'll face slow processing times, a limit of a thousand patients per request, and a constraint that the needed data falls within an available FHIR resource. Using Kit—Epic's method of opening up the Caboodle enterprise data warehouse to third-party vendors—will allow for larger pulls, but the database queries aren't free, and Kit includes a meager subset of all Epic data points.
With few exceptions, bulk data exchange simply hasn't been part of the culture of healthcare technology. This is somewhat understandable given the sensitive nature of healthcare data; no provider or payer wants a vendor to access more than the minimum necessary. Even today, the only federal regulation that touches on bulk data exchange is the requirement that certified EHRs support Bulk FHIR for the first version of USCDI—and this requirement only took effect seven months ago. Yet the industry must embrace bulk data transactions to enable advancements in artificial intelligence, population health, operations, and analytics. All these domains subsist on data, and lots of it, so we must make it easier for technology products to gather extensive amounts of data efficiently.
Can read, can't write
Similar to bulk exchange, the culture of healthcare interoperability has been far more focused on pulling data out of systems than pushing data in. None of athenahealth's FHIR APIs support writing to the EHR. Epic lists about 450 available FHIR APIs, yet by my count, only 32 allow for sending updates in. Yes, HL7v2 and X12 interfaces have historically had greater writing capabilities, such as the ability to create or update appointments, documents, and diagnostic results, but these point-to-point connections are more difficult to scale than APIs and often require a VPN tunnel to be configured and maintained.
If we accept the fact that much of healthcare occurs outside the walls of a hospital or clinic, then we must accept that other sources of healthcare data should be able to easily contribute to the patient's medical record. The ONC could help here by requiring EHRs to support bidirectional data exchange for USCDI.
Clinical has been king
Lastly, interoperability's emphasis overwhelmingly has been on clinical data, rather than operational, administrative, or financial data. For example, no major EHR provides a way for third-party apps to fetch hospital occupancy metrics through a single API. Likewise, EHRs have dragged their feet on releasing billing-related APIs, and robotic process automation (aka screen-scraping) has become a favored tool in revenue cycle due to the lack of interoperable alternatives. On the regulatory front, the first two versions of USCDI included only clinical data elements, and the recently finalized USCDI v4 has nine times as many clinical data elements as non-clinical.
The absence of a spectrum of APIs hinders the adoption of new tools, such as revenue cycle management products, automated coding systems, and IT administration apps. They also make data collection for public health agencies more arduous. Imagine if, during the height of the COVID-19 pandemic, the CDC could have simply called an API to know the number of staffed, occupied, and available beds at a hospital. It would have provided faster data collection while eliminating a complicated daily reporting task for overburdened health officials. No new technology is needed to close this gap; it just takes the willingness to make the interoperable exchange of all data a top priority.
---
Image by Greg Plominski from Pixabay
