An EHR vendor and IT provider dispute over who owns a technology issue almost always comes down to one missing thing: nobody was ever assigned to coordinate between them when something breaks.
The EHR has been sluggish all morning.
Charts take twenty seconds to load instead of two.
A nurse tries to enter vitals and the screen freezes entirely.
The office manager calls the EHR vendor’s support line.
After a twenty-minute hold, a support representative runs a few checks on their end.
“Everything looks normal from our side,” she says. “This is probably a network issue. I’d recommend contacting your IT provider.”
The office manager calls the IT company next.
A technician reviews the network, checks internet speed, confirms the server is running normally.
“Our systems all look fine,” he says. “This looks like it’s happening inside the EHR application itself. That would be something for your EHR vendor to look into.”
The office manager is now holding two professional opinions, both confident, both polite, and both pointing at the other.
Meanwhile, the waiting room is still full.
The charts are still slow.
Nobody at either company is lying.
Nobody is necessarily even wrong, from their own narrow view of the system.
And the practice is stuck in the middle, no closer to a working EHR than it was an hour ago.
This Is Not a Rare Situation. It Is a Structural One.
Ask around, and most practice owners and office managers have a version of this story.
It usually is not caused by incompetence on either side.
It is caused by how modern healthcare technology is actually built.
A single EHR session today typically depends on multiple separate systems working together: the EHR vendor’s application and servers, the practice’s internet connection, the practice’s internal network equipment, the workstation itself, and often additional integrated systems such as e-prescribing services, lab interfaces or clearinghouses.
Each of those pieces is usually supported by a different company.
Each company can accurately verify that its own piece is functioning correctly.
None of them, by default, has explicit responsibility for troubleshooting the connections between those pieces, or for looking at the problem as a whole rather than as a narrow slice.
The result is a system where every vendor can be technically correct and the practice still has no resolution.
Why Vendors Genuinely See Different Things
This is not usually a matter of vendors being evasive.
An EHR vendor’s support team typically has visibility into their own application’s servers, performance logs and known issues.
If their servers are responding normally and no other customers are reporting the same issue, their diagnostic tools may genuinely show nothing wrong on their end.
An IT provider, similarly, can usually confirm that the practice’s internet connection, internal network and workstations are functioning within normal parameters.
If bandwidth looks fine, latency looks fine and no obvious network errors are occurring, their tools may genuinely show nothing wrong on their end either.
The actual problem may be sitting in the narrow space between these two views: a specific integration point, a browser configuration issue interacting oddly with a specific EHR update, an authentication token expiring unpredictably, or a very specific pattern of network behavior that only manifests under certain conditions the EHR vendor’s monitoring does not track.
Neither vendor is necessarily equipped, or contractually obligated, to investigate that narrow space unless someone specifically directs them to.
HIPAA Business Associate Agreements Don’t Solve This Either
Many practice owners assume that because their EHR vendor and IT provider both sign HIPAA Business Associate Agreements, some formal structure already exists governing how these companies coordinate during an outage.
That assumption is usually incorrect.
A Business Associate Agreement, as required under the HIPAA Security Rule, establishes obligations regarding the protection, use and disclosure of protected health information.
It is a privacy and security compliance document.
It does not typically function as an operational agreement establishing who leads troubleshooting during a performance issue, who coordinates communication between vendors, or who is accountable for a resolution timeline.
A practice can have fully compliant Business Associate Agreements with both companies and still experience exactly the scenario described above, because those agreements were never designed to solve that particular problem.
NIST’s Guidance on Third-Party Risk Points at the Real Gap
NIST’s guidance on supply chain and third-party risk management emphasizes that organizations should understand their dependencies on external vendors and service providers, including how those relationships interact with one another and where responsibility boundaries actually sit. Our managed IT services start with mapping exactly that dependency chain for your practice.
Applied to a medical practice’s technology environment, this means understanding, in advance, exactly which vendor is responsible for which layer of the system, and critically, who is responsible for coordinating across those layers when something breaks.
Most practices have never actually mapped this out.
They know they have an EHR vendor.
They know they have an IT provider.
They generally assume that if something goes wrong, “someone” will figure it out.
That assumption is exactly the gap that leaves practices stuck between two support lines, each accurately describing their own piece of a puzzle nobody has been assigned to assemble.
The Fix Is Not Complicated, But It Has to Be Explicit
The solution to this problem is not more technology.
It is a defined, agreed-upon point of ownership for troubleshooting coordination, established before an issue occurs rather than during one.
This typically means one of two things.
Either the practice’s IT provider is explicitly contracted to serve as the first point of contact for any technology issue, including issues that ultimately turn out to be inside the EHR application itself, with responsibility for engaging the EHR vendor’s support team directly and driving the issue to resolution.
Or the practice designates a specific internal person responsible for coordinating between vendors when finger-pointing occurs, with clear authority to escalate and push for resolution rather than accepting “not our problem” from either side.
Without one of these arrangements explicitly in place, the default outcome is exactly the scenario at the start of this article: two accurate diagnoses, zero resolution, and a practice stuck coordinating a technical investigation it never should have had to manage on its own.
What “IT Provider as First Point of Contact” Actually Means
Some IT providers position themselves narrowly: they support the network, the workstations and the server, and anything involving the EHR application itself is explicitly outside their scope.
Other IT providers position themselves as the practice’s single point of contact for any technology issue, with an explicit responsibility to engage the EHR vendor’s support team on the practice’s behalf, track the ticket through to resolution, and escalate when the vendor’s response is inadequate.
These are very different service models, even if the marketing language describing them sounds similar.
A practice should know explicitly which model its IT provider actually operates under, because that distinction determines exactly what happens the next time an EHR issue arises that does not have an obvious cause.
If your IT provider’s contract or service description does not clearly state whether they will personally engage your EHR vendor’s support team on your behalf during an issue, that is a gap worth closing before it matters.
A Documented Vendor Escalation Process Changes Everything
A mature practice, or a mature IT provider serving that practice, should maintain a documented vendor escalation process.
This does not need to be complicated.
At minimum, it should identify every technology vendor the practice depends on: the EHR vendor, internet service provider, IT provider, e-prescribing service, clearinghouse, phone system provider and any other critical technology dependency.
For each vendor, it should identify the correct support contact information, any account or reference numbers needed to expedite a support call, and specifically who at the practice or IT provider is responsible for engaging that vendor when an issue arises.
Critically, it should designate who owns cross-vendor coordination: the specific person or organization responsible for driving an issue to resolution when the initial diagnosis from either vendor does not solve the problem.
Without this document, every technology issue starts from zero, with staff improvising who to call and in what order, often during the exact moment when the practice can least afford confusion.
What This Looks Like When It Works
Consider the same scenario from the beginning of this article, but with a properly defined escalation process in place.
The EHR becomes sluggish.
Staff report it to the designated IT provider, who is contractually responsible for coordinating any technology issue regardless of where it ultimately originates.
The IT provider checks the network, confirms it is functioning normally, and then contacts the EHR vendor’s support team directly, using an established support relationship and reference information already on file.
If the EHR vendor’s initial response does not resolve the issue, the IT provider continues escalating, potentially requesting the vendor’s technical team investigate further, rather than the practice being told to call back later.
The practice staff experience a single point of contact and a coordinated resolution process, rather than two separate phone calls and two separate, dead-end diagnoses.
The technical challenge of an ambiguous root cause has not disappeared.
But the practice is no longer the one responsible for solving a coordination problem it was never equipped to solve in the first place.
Why This Matters Beyond Simple Convenience
An EHR performance issue that drags on for hours because of vendor finger-pointing is not merely an inconvenience.
It directly affects patient care, staff efficiency and, depending on the nature of the issue, potentially the availability of electronic protected health information that HIPAA’s Security Rule is specifically concerned with.
A practice that cannot get a clear answer about who owns troubleshooting an EHR performance issue also likely cannot answer more serious questions about contingency planning, disaster recovery ownership or incident response coordination during a genuine emergency.
The everyday frustration of “it’s not our problem” phone calls is often a visible symptom of a larger, unaddressed gap in how the practice’s technology relationships are structured.
The Staff Perspective Nobody Talks About
There is a human cost to this problem that rarely gets discussed openly.
The office manager or front desk staff member stuck coordinating between two support lines is not trained in network diagnostics or EHR architecture.
They are trying to translate what one vendor said into language the other vendor will accept as a valid starting point, often while also managing patients, phones and a full schedule at the same time.
This is an unreasonable position to put a non-technical staff member in, repeatedly, without them ever having agreed to take on that responsibility.
Over time, this kind of recurring frustration contributes meaningfully to staff burnout and turnover, particularly for the office managers and administrators who end up as the default point of contact simply because nobody else has claimed that role.
Addressing the underlying vendor coordination gap is not only a technical improvement.
It removes an unfair and exhausting burden from staff who were never supposed to be the ones solving it.
A Real-World Example of How Quickly This Escalates
Consider a slightly different version of the same scenario, one involving a specific integration rather than general slowness.
A practice’s e-prescribing feature suddenly stops working. Physicians can no longer send prescriptions electronically.
The EHR vendor confirms their e-prescribing module is functioning normally and suggests the issue may involve the practice’s internet connection or a firewall setting blocking the required connection.
The IT provider checks the firewall and internet connection, confirms normal function, and suggests the issue may be specific to the EHR vendor’s e-prescribing integration itself.
Meanwhile, physicians are manually calling in prescriptions or writing paper scripts, adding significant time to every patient visit.
This is a scenario where the actual root cause might involve a specific certificate expiration, a change on the pharmacy network side, or a very particular firewall rule interacting with a recent EHR update. It requires someone with authority and technical knowledge to push both vendors toward a coordinated investigation rather than accepting two separate “not our problem” conclusions.
Without a designated owner of that coordination, this kind of issue can persist for days, quietly costing the practice significant time on every single patient encounter.
Are you contractually responsible for engaging our EHR vendor’s support team directly when an issue arises, or is that our responsibility?
Do we have a documented vendor escalation process identifying every technology vendor we depend on and who is responsible for coordinating with each one?
If our EHR vendor tells us “it’s a network issue” and you tell us “it’s the EHR,” who is responsible for resolving that disagreement?
Do you maintain an ongoing relationship with our EHR vendor’s support team, or would a new issue start from zero each time?
What is our documented escalation path if a first-line resolution does not solve the problem?
If your IT provider cannot answer these clearly, your practice may be more exposed to exactly this scenario than you realize.
The Goal Is One Phone Call, Not Two
Practices do not need every technology vendor relationship to be perfect.
They need clarity about who is responsible for coordinating when something breaks, established before it happens rather than negotiated in real time while the waiting room fills up.
A single, accountable point of contact, backed by a documented escalation process and an established relationship with your EHR vendor’s support team, transforms “it’s not our problem” from a dead end into a starting point for actual resolution.
ITva Technologies provides managed IT services for medical practices across Miami-Dade and Broward, with a specific focus on serving as a true single point of contact for technology issues, including active coordination with EHR vendors rather than narrow network-only support.
Our managed IT services include documented vendor escalation processes, so your staff always know exactly who to call and what happens next when an issue arises.
Our cybersecurity services ensure that vendor coordination during an incident also accounts for HIPAA security and availability requirements, not just getting the system back online quickly.
If your practice has never confirmed exactly who owns troubleshooting between your EHR vendor and your IT provider, that is worth clarifying before the next slow morning, not during one.
Schedule a free IT and vendor management assessment with ITva.
We will review your current vendor relationships, escalation processes and support agreements, then show you exactly where coordination gaps may exist.
Because the next time something goes wrong, your practice deserves one clear answer.
Not two confident ones that cancel each other out.
Frequently Asked Questions
Why do EHR vendors and IT providers often disagree about the source of a problem?
Each vendor typically has visibility only into their own layer of the technology stack. An EHR vendor can confirm their servers and application are functioning normally, while an IT provider can confirm the network and workstations are functioning normally, even when the actual problem exists in the specific interaction between the two.
Does our Business Associate Agreement establish who resolves technical issues?
Generally, no. A Business Associate Agreement addresses the protection, use and disclosure of protected health information under HIPAA. It does not typically function as an operational agreement defining troubleshooting responsibility or vendor coordination during a technical issue.
Should our IT provider be responsible for contacting our EHR vendor directly?
This depends on how your IT provider’s services are scoped. Some IT providers explicitly serve as a single point of contact for any technology issue, including coordinating with EHR vendors. Others limit their scope to network and workstation support only. It is worth confirming explicitly which model applies to your practice.
What is a vendor escalation process?
A vendor escalation process is a documented plan identifying every technology vendor a practice depends on, the correct contact information for each, and specifically who is responsible for engaging and coordinating with each vendor when a technology issue arises.
Can this kind of coordination gap create a HIPAA compliance issue?
It can contribute to one, particularly if a prolonged technology issue affects the availability of electronic protected health information, which is a specific concern under the HIPAA Security Rule. A clear vendor coordination process helps ensure that availability-related issues are resolved promptly.
How can we tell if our current IT provider actually coordinates with our EHR vendor?
Ask directly whether they are contractually responsible for contacting your EHR vendor’s support team during an issue, and whether they maintain an ongoing relationship or reference history with that vendor. If the answer is unclear, it is worth clarifying before the next issue arises.