Reciprocity, Treatment Use, and the Missing Link in Health Information Exchange

Every day, millions of medical records are exchanged behind the scenes for doctors through health information exchange networks across the United States. These networks exist so that when a clinician is treating a patient, they can access outside medical records and use that information to improve care.

One of the most important national frameworks for this kind of exchange is Carequality®. Carequality helps connect different health systems, EHRs, vendors, and clinical organizations so that medical records can move when there is a valid reason to access them, such as treatment.

A core concept in these networks, and especially in Carequality-style exchange, is reciprocity.

Reciprocity means you cannot just take from the network. If you are going to retrieve valuable clinical data from other participants, you also need to contribute clinical data back.

That matters because the network only works if participants are both receiving and contributing data. If one side only pulls records and never makes useful clinical data available in return, the exchange becomes one-sided. The organizations doing the hard work of making records available get less value back.

Reciprocity is meant to prevent that. Reciprocity is what allows participants to trust the framework. The network works because each participant understands that access is not purely extractive: those who benefit from the exchange also have a responsibility to contribute useful clinical information back when they create it.

A lopsided model would undermine that trust. If some implementers and participants do the work of supporting data sharing while others use the network without meaningfully contributing in return, the framework starts to look unfair. Over time, that dynamic would discourage the largest data contributors from operating in good faith and could weaken the exchange for everyone.

In a real treatment workflow, this is not so different from a familiar doctor-to-doctor referral relationship.

When a physician refers a patient to a specialist, the ideal expectation is not that the specialist simply receives the patient, performs an assessment, and disappears from the care picture. The referring physician expects some form of follow-up: what the specialist found, what they recommended, what treatment plan was discussed, and what should happen next.

Health information exchange works best when it reflects that same basic clinical norm at network scale.

If a clinician uses outside medical data during a patient visit, that clinician will often create a new clinical artifact: a SOAP note, consult note, radiology report, operative note, discharge summary, uploaded document, or another piece of treatment documentation.

That new treatment data can then be made available back through the exchange for future clinicians caring for the same patient.

In other words, reciprocity is not just a technical participation requirement. It is the network-level version of a familiar clinical expectation: when you benefit from the patient’s prior record, you should contribute useful new information back to the patient’s longitudinal record.

Treatment access and reciprocity are related, but they are not the same thing

Health information exchange networks support different types of data requests, including treatment, payer, and patient access requests.

A treatment request is powerful because other participants are expected to respond when there is a valid treatment purpose. In Carequality, this is a major part of how the network functions: if a clinician is treating a patient, the exchange is designed to make the relevant outside medical record available to support care.

But that also means the implementer making treatment requests has a responsibility to make sure its participants are actually using the data for treatment.

That does not just mean there is a clinician somewhere in the workflow. It means the data is being used in a real care context by a clinician who is caring for the patient.

This is where a lot of confusion happens.

Reciprocity is a network participation requirement. It helps show that a participant is contributing value back to the exchange. But reciprocity by itself does not automatically prove that the data being retrieved is actually being used for treatment.

Providing useful data back is a good signal. It may suggest that there is a real treatment workflow happening. But it is not, by itself, complete evidence that the retrieved HIE data is actually being embedded into clinical care.

That distinction matters.

A common gray area

Here is a simple example.

A company has patients complete telehealth visits with licensed clinicians. During those visits, the clinicians create treatment notes. Those notes are useful and can be made available back through the exchange.

Separately, the same company participates in value-based care contracts and works with payers to close care gaps. The company then partners with an implementer to pull more medical data through an API so it can support that value-based care business line.

The company may say: we have a treatment relationship, we create treatment notes, we get patient consent, and we push those notes back through reciprocity.

All of that may be true.

But the important question is different: is the HIE data actually being used by the clinician during the care workflow?

If the outside records are retrieved before the visit, but the clinician does not review them, does not use them to make treatment decisions, and the data mainly flows into a secondary analytics or care-gap process, then reciprocity alone does not prove treatment use.

In that scenario, the participant may be meeting reciprocity. They may also have a real treatment workflow. But there is still not clear evidence that the HIE data being retrieved is actually being used to improve care during that treatment workflow.

The treatment visit created a useful document that can be shared back. But the outside data was not actually embedded into the treatment workflow. It was primarily being used somewhere else.

That is the problem.

Why the UI matters

This is why the user interface matters so much.

It is very hard to show that HIE data is being used for treatment if the data is only being pulled through an API and never shown to the clinician in a way that meaningfully supports care.

A clinician needs to be able to actually use the information.

That can happen in a few ways.

The participant may own and manage a clinical application that clinicians actively use during treatment, where they review records, create notes, upload documents, and generate clinical artifacts that can be shared back.

The participant may integrate a clinical application into an EHR, so the clinician can use that outside data during the visit.

Or the participant may use an API, but then needs a real workflow for the clinician to use the data during care and for new treatment data to be made available back to the network.

If a clinician is actively using a UI platform during a treatment workflow, reciprocity is usually much more straightforward. The clinician is using the data. The workflow is tied to care. New treatment data can be created, uploaded, reviewed, and made available back through the exchange.

But if a company connects an app to an API, then the company needs to be much more deliberate. It needs to handle the pushback. It needs to show that the data is being used for treatment in their UI application. And it needs to make sure the workflow is not just a secondary-use data pipeline with a treatment note attached to it.

Storage versus pass-through

Implementers can support reciprocity in different ways.

One approach is for the implementer to store the clinical data under its business associate agreement with the participant and make that data available to other authorized implementers when appropriate.

Another approach is for the implementer to act as a pass-through, where incoming requests are routed back to the participant and the participant handles the response.

In practice, because of the complexity of HIE infrastructure, latency expectations, network availability, and the development capabilities of many participants, it is often safer for the implementer to store the data and support the exchange workflow directly.

That does not mean the data is being used for unrelated purposes. It means the implementer is helping the participant meet the technical and operational requirements of exchange.

How Abstractive Health approaches reciprocity

At Abstractive Health, we simplify reciprocity by building a clinical application that doctors actually use while treating patients.

That sounds obvious, but it is not. A lot of companies underestimate how hard it is to get clinicians to use outside medical records during real care.

It is not enough to have access to the data.

In the real world, clinicians often have only a few minutes for pre-visit chart review. When an outside record retrieval returns hundreds or thousands of pages, the practical problem becomes obvious: no clinician can functionally sift through all of that material, identify what matters, and apply it to the patient’s care in the time they actually have.

That is why health information exchange cannot stop at record retrieval. The information has to be organized, summarized, and made usable inside the clinical workflow.

The data has to be usable, fast, summarized, and integrated into the way clinicians actually think.

We have found that many organizations start by wanting a pure API workflow. But over time, they often realize that the safer and more clinically useful structure is to make the Abstractive application available to their clinical staff.

That is because the application creates a clearer treatment workflow. Clinicians can retrieve the record, review the medical history, interact with the summary, ask questions against the chart, use that information during care, and then upload or create clinical artifacts that can support reciprocity.

That is the point of health information exchange.

Not just to move data around.

To make sure the right clinician can actually use the right information at the right moment to take better care of the patient.