Epic integration for archived data, the four patterns that work

The wave of health-system consolidation onto Epic over 2022–2026 left most CIOs with the same problem: thirty years of clinical, financial, and operational records sitting in retired Cerner, Meditech, Allscripts, McKesson, AHLTA, and Essentris systems, and a generation of clinicians who have learned to work entirely inside the Epic chart. Forcing clinicians out of Epic to retrieve historical records is the fastest way to kill an archival program. Forcing them to log in to a separate vendor portal kills adoption inside 90 days.

The answer is integration. The archive becomes the long-term records-of-truth tier, Epic becomes the active-workflow tier, and a small number of well-defined integration patterns connect the two without disrupting the clinician's muscle memory. InterScripts has implemented these patterns at 50+ Epic customers and pulled the four that consistently work into a public reference architecture. This page focuses on the Epic-side patterns; the broader category framing (when to archive vs. migrate, vendor landscape, federal deployment baselines) is in the Healthcare Data Archival Complete 2026 Guide.

The simplest pattern: a context-aware link from Epic Chart Review that opens the archive's search UI pre-filtered to the active patient. Epic Hyperdrive supports passing the patient identifiers (MRN, EPI, encounter CSN) through a configurable external link. The archive's URL handler resolves those identifiers, opens the search results pre-scoped to the patient, and the clinician sees historical records without re-typing any context.

This pattern is the right starting point for two reasons. First, it ships in a single Epic Userweb ticket, no App Orchard certification, no Smart on FHIR registration, no custom Hyperdrive XAML. Second, it preserves the archive UI in its native form, which is important when the archive surfaces unstructured records (PDFs, scans, transcribed dictations) that don't map cleanly to Epic's structured Chart Review views.

The premium pattern: a SMART on FHIR application (HL7 FHIR + OAuth 2.0 + OpenID Connect) registered with Epic, embedded as an activity inside Hyperdrive. The app opens inside the Epic chart context, calls the archive's FHIR R4 endpoints with the patient and encounter identifiers Epic passes through the SMART launch, and renders results in an Epic-styled interface that matches the rest of the chart.

SMART on FHIR is the pattern Epic Open and App Orchard customers prefer because it preserves the single-pane-of-glass experience clinicians demand. Implementation requires the archive to expose FHIR R4 endpoints for Patient, Encounter, Condition, MedicationStatement, AllergyIntolerance, Immunization, DocumentReference, and Observation resources, plus OAuth 2.0 with the SMART launch context scopes. BytePad ships these out of the box; for other archive vendors, expect 3–6 months of engineering to add SMART on FHIR support.

The patient-facing pattern: a MyChart tile that surfaces a patient's archived encounters, visit summaries, lab results, and imaging reports. The tile renders inside MyChart Hyperdrive Web or the MyChart mobile app, calls the archive through Epic's MyChart Patient Access FHIR APIs (21st Century Cures Act compliant), and presents historical records alongside the active record without the patient knowing the data came from a different system.

This pattern is the right answer when the 21st Century Cures Act information-blocking rules drive the requirement, patients have a right to all their records, including those from retired systems. Surfacing the archive in MyChart removes the support-ticket category of "I called the records department to ask for my chart from 2018" and converts it to self-service retrieval. The clinical-operations win is substantial: typical InterScripts customer pattern shows a 60% reduction in records-request tickets within 90 days.

The backfill pattern: BIIG (the BytePad Integration & Interoperability Gateway) extracts structured records from the archive and pushes them into Epic as an HL7 v2 or FHIR R4 bulk import. The target is the active record set every clinician sees on chart open, problem list, medication list, allergy list, immunization record, and a defined look-back window of clinical notes.

This is the pattern that lets clinicians stop thinking about the archive at all. Once the active record set is backfilled into Epic, the archive is the long-tail historical store, and Patterns 1, 2, or 3 cover the cases where a clinician needs to dig deeper. Most InterScripts Epic-cutover programs use Pattern 4 as the migration mechanism and Pattern 2 or 3 as the steady-state retrieval mechanism, the two are complementary.

The 21st Century Cures Act information-blocking rules are the regulatory backdrop for every Epic + archive integration today. The rules require that electronic health information (EHI) be accessible, exchangeable, and usable without unreasonable interference, and they apply to archived data, not just data in the active EHR. ONC's enforcement posture has continued to escalate, with provider organizations now subject to monetary penalties for information-blocking violations.

For Epic integration patterns, this translates into three concrete requirements. First, the archive must expose FHIR APIs covering the USCDI v3 data classes (Patient, Encounter, Condition, Medication, Allergy, Immunization, Observation, DocumentReference, and the others in the standard). Second, response times must be reasonable, ONC has not set a hard SLA but practical interpretation is sub-30-second for FHIR API calls and sub-2-second for clinician-interactive retrievals. Third, the archive must support patient-access workflows (Pattern 3) at no additional cost to the patient.

Epic App Orchard certification is the recognizable path for SMART on FHIR apps. App Orchard provides Epic-validated launch, identity, and FHIR access, and gives customer Epic admins a defined install path with vendor support contracts already in place. The trade-off is timeline and price: App Orchard certification typically runs 6–12 months and carries fees that vary by app scope.

For customers who need archive integration faster than 12 months, a custom SMART on FHIR app, registered directly with the customer's Epic instance using the customer's own client_id, works equally well from a clinician-experience perspective. The archive vendor and customer build a direct App Build agreement; Epic supports this path through its standard FHIR API program. BytePad ships in both modes, App Orchard for the cross-customer pattern, direct App Build for customer-specific needs.

Clinician adoption depends on speed. Sub-2-second median retrieval from the archive UI is the threshold; above 5 seconds, clinicians stop using the integration and start opening parallel windows or filing support tickets. BytePad targets sub-1.5-second median for SMART on FHIR retrievals and sub-2-second for Chart Review external-reference launches.

Security baseline for Epic integration is HITRUST r2, SOC 2 Type II, ISO 27001:2022, and HIPAA Privacy + Security Rule alignment. OAuth 2.0 + OpenID Connect for SMART on FHIR launches; TLS 1.2+ for every API call; AES-256 encryption at rest. Federal Epic deployments (DHA MHS GENESIS, VA EHRM) add NIST SP 800-53 Rev. 5, CMMC L2, DoD RMF, and Zero Trust (CISA Zero Trust Maturity Model) controls on top.

Audit logging: every archive retrieval, Chart Review link, SMART on FHIR call, MyChart tile load, BIIG sync, is logged with patient identifier, encounter context, requesting user, retrieved resource, and timestamp. The audit log is immutable and supports OCR audit response, HIPAA reporting, and litigation hold extraction.