Microsoft Fabric and Power BI implemented for provider organizations with capacity sized against real workload, one certified semantic model rather than four hundred datasets, and the legacy reporting estate actually retired.
Fabric is a strong platform and it is easy to switch on badly. Most provider tenants we assess have a capacity that throttles during month-end close, hundreds of overlapping datasets nobody owns, self-service enabled before a governed model existed, and a legacy estate still running alongside because nothing was ever switched off. We implement the platform, the governance and the migration together, because doing the first without the other two is how organizations end up paying for two reporting environments.
The licence is the cheap part. Capacity design, semantic governance and retirement are what determine whether this works.
Provider organizations have generally already modernized their BI tool at least once. The reporting estate that followed looked different and behaved the same: hundreds of assets, several versions of the same measure, logic buried inside individual reports, and an analytics team spending most of its time answering why two numbers disagree.
Fabric changes what is technically possible. It does not, by itself, change any of that. A platform migration executed as a lift and shift moves the existing problem onto consumption based pricing, where it now also costs more when it misbehaves.Â
Dataset sprawl as the default outcome
Self-service enabled before a governed model existed produces hundreds of overlapping datasets, each with its own version of encounters and net revenue.
Capacity that throttles when it matters most
Month-end close, board pack production and large refreshes collide in the exact week leadership is watching.
Logic living inside reports
A measure written independently in several reports will differ, and those differences surface in a meeting rather than a test.
Data copied more often than it is governed
EHR to reporting database to warehouse to departmental extract to dataset. Every copy adds cost, refresh and reconciliation risk.
Nothing ever gets switched off
The new platform launches and the old one stays because someone still uses a legacy report.
Licensing decided before the consumption model
Commercial decisions are often made after the architecture and then constrain it.
Governance deferred to phase two
Tenant settings, workspace structure, sharing rules and sensitivity labels are far cheaper before hundreds of assets exist.
A platform migration is an opportunity to fix the estate. It is usually used to copy it.
If the outcome is the same measures, defined the same number of times, published to the same number of assets, on a newer platform, the programme has spent a capital budget to change a logo. The migration is the only moment when retirement is politically possible, and it should be used.
Governance applied to an empty tenant is a configuration exercise. The same governance applied after two hundred workspaces exist is a change programme with stakeholders.
Step 1
Assess the current estate
Inventory datasets, reports, workspaces, refresh schedules and actual usage.
You get an evidence-based view of what is genuinely consumed and what can go.
Step 2
Size the capacity properly
Model refresh windows, month-end concurrency and peak reporting. Size on peak, not average.
You get a capacity plan with headroom at close.
Step 3
Design the tenant and workspaces
Agree structure, naming, roles, deployment pipelines, sharing rules, sensitivity labels and tenant settings.
You get governance as configuration rather than future negotiation.
Step 4
Design OneLake and the layers
Define lakehouse and warehouse structure, medallion layering, shortcuts and mirroring where they avoid needless copies.
You get one logical lake with a clear promotion path.
Step 5
Build the shared semantic model
One certified model per domain carrying measures, hierarchies and security, consumed by every report.
You get the same number wherever it is read.
Step 6
Implement security in the model
Row and object-level security aligned to enterprise identity.
You get entitlement that does not depend on each report being configured correctly.
Step 7
Migrate in waves and retire as you go
Move reports by domain, migrate consumers, and switch off the legacy asset in the same wave.
You get a shrinking estate rather than two running in parallel.
Step 8
Enable governed self-service
Open self-service onto certified models with endorsement, training and guardrails.
You get analyst velocity without a new generation of competing numbers.
Step 9
Operate the platform
Capacity monitoring, refresh reliability, cost attribution, endorsement lifecycle and estate review.
You get a platform that stays healthy after implementation.
Not every report, dataset, pipeline or table deserves migration. Step one produces an inventory. This turns it into a scope.
Retain
Works where it is. Frequently EHR vendor content or a well-governed existing asset. Left alone deliberately.
Modernize
Genuinely needed, rebuilt on the certified model rather than ported as-is.
Consolidate
One of several assets answering the same question. Merged into one certified product.
Replace
The need is real; the current implementation is not worth carrying forward.
Retire
No longer used, trusted, or needed. Switched off with a named owner for the decision.
| Property | Power BI Sprawl | Legacy BI Tool | Fabric as Lift and Shift | Governed Fabric |
|---|---|---|---|---|
| One certified definition | No | Sometimes | No | Yes |
| Capacity sized on peak | Not applicable | Not applicable | Rarely | Yes |
| Security in the model | Per report | Per report | Per report | In the semantic model |
| Legacy estate retired | No | No | No | Yes, per wave |
| Self-service safe to open | No | Restricted | No | Yes, onto certified models |
| Cost attributable to a consumer | No | Fixed | No | Yes |
| Portable if the platform changes | Partly | No | Partly | Storage yes, model layer no |
These three groups are usually delivered by three different teams at three different times, which is why the platform arrives before the governance and the migration never finishes. We deliver them together and sequence them so the governance lands first.
Platform and Architecture
Capacity Design and Management
SKU selection modeled against measured workload, workload isolation, and monitoring before go-live.
OneLake and Lakehouse Architecture
Medallion layering with clear promotion rules, shortcuts and mirroring to avoid unnecessary copies, and Delta as an open storage format.
Data Engineering and Pipelines
Ingestion from EHR reporting environments, FHIR and HL7 sources, claims, ERP, workforce and departmental systems using the mechanism each source warrants.
Real-Time and Event Data
Streaming and event workloads where a decision genuinely needs them.
Model and Report
Semantic Model Engineering
One certified model per domain with measures, hierarchies, time intelligence and security defined once.
Storage Mode Design
Direct Lake, Import and DirectQuery selected per model against volume, latency and feature requirements.
Measure and DAX Governance
A reviewed measure library with naming standards, documented definitions and version control.
Report and Application Design
Interactive reports, paginated reports, mobile layouts and embedded analytics selected for the audience.
Govern and Operate
Tenant and Workspace Governance
Tenant settings, workspace structure, role assignment, naming standards, sharing and external access rules established before content exists.
Endorsement and Certification
Promoted and certified endorsement mapped to the certification tiers used across the analytics estate.
Lifecycle Management
Deployment pipelines, source control and promotion from development to test to production.
Capacity and Cost Operations
Utilization monitoring, throttling alerting, cost attribution to workspace and domain, and periodic estate review.
What CaliberFocus does, and does not do?
We implement the platform, but the work that determines success is the governance and the migration around it. We will assess honestly whether Fabric is the right destination for a given workload, tell you what should stay in your EHR vendor analytics layer, and be explicit about which parts of the architecture are portable if you later change platform.
We implement the platform, but the work that determines success is the governance and the migration around it. We will assess honestly whether Fabric is the right destination for a given workload, tell you what should stay in your EHR vendor analytics layer, and be explicit about which parts of the architecture are portable if you later change platform.
A platform assessment that concludes everything should move is not an assessment. The third column is the useful one: what to watch on each workload, and where the honest answer is to leave it where it is.
| Workload | Why Fabric Fits | What to Watch |
|---|---|---|
| Enterprise executive and financial reporting | One certified model across EHR, finance, workforce and claims that no single source system can produce. | Reconciliation to the close, and refresh timing against the finance calendar. |
| Cross-source operational analytics | Combines EHR, scheduling, workforce and supply data that live in different systems. | Identity resolution has to be solved upstream, not in the report. |
| Revenue cycle analytics | High volume, joins clearing house and remittance data to the EHR, benefits from lakehouse scale. | Data volume drives capacity. Model this workload specifically before sizing. |
| Service line and margin analysis | Needs cost accounting, clinical activity and claims together. | Definition ownership between finance and operations must be settled first. |
| Population and claims analytics | Large historical volumes and ML workloads suit the lakehouse pattern. | Sensitive category segmentation must be designed at ingestion. |
| Self-service analyst environment | Governed exploration on certified models with a clear promotion path. | Only open this after the certified models exist. The order is not negotiable. |
| Data science and ML feature preparation | Notebooks, Delta tables and the same governed data the reporting uses. | Keep training and serving features consistent with the reporting definitions. |
| EHR operational reporting | Usually a poor fit. The vendor layer is already reconciled and well understood. | Leave it unless the question crosses instances or sources. |
| Sub-second transactional lookup | Not a Fabric workload. | Use the operational system or a purpose built store. |
Scope boundary
For the metric layer, driver models and reporting discipline independent of platform, explore our Operational and Financial Analytics services. For the data foundation beneath this, explore our Healthcare Data Platform Engineering and EHR Data Warehousing and Lakehouse services.
For the metric layer, driver models and reporting discipline independent of platform, explore our Operational and Financial Analytics services. For the data foundation beneath this, explore our Healthcare Data Platform Engineering and EHR Data Warehousing and Lakehouse services.
The single highest leverage decision in a Power BI estate is whether measures live in shared certified semantic models or inside individual reports. Everything else about consistency, governance, security and maintenance follows from it, and it is very difficult to reverse once a few hundred assets exist.
| Mode | Best For | What to Design Around |
|---|---|---|
| Direct Lake | Large models on lakehouse Delta tables where near current data and fast interactive performance are both needed. | Guardrail limits by capacity tier, and fallback behavior when they are exceeded, which degrades performance quietly rather than failing loudly. |
| Import | Well bounded models, complex transformation logic, maximum interactive performance. | Refresh windows, memory footprint against capacity, and data freshness expectations set with consumers. |
| DirectQuery | Very large or highly volatile sources, or where a copy is not permitted. | Source system load, query performance, and the reduced modeling feature set. |
| Composite | A large fact volume with smaller dimensions, or blending a governed model with local additions. | Complexity of governance, and the risk of local additions quietly becoming production. |
One certified model per domain
Reports connect to shared models rather than carrying their own. A report author writing a new base measure is a signal that the model has a gap.
A reviewed measure library
Naming standards, documented business definitions, review before publication and version history.
Endorsement used deliberately
Certified for board, regulatory and contractual use. Promoted for reviewed operational content.
Deployment through pipelines, not through edits
Development, test and production workspaces with a promotion path and source control.
Board
Strategic measures, trend and target, with minimal operational detail.
Executive
Enterprise outcomes with a controlled drill path into major drivers.
Manager
Operational drivers at the level the manager can influence today or this week.
Analyst
Governed model access for investigation and self-service.
Before a single report exists, the tenant already permits or prevents publishing to the web, external sharing, export to file, workspace creation by any user and other behaviors. Reviewing them is easy on an empty tenant and much harder once departments have built around permissive settings.
Tenant and workspace
- Tenant settings reviewed against a healthcare posture, with publish to web disabled and external sharing off by default
- Workspace creation controlled with a defined request path
- Workspace structure, naming and role assignment standardized
- Deployment pipelines and source control required for certified content
Data access
- Row and object-level security implemented in the semantic model
- Security roles driven by enterprise identity and group membership
- Provider and staff-level performance reporting access designed with legal and medical staff leadership
- Sensitive category segmentation enforced in the model
Protection and classification
- Sensitivity labels applied to models and reports
- Export controls on downloads, print and analyze in Excel
- External and guest access controlled explicitly
- Data loss prevention and classification integrated with enterprise information protection tooling
Audit and assurance
- Activity logging retained and reviewable
- Periodic access review
- Certified content reviewed on a cycle
- BAA and shared responsibility position with Microsoft documented, and data residency confirmed
Lineage Answers Two Questions
Where did this number come from, and what breaks if this source, transformation, measure or model changes. Both are needed before a change reaches production.
Where did this number come from, and what breaks if this source, transformation, measure or model changes. Both are needed before a change reaches production.
Capacity is the aspect of Fabric that most consistently surprises provider organizations after go-live. Consumption is smoothed and can burst, which is generous until sustained overuse produces throttling, and throttling arrives during the exact week that combines month-end close, board pack production and the heaviest refreshes of the cycle. Sizing on average workload guarantees this. Sizing on peak concurrency, with heavy workloads isolated, avoids it.
Size on peak, isolate the heavy workloads
Model close week concurrency rather than a Tuesday average, and separate large refresh and data engineering workloads from interactive reporting so one cannot starve the other.
OneLake as one logical lake
Shortcuts and mirroring used to reference data in place rather than copying it repeatedly. Every avoided copy is avoided cost, avoided latency and one fewer version to reconcile.
Medallion layering with promotion rules
Raw, conformed and curated layers with defined promotion, so consumers never read from raw and a source change is absorbed in one layer.
OneLake does not mean copy everything
into one place
It is one logical lake, not a mandate to centralize every byte. Shortcuts and mirroring reference data in place, and the EHR database schema is not the enterprise analytical model.
Be explicit about portability
Delta in OneLake is an open format and the data layer is genuinely portable. Semantic models, DAX, workspace configuration and pipelines are not.
Integration by source, not by default
EHR reporting environments, FHIR and HL7, X12, ERP, workforce and departmental systems each ingested through the mechanism they actually support,
Cost attributed from day one
Capacity consumption attributed to workspace, domain and consumer, so a cost conversation is about a specific workload rather than about the platform in general.
Use Accelerators to Accelerate, Not as the Only Place You Understand Your Data
Your data model, transformation logic, identity strategy, metric definitions, governance and semantic models must remain owned and understandable by your own team regardless of which accelerator you started from.
Design the Foundation Once for Analytics and AI
The same governed data products and certified semantic models should serve Power BI, forecasting, machine learning, copilots and agents.
The Licensing Conversation Belongs Early
Who needs a per-user licence, who consumes from capacity, what SKU the workload requires and what happens when consumption grows are commercial questions that constrain the architecture.
Platform programmes are usually reported on delivery: workspaces created, reports migrated, users onboarded. Those measure activity. We baseline the estate before starting and report on whether it got smaller, more reliable and better trusted.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Estate size | Datasets, reports and workspaces before and after, duplicate models retired, unused assets removed | Migration should shrink the estate. If it grew, it copied. |
| Consistency | Share of reporting on certified models, competing versions of key measures in circulation | The whole reason for a shared semantic layer. |
| Capacity health | Utilization against capacity, throttling incidents, refresh success rate and duration at close week | The failure everyone discovers late. |
| Reliability | Refresh commitments met, failures by cause, time to detect a source change | Consumers stop checking whether the data loaded. |
| Speed | Time to publish a new certified report, analyst time to answer a new question | The productivity case. |
| Cost | Capacity and licence cost per active consumer, cost by domain, trend against usage growth | Consumption platforms succeed technically then get challenged in budget. |
| Adoption | Weekly active consumers by role, manager tier adoption, legacy platform usage decline | Legacy usage that never declines means nothing was actually replaced. |
| AI readiness | Governed data products and certified models available to AI, and AI initiatives consuming them rather than building new extracts | Whether this foundation is serving the next wave or being bypassed by it. |
Migration is where these programmes stall.
Building the platform takes weeks and moving consumers off two hundred legacy assets takes quarters. Budget the migration as the larger half of the work, name an owner for retirement specifically, and expect to leave a small number of legacy reports running deliberately rather than pretending they will all go.
Building the platform takes weeks and moving consumers off two hundred legacy assets takes quarters. Budget the migration as the larger half of the work, name an owner for retirement specifically, and expect to leave a small number of legacy reports running deliberately rather than pretending they will all go.
In most assessments a large share of published assets have almost no viewers, a handful of datasets duplicate each other, and capacity is under pressure in a predictable week nobody has modeled. We will show you the estate as it really is, size capacity against your actual workload including close week, and give you a migration and retirement sequence that ends with fewer assets than you have now. If you are early enough that the tenant is close to empty, that is the ideal time and the governance work is a fraction of the cost.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
