Microsoft Fabric for Healthcare: HIPAA Reference Architecture (2026)

Healthcare organizations moving analytics to Microsoft Fabric face a specific set of constraints that generic Fabric guides ignore: PHI must be encrypted in transit and at rest, audit logs must be retained for six years, access to PHI must be scoped to minimum-necessary users, and every service touching PHI must be covered by Microsoft's HIPAA Business Associate Agreement. This is the reference architecture we deploy in HIPAA-scoped Fabric engagements. It covers ingestion from EHR systems, PHI handling at each medallion layer, security controls, compliance mapping, and the exact list of Fabric services covered by the Microsoft BAA today.

Architecture at a Glance

The reference architecture has five layers running left-to-right across Fabric:

1. Source systems: Epic, Cerner, Meditech, athenahealth, and non-clinical systems (billing, claims, patient portal analytics, medical device telemetry).
2. Ingest layer: Fabric Data Factory pipelines with private endpoints, or OneLake shortcuts to existing ADLS Gen2 for organizations that already have a data lake.
3. Medallion: Bronze (raw source-fidelity), Silver (cleaned and de-identified where possible), Gold (dimensional models for reporting).
4. Semantic layer: Direct Lake+ semantic models with row-level security by care team, department, or facility.
5. Consumption: Power BI reports for clinical operations, embedded analytics in patient portals, and Copilot for analytics-native workflows.

Every layer has specific HIPAA-relevant controls that this guide walks through.

Microsoft BAA Coverage

The Microsoft Business Associate Agreement covers most Fabric services, but the specific list matters. As of 2026 GA, the BAA covers:

• Microsoft Fabric (all workloads at F-SKU capacity)
• Power BI Pro, Premium Per User, and Fabric-embedded Power BI
• OneLake storage
• Fabric Data Factory
• Fabric Lakehouse and Warehouse
• Fabric SQL Database
• Real-Time Intelligence (Eventstream, KQL Database, Data Activator)
• Fabric Notebooks
• OneLake Catalog and Purview integration

Not covered under the BAA and must NOT touch PHI: - Fabric Copilot free-tier (individual Microsoft accounts) - Some third-party marketplace items — evaluate each - Any service explicitly labeled preview or beta without HIPAA attestation

Before touching PHI in Fabric, confirm your Microsoft tenant has an executed BAA and that the services you plan to use are in-scope. This is a non-negotiable prerequisite.

Layer 1: Source Systems

Healthcare data sources fall into three categories with different ingest patterns:

EHR systems (Epic, Cerner, Meditech, athenahealth): ingest via FHIR APIs where possible, HL7 v2 message feeds where FHIR isn't available, and direct database access as a last resort. FHIR is preferred because it exposes structured, standardized data. Use Azure Health Data Services + Fabric shortcuts for the cleanest pattern.

Claims and revenue cycle data: typically already batch-fed to a data warehouse. OneLake shortcut into that warehouse is fastest, though a Fabric Data Factory pipeline is sometimes cleaner if the source warehouse is being retired.

Medical device telemetry: ingest via Fabric Eventstream from Azure IoT Hub. Structured metadata routes to KQL Database for time-series analysis; raw waveforms may need to stay in specialized storage due to volume.

Layer 2: Ingest Controls

Every ingest pipeline needs the following controls before landing PHI in Fabric:

• Private endpoints on the ingest source (Azure SQL, ADLS, Event Hubs). PHI must never traverse the public internet.
• Managed identity or workload identity for auth. No SQL passwords, no service account passwords stored in pipelines.
• Encryption in transit confirmed (TLS 1.2+).
• Encryption at rest confirmed (source system has TDE or equivalent).
• Ingest audit log enabled — every pipeline run, every batch, logged to Log Analytics with 6-year retention.
• Data lineage captured via OneLake Catalog + Purview so downstream PHI can be traced back to the source system for breach investigations.

Layer 3: Medallion — PHI Handling by Layer

Bronze (raw PHI): stored in a dedicated Bronze Lakehouse with sensitivity label "PHI - Restricted." Access restricted to a small data engineering team via Entra ID group. Retention policy: match source system retention (typically 7-10 years for clinical data). Column-level security not required at this layer because access is already restricted.

Silver (cleaned and de-identified where feasible): the critical layer for PHI handling. Two patterns:

• De-identified Silver. Where possible, Silver strips or hashes direct identifiers (name, MRN, SSN, address, phone, email) so downstream Gold and semantic models can operate on de-identified data. Not all use cases can be de-identified — a clinical operations dashboard needs to identify the specific patient. Where de-identification is possible, do it.
• PHI Silver. For use cases requiring identification, Silver retains PHI but adds surrogate keys and sensitivity labels. Access remains restricted.

Gold: dimensional model for reporting. Column-level security on any table containing direct identifiers. Sensitivity labels propagate from Silver.

Layer 4: Row-Level Security Patterns

Healthcare RLS falls into four common patterns:

1. By facility. A user assigned to Facility A sees only Facility A data. Simple, effective for multi-hospital systems.
2. By department or specialty. Cardiology sees cardiac patients; oncology sees oncology patients. Cross-department access requires explicit grant.
3. By care team. A user sees only patients on care teams they are a member of. Most granular; matches minimum-necessary access principle.
4. By treatment relationship. Provider sees only patients they have a documented treating relationship with. Highest bar to implement; usually reserved for external providers or referral networks.

Implement RLS in the semantic model using USERPRINCIPALNAME() and a security-mapping dimension table maintained via the identity system. Test with three or more distinct user identities before production.

Layer 5: Column-Level Security

Not all PHI columns need to be visible even to authorized users. Common patterns:

• Sensitive columns (mental health notes, HIV status, substance abuse) require additional authorization even for users with base access to the patient record.
• Use warehouse column-level security or hide columns at the semantic model level with role-based dynamic security.
• Log every access to sensitive columns for audit review.

Audit Logging

HIPAA requires 6-year retention of audit logs sufficient to reconstruct who accessed what PHI and when. In Fabric, this means:

• Fabric admin log exported to Log Analytics or a dedicated Fabric warehouse with 6-year retention.
• Power BI audit log exported similarly.
• Semantic model query audit enabled for the semantic models containing PHI.
• Copilot invocation log exported (if Copilot is enabled on PHI-scoped data).
• Purview activity log for lineage and access reviews.

Six-year retention on log storage is a non-trivial cost item; budget accordingly.

Compliance Mapping to HIPAA Security Rule

Reference Deployment Checklist

• [ ] Microsoft BAA is executed for the tenant.
• [ ] Fabric capacity is provisioned in a region that meets your data residency requirements.
• [ ] All ingest pipelines use private endpoints and managed identity.
• [ ] Bronze Lakehouses have sensitivity label "PHI - Restricted."
• [ ] Silver applies de-identification where feasible; sensitivity labels flow through.
• [ ] Gold and semantic models have RLS matching the appropriate access pattern.
• [ ] Column-level security on sensitive PHI columns.
• [ ] Audit log export to Log Analytics with 6-year retention configured and tested.
• [ ] OneLake Catalog + Purview lineage confirmed capturing PHI data flows.
• [ ] Fabric admin center configured for HIPAA-required policies (no PHI export, Copilot restrictions).
• [ ] Compliance officer has reviewed and signed off on the deployment.
• [ ] Breach response runbook exists and includes Fabric-specific data pull procedures.

What Gets Regulated Industries Wrong

Common failure patterns in healthcare Fabric deployments:

1. PHI in Bronze exposed to too-broad an Entra group. The convenient "all data engineers" group ends up with PHI access. Solve: dedicated PHI-scoped groups, quarterly access reviews.
2. Copilot enabled tenant-wide before scoping. Copilot queries generate LLM interactions that fall outside the standard audit boundary. Solve: scope Copilot to non-PHI workloads first; enable on PHI workloads only after establishing Copilot-specific logging.
3. Sensitivity labels applied inconsistently. Some workspaces label PHI, others don't. Solve: automated policy that requires PHI label on every Fabric item under a PHI-scoped workspace.
4. Audit log retention set to default 90 days. HIPAA requires 6 years. Solve: explicit Log Analytics workspace with 6-year retention SKU.
5. RLS not tested against real clinical roles. Nurse practitioners get admin-level access because RLS was tested only with the developer's account. Solve: three-role UAT with real user identities.

Related Guides

• Fabric Data Agent API: Public Preview Guide
• Microsoft Fabric Consulting: 90-Day Activation Runbook
• OneLake Catalog GA: Enterprise Governance Guide
• Microsoft Fabric Consulting Services

Ready to design a HIPAA-compliant Fabric architecture for your healthcare organization? Book a 30-minute compliance review call and we will map this reference against your specific EHR footprint and compliance state.