The EMR Is Down After Server Failure, and Required Patient Records Are Inaccessible
The organization cannot reliably reach current charts, encounters, orders, results, appointments, treatment information, billing data, documents, or other required records after a server, VM, database, RAID, or storage failure. The immediate task is to identify the hosting and failure boundary, preserve every client-controlled source, and determine which records and relationships must be recovered first.
Stop rebuilds, forced-online actions, database or filesystem repair, restores to the affected system, application reinstallation, migration, and repeated restarts. Preserve every client-controlled server, VM, volume, database and log, repository, interface, attachment store, export, backup, snapshot, original storage member, and copy already created.
Tell an ADR technician what the system reports and what has already been attempted. The failed system does not have to be brought online first.
What this condition means
An EMR login, network, service, identity, interface, or vendor-hosted outage may remain an application-support incident. It becomes an ADR recovery case when supported continuity or vendor steps have not restored the required data and a defined organization-controlled source is unavailable, damaged, incomplete, rejected, or untrustworthy.
EMR products do not share one database engine, hosting model, or repository layout. Required records may span databases, documents, images, interfaces, archives, exports, and supporting applications. The product, version, deployment, current vendor, exact failed source, and data relationships must be established before database or storage work begins.
What to record
- EMR product, version, modules affected, current support vendor, hosting model, locations, and last normal access
- Vendor or application-support findings and whether the incident has been isolated to hosted service or an organization-controlled source
- Patients, date ranges, encounters, charts, notes, orders, results, medications, appointments, claims, payments, documents, images, reports, or other data required first
- Every client-controlled server, VM, volume, database and log, repository, interface, archive, attachment store, export, backup, snapshot, and migrated copy
- Server and storage topology, controller, RAID level, member identities, replacements, current state, paths, sizes, and timestamps
- Exact application, database, operating-system, virtualization, controller, RAID, filesystem, interface, and storage errors
- Every failover, restart, rebuild, repair, attach, log change, restore, reinstall, upgrade, migration, controller change, or write already attempted
- Authorized access, custody, confidentiality, destination, and onsite requirements
What not to do
- Assume the EMR uses SQL Server or one standard repository layout
- Treat a vendor-hosted service incident as a local database-recovery case
- Run repair, rebuild, or filesystem operations on the only client-controlled source
- Restore an older database or backup over the affected source
- Reinstall, upgrade, or migrate the EMR before protecting its data
- Discard documents, images, interfaces, archives, exports, or supporting repositories because the main database appears to open
- Write recovered or repaired output back to the failed storage
How ADR evaluates it
ADR first establishes the product, hosting and custody boundary, responsible vendor, affected workflows, failed component, and required information. Vendor-controlled sources remain a vendor matter; ADR protects and evaluates only identified client-controlled sources for which access is authorized.
For a client-controlled failure, ADR separates RAID, filesystem, VM, database, repository, interface, archive, and application conditions before repair. Candidate results are evaluated against the authorized patients, dates, records, relationships, reports, and operational objectives—not merely whether the EMR or a database opens.
ADR can begin with the EMR product and hosting model, vendor findings, protected server or storage topology, databases and logs, repositories, interfaces, exports, backups, exact errors, prior actions, custody requirements, and the records required first. A failed client-controlled server, VM, volume, or array does not have to be returned online before its sources are protected and evaluated.
What happens next
An EMR that will not start after server failure does not establish that its records are lost. The practical result depends on the identified failed source and ownership boundary, preserved storage and data states, available vendor-supported copies and exports, linked repositories, prior intervention, and whether the required records and relationships remain internally consistent.