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)


The most significant gaps in interoperability - Nonstop Interop

The most significant gaps in interoperability

Edited photo of President Joe Biden and Lael Brainard before a screen that says "Junk Fees" and with a speech bubble that says "Interoperate with me, I'm Irish"

![Edited photo of President Joe Biden and Lael Brainard before a screen that says "Junk Fees" and with a speech bubble that says "Interoperate with me, I'm Irish"](/images/Biden-junk-fees-1689570000.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.


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?

![Tesla charger at night](/images/Tesla-charger-1686718800.jpg)

The past three weeks have brought some notable news within interoperability—but for cars, not healthcare. [Ford declared](https://apnews.com/article/ford-tesla-supercharger-network-charging-evs-851373260a81ed39d7fce7e10fdeec1f) in late May that it will move to adopt Tesla's standard for electric vehicle charging; by this time next year, Ford EV owners will have access to Tesla's network of chargers, and new cars that Ford produces from 2025 onwards will use Tesla's currently proprietary charging standard. [General Motors followed](https://apnews.com/article/general-motors-tesla-charging-stations-electric-vehicles-f53d07e5459aac0c9c6723a6469fbe6d) last week with much the same announcement, ratcheting up the pressure on other automakers to follow suit. It's safe to say the road ahead likely leads to Tesla's standard becoming [the universal one](https://techcrunch.com/2023/06/12/ev-charger-networks-are-turning-to-tesla-standard-as-support-accelerates/) in North America. Amazing how much can change in three weeks.

Is this good news or bad? Like anything of consequence, that [depends on your perspective](/blog/perception-the-difference-for-interoperability-20230412). Media outlets and financial analysts were quick to point out the benefits, such as unlocking the fastest charging on the market for even more cars and reducing the friction of EV adoption. Clearly it will be a financial boon for Tesla as more vehicles to charge means more revenue for the mother ship; Tesla's stock rose 27% from May 26 through June 9, soundly beating the S&P 500's 3.5% climb.

But we shouldn't ignore the disadvantages of this approach and the lessons we can learn for healthcare interoperability. The auto industry's embrace of a still-proprietary standard contrasts with [the evolution of healthcare interoperability](/blog/evolution-interoperability-20230428) standards and tips the scales towards a single company. Consumers and carmakers should be wary of these changes leading to unpleasant shocks.

##### Untangling the wires

Unless you're an expert on EVs, your brain might need a recharge on charging standards. (Note: this post focuses on North America, as standards vary globally.) EV charging has [two key technical aspects](https://www.pcmag.com/how-to/can-i-plug-in-charging-an-electric-car-explained). One is the level of charging, which essentially means the power and speed at which vehicles can charge. Most public chargers in the US are Level 2 chargers, but these are pretty slow and only suitable when you can leave your car charging for a couple of hours. Level 3 chargers, including Tesla's Superchargers, are the fastest; automakers want their customers to have convenient access to these to make charging less of a hassle, especially on road trips.

The second aspect is the shape and size of the connector and inlet. Think of the connector as the plug at the end of a power cord and the inlet as the outlet in a wall. The plug and outlet must match up or you'd never be able to plug anything in. EV connectors and inlets are either NACS, which is Tesla's proprietary standard that (as of now) only its cars use and support, and CCS, which is used by almost every other manufacturer and which is a [public industry standard](https://webstore.iec.ch/publication/59922) that has gone through the standards development process. A key aspect of Ford and GM's decision is that their cars will move away from CCS and adopt NACS, with an adapter needed for vehicles that still have a CCS inlet. The top three US EV producers—representing [60% of the current market](https://www.reuters.com/world/us/white-house-says-tesla-chargers-available-federal-dollars-long-they-include-ccs-2023-06-09/)—will be on NACS in short order.

I think any objective observer would agree that Tesla's charging infrastructure is better. In addition to having the most Level 3 chargers in North America, the NACS design is slimmer and lighter. Credit is due to Tesla as well for [publishing NACS](https://www.tesla.com/blog/opening-north-american-charging-standard) for other automakers and charging infrastructure companies to utilize, and it says it's working to make NACS a public standard. This is certainly not entirely out of altruism; Tesla must make its charging network usable by other brands in order to qualify for billions in federal subsidies.

##### Watts not to like?

There is no guarantee, however, that NACS will become a public standard. Such a process can take over a year, and until that happens, Tesla could choose to modify the standard without input from others, limit information sharing with standards development committees, or reverse itself and keep its specification proprietary. To be clear, there is no indication that Tesla will do such things, but they remain distinct possibilities. To relate this back to healthcare interoperability, imagine that FHIR was originally a proprietary standard created by ACME EHR company. One day ACME says, "We're opening up FHIR to everyone!" and the health IT world rejoices. But then as more and more EHRs and digital health apps get onboard with FHIR, ACME retains control and slow-walks making it a truly open, multistakeholder standard. Suddenly those EHRs and apps are stranded on a ship with an uncooperative captain.

That scenario would be even worse if ACME is able to financially gain from the use of FHIR, such as through royalties or pay-to-play fees. No one would appreciate a shakedown like that. The circumstances for Tesla aren't quite the same, but no doubt Tesla will see monetary benefits from its Ford and GM arrangements. Until other charging networks build out NACS infrastructure, consumers will have little choice but to rely on Tesla chargers. Tesla could earn money from selling NACS-to-CCS adapters or mandating network access fees, and while the company has historically shied away from advertising, driving more cars to its chargers creates a stellar opportunity to self-promote or sell ad space at its charging stations. Busier charging stations also increase the likelihood that Tesla can collect [idle fees](https://www.tesla.com/support/supercharger-idle-fee). Cha-ching, cha-ching, cha-ching.

Lastly, a very important distinction is needed. While Tesla has opened up its NACS standard, these deals with Ford and GM do not open up its entire network. Reports are that 12,000 of the 17,000 Superchargers will be accessible to the latter two's drivers; ostensibly, Tesla is reserving 5,000 Superchargers for its own customers' exclusive use. The end result is that Tesla gets to decide where thousands of drivers can and can't charge. Again, tying back to healthcare, this would be like an HIE picking and choosing which health systems a provider can request clinical data from. To maximize the power of networks, they must be truly interoperable, and they can't be truly interoperable if not every point on the network is equally accessible.

##### Lighting the way

What would be the better approach? There’s no doubt we need to get to a common charging standard; can you imagine how painful it would be if the nozzle on a gasoline pump came in a variety of shapes, like diamond and trapezoid? As I mentioned earlier, NACS is likely the best standard out there today, but that doesn't mean it's the best it can be.

As it undergoes peer review and becomes a truly open standard, we may find that changes are needed to make NACS truly interoperable across all vehicles. Car companies, Tesla included, and charging vendors should be uniting around a single, public, and interoperable charging standard and baking that into vehicles and charging stations. We absolutely can start with NACS as the initial proposal, but we should allow it to go through revisions, improvements, and testing before everyone jumps onto the bandwagon. This is what we do for FHIR, where HL7 leads a standards development process that is [well-documented](https://confluence.hl7.org/display/HL7/Understanding+the+Standards+Process), consensus-based, and open to all, and where new proposals are validated in the real world on multiple occasions to verify they are the best choice. The EV industry would do well not to short-circuit truly fair and open progress in charging, and it could learn some valuable lessons from the healthcare IT community.

\--- 

Photo by [Paul Steuber](https://unsplash.com/@paulsteuber) on [Unsplash](https://unsplash.com)


Tesla's charging deals illustrate a flawed approach to interoperability - Nonstop Interop

Tesla's charging deals illustrate a flawed approach to interoperability

Parody image of House Speaker Kevin McCarthy telling President Joe Biden "I hear our technical debt is huge too."

![Parody image of House Speaker Kevin McCarthy telling President Joe Biden "I hear our technical debt is huge too."](/images/McCarthy-Biden-1684990800.jpg)

The political class loves a good crisis. I suspect there must be something in the water in Washington, DC. The current flavor of the month is the negotiations over raising the national debt ceiling, which likely needs to happen by June 1 in order to avoid the first-ever default on our national debt. If this sounds vaguely familiar, that's because it's a [well-worn impasse](https://bipartisanpolicy.org/debt-limit-through-the-years/) that already played out in 1954, 1957, 1979, 1985, 1996, 1997, 2011, 2013, 2015, 2017, 2019, and 2021.

No matter which side you take in this battle, there's no denying our national debt is scarily enormous. The [gross national debt](https://fiscaldata.treasury.gov/americas-finance-guide/national-debt/) is $31.46 trillion dollars. That amount is equivalent to winning the [largest lottery jackpot](https://abcnews.go.com/US/wireStory/10-largest-us-lottery-jackpots-won-95855651) ever 15,421 times. If you had the amount in [$1 bills](https://www.alliantcreditunion.org/money-mentor/the-dollar-bill-believe-it-or-not), you could make eight stacks of cash that [reach the Moon](https://spaceplace.nasa.gov/moon-distance/en/) and still have $3.3 trillion left over.

The debt grows when Congress fails to balance the budget and revenue from taxes doesn't match the budgeted spending levels. This has been the case in [all but seven](https://www.thebalancemoney.com/us-deficit-by-year-3306306) of the past 70 years. No matter which party is in charge, our elected leaders have proven that a balanced budget is not their priority and so-called fiscal responsibility is just a political talking point. Even when Congress has tried to force itself to cut spending, it has conveniently [gotten cold feet](https://democrats-budget.house.gov/publications/report/FAQs-on-Sequester-An-Update-for-2020).

In the past 15 years, the federal government has earmarked dollars specifically for interoperability and health IT, but rest assured that this has been a very minor contributor to our national debt. As the table below shows, the ONC's budget hasn't even kept up with inflation, and if you assume every budgeted dollar was paid for with borrowed money, the total addition to the national debt would be less than a billion dollars.

**Annual budget for the ONC**<sup>**1**</sup>

| **Fiscal Year** | **Budget (current dollars)** | **Budget (Apr 2023 dollars)** |
|:---------------:|:----------------------------:|:-----------------------------:|
| [2010](https://www.congress.gov/bill/111th-congress/house-bill/3288/text?format=txt)            | $61,342,000                  | $86,081,740                   |
| [2011](https://www.congress.gov/bill/112th-congress/house-bill/1473/text?format=txt)            | $61,342,000                  | $85,084,400                   |
| [2012](https://www.congress.gov/bill/112th-congress/house-bill/2055/text?format=txt)            | $61,226,000                  | $82,031,720                   |
| [2013](https://www.congress.gov/bill/113th-congress/house-bill/933/text?format=txt)            | $61,226,000                  | $80,295,450                   |
| [2014](https://www.congress.gov/bill/113th-congress/house-bill/3547/text?format=txt)            | $60,367,000                  | $78,413,310                   |
| [2015](https://www.congress.gov/bill/113th-congress/house-bill/83/text?format=txt)            | $60,367,000                  | $77,129,610                   |
| [2016](https://www.congress.gov/bill/114th-congress/house-bill/2029/text?format=txt)            | $60,367,000                  | $76,998,270                   |
| [2017](https://www.congress.gov/bill/115th-congress/house-bill/244/text?format=txt)            | $60,367,000                  | $75,758,860                   |
| [2018](https://www.congress.gov/bill/115th-congress/house-bill/1625/text?format=txt)            | $60,367,000                  | $74,243,460                   |
| [2019](https://www.congress.gov/bill/115th-congress/house-bill/6157/text?format=txt)            | $60,367,000                  | $72,416,770                   |
| [2020](https://www.congress.gov/bill/116th-congress/house-bill/1865/text?format=txt)            | $60,367,000                  | $71,161,450                   |
| [2021](https://www.congress.gov/bill/116th-congress/house-bill/133/text?format=txt)            | $62,367,000                  | $72,660,180                   |
| [2022](https://www.congress.gov/bill/117th-congress/house-bill/2471/text?format=txt)            | $64,238,000                  | $70,456,280                   |
| [2023](https://www.congress.gov/bill/117th-congress/house-bill/2617/text?format=txt)            | $66,238,000                  | $65,391,440                   |

Similarly, the incentive payments CMS provided to eligible providers and hospitals for adopting EHRs totaled [roughly $20 billion](https://web.archive.org/web/20130514174203/http://www.hhs.gov/recovery/programs/#Health), and these outlays have [fallen significantly](https://www.usaspending.gov/agency/department-of-health-and-human-services) over the past 5-6 years as the federal government has shifted to sticks over carrots. In contrast, outlays for several federal Cabinet-level agencies have grown significantly in the past two decades, led by HHS' almost $1 trillion increase in annual expenditures ($650 billion in constant dollars).<sup>2</sup>

![Bar graph showing the growth in annual outlays for key federal departments between fiscal year 1999 and fiscal year 2019](/images/Federal-outlays-increase-1684990800.jpg)

This is important because any spending cuts to resolve the debt ceiling battle are likely to fall heavily on the kinds of discretionary programs and low-profile agencies that support greater interoperability in healthcare, but that will probably yield little in the way of savings. And cutting spending around interoperability would delay much needed investments, such as [adopting new standards](/blog/teach-football-tefca-20230216) and boosting the use of [EHRs in post-acute settings](/blog/speaker-finish-strong-interoperability-20230109). As they duke it out over the debt ceiling, Democrats and Republicans should be careful not to treat interoperability initiatives as a problem, when they are in fact a much-needed solution.

\--- 

###### Notes and methodologies

**Note 1: ONC's budget**

Links to the appropriations bill for each fiscal year are in the table. In most cases, you can find the budgeted amount within the bill text by searching for "national coordinator" within the page. Fiscal years 2011 and 2013 simply maintained the budgeted levels of the prior fiscal year. Fiscal year 2012 included 0.189% across-the-board cuts in discretionary spending for HHS. The value of each amount was converted from dollars at the beginning of the fiscal year (which is October of the previous calendar year) to April 2023 dollars using BLS' [CPI Inflation Calculator](https://www.bls.gov/data/inflation_calculator.htm).

**Note 2: Federal outlays**

Defense spending includes military spending, civil works, and the Corps of Engineers. Social Security Administration outlays include on- and off-budget expenditures. Source: [Table 4.1](https://www.whitehouse.gov/omb/budget/historical-tables/) - Outlays by Agency 1962-2028. Dollar amounts were converted to equivalent dollars in October 2018 using BLS' CPI Inflation Calculator.


Interoperability's tiny slice of the debt pie - Nonstop Interop

Interoperability's tiny slice of the debt pie

Several flowers in a row and in progressive stages of blooming

*This is the second post in a two-part series on the evolution of interoperability. Read part one* [*here*](/blog/evolution-interoperability-20230428)*.*

![Several flowers in a row and in progressive stages of blooming](/images/Flowers-blooming-1683781200.jpg)

Last time, we looked at how interoperability has changed from the 1980s through the Meaningful Use era. We reached a point where interoperability was mostly event-driven and based on individual connections, and where technical standards focused on specific use cases. Today I'd like to continue our walk through time, but to begin, we'll need to back up a touch to the early 2010s.

##### The discovery of FHIR

In the [Shahnameh](https://en.wikipedia.org/wiki/Shahnameh), legend has it that a king discovered fire when he threw a stone intending to kill a snake. He missed, but sparks flew when the stone hit another stone. Fire was found, an act [celebrated](https://parsi-times.com/2023/02/zoroastrians-celebrate-jashn-e-sadeh-in-iran/) to this day by Zoroastrians worldwide and many in Iran.

The discovery of FHIR is certainly less fanciful but no less consequential. Before FHIR, healthcare lacked a clear-cut standard for exchanging data through modern web-based technologies. The technical components ([OAuth](/blog/oauth-most-important-standard-interoperability-20221013), HTTPS, JSON, etc.) were there, but we hadn't turned towards representing data in discrete, interconnected concepts (e.g., patient demographics within a Patient, facility details within a Location, drug information within a Medication).

That changed when "[Resources for Healthcare](https://hl7.org/fhir/2011Aug/)" emerged in 2011. Though admittedly immature, we finally had a way to interoperate using a 21st century approach, much like Twitter or Facebook have always worked. FHIR has since grown bigger and stronger, with its fifth major version released earlier this year. Yet more important than the blossoming of the specification is how the healthcare IT community has embraced it. FHIR accelerators emerged to solve real-world problems with FHIR; the federal government began to push for FHIR adoption. This is a major shift from the old way, where different standards were developed and recommended for specific use cases. Instead, FHIR has become the foundational standard for healthcare interoperability, poised to one day replace narrower frameworks like HL7v2 and DICOM. 

##### It gets personal (and regulated)

![Timeline of interoperability milestones from 2010 to 2023](/images/Interoperability-timeline-3-1683781200.jpg)

FHIR hasn't been the only thing heating up over the past 10-ish years. Notably, interoperability has evolved to become more patient-centric. [Blue Button](https://www.va.gov/BLUEBUTTON/index.asp) launched in 2010 with the goal of empowering patients' access to their health data. Championed by both the VA and CMS, Blue Button has unlocked veterans' health data and Medicare beneficiaries' claims data via APIs. CMS went further in 2020 when it finalized the [Patient Access Rule](https://www.federalregister.gov/documents/2020/05/01/2020-05050/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-and), which required affected payers to release FHIR R4 APIs. This opened the door for developers to build patient-facing apps powered by members' clinical and claims data.

CMS hasn't stopped there. Late last year, the agency proposed expanding API requirements for many payers by mandating support for [electronic prior authorization](/blog/cms-prior-auth-rule-20230302), the ability for payers to exchange data on a member, and the ability for providers to request member data individually or in bulk. Yet again, as proposed these APIs would all need to be FHIR R4 APIs. Not to be outdone, ONC has been more focused on interoperability since requiring patient-facing APIs in 2015. The highlight has been [USCDI](/blog/uscdi-power-write-access-20220930), which is like a baseline for interoperability nationwide. Under USCDI, certified EHRs must support exchanging select data elements through FHIR R4 APIs. The beauty is that new data elements are added to USCDI each year, thereby raising the bar for interoperability on a regular basis once ONC completes the necessary rulemaking.

These regulations demonstrate how the federal government has become more assertive in moving the needle for interoperability. Rather than waiting for the industry to voluntarily embrace FHIR, the government has made it a required standard on multiple occasions. Rather than relying on private certification programs, such as the [HIMSS maturity models](/blog/himss-stage-8-20221114), to incentivize the availability of APIs and the data they support, the government has mandated modern technologies and an ever-expanding scope of interoperability. This would have never happened 15 years ago, when technology was less ubiquitous and interoperability looked much different.

##### Marching on

The context of the past informs the dreams of our future. In merely a dozen years, we've seen a transition from individual standards to the broad-based FHIR, and we've seen government play a more active role in policing technology and patients' access to their data. I hope you've enjoyed this brief history; it makes me appreciate all the people who have worked tirelessly on interoperability since before I was born.

Now, I've used this series of posts to focus on the past, not the future. What lies ahead? Humans are [incredibly bad](https://www.rd.com/list/predictions-that-were-wrong/) at [predicting](https://www.poynter.org/reporting-editing/2015/the-internet-bah-classic-off-target-essay-appeared-20-years-ago/) the future—thus, I won't add to that miserable record. I will, though, highlight the potential of [TEFCA](/blog/teach-football-tefca-20230216). Once fully implemented with live QHINs, TEFCA will provide us with a network-based approach to interoperability from coast-to-coast. Rather than repeatedly building individual connections, systems will be able to route data wherever it needs to go by leveraging existing digital highways. I'm eager to see if TEFCA turns data exchange over networks into a popular choice; if so, this would truly be a milestone in the evolution of interoperability.

\---

Photo by [Edward Howell](https://unsplash.com/@edwardhowellphotography) on [Unsplash](https://unsplash.com)


The evolution of interoperability (part 2) - Nonstop Interop

The evolution of interoperability (part 2)

A man standing next to four figures showing the evolution of humans from apes

*This is the first post in a two-part series on the evolution of interoperability. Read part two* [*here*](/blog/evolution-interoperability-20230511)*.*

![A man standing next to four figures showing the evolution of humans from apes](/images/Evolution-1682658000.jpg)

In life, change is inevitable, and history is invaluable. Both are equally true for healthcare interoperability.

As I discussed last time, [interoperability is a social construct](/blog/perception-the-difference-for-interoperability-20230412), constantly evolving as technology, regulations, and community expectations advance. What fits the mold of interoperability today may be deemed insufficient in just a few years. With today's post, I'd like to look at the historical side of interoperability.

Despite the concept's relatively recent buzz, interoperability has existed in some form or fashion for decades. That isn't to say it has been robust or pretty or efficient—it is, on the whole, still not that way—but it's been there, and there's been a dedicated community of passionate people working to make it better. With a focus on the US, and with the caveat that I won't be able to do justice to everyone or everything, let's highlight some of the key milestones in the evolution of interoperability.

##### Rise of the acronyms 

![Timeline of interoperability milestones from 1977 to 1998](/images/Interoperability-timeline-1-1682658000.jpg)

The 1980s and 90s were the metaphorical baby boom of interoperability.

*   HL7 International was founded in 1987 and quickly followed up with the first interface standards, [HL7 v2.1](http://www.hl7.eu/HL7v2x/v21/std21/hl7.html). Over the ensuing three-plus decades, HL7v2 has developed into likely the most widely supported standard in healthcare IT.



*   In similar fashion, the Accredited Standards Committee for X12 began to focus on healthcare workflows [in 1991](https://web.archive.org/web/20140927153732/http://www.x12.org/x12org/about/X12History.cfm) with the formation of the X12N Insurance Subcommittee. By the turn of the century, X12 was fully aligned with HIPAA and to this day is the standard for healthcare financial operations such as insurance claims and eligibility.



*   DICOM was even earlier, published under the name [ACR-NEMA 300](https://www.dicomstandard.org/history/) in 1985 and rapidly improved upon throughout the next 15 years. Notably, DICOM underwent a shift in 1995 to be inclusive of all medical imaging, not just radiology, which enabled it to expand into cardiology, endoscopy, and dermatology.



*   The National Council for Prescription Drug Programs, in existence [since 1977](https://member.ncpdp.org/Member/media/pdf/NCPDPinfo/100ABackgroundOrgStructure.pdf), became an accredited standards body in 1996. NCPDP is best known for the SCRIPT standard that facilitates e-prescribing, though it maintains numerous [other standards](https://standards.ncpdp.org/Access-to-Standards.aspx), such as ones for prescription drug monitoring programs and communication between pharmacies and insurance companies.



*   And while not a standard, Integrating the Healthcare Enterprise (IHE) was born in 1998 to help define how technology standards can satisfy clinical workflows. [IHE profiles](https://www.ihe.net/resources/profiles) answer the question of "How?" in healthcare interoperability by applying technical specifications to healthcare-specific use cases.

The parallels among these veteran standards say a lot about how interoperability has been viewed historically. For one, interoperability has been use case-specific. Standards bodies aligned around specific workflows and stakeholders, rather than seeking to be something for everyone. DICOM lives and breathes imaging, while X12 sticks to financial operations and NCPDP SCRIPT dominates anything associated with retail prescriptions. Secondly, integrations were predominantly event-driven and followed a publisher-subscriber model. For example, the vast majority of HL7v2 interfaces operate under the premise of "something (e.g., a new patient admission) happened in system A, and that's my trigger to send the details to system B." We'll see later how APIs provide a completely different paradigm.

Finally, these integration methods take an incremental, point-to-point approach to interoperability. Establishing an HL7v2 or X12 connection traditionally means connecting to specific IP addresses and ports for communication over TCP/IP. (There are alternatives, such as exchanging messages over web services, but these are less common.) If you need to secure the data transfer, you set up a VPN between the parties. All this friction limits the potential for scalability, and that's why there is no nationwide HL7v2 network for an app developer to tap into today. This makes sense to an extent because these standards came of age when technology was much different—in the 80s and 90s, the World Wide Web was much less trafficked and its underlying technologies were still nascent. Remember, the year HL7 v2.1 came out, General Motors [topped the Fortune 500](https://money.cnn.com/magazines/fortune/fortune500_archive/full/1989/), the Berlin Wall fell, and Mark Zuckerberg turned five.

##### The Meaningful Use era 

![Timeline of interoperability milestones from 1996 to 2018](/images/Interoperability-timeline-2-1682658000.jpg)

The HITECH Act of 2009 transformed the US health IT landscape, though its impact on interoperability was gradual. The [first iteration](https://www.federalregister.gov/documents/2010/07/28/2010-17210/health-information-technology-initial-set-of-standards-implementation-specifications-and) of the ONC's Health IT Certification program (which aligned with Meaningful Use Stage 1) focused largely on getting providers onto electronic systems and ensuring they were checking boxes and filling in fields. There were requirements to electronically exchange lab results, immunizations, reportable conditions, and prescriptions, but the final rule removed mandates for electronic insurance eligibility queries and claims submission due to their administrative, rather than clinical, nature. Certified EHRs also needed to electronically receive and transmit patient summaries.

The [2014 certification criteria](https://www.federalregister.gov/documents/2012/09/04/2012-20982/health-information-technology-standards-implementation-specifications-and-certification-criteria-for) brought the endorsement of Direct messaging, which is akin to secure email, as a way for providers to safely send clinical information. This was particularly relevant for transitions of care, such as when a patient is referred to a specialist and the referring provider needs to transmit a clinical summary. This is a noteworthy moment because it signals a shift in thinking towards interoperability through networks, rather than through point-to-point connections. Rather than a referring provider needing to establish a connection with every possible specialist, she can use a provider directory, which is like a phone book, to look up the recipient's Direct address and route the documentation correctly.

[In 2015](https://www.federalregister.gov/documents/2015/10/16/2015-25597/2015-edition-health-information-technology-health-it-certification-criteria-2015-edition-base), the ONC again signaled a shift. Certified Health IT would now need to allow patients to connect their health data to any app of their choosing via APIs. Here was the federal government finally promoting modern integration technologies that the broader tech community had been using for over a decade. Here was the federal government saying "Patients call the shots. They can use whichever third-party software they would like to surface their health data."

Note, however, all the things this regulation didn't do. It didn't require the APIs to follow a standard, such as FHIR; it didn't require APIs that could write data to the patient's health record, only ones that could retrieve data; it didn't apply to any stakeholders or workflows outside of a single patient requesting their own data; and it didn't require support beyond roughly two dozen data points, known as the [Common Clinical Data Set](https://www.federalregister.gov/d/2015-25597/p-1357). Additionally, the rules would only apply to EHRs and not to other repositories of health data, such as payer databases. This was merely a starting point.

##### Catching our breath 

We've traversed a few decades in about 1,000 words, so let's recap. We've seen how interoperability really started to emerge in the 1980s and 1990s, thanks to smart people creating and nurturing standards through accredited organizations. These tried-and-true standards rely on the technology of the times, which favors event-driven integration workflows through individual connections, making it difficult to rapidly scale. Interoperability was about how business entities exchanged data, with little input or involvement from patients, and different use cases utilized different standards.

Yet about a decade ago, the federal government introduced key regulations that hinted at a new direction, one built around integrating through networks, leveraging APIs, and transferring control to patients. We are now in the 2010s, and next time I'll cover the most recent advancements. We are not at the beginning of the end of interoperability's evolution—but it is perhaps the end of the beginning.

\--- 

Photo by [Eugene Zhyvchik](https://unsplash.com/@eugenezhyvchik) on [Unsplash](https://unsplash.com)

The evolution of interoperability (part 1) - Nonstop Interop

The evolution of interoperability (part 1)

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
