Snowflake for Healthcare
Snowflake makes reporting and data sharing easier, but only if patient data is governed from the start and costs have an owner. Our Snowflake healthcare data engineering services give your teams reports built on one set of definitions and controlled sharing with partners. A fixed-price assessment shows the plan and the cost, including whether Snowflake is the right choice.
Book the Healthcare Data Platform AssessmentFor analytics leaders, healthcare product teams and warehouse owners.
Teams wait for reports, costs drift, and sharing data with partners feels too risky to approve.
Reports built on agreed definitions, and sharing that stays within what you approve.
The right Snowflake edition and agreement come first. Access and masking are tested with real roles.
$3,500 fixed for the assessment. 2 to 3 weeks, credited against the build.
Book the assessment. If Snowflake is the wrong fit, it will say so.
The business case
Snowflake is simple to start with. Keeping it trusted, safe and affordable takes deliberate setup.
Teams add data and reports quickly, and that speed creates its own problems. Numbers drift apart, patient data spreads into places it should not be, and the bill grows with nobody responsible for it. Partners ask for data, and the safe answer turns into a long debate.
Our view
Snowflake fits when your team thinks in SQL, your main output is analytics and you need to share governed data with partners. Set the edition decision at the start: Snowflake lists PHI support on Business Critical and above, with a signed BAA required before any PHI is stored.
PHI support and Tri-Secret Secure sit at Business Critical. Masking and row access policies start at Enterprise. Finding this out late changes your budget and your timeline.
A dynamic table keeps a query result up to date against a target lag, and chained tables refresh in order. We reach for streams and tasks when the logic is procedural or has to call out.
Snowflake states that actual lag can exceed it when refreshes take longer than expected. If a consumer depends on freshness, monitor it and show it on the report.
Semantic views store logical tables, facts, dimensions and metrics in the database, and Cortex Analyst and Cortex Agents can use them. A definition held there can serve both reports and natural language questions.
When we would tell you not to choose Snowflake: large nested data needs heavy custom processing, or machine learning sits at the center of the work. Databricks may fit better, and a team already running one platform well should usually stay on it.
For decision makers
These are the questions that decide whether a data engineering vendor is safe to hire. Here are our answers, and how to test them.
| Risk | How we control it |
|---|---|
| PHI enters the wrong edition | Confirm edition and BAA before the first load, and record it |
| A shared dataset exposes too much | Secure views with minimum necessary scope, and tests from the consumer side |
| Freshness is assumed | Show actual lag on the report and alert when it exceeds the target |
| Credit use climbs | Separate warehouses by workload, with auto-suspend and a named owner |
| Legacy reports stop matching | Move report groups in stages, with a parallel run and reconciliation |
The first step
Fixed price: $3,500. 2 to 3 weeks, credited against the build.
A fixed-price first step for one decision you need the data to support. You finish with enough evidence to approve, change or stop the build, and the outputs are yours to use with any vendor.
Book the Healthcare Data Platform AssessmentThe assessment is complete when all five outputs are delivered and walked through with your owners. Sending the form starts a conversation, and you pay nothing until you agree the assessment.
How the work runs
Edition, roles and policies come first, then loading, then models. Migrations run report group by report group.
Check the edition, BAA, region, network rules and key management.
You review: An account readiness record
Set role hierarchy, masking and row access policies, and classification with tags.
You review: A policy design with access tests
Use Snowpipe for files and Snowpipe Streaming for rows, keeping raw payloads in VARIANT.
You review: Raw tables with load history
Flatten with LATERAL FLATTEN and build curated and business layers with dynamic tables.
You review: Documented models with tests
Define semantic views, connect reports and set up secure shares where needed.
You review: Governed metrics and shares
Schedule data metric functions, watch warehouse cost and rehearse recovery.
You review: A runbook and a cost review
Related delivery
Public-source life-sciences data moves through collection, name reconciliation and approval before reporting and source-cited AI answers.
Delivery context: a public-data intelligence platform built with Frappe and Power BI, with AI assistants. The case shows source integration, reconciliation and review workflows.
Read the implementation case study →
Cost drivers
The assessment is a fixed $3,500. It takes 2 to 3 weeks and is credited against the build. The build is costed in its plan, and these factors move that cost most.
FHIR JSON, X12 claims, HL7-derived tables and database CDC each need different parsing and tests.
The number of reports, stored procedures and downstream consumers that must reconcile before cutover.
Measures without an agreed definition need workshops and sign-off before they can be built.
Row-level PHI restrictions, masking by role and multiple environments add policy work and tests.
Each external consumer adds secure views, agreements and possibly replication.
Near-real-time loads with Snowpipe Streaming cost more to build and run than daily batch.
For your engineers
What your technical team will want to check: loading, schema layers, governance on Snowflake and samples of the work. Platform statements were read on the Snowflake documentation in October 2026.
The short answer
We engineer Snowflake healthcare warehouses: FHIR NDJSON, HL7-derived tables, X12 claims and EHR extracts load through Snowpipe or batch COPY into raw VARIANT and staging tables, dbt or dynamic tables build documented clinical and claims models, and masking and row access policies control PHI. Snowflake supports PHI only on Business Critical edition or higher, with a signed Snowflake BAA in place before PHI is stored, and we confirm both before the first load.
What we build
Snowflake features applied to clinical and claims data, each with a reviewable output.
Bulk Data NDJSON loads into VARIANT columns, then LATERAL FLATTEN views and typed tables for Patient, Encounter, Observation, Condition, Claim and ExplanationOfBenefit, with extensions and codings handled explicitly.
Clinical data modeling in SnowflakeSnowpipe for file drops and exports, Snowpipe Streaming or connector-based CDC for EHR and billing databases, with load history reconciled to source counts.
CDC for healthcare data warehousesMember, claim, service line, encounter and cohort models with documented grain; X12 835 adjustments with CARC and RARC codes; OMOP CDM where research needs it. Built with dbt tests or dynamic tables.
OMOP vs FHIR for clinical analyticsDynamic data masking, row access policies and object tags for PHI columns, role hierarchy per team and environment, and access history review.
Governance, lineage and PHI accessLive, read-only shares of governed datasets to partners, payers, providers or research teams without copying files, including de-identified shares prepared under HIPAA Safe Harbor.
Safe Harbor vs Expert DeterminationMigration from SQL Server, Oracle, Teradata, Netezza or Redshift with dependency inventory, parallel runs and report-level reconciliation before cutover.
ETL vs ELT for clinical data warehousingSources handled
Snowpipe suits data that already sits in files. Snowpipe Streaming suits rows pushed from applications. The two work side by side.
| Source | Snowflake path | What we keep or decide |
|---|---|---|
| FHIR Bulk Data NDJSON | Stage plus Snowpipe into a VARIANT column | The raw resource, file name and load time, then flatten by resource type |
| HL7 v2 via an interface engine | Snowpipe Streaming, or files from the engine | The raw message and control ID, then parse to segment tables |
| X12 837 and 835 | Parsed before loading, then staged | Claim, line and adjustment tables with CARC and RARC codes |
| EHR and billing databases | CDC tool into raw tables, then streams or dynamic tables | Source log position and delete markers |
| Partner and payer datasets | Secure Data Sharing where the partner is on Snowflake | Agreements, minimum necessary scope and a reader account if they are not |
Integration boundaries
What we own, and what stays with your platform, data and compliance owners.
You hold the Snowflake contract, edition and BAA. PHI requires Business Critical or higher; we verify it before loading PHI.
Source owners grant extracts, database access or FHIR export registration. We build and test the loads.
Business and clinical owners approve measure definitions. We implement them with tests and document every exclusion.
The primary scope is the data foundation. BI dashboards can be added as a separately agreed deliverable.
Data use agreements with partners are yours to sign. We implement the shares and access policies they require.
Compare your options
The sharing method decides who holds a copy, who pays for compute and how access is revoked.
| Method | How it works | Best for | Plan for |
|---|---|---|---|
| Direct Secure Data Sharing | Consumer account queries your governed objects live, with no copy | Partners that already run Snowflake in the same region | Replication for cross-region or cross-cloud consumers; share only secure views |
| Reader account | You provision a managed account for a consumer without Snowflake | Smaller partners who need read access | You pay the reader compute and manage its users |
| Listing (private or Marketplace) | Packaged, discoverable share with terms and optional auto-fulfillment | Repeatable data products for many consumers | Product ownership, documentation and refresh commitments |
| File extract | Scheduled export to cloud storage or SFTP | Consumers on other platforms | Copies to track, encryption and retention on the receiving side |
PHI in any share needs a permitted purpose, a BAA or data use agreement as applicable, and minimum-necessary views. De-identified shares follow Safe Harbor or an Expert Determination.
Medallion layers
The medallion idea applies in Snowflake as schemas with clear rules. We usually name them raw, curated and business.
| Layer | Snowflake objects | Rule | Who reads it |
|---|---|---|---|
| Raw (bronze) | Tables with VARIANT, loaded by Snowpipe | Load unchanged, with load metadata | Pipeline roles only |
| Curated (silver) | Flattened tables and dynamic tables | One row per stated grain, typed and checked with data metric functions | Engineers and approved analysts |
| Business (gold) | Dynamic tables, secure views and semantic views | Reconciled and signed off, with masking and row access applied | Analysts, BI tools and shares |
Dimension mapping
Governance belongs on the dimension. Classification can tag sensitive columns, and a masking policy tied to a tag applies automatically when that tag is assigned.
| Dimension | Mapping approach | Access treatment |
|---|---|---|
| Patient | Survivor key with merge history. A tokenized key for shared and de-identified data | Tag-based masking on identifiers |
| Provider | NPI-based key with role and effective dates | Standard role access |
| Payer and plan | Governed crosswalk with effective dates | Standard role access |
| Facility | Hierarchy table that also drives row access | Row access policy using a mapping table |
| Clinical codes | Crosswalk to LOINC, SNOMED CT, ICD-10-CM and RxNorm, with the local code kept | Standard role access |
Semantic models
A semantic view is a schema-level object made of logical tables, facts, dimensions and metrics. You query it with SELECT, and Cortex Analyst can use it when you name it in the request.
| Part of the semantic view | Healthcare example | Decision for its owner |
|---|---|---|
| Logical table | Claim, claim line, encounter, member | Which table sets the grain of each question |
| Fact | Billed amount, paid amount, adjustment amount | Whether paid means current or as first remitted |
| Dimension | Payer, service month, facility, reason group | Which hierarchy finance and operations share |
| Metric | Initial denial rate, net collection rate | Written definition, exclusions and a named owner |
Refresh frequency
Set refresh per table. With dynamic tables you state how fresh the data must be, and Snowflake schedules the work.
| Need | Option | Check first |
|---|---|---|
| Files arrive through the day | Snowpipe | Whether batch-style latency is acceptable |
| Rows pushed from an application | Snowpipe Streaming | Whether anything acts on low latency |
| Models that stay current | Dynamic tables with a target lag | Whether incremental refresh applies. AUTO lets Snowflake choose when the table is created |
| Procedural or conditional steps | Streams and tasks | Who owns the task graph and its failures |
| Shared data | Secure views over refreshed tables | What freshness the partner agreement promises |
Cleanup problems and fixes
These are issues we look for when reviewing an existing account.
| Problem | Fix | How you can check it |
|---|---|---|
| PHI in an account below Business Critical | Stop, confirm the edition and BAA, then plan the move | Account edition and agreement on record |
| Flattening multiplies rows | State a grain and aggregate before joining | Row counts per resource, before and after |
| Nulls and duplicates found by report users | Schedule data metric functions, with an expectation on each result | Check history in the quality views |
| Target lag missed unnoticed | Monitor refresh history and show freshness on the report | Actual lag compared with target for each table |
| Sensitive columns not tagged | Run classification, review its results and link tags to masking | Query as a limited role and see masked values |
| Warehouses left oversized | Separate warehouses by workload, with auto-suspend and an owner | Credit use by workload |
Dashboards people act on
Reports read semantic views, so a metric has one definition across BI tools and Cortex questions. These are scoping examples.
| Who opens it | The question | The action it triggers | Snowflake piece |
|---|---|---|---|
| Payer contracting lead | Which plans underpay against contract? | Open a dispute or renegotiate | Semantic view over claim lines |
| Population health lead | Which members have open gaps by clinic? | Direct outreach | Row access by clinic |
| Partner analytics team | What does the shared dataset cover, and how fresh is it? | Use or query the share | Secure share with a freshness field |
| CFO | What cash should arrive by payer? | Adjust the collections focus | Forecast results beside actuals |
Forecasting loop
SNOWFLAKE.ML.FORECAST lets a SQL team begin without a separate platform, as long as the loop around it is taken seriously.
Create a view with a timestamp at a fixed interval, a numeric target and any useful features.
Train and predict. Each result has lower and upper bounds, with a default prediction interval setting of 0.95.
Read the cross-validation results with SHOW_EVALUATION_METRICS, such as MAE and MAPE, and compare them with a simple baseline.
If you train with extra columns, you must supply their future values, so choose features you will really know ahead of time.
Store each run, join it to actuals and retrain or retire the model.
Forecasting functions need the same PHI review as any other workload. Prefer aggregated inputs for operational forecasts.
Deliverables
All of it lives in your repository and your Snowflake account.
Edition, BAA, network and key decisions.
Role hierarchy, masking, row access and tags, with test results.
Snowpipe definitions, dynamic tables and tests in version control.
Signed-off metrics that reports and Cortex can read.
Secure views, shares or reader accounts and their scope.
Recovery steps, quality checks and a workload cost owner.
Samples of the work
You should see what the work looks like before you hire anyone. These samples show the format we hand over. All values here are invented for illustration. They do not come from any patient, client or project.
One row for each field, with the grain stated.
| VARIANT path | Curated column | Rule | Check |
|---|---|---|---|
| raw:id, raw:meta.versionId | encounter_id, version_id | Keep the latest version per ID | Duplicate count is zero |
| raw:period.start | admit_at | Cast to timestamp and store in UTC | Null count within the agreed limit |
| raw:type[] via LATERAL FLATTEN | encounter_type (one row each) | Separate table, because flattening multiplies rows | Row count stated per encounter |
| raw:subject.reference | patient_key | Resolve through the patient crosswalk | Unresolved keys go to the exception table |
Data metric function results with an expectation, and actual lag against target.
| Table | Measure | Expectation | This run |
|---|---|---|---|
| curated.encounter | Null count on patient_key | 0 | 0, pass |
| curated.claim_line | Duplicate count on line key | 0 | 14, fail: release held |
| business.denials | Actual lag against target | Within target | Over target, shown on the report |
Features per Snowflake documentation, October 2026. A reference design.
| Stage | What it holds |
|---|---|
| Sources | FHIR NDJSON, HL7 v2, X12 837 and 835, CDC feeds and partner data. |
| Load | Stage and Snowpipe, Snowpipe Streaming and a CDC tool. |
| Schemas | Raw as VARIANT, curated and flattened, business as dynamic tables. |
| Semantic views | Logical tables, facts, dimensions and metrics. |
| Consumers | BI tools, Cortex Analyst, secure shares and ML forecasts. |
| Across it all | Business Critical and a BAA for PHI, masking, row access and classification. |
| Step | What happens | Why it matters |
|---|---|---|
| NDJSON files in a stage | One file set per resource type. | |
| Snowpipe into VARIANT | Raw resource, file name and load time. | The payload is kept as received. |
| LATERAL FLATTEN to curated | State the grain of each table. | One resource can give many rows. |
| Dynamic tables chain | Target lag, refreshed in order. | Lag can exceed the target, so monitor it. |
| Data metric functions | Measure, then set an expectation. | Out of range: alert the owner. |
| Semantic view | Reports and Cortex read it. |
| Layer | Objects | Role | Promote when |
|---|---|---|---|
| Raw (bronze) | VARIANT tables, Snowpipe | Pipeline roles only | Load recorded |
| Curated (silver) | Flattened and dynamic tables | Engineers, approved analysts | Grain stated, quality checks pass |
| Business (gold) | Dynamic tables, secure and semantic views | Analysts, BI tools, shares | Reconciled, signed off, masked |
Answer in this order. The first yes is the object to use.
| Question | If yes |
|---|---|
| Getting files into Snowflake? | Snowpipe |
| Rows pushed by an application? | Snowpipe Streaming |
| Can one query express the transformation? | Dynamic table |
| Procedural or conditional steps? | Streams and tasks |
| None of these? | Rethink the step, or run it outside Snowflake. |
| Area | What applies |
|---|---|
| Business Critical | PHI support and Tri-Secret Secure. BAA signed first. |
| Enterprise and up | Masking, row access, classification and data metric functions. |
| Classify | Find sensitive columns and review the results. |
| Tag and mask | A masking policy tied to a tag applies automatically. |
| Roles | Hierarchy by job, tested from a limited role. |
| Share | Secure views, minimum necessary, tested from the consumer side. |
| Where | What happens there |
|---|---|
| Your environment | Holds your source systems, data platform and PHI, under your platform and cloud BAAs, your roles, your masks and your audit logs. |
| During the assessment | We use schemas, data dictionaries and synthetic samples. We do not use PHI or production credentials. |
| During a build | We sign a BAA with you first. Access uses approved roles, is logged and is the least needed. You grant, review and revoke it. |
| The code | Code and tests use synthetic data and live in your repository. |
Explore the implementation decisions
Explore FHIR JSON, analytics models and governed sharing boundaries.
Compare warehouse and lakehouse approaches against the workload, operating team and data consumers.
Work through source dependencies, platform responsibilities and the path to a usable data product.
Primary documentation for the standards and platform features named on this page.
Snowflake editions: PHI support on Business Critical ↗Snowflake Secure Data Sharing ↗Snowpipe continuous loading ↗Snowflake semi-structured data (VARIANT) ↗Snowflake dynamic data masking ↗Snowflake row access policies ↗Snowflake dynamic tables ↗FHIR Bulk Data Access IG ($export and NDJSON) ↗Snowflake semantic views ↗Snowflake data quality and data metric functions ↗Snowflake ML forecasting ↗Snowflake sensitive data classification ↗Snowpipe Streaming ↗Snowflake streams and tasks ↗Before we begin
Snowflake supports PHI under HIPAA on Business Critical edition or higher, and a signed business associate agreement with Snowflake must be in place before any PHI is stored. Your own configuration, access policies and procedures complete the picture, which is the work we implement and document.
Yes. FHIR resources load as JSON into VARIANT columns, and views or tables flatten them for analytics. Snowflake is an analytics warehouse, so applications that need a live FHIR API use a FHIR server alongside it.
We land FHIR Bulk Data export files in cloud storage, load them with Snowpipe or COPY into VARIANT tables per resource type, then build typed models with LATERAL FLATTEN. Incremental runs use _since and resource versions so corrected resources replace earlier ones.
Secure Data Sharing gives another account live, read-only access to selected objects without copying data. PHI can be shared only for a permitted purpose with the right agreements and minimum-necessary secure views; many teams share de-identified data instead.
Snowflake suits SQL-first analytics, reporting and data sharing. Databricks suits large nested FHIR and HL7 volumes, streaming and ML. We recommend based on workload, team skills and existing investment, and many organizations run both.
Yes. We migrate in report groups with parallel runs against the legacy warehouse, reconcile the outputs and cut over each group when its owners accept the results.
There are two HIPAA routes. Safe Harbor removes the 18 identifier types, and it keeps no date element more specific than the year. Date shifting and linkage tokens need a review under Expert Determination, so we prepare the data and documentation for that expert. Masking policies protect identified columns in the source layers.
Ask which edition they assume for PHI, how they test masking from a limited role, how they handle a flattened resource that multiplies rows, and what they do when target lag is missed. We build dashboards when they serve an agreed decision, on top of governed semantic views.
Yes. The FHIR store serves applications through a live API and the warehouse serves analytics. We define the export, transformation and update behavior between them so each dataset has one source of truth.
The assessment takes 2 to 3 weeks. We do not quote a build schedule before it, because source access and sign-off owners set the pace and differ widely. The costed build plan gives the sequence and its dependencies, once those are known.
The Healthcare Data Platform Assessment is a fixed $3,500. It takes 2 to 3 weeks and is credited against the build. It ends with a costed build plan. The build depends on sources and formats, legacy report dependencies, undefined measures, the access model, sharing and freshness. Snowflake usage is billed by Snowflake.
Yes. We sign a business associate agreement with you when our work touches PHI, and we confirm the Snowflake edition and BAA before PHI is loaded.
Talk to our team
Tell us what you are planning, what exists today and what needs to change. We’ll review the context and discuss scope, dependencies and the next useful step.
hello@nirmitee.io →Explore Related Services
