The problem
Clinical, claims and billing records live in separate systems with separate rules. Each team pulls its own extract, applies its own logic and reports its own number. When leaders ask why the numbers differ, nobody can answer quickly.
Healthcare Data Warehouse
Healthcare Data Warehouse Services
When two reports give two answers, your leaders stop trusting both. A healthcare data warehouse gives clinical, claims and operational reporting one set of definitions, so the same question gets the same answer. You see the plan and the cost for a fixed fee before you commit to a build.
Request the data platform assessmentFor analytics leaders, data teams and healthtech product owners.
At a glanceFor decision makers
- 01The problem
Two teams ask the same question, get different answers, and nobody can say which is right.
- 02The outcome
Reports that use one set of definitions and can be traced back to the source.
- 03How risk is controlled
Each load is checked first. If a check fails, reports keep the last good data.
- 04What it costs
$3,500 fixed for the assessment. 2 to 3 weeks, credited against the build.
- 05The next step
Request the assessment and get a costed plan you can use with any vendor.
The business case
What Disagreeing Reports Cost You
A warehouse is worth buying when people need the same number from systems that were never designed to agree.
What it costs you
- Board and payer conversations rest on numbers people quietly doubt.
- Skilled staff spend their week reconciling reports before anyone can act on them.
- Reports break when a source system changes, and people find out from the report.
- A warehouse built on every source at once delays the first useful answer.
What you get
- One definition and one named owner for the numbers that matter most.
- A reported number can be traced to the records behind it, wherever lineage is captured.
- Reports that keep the last good data when a load fails.
- Your code, your accounts and a team trained to run it.
The short answer
What Is a Healthcare Data Warehouse?
A healthcare data warehouse is a governed database built for reporting and analytics. It brings together data from the EHR, HL7 v2 feeds, FHIR exports and X12 claims, keeps its history, and applies one set of definitions. We build it around the questions your team needs answered, test the models and reconcile each load to its source, so a reported number can be traced back to its source rows.
- Who it is for
- Provider groups, payers and healthtech teams whose reports disagree or whose current warehouse is hard to change.
- What you get
- Reconciled loads, documented models, access rules and a runbook, all in your own cloud account and repository.
- Where to start
- One question that matters, with an owner who can approve the definition.
Our view
Start with a Warehouse Unless a Workload Proves Otherwise
This is our judgment for most provider, payer and healthtech reporting programs. The choice of platform matters less than most vendor comparisons suggest. These are our reasons.
Most report conflicts are definition conflicts
When two teams disagree on a readmission count, a faster engine will not settle it. A written grain and a named owner will, and a warehouse forces that work early.
If you run Epic, use what Epic already gives you
Rebuilding clinical models that your Epic reporting tools already hold is costly and hard to keep current. Add the claims, partner and other non-Epic data those tools leave out.
Keep raw history from the first day
Modeling rules change. If the original messages and files are kept, you can rebuild a model. If they are gone, the old error stays in your reports for good.
Build one question end to end before the next
A complete model of every source sounds thorough, but it delays the first trusted number and hides mistakes until they are expensive. One owned measure tests the whole path.
Make a failed check stop the load
A warning that nobody reads teaches people to distrust the warehouse. Reports should keep the last good data until the problem is fixed and replayed.
We would choose a lakehouse first when machine learning or large nested FHIR and HL7 volumes are the main workload and you have the engineers to run it. If you need one patient's record at the point of care, a clinical data repository or FHIR store is the better fit, and it can feed the warehouse later.
For the person signing off
What to Know Before You Hire Anyone for This
The questions we expect from a CIO, CTO or head of data, with our answers.
| Risk | How we control it |
|---|---|
| Numbers that do not match the source | Reconcile each load to its source. A failed check stops publication. |
| PHI reaching people who should not see it | Access by layer and role, masking, de-identified views and scheduled access reviews. |
| A vendor-dependent warehouse | Code in your repository, written definitions, a runbook and a handover your team rehearses. |
| Platform cost that surprises finance | Workload monitoring and refresh schedules set by real need, reviewed with your team. |
| Scope that grows until nothing ships | One question at a time, each with acceptance checks and a named owner. |
| Upstream changes breaking reports | Source contracts, format checks and alerts to the source owner, with replay from raw history. |
Governance and PHI handling
- We sign a BAA before our work touches PHI
- Design and testing start with synthetic or de-identified data
- PHI stays in your cloud account and platform
- Your security team approves roles and masking
- Nirmitee is ISO 27001:2022 certified
Who owns the code and data
- Once paid, you own the custom code, models, mappings and runbooks we write for you, and all of your data
- We keep our reusable tools and open-source parts
- The platform contract and BAA stay between you and the vendor
What the team looks like
- From us: a technical lead and data engineers sized to the plan
- From you: a data owner, a clinical or finance reviewer and a security contact
- The costed plan names the roles before you commit to a build
What you receive
- Load and model code in your repository
- Tests and reconciliation reports
- Definitions with named owners
- Access matrix and runbook
How to Judge a Vendor, Including Us
- Ask them to explain one number from report back to source row. Can they show how?
- Ask what happens when a reconciliation check fails. Does the load stop?
- Ask who owns the code and how handover is tested.
- Ask for their certifications in writing, and check what each one covers.
- Ask what they would leave out of the first release, and why.
A focused first engagement
Healthcare Data Platform Assessment: $3,500 Fixed
To start, bring your source list, the current reports and a number people disagree about. No PHI is needed. You get a plan you can act on with us, with another vendor or with your own team. It takes 2 to 3 weeks, and the fee is credited against the build.
Request the data platform assessment →Assessment Deliverables
- Source inventory
- Target architecture
- Data model outline
- Risk list
- Costed build plan
Not Included
- Building or running the warehouse
- Loading PHI or production data
- Platform licenses and usage charges
- Epic licensing or Clarity data model access
- Legal, compliance or security certification review
Delivery in reviewed stages
Agree the Evidence Before Expanding the Scope.
Timing and pricing depend on source access, environment readiness and the agreed acceptance checks. Each stage ends with a reviewable output.
- 01
Assess
Agree the first question, list the sources and check access, quality and platform fit.
You review: Source inventory, definitions and a phased plan
- 02
Load
Load raw history and incremental changes, keeping source and load time on each record.
You review: Load code and a reconciliation report
- 03
Model
Build reviewed patient, encounter, claim and measure models with tests and written definitions.
You review: Documented models and test results
- 04
Hand over
Set access roles, connect the first reports, add monitoring and train your team.
You review: Runbook, access matrix and named owners
Evidence you can check
- ISO 27001:2022 certified
- HIPAA safeguards built in; we sign BAAs
- Our team has built 350+ interfaces on Mirth Connect
- Open-source X12 clearinghouse simulator: 270/271, 278, 837, 999/277CA, 835, 276/277
- 20 open-source healthcare repositories on GitHub
Related delivery
Multi-source Data Integration for Governed AI
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 →
For your engineers
The Technical Detail
What the warehouse holds, how it compares with a lake or lakehouse, which sources it loads and how each load is checked.
What we build and connectSources, ingestion and who owns what
What it holds
What a Healthcare Data Warehouse Holds
A warehouse stores the records your reports depend on, with the history and source of each one. Most start with a few of these areas and add more over time.
Patients and encounters
Patient identity across systems, visits, admissions, transfers and discharges, with a written rule for what counts as one encounter.
Bulk FHIR export from major EHRsDiagnoses, medications and results
Problems, orders, medications and lab results, kept with their original codes and mapped to standards such as ICD-10, RxNorm and LOINC.
OMOP vs FHIR for clinical analyticsClaims and remittance
X12 837 claims and 835 payments split into claim, line and adjustment tables, with CARC and RARC codes kept for denial reporting.
X12 EDI integration servicesMembers and coverage
Enrollment from X12 834 files, plan and coverage periods, so claims and care can be counted against the right population.
Healthcare data quality before analyticsOperational data
Scheduling, capacity and billing activity, joined to encounters so operations and finance use the same counts.
CDC for healthcare data warehousesHistory and lineage
Earlier versions of corrected records, the source of each row and its load time, so a past report can be explained.
Governance, lineage and PHI accessSources
Sources We Load into a Healthcare Data Warehouse
Each source has its own format and access path. We confirm both for your environment before scoping the load.
Epic Clarity
Clarity is the relational database Epic documents for reporting. Your organization grants access, and any licensing of the Clarity data model goes through Epic.
Epic Caboodle
Vanderbilt University Medical Center describes Caboodle as a warehouse for report writing that holds most of Clarity's data and links to non-Epic sources. We confirm contents and refresh timing on your instance.
HL7 v2 feeds
HL7 v2 messages such as ADT and ORU carry events between clinical systems. We parse them into tables and keep the original message for replay.
FHIR Bulk Data
The $export operation returns NDJSON files for a whole system, all patients or a group. The _since parameter limits a run to resources changed after a given time.
X12 claims
X12 837 claims, 835 payments and 834 enrollment files load into claim, line, adjustment and member tables.
Other databases and files
Billing, scheduling and partner data arrive through change data capture or scheduled files, with the same reconciliation checks.
Platform choice and data layersOptions compared, layers and the data model
Compare your options
Healthcare Data Warehouse vs Data Lake vs Lakehouse vs Clinical Data Repository
These four solve different problems, and many organizations run more than one. Choose by who uses the data and how they use it.
| Option | What it is | Data shape | Best for | Plan for |
|---|---|---|---|---|
| Data warehouse | Modeled tables with agreed definitions | Structured | Reporting, quality measures and finance | Definition work before new data is usable |
| Data lake | Low-cost storage of files as received | Any, including notes, images and raw messages | Keeping raw history and data science work | Governance, so it stays searchable and access stays controlled |
| Data lakehouse | Warehouse-style tables and governance on lake storage | Any, with modeled layers on top | One platform for reporting, large FHIR or HL7 volumes and machine learning | Engineering skills to run layers and table upkeep |
| Clinical data repository | A patient-level store of clinical records | Clinical records | Looking up one patient, often for care or exchange | A separate analytics path, since it usually is not built for population reporting |
Healthcare data lake
A lake keeps data in its original form, which suits raw HL7 messages, FHIR NDJSON, notes and images. It is a good place to keep history, but people still need reviewed tables before they report from it.
Healthcare data lakehouse
A lakehouse combines the benefits of lakes and warehouses on one platform. It fits when the same data serves reporting and machine learning, and when your team can run a platform such as Databricks.
A warehouse can load from a lake or lakehouse, and a clinical data repository can be one of its sources.
Engineering scope and early decisionsWhat we work on and what to settle before the first table
Engineering scope
Source mapping
List each source, its owner, its refresh schedule and what one row means.
Loads and reconciliation
Build full and incremental loads, then compare each load with the source and explain the differences.
Reviewed data models
Build patient, encounter, claim and measure models with tests and written definitions, reviewed by your owners.
Access and handover
Set roles and PHI rules, add monitoring, and hand over how to run and fix each load.
Decide these before the first table is built.
What one row means
Write down the grain of each model and how joins change counts. Most conflicting reports start here.
Patient identity
Decide how records from different systems are matched, who reviews uncertain matches and how a later correction flows through.
Corrections and history
Decide how corrected results, reversed claims and changed codes affect past reports.
Who can see PHI
Name the sensitive fields, the roles that can read them and the de-identified views for everyone else.
Architecture, flows and ownershipThe design written out, step by step
Healthcare Data Warehouse Architecture
Which source enters how, and where each team reads from.
| Source | Load | Detail |
|---|---|---|
| Epic Clarity and Caboodle | Extract jobs | SQL extract with watermarks |
| HL7 v2 feeds | Message parser | ADT and ORU, keeping the original message |
| FHIR Bulk Data | Export client | $export to NDJSON, with _since runs |
| X12 files | EDI parser | 837, 835 and 834 into claim, line and CAS |
| Billing and scheduling databases | CDC connector | Ordered changes |
All sources land in raw history as received, move to conformed models with codes and identity, then to reporting marts with measures and owners. Consumers are BI and reports, quality measures, finance and denials, de-identified shares and scoped AI workflows. Across every layer: roles and PHI masking, lineage, reconciliation, tests, monitoring and named owners.
Layers of a Healthcare Data Warehouse
Few people read raw data. More can read each reviewed layer.
| Layer | What it holds | Example content | Who reads it |
|---|---|---|---|
| Raw history | Exactly as received. Never edited, so any load can be replayed. | HL7 messages, NDJSON, X12 files, Clarity extracts | Engineers only |
| Conformed | One patient and encounter identity. Codes mapped, originals kept. | Patient match, LOINC, RxNorm, ICD-10, CARC, RARC | Engineers and data stewards |
| Core models | Each table has a written grain: what one row means. | Patient, encounter, result, claim line, member month | Analysts, by role |
| Reporting marts | Measures with a definition and a named owner. | Readmissions, denial rate, capacity, de-identified views | Report users and partners |
Warehouse, Lake, Lakehouse or Repository?
Ask who uses the data and how, in this order. The first yes is usually your starting point.
| Question | If yes | Note |
|---|---|---|
| Point of care lookup? | Clinical data repository or FHIR store | Often sits beside a warehouse and feeds it. |
| Mostly SQL reporting? | Data warehouse | Our default. If you run Epic, start from Clarity or Caboodle. |
| Machine learning or large nested data? | Data lakehouse | Needs a team that can run the platform. |
| Raw data only? | Data lake | Add reviewed tables before anyone reports from it. |
| None of these? | Write down the first question, then decide |
How One Load Reaches a Report
Three checks stand between a source and a report, and each one can stop the load.
| Step | What happens | If it fails |
|---|---|---|
| Arrival | A new file, message or change lands in raw history with its source and load time. | |
| Format check | Is the format valid? | Quarantine the batch and alert the source owner. |
| Source check | Compare counts and totals with the source against the rule. | Stop here. Reports keep the last good data. |
| Model tests | Build models and run tests. | Stop here. The owner sees the failed test. |
| Publish | Publish to reports and keep the check result. | |
| Recovery | Fix, then replay from raw history. |
Tracing One Report Number Back to Its Source
An illustrative example with no real data. Read upward to see how a number is built, and trace downward to answer a question about it.
| Level | Example | What it records |
|---|---|---|
| Report | Denied claim lines this month | Owner: revenue cycle lead. Definition written and approved. |
| Reporting mart | denial_summary | Groups claim lines by month, payer and CARC code. |
| Core model | claim_line | One row is one service line on one claim. |
| Conformed | Payment matched to claim | CARC and RARC codes kept as received. |
| Raw history | 835 file, CAS segment | Source file name and load time kept. Never edited. |
Who Owns What on a Data Warehouse
You keep the decisions and the data. Each stage has one owner per task.
| Stage | Your data owners | Your security team | Nirmitee engineers | Platform vendor |
|---|---|---|---|---|
| Assess | Name the first question and owner | Set PHI and residency rules | Inventory sources, draft the plan | Confirm edition and BAA terms |
| Load | Grant source access | Approve roles and BAAs | Build loads and reconciliation | Run the platform service |
| Model | Approve each definition | Review masking and de-identified views | Build models and tests | Provide masking and audit features |
| Run | Own measures and priorities | Review access on a schedule | Hand over runbook and code | Bill usage, maintain the service |
Guides and referencesFurther reading and vendor documentation
Explore the implementation decisions
Guides for the Work Ahead.
Choosing a healthcare data architecture
Compare warehouse and lakehouse approaches against the workload, operating team and data consumers.
Building a healthcare data lakehouse
See how FHIR and EHR data move through a lakehouse on Databricks.
A clinical data warehouse on Snowflake
Model FHIR JSON for analytics and set governed sharing boundaries.
From data to an AI workflow
Give AI Features Data Your Team Already Trusts.
An AI feature depends on the same joins, definitions and access rules as your reports. Once a warehouse model is reviewed, it can feed one scoped AI workflow.
Healthcare AI development and integration →Healthcare AI agent development →Define the Next Delivery Boundary
- Trace each input to its source and load time
- Apply access rules before data reaches the model
- Agree how answers are checked and who reviews them
Standards and platform references
Primary documentation for the standards and platform features named on this page.
open.epic technical specifications: Clarity and Kit ↗Vanderbilt University Medical Center: Clarity and Caboodle data resources ↗HL7 Version 2 product suite ↗FHIR Bulk Data Access IG ($export and NDJSON) ↗X12 transaction sets, including 837, 835 and 834 ↗Snowflake editions: PHI support on Business Critical ↗Databricks HIPAA and the compliance security profile ↗Databricks: what is a data lakehouse ↗Before we begin
Healthcare Data Warehouse Questions Buyers Ask
What is a healthcare data warehouse?
It is a governed database built for healthcare reporting and analytics. It combines clinical, claims and operational data, keeps history and applies one set of definitions, so teams get the same answer to the same question.
What data goes into a healthcare data warehouse?
Usually patients and encounters, diagnoses, medications, lab results, claims, remittance, enrollment and operational data. Most organizations start with the sources needed for one question and add others over time.
What is the difference between a data warehouse and a data lake in healthcare?
A warehouse holds modeled tables with agreed definitions, which suits reporting. A lake stores files as received, including notes, images and raw messages, which suits raw history and data science.
What is a healthcare data lakehouse, and do we need one?
A lakehouse combines the benefits of lakes and warehouses on one platform. It fits when the same data serves reporting and machine learning. If your need is mainly SQL reporting, a warehouse is often the simpler choice.
How is a warehouse different from a clinical data repository?
A clinical data repository holds patient-level records, often for lookup during care or for exchange. A warehouse is built to count and compare across populations. A repository can feed a warehouse.
Can you load data from Epic Clarity and Caboodle?
Yes, when your organization grants access. We map the tables your questions need, reconcile the loads and join them to non-Epic sources. We confirm the contents and refresh timing on your instance first.
Should we build on Snowflake or Databricks?
Snowflake suits SQL-first reporting and data sharing. Databricks suits large nested FHIR and HL7 volumes, streaming and machine learning. We recommend based on your workload, team skills and existing contracts.
Is a healthcare data warehouse HIPAA compliant?
Compliance depends on your contracts, configuration and procedures. Snowflake supports PHI on Business Critical or higher with a signed BAA. Databricks requires the compliance security profile and an active BAA. We confirm these before PHI is loaded.
How do you check that the data is right?
We compare each load with its source, test the models and have your owners review the definitions. Differences are explained and recorded. A failed check stops the load, though checks catch only the failures they are written to detect, so we review them with your owners.
How long does a healthcare data warehouse take to build?
It depends on the number of sources, how quickly access is granted and how many definitions need agreement. We give a build schedule at the end of the assessment, when those are known.
What does a healthcare data warehouse cost?
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 cost depends on the sources and formats, history and volume, how fresh the data must be, the access model and any reports that must move from an old warehouse. Platform usage is billed by the vendor.
Do you sign a BAA?
Yes. We sign a business associate agreement when our work touches PHI. Nirmitee is ISO 27001:2022 certified, and we start design and testing with synthetic or de-identified data.
Talk to our team
Request the data platform assessment
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 →Thank you. Your inquiry has been received. Our team will review your requirements.
Explore Related Services