Summary
Medallion architecture sorts healthcare data into three progressively cleaner layers, bronze, silver, and gold, so a hospice or health system’s leadership team can trust the number behind every clinical, compliance, and financial decision. This guide breaks down what happens at each layer, where PHI de-identification belongs, and what a real build costs.
Introduction
Your length-of-stay number is probably wrong. Not fraudulently wrong!
Quietly wrong: pulled from three systems, patched by hand where the columns didn’t line up, rounded where nobody had time to check. It ends up in the board deck anyway. Ask where it actually came from and watch the room go quiet.
That’s the real failure hiding inside most hospice data stacks. It’s not that the data is missing. It’s that nobody can say with confidence which version of it is true.
Medallion architecture is the fix. Databricks, Microsoft Fabric, and Snowflake have all landed on it as their default recommendation, a layered bronze, silver, gold pattern that turns scattered EHR exports, claims files, and referral forms into one number a COO can actually defend, whether that’s in a board meeting or in front of a CMS reviewer.
What medallion architecture actually means
Medallion architecture organizes data into three layers, bronze, silver, and gold, where each layer represents a higher standard of trust than the one before it. Databricks popularized the pattern around 2019 as part of its data lakehouse approach. It’s since become the default design recommendation inside Microsoft Fabric’s OneLake and Snowflake’s dynamic tables, and that convergence across three competing vendors says something: this isn’t a one-vendor trend, it’s how the industry has settled on structuring data at scale.
The concept itself is simple, even when the engineering underneath isn’t. Raw data lands untouched. It gets cleaned and validated in a middle layer. It gets shaped into something a dashboard, a predictive model, or a CMS report can consume directly in the last layer. Each layer acts as a checkpoint, and a number doesn’t move forward until it clears the bar for that stage.
For a hospice organization pulling EHR records, claims data, referral intake forms, and HOPE assessment data out of a dozen disconnected systems, a familiar problem if you’ve read our breakdown of hospice EMR and referral data integration, medallion architecture is what turns that sprawl into one governed, explainable pipeline instead of a dozen separate one-off cleanup jobs.
Bronze, Silver, and Gold: what actually happens at each layer
Bronze: raw data, untouched
The bronze layer stores data exactly as it arrives, no cleanup, no validation, no reformatting. An EHR export lands here with its duplicate patient records still duplicated. A claims file lands here with its rejected line items still in it. Nothing gets fixed yet, and that’s deliberate.
Keeping an untouched copy means you always have a way to answer what the source system actually sent, without arguing about it later. If a downstream report looks wrong, bronze is where you go to check whether the error started upstream or got introduced during cleanup.
Silver: cleaned, validated, de-identified
This is where the real work happens. Silver takes the raw bronze data and applies the rules: drop the duplicate patient records, standardize date formats across systems that all format dates differently, reject line items that fail a validation check, and join related datasets, patient plus claims plus caregiver visit, for instance, into something coherent.
This is also, functionally, where PHI de-identification belongs in most healthcare medallion builds. The HHS Office for Civil Rights’ Safe Harbor guidance under 45 CFR 164.514(b) sets out 18 identifier categories that have to be removed or generalized before health data counts as de-identified.
Silver is the natural checkpoint for that removal, after raw data has been validated and joined, but before it reaches gold-layer tables that a wider set of analysts, vendors, or BI tools can query.
De-identification is one piece of a bigger picture. Access controls, retention policies, who’s allowed to query what, that’s a separate set of decisions worth its own conversation, which is why we’ve broken it out in our framework for data governance and CMS compliance for hospice care agencies.
Gold: business-ready, aggregated
Gold is what your COO actually looks at. Length-of-stay averages by team. HQRP compliance rates by facility. Referral-to-admission conversion by source. These are aggregated, curated tables built for a specific consumer, a dashboard, a predictive model, a CMS submission, not a general-purpose dump of everything the organization has ever collected.
The Databricks lakehouse documentation is explicit on this point: gold tables should be organized around named use cases with a clear owner, not treated as a shared catch-all for every possible metric. When two departments can’t agree on which gold table holds the real length-of-stay number, that’s usually a sign gold wasn’t scoped tightly enough to begin with.
Usually, that argument gets settled by tracing the number back through the pipeline, bronze to silver to gold, which is exactly what is built for: not just what a gold table says, but proof of how it got there.
Medallion Architecture vs. Data Mesh: Which One Do You Actually Need
Medallion architecture organizes data by quality stage, bronze to silver to gold. Data mesh organizes data by business domain, giving each team, clinical, billing, referrals, ownership of its own data products. They answer different questions, and for most single-organization hospice or home-based care networks, they’re not actually competing.
A mid-size hospice agency with one data team and a handful of source systems rarely needs the organizational overhead of a full data mesh: distinct domain teams, federated governance, a data product marketplace. Medallion architecture, applied inside a single governed platform, gets you a trustworthy, audit-ready gold layer without that overhead. Data mesh tends to earn its complexity at multi-facility health systems or larger networks, where a dozen departments are already fighting over who owns what data and no single team could realistically own a company-wide bronze-to-gold pipeline anyway.
Databricks, Microsoft Fabric, or Snowflake: How the Big Three Actually Differ
All three vendors now treat medallion architecture as a first-class, documented pattern, but the mechanics differ:
- Databricks implements the layers as Delta Lake tables inside Unity Catalog, typically one schema per layer, and increasingly through Lakeflow’s declarative pipelines for the bronze-to-gold flow, per Databricks’ own lakehouse documentation.
- Microsoft Fabric builds medallion directly on OneLake, its unified logical data lake, recommending either separate lakehouses per layer or materialized lake views for the silver-to-gold transformation, according to Microsoft’s own Fabric documentation.
- Snowflake doesn’t require separate storage per layer. Its own documentation on dynamic table design patterns describes bronze as the raw landing table, silver as a cleaned dynamic table with a downstream-linked refresh target, and gold as an aggregated dynamic table with its own freshness goal, all inside one platform’s compute and governance model.
The practical takeaway for a hospice CIO evaluating platforms: the medallion pattern itself is vendor-agnostic. What changes is how much infrastructure you manage directly versus how much a managed service handles for you, and that’s a platform decision worth making with your data engineering partner, not one the architecture pattern forces on you.
What This Actually Costs: Team, Timeline, and Budget
A realistic bronze-to-gold build for a mid-size hospice care agencies typically needs a small dedicated team, one to three data engineers depending on source system count, plus a part-time data architect for the first phase, and runs for some weeks for an initial working pipeline covering your highest-priority source systems: EHR, billing, referral intake. Full coverage across every legacy system usually extends past that, as acquisitions and edge cases get absorbed.
That tracks with what we’ve seen in practice. Our work building an enterprise data platform from the ground up for a post-acute care organization unified EMRs, a patient triaging platform, the state HIE, and HR data into one governed warehouse, architected specifically so new EMRs, service lines, or acquired entities can onboard without rebuilding the foundation each time. The project shipped in a fraction of its planned 18-month timeline.
The heavy lift is building that foundation once. After that, onboarding a new source system becomes a repeatable process instead of a custom project.
Cost scales with source system count and data volume more than with the architecture pattern itself. Medallion architecture doesn’t inherently cost more than an ad hoc pipeline. It just makes the cost visible and predictable instead of hidden inside a dozen one-off scripts nobody understands months later.
Is Medallion Architecture Still Relevant in 2026?
The medallion pattern remains the default, not a close call. Databricks recommends it natively, Microsoft Fabric calls it the recommended design approach, and Snowflake has built native tooling around the same three-layer vocabulary in its own documentation.
At nearly six years old, it’s mature enough that the real question has shifted from whether to use it to how to enforce layer boundaries so gold doesn’t become a dumping ground, which for a healthcare organization sitting on scattered EHR, claims, and referral data is reason to adopt it now, not wait for a replacement that isn’t coming. And gold doesn’t just sit there for reporting: it’s what feeds the length-of-stay models, staffing projections, and capacity planning that become forecasts leadership can defend, not a hunch dressed up in a spreadsheet.
Building This on a Foundation That’s Actually CMS-Ready
None of this works in isolation. A gold layer is only as trustworthy as what’s holding it up, and that’s the full picture we walk through in our guide to building a CMS-ready hospice data foundation. Medallion architecture gives you the layers. That guide is where the rest of the foundation lives.
