Share this post

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

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

![Labyrinth game board with red ball](/images/Labyrinth-game-board-with-red-ball-1656306000.jpg)

"It should be easy." If you've dealt with interoperability in healthcare at any point within the past decade, that thought has probably crossed your mind at least once. Innovation and ingenuity have led to software that can chat with you like a human, transmit money to a bank account across the globe, and track a package from the warehouse to the front door. But in healthcare, it can be a struggle simply to pass a consolidated clinical summary from a referring provider to a specialist. In my mind, there are three key reasons why healthcare interoperability remains challenging.

##### Availability

Healthcare technology didn't begin with a culture of interoperability. That's understandable, given that we can trace health information management systems back to the 1960s when the industry was truly entering uncharted waters and our technological capabilities were far more limited than today's. Integrations have been added as business needs arose and standards were defined, but I would argue this bias towards interoperability as an add-on rather than an intrinsic feature slowed its progress.

Even now, the culture of interoperability is nascent and the availability of integrations is incomplete. HL7v2 interfaces are widely supported by EHRs and ancillary systems, but their publisher-subscriber model and lack of inherent security make them ill-suited for modern web applications. API coverage is growing, but among the major EHRs such as Epic and Cerner, the majority of APIs only support pulling data out, not pushing data in, and only for a single patient at a time. Most EHRs, payers, and clearinghouses don't advertise direct database access for advanced data extraction and analytics. And high costs to integrate—which I assert is common throughout the tech industry—can make available integration methods de facto inaccessible.

##### Complexity

Healthcare is difficult to distill down to ones and zeros. For one, it is ubiquitous across the globe, which means that healthcare integrations must accommodate the enormous variety of cultural differences. Take something as basic as a patient's name; in the Western world, we are accustomed to a pattern of first names and family names, with most people also having a middle name. How then to interoperate with software designed for a totally different region, such as Ethiopia where [patronymics](https://en.wikipedia.org/wiki/Patronymic) dominate instead? Street addresses provide comparable challenges across borders, yet true interoperability can't function only for Western standards.

Secondly, meaningful healthcare data encompasses an array of data points, types, and formats. There are discrete values like vital signs that boil down to a number with a unit of measure. There are free-text strings ranging from a brief reason for a visit to lengthy rich-text notes. There are images, PDF documents, code sets, and more, some of which could be intensely private or critical for patient care. It isn't like integrating with Google Maps, where a few details about your origin and destination results in a mundane set of driving directions. Healthcare is a reflection of the realities of life, and life is complex.

##### Fragmentation

This factor is the most difficult one to overcome, in my opinion. If healthcare IT is a jigsaw puzzle, modern interoperability is trying to put it together only to realize several pieces don't fit. You might perfect one or two corners, but the full picture can't be seamless.

In healthcare we rely upon a vast number of systems and data repositories, from EHRs to ancillary lab and radiology systems to public health registries and others. No two software applications or databases have the exact same data points and in the exact same format. Not one is an authoritative data source for a majority of patients (at least, not unless Oracle can truly pull off a national health records database—but I digress).

Compare this to, say, developing smartphone apps, where Apple's iOS and Google's Android have cornered the market. To make my app work, I only need to code to the standards of two platforms, and as those standards evolve, I can make updates that work for all users at once. Admittedly I'm oversimplifying—there are aspects such as OS versions to consider—but the permutations are still more limited, and the points of integration will remain the same whether my user is in Jakarta or Jackson Hole.

We simply don't have this luxury today in healthcare technology and we may never enjoy it. No doubt industry standards such as HL7v2, ANSI X12, and FHIR help reduce the complexity of integrations, but they don't eliminate the need for understanding and adapting to the nuances of each source and destination system, which is a time-consuming chore. This will always be a source of friction in the race to build an interoperable healthcare network.

##### Speed limits remain

The struggle is real. Healthcare could very well be the only industry in the U.S. where the federal government has had to mandate a minimum data set that must be exchangeable through APIs and to specify rules to prevent information blocking. To me, this speaks volumes to how challenging healthcare interoperability remains and how far we have to go. I can't say with certainty where the finish line lies, but I can say the journey isn't easy.

\---

Photo by [Alexas_Fotos](https://pixabay.com/users/alexas_fotos-686414) on [Pixabay](https://pixabay.com)


Learn about the three key reasons why healthcare interoperability remains challenging

Why interoperating in healthcare is hard - Nonstop Interop

Why interoperating in healthcare is hard

Composite of a man's silhouette composed of numbers and letters and a man forging metal with a hammer

##### ![Composite of a man's silhouette composed of numbers and letters and a man forging metal with a hammer](/images/Silhouette-of-man-and-hammer-forging-metal-1654491600.png)

##### Welcome

Welcome to Nonstop Interop and its first post! We’re excited to have you and to share our perspective on healthcare technology and the interoperability landscape.

I crossed the threshold into healthcare IT a decade ago, thinking I would stick with it for two or three years and then move on to greener pastures. As it turned out, the pastures in Verona, Wisconsin—and within the industry—proved to be more magnetic than planned.

I have a lot to be grateful for from the past decade—the wonderful people I’ve met, the cool places I’ve visited, the immense knowledge I’ve gained—and I hope Nonstop Interop is one way to offer the best portions to you. Thank you for making us a part of your world.

##### At the core

There is arguably no hotter topic in healthcare technology than interoperability. Numerous entities—from payers to technology companies to governments on multiple continents—are on a mission to make connected software and information networks ingrained into healthcare IT.

But interoperability is more than a buzzword. I wouldn’t characterize it as a trend either, because the word implies that its popularity and emphasis could wane in the future. To me, interoperability is a necessity, a rule of the road that is fundamental to 21st century healthcare.

Despite this, I admittedly catch myself sometimes questioning why interoperability is so important. Why does it matter if a technology startup with a new app can’t write recent vital signs into a patient’s electronic record? Which real-world problems actually arise when U.S. hospitals don’t provide pricing information in a machine-readable file as required by CMS?

Over time I’ve come to believe that interoperability’s value boils down to two key things: data and power. These two elements best capture the potential energy within interoperability, and they are fueling the explosion of integrations, standards, innovation, and regulation within our industry.

##### Data

Of these two core elements, the importance of data is more obvious in my mind. Data is the lifeblood of interoperability; the latter could not exist without the former. Imagine if a farmer tried to irrigate their fields while lacking any water. They could build all the pipes and connect all the pumps, but if there are no molecules of H2O to move from point A to point B, there's no irrigation.

Likewise, data is what gives interoperability a sense of worth. Organizations we work with at Ashavan often evaluate integration options in terms of the data points that they need to feed an algorithm or support a workflow. Acquiring a set of data means these organizations are acquiring knowledge that would otherwise be hidden from view and potentially underutilized, and that knowledge enables them to take meaningful action.

##### Power

This leads me to power. I’ve debated whether other factors such as money or transparency were more crucial, but in the end I feel power is the foundation upon which those stand. The siloed and independent nature of legacy health information systems meant that strength accumulated to those who held the most data, but interoperability diminishes that rule and provides a way for every stakeholder within healthcare IT to challenge the status quo.

With interoperability, technology companies of all sizes realize the power to create innovative products that could enable faster and higher quality experiences for users. Patients earn the power to participate in their own care and to ensure they can share their health information with whomever they want. Care coordinators and researchers gain the power to see the full breadth of a patient’s healthcare journey and better identify helpful interventions. The power at the heart of interoperability multiplies the potential within healthcare.

##### Wrapping up

Yes, interoperability is essential to modern healthcare. The ability to unlock data from repositories large and small empowers us to innovate and communicate more effectively, and while interoperability doesn’t guarantee better health outcomes for everyone, it does give us the power to move closer to that goal.

\---

Photos by [Amirhossein Azandarian Malayeri](https://unsplash.com/@mr_brightsides) on [Unsplash](https://unsplash.com) and [J.MT Photography](https://www.pexels.com/@j-mt_photography-628996/) on [Pexels](https://www.pexels.com)


Hear from our Founder and CEO on why interoperability comes down to data and power

Interoperability is all about data and power - Nonstop Interop

Interoperability is all about data and power

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
