Share this post

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

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

Person preparing a syringe from a vial of influenza vaccine

![Person preparing a syringe from a vial of influenza vaccine](/images/Vaccine-1666760400.jpg)

It's vaccine season. Not necessarily in an official sense, but with the approach of winter comes the [invariable](https://www.cdc.gov/surveillance/nrevss/rsv/natl-trend.html) rise in [respiratory](https://www.cdc.gov/flu/weekly/index.htm) [illness](https://www.cdc.gov/coronavirus/2019-ncov/covid-data/covidview/index.html) and the shots designed to prevent the worst outcomes. (Quick PSA: go get your flu shot and COVID booster. Both are important, and it would actually make me happy if you stopped reading this to [schedule an appointment](https://www.vaccines.gov/).)

Vaccines are pretty amazing things; they can prevent infection—though the rate varies and practically no vaccine blocks all infections in everyone—and even when they don’t, they reduce the chances of severe illness, hospitalization, and death. A small amount of substance—sometimes less than a milliliter—added to your body provides a wealth of protection. We have vaccines to thank for the eradication of [smallpox](https://www.who.int/health-topics/smallpox) and the great reduction in [measles](https://www.cdc.gov/measles/about/history.html) and [polio](https://polioeradication.org/polio-today/history-of-polio/) worldwide.

Those jabs take more than just a biological journey, however. Healthcare IT has played an important role in vaccine administration and monitoring for years, and we should acknowledge and applaud the success of vaccine-related integrations.

##### Through vessels and VPNs

A vaccine visit tends to be pretty straightforward. A qualified clinician will identify and prep the correct products, ask about any allergies or previous reactions, and administer the dose. From there, your immune system picks up on the new entrant and [begins its response](https://www.uchicagomedicine.org/forefront/coronavirus-disease-covid-19/demystifying-vaccines-1). Special white blood cells called [B cells](https://www.immunology.org/public-information/bitesized-immunology/cells/b-cells) produce antibodies to protect against the antigen, and another kind of white blood cell called [T cells](https://www.ncbi.nlm.nih.gov/books/NBK10762/) "memorize” the pathogen so that they can recognize it in the future and respond more quickly.

While all of this goes on, the clinician has likely documented the vaccine administration in your electronic medical record, which triggers its own call to action. Public health agencies in every state maintain immunization registries to keep track of who has been vaccinated and with which product, and every certified EHR is [required to be interoperable](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315#p-170.315$f$) with those registries. The EHR compiles information about you and the vaccine you received, such as the lot number and where on the body it was administered, and organizes it into an HL7v2 interface message designed just for vaccines. This VXU message is then sent to the appropriate registries to update them on your new shot.

It isn’t just a one-way street, either. Certified EHRs must also be able to query an immunization registry for a patient’s vaccine history. Imagine that you stepped on a nail and received a tetanus booster at an urgent care center. You’d want your chart at your PCP’s office to include all of your immunizations, so when your PCP logs in, they can trigger a request to download the latest details. A QBP message fires off to the registry, which will verify it can find you in the database, and if successful, an RSP message will venture back with data to review and reconcile into the medical record.

##### Integration tribulations

These vaccination integrations provide significant value, but they aren’t necessarily simple or perfect. For one, the lack of a centralized immunization registry means numerous connections are needed. Thankfully the CDC has [encouraged standards](https://www.cdc.gov/vaccines/programs/iis/technical-guidance/index.html) to minimize variation across the states, but these standards rely on older, tried-and-true HL7v2 messaging. We’re still years away from seeing FHIR APIs as the go-to technology for connecting to immunization registries.

Secondly, guarding against duplicate records is a persistent challenge. Since the registries typically cover an entire state, they receive messages from thousands of sources and maintain databases with millions of patients. They must parse through the demographics to determine if a particular message represents a brand-new patient or someone already in the system. Likewise, the vaccine administration details require diligent analysis to ensure nothing erroneous gets through.

The stakes are high. Public health officials rely on the registries to understand regional vaccination coverage and trends in reactions. Providers and patients rely on registries to identify missed vaccines and ensure children get the right shots on the right schedule. Underlying all of this is a system of interoperability that must be efficient and effective—and it is. While those B cells and T cells silently do their biological duty protecting you from harm, the bits and bytes of vaccine integrations are keeping digital systems up-to-date, and that enables everyone to live safer and healthier lives.

\---

Photo by the [CDC](https://unsplash.com/@cdc) on [Unsplash](https://unsplash.com)


Healthcare IT has played an important role in vaccine administration and monitoring for years, and we should acknowledge and applaud the success of vaccine-related integrations.

Vaccines move through more than just your body - Nonstop Interop

Vaccines move through more than just your body

Two coins partially stacked on a brown table

![Two coins partially stacked on a brown table](/images/Two-coins-on-table-1665637200.jpg)

"Can you explain OAuth to me?" A customer posed this question recently and I happily obliged, describing how tokens are its currency, how it differs from [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), and where you can see it in use in everyday life. Then, I thought nothing of the conversation for a few days.

I realized later that I probably gave the customer an incomplete answer. I offered a decent lesson on the basics of OAuth and how it works, but I don't think I did justice to why it's so valuable. In the world of healthcare interoperability, our hearts start pounding over concepts like USCDI and TEFCA. FHIR is likely the greatest source of excitement and it no doubt holds great potential. But if I had to vote tomorrow for the most impactful idea thus far for 21st century interoperability, I would choose OAuth.

##### A standout standard

Before I expand upon my opinion, let's go over some of the facts. The most basic thing to know about OAuth is that it is a standard. If you work in healthcare, you live, breathe, and eat standards. There are standards for how medications are coded, how quickly stroke patients should receive treatment, and which diagnoses can be used on claims. ("Burn due to water skis on fire" somehow makes the cut.) In healthcare IT it's no different. We have a veritable alphabet soup to guide us on exchanging data over point-to-point interfaces (HL7v2, X12) and protecting information and managing risk (HITRUST), among countless other things.

OAuth is a standard that allows apps to connect to one another in a secure fashion by proving that a user is really who they claim to be and that they have permission to do the things they want to do. Like any good standard, it has improved over time, and [OAuth 2.0](https://oauth.net/2/) is the latest version. There are a few flavors but I'll focus on what's known as the "[authorization code grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.1)."

You probably have used OAuth in your life without realizing it; if you've ever visited a website and created an account by clicking a button that says "Log in with Google" or "Log in with Facebook," that's OAuth. When you click that button, app #1 (the website) communicates with app #2 (the "identity provider," such as Google or Facebook) and says "Hey, this user wants to log in with their account." If you aren't already signed in, the identity provider will ask for your username and password to prove your identity, and it may ask you for permission to connect your account to the website and to share a few details.

Does this mean Google and Facebook are leaking your username and password to other apps? Not at all. The language of OAuth is tokens; when these apps talk to one another, they exchange long combinations of numbers and letters called tokens, which serve as a passport of sorts to uniquely identify you and what you're trying to do. These tokens allow app #2 to tell app #1 "You have permission to use this user's account with your website. Just be sure to show this passport when you send a request to me, so that I know it's legitimate."

##### Reducing the friction

This use of tokens is a key aspect of OAuth's value to healthcare interoperability. First and foremost, from a patient's perspective, OAuth simplifies the experience of connecting apps to your medical records. When you can log in and pull data securely using an existing account—say, a patient portal account—you have a user experience with less friction, not to mention fewer usernames and passwords to remember. Tokens also expire and become useless relatively quickly, usually within an hour, so they provide a greater layer of protection in case someone malicious gets ahold of one.

The benefits are equivalent for the developers of healthcare apps, because they can design their app without needing to manage and secure an extra set of login credentials and without needing to accommodate unique authentication workflows for every EHR. Think back to 2015 when Meaningful Use Stage 3 first [mandated patient access](https://www.federalregister.gov/d/2015-25595/p-1501) to their health information through APIs. Could this endeavor have ever been successful if app developers needed to support a dozen authorization schemes in order to support a critical mass of EHRs? I am skeptical.

##### Winner

I do not intend to downplay the importance of FHIR or any other standard relevant to healthcare interoperability. Really smart, passionate people have created these essential frameworks, and we need all of them to accelerate our progress. But FHIR, USCDI, and TEFCA are too new in my mind to have had the greatest impact to this point, and more mature standards like HL7v2 and X12 are hamstrung by their dependency on event-driven point-to-point interfaces, which aren't conducive to an app-based ecosystem. OAuth provides a simple, secure structure to enable software systems to communicate, and from my point of view, it has been the most important standard thus far for modern healthcare interoperability.

\---

Photo by [Erdenebayar](https://pixabay.com/users/erdenebayar-740663/) on [Pixabay](https://pixabay.com)


OAuth provides a simple, secure structure to enable software systems to communicate, and it has been the most important standard thus far for modern healthcare interoperability.

OAuth - not FHIR - has been the most important standard for modern interoperability - Nonstop Interop

OAuth - not FHIR - has been the most important standard for modern interoperability

![Pile of one hundred dollar bills](/images/100-dollar-bills-1665032400.jpg)

Today's a big day. The information blocking regulations have now reached their full scope and cover all electronic health information, rather than the limited subset of data points from USCDI version 1 as has been the case for 18 months. This is a positive step forward; while I wish the government didn't need to get involved, it's clear that rules of the road are needed to advance interoperability, and Congress empowered the ONC to establish these guidelines.

The work isn't done, however. The ONC was responsible for defining the info blocking rules and it has fulfilled its obligations. The Office of the Inspector General for Health and Human Services, as well as HHS itself, were tasked with outlining the penalties and disincentives for info blocking violations, and both are late to the party.

##### Where we stand

There are a few different characters in the info blocking saga, so let's do a quick review. [Three kinds of entities](https://www.healthit.gov/sites/default/files/page2/2020-03/InformationBlockingActors.pdf) are subject to the regulations—healthcare providers, health information networks/exchanges, and certified health IT developers, which collectively the ONC terms "IB actors." [Congress empowered the OIG](https://www.healthit.gov/sites/default/files/page2/2021-11/Information-Blocking-Portal-Process.pdf) to investigate all claims of info blocking, and the OIG retains most of the enforcement authority as well. For healthcare providers, though, HHS takes the lead on establishing and applying disincentives.

The OIG [issued a proposed rule](https://oig.hhs.gov/newsroom/news-releases/2020/infoblocking.asp) for the civil monetary penalties it can levy, and it gave a 60-day comment period. It also stated its goal of not enforcing any penalties until at least 60 days after the final rule is published. Trouble is, this all happened back in April 2020. Since then, there have been few public updates other than that they are prepping a final rule and that [it's a priority](https://oig.hhs.gov/documents/speeches/314/hcca-04292021-handout.pdf). HHS has similarly said it is [hard at work](https://www.healthcareitnews.com/news/hhs-secretary-cures-act-enforcement-long-overdue) on rule-making.

While no clear reasons have been given for the delays, understandably both departments have had a lot on their plates. The Senate didn’t [confirm Inspector General Christi Grimm](https://www.congress.gov/nomination/117th-congress/750) until February and the office lacks a confirmed Principal Deputy Inspector General. Additionally, the COVID-19 pandemic has rightfully been a top focus area that has taken resources and attention from other initiatives.

##### Why it matters

Finalizing the penalties and disincentives has the obvious benefit of putting teeth into the info blocking regulations. Rules aren't potent without a means of holding bad actors accountable and discouraging future bad behavior. HHS' rule-making would be especially valuable since [more than three-quarters](https://www.healthit.gov/data/quickstats/information-blocking-claims-numbers) of info blocking complaints submitted thus far have been about healthcare providers.

Yet final rules would also help the IB actors by providing clarity on what to expect. It is not fair to subject these groups to new rules without clearly outlining the consequences of their violation. As it stands, everyone is in the dark about the severity of punishment (outside of the limits Congress wrote into the Cures Act), and uncertainty is no one's friend.

It's time for both HHS and the OIG to step up and complete the rulemaking process on penalties and disincentives. Only then can we say that all the tools to combat info blocking are in place.

\---

Photo by [Giorgio Trovato](https://unsplash.com/@giorgiotrovato) on [Unsplash](https://unsplash.com)


The information blocking regulations have reached their full scope, but they cannot be considered complete until HHS and the OIG define the necessary penalties and disincentives.

HHS and the OIG are past due on the info blocking penalties - Nonstop Interop

HHS and the OIG are past due on the info blocking penalties

Yellow road sign that says "Speed humps ahead"

![Yellow road sign that says "Speed humps ahead"](/images/Road-sign-speed-humps-ahead-1664514000.jpg)

Today is the final day to [submit feedback](https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi) to the ONC on version four of the USCDI. Since USCDI first came out in 2020, the ONC has made several useful updates and regularly raised the bar on the data that Certified Health Information Technology must be able to exchange. For example, version 2 added sexual orientation and gender identity as constituent data elements to better support care for LGBTQ+ patients, and version 3 brought the first billing-related data class of health insurance information. No doubt USCDI is an important standard that moves healthcare interoperability forward.

Yet USCDI can't reach its full potential as long as the regulations for CHIT continue to focus on read and search capabilities. Currently, vendors are required only to provide a standard API that can "[respond to requests](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315#p-170.315$g$$10$)" for the mandatory data points. This solves only one half of the interoperability equation. The ability for external systems to create and update data in a patient's chart is equally important in the pursuit of a competitive app-based ecosystem.

##### Write about that

Why is write access as important as read? For one, the ability to write data into an EHR opens up a large number of workflows for digital health companies. Remote patient monitoring, insurance verification, diagnostic questionnaires, and clinical research immediately come to mind, but the possibilities go well beyond such a short list.

Secondly—and just as importantly—write access better enables innovators to challenge the dominant position of EHRs as the guardians of our health information. Prioritizing read and search implies that the EHR knows all and you should just accept that. Anyone with experience in this industry, however, recognizes that the fragmented nature of health IT means the EHR can't be everywhere and know everything. There are numerous sources of data—from patients to wearables to insurance payers—that could meaningfully contribute to a patient's health record if they just had an easy, standards-based way to do so.

Plus, establishing a floor for CHIT to accept data over RESTful APIs will accelerate our shift to modern standards and technologies. Nowadays plenty of write operations occur, but vendors must work around limited API support and leverage options such as HL7v2 interfaces and file imports. These can work well in many instances, but they can take longer to implement, are harder to scale, and come with extra baggage such as the need for a VPN. The technology for 21st-century data exchange exists; we just need to nudge CHIT developers towards robustly supporting it.

##### Do it the write way

To be clear, federal rules don't need to require unlimited write access. They could take an incremental approach, first obligating updates and then create operations, and it may not make sense to mandate delete access via APIs. I acknowledge too that mandating write access will create additional burdens for CHIT developers, since validating, sanitizing, and ingesting data from an external source is inherently more complex and riskier than responding to a request. Yet another reason why slow and steady is likely best here. Nevertheless, it's important that we begin this journey now; otherwise the power of USCDI will continue to be stifled.

\---

Photo by [Michael Anthony](https://www.pexels.com/@michaelanthony/) on [Pexels](https://www.pexels.com)


USCDI can’t reach its full potential as long as the regulations for CHIT continue to focus on read and search capabilities.

USCDI's power will be stifled until write access is required - Nonstop Interop

USCDI's power will be stifled until write access is required

![SARS-CoV-2 (coronavirus)](/images/SARS-CoV-2-1663736400.jpg)

"The pandemic is over." That's [President Biden's belief](https://www.cbsnews.com/video/60minutes-2022-09-18/), though neither the World Health Organization nor the U.S. Department of Health and Human Services has declared an end to the COVID-19 emergency. We are certainly in an interesting period where much of the general public has moved on yet public health officials are (rightfully) concerned about new variants, surges, and the hundreds of Americans dying from COVID each day.

What is definitely not over, however, is the battle against [post-COVID conditions](https://www.cdc.gov/mmwr/volumes/71/wr/mm7121e1.htm), better known as "Long COVID." Long COVID sufferers (sometimes called "long-haulers") have faced persistent symptoms—at times debilitating ones—since their infections, and sadly we haven't figured out what causes it or how to best prevent and treat it. The exact scope of Long COVID isn't even clear, though by some estimates, it is having a significant impact on the job market and patients' ability to work.

This is a perfect example of how interoperability could make an enormous difference in people's lives. Interconnected systems could help us better track and analyze who has Long COVID, what their infection was like, which treatments have been tried and which ones have proven effective. But the fragmentation of our healthcare technology ecosystem means information lives in silos, and silos don't breed success. Solving the Long COVID puzzle requires an acceleration in interoperability; millions living with the condition deserve nothing less.

##### Bearing a great burden

We don't truly know how many people are living with Long COVID, but it's likely a large number. The National Bureau of Economic Research [published a paper](https://www.nber.org/system/files/working_papers/w30435/w30435.pdf) this month calculating that half a million Americans have been pushed out of the labor market due to COVID. The Brookings Institution [went even higher](https://www.brookings.edu/research/new-data-shows-long-covid-is-keeping-as-many-as-4-million-people-out-of-work/), estimating as many as four million people could be out of work due to Long COVID, at a cost of up to $230 billion in annual lost wages. Both reports measure only working-age Americans, so they surely undercount the true prevalence.

Relief for the millions of long-haulers is also lacking. The National Institutes of Health and the Centers for Disease Control and Prevention are [coordinating](https://recovercovid.org/) studies on [COVID's long-term effects](https://www.covidinspire.org/), and HHS [produced a report](https://www.covid.gov/assets/files/Services-and-Supports-for-Longer-Term-Impacts-of-COVID-19-08012022.pdf) last month outlining the various resources available to individuals with Long COVID. Yet the answer to the fundamental question of "Why did I develop Long COVID and how can I treat it" remains elusive. Several large health systems have established Long COVID clinics to provide focused treatment, but doctors are forced to fit in patients as they can and to [rely on informal networks](https://www.politico.com/news/2022/09/07/doctors-are-taking-it-on-themselves-to-figure-out-long-covid-00054748) for sharing best practices. From the patient's perspective, they must endure extra appointments and shuttling between primary care and specialty providers—that is, if they even have easy access to help.

##### Stitching together a solution

It doesn't have to be this way. Imagine a world where providers can easily flag patients with Long COVID and add them to a regional or national registry. Patients could meet with providers through telehealth visits, complete assessments on a mobile device, and automatically report vitals through remote patient monitoring services, all of which improve accessibility for low-income and rural patients. Providers who take on new Long COVID referrals could receive medical records electronically, relieving long-haulers of the strain of repeatedly recounting their ordeals. And researchers could pull together aggregate data on Long COVID to identify trends and promising treatment options using metrics, rather than guesswork or anecdotes.

Nothing I've described is outside the realm of possibility—in fact, from a technology perspective, we have all of these capabilities already. But we lack the interoperability network to stitch it all together. It's as if we have dozens of pieces of fabric but we're still well short of a quilt. For us to truly make headway with Long COVID, we need to make it easy to identify and track cases, gather discrete and narrative data, and exchange this data with the organizations and people who can use it to better long-haulers' lives. Without improved interoperability, providers and patients are left to fend for themselves, and the costs associated with treating Long COVID balloon due to inefficiency and duplication. With greater interoperability, we can harness data to return [power](https://ashavan.co/blog/interoperability-data-power-20220607) to those who have suffered for too long.

\---

Illustration by [Fusion Medical Animation](https://unsplash.com/@fusion_medical_animation) on [Unsplash](https://unsplash.com)


Silos don't breed success. Solving the Long COVID puzzle requires an acceleration in interoperability; millions living with the condition deserve nothing less.

Long COVID is a perfect example of the need for greater interoperability - Nonstop Interop

Long COVID is a perfect example of the need for greater interoperability

![Female weightlifter performing squats](/images/Female-weightlifter-performing-squats-1661317200.jpg)

This month the Federal Reserve wrapped up its [annual stress test program](https://www.federalreserve.gov/supervisionreg/stress-tests-capital-planning.htm) for the largest American banks. Thanks to the Dodd-Frank Act of 2010, each year the Fed simulates the impact of a severe economic downturn on these pillars of finance to ensure they would remain solvent and able to support the economy. Earlier in the summer, the Fed announced that [all banks performed well](https://www.federalreserve.gov/newsevents/pressreleases/bcreg20220623a.htm), even in the face of tougher criteria than last year, and can withstand "total projected losses of $612 billion." More recently it outlined the [minimum capital requirements](https://www.federalreserve.gov/publications/files/large-bank-capital-requirements-20220804.pdf) for each institution to guarantee sufficient cushion against a recession.

Good to know, but this blog is not about banking and finance. (If it were, maybe we would call it Perpetual Pesos.) Yet we can learn something from the world of money that is pertinent to healthcare interoperability. Today, developers of Certified Health IT (CHIT) must meet a wide variety of requirements outlined in federal regulations, yet none of those regulations address the basic level of technical performance and stability. This needs to change. If we are to have truly seamless integration in healthcare, we must have standards that enforce the speed and availability of data exchange, and CHIT should be held accountable to those standards.

##### A dollar short

Under the current rules, CHIT must support [a host of workflows](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315) from electronically ordering medications and labs to sending a Continuity of Care Document during a transition of care. The 21st Century Cures Act led to [API requirements](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-D/section-170.404) and information blocking rules as well. These are good things, but thus far the federal government's carrots and sticks have been aimed at the features and usage of clinically focused software.

Nothing in the current standards requires CHIT developers to simulate a large spike in API calls and HL7 interface messages or for vendor-hosted EHRs to guarantee a level of uptime. As our healthcare data highways become more congested, we need to elevate the importance of system performance and availability. Consumers, clinicians, and innovators need to be able to trust that when they reach out electronically for information, the source system will be almost assured to respond quickly.

##### Going from rags to riches

What would it look like to set and enforce performance standards for CHIT? I envision something akin to the Federal Reserve's stress test program, but with changes that account for the uniqueness of healthcare and for the regulatory processes already in place.

For one, any new rules should apply to all CHIT and not just the largest vendors. While some banks may be more important and impactful to our economy given their size, healthcare data is valuable regardless of the source or its parent company's market share. Considering the [fragmented nature](/blog/interoperating-healthcare-hard-20220627) of our data today, a patient could have meaningful information stored in both a major EHR used in a hospital and a tiny competitor used in a small physician clinic, so it's essential that every CHIT vendor meets expectations.

Secondly, the ONC has already defined a process for CHIT to attest that it follows the regulations and to conduct real-world testing to verify the technology meets the legal requirements. Congress should empower the ONC to define and enforce technical criteria that can be incorporated into this process. For example, CHIT could be required to measure and report annually the percentage of system uptime per production instance, the number of API calls received in total, the number of API calls that failed due to a server error, and the total and failed number of XDS.b document sharing transactions.

Additionally, the real world testing process could be enhanced to include simulations of high-volume transactions. In light of the growing focus on big data and analytics, I would advocate for CHIT to test and verify that they can efficiently respond to numerous simultaneous multi-patient requests, such as through Bulk FHIR. CHIT could be instructed on specific scenarios to test and data points to measure, and the ONC could use this information to publish an interoperability report card that allows health systems and app developers to better compare how well each product performs.

##### Pass the buck?

The framework I've described is simply a starting point and certainly needs refinement. I acknowledge there are some flaws out of the gate, mainly around who isn't included.

First, I've focused only on CHIT, but in reality, interoperability is important for all kinds of other non-certified products as well, such as data warehouses, PACS, and LIMS. Should we force these other systems to become certified as well? I don't think so, at least not within the current CHIT guidelines. Perhaps we could start with a voluntary program to allow ancillary applications to measure and report their technical performance.

Similarly, I've focused this discussion primarily on APIs and similar request-response exchange technologies. HL7v2 interfaces are still a big part of healthcare interoperability, however, and should not be left out. The challenge is that health systems often route these transactions through an interface engine, and EHRs can't be held accountable for the performance of another vendor's software. Again, there may be an opportunity for interoperability platforms and EHRs to collaborate and voluntarily demonstrate how well they perform together.

Lastly, CHIT can run simulations day and night, but what matters in the end is how well each production instance is performing in real life. This introduces complicating factors such as hardware and security software that can influence integration performance. Again, EHRs can't be held accountable for things not under their control, which would be the case for any product hosted by the healthcare systems. And I do not think we should impose new regulations on every meaningful user of CHIT, as that would introduce additional burdens on thousands of providers—some of whom, such as Critical Access Hospitals and Federally Qualified Health Centers, may not have the staff and resources to comply. Yet we must find a way to ensure the outcomes seen in an idealized test environment translate into the same bang for the buck in day-to-day interoperability.

\---

Photo by [Alora Griffiths](https://unsplash.com/@aloragriffiths) on [Unsplash](https://unsplash.com)


Stress tests should be required for Certified Health IT - Nonstop Interop

Stress tests should be required for Certified Health IT

Composite of a doctor using a smartphone and a smartphone with the Amazon logo on the screen

![Composite of a doctor using a smartphone and a smartphone with the Amazon logo on the screen](/images/Doctor-using-a-smartphone-and-a-smartphone-with-amazon-logo-1659934800.webp)

Arguably the biggest news in healthcare over the last four weeks has been Amazon’s planned $3.9 billion acquisition of One Medical. Plenty of debate abounds about what this move means for [healthcare delivery](https://www.beckershospitalreview.com/healthcare-information-technology/will-amazon-change-healthcare-health-system-cios-weigh-medical-one-s-acquisition.html) and [data privacy](https://www.washingtonpost.com/technology/2022/07/22/amazon-one-medical-privacy/). (Fortunately for One Medical’s CEO, his estimated $119 million payout in the all-cash transaction hasn’t generated nearly as much buzz.)

There’s no doubt that Amazon is looking to make inroads in brick-and-mortar healthcare and to bring a more consumer-friendly and tech-first model to how we seek out and manage our care. Will they revolutionize the industry? No one knows at this point, though history is [not on their side](https://apnews.com/article/business-9bfc3b1192055c9e1a305bb18fd77ccf).

But what isn’t being discussed is how the success of this deal will be dictated by interoperability. Amazon is acquiring a company and a business model where integrations are crucial to their existence, and it faces a path that could lead to opportunistic wins or painful struggles.

##### A big fish to fry

Let’s establish one thing first: interoperability is vital to One Medical’s growth. It said so itself in its most recent [annual report](https://www.sec.gov/Archives/edgar/data/0001404123/000140412322000010/onem-20211231.htm): "If the integration process with our partners is not executed successfully or if execution is delayed, we could incur significant costs, partners could become dissatisfied and decide not to continue a strategic contractual relationship with us beyond an initial period during their term commitment or, in some cases, revenue recognition could be delayed, any of which could harm our business and results of operations."

As a primary care-only provider, One Medical relies on health network partners to offer specialty services and inpatient treatment for its members. One Medical must be able to exchange patient data with those providers to arm the specialists with the necessary data for treatment, and likewise, those partners must be able to route notes, images, and a variety of other data points back to One Medical’s 1Life EHR in order to achieve a closed loop of care.

Even internally to One Medical, integrations are the lifeblood of its operations. The same annual report notes that "our members depend on our digital health platform, including our mobile app, web portal, and support services to access on-demand digital health services or schedule in-office visits." The healthcare-at-your-fingertips approach that keeps existing members happy and attracts new ones doesn’t work without every system being tightly interconnected.

##### Keep it simple

On the one hand, if there’s any work needed to enhance and expand One Medical’s internal interoperability capabilities, Amazon can make an immediate impact. It has the technical talent and resources to wholesale overhaul the 1Life platform to ensure it is primed for integrations. But such an effort would only address one half of the equation.

The challenge for Amazon as it adds virtual and physical care locations will be scaling and accelerating connections with its health network partners. These providers host a multitude of EHRs and ancillary software systems, all of which have varying integration capabilities, and their IT teams are likely already managing high workloads. Amazon can’t afford to open a location in a new city but then spend months faxing documents to-and-fro while it attempts to connect to the specialty clinics and hospitals in the area. That will simply inflate administrative costs, frustrate providers, and deter potential members and partners. The integration process must be efficient and cost-effective.

The key for the U.S.’s fourth-largest company will be making ease of integration a primary factor in its pursuit of partners. As it evaluates the players in the market, it should consider interoperability up there with traditional factors like prestige, accessibility, and quality of service. If the prospect’s EHR is challenging to connect to, then move on and target a relationship with someone else. This of course has the downside of limiting providers’ choices for where to refer patients, but it gives Amazon the certainty and repeatability needed to ensure it can rapidly scale operations. The alternative—pursuing laborious integration projects and creating and supporting heavily customized solutions—would be a momentum killer.

##### The better road

Building and perfecting integrations will be a significant source of friction as Amazon grows its primary care business. If it hasn’t experienced it yet, Amazon will quickly see why fragmentation, complexity, and availability make healthcare interoperability so hard. But it can find a happy path by elevating the importance of interoperability in its growth strategy and being selective in its partners. This is not an easy road to follow, but done the right way, it can lead to climbing mountains instead of laboring through mud.

\---

Photos by [The National Cancer Institute](https://unsplash.com/@nci) and [Christian Wiediger](https://unsplash.com/@christianw) on [Unsplash](https://unsplash.com)


Amazon's acquisition of One Medical is big, but interoperability will be a major factor in the deal's success

Interoperability will drive the success of Amazon's One Medical acquisition - Nonstop Interop

Interoperability will drive the success of Amazon's One Medical acquisition

Mural of the Monopoly man mimicking "see no evil, hear no evil, speak no evil"

![Mural of the Monopoly man mimicking "see no evil, hear no evil, speak no evil"](/images/Mural-of-monopoly-man-1658206800.jpg)

It's been a year since President Biden signed [an executive order](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/07/09/executive-order-on-promoting-competition-in-the-american-economy/) aiming to address market concentration and competition within a host of industries. Healthcare featured prominently in the list, with the president decrying the effects of hospital mergers and the continued high cost of prescription drugs. Very valid concerns, in my opinion, and issues that should be tackled not only by the executive branch but also the legislative one.

The premise of the executive order is that excessive market concentration, monopoly, and limited choice are bad. With this I wholeheartedly agree. But the question in my mind is: is this a concern within healthcare interoperability? In a way, we seem to have the opposite problem. As I argued in [our last edition](/blog/interoperating-healthcare-hard-20220627) of Nonstop Interop, healthcare IT suffers from ailments such as fragmentation that make it difficult to exchange data. Could we see benefits to our pursuit of frictionless data exchange if the market were more condensed? Let's ponder.

##### Ground rules

First, let's be clear about the scope of this analysis. I'm examining this topic through the lens of interoperability in healthcare technology only; in no way does it apply to healthcare delivery, price transparency, pharmaceuticals, or the myriad other topics where reduced competition are real and relevant concerns.

In the subsequent paragraphs, I'm making an assumption that the market has solidified around one offering per type of software. So, imagine a monopoly for EHRs, for radiology and cardiology PACS, for lab information systems, etc., on top of which developers can build narrowly tailored apps. How we got to this point—whether through mergers and acquisitions, government action, or something else—isn't pertinent. It just matters that we are at the end state of one dominant player with no imminent threat of competition.

With the ground rules in place, let's re-examine the factors from our last post with an eye towards how greater market concentration could change the interoperability landscape.

##### Availability

Here I'm doubtful that greater consolidation will make interoperability easier. If anything, I would argue that having a single market participant would disincentivize offering greater integration options.

A software provider is first and foremost protective of its own usefulness and viability, so its goal is to elevate its product as a must-use tool rather than to debase it as a repository. Why go out on a limb and offer more integration choices when your customers have nowhere else to turn? Absent an external force, such as rules by a regulatory body, the dominant entity would have little reason to invest in greater interoperability.

##### Complexity

Even if there were high availability of integration options in a monopolized environment, there's no guarantee the complexity of integrations would be alleviated. On the one hand, having a single system and data model to align to would provide a level of consistency that is lacking today. For example, if you knew that all healthcare providers used the same version of athenahealth as their EHR, your integration decisions would become simpler.

The complexity of interoperability, however, is ultimately rooted in the complexities of culture and medicine. No buffet of software choices, or lack thereof, can eliminate this reality. In our imaginary ecosystem of monopolies, the data model of the EHR likely won't be perfectly complementary to the data model of the LIS, which in turn won't be perfectly complementary to the data model of inventory management system. Thus, interoperability will still face a mountain of complexity to climb.

##### Fragmentation

When I began writing this post, I had high hopes that monopolies could at least solve the fragmentation problem. A single source system for all to tap into—how much better can it get for interoperability? Much better, actually.

The sticky and unavoidable problem in healthcare is that patients don't carry their data with them. The healthcare provider owns the software and the data within it, and they typically only know what happens within their four walls. In IT speak, this is the dreaded problem of every provider having its own software instance. Even with a single ubiquitous system, nothing prevents a patient from having a different health record across multiple instances, and an app developer has to be aware of and connected to each of those instances in order to gain a complete picture of the patient's health.

##### A road not yet traveled

This post's title is admittedly a bit gimmicky. It's obvious in my mind that monopoly would be terrible for practically anything, healthcare interoperability included. Monopoly of software would not solve the major challenges of interoperability, and there are factors such as cost, choice, and innovation that make monopolies detrimental to our economy and our lives. But while market concentration may not be beneficial, could data concentration perhaps be a win for interoperability? I'll leave that question for exploration in a future post.

\---

Photo by [BP Miller](https://unsplash.com/@bp_miller) on [Unsplash](https://unsplash.com)


Could we see benefits to our pursuit of frictionless data exchange if the healthcare IT market were more condensed?

Is monopoly the solution for interoperability? - Nonstop Interop

Is monopoly the solution for interoperability?

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
