It’s 9:15 on a Tuesday morning, the waiting room is full, and your electronic health record system just stopped loading. Charts won’t open. The front desk can’t pull up today’s schedule. Everyone turns to the office manager, who is now staring at a phone trying to decide which support number to call. The EHR vendor? The IT company? And while that decision gets made, providers are standing in hallways and patients are watching the clock.
This is one of the most common, and most stressful, questions we hear from medical and dental practices. When the system that runs your whole day goes down, whose job is it to fix it? The honest answer is that it depends on what actually broke, and a good chunk of the frustration comes from nobody having drawn that line clearly before the bad morning arrived.
Let’s draw it now.
The simple way to split responsibility
Think of your EHR as a piece of software sitting on top of a stack of other things it needs to work. The software itself is the vendor’s responsibility. Everything underneath it, the part that lets the software run and reach the people who use it, is your IT company’s responsibility.
Your EHR or practice-management vendor owns the application. That means the actual program code, the features, the database structure they built, software bugs, version updates, and how the system behaves when you click a button. If a specific screen throws an error, if a report calculates wrong, if a new release breaks a workflow, that is a vendor support ticket.
Your IT company owns the environment the software lives in. That is the server or cloud connection the application runs on, the network, the workstations in each operatory or exam room, the internet circuit, the firewall, user accounts, backups, and security. If the application will not load because the server is offline, because the internet dropped, because a workstation will not connect, or because a Windows update broke something underneath, that is an IT issue.
The trouble is that from the front desk, both failures look identical. The screen is frozen either way. So the real skill is not memorizing a rulebook, it is having someone who can quickly figure out which side of the line the problem fell on, and who is not going to bounce you back and forth.
Where it actually gets murky
If the split were always clean, nobody would be confused. Here are the situations that cause the most finger-pointing, and how to think about them.
Cloud-hosted EHRs. Many practices now run a cloud EHR like Dentrix Ascend, Open Dental’s cloud option, athenahealth, or eClinicalWorks. In that model the vendor hosts the application and the database in their own data center. So if their platform is down, that genuinely is on them, and there is little your IT company can do except confirm your side is healthy. But here is the part people miss: cloud EHRs still depend completely on your internet connection, your local network, your workstations, and often a local scanner, imaging sensor, or label printer. When a cloud EHR feels slow or will not load at one workstation, the problem is very often local, and that is squarely IT’s job.
Server-based EHRs. If your practice runs Dentrix or Eaglesoft on a server in a closet down the hall, that server, its database service, its backups, and its performance are part of your IT environment. The vendor wrote the software, but keeping the box it runs on healthy, patched, and recoverable is IT work. We see practices assume the vendor is watching that server. They are usually not.
Imaging and integrations. Digital X-ray sensors, intraoral scanners, and the bridges between your EHR and other systems sit right on the seam. The imaging hardware and its drivers are typically IT and the device manufacturer’s territory. How the image lands inside the patient chart is a vendor integration. When imaging breaks, the answer is usually “let’s look together,” which is exactly why having one coordinated team matters.
Why “just call the vendor” fails you
Plenty of practices try to handle EHR problems by calling the software vendor directly every time. It feels logical, the vendor made the software. The problem is that vendor support is built to answer questions about their application, not to troubleshoot your network, your server, or the workstation in operatory three. When the issue is environmental, and a large share of them are, the vendor will reasonably tell you it’s not their software and point you back to IT. Now you’ve lost forty-five minutes and you’re back where you started, except the waiting room is fuller.
A genuinely local IT provider changes that dynamic. When you have a partner who already knows your setup, the first call goes to one place. They can immediately check the things only IT can see, the server, the network, the internet circuit, the specific workstation, and either fix it on the spot or tell you with confidence “this one is the vendor, here is the ticket I have already opened with them on your behalf.” That difference, between bouncing around alone and having someone own the coordination, is most of what you are paying an IT company for.
This is also where having a provider with local people matters more than anything. An offshore help desk reading from a script can’t walk into your office, look at the server, and tell your providers when they’ll be seeing patients again. We can, because we have technicians right here in Alaska and Hawaii who know your practice.
Plan for downtime before it happens
The practices that handle an EHR outage calmly all have one thing in common. They decided ahead of time what they would do when, not if, the system goes down. HIPAA’s contingency planning requirements expect this too. You are supposed to have a documented plan for operating, and protecting patient data, when systems are unavailable. The Department of Health and Human Services lays out the data backup, disaster recovery, and emergency mode operation expectations in the Security Rule.
A workable plan answers a few plain questions. How does the front desk check in patients and keep the schedule if the system is down for two hours? Where are the paper downtime forms, and does anyone know where they are kept? Who calls IT, and what is the number? How do entries get back into the system once it is restored? If you do not have those answers written down, our EHR/System Downtime Contingency Plan template is a straightforward starting point you can adapt to your practice in an afternoon.
The goal is not to predict every failure. It is to make sure that when one happens, your team reaches for a plan instead of arguing over a phone number.
Where to start
If your practice has never clearly mapped which problems go to the vendor and which go to IT, that conversation is worth having before your next busy morning. We’re happy to sit down, look at how your EHR is set up, whether it’s cloud or on a server in the building, and help you draw those lines so the right call goes to the right place the first time.
No pressure and no jargon, just a clear picture of who fixes what, so the next time a screen freezes your team knows exactly what to do.