The moment the EHR comes back online after a downtime event, most clinical and administrative staff experience a wave of relief. The system is back. The crisis is over. In reality, the work of managing the downtime event is only partially complete. The documentation, registrations, forms, and clinical data collected during the outage period now need to be reconciled into the restored EHR, and how well that reconciliation is managed has direct consequences for billing accuracy, patient record integrity, and regulatory compliance.
For organizations that relied on paper during the outage, the reconciliation process can take days and frequently results in incomplete or inaccurate records. For organizations using dbtech’s Downtime Solution, the reconciliation process is structured, electronic, and significantly faster. This guide walks through the reconciliation process step by step, covering both what needs to happen and how dbtech supports each phase.
Before the EHR Comes Back Online: Setting Up for a Clean Recovery
The quality of post-outage reconciliation is determined largely by what happened during the outage. Organizations that maintain structured electronic documentation during downtime events start the reconciliation process in a far better position than those working from paper. Before the EHR is restored, downtime teams should take the following steps:
- Confirm that all patient registrations completed during the outage have been entered into the downtime system with complete demographic information and correctly assigned downtime encounter numbers
- Verify that all eForms completed during the outage are saved and accounted for, including consent forms, nursing assessments, and any other clinical documentation captured electronically
- Ensure that all documents scanned during the outage, including patient identification, insurance cards, and signed paper documents, are attached to the correct patient record in the downtime system
- Compile a log of all downtime encounter numbers issued during the outage so that the reconciliation team has a complete accounting of every patient interaction that needs to be verified
- Brief department leads on what the reconciliation process will require from their teams so that staff are not surprised by the workload when the EHR comes back online
Step 1: Confirm EHR Restoration and System Stability
The first step after the EHR is restored is confirming that the system is stable before beginning data migration. Returning data to an EHR that is not fully restored or that may experience a secondary outage creates additional reconciliation risk. IT should confirm:
- The EHR is fully operational and all modules are functional
- The HL7 integration between dbtech and the EHR has been re-established and is feeding data correctly
- All downstream systems, including pharmacy, lab, and radiology interfaces, are reconnected and operational
- There is no ongoing threat, such as a cybersecurity incident, that could cause a secondary outage during the reconciliation window
This confirmation step is particularly important when the outage was caused by a cybersecurity event rather than a routine system failure. Returning data to a system that has not been fully cleared of a threat introduces data integrity risk. Your IT security team should sign off on system stability before reconciliation begins in any scenario involving a potential security incident.
Step 2: Export Downtime Data from dbtech
With the EHR confirmed as stable, the next step is exporting the data collected during the downtime period from dbtech’s system. The bi-directional HL7 interface that fed patient data into dbtech before and during the outage supports the structured export of downtime-collected data back into the EHR. This export process covers:
- Patient registrations completed during the downtime period, including demographic information and downtime encounter numbers that link to the restored EHR record
- Electronic form completions, including consent forms, nursing assessments, and any clinical documentation captured through dbtech’s eForms during the outage
- Scanned documents attached to patient records in dbtech, which are exported and attached to the corresponding EHR record
- Any additional structured data fields captured in dbtech that correspond to EHR data entry requirements
The export is organized by patient and encounter, which makes it straightforward for reconciliation staff to work through systematically rather than managing an unorganized collection of records. The electronic format eliminates the transcription step that paper-based reconciliation requires, which is one of the primary reasons dbtech users complete reconciliation in hours rather than days.
Step 3: Reconcile Downtime Registrations with the Restored EHR
New patient registrations completed during the downtime period require specific attention because they were created using downtime encounter numbers rather than EHR-generated numbers. The reconciliation process for registrations involves:
- Matching each downtime registration to the corresponding EHR record using the patient’s MRN, date of birth, and demographic information
- Confirming that the downtime encounter number has been correctly linked to the EHR encounter number in the system
- Verifying that insurance information captured during downtime has been transferred to the EHR record and is complete for billing purposes
- Flagging any duplicate registrations where a patient may have been registered both in the downtime system and by another method during the outage
Registration reconciliation should be led by the patient access or health information management team, with IT support for any technical matching issues that arise. Most organizations using dbtech complete registration reconciliation for a typical outage within two to four hours depending on volume.
Step 4: Reconcile Clinical Documentation
Clinical documentation captured during the outage, including nursing assessments, medication administration records, and physician notes, needs to be verified against the restored EHR to ensure that the complete care record is intact. This step involves:
- Confirming that all eForms completed during the outage have been attached to the correct patient record in the EHR
- Reviewing the MAR for the downtime period to confirm that medications documented during downtime are accurately reflected in the restored medication record
- Verifying that any verbal orders communicated during the outage have been entered into the EHR by the ordering physician
- Confirming that critical value notifications that may have been communicated by phone during the outage are documented in the EHR record
Clinical documentation reconciliation should be led by nursing leadership in coordination with health information management. For high-acuity units like the ICU and ED, this step may require physician review to confirm that all orders and assessments from the downtime period are accurately reflected in the restored record.
Step 5: Address Revenue Cycle and Charge Capture
The billing and revenue cycle implications of the downtime period need to be addressed as part of the reconciliation process, not as an afterthought. Specific steps include:
- Reviewing charge capture for all services provided during the downtime period to confirm that charges were captured in the downtime system and transferred to the EHR billing record
- Verifying that all downtime-period encounters have been assigned the correct payer information and that eligibility verification has been completed for any patients registered during the outage
- Flagging any encounters where documentation is incomplete in a way that could affect coding or billing, so that the clinical documentation team can address those records before they are billed
- Confirming that the MDS and PDPM classification data for long-term care patients was not affected by the outage in a way that would affect reimbursement accuracy
Step 6: Document the Outage and Close the Reconciliation Record
The final step in the reconciliation process is documenting the outage event and formally closing the reconciliation record. This documentation serves multiple purposes: it creates an evidence trail for regulatory reviews, it captures lessons learned for future preparedness planning, and it provides the data needed to evaluate the cost and impact of the event. Documentation should include:
- The start and end time of the outage and the cause if known
- A summary of which departments were affected and which downtime procedures were activated
- The number of patient registrations, eForms, and documents processed during the downtime period
- The time required to complete each step of the reconciliation process
- Any gaps or errors identified during reconciliation and how they were resolved
- Recommendations for improving the downtime or reconciliation process based on the event
This post-outage report should be reviewed by the downtime program owner and shared with the executive sponsor. Over time, these reports create a body of evidence that supports accreditation readiness, informs investment decisions about downtime preparedness, and demonstrates to leadership that the program is actively managed rather than passively maintained.
To learn more about how dbtech supports the full downtime lifecycle from preparation through recovery, explore our Downtime Solutions page or request a demo.