Healthcare: Epic + SharePoint + Power BI Integration

Why This Integration Matters

Epic is the clinical backbone for over 250 million patient records in the US. But Epic was not designed as an analytics platform or a document management system. Health systems need:

• Operational dashboards that pull live data from Epic — ED throughput, bed management, OR utilization, staffing metrics — and present them in Power BI for leadership and clinical teams.
• Clinical analytics built on Caboodle/Clarity data — quality measures (HEDIS, CMS Stars), readmission risk models, population health metrics — in a governed analytics environment.
• Document management for clinical and operational documents — policies, procedures, care plans, credentialing files, training materials — in SharePoint with proper HIPAA controls.
• Unified governance across the Epic-to-Microsoft data pipeline — data lineage, access controls, audit trails, and retention policies that satisfy HIPAA and Joint Commission requirements.

Reference Architecture: Epic to Microsoft Data Flow

The integration architecture has three primary data flow patterns, each serving different use cases:

Pattern 1: Caboodle/Clarity to Azure to Power BI (Historical Analytics)

This is the workhorse pattern for clinical and financial analytics. The data flow:

1. Extract: Scheduled extract from Epic Caboodle (data warehouse) or Clarity (reporting database) via SSIS, Azure Data Factory, or Epic's Cognitive Computing data export tools.
2. Land: Raw data lands in Azure Data Lake Storage Gen2 (bronze layer) with encryption at rest using customer-managed keys.
3. Transform: Azure Synapse Analytics or Microsoft Fabric lakehouse transforms raw data into analytical models — star schemas for clinical quality, financial, and operational domains.
4. Serve: Power BI Premium connects to the silver/gold layer via DirectQuery or Import mode, depending on data volume and refresh requirements.
5. Consume: Dashboards published to Power BI workspaces with row-level security (RLS) enforcing department-level and facility-level access controls.

Refresh cadence: Nightly for most clinical analytics. Weekly for financial reporting. The extract should complete by 4 AM so dashboards are current before 6 AM morning huddles.

Pattern 2: Epic FHIR APIs to Azure to Power BI (Near-Real-Time Operations)

For operational dashboards that need data fresher than nightly extracts:

1. Poll: Azure Functions poll Epic FHIR R4 APIs on a 5-15 minute interval for specific resource types — Patient, Encounter, Observation, Location (bed status), Schedule.
2. Ingest: FHIR resources are parsed, flattened, and written to Azure SQL Database (not Synapse — lower latency for real-time queries).
3. Serve: Power BI connects via DirectQuery to Azure SQL for live operational metrics.
4. Display: Auto-refresh dashboards on wall-mounted displays in ED, OR, and nursing stations update every 5-15 minutes.

Key FHIR resources for operational dashboards: Encounter (census, throughput), Location (bed availability), Appointment/Schedule (clinic utilization), Observation (vital signs for clinical alerts), and DiagnosticReport (lab turnaround time).

Pattern 3: SharePoint as Clinical Document Repository

SharePoint serves as the managed document repository for content that supports clinical operations but lives outside Epic:

• Clinical policies and procedures: Version-controlled documents with approval workflows, retention policies, and access controls by department and facility.
• Credentialing and privileging files: Provider credentialing documents managed in SharePoint with integration to credentialing systems via Power Automate.
• Quality improvement documentation: Root cause analyses, corrective action plans, peer review documentation (with appropriate legal protections).
• Training and education: Clinical training materials, competency documentation, and continuing education records.
• Epic go-live and upgrade documentation: Implementation guides, testing scripts, change management materials organized by Epic module.

HIPAA Security Controls for the Integration

Every layer of this architecture handles ePHI and must be governed accordingly:

Network and Transport Security

• ExpressRoute or VPN from on-premises Epic infrastructure to Azure — no public internet traversal for PHI data flows.
• TLS 1.3 for all API communications including FHIR endpoints.
• Azure Private Endpoints for Azure SQL, Synapse, and Storage accounts — no public IP exposure.
• Network Security Groups (NSGs) restricting traffic to known source IPs.

Data Protection

• Encryption at rest using customer-managed keys (Azure Key Vault) for all storage accounts, databases, and Synapse pools.
• Column-level encryption for high-sensitivity fields (SSN, MRN, date of birth) in Azure SQL and Synapse.
• Microsoft Purview sensitivity labels on all SharePoint sites and libraries containing PHI.
• Data Loss Prevention (DLP) policies preventing PHI content from being shared outside the organization.

Access Control and Audit

• Entra ID Conditional Access with MFA enforcement for all users accessing Power BI dashboards and SharePoint PHI sites.
• Power BI Row-Level Security (RLS) enforcing department and facility access boundaries — a nurse manager sees their unit's data, not the entire hospital.
• SharePoint site-level permissions aligned with workforce role and minimum necessary requirements.
• Unified Audit Log retention set to six years minimum for all Copilot, Power BI, and SharePoint access events.
• Azure Monitor and Microsoft Sentinel for anomaly detection on data access patterns.

Power BI Dashboard Use Cases for Epic Data

The dashboards we most frequently build for health systems integrating Epic with Power BI:

Implementation Approach

EPC Group's implementation approach for Epic + SharePoint + Power BI integration follows a phased model:

• Phase 1 (Weeks 1-4): Discovery and architecture — Epic environment assessment, data dictionary review, FHIR API capabilities validation, Azure architecture design, HIPAA security requirements documentation.
• Phase 2 (Weeks 5-12): Azure infrastructure and ETL — landing zone deployment, Caboodle/Clarity ETL pipelines, FHIR API integration, data transformation logic, security controls implementation.
• Phase 3 (Weeks 9-16): Power BI development — semantic models, dashboard development, RLS configuration, refresh scheduling, user acceptance testing with clinical and operational stakeholders.
• Phase 4 (Weeks 10-18): SharePoint configuration — site architecture, sensitivity labeling, document libraries, retention policies, workflows, permissions structure.
• Phase 5 (Weeks 16-24): Training, go-live, and stabilization — role-based training, phased rollout by department, monitoring, and 90-day post-go-live support.

Frequently Asked Questions