Share this post

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

![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

Brick wall with the phrase "Until debt tear us apart"

![Brick wall with the phrase "Until debt tear us apart"](/images/Debt-1736920800.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.

\--- 

Photo by [Alice Pasqual](https://unsplash.com/@stri_khedonia) on [Unsplash](https://unsplash.com)

###### 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)

LSU's Angel Reese pointing to her ring finger with Caitlin Clark in the foreground and a speech bubble that says "Look! I've got interoperability!"

![LSU's Angel Reese pointing to her ring finger with Caitlin Clark in the foreground and a speech bubble that says "Look! I've got interoperability!"](/images/Angel-reese-found-interoperability.jpg)

As the seconds ticked down on April 2nd, there were a lot of happy LSU Tiger fans—yours truly included. The women's basketball team was about to cap off a great season with the school's first ever basketball national championship. We the fans had suffered through [disintegration in football](https://www.espn.com/college-football/story/_/id/32732890/ed-orgeron-coach-lsu-tigers-bowl-game-qualifying-upset-no-15-texas-am) and the steaming, [corrupt mess](https://www.espn.com/mens-college-basketball/story/_/id/33486250/will-wade-lsu-men-basketball-coach-sources-confirm) of men's basketball. Finally, glory was ours again, and the whole nation would be talking about the Tigers' new crown!

Except, [The Gesture Seen Around the World](https://apnews.com/article/march-madness-lsu-iowa-reese-clark-f9f814102702e21dc18b48405e197b5c) happened—and the crown took a backseat to an invisible ring. Naturally, the Twitterverse had a field day screaming about whether Angel Reese's parting shots at Caitlin Clark were confident trash talk or classless taunting. Did you see a champion to celebrate or a jerk to excoriate? Battle lines were drawn like we haven't seen since [#TheDress](https://en.wikipedia.org/wiki/The_dress).

##### What color is this integration?

In the healthcare IT world, we are thankfully more calm, civil, and tolerant, yet we still don't see the same things. There's an important lesson to learn from this episode on the significance of interpretation. While we strive to be an objective and technocratic industry, we can't lose sight of the difference our subjective beliefs and expectations make. In interoperability, for example, the word is tossed around endlessly as we bemoan the lack of "full" or "better" or "true" interoperability—yet when you dig into the details, everyone seems to have varying expectations of the ideal state.

Have we reached interoperability if we can exchange a wide range of clinical values, but we can't transmit guarantor and insurance details? Does interoperability mean that we can only pull data from a source, or must we also be able to [write back](/blog/uscdi-power-write-access-20220930) for a system to be interoperable? What are the requirements around bulk data transfer and data frequency for us to be satisfied with the state of interoperability?

##### IYKYK

Poll a large group of attendees at HIMSS next week, and you're likely to get a variety of answers to those questions. That's okay and expected. Try as we may to distill interoperability down to [a technical definition](https://www.iso.org/obp/ui#iso:std:iso:ts:27790:ed-1:v1:en:term:3.39), I doubt it will ever feel complete. Interoperability is not some static, black and white noun. I view it as a social construct like justice or fairness, something that evolves over time in its scope and meaning. We can't perfectly define it, but situation by situation, we know when it's there and when it isn't.

Our understanding of interoperability derives from our various individual perceptions which, when mixed together, produce a coherent set of norms for the community at large. Those norms can be influenced by government action, milestone events, prominent voices for change, or even financial incentives. None of this is wrong or bad, but it does mean we need to accept that the climb towards interoperability's summit can never end. It also means that when speaking about interoperability, we should clearly outline our individual perceptions of it, so that everyone is clear on your perspective and how it differs from their own. Before you assert that interoperability is or isn't measuring up, you need to show us your ruler.

How do I gauge interoperability? I see the ultimate state as one that overcomes the [three core challenges](/blog/interoperating-healthcare-hard-20220627) of data exchange. When methods for data transmission are highly available and comprehensive enough to overcome the friction caused by complexity and fragmentation, we're in a good spot. In more tangible terms, that means interoperability exists when we can exchange all the primary data types—clinical, financial, operational, and administrative—both individually and in bulk, on demand, in either direction between two systems. The technology used (e.g., APIs vs HL7) or the exact routing mechanism (e.g., point-to-point versus over a network) isn't as important as getting the desired amount of data when and where we want, so that it can be understood and acted upon in the same way regardless of the system it lives in. This is my belief today, but it may change next year, and it is no more correct than yours. Together, however, these beliefs help push our progress and our expectations further and further along.


We can't perfectly define interoperability, but situation by situation, we know when it's there and when it isn't.

Perception makes all the difference for interoperability - Nonstop Interop

Perception makes all the difference for interoperability

Man holding a phone with a questioning look on his face, standing beneath a sign that says "Silicon Valley EHR?"

![Man holding a phone with a questioning look on his face, standing beneath a sign that says "Silicon Valley EHR?"](/images/Silicon-valley-ehr-1678856400.jpg)

Well...that escalated quickly.

The life of Silicon Valley Bank went into roller coaster mode last week as the bank [announced](https://ir.svb.com/news-and-research/news/news-details/2023/SVB-Financial-Group-Announces-Proposed-Offerings-of-Common-Stock-and-Mandatory-Convertible-Preferred-Stock/default.aspx) a share offering to offset nearly $2 billion in losses. Depositors, many of whom are startups or are connected to venture capital, promptly fled to the tune of [$42 billion](https://dfpi.ca.gov/wp-content/uploads/sites/337/2023/03/DFPI-Orders-Silicon-Valley-Bank-03102023.pdf) in a single day, and the fallout has pulled Signature Bank down with it and hammered plenty of regional financial institutions.

All this begs the question of whether we can draw any lessons for healthcare and interoperability. I'll concede that the comparisons can't be exact, but if we suspend some disbelief, what would happen in the extreme case of an EHR suddenly becoming unavailable to patients and providers? What harm could that do and is there anything we can do to prepare?

##### Long odds

Let's be clear that there are no signs that any major EHR companies are imminently threatened, nor would a collapse play out in the same way. At the most basic level, banks operate by accepting your deposits and making money on them through loans and investments. If a large number of account holders suddenly want to yank out their cash, a bank may have to sell securities (potentially at a loss) or borrow money to meet the demand.

EHRs are much different. While they will gladly take in more of your data and repurpose it for analytics, algorithms, and automation, wiping it out is a harder process. For one, [data retention regulations](https://library.ahima.org/PB/RetentionDestruction) obligate healthcare providers to hold on to your information for years, and in the US there is no [right to be forgotten](https://gdpr-info.eu/art-17-gdpr/). Nor is there any practical risk of a "run" that threatens an EHR's solvency. Revenue for an EHR company is typically dependent on factors like the number of concurrent users or the number of licensed modules, rather than the raw quantity of data on a hard drive.

##### A better bet

Instead, the more likely parallel to what we see in the financial world is the issue of access to your data. Suppose you woke up to the news that all patient records at your primary source of healthcare were inaccessible. Such a scenario isn't far-fetched; it could occur if a health system that hosts the EHR itself suddenly [closes its doors](https://www.healthcarefinancenews.com/news/dallas-independent-walnut-hill-medical-center-files-bankruptcy-after-sudden-closure), or a [ransomware attack](https://healthitsecurity.com/news/uvm-health-brings-ehr-back-online-one-month-after-ransomware-attack) forces IT systems offline, or a provider simply [doesn't pay its bills](https://clarksvillenow.com/local/acm-medical-clinic-closed-in-clarksville-as-employees-go-without-pay-lose-access-to-records/).

Thankfully such instances are rare and usually temporary, but that isn't guaranteed. Healthcare lacks a mechanism like the FDIC to serve as a backstop and restore faith and availability in times of crisis. If your data were permanently locked away, treatment would be disrupted, digital health apps that rely on connections to your patient record would be rendered ineffective, and transitioning to a new care provider would be very difficult. Patients would need to rebuild their clinical history from scratch, and the government won't be coming to the rescue.

##### Coming out ahead

What can we do to address this challenge? On a personal level, we should treat our health information like any other irreplaceable asset and back it up on a regular basis. Federal rules require certified EHRs to facilitate [exporting](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315#p-170.315$e$$1$) your clinical information and [exchanging it](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315#p-170.315$g$$9$) via APIs, so much like you might save important family photos on a flash drive, you can leverage these mandatory features to create a copy of your data for safekeeping. Perhaps downloading and archiving a copy of your medical information becomes an annual household ritual, like checking your credit report or getting an eye exam.

This is admittedly only a partial solution, however, and revised policies are warranted. The current regulations simply require that the APIs support [USCDI v1](https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi), so not all EHRs will allow retrieving things like diagnostic reports, encounter information, and detailed problems and medications. Policymakers should raise the bar for EHR developers and push them to support the latest version of USCDI, so that patients can safely archive a larger subset of their data.

CMS should also press forward with the Patient API and Provider API requirements in its proposed [prior authorization rule](/blog/cms-prior-auth-rule-20230302). While probably not CMS' primary intent of the proposal, these APIs open new options for patients and providers to retrieve valuable clinical data directly from payers, which could be a lifesaver if EHR data is inaccessible. The rule wouldn't help the uninsured population or Medicare Fee-for-Service members, but it would nonetheless help a significant majority of patients lower the risk of permanent loss of their medical history.


While the comparisons aren't exact, we can draw valuable lessons for healthcare and interoperability from the recent banking firestorm.

What if an EHR fails? - Nonstop Interop

What if an EHR fails?

A pile of books swirling like a whirlpool

![A pile of books swirling like a whirlpool](/images/Swirling-books-1677736800.jpg)

Prior authorization is no fun. Patients get anxious about whether services they need will be denied. Providers gripe about enduring years of training only to have greedy insurance companies tell them what is and isn't medically appropriate. Payers benefit from prior auth by reducing healthcare utilization and claims volume, but it comes at the cost of significant overhead and unwieldy processes. Perhaps only paper makers and faxing companies are happy with the status quo.

On the other hand, reading proposed rulemaking by the federal government is...kind of fun? Maybe only for consultants. It's certainly exciting to see proposed changes that will move an industry forward and bring about greater transparency and efficiency, and CMS' [proposed rule on electronic prior authorization](https://www.federalregister.gov/documents/2022/12/13/2022-26479/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability) will do just that. Embracing electronic prior auth could reduce administrative burden and save [nearly half a billion dollars](https://www.caqh.org/sites/default/files/2023-01/2022-caqh-index.pdf) annually, but there are key gaps that could lead to a frustrating mess when implementing portions of the rule. CMS needs to be bolder and more prescriptive to ensure standardized prior auth APIs are truly a game-changer for healthcare in the US.

##### Recapping the rulemaking

The first order of business is an overview of the proposed rule. It's rather difficult to condense 134 three-column pages into a few sentences, so I must exclude numerous details. We've shared a [series of LinkedIn posts](https://www.linkedin.com/search/results/content/?fromOrganization=[%2273933754%22]&keywords=prior%20auth%20OR%20chocolate&origin=FACETED_SEARCH&sid=osk&sortBy=%22relevance%22) that you may find helpful in learning about the rule beyond what's covered here.

###### *Who's affected?*

Two major groups: payers and providers. In terms of payers, Medicare Advantage organizations, state Medicaid and CHIP programs (both Fee-for-Service and managed care), and companies that sell plans through the federal health insurance marketplaces must comply. Notably, Medicare Fee-for-Service (aka "traditional Medicare") is not impacted. In terms of providers, clinicians and hospitals who receive incentive payments or penalties from CMS for their interoperability practices will have new measures to report on.

###### *What must they do?*

Payers will need to develop three new APIs: a Provider Access API that allows providers to pull data from payers about a member, a so-called PARDD API that supports prior authorization workflows, and a Payer-to-Payer API that allows insurance companies to exchange data with each other—for example, when a patient has concurrent plans and wants to share health data between them. Payers must also enhance their existing [Patient Access API](https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index#CMS-Interoperability-and-Patient-Access-Final-Rule), which allows patients to connect their member data with apps of their choice, to include prior auth information. Lastly, affected payers will need to report annual metrics on Patient Access API usage and prior auth decision-making.

Providers must measure and report on the number of prior authorizations requested and how many were requested electronically via an insurer's PARDD API. The measures are the only new aspect here; CMS is baking them into existing processes for data collection and sharing as part of the [incentive programs](https://www.cms.gov/regulations-and-guidance/legislation/ehrincentiveprograms).

###### *What are the key dates?*

March 13 is the deadline for submitting comments on the proposed rule. Most provisions would take effect by January 1, 2026, though certain exceptions and exemptions are permitted.

##### Someone missed a spot

On the whole, the proposal outlines valuable changes. I applaud CMS for taking this step and recognize the significant effort it's taken to reach this point on the part of policymakers, industry players, and collaborative groups like the [Da Vinci Project](https://www.hl7.org/about/davinci/index.cfm). Here's where the rule falls short, however.

###### *FHIR suppression*

CMS is requiring all of the planned APIs to be FHIR APIs, and they are strongly encouraging the use of certain FHIR Implementation Guides to serve as playbooks for how payers design and develop their new APIs. Yet FHIR is only partially useful within prior authorization workflows because of [existing regulations](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-M/section-162.1302#p-162.1302(b)(2)(ii)) that require the use of X12 278 transactions. It is unlawful today for a provider to send a prior authorization request directly to a payer using FHIR, and CMS is not looking to change that with the proposed rule. Instead, it is cornering providers and payers into translating prior authorization messages between FHIR and X12 278 as they attempt to conform to incompatible regulations.

Imagine if every time you ate at a restaurant, the server had to translate your order into Morse code before sending it to the chef in the kitchen, and the chef had to do the same when announcing your dish was ready. It would be an unnecessary hoop to jump through and would likely doom the restaurant's operations. Translating data between formats isn't as hard on a computer, but CMS is nonetheless introducing greater [complexity](/blog/interoperating-healthcare-hard-20220627) into healthcare technology and forcing further reliance upon clearinghouses (which [may exchange FHIR](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-I/section-162.930) data under certain circumstances). If the agency believes FHIR is the future of healthcare interoperability, it needs to embrace FHIR fully and use this rule to add FHIR as a HIPAA-compliant standard for prior auth.

###### *Codify the codes*

Complementary to the above is the issue of code sets. X12 278 transactions have standard code sets that must be used, such as for the status or denial reason for a request. FHIR can't be so rigid, since it must work for healthcare workflows outside the US, thus an API can be FHIR-compliant while using completely novel codes. The recommended Implementation Guides mandate the X12 code sets, but CMS isn't willing to require those IGs "while they are still undergoing additional enhancements."

This leaves the health IT community crossing its fingers that everyone will do the right thing and use the tried-and-true code sets. It would be better if CMS asserted that the payers' APIs need to utilize the X12 code sets or that payers must provide a machine-readable mapping of their codes to the X12 ones. Either approach would provide consistency and reduce friction for health IT developers when working with the APIs.

###### *99 payers, but I don't know which one*

As discussed earlier, the Payer-to-Payer API would allow payers to exchange data with each other, thus making it easier for a patient to share data between concurrent payers or to move their data to their new payer if their health plan has changed. Notably, patients must opt-in to this data exchange, and payers must collect enough information to know who the other insurance company is and how that payer identifies the member (e.g., the member ID with the other payer).

When you contemplate all the different payers, brand names, and subsidiaries out there, I fear that identifying the right insurer is going to be a nightmare in this process. Proper payer identification is crucial, as that determines the URL you use to make the Payer-to-Payer API calls. Not knowing the correct URL is like being late for lunch and not knowing the address of the café you're trying to get to. You're going to end up in the wrong spot.

Consider Centene, which is one of the country's largest payers and which boasts the most plans on the marketplaces. It operates multiple brands, such as a different Ambetter brand in each of 27 states. But if you look up Ambetter in the de facto [national list of insurers](https://content.naic.org/cis_consumer_information.htm), you find only two. Payers often operate multiple subsidiaries that are the true licensed entities (SilverSummit Healthplan and Celtic Insurance Company would be two examples for Centene). If a new Humana member specifies they want to pull their data from "Ambetter," Humana must waste time and energy figuring out which Ambetter it is, what the true name of the insurance company is, and which URL to connect to.

The situation is not hopeless, however. CMS could beef up the proposed rule to address this challenge in two ways. First, CMS should require affected payers to leverage [the power of OAuth](/blog/oauth-most-important-standard-interoperability-20221013). OAuth allows apps to connect to one another in a secure fashion by proving that a user is really who they claim to be and sharing select data points across apps. For payer-to-payer data exchange, payer #1 could show a button within the member's online account that says "Connect to a different payer." Clicking the button would generate a unique, short-lived URL associated with the member's account. The member could then share that URL with payer #2, and payer #2 could immediately call that URL, ask the member to authenticate and approve the data exchange, and gather the member's health history. This would reduce the extra paperwork for members and insurers and is analogous to the process that Google and Facebook use when you leverage your existing account to sign into a different website.

A second, slightly lower-tech option would be to strongly encourage payer #2 to request payer #1's public website when the member provides their identifying information. While this approach wouldn't be as automatic as OAuth, having the website in addition to the payer's name would allow payer #2 to more easily research and discover the right payer to connect to. Payers could even build a collaborative database to map public websites to API URLs and automate data exchange down the line. The larger point is that we have technological options here that CMS should endorse, and if it doesn't, it risks discontent and poor adoption of the Payer-to-Payer API.

##### From good to great

Those aren't all the weaknesses of the proposed prior auth rule—I'll spare you my concerns regarding the required metrics and the conversion of prior auth guidelines into a usable format for APIs. But I want to reiterate that there is a lot to like about the proposed rule, and I'm thankful that we have the rulemaking process to scrutinize and improve upon federal action before it takes effect. A few prescriptive refinements are all that's needed to ensure CMS fosters a future of efficiency and interoperability, rather than one of confusion and regrets.

\---

Photo by [Pixabay](https://www.pexels.com/@pixabay/) on [Pexels](https://www.pexels.com)


CMS needs to be bolder and more prescriptive to ensure standardized prior auth APIs are truly a game-changer for healthcare in the US.

CMS' prior auth rule: game-changer or hot mess? - Nonstop Interop

CMS' prior auth rule: game-changer or hot mess?

Football with the word TEFCA overlayed on a field along a hash mark

![Football with the word TEFCA overlayed on a field along a hash mark](/images/Football-1736920800.jpg)

It's hard to follow the Super Bowl. [113 million people](https://apnews.com/article/kansas-city-chiefs-los-angeles-rams-philadelphia-eagles-cincinnati-bengals-nfl-c771bc37dff5631ed836e4f289a78985) don't tune in to just any live event. (To my chagrin, nor do such masses read blogs about interoperability.) Thus, you're forgiven if you missed Monday morning's extravaganza, at which HHS announced the first prospective QHINs under TEFCA. In fact, you're forgiven if you don't know what the heck TEFCA is, why anyone would want to be a QHIN, and if it will have any bearing on your next trip to urgent care.

At [Monday's event](https://www.youtube.com/watch?v=pIN7-byulhk), HHS Secretary Xavier Becerra claimed the announcement was "more consequential than yesterday's game." Many Kansas City fans would disagree, but there's no denying we've begun a new chapter for interoperability. And perhaps surprisingly, football can help even the most casual observer of health IT understand what's going on and why it's important.

So whether you're a die-hard fan or you just know someone lucky enough to [catch the game-winning ball](https://7news.com.au/sport/nfl/melbourne-man-catches-match-winning-super-bowl-field-goal-1198km-from-his-san-francisco-home--c-9748751), here's a primer on TEFCA that'll work from the gridiron to the gynecology clinic.

##### The opening kick

[TEFCA](https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca) is the Trusted Exchange Framework and Common Agreement, and you can thank Congress for it. The [21st Century Cures Act](https://www.congress.gov/bill/114th-congress/house-bill/34/text/pl?overview=closed), passed in 2016, directed HHS to create TEFCA in order to promote greater, more efficient healthcare data exchange throughout the US (search for "Sec. 4003" within the bill's text). However, Congress specified that participating in TEFCA is strictly voluntary.

##### The current playing field

Imagine a world with professional football teams but no NFL or standardized rule book. When the Titans play the Steelers in Week 1, they must negotiate over things like the length of each quarter, how many players are allowed on each team, and how many timeouts both sides get. Then when the Titans play the Cowboys in Week 2, they must negotiate again over the same things, and the rules for this second game may differ from the first one's.

Exchanging data in healthcare is like that today. Its [fragmented nature](/blog/interoperating-healthcare-hard-20220627) means you often have to establish point-to-point connections with individual providers, payers, etc. Need to send lab orders and receive results from three different reference labs? You'll have to build separate interfaces for each, and there is variation in how you establish those connections, what information you must provide to get the data you seek, and for what purposes you are allowed to request and receive data.

##### The Xs and Os

The TEF part in TEFCA is the shorter, more general portion. It's [a set of non-binding principles](https://www.healthit.gov/sites/default/files/page/2022-01/Trusted_Exchange_Framework_0122.pdf) that health information networks should follow to achieve that aforementioned goal of strong, efficient interoperability. In football, it's common practice to shake hands after a game and to remove your helmet before doing so. Neither action is required in the rule book, but these are shared principles that make for good sportsmanship and build a sense of respect among competitors. Likewise, the TEF encourages HINs to follow certain best practices, such as using industry standards rather than proprietary ones and making their privacy policies publicly accessible, for the sake of strong, efficient interoperability.

The CA part is [a legal agreement](https://www.healthit.gov/sites/default/files/page/2022-01/Common_Agreement_for_Nationwide_Health_Information_Interoperability_Version_1.pdf), so it is more detailed and is legally binding. Think of this like the bylaws for a league. When an expansion team joins the NFL, they are agreeing to follow this set of rules, and there are consequences if they break any rules. The CA and its associated standard operating procedures outline rules that HINs must follow, such as only exchanging data for a valid purpose like treatment-payment-operations and carrying a minimum amount of cybersecurity insurance, to ensure they are participating in TEFCA correctly and fairly.

##### Winners and QHIN-ers

A Qualified Health Information Network (QHIN) is simply a health information network (i.e., a repository of health data across a large population) that has signed the Common Agreement and is participating in TEFCA. Not just anyone can become a QHIN; an organization must meet the criteria, apply, and be approved as a prospective QHIN. That is where we are today; Monday's event simply announced the first six organizations to have their applications approved. After this, the prospective QHINs must sign the Common Agreement and complete [an extensive onboarding process](https://rce.sequoiaproject.org/qhin-process/) before becoming fully designated QHINs.

##### Who's calling the plays?

The ONC saw the need for a partner to manage and support several aspects of TEFCA, so it underwent a competitive process to draft a [Recognized Coordinating Entity](https://rce.sequoiaproject.org/rce/) (RCE). The Sequoia Project is the current RCE and is on point for, among other things, engaging with the health IT community and monitoring the designated QHINs. It's important to note that the ONC hasn't punted away all of its responsibility and authority. They've simply hired a league commissioner to manage the key operational tasks like establishing the rules for the league's teams, onboarding new teams into the league, and making sure things are running smoothly. The ONC has [allocated $5.1 million](https://www.usaspending.gov/award/ASST_NON_90AX0026_7576) to The Sequoia Project for serving as the RCE over four years, ending just before the start of the next NFL season.

##### Must-see TV

What's the practical impact of all this? Earlier, I gave the example of lab interfaces to highlight the fragmented nature of healthcare interoperability. While a very real scenario, I have to admit that was a bit of [a hook and ladder](https://www.youtube.com/watch?v=iUCdfS0iTnY). Not all healthcare data exchange relies on singular connections with individual software systems.

There are health information exchanges and other entities that aggregate large amounts of data across an entire population, so you can get a more comprehensive set of data this way. Examples include [CRISP](https://www.crisphealth.org/) in Maryland, [Big Sky Care Connect](https://www.mtbscc.org/) in Montana, and implementers of the [Carequality framework](https://carequality.org/members-and-supporters/). If you need to make a trip to urgent care and that location participates in an HIE, they should be able to pull your medical data from other HIE participants to have a more comprehensive view of your clinical history.

But these HIEs don't necessarily talk to each other well, so if the data that urgent care needs lives with two different HIEs, they would have needed to establish separate connections and conform to separate rules. In the NFL, this would be like if the AFC and NFC had different rules, so playing a team within your conference is a lot easier than playing one without. Instead, the NFL says "No matter where your team is located or which conference it is in, here are the rules every team will follow."

TEFCA aims to do the same thing, allowing any requester within a participating QHIN to get the data it needs from any other source within any QHIN. The hope is that standardizing the rules for data exchange will make it easier for patients, providers, researchers, and others to request and retrieve medical information, to improve care delivery, and to make us healthier. Will TEFCA solve all of our interoperability woes? Absolutely not, but it will take us a bit further downfield.

\---

Photo by [Dave Adamson](https://unsplash.com/@aussiedave) on [Unsplash](https://unsplash.com)


Here's a primer on TEFCA that'll work from the gridiron to the gynecology clinic.

How to teach a football fan about TEFCA - Nonstop Interop

How to teach a football fan about TEFCA

Modification of the Hollywood sign to say Data Exchange

![Modification of the Hollywood sign to say Data Exchange](/images/Hollywood-sign-data-exchange-1675144800.jpg)

Everyone has an opinion about California. Either you love it for its beautiful landscape, fertile valleys, and hubs of creativity and innovation, or you're appalled by the bureaucracy, the enormous homelessness crisis, and, yes, the taxes. Time to add the state's interoperability ambitions to the positive side of the ledger.

In 2021 the state Assembly [passed a bill](https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202120220AB133) that sought, in part, to address the challenges of data collection and data sharing during the onset of the COVID-19 pandemic (search for "framework" within the bill's text). Today we reach one of the first milestones in this journey. January 31 is the deadline for affected health and human services organizations to sign the Data Sharing Agreement for California's [Data Exchange Framework](https://www.chhs.ca.gov/data-exchange-framework) (DxF); no actual data sharing is mandated just yet, but it will be over the course of the next 12-36 months.

##### Groundwork on the framework

What is the DxF? The simplest analogy would be that it's California's version of TEFCA. The DxF establishes compulsory policies and procedures for California-regulated entities to share health data electronically. These policies define, for example, the data standards that must be supported, the data elements that must be available for exchange, and the rights of patients that must be respected. The [Data Sharing Agreement](https://www.chhs.ca.gov/wp-content/uploads/2022/11/1.-CalHHS_DSA_Final_v1_7.1.22-11.8.22.pdf) is at the heart of the framework and establishes a set of rules of the road for participants to follow.

Today's deadline is merely the start. Later this year, the state expects to open applications for Qualified Health Information Organizations—analogous to QHINs under TEFCA—and to approve a list of QHIOs who can assist regulated entities in meeting the data exchange requirements. By January 31, 2024, the [DxF will be live](https://www.chhs.ca.gov/wp-content/uploads/2023/01/Data-Exchange-Framework-FAQ-2023-1-23.pdf) and most of the signatories to the DSA will have to adhere to the policies and procedures.

##### No fool's gold

There's a lot to like about the DxF. Most importantly, it differs from TEFCA by requiring a host of organizations to participate in the framework. Whereas [TEFCA is voluntary](https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement) and centered around several non-binding principles, the DxF applies to all acute care hospitals, physician practices, inpatient behavioral health centers, skilled nursing facilities, clinical laboratories, and even insurers. County health and public health organizations aren't required to take part, but the state has made it a point to encourage them to do so.

Too often we've looked at healthcare technology and interoperability through a narrow lens of traditional physician offices and hospitals (Exhibit A: [Meaningful Use/Promoting Interoperability](/blog/speaker-finish-strong-interoperability-20230109)). California is doing the right thing by bringing a vast continuum of healthcare players under one set of rules and opportunities. Granted, casting such a wide net of participants does mean the regulatory burden falls on smaller organizations as well, but thankfully the DxF provides flexibility for those groups by [delaying their data sharing requirements](https://www.chhs.ca.gov/wp-content/uploads/2023/01/CalHHS-CDII-DxF_Webinar-5_January-19-2023.pdf) until January 31, 2026 (slide 14 of the presentation). Legislators also set aside [$50 million in grants](https://www.chhs.ca.gov/wp-content/uploads/2022/12/CalHHS_DxF_Grants-Programs_One-Pager_final-1.pdf) for organizations with limited resources to meet the DxF's obligations, which will ensure no one is left behind.

Additionally, the DxF does a better job of embracing the leading edge for data standards. Whereas ONC regulations currently [only require USCDI version 1](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-B/section-170.213) for health IT certification—which is a key determinant of the EHRs that providers purchase and use—the DxF sets [USCDI version 2 as the floor](https://www.chhs.ca.gov/wp-content/uploads/2022/12/4_CHHS_DSA-Data-Elements-to-Be-Exchanged-PP_Final_v1_11.16.22_For-Posting.pdf). California's framework also explicitly encourages the use of FHIR as a standard for data exchange, while TEFCA has [a longer road ahead](https://rce.sequoiaproject.org/three-year-fhir-roadmap-for-tefca/) before FHIR plays a major role.

Lastly, I appreciate the spirit of continuous improvement that's baked into the DxF's refinement process. The core advisory committee that drove the work didn't simply focus on writing regulations. It also identified [10 key gaps](https://www.chhs.ca.gov/wp-content/uploads/2022/07/6_CalHHS_DxF_Gaps-and-Opportunities_Final_v1_07-01-2022.pdf) in the exchange of health information today and outlined multiple ways the state can work to close these gaps without waiting on Washington. This sort of analysis provides crucial material for policymakers as they determine the next steps in the push for greater interoperability.

##### Consistency is a must

What are the DxF's flaws? To me, the biggest risk is the potential to conflict with efforts at the federal level. Powerful groups have already raised this concern, [along with others](https://calmatters.org/health/2022/06/patient-data-california/). I think the original law and subsequent regulations have done an adequate job of ensuring California's approach remains in line with federal standards, and I believe these state-level efforts are still valuable given the slow pace of progress at the national level. However, it will be critical for the Golden State to stay joined at the hip with the federal government and to avoid policies that push healthcare organizations in multiple directions. The DxF is a welcome and needed accelerator for interoperability, and we can't afford to ruin it by imposing conflicting sets of rules.


California's Data Exchange Framework is a welcome and needed accelerator for interoperability,  but it must avoid policies that push healthcare organizations in multiple directions.

California's interoperability approach is good, but consistency will be key - Nonstop Interop

California's interoperability approach is good, but consistency will be key

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
