A medical practice does not have one pool of data to back up. It has at least five, and they behave nothing alike. The EHR database changes every few minutes and must come back fast. Imaging files never change but must remain retrievable for years. Microsoft 365 looks backed up and mostly isn’t. Billing data is nobody’s favorite subject until a month of claims disappears. And the scanned documents from the paper chart era sit wherever they landed a decade ago.
A backup plan that treats all of that as “the server” will protect some of it well, some of it badly, and some of it not at all, and the gaps only surface on the worst possible day, with a full schedule and patients in the waiting room. So take them one at a time.
How should the EHR database be backed up?
The first question is where the EHR actually runs, because the answer changes the job completely.
On premises. If the EHR server lives in the practice, the backup is entirely your responsibility, and a database has requirements a plain file copy does not meet. Copying live database files underneath running software produces backups that may not restore, or that restore into an inconsistent state. The EHR needs an application-aware backup that coordinates with the database, captures frequently enough that a bad day costs hours of charting rather than a week, and lands a copy somewhere ransomware in the office cannot reach. This is also the system with the tightest recovery clock in the building: when the EHR is down, providers are charting on paper and the schedule is degrading in real time.
Hosted or cloud. If the vendor hosts the EHR, the database is on their infrastructure and they run backups of their platform. That removes the mechanical work but not the responsibility, which brings us to the question every practice with a hosted EHR should be able to answer in writing.
We support the environment EHR systems run on, whichever model a practice uses, and coordinate directly with the software vendor when the answer lives inside the application, so the practice is not stuck relaying messages between its IT provider and its EHR vendor. More on that split in our guide to EHR and practice management IT support.
The vendor says they handle backups. What do you still need to know?
“The vendor handles it” is where diligence usually stops, and it is exactly where it should start. Vendor backups exist first to protect the vendor’s service. Whether they protect your practice depends on answers most practices have never asked for:
- What is actually covered? The clinical database, usually. Attached documents, faxes, and imported files, sometimes. Your customizations and templates, ask.
- What can they restore, and to when? Whole-platform recovery is not the same as restoring the one chart a staff member damaged last Tuesday. Ask whether granular restores are possible, how far back the restore points go, and what a restore request costs.
- What is the restore SLA? Not the uptime number in the brochure. How long from your call to your data back, in writing.
- What happens at contract exit? If you switch EHRs or the vendor is acquired or shuts down, how do you get your data, in what format, at what cost, and how long after termination is it still available? Practices have learned at the exit that the export is expensive, slow, or barely usable. Ask before signing, and again before renewal.
If any answer is vague, price that vagueness into the relationship. And notice what vendor backups never cover: everything else in this article.
What do imaging and DICOM files need?
Imaging is the odd one out, and treating it like ordinary file data wastes money at best and loses studies at worst. Three traits drive the design.
The files are large. X-ray, ultrasound, CT, and other modalities generate storage measured in terabytes over the life of a practice. Backup bandwidth, storage cost, and restore time all scale with that.
The files are immutable. A study is written once and never edited. That is a gift: unchanging data belongs on a durable archive tier that is verified for integrity, not churned through the nightly incremental forever. Back up new studies as they arrive, then let the archive hold them cheaply and verifiably.
The retention is long. Imaging often has to remain retrievable for many years, with the clock and duration depending on state law, record type, and patient age. Whatever your policy says, the archive has to actually reach that far and stay readable that long, across media generations and system migrations.
One trap deserves bold type: the images and their index must be captured together. A PACS or imaging module pairs the image files with a database that says which study belongs to which patient. Restore the files without the index and you own terabytes of unfindable pixels. Application-aware, both halves, consistent point in time.
Isn’t Microsoft 365 already backed up by Microsoft?
No, and this is the most common gap we find in practices of every size. Microsoft operates a shared responsibility model: they keep the service available and protect against failures on their side. Recovering your data after your own staff deletes it, after an account is compromised, or after ransomware syncs encrypted files up to the cloud is your side of the line.
What looks like backup inside Microsoft 365 is a set of deletion grace periods with default windows measured in days or weeks: recoverable items in Exchange Online, recycle bins in SharePoint and OneDrive, a short holding period for a departed employee’s OneDrive. Useful for “I deleted that this morning.” Useless for “we need the referral correspondence as it stood last spring,” and no help at all when a compromised account’s files are encrypted and the encrypted versions replicate to the cloud looking like legitimate edits.
For a practice this matters more than it first appears, because Microsoft 365 quietly carries PHI: referral emails, patient communications, shared spreadsheets, scanned attachments. The fix is an independent Microsoft 365 backup with its own storage and retention the practice controls, covering Exchange, SharePoint, OneDrive, and Teams. Given how much clinical and administrative material lives there, this is not an add-on to the backup plan. It is a full pillar of it.
What about practice management and billing data?
Billing data is easy to deprioritize because it is not the chart, but losing it means losing unfiled claims, aging receivables, eligibility records, and the payment history behind every patient balance. “We reconstructed the month as best we could” is not a sentence anyone wants to say to a partner or an auditor.
Like the EHR, practice management and billing systems usually sit on a database and need application-consistent backups, whether the system is a module of the EHR or a separate product. If it is a separate hosted product, it gets the same written-answers treatment as the hosted EHR: coverage, restore granularity, SLA, exit.
Timing is the quiet risk here. The most valuable data in the billing system is the newest, this week’s unsubmitted claims. A nightly backup means a worst case of losing a day of billing work. That may be acceptable, but it should be a decision someone made on purpose, not a default nobody examined.
What about scanned documents and old charts?
Almost every practice has a scanned-document layer: the digitized paper charts from an EHR conversion, insurance cards, consent forms, faxed referrals, lab printouts. And almost every practice is fuzzy on where all of it lives. Some is attached inside the EHR, some sits on a file share in folders named by year, some is on the scanner workstation’s local drive, and some is in a staff member’s OneDrive because that was the fastest way to get it off the scanner.
Two rules. First, inventory before architecture: the backup has to follow where scans actually live, not where policy says they should. The consent form that only exists in a “Scans2019” folder on the front desk PC is patient record material with zero copies. Second, once inventoried, scanned documents behave like imaging: written once, rarely touched, retained for years. Consolidate them onto protected storage and let an archive tier hold them, rather than leaving fragments scattered across machines that were never in the backup at all.
What standards should the whole design meet?
Four, across every data type above.
Three copies, two media, one off site. The 3-2-1 rule is the floor: three copies of the data, on two different kinds of storage, at least one away from the office. A backup drive sitting next to the server shares the server’s fires, floods, and thefts. Houston practices can add hurricanes to that list.
One copy immutable, and everything encrypted. Ransomware crews target healthcare because downtime pressure pays, and they find and destroy backups before they detonate. An immutable copy cannot be altered or deleted for a set period, even with administrator credentials, which is precisely the scenario a stolen admin account creates. And because every one of these copies is PHI, backups must be encrypted in transit and at rest, with access controlled and a business associate agreement in place with any vendor whose platform touches them. Our guide to ransomware protection for medical practices covers the rest of that defense.
Restores tested on a schedule. A backup you haven’t restored from is a hope, not a plan. Quarterly at minimum, and test outcomes, not job logs: bring the EHR up from backup and open a chart, pull an imaging study from the archive and confirm it opens against the right patient, restore a mailbox item, run a report from a restored billing database. Tested backups are also part of what HIPAA’s contingency planning expectations point toward, and they are a question cyber insurers now ask directly. Our HIPAA IT requirements guide puts that in its larger context.
Retention set by your records policy, then actually reached. Medical record retention varies by state and by record type, and pediatric records often extend the clock. One conflation to avoid: HIPAA’s six-year retention requirement applies to HIPAA documentation, your policies, risk assessments, and compliance records, not to the medical records themselves. State law and your own records policy govern those. The IT job is blunt either way: set retention from your records policy and state requirements, then make the backup and archive actually reach that far. The common failure is a policy measured in years resting on a platform that keeps 90 days.
Who should own all of this?
Someone, by name. Backup is the one system in a practice that fails silently, because nobody interacts with it until the day it must work, and by then the verification that was skipped is the recovery that doesn’t exist.
Braintek has been carrying that ownership for Texas businesses since 2002, with local teams in Houston and Dallas-Fort Worth, and we sign business associate agreements with our healthcare clients. Our backup and disaster recovery service starts by inventorying what is actually protected today versus what everyone assumes is, then closes the gaps: application-aware coverage for the EHR and billing systems, an archive tier for imaging and scanned documents, an independent Microsoft 365 backup, immutable encrypted copies, retention matched to your records policy, and restore tests on a schedule with results you can hand to an insurer or an auditor. Fully managed support fits practices of roughly 10 to 50 people; larger organizations typically pair us with internal IT in a co-managed arrangement, and our guide to managed IT costs for medical practices covers what that runs.
To see the picture for your own practice, start with our IT services for healthcare, the medical practices page if you run an independent office, or book a discovery call. The best time to find out what your backup can restore is any week you don’t need it to.