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.

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

Modified image of Kevin McCarthy holding a sign that says Interoperability in place of the Speaker's gavel

![Modified image of Kevin McCarthy holding a sign that says Interoperability in place of the Speaker's gavel](/images/Kevin-McCarthy-interoperability-sign-1673244000.jpg)

Finally, we have a Speaker of the House. Whether you followed the political drama last week with amusement and fascination or despair and trepidation, it's a relief to know that it's over (for now). Congress is at full strength, and [work can begin](https://www.marketwatch.com/story/what-happens-while-theres-no-house-speaker-salaries-in-limbo-taxpayers-requests-turned-away-11672944906).

The new majority leadership in the House has outlined [a few priorities](https://www.newsweek.com/heres-what-kevin-mccarthys-gop-has-planned-america-1745522), much of which has been [recycled](https://www.politico.com/news/2020/09/14/mccarthy-gop-win-control-house-414585) from the prior election cycle and lacks specificity. Sadly, there's no mention of a focus on healthcare interoperability. You can't blame them—no one tunes into the evening shows on cable news to hear politicians sermonize about sharing medical records. And this is a long-time, bipartisan problem, with [Newt Gingrich](https://en.wikipedia.org/wiki/Contract_with_America) and [Nancy Pelosi](https://www.reuters.com/article/us-usa-congress-agenda-idUSN0448857520070104) ignoring the topic as well. (In fairness, both became Speaker well before Meaningful Use and the widespread use of EHRs.)

But if Republicans truly want to [finish strong](https://twitter.com/SpeakerMcCarthy/status/1611881280031051778) for America, a great way to do it would be to take the lead on advancing interoperability. It won't be sexy or attention-grabbing work, and it's going to take bipartisan compromise given that both chambers are closely divided, but it could be tremendously impactful. Here are some ideas for how Congress can use its legislative powers to be a force for good in interoperability.

##### National patient ID

We need to [eliminate the outdated ban](/blog/congress-whiffs-advancing-interoperability-20221229) on a national patient identifier. A well-designed national patient ID will provide something that we don't have today, a verifiable and consistent identifier that is valid and recognizable throughout our healthcare system but which is also changeable and better protected against fraud. The House has been warmer to a national ID than the Senate but bipartisan support is there. If Congress isn't ready to completely allow it, it should at the very least clarify the law in the next appropriations bill to allow for research and analysis into the issue while maintaining a prohibition on actual implementation.

##### Extend protections

A lot of Americans assume HIPAA is more powerful than it really is. While HIPAA applies to healthcare providers, clearinghouses, payers, and their business associates, a host of entities involved in digital health are not governed by its rules. Direct-to-consumer apps can collect our health data with far less scrutiny. The federal government has provided [guidelines for app developers](https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool) and clarified that the FTC can take enforcement action on wrongdoers, but Americans deserve HIPAA-like protections whenever their health data is stored and used. Introducing such assurances will spur greater trust in and adoption of digital health tools and accelerate the demand for seamless interoperability.

Any changes here should include codifying the FTC's [Health Breach Notification Rule](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-318). We have a right to know when our personal information is leaked, yet the protections that exist today could be removed in the future with simple rulemaking. Let's make these safeguards part of the law. 

##### Nonprofits under FTC purview

Speaking of the FTC, it's time to bring nonprofits under their jurisdiction. As the FTC Act is [currently written](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section45\&num=0\&edition=prelim), it applies [only to entities](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section44\&num=0\&edition=prelim) that "carry on business for its own profit or that of its members." This means that the FTC's consumer and competition protections don't apply to the vast majority of health systems in the US. There's been [interest in changing this](https://www.judiciary.senate.gov/meetings/09/17/2019/07/23/2019/oversight-of-the-enforcement-of-the-antitrust-laws) (fast forward to 53:20) yet no concrete modifications to the law have been proposed, and Congress will need to consider whether to limit the impact on other nonprofits such as religious institutions and community service organizations.

Will this change directly impact interoperability? Probably not, but it will bring a level field of oversight between nonprofit and for-profit entities in healthcare, and fostering a more competitive landscape could spur innovative providers to change how healthcare is delivered, with interoperability as a core principle rather than a secondary factor.

##### Push for HHS action

Congress doesn't have only lawmaking powers; it also has the power of oversight, and it should wield it to prod HHS towards action. For one, we need [penalties and disincentives](/blog/hhs-oig-past-due-info-blocking-20221006) for information blocking ASAP. It's been three months since the info blocking provisions reached their full effect—and nearly three years since the rules were finalized—yet HHS has not defined any disincentives for providers and the HHS OIG has not finalized its [proposed penalties](https://oig.hhs.gov/newsroom/news-releases/2020/infoblocking.asp). Congress should ensure they act quickly.

Secondly, electronic prior authorization is in the news thanks to CMS' recent proposed rule. However, [HHS' current rules](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-M/section-162.1302) hamstring interoperability by requiring payers to exchange referral and authorization information using the X12 278 standard, which relies on point-to-point interfaces and for which the adoption rate has been disappointing. The proposed rule [will not fix](https://www.federalregister.gov/d/2022-26479/p-715) this problem. While I recognize that APIs for electronic prior authorization are still maturing, HHS should update its rules to allow for an API-based exchange standard, and Congress should lean on it to do so quickly.

##### PI for post-acute

Federal funding spurred an enormous wave of digitization in healthcare beginning in 2009, and the government continues to issue incentive payments and penalties for [interoperability-related objectives](https://www.cms.gov/regulations-guidance/promoting-interoperability/2023-program-requirements). The current system, though, only applies to acute care and ambulatory providers. We need to close this gap.

Congress should allocate funds to HHS to establish a version of Promoting Interoperability for post-acute care providers such as home health, hospice, and skilled nursing facilities. I fully acknowledge that this won't be easy or cheap, but it's nonetheless necessary. We don't have to duplicate the initial Meaningful Use program; I would advocate for introducing penalties sooner and holding providers accountable to interoperability measurements from the get-go. Additionally, I strongly believe any such program should be paid for in full, rather than adding to our already massive national debt. But we can't allow for HHS to focus on only part of the healthcare continuum. As patients, we deserve stronger interoperability among all care providers.


Some ideas for how Congress can use its legislative powers to be a force for good in interoperability.

Mr. Speaker, let's finish strong for interoperability - Nonstop Interop

Mr. Speaker, let's finish strong for interoperability

![Personal identification card](/images/ID-card-1672293600.png)
The federal government didn't shut down this past weekend. That's always a positive, but the mad rush to pull together an appropriations package that can pass a polarized Congress inevitably leads to winners and losers. Interoperability has consistently fallen into the latter bucket and this time was no different.

How so? The annual spending bill perpetuates a nearly 25-year ban on using federal funds to establish a standard for a national patient identifier. Accurate patient identification is one of the most important yet challenging aspects of interoperability, and [advocates say](https://patientidnow.org/about) a national patient identification framework could reduce administrative burdens and improve care. On the flip side, it would no doubt be costly and difficult to get right.

To me, the fundamental flaw in the status quo is that it prevents any serious effort at trying to get it right. In healthcare technology—really, within any industry—there's a pattern to innovation where new solutions and concepts are introduced, scrutinized, and refined or discarded. The current law unnecessarily cripples this debate, and Congress missed another chance to correct its error.

##### A hot and cold relationship

The legislative branch has a history with national health identifiers; uncovering it requires much digging through the archives. If you thought interoperability was hard, try conducting congressional research!

The saga began with HIPAA, which [directed HHS](https://www.congress.gov/bill/104th-congress/house-bill/3103/text/pl) to "adopt standards providing for a standard unique health identifier for each individual, employer, health plan, and health care provider for use in the health care system." (Congressional records are hopelessly void of anchor links, so when I don't quote exact text, I'll share words you can search for within the page to find the relevant portion.)

The present-day restriction was born a couple of years later in the [omnibus funding law](https://www.congress.gov/bill/105th-congress/house-bill/4328/text/pl) for fiscal year 1999 (search for "health identifier"). Its author was Texas congressman Ron Paul, who took to the floor of the House on October 8, 1998 to advocate for inserting the language. Rep. Paul [expressed concern](https://www.congress.gov/congressional-record/volume-144/issue-140/house-section/article/H10137-1) that a national ID would "be used to create a national database containing the medical history of all Americans" and "would allow federal bureaucrats to track every citizen's medical history from cradle to grave."

Since that fateful legislation, the language has remained constant in the yearly appropriations bill, whether that's a standalone bill to fund the Departments of HHS, Education, and Labor or a consolidated appropriations act that bundles together the 12 bills that fund the entire government. (Note: the provision is colloquially referred to in the healthcare community as "Section 510" and I'll do the same here. However, the actual section number has varied over time. It was Section 514 in the [Consolidated Appropriations Act of 2001](https://www.congress.gov/bill/106th-congress/house-bill/4577/text/pl), for example, and Section 511 in fiscal year [2010's equivalent act](https://www.congress.gov/bill/111th-congress/house-bill/3288/text/pl). Search for "health identifier" in both.) Section 510 directly nullifies part of HIPAA's requirements, stating that no appropriated money can be used "to promulgate or adopt any final standard...providing for, or providing for the assignment of, a unique health identifier for an individual (except in an individual's capacity as an employer or a health care provider), until legislation is enacted specifically approving the standard."

After two decades of quiet, a hint of momentum emerged in 2019 when the House passed [a bipartisan amendment](https://www.congress.gov/amendment/116th-congress/house-amendment/286) to strike out Section 510. The House has made multiple attempts to remove it ever since. In the Senate, change has been slower but [the initial appropriations bill](https://www.appropriations.senate.gov/imo/media/doc/LHHS1.pdf) for FY2022 excluded Section 510 (search for "health identifier"). Old habits die hard, though, and Section 510 lives on. Not everyone wants to see it go, either; Sen. Rand Paul of Kentucky has expressed many of the same concerns as his father did, and he has worked with [like-minded colleagues](https://www.congress.gov/bill/117th-congress/house-bill/5812) to [introduce legislation](https://www.congress.gov/bill/117th-congress/senate-bill/3124) removing the original requirements from HIPAA. These proposals have not advanced in either chamber.

##### Fight club

I feel the players on both sides of this issue hold skewed and rigid viewpoints that don't survive rigorous scrutiny. For one, while patient misidentification is undoubtedly a problem, a national ID will not be a panacea for our woes. We already [see mistakes happening](https://psnet.ahrq.gov/web-mm/patient-identification-errors-systems-challenge) when healthcare workers have unique data points available to them, such as distinct names, dates of birth, and medical record numbers. Introducing an additional number in an electronic chart or on a patient armband won't stop fallible human beings from mixing up similar information or failing to follow the right process. To reduce the risk of patient harm due to misidentification, we are better served by implementing and religiously following a system for positive patient verification at every key point in the delivery of care.

What's more, a unique ID will be costly and time-consuming to roll out. Software will need to be updated and existing records will need to be matched to newly issued IDs. The federal government would need to define a process for assigning and managing IDs for unexpected participants in the health system, such as international visitors who need medical care. And a host of questions would need to be answered, like how to verify that an ID a patient provides is truly theirs and how to accommodate patients who are unable to provide theirs.

On the other hand, those resisting work on an identification framework miss the mark in several ways. Privacy and security are the most commonly cited apprehensions, but these are addressable. Opponents assume, as Rep. Paul did in his floor speech, that national IDs will automatically mean a nationalized database of all of our health information, but these are not inseparable. Congress can easily allow for an ID standard while prohibiting a national EHR.

Secondly, the fear of national IDs getting into the wrong hands is often cited. It'll be like Social Security numbers, they say, where you're doomed for the rest of your life once it's leaked. But I would argue this is shortsighted because we shouldn't design a national ID to be like an SSN. We should take a page from the banking industry and make it like a credit card. When my card number is stolen, the bank can easily render it useless and issue a new one. Credit cards also follow defined patterns with check digits to [ensure their validity](https://en.wikipedia.org/wiki/Luhn_algorithm), which reduces the chances of transposed numbers and ensures criminals can't use just any random one. We need to adopt these same principles when developing a unique patient ID.

##### Give it the green light (or at least a yellow one)

In my mind, the key advantage of a national patient ID for interoperability is that it allows us to move to a consistent, verifiable, and fungible value for every participant in our healthcare system. This is something our present-day identifiers can't match. Like an SSN, your name, date of birth, address, and phone number are demographics that are difficult or impossible to change, so their value to malicious actors remains high over time. MRNs provide a unique and (usually) changeable identifier, but they don't carry the same meaning outside of the walls of a single health system. A well-designed national identifier gives us the best of both worlds and reduces friction in the pursuit of seamless data exchange.

To be clear, there's room for meaningful compromise on this issue that allows for incremental progress. Section 510 could be amended to prohibit adopting a final standard while allowing the use of funds to conduct research on what a national patient ID framework could look like. Congress has taken similar steps [on other issues](https://en.wikipedia.org/wiki/Dickey_Amendment#Subsequent_history) by allowing research while preventing a wholesale change in policy. And as we work through if, how, and when we adopt a national patient ID, we shouldn't lose sight of an underappreciated fact: millions of Americans already have one. Every Medicare recipient has a 11-digit Medicare Beneficiary Identifier issued by CMS and recognized nationwide. Congress mandated the change from the old SSN-based identification numbers, and while the rollout required much planning and effort, it was ultimately successful because CMS was empowered with the time and resources needed to make it happen. The same can be true for a unique national patient identifier; it's time for Congress to end the quarter-century ban and advance interoperability by allowing much needed research and innovation.

\---

Image by [OpenIcons](https://pixabay.com/users/openicons-28911) on [Pixabay](https://pixabay.com)


It’s time for Congress to end the quarter-century ban on funding for a national patient identifier.

Congress whiffs again on advancing interoperability - Nonstop Interop

Congress whiffs again on advancing interoperability

Jigsaw puzzle with one missing piece in the center

![Jigsaw puzzle with one missing piece in the center](/images/Jigsaw-puzzle-with-missing-piece-1670997600.jpg)

Last time on Nonstop Interop, I wrote that [the time was ripe](/blog/himss-stage-8-20221114) for HIMSS to add an additional stage focused on interoperability to its two most popular maturity models, EMRAM and O-EMRAM. Doing so would incentivize healthcare providers to embrace modern integration methods and would provide a strong roadmap of interoperability best practices that they can follow. Today I'd like to continue the discussion by outlining the key pieces to include in a possible Stage 8.

##### Themes and workflows

The first recommendation I would make is to anchor Stage 8 around specific themes. HIMSS does a pretty good job of this already within the models, so it would be consistent with what's currently in place. For example, in the EMRAM benchmarks are divided between key themes such as patient satisfaction, clinical workflows, and data analytics. Governance is another area of focus that's thoroughly incorporated into the existing stages, with change management processes required in Stage 2 of the EMRAM and system-wide governance with "a demonstrable history of solving problems" expected in Stage 7 of the O-EMRAM.

In addition, however, Stage 8 should target particular workflows where interoperability could have a powerful impact. It should require using data exchange technologies to automate workflows and free up staff for more complex problems. The models thus far shy away from being so prescriptive, so I recognize this would be a significant shift from the status quo. Nonetheless, it's the right move to accelerate the adoption of interoperable solutions.

##### Themes

I envision three themes forming the backbone of HIMSS Stage 8.

###### *Governance*

Interoperability deserves dedicated focus and oversight. Stage 8 should emphasize governance around interoperability, perhaps by encouraging each health system to form an interoperability council or to incorporate responsibilities into an existing governing body. The council would define and maintain the organization's roadmap for embracing higher levels of interoperability and would work with executives, department leads, vendors, and standards bodies to identify solutions to key problems.

###### *Standards*

FHIR is the future for healthcare data exchange; we've seen the federal government mandate its use in certain cases as it seeks to establish a common foundation for integrations. Stage 8 should require that health systems make FHIR APIs available to external entities—this should be easily satisfied by organizations using an ONC-certified EHR. Moreover, it should encourage them to participate in the advancement of interoperability standards through ways such as submitting comments to the ONC, serving on an industry workgroup, or participating in a connectathon.

That said, I strongly believe Stage 8 shouldn't mandate the use of FHIR. Not only is that a better role for regulators, but also it's important to give providers the flexibility to find the best solution for their circumstances and needs. Many would likely gravitate to FHIR wherever it could work, but there are a host of workflows where HL7v2, X12, or another standard may be the better fit.

###### *Transparency*

It should be easy for the public to understand how to integrate with a health system and to what extent it is integrating with others. To answer the how question, a Stage 8 organization should publish full specifications for the APIs, web services, and interfaces it can support. (These could be as simple as linking to documentation hosted by its EHR vendors.) It should also outline the steps a patient, peer institution, or vendor must follow to establish a connection and provide a way to get in touch with an interoperability point person.

To shed light on the extent of interoperability, Stage 8 could encourage providers to post metrics annually on its public website. Perhaps a particularly enterprising health system could host a dashboard that updates on a regular basis and allows for deeper analysis. While health systems should retain some discretion on what to share, I would love to see them outline the number of unique systems they are connected to, a breakdown of connections by type (e.g., FHIR API, non-FHIR API, HL7v2 interface), the average daily transaction volume per month, and a list of the most common data types exchanged (e.g., a list of FHIR resource types or HL7 message types). Having this data would not only be informative but could also expose gaps and stimulate ideas for future innovation.

##### Workflows

In terms of workflows, the below isn't an authoritative list; there are plenty of other possibilities that could make the cut. The emphasis, however, should be on workflows where the necessary technology and standards exist or will exist soon and where the benefits of interoperability and automation will reduce costs, alleviate burnout, and improve clinical care the most.

###### *Virtual care*

Even if in-person care continues to be the norm, virtual care should be embraced and offered by Stage 8 organizations. Video visits and messaging services that are tightly integrated with the EHR can make healthcare more convenient and accessible, especially for underserved populations and those without reliable transportation.

###### *Patient data submission*

Stage 8 should spur providers to allow patients to contribute to their clinical record. This could take the form of remote patient monitoring, patient-entered questionnaires, or integrations with consumer devices. I acknowledge that we'll need to balance this against the potential burden for clinicians, who should not have to review and reconcile enormous amounts of submitted data.

###### *Electronic payments*

This is a unique suggestion because the HIMSS maturity models have typically focused on the clinical side of healthcare. We can't ignore the financial side, though. This should be an easy win as the standards and technology for taking payments electronically have been available for more than a decade and most health systems do this already. Let's formalize it as a requirement in Stage 8; it should, however, only be required for organizations in countries where accepting patient payments is customary.

###### *Electronic prior authorization*

Like the previous one, this workflow is likely not as applicable outside of the US and a few other countries, but it's particularly timely given [CMS' recent proposed rule](https://www.cms.gov/newsroom/fact-sheets/advancing-interoperability-and-improving-prior-authorization-processes-proposed-rule-cms-0057-p-fact). Prior authorization is a laborious and inefficient undertaking today, but we have the fundamental pieces to make it much better.

###### *Automated release of information*

I'll admit I'm casting a wide net here, because release of information encompasses so many potential request types, requesters, and data needs. It's unlikely that interoperability can allow us to automate every release request in the near future, but HIMSS Stage 8 could focus on pushing health systems to digitize the easiest use cases, such as delivering clinical abstracts to patients, releasing notes and lab results to life insurance companies, or allowing specialty providers to obtain complete patient and encounter summaries when they receive a new patient referral.

\---

Photo by [Pierre Bamin](https://unsplash.com/@bamin) on [Unsplash](https://unsplash.com)


Outlining the key pieces to include in a possible HIMSS Stage 8

Defining a possible HIMSS Stage 8 - Nonstop Interop

Defining a possible HIMSS Stage 8

Boy standing on a ladder in a lake surrounded by mountains

![Boy standing on a ladder in a lake surrounded by mountains](/images/Boy-on-ladder-in-lake-1668405600.jpg)

To reach new heights, it's helpful to have a ladder. Each step brings steady progress towards the destination, though the last couple of rungs are the hardest to scale and require ample patience and balance. And if what you seek remains out of reach, you'll wish that ladder was just a bit longer.

We use ladders in health IT—figurative ones at least. Top of mind for me are the [maturity models](https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models) developed and administered by HIMSS. These frameworks offer healthcare providers stepping stones for greater adoption of digital tools and processes; best-known and most popular are the EMRAM and O-EMRAM, which respectively define roadmaps for maximizing EMR use in hospitals and outpatient clinics. It's a laudatory achievement to attain the pinnacle of Stage 7, and providers who do so benefit from digitized workflows and (hopefully) increased patient and clinician satisfaction.

As important as the goal of maximal EMR utilization is, however, it's increasingly insufficient. The burning priority for healthcare IT isn't the ability to punch orders into a computer but rather to exchange data beyond your four walls. Interoperability has become a key focus for practically every stakeholder, including patients and regulators, and it deserves a more prominent role within the EMRAM and O-EMRAM. We need a new HIMSS Stage 8 to guide providers in their interoperability journeys and to help the most integrated ones stand above the rest.

##### A little short

In fairness to HIMSS, it has baked a hint of interoperability into its offerings already. The [Continuity of Care Maturity Model](https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/continuity-care-maturity-model-ccmm) (CCMM) calls for "multiple entity clinical data integration" at Stage 3, e-prescribing at Stage 4, and a rather vague benchmark of "mobile tech engages patients" at Stage 5. Unfortunately, it seems that the CCMM hasn't caught on, as [not a single health system](https://www.himss.org/what-we-do-solutions/digital-health-transformation/achievement-list) has reached at least Stage 6 after [nine years](https://www.beckershospitalreview.com/healthcare-information-technology/himss-unveils-continuity-of-care-maturity-model.html) of existence.

Within the EMRAM and O-EMRAM, there are guidelines for participating in an HIE, exchanging discrete and unstructured data, and taking in lab results electronically. This is a decent baseline but doesn't push providers to adopt the latest and greatest. There's no mention of using APIs to release clinical information to payers and patient-authorized digital health apps. There's no declaration that providers should have a governance body overseeing implementation and auditing of integrations with third-parties. These gaps leave providers to figure out best practices on their own and slow down the adoption of new innovations.

##### A necessary step?

You may be questioning whether it makes sense to add interoperability to two tried-and-true maturity models. Wouldn't this be moving the finish line after the runners completed the race? And isn't it enough that the ONC is issuing regulations around info blocking and certified HIT that already promote interoperability? Fair points, but allow me to counter.

First, the ONC's approach has favored sticks over carrots. For an organization empowered to define the rules of the road, this isn't unexpected, but it would be valuable to have rewards as well. Incorporating interoperability more strongly within the EMRAM and O-EMRAM would incentivize providers who seek to be best-of-breed without introducing mandates on hospitals and practices with limited people or resources. Second, most of the recent ONC regulations for interoperability have been targeted at health IT developers, not healthcare providers. It's the developers, for instance, [who must ensure](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315) their products integrate with immunization registries and support bulk FHIR API requests. Instead, what I'm proposing addresses the provider side of the equation.

I also wouldn't think of this as an exercise in moving the goalposts. The achievements of a Stage 7 organization would not go away; Stage 7 would still be a gold standard for the effective use of information technology in healthcare. We all recognize, though, that technology evolves and advances, and how we measure our progress with technology should evolve and advance as well. We have an opportunity here for continuous improvement, something that can take organizations from the gold level to platinum.

##### Building a better ladder

Okay, that's the why behind a new Stage 8, but what should be the specific criteria within it? Given the numerous possibilities, that warrants a separate post to discuss. Look for my thoughts and examples in the next edition of Nonstop Interop.

\---

Photo by [Armand Khoury](https://unsplash.com/@armand_khoury) on [Unsplash](https://unsplash.com)



We need a new HIMSS Stage 8 to guide providers in their interoperability journeys and to help the most integrated ones stand above the rest.

It's time for HIMSS Stage 8 - Nonstop Interop

It's time for HIMSS Stage 8

Jack-o'-lantern on the head of a shadowy figure

![Jack-o'-lantern on the head of a shadowy figure](/images/Jack-o-lantern-head-1667192400.jpg)

If you’ve been in health IT circles for a while, the description of “beings who roam the world at night searching for people whose blood they feed upon” may make you think of both [vampires](https://www.history.com/topics/folklore/vampire-history) and EHR companies. The comparison is grossly unfair, though you’ll certainly [bleed money](https://www.healthit.gov/faq/how-much-going-cost-me) over EHR implementation and maintenance. EHRs are not ghouls, but that doesn’t mean they’re perfect either.

Case in point: in the interoperability world, EHRs have historically been very skeptical of middleware applications. By middleware I mean not only your traditional interoperability engines that serve as an integration layer between multiple software systems, but also digital platforms that strive to provide an all-in-one experience for patients and providers (and therefore make the EHR’s UI irrelevant). Middleware providers have struggled to get listed on EHR app marketplaces and to gain access to the full suite of integration options.

EHRs have had some understandable concerns regarding middleware. One is that middleware applications often serve as a pass-through to other software. EHRs can’t truly know where the data sourced from their databases is ending up and how it’s being used. Is that iPaas feeding data only to a CRM to boost patient engagement, or is it also shipping demographics to marketers, data brokers, or worse?

Hand-in-hand with that is the criticism that middleware seeks the interoperability kitchen sink. By connecting to every API and pulling every data point, middleware provides a primordial soup of integrations, rather than a standardized, tightly defined product with prescriptive use cases. This is particularly problematic in an industry whose daily operations revolve around clear, structured workflows. EHRs don’t want to risk blowback from their customers for sanctioning second-class software, and they are not alone. Apple, for example, places [26 printed pages](https://developer.apple.com/app-store/review/guidelines/) of requirements upon App Store developers to prevent a bad experience for its customers.

Yet if a third-party vendor has developed inferior software, shouldn’t it be up to its customers—both prospective and actual—to make that judgement for themselves? What EHRs miss in their trepidation is that middleware companies sell pretty much exclusively to other businesses, not directly to consumers. These businesses—whether they are health systems, technology companies, or researcher organizations—are savvy buyers who should own the responsibility and power to choose the best products for their needs. Likewise, rather than EHRs being the arbiters of who should and shouldn’t receive data, middleware’s customers should retain the authority to determine the right recipients.

Unsaid by EHRs is the challenge that middleware presents to their revenue models. App developer programs often mandate an annual fee just to participate in the official marketplace; Oracle Cerner, for instance, [pulls in $15,000-25,000](https://code.cerner.com/apiaccess) annually per application validation, with only the higher tier earning you the ability to market the app on the App Gallery. If a middleware system lists itself and integrates on behalf of 15 destination systems, that’s 15 lost sources of annual recurring revenue for the EHR. I can’t help but suspect that this is a major cause of the quaking in their boots; as sympathetic as I am about the loss of revenue, the primary objective of interoperability is seamless data exchange, not higher profitability.

Middleware has been a scary concept for EHRs; thankfully the information blocking regulations’ new, broader reach has lessened their fear—or at least, their resistance—though [the lack of penalties](https://ashavan.co/blog/hhs-oig-past-due-info-blocking-20221006) is holding back the rules’ full effect. The fears are misplaced, however, and interoperability would be better served if all varieties of software had access to EHRs’ integration options. Let’s open up the playing field and let providers decide what’s a trick and what’s a treat.

\--- 

Photo by [Kenny Eliason](https://unsplash.com/@neonbrand) on [Unsplash](https://unsplash.com)


Middleware has been a scary concept for EHRs; the fears are misplaced, however, and interoperability would be better served if all varieties of software had access to EHRs’ integration options.

Dear EHRs, don't be spooked by middleware - Nonstop Interop

Dear EHRs, don't be spooked by middleware

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
