Share this post

Subscribe to the blog

Latest from Nonstop Interop

Poker scene from the movie Casino Royale with text overlaid

![Poker scene from the movie Casino Royale with text overlaid](/images/Casino-royale-1727931600.jpg)

Over the summer, ASTP (formerly ONC) released [HTI-2](https://www.federalregister.gov/documents/2024/08/05/2024-14975/health-data-technology-and-interoperability-patient-engagement-information-sharing-and-public-health), a massive proposed rule with widespread implications for stakeholders across the healthcare ecosystem. This regulation is focused on two important things. First, it broadens the interoperable capabilities of health IT to support a greater variety of workflows, and second, it increases the reliability and trustworthiness of the data exchanged. In some cases, new requirements will unlock brand new workflows and open the door to previously unavailable outcomes. More often, changes will increase the utility of data by improving its reliability or timeliness.

The word you will see often both in the rule and in this post is "standardize." Standardization is desperately needed across healthcare, and in HTI-2 ASTP has proposed to expand and update the code systems, protocols, and implementation guides that certified health IT systems would be required to adhere to. There are plenty of summaries out there to peruse, so this post will instead dive more deeply into a couple of the rule's key provisions and explain why we at Ashavan are so excited about their implications.

##### A combo draw for public health

HTI-2 packs many new public health data exchange requirements that concern not only provider-facing health IT like EMRs, but also Public Health Agency (PHA) health IT. This is an important acknowledgement by ASTP that both participants in a public health data transaction are responsible for its outcome and that efficacious bidirectional exchange of data will lead to the greatest utility of shared public health data. Our discussion will focus on the new certification criteria for the health IT used by PHAs.

HTI-2 proposes a baseline level of data exchange functionality for all certified PHA health IT systems. Important new requirements like a standardized data transport mechanism, data validation logic, and support for querying and filtering would be included in this baseline functionality. This would create much clearer expectations for external systems when sending data into or receiving it from PHA systems, leading to an environment in which stakeholders can better trust public health data quality and access it when needed.

Let's look at how HTI-2's proposed criteria would impact immunization data exchange as an example use case. Today, there is no standardized data transport mechanism that all PHAs must support to send and receive immunization data. This has led to mismatched, incompatible integration interfaces between EMRs and PHAs' Immunization Information Systems (IIS) and particular barriers to accessing immunization data from multiple states. HTI-2 would require PHAs' certified health IT systems to adopt SOAP-based data transport. We would prefer to see ASTP jump straight to FHIR APIs as it did for the public health FHIR API requirement for EMRs, but possibly more important than the chosen standard is the fact that a standard would now exist, allowing for more consistent and predictable connections with PHAs.

Equally important is today's lack of minimum validation logic required of PHA health IT when ingesting and storing immunization data. Data submission errors such as an invalid CVX code or missing required data like a vaccination date hurt data quality and erode users' trust. HTI-2 proposes that certified health IT for PHAs incorporate specific data validation, including data mapping, null value interpretation, and proper error detection, into the data ingestion process. This should create a baseline level of data quality that consumers of IIS data can expect.

Additionally, new requirements in HTI-2 mean that certified IIS would need to support a minimum level of querying and filtering. Say a patient comes to the emergency department after stepping on a nail, and their provider accesses the local immunization registry to determine the date of the patient's last tetanus shot. Without a way to filter down to only pertinent immunization data, the provider may see and need to hunt through a long list of vaccinations. But with HTI-2, that registry's software must be able to filter by a specific vaccine code, making it much easier for the provider.

While some of these changes may seem modest at first glance, ASTP's proposed requirements would finally establish clear baseline capabilities of PHA health IT systems to exchange public health data with a wide variety of stakeholders, including clinicians, researchers, and other health agencies. The COVID-19 pandemic highlighted the need for efficient exchange of public health data, including immunizations, disease transmission, drug prescribing, and lab results. This regulation would guide the US' public health ecosystem towards a future where public health data of verifiable quality can be exchanged through repeatable, secure integrations.

##### Showdowns through subscriptions

FHIR adoption in the U.S. healthcare system has been limited in supporting real-time workflows at the point of care, primarily because many EMRs have implemented FHIR without enabling external systems to detect data changes with [webhooks](/blog/webhooks-biggest-gap-interoperability-20230822). As a result, implementers often must rely on older integration modalities like HL7v2 for event-driven triggers. Some EMRs like athenahealth have implemented proprietary APIs to accommodate these types of workflows, and others like Epic and eClinicalWorks support the CDS Hooks specification, which allows the exchange of real-time data for clinical decision support in specific scenarios. That said, a standardized, API-based means of triggering real-time data exchange from within a source system has yet to be adopted across the health IT landscape, which has severely curtailed health IT innovation.

To address this gap, HTI-2 proposes the widespread adoption of the FHIR event subscription framework. This FHIR-based protocol would allow external systems to "subscribe" to notifications when a particular "event" occurs in a health IT system. For example, when a new lab result appears in an EMR, subscribers of that event would be notified, allowing them to retrieve those lab results from the electronic health record via a FHIR API request. Imagine if a patient's care team members could subscribe to each other's patient updates. Patients could identify new providers in pre-appointment questionnaires to allow for the exchange of EMR endpoint information. Then, when the patient's psychiatrist updates the dosage of a medication they are taking, the primary care physician's EMR would be alerted to this change. It could make a subsequent FHIR API request to the psychiatrist's system to get the medication update and notify the PCP of the change. This could all be implemented with a small fraction of the effort and cost needed to accomplish the same thing through an HL7v2 interface.

The proposed initial rollout of the FHIR event subscription requirement in HTI-2 focuses primarily on clinical data contained in key FHIR resources like Condition, DocumentReference, Immunization, MedicationRequest, Observation, and Patient. Subscribing health IT systems would be notified when a FHIR resource they are subscribed to is created or updated, allowing it to immediately retrieve those changes. We're pleased that ASTP incorporated filtering capabilities into the proposed subscription requirements; for example, Encounter subscriptions must be filterable on reasonCode, patient, and type.

The implications here are extensive. With better real-time data exchange, clinical decision support use cases expand dramatically. Contraindicated medications that a patient is on could be identified without relying on the patient properly relaying the changes to their care team. Public health agencies could be alerted in real time when a new case of a disease is identified, and details of the case could be made available in their systems immediately upon the diagnosis being documented in the provider's EMR.

In practice, use cases like these may be limited in the near-term, but the reason for this is much less likely to be technical in nature. These new requirements improve the repeatability and durability of event-driven data exchange by allowing us to finally move on from the HL7v2 standard and alter the cost-benefit analyses of decision-makers considering whether to invest in these types of integrations.

##### More ways to win

The proposed changes in HTI-2 are immense and this article has hit on only a subset of the changes that will take effect if the rule is finalized. We'll be following closely as HTI-2 makes its way through the finalization period. Given the impending presidential election and subsequent change in administration, it will be worth seeing whether ASTP is able to finalize HTI-2 in the near future. Overall, we applaud ASTP for proposing regulations that go all-in on advancing healthcare interoperability and improving patient outcomes.


With HTI-2, the feds go all-in on interoperability - Nonstop Interop

With HTI-2, the feds go all-in on interoperability

Get new post notifications in your inbox


Calendar on a light brown desk next to a green money plant

![Calendar on a light brown desk next to a green money plant](/images/Calendar-1736920800.jpg)

In recent weeks, HHS and its agencies have been anything but slackers. Each of the past three months has brought some kind of notable rulemaking that moves the needle on interoperability. In November, it was a proposed rule on [provider disincentives](https://www.federalregister.gov/documents/2023/11/01/2023-24068/21st-century-cures-act-establishment-of-disincentives-for-health-care-providers-that-have-committed) for information blocking. The ONC followed in December with its latest final rule for Health IT Certification, known as the [HTI-1 rule](https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program). And just last week, CMS issued its most important [interoperability-related rule](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f) since 2020, one that adds a host of requirements for prior authorization-related FHIR APIs.

But while our federal government no doubt moves, it doesn't necessarily move quickly, and it doesn't always ask others to move quickly either. The prior auth rule is a good example. Impacted payers—which include Medicare Advantage insurers, state Medicaid and CHIP programs, and payers who offer federal marketplace plans—have until January 1, 2027, to release their prior auth APIs, and these APIs only need to cover prior auth for procedures, not drugs.

Though I don't want to minimize the challenge of this task, three years is far too long a wait until prior auth begins to emerge from the Stone Age. If we want to rapidly improve prior authorization processes—and, more generally, accelerate the advancement of interoperability in healthcare—we should invest in financial incentives.

##### PA = Pretty Awful

Prior auth is basically a reality of life. If you have insurance and need a consultation with a specialist, a complex procedure, or an expensive medication, your insurance company will likely require pre-approval before agreeing to pay. This extra hoop to jump through doesn't please providers; 89% of respondents to [an AMA survey](https://www.ama-assn.org/system/files/prior-authorization-survey.pdf) said the prior auth process has negatively impacted their patients' care, and 88% feel it is a burdensome task.

Burden equates to wasted time and money. It's at such an extreme that [CMS estimates](https://www.federalregister.gov/public-inspection/2024-00895/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability) its final rule will collectively save practices and hospitals 230 million hours and $16 billion over 10 years. The Council for Affordable Quality Healthcare, which tracks adoption of electronic transactions for administrative workflows under HIPAA, is less generous, with its most recent estimate that fully electronic prior auth would save the industry (providers and payers) [$450 million annually](https://www.caqh.org/sites/default/files/2023-05/2022-caqh-index-report.pdf). (Note: CAQH defines electronic prior auth as X12 278 transactions, not API-based transactions, since HIPAA mandates the former.)

##### Moolah to get moving

Whichever estimate you believe, there's the potential to cut hundreds of millions of dollars in unnecessary spending by getting our industry to embrace modern technology—and that's for only one portion of a single workflow. But we're leaving that money locked up and out of reach if most payers (legally) delay deployment of the prior auth APIs until 2027. I don't begrudge CMS for setting that timeframe; insurance companies have a lot of work ahead of them, from [translating their prior auth criteria](/blog/cms-prior-auth-rule-20230302) into machine-computable rules to developing and testing their APIs, and no one wants to see a hasty and flawed rollout.

But that doesn't mean there aren't ways for public and private players to encourage the availability of prior auth APIs sooner. If payers release their APIs in 2025 or 2026, their billing providers will realize enormous savings sooner. One idea would be for providers and payers to arrange to share in these savings until the official deadline arrives. Another option could be for the federal government to temporarily increase payments or cost sharing for those leading-edge payers. Both approaches would reward innovation, speed, and efficiency and would still result in overall savings for our industry.

I will admit, this is an idea with holes and flaws. For one, any financial incentives from Washington will have to be paid for, because [our national debt](/blog/interoperability-debt-pie-20230525) isn't getting smaller. Second, the payers' prior auth APIs are less than helpful if EHRs don't support transacting with them, so some sort of benefit has to be considered for EHRs that provide early support.<sup>1</sup> And calculating, documenting, and exchanging the savings resulting from the prior auth APIs could be a burdensome process itself, negating some of the overall benefits.

Nonetheless, if we want to go big on prior authorization, we have to dream big. Thinking more broadly, I believe financial incentives should be regularly in play for high-value/high-impact interoperability initiatives. For example, [webhooks can add significant value](/blog/webhooks-biggest-gap-interoperability-20230822) and open the door to new innovations, so EHRs should be incentivized to offer webhooks until they are mandatory.

Right now the pace of change in interoperability is essentially the speed at which Congress passes new laws and HHS issues new rules—in other words, a slow, methodical grind. When greater interoperability can bring greater efficiency, lower spending, and healthier lives, we should be willing to commit money upfront to realize those benefits. In business, when you want something done, you invest not only time but also money into making it happen. Healthcare in America is a business, and interoperability must be one of its most important investments.

\---

Photo by [Blessing Ri](https://unsplash.com/@blessingeffect) on [Unsplash](https://unsplash.com)

###### Notes

**Note 1: EHRs and prior auth APIs**

CMS' prior auth rule does not affect EHRs in any way. Any rulemaking to require EHRs to support prior auth APIs would need to come from the ONC. It is widely expected that the ONC's next rule for Health IT Certification, the HTI-2 rule, will include this requirement when it is proposed this year.


It pays to incentivize interoperability - Nonstop Interop

It pays to incentivize interoperability

![Apple hearts Google](/images/Apple-hearts-Google-1701151200.jpg)

You might've missed Apple's big announcement this month. If so, you're forgiven. What should have been a wave felt more like a ripple, because news about interoperability—unlike news about Taylor Swift—rarely makes headlines.

Beginning in 2024, Apple will reverse years of resistance and [start supporting](https://www.theverge.com/2023/11/16/23964171/apple-iphone-rcs-support) Rich Communication Services (RCS) for messaging with non-Apple devices. If you've ever used a modern messaging app that works over Wi-Fi or that shows you when the other person is typing a response, it's possible that you were using RCS. This announcement doesn't mean Apple is suddenly an altruistic industry player—the company is likely responding to [European regulations](https://www.privacyworld.blog/2022/10/dma-eu-publishes-the-new-digital-markets-act/) and [scrutiny](https://www.theverge.com/2023/9/6/23861030/imessage-bing-european-union-commission-digital-markets-act-dma)—but it does portend a more complete, satisfying, and interoperable messaging experience for millions of people.

##### A tell-all on protocols

To appreciate why Apple's shift is a big deal, we need to dissect what it actually means. The word to know in telecommunications is "protocol," which you can think of as a standard that describes how devices and networks can communicate. Analogous to how APIs facilitate data exchange between software applications, communications protocols allow the happy birthday text you type out for your cousin to leave your device, traverse the globe, make it to the correct destination phone, and display accurately for the birthday boy.

Texting has been around for decades, but for most of that time, it's been based on SMS, a protocol from the 1980s. SMS has done its job well and is universally supported, but it has some drawbacks. For one, it sends messages over a cellular network, so you must have a phone plan. It technically only supports messages of 160 characters (even less than Twitter!), though carriers handle breaking up and reassembling longer texts for us. And SMS' support for sending images and videos, via an extension to the protocol known as [MMS](https://www.twilio.com/en-us/learn/messaging/what-are-sms-and-mms), is pretty limited in terms of the size and quality of the files.

In recent years, new kinds of messaging apps that use the Internet, rather than cell networks, have exploded in popularity. WhatsApp, WeChat, Messenger, and Signal are but a few examples. These apps provide numerous handy features like larger message sizes and the ability to see whether your message was sent, received, and opened. Phone carriers wanted to bring an equivalent experience to their subscribers, so they banded together and developed RCS as the industry-standard protocol to do that. Carriers and device manufacturers have 260 pages of [open specifications](https://www.gsma.com/futurenetworks/wp-content/uploads/2019/10/RCC.71-v2.4.pdf) to implement, and the end result allows you and I to do things like transfer files during a call or resize images and videos before sharing them.

##### Apple finally bites

RCS is not supported by everyone, however, and that brings us to the world's most valuable company. Apple is well-known for erecting a walled garden and locking users into its ecosystem. Its Messages app is available only on Apple devices and uses a proprietary protocol called iMessage. For messaging with non-Apple devices, Messages falls back to SMS/MMS. Those non-Apple users appear in a conversation with green bubbles, rather than the traditional blue, and up till now, Apple has stubbornly declined to provide a modern or commensurate experience. One of its go-to arguments has been that iMessage offers superior security, since RCS does not natively address encrypting messages end-to-end.

Google and Samsung, on the other hand, have embraced RCS and [publicly advocated](https://www.android.com/get-the-message/) for its adoption; Google has tried publicly shaming Apple into changing its mind, even making the rather [dubious claim](https://www.usatoday.com/story/tech/2022/01/10/google-imessage-iphone-text-messages/9155873002/) that the different colored bubbles represent a form of bullying. The effort was fruitless for years, however, until Apple's declaration on November 16 that RCS support is coming and that the company will work with industry stakeholders to improve the standard's security.

To be clear, this decision does not mean iMessage is going away or that Apple is opening up any new integration opportunities. Apple will continue to use the closed-source protocol for Apple device-to-Apple device communication. We the people will still be divided into blue and green camps. RCS will simply replace SMS/MMS as the primary protocol for communicating with non-Apple devices.

##### Slow and steady

It's a small step forward, but also a significant win for interoperability. The fundamental goal of interoperability is to be able to exchange data between systems and to have that data be equally usable and understandable regardless of where it lives. Apple's decision advances that aim, bringing greater parity to the exchange of messages across platforms and allowing everyone in the world who has or communicates with an Android device to enjoy texts, images, and videos in equal measure. And that is truly big news.


The biggest news in interoperability isn't in healthcare - Nonstop Interop

The biggest news in interoperability isn't in healthcare

Child in a pink shirt and gray vest holding a book with a look of surprise on his face, with overlayed text that says "Warning: APIs may cause great excitement in minors"

![Child in a pink shirt and gray vest holding a book with a look of surprise on his face, with overlayed text that says "Warning: APIs may cause great excitement in minors"](/images/Surprised-child-1698382800.jpg)

"Is this hacking?" he asked.

Taken aback by the question, I ad-libbed, "Well—not really, but it's a little like legal hacking."

"This is so cool," he replied.

That was a snippet of a conversation with a middle schooler, as I introduced him to the world of APIs. I volunteered this week at a public middle school here in Nashville; it was Family STEAM Night, and a variety of businesses were showcasing careers and opportunities in science, technology, engineering, the arts, and math. A little surprisingly, Ashavan was the only tech company in attendance, but that didn't make us the biggest draw. The gentleman at the adjacent table had a live snake the kids could pet; it's tough to compete against that.

Nonetheless, a good time was had. I was there to teach kids about APIs and how you can make a career out of getting totally different software systems to talk to one another. The demo was simplistic, a couple of API calls between Postman and Salesforce, but it resonated with the students. They had no idea apps on a phone or computer could exchange data back and forth.

##### Connecting to more kids

The experience made me realize that we should be exposing our children to APIs in K-12 schools. We've made strides in incorporating computer science into curriculum, with the Code.org Advocacy Coalition [reporting](https://advocacy.code.org/stateofcs) that now over half of high schools in the US provide a computer science course. And [54% of the states](https://advocacy.code.org/2022_state_of_cs.pdf) require schools to offer computer science, with five of those (Arkansas, Nebraska, Nevada, South Carolina, and our home of Tennessee) implementing computer science courses as a high school graduation requirement.

Yet these courses focus heavily on hands-on-keyboard coding, and there's more to software and technology than simply building the tools. There's also design thinking, system architecture, and solutioning. There's security, performance, and data privacy. You can build a successful foundation of knowledge—and a well-paying career—without becoming an expert in a programming language.

APIs can be a powerful conduit for teaching all of these things. Now, granted, truly understanding APIs requires deep, high-level thinking skills that younger kids probably won't have developed yet. The [K-12 Computer Science Framework](https://k12cs.org/wp-content/uploads/2016/09/K%E2%80%9312-Computer-Science-Framework.pdf), developed by Code.org and a few other organizations, appropriately reserves API concepts for high schoolers. And APIs aren't exactly flashy and exciting to most people; writing a Python script that causes a toy robot to turn and move feels more rewarding.

However, I believe APIs have a place within computer science curriculum, and we can and must do a better job of introducing them at an early age. We can do this by relating API concepts to the real world and demonstrating the practical effects that arise when software is interoperable. Here's one idea: have younger students roleplay as apps and data points. The "apps" could call out commands to send or retrieve data points, and those "data points" could run back and forth between the connected apps. But if an "app" gives an invalid command, no data will move. It's a simple way to demonstrate technical communication while incorporating some physical activity.

##### Mix in some magic

Despite studying education in college, I'm by no means an expert on the best approach here. We have educators who are better suited for baking APIs into school curricula than an interoperability nerd like me. But what I do know is that we should do it. APIs are magical things; they break down barriers and spur innovation. Let's expose our kids to that magic in the right way and at the right pace, and hopefully we'll bring greater understanding and a brighter future to a few more (legal) hackers.

\---

Image by [Ben White](https://unsplash.com/@benwhitephotography) on [Unsplash](https://unsplash.com)


We should teach our kids about APIs - Nonstop Interop

We should teach our kids about APIs

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)


The most significant gaps in interoperability - Nonstop Interop

The most significant gaps in interoperability

![Pile of coins](/images/Coins-1736920800.jpg)

The President of the United States is not a fan of fees. [Hidden fees](https://apnews.com/article/biden-junk-fees-pricing-livenation-airbnb-10c32ecf2306cad8123d55c392a8b887) for an Airbnb or concert ticket? He wants them wiped out. Overdraft and bounced check fees [from banks](https://apnews.com/article/inflation-biden-business-economy-government-and-politics-39153f8d641f587e2fccb53f94371401)? They've gotta go.

President Biden's [latest push](https://apnews.com/article/biden-health-care-insurance-prescription-drugs-e8960514ff32bcc37bb8becccf3112cf) against so-called "junk fees" dipped into the world of healthcare. Ten days ago, he announced a [new federal rule](https://www.federalregister.gov/documents/2023/07/12/2023-14238/short-term-limited-duration-insurance-independent-noncoordinated-excepted-benefits-coverage) to restrict short-term, limited-duration insurance (STLDI) and [new guidance](https://www.cms.gov/files/document/faqs-part-60.pdf) requiring healthcare facility fees to be revealed upfront. STLDI usually carries capped benefit amounts and doesn't cover pre-existing conditions, so the Biden administration is proposing to revert STLDI back to a maximum coverage period of three months. (President Trump's administration had extended it to 364 days.)

Some will cheer these changes, and some will criticize them. But for the interoperability community, we should be pushing the White House not to forget about healthcare's other junk fees—high fees for interoperability. There's a host of charges that impede frictionless data exchange and hinder innovation, and they've become ingrained within the culture of healthcare interoperability. It doesn't have to be this way, though, and we need the backing and attention of the President (and Congress) to reduce those costs.

##### HL7v2 interface fees

Let's start with an oldie but not-so-goodie. HL7v2 interfaces have been around for decades, and they are synonymous with high fees. [Epic's approach](https://www.epic.com/Docs/MUCertification.pdf) is typical; either you pay a one-time licensing fee plus an ongoing annual maintenance fee, or you package those together into one recurring fee (see the bottom of page 13 of the linked PDF). Either way the cat gets skinned, you will be bleeding.

EHRs generally don't disclose the exact costs, but it's [common knowledge](https://community.spiceworks.com/topic/175107-hl7-interface-cost-and-maintenance) that they run from $10,000-$20,000 per interface. When you think about the typical number of interfaces at play at a typical health system—ADTs, SIUs, ORMs, ORUs, DFTs, MDMs, and more—that's a hefty amount going towards interfaces. And keep in mind, those are simply the license and maintenance fees. Implementation service fees for establishing and configuring the data connections will require even more moolah.

##### API fees

APIs are the new way to interoperate, but the old habit of charging for them remains. Thankfully, many EHRs no longer charge integrators for using FHIR APIs required by USCDI, but that doesn't mean costs have been entirely eliminated.

Epic, for example, has shifted some of the burden away from third-party vendors and onto its customers. Health systems on Epic must pay [subscription fees](https://fhir.epic.com/Download/ApiLicenseAgreement) in order for its FHIR APIs to be usable by vendors (see section 5 "Subscription and Other Fees"). Oracle Cerner takes [a similar approach](https://www.cerner.com/certified-health-it), imposing a host of setup and annual fees that could bring the price of a first-time implementation to over $50,000 (click the "Keep Reading" button under the "Certified API Technology Fees" section). And several EHRs offer so-called ["non-certified"](https://docs.athenahealth.com/api/resources/complete_list_athena_apis) or "private" APIs that come with per-transaction costs; the amounts vary, but I've seen transaction fees range from 1 cent to $1.24 per API call. That can be cost-prohibitive for apps with a large user base or that need significant amounts of data.

##### Exclusive marketplaces

In fairness to EHR companies, platforms' charging fees for interoperability is not new; [Apple](https://arstechnica.com/gadgets/2021/03/google-undercuts-apple-with-new-15-revenue-share-for-certain-play-apps/), Google, [Salesforce](https://developer.salesforce.com/docs/atlas.en-us.packagingGuide.meta/packagingGuide/appexchange_checkout_rev_share.htm), and [Shopify](https://shopify.dev/docs/apps/store/revenue-share)—just to name a few—have been milking app developers for 15-30% of revenue for years. The main reason they can do this is that they host exclusive marketplaces and developer programs. Want to create an awesome iOS app? You'll have to play by Apple's rules, get approved for their App Store, and share a large chunk of your revenue with them. Any attempt to wriggle yourself out of these handcuffs will get you booted and banned.

EHRs have striven to copy this approach, though thankfully information blocking rules and certified FHIR API requirements have ensured some open integration methods remain. Nonetheless, EHRs maintain a level of monopoly over how integrators distribute apps to health systems. You can't simply search the Internet and download any app you desire from wherever you'd like, such as a competing marketplace. Instead, integrators must register and distribute their app within the EHR's designated developer portal. Furthermore, getting your app listed on an official marketplace to showcase and market your offering will require a big wad of cash; Cerner, for example, asks for [$25,000 per year per app](https://code.cerner.com/apiaccess) and $3,000 per production connection. The lack of choice, and the high fees it engenders, are simply wrong.

##### Unchain us from these charges

To borrow from Christopher Bullock (not [Benjamin Franklin](https://en.wikipedia.org/wiki/Death_and_taxes_%28idiom%29), you may feel that nothing in life is certain except death, taxes, and integration fees. You know they're a problem when the federal government must bake language regarding fees into its [information blocking rules](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-171/subpart-C/section-171.302), so that vendors are on notice that excessive charges will not be tolerated. To be clear, I don't believe companies should be prohibited from levying anything at all, and I also acknowledge how serious it is to ask government to intervene in matters of business. As a business owner, I don't take that lightly. However, I firmly believe interoperability is such a core part of our personal and national health that more should be done to get it down to [a fair price](/blog/fair-price-interoperability-20230622). Mr. President, I hope you'll make healthcare interoperability the next task in your battle against junk fees.

\---

Photo by [Shopify Partners](https://www.shopify.com/stock-photos/@shopifypartners) on [Burst](https://www.shopify.com/stock-photos)


Mr. President, don't ignore interoperability's junk fees - Nonstop Interop

Mr. President, don't ignore interoperability's junk fees

Notification box from Reddit stating that the mildly interesting subreddit is private in protest of Reddit's proposed API changes

![Notification box from Reddit stating that the mildly interesting subreddit is private in protest of Reddit's proposed API changes](/images/Reddit-private-community-1687410000.jpg)

When the Internet is mad about something, it goes for shock and awe. As [far back as 1996](http://www.cnn.com/TECH/9602/cyber_censors/index.html), websites have intentionally gone unusable in the hopes of jolting the public into action or depriving corporate antagonists of money. [The 2012 uprising](https://en.wikipedia.org/wiki/Protests_against_SOPA_and_PIPA) over two pieces of federal legislation prompted social media sites to go dark, led to GoDaddy temporarily losing thousands of domains, and ultimately killed the proposals.

Last week many Reddit communities (aka subreddits) waged civil war in protest of the [company's own changes](https://www.reddit.com/r/reddit/comments/145bram/addressing_the_community_about_changes_to_our_api/). Reddit announced in April that, among other things, it would begin charging for API calls, and [the anticipated costs](https://www.reddit.com/r/apolloapp/comments/13ws4w3/had_a_call_with_reddit_to_discuss_pricing_bad/) have spurred popular Reddit apps to announce they will shut down. This comes on the heels of Twitter's move to [monetize its API](https://www.wired.co.uk/article/twitter-data-api-prices-out-nearly-everyone) and [cut off](https://www.theverge.com/2023/1/19/23562947/twitter-third-party-client-tweetbot-twitterific-ban-rules) access to any competitor apps.

Frankly, if Reddit were a healthcare software company, its announcement would have been a nothingburger. What to some may seem like a sudden and exorbitant shift is par for the course in our industry. Integration fees are far too common (and excessive) in healthcare technology, and Reddit's saga teaches the healthcare IT community an important lesson: we need to reframe what's a fair price for interoperability.

##### Summarizing the swordfight

A heaping amount of context is necessary. First, Reddit is unique among the major social media companies in that it grants the moderators of subreddits a large amount of control. Beyond complying with a few platform-wide regulations, moderators set the rules, police their community, and determine the visibility of content. This power is the price Reddit pays in exchange for having volunteers handle the vast majority of oversight. Rather than face the expense and controversy inherent to the top-down approach Twitter and Facebook take, Reddit can lay some foundational rules and leave the rest to ordinary users.

Secondly, Reddit's changes affect its API in a few ways. New API rate limits will go into effect on July 1. Additional fees begin to apply to apps making more than 100 API calls per minute, and they come out to 0.024 cents per API call. Since some popular Reddit apps make tens of millions of API calls per day, however, those app creators will face thousands of dollars in expenses. Users despise this because the official Reddit app allegedly has poor moderation tools and [isn't accessible](https://www.reddit.com/r/Blind/comments/14ds81l/rblinds_meetings_with_reddit_and_the_current/) for the visually impaired, thus many have gravitated towards third-party replacements.

Why is Reddit implementing these changes? As always, interoperability boils down to [data and power](/blog/interoperability-data-power-20220607). Reddit holds an enormous amount of user-generated data written in a variety of styles, much of which is publicly accessible without a login. Tech companies have taken advantage by using Reddit's API to pull down gobs of data and train their AI algorithms on it. In essence, Reddit is subsidizing the advancement of AI and it wants the power to monetize that. Additionally, when third-party apps use the API to serve content, they divert users from going directly to the Reddit app and website; that translates into fewer eyeballs viewing Reddit's ads and less money flowing to the corporation. What CEO wouldn't want to stop that?

##### The price is wrong

On its face, Reddit's proposed fee isn't excessive. No one likes having new charges sprung on them, but 0.024 cents per API call falls near the free-of-charge Facebook API and well below the 0.5 cent per call fee for [integrating with Google Maps](https://developers.google.com/maps/documentation/routes/usage-and-billing#routes-basic). Compare these prices to the health IT world, where I've seen transaction fees range from 1 cent to $1.24 per API call. Yes, you read that right—more than a dollar for a single API call.

High fees have been a staple of healthcare interoperability, though government regulation has helped somewhat. Nowadays the major EHRs make their USCDI-mandated APIs available free of charge to avoid government scrutiny, and information blocking rules delineate [several constraints](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-171/subpart-C#171.302) on EHR companies regarding data exchange fees. Yet the law still provides plenty of leeway for significant integration expenses, stating that "a reasonable profit margin" is permitted without defining what counts as reasonable.

As an entrepreneur, I'm a big fan of profit, but interoperability is such a fundamental part of efficient healthcare delivery that I believe EHRs should only be able to charge for integrations at-cost. I view interoperability like I do two-factor authentication; both may seem like optional features, but in reality they are essential components of functioning software that should be available to all users and should not be fat sources of earnings.

A counterpoint is that a profit margin is necessary to incentivize EHRs to develop new APIs, but I would say this is a weak argument. For one, EHRs still have a profit motive through offering value-added services like security reviews, app marketplaces, and marketing support. If EHRs release more APIs, more third-party developers will want to integrate with their software and leverage those services. Moreover, the profit incentive for APIs is already weak since EHR companies likely earn a much healthier profit on software licenses, and they are motivated to focus R&D resources on adding features for native users instead of third-party integrators.

##### Interoperability is a necessity

In healthcare, interoperability isn't simply a matter of convenience. It's just as much a matter of wellness, efficiency, innovation, and fairness. Data exchange allows doctors to be better informed when seeing a brand new patient and reduces duplicate procedures. It allows a cancer patient to seek care without towing around thick binders of paper. It allows entrepreneurs to create new, competing products and lower switching costs between technology platforms. We need interoperability to have a functioning and rational healthcare system, and capping integration fees at-cost is the right move to get us there faster. It's time healthcare priced interoperability as a core necessity rather than a premium feature.


What's a fair price for interoperability? - Nonstop Interop

What's a fair price for interoperability?

Nonstop Interop is a when-the-moment-feels-right blog focused on interoperability and data integration within healthcare. Our goal is to provide educational and insightful content for technical and non-technical audiences.

Nonstop Interop

Satellite image of lights in the United States at night

Nonstop Interop is a when-the-moment-feels-right blog focused on interoperability and data integration within healthcare

Our goal is to provide educational and insightful content for technical and non-technical audiences. Please forgive any digressions, bad analogies, or shameless self-promotion.

##### Spread the word
