Modern Data Platform for a Healthcare Services Company

A national healthcare services organization relied on Microsoft Dynamics 365 and Dataverse to manage operational case data, including information containing Protected Health Information (PHI).

Dynamics 365 was effective as a transactional platform, but the organization increasingly needed capabilities that were difficult to provide directly from the operational system: historical reporting, trend analysis, higher-frequency analytics, consistent business metrics, and a data foundation capable of supporting future AI use cases.

Because the data included PHI, expanding analytics also introduced an important requirement: the organization needed a HIPAA-compliant analytical architecture that maintained appropriate safeguards as sensitive data moved beyond the operational Dynamics environment.

Stackular designed and implemented a modern data platform using Microsoft Fabric and a Bronze, Silver, and Gold medallion architecture. The platform uses Microsoft's native Dataverse-to-Fabric integration to make operational data available in Fabric, preserves historical versions of records in the Silver layer, and exposes curated analytical data through a Fabric Data Warehouse in the Gold layer.

Fabric Notebooks provide the programmable data-engineering capabilities needed for historical processing and transformation, while Fabric Materialized Views create reusable, optimized analytical structures for Power BI and other downstream consumers.

The Challenge

The organization's healthcare case-management operation generated business-critical information inside Microsoft Dynamics 365 and Dataverse.

The operational application was primarily designed to manage current cases, workflows, assignments, and business processes. As reporting requirements became more sophisticated, users increasingly needed to answer questions that extended beyond the current state of a Dataverse record.

They needed to understand:

• How has operational activity changed over time?
• What did a case look like at an earlier point in its lifecycle?
• How long did cases remain in different stages?
• Are operational trends improving or deteriorating?
• What patterns exist across historical cases?
• How do current results compare with previous periods?
• How can historical information eventually support predictive analytics or AI?
• How can reporting become more current without increasing analytical load on the production Dynamics environment?

The existing reporting process also refreshed analytical data only once per day. For operational dashboards, that meant information could be many hours behind the activity occurring in the case-management system.

The organization therefore needed a dedicated analytical platform that could:

• preserve historical state
• increase reporting frequency
• support complex analytics
• reduce reliance on Dynamics for analytical processing
• centralize business logic
• support Power BI
• protect PHI throughout the analytical lifecycle
• provide a foundation for future AI capabilities

Why the Operational System Wasn't Enough

Dataverse is well suited for transactional workloads such as maintaining current record state, enforcing application security, supporting workflows, and providing users with interactive business applications.

Analytics requires a different type of architecture.

A transactional case-management system may need to answer:

What is the current status of this case?

An analytical platform may need to answer:

How did this case progress through its lifecycle, how long did it remain in each stage, and how does that behavior compare with thousands of historical cases?

If an analytical solution stores only the current value of each source record, important historical context can disappear as records change.

Advanced analytics also introduces workloads such as large data scans, historical comparisons, complex joins, reusable transformations, aggregations, and time-based analysis that are better handled outside the operational application.

Stackular therefore separated transactional processing from analytical processing rather than continuing to expand reporting directly against Dynamics and Dataverse.

Stackular's Approach

Stackular designed the platform around Microsoft Fabric using a layered medallion architecture.

The architecture separates data responsibilities into three primary layers:

• Bronze — source-aligned operational data from Dataverse
• Silver — transformed, conformed, and historically preserved data
• Gold — curated analytical data presented through a Fabric Data Warehouse

Each layer has a clear role.

This separation allows ingestion, data engineering, historical processing, security, analytics, and reporting to evolve independently while maintaining traceability back to the operational source.

Because the source data includes PHI, security and HIPAA requirements were treated as core architectural requirements, not as controls to be added after the analytical solution was built.

The architecture was designed to maintain safeguards around sensitive healthcare data throughout ingestion, transformation, storage, warehousing, semantic modeling, and reporting.

Microsoft Fabric medallion architecture

From operational healthcare data to governed analytics

1. Operational sourceDynamics 365 + DataverseCurrent healthcare operations
2. BronzeSource-aligned ingestionNative Fabric integration, traceability, and recovery
3. SilverHistorical + conformed dataNormalization, transformation, and historical preservation
4. GoldBusiness-ready warehouseKPIs, Materialized Views, and reusable analytical models
5. ConsumptionPower BI + AI-ready foundationSemantic models, reporting, analytics, and governed future AI use cases

• HIPAA / PHI governanceIdentity, minimum-necessary access, encryption, controlled workspaces, and governed exposure

Solution Architecture

Bronze Layer — Native Dataverse Data in Microsoft Fabric

The Bronze layer uses Microsoft's native Dataverse-to-Fabric integration to make operational Dataverse data available within the Fabric environment.

Rather than creating and maintaining a traditional API-based ETL framework for each source table, the architecture takes advantage of Microsoft's platform-level integration between Dataverse and Fabric.

The Bronze layer maintains data close to its source representation and provides the foundation for:

• source ingestion
• reconciliation
• traceability
• downstream transformation
• historical processing
• recovery and reprocessing

Because Bronze can contain PHI, it is treated as a controlled analytical data layer rather than as an unrestricted raw-data repository.

Using the native Fabric integration also reduces the need to create additional intermediate databases, custom extraction services, and unnecessary copies of sensitive data.

Silver Layer — Historical and Conformed Data with Fabric Notebooks

The Silver layer transforms operational data into structures designed for analytics.

One of its most important responsibilities is historical preservation.

Operational records change throughout their lifecycle. A case can move through multiple statuses, assignments, dispositions, and other states. If analytics retains only the latest version of the Dataverse record, previous states can disappear from the analytical view.

Stackular designed the Silver layer specifically to retain historical versions of operational information so analysts can examine how records and processes change over time.

This makes it possible to answer questions such as:

• How long did cases remain in each stage?
• How did workloads change across different periods?
• What operational patterns preceded specific outcomes?
• How do current metrics compare with previous periods?
• What historical characteristics could eventually be useful for predictive analysis?

Microsoft Fabric Notebooks are used as part of the Silver-layer data-engineering process.

Notebooks provide a programmable environment for implementing processing that goes beyond simple data movement, including:

• historical processing
• normalization
• data-quality rules
• transformation logic
• derived fields
• reusable engineering logic
• preparation of data for downstream analytics

The Silver layer therefore serves as both a historical analytical foundation and a controlled location for creating trusted, conformed data.

Because that data can still contain PHI, access to Silver-layer information remains governed based on the needs of data-engineering and analytical workloads.

Gold Layer — Governed Fabric Data Warehouse

The Gold layer uses a Microsoft Fabric Data Warehouse to provide business-ready analytical data.

Rather than requiring every Power BI report to understand operational Dataverse schemas or independently recreate transformation logic, the Gold layer organizes information around analytical and business concepts.

This layer can also serve as an important consumption boundary for sensitive data.

Business users and reporting solutions can consume curated analytical structures rather than requiring broad direct access to lower-level source or historical data.

The Gold layer supports:

• operational dashboards
• management reporting
• KPI calculation
• historical comparisons
• trend analysis
• time-based metrics
• reusable analytical structures
• Power BI semantic models
• future advanced analytics and AI use cases

Using Fabric Materialized Views for Reusable Analytics

Fabric Materialized Views are used where appropriate to create reusable analytical structures for frequently needed calculations and data relationships.

Analytical workloads often perform the same joins, aggregations, and transformations repeatedly.

Without a centralized approach, similar logic can end up being recreated independently across Power BI reports and semantic models.

Materialized Views allow selected analytical results to be prepared and persisted centrally so downstream consumers can reuse them.

This provides several benefits:

• simpler downstream reporting
• consistent analytical logic
• reduced repeated query processing
• reusable curated datasets
• clearer separation between data engineering and visualization

For a healthcare environment containing PHI, this approach can also help reduce the need for downstream reporting solutions to repeatedly access and transform lower-level data.

Protecting PHI Across the Data Platform

HIPAA Compliance Was an Architectural Requirement

The source Dynamics environment contains healthcare operational information that includes PHI.

Creating a separate analytical platform without maintaining appropriate safeguards would have introduced unnecessary risk.

Stackular therefore designed the Fabric platform as a HIPAA-compliant data architecture, with PHI protection considered throughout the data lifecycle.

The objective was not simply to copy sensitive data into an analytics platform. It was to create a governed analytical environment in which data could be ingested, transformed, modeled, and consumed while maintaining appropriate protections.

Controlled Access to Sensitive Data

Not every user who needs analytical information needs direct access to raw or historical PHI.

The layered architecture makes it possible to distinguish between:

• engineering access to source-aligned data
• processing access to historical and transformed data
• business access to curated analytical information
• reporting access through semantic models and Power BI

This supports least-privilege and minimum-necessary access principles.

Curated Analytical Exposure

Where practical, report consumers access Gold-layer structures and Power BI semantic models rather than directly accessing Bronze or Silver datasets.

This reduces unnecessary exposure of detailed healthcare information while giving users the information they need for operational and management reporting.

Encryption and Identity-Based Controls

The architecture uses Microsoft cloud security capabilities to protect healthcare information in transit and at rest, combined with identity and access controls governing who and what can access data throughout the platform.

Separation of Operational and Analytical Workloads

Moving analytical processing into Fabric reduces the need to execute complex reporting workloads directly against the production Dynamics environment.

This separation improves analytical scalability while creating clearer boundaries around how operational PHI is consumed for analytics.

Key Technical Decisions

Why Microsoft Fabric?

The organization was already operating extensively within the Microsoft ecosystem.

Microsoft Fabric provides an integrated platform for data ingestion, lakehouse storage, data engineering, notebooks, warehousing, semantic models, Power BI, and advanced analytics.

Using Fabric reduced the need to assemble and operate a collection of disconnected technologies while providing an architecture capable of expanding into future analytics and AI use cases.

Why Use Microsoft's Native Dataverse-to-Fabric Integration?

Because Dataverse was the primary operational source, Stackular used Microsoft's native integration capabilities instead of creating an independent API extraction framework.

This reduced custom ingestion code and allowed the data-engineering architecture to focus on higher-value capabilities such as historical processing, transformation, analytics, and governance.

Why Not Report Directly Against Dataverse?

Direct Dataverse reporting can be appropriate for straightforward operational reporting.

As analytical requirements grow, organizations often need:

• historical state
• more complex transformations
• larger data scans
• joins across multiple business entities
• reusable business calculations
• trend analysis
• higher reporting frequency
• advanced analytics

Separating those workloads into Fabric allows Dynamics and Dataverse to remain focused on transactional application processing.

Why Preserve Historical Data in Silver?

The current value of a business record does not tell the complete story of a business process.

Knowing that a case is currently complete does not reveal:

• when it entered each previous stage
• how long it remained there
• how frequently its state changed
• how its progression compared with other cases

Historical preservation creates the time dimension required for operational improvement, process analytics, trends, and many predictive use cases.

Why Use Fabric Notebooks for Silver-Layer Processing?

Not every data transformation is best implemented with simple pipeline activities or SQL.

Fabric Notebooks provide a programmable engineering environment for implementing more sophisticated historical and transformation logic.

Keeping this processing within Fabric also allows ingestion, transformation, storage, warehousing, and analytics to operate within a common platform.

Why Use a Fabric Warehouse for the Gold Layer?

Raw or historically transformed data is not necessarily organized around the questions business users ask.

The Fabric Data Warehouse provides a relational, analytics-oriented layer where information can be curated for reporting and reuse.

It also reduces the likelihood that separate reporting solutions will independently implement different versions of the same business metric.

Why Use Fabric Materialized Views?

Frequently used analytical logic should not necessarily be recomputed independently by every report.

Fabric Materialized Views provide reusable persisted analytical structures that can simplify downstream consumption and centralize selected joins, transformations, and aggregations.

Why Was HIPAA Compliance Part of the Data Architecture?

The source data includes PHI.

Moving that information into an analytical environment without equivalent safeguards would undermine the organization's healthcare data protections.

The architecture therefore considered identity, access, encryption, workspace governance, controlled analytical exposure, and minimum-necessary access as part of the platform design.

Why Use a Gold Layer for PHI Reporting?

The Gold layer provides more than reporting convenience.

It creates a governed consumption boundary.

Power BI and business users can access curated analytical structures without requiring broad direct access to lower-level operational and historical PHI.

Increasing Reporting Freshness from Daily to Every Two Hours

The previous reporting process refreshed analytical data once per day.

For an operational healthcare organization, that meant dashboards could be many hours behind activity occurring in the case-management system.

The Fabric architecture increased analytical refresh frequency to every two hours.

That changed the reporting cycle from:

Before: 1 refresh every 24 hours
After: up to 1 refresh every 2 hours

This increased data refresh frequency from 1 to 12 times per day.

The result was substantially more current operational information without requiring dashboards to execute their analytical workloads directly against Dynamics.

Supporting Power BI

Power BI provides the primary business-intelligence experience on top of the Fabric data platform.

Instead of requiring individual reports to implement extensive data transformations independently, Fabric performs much of the engineering required to produce trusted analytical datasets.

The combination of the Gold-layer Fabric Data Warehouse, Fabric Materialized Views, and reusable Power BI semantic models allows the reporting layer to focus primarily on:

• visualization
• business metrics
• management dashboards
• operational analysis
• exploration
• decision support

Reusable analytical logic can be maintained in the data platform instead of being recreated separately across reports.

Creating a Secure, AI-Ready Data Foundation

The same historical information required for effective analytics can eventually support more advanced use cases.

A transactional record containing only the current state provides limited information about the sequence of events that produced that outcome.

Historically preserved and curated data provides substantially richer context for:

• trend detection
• anomaly identification
• forecasting
• predictive analytics
• operational recommendations
• natural-language analytics
• enterprise AI agents

For healthcare organizations, however, AI readiness also requires security readiness.

Preparing PHI for analytical or AI use does not mean making it broadly accessible.

The data platform creates a governed foundation in which historical context, data quality, identity controls, access management, and PHI protections can work together as future capabilities are introduced.

Business Results

Reporting Refreshes Increased from Once Daily to Every Two Hours

Analytical data is now refreshed up to 12 times per day instead of once per day, providing users with much more current operational information.

HIPAA-Compliant Analytics

The organization gained richer historical and operational analytics while maintaining a data architecture designed to protect PHI throughout ingestion, processing, storage, modeling, and reporting.

Historical Analytics

The Silver layer allows the organization to analyze previous operational states rather than being limited to current Dataverse values.

Controlled Access to PHI

Curated Gold-layer data and Power BI semantic models reduce the need for most business users to directly access lower-level datasets containing detailed healthcare information.

Reduced Dependence on Dynamics for Analytics

Reporting and analytical workloads can operate against the dedicated Fabric platform rather than depending on complex analytical processing against the production transactional system.

Consistent Business Metrics

Curated Gold-layer models, Materialized Views, and reusable semantic models create centralized locations for analytical logic and business definitions.

Better Data Reuse

Trusted and transformed datasets can support multiple dashboards and analytical workloads instead of being reconstructed separately for every report.

Foundation for Secure AI and Advanced Analytics

Historical, curated, and governed data provides the context necessary for future predictive analytics, machine learning, and generative AI while preserving controls around sensitive healthcare information.

Scalable Data Architecture

The Bronze, Silver, and Gold model creates clear architectural boundaries that make it easier to incorporate additional sources and analytical requirements over time.

Technologies Used

• Microsoft Fabric
• Microsoft Dataverse
• Dynamics 365
• Dataverse Link / Fabric Integration
• Fabric Lakehouse
• Fabric Data Warehouse
• Fabric Notebooks
• Fabric Materialized Views
• Fabric Data Pipelines
• Power BI
• Power BI Semantic Models
• Microsoft Entra ID
• Medallion Architecture
• Historical Data Processing
• Incremental Data Processing
• Role-Based Access Control
• Encryption at Rest and in Transit
• HIPAA-Compliant Data Architecture
• PHI Data Governance

Lessons for Organizations Building a Modern Healthcare Data Platform

Don't use your transactional application as your enterprise data warehouse.

Operational systems and analytical systems solve different problems.

A system optimized for application transactions, workflows, and user interactions should not also be expected to perform every historical and analytical workload.

Preserve history intentionally.

If historical analysis may eventually matter, design for it before the organization needs it.

Once previous values are overwritten in an operational system, reconstructing that history can be difficult or impossible.

Reporting freshness is an architectural decision.

Organizations often focus on dashboard design while overlooking how quickly the underlying data becomes available.

Moving from daily refreshes to every two hours substantially changes how useful operational reporting can be.

Separate raw data from business-ready data.

Bronze, Silver, and Gold are valuable because they establish explicit boundaries between source-aligned data, trusted historical data, and information prepared for business consumption.

Use curated analytical layers to reduce PHI exposure.

Most report consumers do not need direct access to raw healthcare data.

A governed Gold layer can provide useful business information while limiting unnecessary access to lower-level PHI.

Treat healthcare data security as part of the data model.

HIPAA requirements should not be addressed only at the network or infrastructure perimeter.

Organizations should consider who needs access at each layer, which information is required for each use case, and whether lower-level PHI needs to be exposed at all.

Centralize reusable analytical logic.

If multiple reports independently calculate the same KPI, inconsistent definitions eventually emerge.

Materialized Views, curated warehouse structures, and semantic models provide places to establish reusable and consistent analytical definitions.

Build the data foundation before expecting sophisticated AI.

Generative AI cannot compensate for fragmented, inconsistent, historically incomplete, or poorly governed enterprise data.

Organizations that want meaningful AI capabilities should first establish reliable, structured, governed, and historically meaningful information.

AI readiness also requires security readiness.

Preparing healthcare data for AI does not mean making it more broadly accessible.

An AI-ready healthcare architecture must combine data quality and history with appropriate identity, governance, access controls, and PHI protection.

Frequently Asked Questions