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

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


Project management

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

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

Pencil and clipboard with three checks in a checklist

Ensure your integration workflows go hand-in-hand with operational workflows, and prime your product and tech stack for integrating


Workflow & technology reviews

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

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?

Patrick Mahomes holding the Lombardi Trophy with a thought bubble that says "The trophy's nice, but I can't stop thinking about TEFCA"

![Patrick Mahomes holding the Lombardi Trophy with a thought bubble that says "The trophy's nice, but I can't stop thinking about TEFCA"](/images/Patrick-Mahomes-TEFCA-1676527200.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.


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

Healthcare Interoperability Consulting

We can help

Project management

Vendor certification

Solution architecture

Integration development

Education & best practices

Workflow & technology reviews

Our customers praise our work

We're passionate about interoperability

What if an EHR fails?

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

How to teach a football fan about TEFCA

Clarity, Certainty, Expertise, Ease

Ashavan - Healthcare Interoperability Consulting

Healthcare Interoperability Consulting

We can help

Project management

Vendor certification

Solution architecture

Integration development

Education & best practices

Workflow & technology reviews

Our customers praise our work

We're passionate about interoperability

What if an EHR fails?

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

How to teach a football fan about TEFCA

Clarity, Certainty, Expertise, Ease