When Did the Patient Become the Integration Layer in Healthcare?
How a single healthcare transaction exposed a broken end-to-end billing process.
A finger laceration sent me to the ER in February 2025. The wound was treated, the claim was eventually processed, and an Explanation of Benefits (EOB) was issued. Yet in September 2026, I was still dealing with the billing issue.
That experience made me ask a question that has stayed with me:
When individual transactions work, but the end-to-end process still fails, where exactly is the system breaking?
What happened?
The timeline is simple.
February 2025 – Emergency care
I went to the ER for a finger laceration requiring stitches. The hospital had my insurance information, but the physician who treated me belonged to a separate emergency physician group.
At that point, I was focused on getting treated. I had no reason to think I would later need to coordinate between multiple organizations to resolve the resulting bill.
March 2025 – Separate physician bill
I received a separate bill from the physician group and provided my primary and secondary insurance information.
From a patient perspective, that felt like the end of my responsibility: provide the insurance information and let the healthcare organizations process the claim.
June 2025 – Communication breaks down
I was contacted again about the balance.
I tried to get the payer and provider to communicate directly. At one point, I stayed on a call while the payer attempted to reach the provider, but they could not connect.
I was eventually advised to submit the claim myself.
So I did.
Not because I had paid the bill and was seeking reimbursement, but because the normal payer-provider communication path wasn't getting the issue resolved.
August 2025 – Claim processed
The payer processed the claim and issued an EOB.
At that point, I believed the matter was resolved.
September 2026 – The issue resurfaces
Almost a year later, I received another voicemail about an outstanding balance.
I pulled the EOB again, contacted the provider, supplied the documentation, and am now waiting for the issue to be reviewed.
The wound healed. The billing issue didn't. 😅
There were long periods when I genuinely believed the issue was resolved. This was not 18 months of continuously chasing the same bill. But each time it resurfaced, I had to reconnect information that already existed across the organizations involved.
That is what made me stop looking at this as simply a billing problem.
Looking at it as a systems problem
From the patient perspective, I received one healthcare service.
Administratively, the experience looked more like:
Hospital → Physician Group → Payer → Billing → Patient
Each organization may have been performing its own function.
But the patient's experience is not made up of those individual functions. It is the end-to-end journey.
And that distinction matters.
A claim can be submitted.
A payer can adjudicate it.
An EOB can be generated.
Yet the patient's account can still remain unresolved.
That means a transaction completing is not necessarily the same thing as the process completing.
Where does the gap actually occur?
I don't know that the root cause in my case was EDI.
I don't know that it was interoperability.
I don't know that it was a privacy constraint.
And I don't know whether a specific billing-system workflow or manual exception process failed.
Those would require visibility into the actual payer and provider workflows.
But that uncertainty is precisely what interests me.
Healthcare already has standardized mechanisms for claims, claim status, and payer-to-provider remittance information. CMS describes electronic remittance advice as a mechanism for communicating adjudication and adjustment information to providers, including information that can be used to associate the payer's decisions with the corresponding claim and support posting into billing applications.
There are also standardized electronic claim-status transactions intended to reduce reliance on manual phone calls and enable information to be posted into provider accounts.
So the question isn't simply:
"Why didn't the organizations communicate?"
It is more fundamental:
If the infrastructure for exchanging claims and adjudication information already exists, what happens when the information does not translate into a reconciled provider account?
The missing layer may be exception management
This is where I think the process becomes particularly interesting from an operations perspective.
The normal flow might look like:
Claim Submission → Adjudication → Provider Remittance → Account Reconciliation → Patient Responsibility → Resolution
But what happens when the normal flow doesn't work?
Perhaps:
Claim → Adjudication → Data Mismatch → Exception → Ownership → Reconciliation → Resolution
The important piece is the exception path.
If the payer and provider records don't align, the process needs to answer:
Who detects the mismatch?
Who owns it?
What information is exchanged?
How is the discrepancy tracked?
What prevents the account from continuing down a billing or collection path before the discrepancy is resolved?
And most importantly:
Why should the patient have to become part of that workflow?
The patient as the manual integration layer
This is the part I find most striking.
When the payer tells the patient to contact the provider, and the provider tells the patient to have the payer call them, the patient becomes the connector between two systems.
When a phone call cannot be completed, the patient becomes the follow-up mechanism.
When an EOB exists but the provider still needs documentation, the patient becomes the data-transfer mechanism.
In systems terms, the end user is compensating for a process boundary.
That may be understandable in an individual exception.
But when the same issue can persist or resurface over a long period, it raises a larger process-design question.
What should the patient experience look like?
From the end-user patient perspective, my requirement is extremely simple:
I received care. After insurance processes the claim, tell me clearly what I owe.
I don't need to know which billing entity owns which workflow.
I shouldn't have to understand the payer's system, the provider's billing system, or the communication protocol between them.
I certainly shouldn't have to act as the project manager coordinating two organizations.
The complexity should be handled behind the scenes, not transferred to the person receiving the service.
The question I'm left with
I'm not arguing that healthcare organizations need one giant system or that every issue can be solved through technology alone.
The more interesting question is:
How do we design the handoffs, information exchange, exception management, and ownership across organizations so that a patient does not become the integration layer?
Because from a systems and operations perspective, the objective shouldn't simply be successful transaction processing.
It should be successful end-to-end resolution.
Working on healthcare administrative productivity solutions has given me an operational lens, while experiencing this as a patient gave me a very different perspective: what happens when the process breaks down at the end user.
And perhaps that is the real healthcare operations question:
How do we make sure the loop actually closes?
Can AI help close the gap?
AI could potentially help with the exception layer of this process.
Imagine a payer adjudicates a claim and the provider's account shows a materially different balance. Instead of relying on a patient to pay and then discover the discrepancy, an automated reconciliation process could identify the mismatch, match the relevant records, classify the exception, route it to the appropriate team, and track it until the provider account is reconciled.
AI could therefore help with detection, matching, classification, routing, and follow-up.
But AI cannot solve the problem if the underlying organizations lack the necessary data exchange, access, or ownership model.
That leads to an even bigger systems question:
Are we looking at an AI problem, or are we looking at a process and interoperability problem where AI could become an enabling layer?
For me, the answer is closer to the latter.
The goal shouldn't be to make the patient a more efficient messenger. It should be to eliminate the need for the messenger.
References & Further Reading
CMS – Health Care Payment and Remittance Advice
Supports the point that payer adjudication and payment/adjustment information can be electronically communicated to providers through remittance advice. This backs the question of what can still break down after a claim has been adjudicated.
CMS – Claim Status Request and Response
Supports the observation that standardized electronic mechanisms exist for payer-provider claim-status communication, raising the question of why some resolution workflows can still depend on manual follow-up.
CMS – Operating Rules for Eligibility and Claims Status
Provides support for the broader idea that healthcare administrative processes have been designed to reduce manual information exchange and make payer-provider workflows more standardized and electronic.
Supports the observation that, despite widespread electronic transactions, healthcare administration still has opportunities to reduce manual processes and improve automation. This reinforces the distinction between having electronic transactions and having a fully connected end-to-end process.
CMS – Federal Independent Dispute Resolution Operations Final Rule (2026)
Supports the broader point that payer-provider communication and information exchange can still present operational challenges even where formal processes already exist.
