Ashavan brings clarity, certainty, expertise, and ease to healthcare data integrations. We make the best choice the easiest one.™

Four alternating red and yellow doors with slats

We make the best choice the easiest one™

Healthcare Interoperability Consulting

We are interoperability experts for the leading EHRs

Bring on a fractional Chief Interoperability Officer to define an interoperability strategy, guide a team, and deliver exceptional results


Executive leadership

Framed white certificate with a red ribbon

Publish on the Epic App Market, Cerner Code App Gallery, Allscripts App Expo, and athenahealth Marketplace


Vendor certification

Workflow diagram with a blue, green, and red box connected by yellow arrows

Design comprehensive and efficient integration solutions


Solution architecture

Build and maintain scalable integrations to automate tasks, reduce double documentation, and increase patient and provider satisfaction


Integration development

Implement your integrations quickly and smoothly while minimizing the burden for customers


Project management

Two stacked books with a mortarboard on top

Prepare your team for success by providing a strong foundation in FHIR, HL7 interfaces, bulk integration methods, ONC regulations, USCDI, HIPAA, and more


Education & best practices

The healthcare technology industry is a jungle

We can help

Word cloud with various words and phrases, such as very knowledgeable, makes it look easy, thorough, listened to our needs, great communicator, helpful, detailed, and proactive

And we have the Net Promoter Score to prove it

Our customers praise our work

Share this post

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

Statue of lady justice holding scales. The beam of the scales is emblazened with the Epic logo, and one scale tilts lower than the other due to a weight labeled Partners & Pals.

![Statue of lady justice holding scales. The beam of the scales is emblazened with the Epic logo, and one scale tilts lower than the other due to a weight labeled Partners & Pals.](/images/Epic-lady-justice-1694494800.jpg)

If it seems the past month has been good to a certain company in Verona, WI, you would not be wrong. Fresh off Epic's annual Users Group Meeting, [UPMC announced](https://www.healthcareitnews.com/news/epic-gains-new-ehr-clients-intermountain-and-upmc-move-cerner) it will transition its hospitals off numerous EHRs (most notably, Oracle Cerner) and onto Epic. Shortly thereafter, news broke that Intermountain will ditch Cerner and roll out Epic across the health system within about two years.

The favorable press actually began in mid-August, when Abridge revealed it is the first startup selected for Epic's [Partners and Pals](https://www.modernhealthcare.com/digital-health/epics-launching-third-party-vendor-program-nuance-abridge) program (PPP). The PPP is a new initiative where Epic collaborates with vendors established ("Partners") and up-and-coming ("Pals") to build deep integration with the Epic EHR and take the combined offering to market. In the last four weeks, [Talkdesk has joined](https://www.healthcareitnews.com/news/epic-adds-talkdesk-its-partners-and-pals-program) as the second Pal, and Nuance and [Press Ganey](https://www.pressganey.com/news/press-ganey-announces-collaboration-with-epic-to-advance-integration-of-patient-experience-insight-into-electronic-medical-records/) are slated as the initial Partners.

The PPP clearly benefits Epic by allowing the company to complement its EHR with a suite of workflow- or capability-specific technologies, most of which are leaders in their respective areas. Such partnerships haven't been common—Epic has always preferred building over buying—but they demonstrate where Epic feels it can't afford to wait to develop equivalent functionality.

##### Not so buddy-buddy

But what's good news for Epic isn't necessarily good news for healthcare. Whereas the direction of our industry has been towards greater interoperability and greater choice, the Partners and Pals initiative threatens to throw everything into reverse. Now, the powers that be in Verona will be able to handpick their favored companies and christen the resulting solutions. They will be able to design, develop, and release new integration options only to particular vendors, leaving everyone else at a disadvantage. Given how influential a stamp of approval from Epic can be, making it into the PPP truly could make or break the fortunes of these companies.

I'll readily admit that I could be reading too much into the situation. Perhaps the PPP is simply a go-to-market strategy with no technology benefits. Or, perhaps any new APIs and interoperability methods will be designed with multiple vendors in mind and shared openly to all who want them. If Epic publicly commits to making all integration options equally available to all vendors, at the same time and the same cost, and with input from allied and non-partner companies alike—then I'll gladly admit I was wrong.

But Epic's public comments on the matter—which, as is typical, are limited—don't inspire much confidence. A key executive for the PPP said it will create "new value for health care by curating unique collaborations...[where] Epic works with [participating companies] to develop deep integration for their products and services, helping them innovate quickly...." That's nice, but it would be far better if Epic created new value for healthcare by opening deep integration points equally and fairly to all vendors. We don't need Epic to pick the winners and losers; its customers can do that just fine when they have a robust set of choices.

##### Freedom over favoritism

I see no issue in Epic collaborating with other vendors to offer a more complete set of products and services to its customers. Epic can partner with whomever it wants. The integration capabilities that these partners use, however, should be equally and concurrently available to non-partner vendors as well. No EHR should limit the availability of integration capabilities or charge extra fees to one company vs another.

Based on what we currently know, nothing about the PPP falls within the category of openness, access, and equal opportunity. This flies in the face of a core element of interoperability. I have no doubt that other EHR companies are watching what Epic does to see how they could mimic it. Absent public commitments to openness and fairness from Epic, the PPP risks making seamless integration with the EHR accessible to only a privileged few, and if that happens, it'll truly stink for interoperability.


Epic's Partners and Pals smells like favoritism, and that stinks for interoperability - Nonstop Interop

Epic's Partners and Pals smells like favoritism, and that stinks for interoperability

Mail app icon on a smartphone screen with two unread notifications

![Mail app icon on a smartphone screen with two unread notifications](/images/Email-notification-1692680400.jpg)

A few weeks ago, I outlined [the most significant gaps](/blog/gaps-in-interoperability-20230803) in healthcare interoperability. In this post, I'd like to elaborate on what I view as the #1 gap: the lack of webhooks.

##### Push notifications for APIs

If you aren't familiar with webhooks, it's best to think of them like push notifications, but for APIs. Today you may have an email app on your phone, and that app will trigger a notification whenever you receive a new email. This is helpful (to a point—we all know how exhausting endless notifications can get) because it keeps you from having to constantly open the app and check your inbox for new messages. Instead, you know immediately when you receive something from your spouse, your favorite store, or that Nigerian prince who could make you rich.

Webhooks serve much the same purpose, though rather than alerting a human being about something different or new, they alert another software system. This permits App A to provide a news feed of sorts to App B, so that App B can keep up-to-date on what's going on in App A. Why does App B care? Staying in sync may be essential to get the maximum value from App B. For example, let's say a healthcare provider uses a CRM system for marketing and patient engagement. If a patient logs into the patient portal (App A) and updates their mailing address, email address, or cell phone number, the CRM (App B) needs to know about that change. Otherwise, future messages and marketing materials could end up undelivered or sent to the wrong patient.

When webhooks don't exist, that news feed becomes invisible to App B, and it must jump through numerous hoops to shine a light on the black box of App A. The most common workaround is polling, where App B pings App A every few minutes to check for any updates. Again, that's like having to jump into your email app to figure out if there's a new email. Not only is this detrimental to efficiency, because both apps must commit system resources to sending and processing the every-few-minute checks, but it can be easier said than done. Sometimes App A can't filter its response down to only the records that were added or changed since the last time App B polled; this means App B must pull back all the data it might care about and analyze it to figure out what's actually net-new. That would be like opening your inbox and seeing that every email is marked as unread, even though you've read most or all of them already.

##### Walking through a webhook

There's no standard for how a webhook must look; that's up to the sending system. It just needs to provide enough information so that the receiving system can take meaningful action. The below is an example of a very simple webhook, written in a format called [JSON](https://www.w3schools.com/js/js_json_intro.asp) ("jay-sawn") that's commonly used with APIs:

```
{
    "record_id": 129483,
    "event": "diagnosis_added",
    "event_date": "2023-08-17",
    "event_time": "5:23 PM CDT"
}
```

We can see that a diagnosis was added at a certain day and time, but we don't know what the diagnosis is, which patient it is for, when the patient first began having the issue, etc. We can discover that information, however, because the webhook includes an ID of the new diagnosis. We simply need to call an API with that ID, and we will get more details.

Contrast that with the below example of a more verbose webhook:

```
{
    "record_id": 129483,
    "record_name": "Pecked by turkey, subsequent encounter",
    "event": "diagnosis_added",
    "event_date": "2023-08-17",
    "event_time": "5:23 PM CDT",
    "patient_id": 90038273,
    "is_sensitive": false,
    "added_by": "Dr. Nonstop Interop",
    "is_primary_diagnosis": true,
    "icd_10_code": "W61.43XD",
    "start_date": "2023-08-16",
    "note": "Patient states the bird was having a bad day and didn't want to go in the oven."
}
```

Now we can determine details like the ICD-10 code and description of the diagnosis, and who documented the diagnosis in the patient's chart, without needing to make additional API calls. Each approach has its pros and cons, but in either case, the fact that we can immediately know when a new diagnosis is added to a patient's medical record provides a wealth of actionable value.

##### The status quo in health IT

Unfortunately, that actionable value is MIA in healthcare IT. Webhooks have near-nonexistent support within our industry; among the major EHRs, none of them support true webhooks, and only athenahealth provides a partial alternative.

How does this hurt healthcare? Webhooks are critical to full interoperability because they make APIs usable in event-based workflows. Let's take laboratory testing, for instance. Most lab workflows are event-based. A provider orders a test in the EHR, which triggers a notification to collect a specimen; the specimen is collected, which triggers accessioning and labeling; and the results are documented by the lab, which triggers a result message back to the EHR. Without an event-based communication framework, such as webhooks, the lab system would have to constantly poll the EHR for new orders, and the EHR would have to constantly poll the lab system to find new results. Not fun and not efficient.

For decades, healthcare has relied on HL7v2 interfaces as that event-based communication framework. Lab orders are sent as ORM messages, and results are returned as ORU messages. This certainly gets the job done, but these interfaces and similar non-API technologies are far from ideal. They don't use the latest data formats and technologies, which makes it difficult for modern app developers to support them in their products. The interfaces require a VPN to ensure the data transmitted remains secure. And they are inherently individual, point-to-point connections that are neither publicly discoverable nor easily scalable. Modern APIs overcome all of these limitations.

The lack of webhooks is the most important reason why point-to-point interfaces will not be obsolete anytime soon. There is hope on the horizon, however. Recently, the ONC accepted comments on its HTI-1 proposed rule, which would update several of the regulations surrounding EHR certification. HTI-1 includes a [request for information](https://www.federalregister.gov/documents/2023/04/18/2023-07229/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency-and#h-184) on FHIR Subscriptions, which are webhooks within FHIR, with ONC asking if "there is a need to define a minimum set of Subscription Topics that can be consistently implemented by all health IT developers of certified health IT." In other words, are there some webhooks all certified EHRs should support? Nothing in this rule, as proposed, would add a new regulatory requirement on EHRs to support webhooks. But it's evident that ONC is studying the issue and could propose such a requirement in the future, and when the day comes that webhooks are universally and robustly supported, that would close the biggest gap in healthcare interoperability.

\---

Photo by [Brett Jordan](https://unsplash.com/@brett_jordan) on [Unsplash](https://unsplash.com)


Webhooks are the biggest gap in today's interoperability - Nonstop Interop

Webhooks are the biggest gap in today's interoperability

Train platform with "Mind the Interoperability Gap" written in yellow

![Train platform with "Mind the Interoperability Gap" written in yellow](/images/Mind-the-interoperability-gap-1691038800.jpg)

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](https://www.mylondon.news/news/local-news/london-undergrounds-mind-gap-phrase-17178357), can be particularly helpful when the gap is rather [large and dangerous](https://www.mylondon.news/news/zone-1-news/london-underground-station-huge-gap-26713803). 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](/blog/evolution-interoperability-20230428), 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](https://docs.athenahealth.com/api/guides/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](https://fhir.epic.com/Documentation?docId=fhir_bulk_data), 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](https://docs.athenahealth.com/api/resources/complete_list_athena_apis#List_of_available_FHIR_APIs_7) support writing to the EHR. Epic lists about [450 available FHIR APIs](https://fhir.epic.com/Specifications), 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](/blog/uscdi-power-write-access-20220930) 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](https://www.healthit.gov/isa/united-states-core-data-interoperability-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](https://www.hhs.gov/sites/default/files/covid-19-faqs-hospitals-hospital-laboratory-acute-care-facility-data-reporting.pdf) 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](https://pixabay.com/users/gregplom-3802982) from [Pixabay](https://pixabay.com)


Healthcare Interoperability Consulting

We can help

Executive leadership

Vendor certification

Solution architecture

Integration development

Project management

Education & best practices

Our customers praise our work

We're passionate about interoperability

Epic's Partners and Pals smells like favoritism, and that stinks for interoperability

Webhooks are the biggest gap in today's interoperability

The most significant gaps in interoperability

Clarity, Certainty, Expertise, Ease

Ashavan - Healthcare Interoperability Consulting

Healthcare Interoperability Consulting

We can help

Executive leadership

Vendor certification

Solution architecture

Integration development

Project management

Education & best practices

Our customers praise our work

We're passionate about interoperability

Epic's Partners and Pals smells like favoritism, and that stinks for interoperability

Webhooks are the biggest gap in today's interoperability

The most significant gaps in interoperability

Clarity, Certainty, Expertise, Ease