---
# System prepended metadata

title: Epic InterSystems Iris Architecture

---

# Epic InterSystems Iris Architecture

## Introduction

InterSystems Iris is the database platform used by the Epic application. It provides a robust, scalable foundation for healthcare data management with comprehensive support for high availability, disaster recovery, and enterprise-scale deployments.

### Core Components

The InterSystems Iris architecture consists of several key components:

- **Data Server**: The access point for persistently stored data
- **Application Server**: Manages database queries and makes data requests to the data server
- **Symmetric Multiprocessor (SMP) Architecture**: Sufficient for most Epic software environments
- **Enterprise Caché Protocol (ECP)**: Enables distributed models for large deployments

### Key Advantages

The updated Iris database provides significant benefits:

- **Increased Scale**: Enables larger organizations with multiple Epic instances to consolidate into one larger instance
- **Platform Flexibility**: Licensing holiday allowing customers to move between AIX and Red Hat Enterprise Linux (RHEL) without paying for a new platform license

## Epic Environment Overview

The complete Epic ecosystem includes multiple interconnected components working together to provide comprehensive healthcare data management.

```mermaid
graph TB
    subgraph "Client Layer"
        HS[Hyperspace<br/>Client Access]
    end

    subgraph "Primary Site"
        PROD[("Production DB<br/>Read/Write")]
        APP[Application<br/>Servers]
        REPORT[("Report Mirror<br/>Read-Only")]
        CLARITY[("Clarity DB<br/>Oracle/SQL Server")]
        WEBLOB[WebBLOB Server<br/>SMB Storage]
    end

    subgraph "Secondary Site"
        DR[("DR Mirror<br/>Read-Only")]
        SUPPORT[("Support Mirror<br/>Read-Only")]
    end

    subgraph "Development"
        TEST[("Test/Dev/Staging<br/>Environments")]
    end

    subgraph "Storage Infrastructure"
        STORAGE[Storage Cluster<br/>SAN/NAS Storage]
        SNAP[Storage Replication]
    end

    HS --> APP
    APP --> PROD
    PROD -.Mirror Sync.-> REPORT
    REPORT -.Daily Extract.-> CLARITY
    PROD -.Async Mirror.-> DR
    PROD -.Mirror.-> SUPPORT
    PROD --> STORAGE
    REPORT --> STORAGE
    DR --> STORAGE
    WEBLOB --> SNAP
    TEST --> STORAGE

    classDef production fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px,color:#fff
    classDef report fill:#4dabf7,stroke:#1971c2,stroke-width:2px,color:#fff
    classDef dr fill:#ff922b,stroke:#d9480f,stroke-width:2px,color:#fff
    classDef support fill:#51cf66,stroke:#2f9e44,stroke-width:2px,color:#fff
    classDef clarity fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
    classDef weblob fill:#cc5de8,stroke:#9c36b5,stroke-width:2px,color:#fff
    classDef test fill:#e9ecef,stroke:#868e96,stroke-width:1px,color:#000
    classDef storage fill:#343a40,stroke:#212529,stroke-width:2px,color:#fff

    class PROD production
    class REPORT report
    class DR dr
    class SUPPORT support
    class CLARITY clarity
    class WEBLOB weblob
    class TEST test
    class STORAGE,SNAP storage
```

## InterSystems Iris Database Architecture

### Symmetric Multiprocessor (SMP) Architecture

For most Epic software environments, the SMP architecture in a single database server suffices to service Epic applications' database requests. In large deployments, a distributed model can be supported using InterSystems' Enterprise Caché Protocol (ECP).

```mermaid
graph LR
    subgraph "Standard SMP Architecture"
        direction LR
        APP1[Application<br/>Server]
        DATA1[Data<br/>Server]
        STOR1[(All-Flash<br/>Storage)]

        APP1 -->|Query| DATA1
        DATA1 -->|I/O| STOR1
    end

    subgraph "Distributed ECP Architecture"
        direction LR
        DATA2[Data<br/>Server]
        STOR2[(Shared<br/>Storage)]
        APP2A[Application<br/>Server A]
        APP2B[Application<br/>Server B]
        APP2C[Application<br/>Server C]

        APP2A -->|ECP| DATA2
        APP2B -->|ECP| DATA2
        APP2C -->|ECP| DATA2
        DATA2 -->|I/O| STOR2
    end

    subgraph "High Availability Cluster"
        direction LR
        PRIMARY[Primary<br/>Data Server<br/>Active]
        STANDBY[Standby<br/>Data Server<br/>Passive]
        SHARED[(Shared<br/>Storage)]

        PRIMARY -.Failover.-> STANDBY
        PRIMARY --> SHARED
        STANDBY -.-> SHARED
    end

    classDef appserver fill:#74c0fc,stroke:#1971c2,stroke-width:2px,color:#000
    classDef dataserver fill:#ff6b6b,stroke:#c92a2a,stroke-width:2px,color:#fff
    classDef storage fill:#343a40,stroke:#212529,stroke-width:2px,color:#fff
    classDef standby fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000

    class APP1,APP2A,APP2B,APP2C appserver
    class DATA1,DATA2,PRIMARY dataserver
    class STOR1,STOR2,SHARED storage
    class STANDBY standby
```

### Failover and High Availability

The use of failover-enabled clustered hardware enables a standby data server to access the same storage as the primary data server. This configuration allows the standby data server to take over processing responsibilities during a hardware failure, ensuring continuous operation.

### Replication Technologies

InterSystems provides comprehensive technologies to satisfy data replication, disaster recovery, and high-availability (HA) requirements:

- **InterSystems Replication**: Replicates an Iris database synchronously or asynchronously from a primary data server to one or more secondary data servers
- **Storage Replication**: Replicates WebBLOB storage for backup and disaster recovery purposes

## Database Server Types

In Epic software environments, a single patient-centric database is deployed with multiple mirror configurations to support different operational needs.

### Mirror Replication Flow

```mermaid
graph TB
    subgraph "Primary Site"
        PROD[("Production Database<br/>Read/Write<br/>High Performance<br/>All-Flash Storage")]
        FAILOVER[Failover Server<br/>Standby]
        REPORT[("Report Mirror<br/>Read-Only<br/>Reporting Workload")]
    end

    subgraph "Disaster Recovery Site"
        DR[("DR Mirror<br/>Read-Only → SRW<br/>Geographic Separation")]
    end

    subgraph "Optional"
        SUPPORT[("Support Mirror<br/>Read-Only → Read/Write<br/>Business Continuity")]
    end

    PROD -.Shared Storage.-> FAILOVER
    PROD -->|Epic Mirror<br/>Synchronous| REPORT
    PROD -->|Epic Mirror<br/>Asynchronous| DR
    PROD -->|Epic Mirror| SUPPORT

    FAILOVER -.Automatic<br/>Failover.-> PROD

    classDef production fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px,color:#fff
    classDef failover fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
    classDef report fill:#4dabf7,stroke:#1971c2,stroke-width:2px,color:#fff
    classDef dr fill:#ff922b,stroke:#d9480f,stroke-width:2px,color:#fff
    classDef support fill:#51cf66,stroke:#2f9e44,stroke-width:2px,color:#fff

    class PROD production
    class FAILOVER failover
    class REPORT report
    class DR dr
    class SUPPORT support
```

### Production Database Server

In Epic's hardware requirements, the physical server hosting the primary read/write Iris data server is called the production database server. Key characteristics:

- **Storage Requirements**: High performance all-flash storage for files belonging to the primary database instance
- **High Availability**: Epic supports the use of a failover database server with access to the same files
- **Replication**: Uses Epic Mirror to replicate to read-only Report, disaster recovery, and support read-only copies
- **Business Continuity**: Each type of database server can be switched to read/write mode for business continuity reasons

### Report Mirror Database Server

A reporting mirror database server provides read-only access to production data. Key characteristics:

- **Configuration**: Hosts an Iris data server configured as a backup mirror of the production Iris data server
- **Storage Capacity**: Same requirements as the production database server
- **Performance Profile**: Write performance matches production, but read workload characteristics are different and sized accordingly
- **Purpose**: Dedicated reporting queries without impacting production performance

### Support Read-Only Mirror Database Server

This database server is optional and provides additional read-only access to production data:

- **Purpose**: Provides a copy of production in read-only mode for support activities
- **Flexibility**: Can be switched to read/write mode for business continuity reasons
- **Deployment**: Not always included in standard configurations

### Disaster Recovery Mirror Database Server

To meet business continuity and disaster recovery objectives, a DR mirror database server is commonly deployed:

- **Geographic Separation**: Deployed at a site geographically separate from production and/or reporting mirror database servers
- **Configuration**: Hosts an Iris data server configured as a backup mirror of the production Iris data server
- **Business Continuity**: Can be configured to act as a mirror read/write instance (SRW) if the production site becomes unavailable
- **Storage Requirements**: Same file storage requirements as production database server, sized from a performance perspective for business continuity

### Test, Development, and Staging Environments

Healthcare organizations often deploy additional environments for testing and development:

- **Purpose**: Development, testing, and staging environments for application updates and testing
- **Storage**: Additional Iris data servers requiring storage, which can be accommodated by the same storage system
- **Requirements**: Epic has specific requirements and constraints for providing additional storage from a shared storage system

## Additional Epic Components

Beyond the Iris ODB data servers, Epic software environments include several other critical components.

### Clarity Database

- **Platform**: Oracle or Microsoft SQL Server database server
- **Purpose**: Backend for Epic's Clarity business-reporting tools
- **Data Source**: Reports on data extracted daily from the reporting Iris database

### WebBLOB Server

- **Protocol**: SMB (Server Message Block)
- **Storage**: Stores large binary objects such as images and documents
- **Replication**: Storage replication used for backup and disaster recovery

### Multipurpose Components

- **Multipurpose Database Server**: Supports various ancillary database needs
- **Multipurpose Virtual Machines**: Provide flexible compute resources for various Epic functions

### Hyperspace

- **Purpose**: Client access layer for Epic applications
- **Function**: Provides the user interface for clinicians and staff to access Epic systems

### Consolidated Storage Strategy

The storage requirements of all these multiple workloads, pools, NAS and SAN protocols can be consolidated and hosted by a single storage cluster. This consolidation enables healthcare organizations to have a single data management strategy for all Epic and non-Epic workloads.

## Storage Architecture

### File Types and I/O Patterns

Each Epic database server performs I/O on three primary types of files:

```mermaid
graph TB
    subgraph "Epic Database Server"
        SERVER[Iris Data Server]
    end

    subgraph "Storage System"
        subgraph "Database Files"
            DB1[Primary Database<br/>100% Random I/O<br/>Most Demanding]
            DB2[Mirror Databases<br/>Less Demanding<br/>Fewer Read Requests]
        end

        subgraph "Journal Files"
            JOURNAL[Transaction Logs<br/>Sequential I/O<br/>Write-Intensive]
        end

        subgraph "Application Files"
            APPFILES[Application Code<br/>Configuration<br/>Static Content]
        end
    end

    SERVER -->|Random Read/Write| DB1
    SERVER -->|Random Read| DB2
    SERVER -->|Sequential Write| JOURNAL
    SERVER -->|Read Access| APPFILES

    classDef database fill:#ff6b6b,stroke:#c92a2a,stroke-width:2px,color:#fff
    classDef mirror fill:#4dabf7,stroke:#1971c2,stroke-width:2px,color:#fff
    classDef journal fill:#51cf66,stroke:#2f9e44,stroke-width:2px,color:#fff
    classDef app fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000

    class DB1 database
    class DB2 mirror
    class JOURNAL journal
    class APPFILES app
```

### Workload Characteristics

The workload of an individual database server depends on its role in the Epic software environment:

- **Production Database Files**: Typically incur the most demanding workload, consisting of 100% random I/O requests
- **Mirror Databases**: Workload is typically less demanding with fewer read requests
- **Journal Files**: Workloads are mainly sequential, providing predictable performance patterns

### Performance Benchmarking

Epic maintains a workload model for storage performance benchmarking and customer workload analysis. For more information about the Epic workload model, benchmark results, and guidance on correctly sizing storage for Epic environments, consult Epic's documentation and sizing tools.

## High Availability and Disaster Recovery

```mermaid
graph TB
    subgraph "Primary Site"
        direction TB
        PROD_PRIMARY[("Production Database<br/>Read/Write<br/>Primary")]
        PROD_FAILOVER[("Failover Server<br/>Standby")]
        REPORT_PRIMARY[("Report Mirror<br/>Read-Only")]
        WEBLOB_PRIMARY[WebBLOB Storage<br/>Primary]
        STORAGE_PRIMARY[(Primary Storage)]

        PROD_PRIMARY -.Cluster.-> PROD_FAILOVER
        PROD_PRIMARY --> STORAGE_PRIMARY
        PROD_FAILOVER -.-> STORAGE_PRIMARY
        REPORT_PRIMARY --> STORAGE_PRIMARY
        WEBLOB_PRIMARY --> STORAGE_PRIMARY
    end

    subgraph "DR Site - Geographic Separation"
        direction TB
        DR_MIRROR[("DR Mirror<br/>Read-Only → SRW<br/>Backup")]
        WEBLOB_DR[WebBLOB Storage<br/>DR Copy]
        STORAGE_DR[(DR Storage)]

        DR_MIRROR --> STORAGE_DR
        WEBLOB_DR --> STORAGE_DR
    end

    PROD_PRIMARY ==>|Epic Mirror<br/>Async Replication| DR_MIRROR
    WEBLOB_PRIMARY ==>|Storage Replication| WEBLOB_DR
    STORAGE_PRIMARY -.Backup/DR.-> STORAGE_DR

    subgraph "Failure Scenarios"
        SCENARIO1["Hardware Failure:<br/>Automatic failover to standby<br/>within Primary Site"]
        SCENARIO2["Site Failure:<br/>Manual activation of DR site<br/>DR Mirror → SRW mode"]
    end

    classDef primary fill:#ff6b6b,stroke:#c92a2a,stroke-width:3px,color:#fff
    classDef standby fill:#ffd43b,stroke:#fab005,stroke-width:2px,color:#000
    classDef dr fill:#ff922b,stroke:#d9480f,stroke-width:3px,color:#fff
    classDef storage fill:#343a40,stroke:#212529,stroke-width:2px,color:#fff
    classDef scenario fill:#e9ecef,stroke:#868e96,stroke-width:1px,color:#000

    class PROD_PRIMARY,REPORT_PRIMARY primary
    class PROD_FAILOVER standby
    class DR_MIRROR dr
    class STORAGE_PRIMARY,STORAGE_DR storage
    class SCENARIO1,SCENARIO2 scenario
```

### Hardware Failure Protection

Failover-enabled clustered hardware provides automatic recovery:

- **Standby Server**: Accesses the same storage as the primary data server
- **Automatic Failover**: Standby server takes over processing responsibilities during hardware failure
- **Minimal Downtime**: Quick recovery maintains service continuity

### Site Failure Protection

Geographic separation and mirror replication provide disaster recovery:

- **Asynchronous Replication**: Data replicated to geographically separate DR site
- **Manual Activation**: DR mirror can be promoted to read/write mode (SRW)
- **WebBLOB Replication**: Storage replication ensures document and image availability
- **Business Continuity**: Full system recovery at DR site if primary site unavailable

## Deployment Planning and Sizing

### Hardware Configuration Guide

Epic provides each customer with a customized hardware configuration guide containing:

- **I/O Projections**: Expected input/output operations based on customer's projected workload
- **Storage Capacity Requirements**: Total storage needs for all database instances
- **Environment Coverage**: Requirements for development, testing, staging, and production environments
- **Ancillary Workloads**: Additional workloads that may be consolidated on the storage system

Customers can use this hardware configuration guide to communicate total storage requirements. The guide contains all the data needed to properly size an Epic deployment.

### Database Storage Layout Guide

During the deployment phase, Epic provides a Database Storage Layout Guide with more granular details:

- **LUN-Level Details**: Specific logical unit number configurations
- **Advanced Storage Design**: Detailed layout recommendations for optimal performance
- **General Recommendations**: Storage best practices for optimal results
- **Storage Optimization**: Use this guide to determine the best storage layout for your infrastructure

