2026-06-18

Cloud Dental Software Down? What to Do When You Can't Access Patient Records

A dental software downtime plan for cloud, internet, desktop and power failures: triage, paper continuity, patient safety, reconciliation, recovery tests and prevention.

Your internet goes out. Or the cloud dental provider has an outage. Or their server is under maintenance. Suddenly, your front desk can't check patients in. The dentist can't pull up records. Billing stops. Appointments can't be booked.

The clinic may not immediately know whether the cause is its internet connection, local network, workstation, identity provider, vendor service, power, or a security incident. The first objective is safe continuity, followed by controlled diagnosis and reconciliation.

What to do during an outage

Immediate steps:

Grab paper — appointment list, patient intake forms, blank treatment notes
Continue treating patients using paper records
Use only approved payment and receipt procedures that remain available
Write down everything: treatments, payments, appointment changes

After the outage:

Enter all paper records into the system — this takes hours
Reconcile payments
Verify no appointments were double-booked during the outage
Apologize to patients who waited

The desktop software difference

Desktop dental software may keep its core local workflow available when only the internet is down:

Locally stored patient records may remain accessible
Local appointments may remain visible
Visits may still be documented
Local billing records may continue
Online integrations may still stop

The trade-off is different responsibility. A local device, database, or power failure can stop desktop software, while the clinic owns backup and recovery. Architecture changes the failure modes; it does not eliminate downtime.

Prepare for the inevitable

Whether you use cloud or desktop, have a downtime plan:

Print tomorrow's appointment list before closing each day
Keep paper forms accessible
Have a non-internet payment method available
Train staff on the downtime procedure

Cloud downtime isn't an "if" — it's a "when." Being prepared turns a crisis into an inconvenience.

Direct answer: what should a dental clinic do when software is down?

Confirm patient safety first, declare the downtime procedure, identify which systems and locations are affected, preserve read-only information that remains available, use controlled temporary records, and assign one incident lead. Do not make uncoordinated changes or repeatedly enter the same transaction. When service returns, reconcile every temporary appointment, clinical note, treatment event, payment, and communication with two-person review where risk warrants it.

If the event may involve unauthorized access, ransomware, or altered data—not just unavailability—stop ordinary recovery actions and follow the clinic’s security and breach-response process.

Triage the failure without delaying care

Use a short decision table:

Check	Observation	Next action
Power and device	One workstation or entire clinic?	Move to approved spare/continuity plan
Local network	Can devices reach approved internal resources?	Contact network support
Internet	Is the clinic connection unavailable?	Use approved secondary link if configured
Vendor status	Is the hosted service reporting an incident?	Record incident reference and updates
Authentication	Is sign-in failing while service loads?	Check identity provider/account controls
Data integrity	Missing, encrypted or unexpectedly changed data?	Escalate as security/data incident

Avoid disabling firewalls, endpoint protection, or access controls just to “see if it works.” Preserve times, error messages, affected users, actions taken, and support references.

Define the downtime authority

Every staff member should know who can declare downtime, postpone non-urgent work, contact the vendor, approve a secondary connection, access printed continuity information, and authorize recovery. Maintain current contact details outside the unavailable system.

Assign roles:

Incident lead: coordinates decisions and status.
Clinical lead: decides what care can continue safely.
Documentation lead: controls temporary record identifiers and reconciliation.
Technical contact: diagnoses within authorization and works with support.
Communications lead: gives staff and patients consistent updates.

In a small clinic one person may hold several roles, but the responsibilities should still be explicit.

Prepare minimum continuity information

The clinic may need an approved, securely stored view of near-term appointments and essential alerts. The exact content, update frequency, encryption, access, retention, and disposal must comply with local policy and law. Printing an unlimited patient list every day can create a larger privacy risk than the outage it addresses.

The continuity set might include:

Item	Purpose	Control
Near-term schedule	Identify expected patients	Date-limited, secured and destroyed properly
Contact/escalation list	Reach authorized support	Reviewed regularly
Blank downtime forms	Capture clinical and admin events	Unique sequence/identifier
Payment log	Prevent loss or duplication	Restricted and reconciled
Recovery runbook	Consistent technical steps	Versioned and accessible
Safety guidance	Decide whether care can proceed	Approved by clinical leadership

Do not depend on the unavailable application to open the downtime plan.

Use controlled temporary records

Each paper or offline record needs patient identity, date/time, author, location, reason for downtime, and a unique temporary identifier. Separate clinical notes, appointment changes, prescriptions/orders where applicable, and financial transactions according to policy.

Never use sticky notes or personal messaging accounts as the record. Keep forms physically controlled, legible, signed/attributed, and collected by the documentation lead. If identity or necessary history cannot be verified, the clinical lead should decide whether to defer treatment.

What should be documented during a visit?

Document the same clinically required facts that would be recorded online, within the limitations and approved process. Note that the entry was created during downtime and preserve its relationship to later system entry. Do not backdate the electronic transcription as if it were entered live.

Set recovery objectives

Two practical measures guide design:

Recovery time objective (RTO): how long an essential workflow can remain unavailable.
Recovery point objective (RPO): how much recently entered data the clinic can tolerate reconstructing.

Workflow	Example question
Today’s schedule	How long can check-in operate without the live queue?
Clinical history	Which visits cannot proceed without record access?
Visit documentation	How much temporary documentation can be reconciled safely?
Billing/payment	Can posting wait, and how are funds controlled?
Images	Can acquisition continue without misidentification?

Set objectives based on patient safety, operational capacity, and applicable requirements. Then test whether vendor commitments, internet redundancy, local architecture, backups, and staffing can meet them.

Reconcile carefully after restoration

Service availability does not mean reconciliation is complete. Freeze uncontrolled duplicate entry and build a numbered queue from every downtime artifact.

Confirm the application is stable and the correct data version is open.
Record the restoration time and any known missing interval.
Match each temporary record to the correct patient using approved identifiers.
Enter/transcribe with the actual author, event time, and downtime context.
Resolve appointment changes before accepting new bookings.
Reconcile charges, payments, receipts, refunds and terminal settlements.
Import or link images only after patient/site verification.
Have an authorized second reviewer check high-risk records.
Mark each temporary artifact reconciled without destroying it prematurely.
Dispose or retain originals according to record policy.

Produce counts: forms issued, returned, entered, reviewed, unresolved, and securely disposed/retained. Missing forms are incidents, not paperwork inconveniences.

Compare cloud and local continuity honestly

Failure	Vendor-hosted service	Local desktop/server
Clinic internet outage	Often loses live access	Local core may continue
Vendor service outage	Often unavailable	Usually unaffected
Local workstation failure	Another device may connect	Single-device workflow may stop
Local server failure	Hosted service unaffected	Multi-user local workflow may stop
Power/building loss	Clinic access stops	Clinic access stops
Credential/identity failure	Sign-in may stop	Local sign-in may or may not work
Ransomware	Local endpoints still at risk	Primary local data may be at risk

Choose controls for the failures the clinic cannot tolerate. The offline buying guide explains how to test a local alternative.

Test backups and vendor exports

For local systems, restore a recent backup on separate supported hardware and verify patients, appointments, notes, charts, images, balances, and configuration. For hosted systems, understand backup, retention, recovery commitments, data export, and what the clinic can access during a prolonged provider incident.

An export is not always an operational fallback. A large archive may require specialized software and may not represent current transactions. Treat it as portability/recovery evidence, not a substitute for a rehearsed continuity process.

Use the dental clinic backup guide for restore validation.

Run a downtime exercise

At least periodically and after material system changes, simulate an authorized outage using synthetic data or a controlled environment. Do not disrupt live care without approval.

Test:

Staff recognize the outage and contact the incident lead.
Required forms and continuity information are accessible.
Patient identity is preserved across handoffs.
Clinical and financial events receive unique identifiers.
Status updates reach all affected rooms.
Restoration is validated before normal entry resumes.
Every temporary item is reconciled exactly once.
The exercise produces corrective actions with owners and dates.

Measure declaration time, time to safe workflow, missing information, duplicate entries, reconciliation duration, and unresolved issues.

Dental software downtime questions

Should the clinic keep printed schedules?

Only through an approved, privacy-conscious continuity process. Limit the date range and fields, secure access, refresh appropriately, and destroy/retain according to policy. Consider other encrypted offline methods where permitted.

Can staff use personal phones or hotspots?

Only if clinic security policy and technical design explicitly approve them. Personal devices and unreviewed networks can expose sensitive information or bypass controls.

Should treatment continue without the electronic record?

The authorized clinical lead must decide based on patient needs, available verified information, procedure risk, and applicable requirements. Some care may be deferred when safe treatment cannot be established.

What if the restored system is missing recent records?

Stop ordinary reconciliation, define the missing interval, preserve all temporary and backup evidence, involve authorized technical/clinical leadership, and reconstruct through a controlled reviewed process.

Is offline dental software the complete solution?

No. It addresses some internet/provider failures but not power, device, database, malware, fire, theft, or human error. Keep a downtime procedure for every architecture.

When is the incident actually closed?

After service stability is confirmed, all temporary records are accounted for and reviewed, financial totals reconcile, security/privacy questions are resolved, affected parties receive required communication, and corrective actions have owners.

Final continuity checklist

A resilient clinic knows its essential workflows, outage authority, continuity data, temporary record method, recovery objectives, vendor contacts, backup/export limits, and reconciliation sequence. The goal is not “zero downtime”; it is safe care, controlled records, and provable recovery when any dependency fails.

Maintain an incident log that records start and restoration times, affected functions, patient-safety decisions, temporary artifacts, vendor/support references, reconciliation counts, possible data or privacy impact, and corrective actions. Review trends across small interruptions as well as major outages.

Close the loop by updating training, contact details, forms, backup procedures, and architecture diagrams. A downtime plan that does not change after an exercise or real failure is probably not using the evidence it collected.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: