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

Four alternating red and yellow doors with slats

We make the best choice the easiest one™

Healthcare Interoperability Consulting

We are interoperability experts for the leading EHRs

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


Executive leadership

Framed white certificate with a red ribbon

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


Vendor certification

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

Design comprehensive and efficient integration solutions


Solution architecture

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


Integration development

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


Project management

Two stacked books with a mortarboard on top

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


Education & best practices

The healthcare technology industry is a jungle

We can help

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

And we have the Net Promoter Score to prove it

Our customers praise our work

Share this post

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

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).2

![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)

Healthcare Interoperability Consulting

We can help

Executive leadership

Vendor certification

Solution architecture

Integration development

Project management

Education & best practices

Our customers praise our work

We're passionate about interoperability

Interoperability's tiny slice of the debt pie

The evolution of interoperability (part 2)

The evolution of interoperability (part 1)

Clarity, Certainty, Expertise, Ease

Ashavan - Healthcare Interoperability Consulting

Healthcare Interoperability Consulting

We can help

Executive leadership

Vendor certification

Solution architecture

Integration development

Project management

Education & best practices

Our customers praise our work

We're passionate about interoperability

Interoperability's tiny slice of the debt pie

The evolution of interoperability (part 2)

The evolution of interoperability (part 1)

Clarity, Certainty, Expertise, Ease