Fabric Deployment Patterns in the NHS: A Case Study

gowheya
Sep 25, 2025
2 min read

Updated: Oct 1, 2025

A multi-tenant Fabric deployment pattern . Source: Microsoft Learn

As NHS trusts and ICSs adopt Microsoft Fabric, one of the first questions is: how should we deploy Fabric to balance governance, cost control, and performance for clinical and operational analytics?

Fabric offers flexibility, but in a complex healthcare setting — with multiple directorates, regulatory requirements, and strict SLAs for patient-facing services — deployment patterns must be carefully chosen.

Deployment Patterns in an NHS Context

1. Monolithic Deployment

Use Case in NHS: Rarely suitable beyond initial pilots. A single workspace and capacity might be used by a small BI team in a community trust trialling Fabric, but it quickly breaks down as clinical and operational demands grow.

2. Multiple Workspaces on a Single Capacity

Use Case in NHS: Effective for smaller trusts or groups piloting Fabric. Finance, Operations, and Clinical teams can each have their own workspace but share one capacity, keeping costs predictable.
Limitation: ETL-heavy workloads (e.g., community data feeds) may affect dashboard responsiveness in another workspace.

3. Multiple Workspaces on Separate Capacities

Use Case in NHS: Recommended for larger acute trusts or partnerships where SLA-sensitive workloads (A&E dashboards, OPEL status) must be isolated from R&D or data engineering jobs.
Benefit: Clearer chargeback to directorates; Production dashboards can have guaranteed performance while R&D teams experiment elsewhere.

4. Multiple Tenants

Use Case in NHS: Typically only needed for cross-ICS deployments where trusts are legally separate or for national bodies (NHS England, NHSBSA). Helps enforce data sovereignty and billing isolation.
Limitation: Collaboration overhead between tenants.

Proposed NHS Capacity Map (Example)

Let’s assume the following workload mix for a large NHS acute + community trust:

Production dashboards: ~150 active dashboards (A&E, RTT, Cancer Waits, Bed Occupancy, Finance).
ETL jobs: 200+ daily pipelines (covering SUS+, ECDS, Community datasets, HR feeds).
Analysts: ~80 users (20 data engineers, 40 analysts, 20 reporting users).
SLAs:
- Critical dashboards (A&E, Bed Management, OPEL status): near real-time (<15 min latency).
- National returns (SUS, MHSDS, CSDS): daily accuracy and timeliness.
- Sandbox/R&D: no SLA, exploratory.

Capacity Allocation Proposal

Capacity	Size (F-SKU)	Assigned Workspaces	Purpose
Production Analytics	F64	Acute Ops, Community Ops, Finance, Executive Dashboards	Hosts SLA-critical dashboards and national returns. Guaranteed performance and resilience.
Data Engineering & ETL	F32	ETL Pipelines, Staging, Data Quality	Heavy ingestion and transformation pipelines run here to avoid contention with dashboards.
Sandbox / R&D	F8	R&D, Innovation, Training	Low-cost capacity for testing new models, training analysts, and prototyping.
Development / UAT	F16	Dev, UAT	Used for pre-production testing of dashboards and dataflows before promotion to Production.

Rationale:

Separation of ETL and Production ensures dashboards are not slowed down by heavy data movement.
Sandbox provides a safe space for analysts to innovate without risking performance.
UAT enforces governance and controlled promotion into Production.
Capacity SKUs can be right-sized after 30–60 days of telemetry monitoring in Fabric.

NHS Benefits from This Model

Performance Isolation: A&E dashboards always perform, even during overnight ETL.
Cost Transparency: Each directorate (Ops, Finance, R&D) mapped to capacity for budget accountability.
Governance: Controlled promotion from Dev → UAT → Prod.
Scalability: Additional F-SKUs can be added as ICS collaboration expands.