Epic-Related Data Is Inaccessible After a Client-Controlled Storage Failure
An Epic-related clinical, reporting, interface, archive, document, or operational workflow is unavailable after a failure in storage the organization controls. The first recovery decision is not how to repair “Epic.” It is which specific client-controlled source failed, what data is unavailable, and how that source fits into the organization’s Epic and continuity architecture.
Do not improvise rebuilds, repairs, restores, or storage changes outside the organization’s approved incident process. Preserve the affected RAID, SAN, NAS, VM, server, database, repository, backup, export, interface, and configuration states, and coordinate source access with the responsible Epic, infrastructure, database, security, and continuity teams.
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 Epic application outage may be vendor, network, identity, application, database, interface, or infrastructure related and does not by itself establish recoverable storage damage. ADR’s role begins when a defined client-controlled source has failed and required data cannot be recovered through the organization’s normal resilience and restore path.
A client-controlled source may support production, reporting, interfaces, extracts, documents, images, archives, backups, disaster recovery, or another dependent workflow. Its platform and relationships must be documented from the actual environment; they cannot be inferred safely from the Epic name.
What to record
- Epic-related workflow affected and the team or vendor responsible for the primary system
- Whether the environment is vendor hosted, organization hosted, or hybrid and which source the organization controls
- Patients, dates, encounters, reports, documents, messages, extracts, images, interfaces, or other data required first
- The exact failed server, VM, RAID, SAN, NAS, volume, datastore, database, repository, archive, backup, or export
- Platform, version, topology, paths, sizes, timestamps, and dependencies for every available source and alternate copy
- Controller, member, volume, datastore, filesystem, database, application, and interface errors
- Every failover, rebuild, restore, repair, snapshot, replication, storage, or configuration action already attempted
- Incident authority, vendor coordination, custody, confidentiality, destination, and change-control requirements
What not to do
- Treat a broad Epic outage as proof of a specific storage or database failure
- Act on vendor-hosted infrastructure the organization does not control
- Change client-controlled storage outside the approved incident and change-control process
- Run rebuild, filesystem, database, or application repair on the only source
- Restore over an affected source before preserving its current state
- Discard extracts, archives, interfaces, reports, backups, or dependent repositories as secondary
- Move protected data before authorization, custody, and destination requirements are defined
How ADR evaluates it
ADR works from the defined client-controlled source and the organization’s authorized recovery objective. The source is protected before RAID, filesystem, virtualization, database, repository, and application dependencies are separated and evaluated.
Candidate results are tested against the authorized records, dates, relationships, messages, reports, documents, extracts, or downstream functions required. Findings and recovered output can be handed back into the organization’s approved Epic and infrastructure recovery process rather than bypassing it.
ADR can begin with the affected component, topology, storage evidence, data files or repositories, backups and replicas, exact errors, actions already taken, responsible teams, custody requirements, and the data required first. The failed client-controlled server or array does not have to be forced online before evaluation begins.
What happens next
Recoverability depends on the identified client-controlled source, its preserved and readable state, available replicas, backups or exports, prior intervention, and the integrity of the required data and its dependencies. It cannot be predicted from the Epic application symptom alone.