Build, Buy or Hire a Healthcare Data Platform: A CIO Decision Guide
CTO & Co-Founder
CTO & Co-Founder at Nirmitee.io. Architects healthcare integrations across FHIR, SMART on FHIR, ABDM and NHCX, writing from production experience taking hospital software from sandbox to go-live.

Updated October 2026
Most health systems should buy regulated and standard reporting, keep definitions and acceptance tests in-house, and build only the logic that is theirs. Hire a partner when you need capacity for a fixed period and have people ready to take over. Build a full platform only if you can fund a team to run it for years.
This guide is for CIOs, CTOs and heads of data with budget at risk. We sell partner work, so read it with care: our own worked example favors buying, and we list when you should not hire us. Our fixed $3,500 Healthcare Data Platform Assessment gives you the inputs for this decision, and our healthcare data engineering services page covers the build work.
What do build, buy and hire really mean for a healthcare data platform?
Build means your employees run the platform on general cloud services. Buy means a healthcare analytics vendor runs much of it for you. Hire means a partner builds on your cloud account and hands it over. These labels hide the main point: the platform has layers, and each one can have a different answer.
| Build | Buy | Hire | |
|---|---|---|---|
| Who runs it day to day | Your team | Vendor, with your staff | Partner at first, then your team |
| Where data sits | Your cloud | Ask. It varies by vendor | Your cloud, if you require it |
| Who owns the logic | You | Often the vendor. Check the contract | Set in the contract |
| Main strength | Control and fit | Speed on standard needs | Capacity and skills for a set period |
| Main weakness | Hiring and keeping a team | Lock-in, and fit beyond standard needs | Failed handover |
| Honest test | Can you fund it for years? | Can you leave? | Who takes over, by name? |
What does the public evidence say?
The evidence is thin, and most of it comes from people selling something. We looked for a neutral study comparing outcomes across these three options for healthcare data platforms and did not find one.
- Penn LDI summarizes a case report from Penn Medicine leaders saying they buy about 90% of their technology while still building some tools. It covers health technology in general, and one institution.
- Health Catalyst argues that build-your-own usually falls short, citing healthcare data handling, integration costs, governance and AI skills. It sells the alternative, and the page text we read gives no checkable cost figures.
- In our own review of 98 healthcare data company pages in late October 2026, 2 covered build versus buy and 6 mentioned a price or cost range. The market leaves buyers short of numbers.
So our recommendation is reasoned judgment, and nobody has measured it. A published comparison of total cost and time to a trusted number would settle much of it, and your own proof slice can settle it for you.
How should a CIO decide between build, buy and hire?
Settle three gates, then decide by how standard your needs are and who can run the result. If the gates are not settled, no option will work, however well it scores.
| Choose | When these are true | Do not choose when |
|---|---|---|
| Buy | Standard reporting is most of the need. You lack engineers. A vendor covers your EHR and payer mix | Exit terms are poor, or your questions sit outside its model |
| Build | Data logic sets you apart, or the data is your product. You already run production data systems and can staff on-call | The plan depends on hires you have not made |
| Hire | You need skills or capacity for a defined period, you have owners, and someone will take over | Nobody on your side can review the work or inherit it |
| Mix | Different layers point different ways, which is common | Nobody owns how the parts fit together |
What team does each option need?
Every option leaves you with owners, reviewers and an EHR reporting expert, so buying and hiring remove fewer seats than proposals tend to imply. Budget for your own people's time in all three. Epic data is a good example, as our Epic Clarity and Caboodle guide shows: access and training rest with the health system.
If you are a health tech CTO
The answer shifts toward building, because customer-facing data features are part of your product. Buy tools for the lower layers and own what customers see. Check whether a platform's terms allow you to resell or embed it, and whether each customer's EHR agreement allows the data route you plan.
What does an in-house team cost?
A five-person team costs about $918,000 a year at national median pay, before recruiting, tools or cloud. This is arithmetic for sizing the question. Team size is our judgment, since we think fewer people struggle to cover on-call and absences.
| Role | Stand-in used for pay | Median pay, May 2025 |
|---|---|---|
| Data architect | BLS database architects | $139,500 |
| Data engineer, 2 people | BLS database administrators and architects, combined | $126,760 each |
| Analytics engineer | BLS data scientists | $120,230 |
| Security and platform engineer | BLS information security analysts | $129,180 |
| Total wages | $642,430 | |
| With benefits | Wages are 70.0% of private industry pay cost, June 2026 | About $918,000 |
BLS has no data engineer category, so those rows are stand-ins. Medians are national and not specific to healthcare, and experienced Epic data people in a major city may cost more. Over three years with no raises, the total is about $2.75 million.
What drives the cost of a healthcare data platform?
Scope, inherited constraints and run costs drive the bill, and the number of sources usually matters more than the choice of warehouse. That ranking is our judgment. Few published numbers exist, and nearly none can be compared.
The one public price table we found comes from a vendor. Treat it as one firm's marketing estimate for build work.
| Scope, per Innowise | Timeline | Build cost | Monthly cloud and software |
|---|---|---|---|
| Department mart, 1 to 2 sources | 2 to 4 months | $60k to $100k | $1k to $5k |
| Mid-sized warehouse, 3 to 6 sources | 5 to 9 months | $150k to $350k | $5k to $20k |
| Enterprise warehouse or lakehouse, 7+ sources | 9 to 18+ months | $400k to $1m+ | $20k to $80k+ |
Read as of 31 October 2026. We have not checked those figures against real projects, and they exclude your staff time. We could not find public list prices for healthcare analytics platforms, so get quotes. Four costs get left out of proposals most often, in our judgment:
- PHI-ready platform tiers. Snowflake requires Business Critical edition and a signed BAA for PHI. Azure Databricks requires its compliance security profile on each workspace handling PHI. Price those settings, not the entry tier.
- Source access. Vendor fees, approvals and your EHR team's time. Ask each source owner.
- Reconciliation. Proving numbers match the source is often the last thing scoped. See why integrated data can be worse than siloed.
- Exit. Exporting data is one line. Rebuilding logic and retraining people is the real cost.
Compare options on one three-year grid: your staff, outside fees, licenses, cloud, source access, security review and exit. Use the same scope in every column, and ask each vendor to fill it in.
What are the risks of each option?
Each option fails in its own way, and you can test for most of these failures before signing. Breaches are a shared risk: IBM's 2026 report puts the global average cost at $4.99 million. That is a study average across industries and does not predict your cost.
| Option | Main risks | Test before you commit |
|---|---|---|
| Build | Key people leave. Hiring runs late. A platform team drifts from business needs | Name who is already hired. Ask what happens if two of them leave |
| Buy | Lock-in. Local logic does not fit. Costs rise at renewal. Subprocessors handle PHI | Run an exit test on sample data. Ask who else touches PHI. Read renewal terms |
| Hire | Failed handover. Knowledge leaves. Team changes after the sale. Reviewers on your side are too thin | Name your successor team. Meet the delivery team. Make handover an acceptance item |
| Any | Definitions stay unowned. Wrong numbers look right. Source access arrives late | Name owners first. Require rerunnable reconciliation |
How do you score the options? A sheet you can copy
Score each option 1 to 5 on seven factors, multiply by the weights and compare totals, after the gates are passed. The weights are our judgment, not a validated model, so change them openly before you see the totals. Have people score separately first, because the disagreements usually tell you more than the total.
Gates, all required: a PHI path your security team can approve, written access from each main source owner, and a named business owner for the first measures.
The example is illustrative: a health system with one Epic instance, a few engineers, and a mix of quality reporting and local logic.
| Factor | Weight | Build | Buy | Hire |
|---|---|---|---|---|
| Fit with regulated and standard reporting | 15 | 2 | 5 | 3 |
| Fit with your custom logic | 15 | 5 | 2 | 4 |
| Talent to run it for years | 20 | 2 | 4 | 3 |
| Time to first trusted number | 15 | 1 | 5 | 3 |
| Exit and portability | 10 | 5 | 2 | 4 |
| Three-year cost on your quotes | 15 | 3 | 3 | 3 |
| Security review path | 10 | 4 | 4 | 3 |
| Weighted total, out of 500 | 100 | 295 | 365 | 325 |
Multiply each score by its weight and add up. In this example, Buy leads Hire by 11.0%. Our rule of thumb: a lead of 10% or more points to that option, and anything smaller is too close, so run a proof slice with the top two. We chose 10% because scores are opinions and small gaps mean little. It has not been tested, so change it if your team prefers. A strong in-house team would change this result: moving Build's talent score from 2 to 5 adds 60 points, which puts it at 355, close to Buy.
If hire wins, write the handover below into the contract. Failed handover is the main risk of that option.
A proof slice is one data domain, built on your data and judged by your tests, with results and exit steps written down. Make any paid pilot prove reconciliation and exit, since a demo dashboard proves little.
When should you not hire Nirmitee?
Do not hire us if a packaged platform already meets your needs, or if you cannot name who takes over. There are several other cases where we are the wrong choice:
- You need standard quality and payer reporting, soon. Buy a product built for it.
- You want someone to run the platform for years, as a managed product. Choose a vendor set up for that.
- You require a named production reference for this exact work on your EHR. Ask us, and if what we can show does not satisfy you, choose a firm that can. We would make the same request of anyone.
- Your Epic agreement or policy keeps outside firms from the data. A team on your staff, or Epic-side services, may be your only route.
- Your own data team is strong and only needs time. Hire people directly.
- No one owns the definitions. Fix that first, since no vendor can do it for you.
Who should own the decision and the platform?
The CIO and CFO should own the choice, and business owners should own what each number means, under all three options. Governance does not move to a vendor with the contract.
How to decide who should build your healthcare data platform
Hire the team that can show you its controls before it shows you its tools. The six questions below are the ones we would ask in your seat. The answers describe what we would put in your plan, so hold us to them in writing.
Risks and how we control them
| Risk | What it costs you | Control we put in the plan |
|---|---|---|
| Choosing before gates are settled | Paid work stops at access or privacy review | Gate answers in writing before anyone prices the work |
| Costs compared on different scopes | A false winner | One three-year grid and one scope for all options |
| Handover fails | You stay dependent, or the platform decays | Named successors, shared on-call before exit, and a rehearsal of recovery by your team |
| Numbers cannot be proved | Leaders stop trusting the platform | Reconciliation reports you can rerun, as an acceptance item |
| Lock-in discovered at renewal | A weak negotiating position | Exit test on sample data before signing |
Governance and PHI handling
PHI stays in environments your security team approves, under the right BAAs with each party that touches it. Discovery and test design start with synthetic or de-identified examples. Access to production data comes later, in approved environments, under a signed BAA. Nirmitee is ISO 27001:2022 certified, which covers how we run our security management. It does not make your platform compliant, so your privacy and security leads still review the design.
Who owns the code and the data
Your data stays yours, and our design keeps it in accounts your organization controls. Ownership of code written during the work is set in the contract before anything is built, so ask to read that clause in the first week. Make sure the clause gives your team the right to use and maintain what it takes forward: the data contracts and mappings, the pipeline and quality tests, the replay and recovery procedures, and the freshness monitoring.
What the team looks like
For partner work, expect a data architect, data engineers, an analytics engineer and QA, each met by name before signing. Epic or other source expertise must be named too, whether it comes from your staff or the partner. Your side supplies a business owner for each published number, a source system owner for each feed, and a privacy or compliance reviewer. A project without those three people on your side will stall, whoever you hire.
What you receive
A build engagement should leave you with running pipelines in your environment, documented grain and definitions, reconciliation reports you can rerun, a runbook, and a handover walkthrough with the people who will operate the platform. Write these into the acceptance criteria.
How to judge a vendor
- Ask what they would advise if they could not sell you anything.
- Ask who has run what they propose, and speak to that person.
- Ask to see a sample deliverable, with client details removed.
- Ask for a written exit plan, covering data, logic and people.
- Ask for the three-year cost on your grid, with your staff time included.
Healthcare Data Platform Assessment: $3,500, fixed
The Healthcare Data Platform Assessment costs a fixed $3,500 and gives you a build plan you can take to any vendor, including us. It suits a team that wants this decision written down before committing. We sell build work, so challenge anything that favors us. It gives you the inputs for the scoring sheet and the three-year grid, and the plan works whichever option you choose.
- Source inventory: every source, its owner, access route, refresh behavior and known gaps.
- Target architecture: layers, platform recommendation and the tradeoffs behind it.
- Data model outline: core entities, grain and the definitions that need an owner.
- Risk list: technical, vendor, privacy and operating risks, ranked.
- Costed build plan: phases, acceptance checks and an engineering estimate.
Not included: building pipelines, production PHI access, vendor license or API fees, vendor approvals, legal review and ongoing support. Ask for a Healthcare Data Platform Assessment and bring one decision the data must support.
For the technical side of the choice, compare warehouse, lake and lakehouse designs, read our data and platform engineering guide, or see healthcare data warehouse services and data pipeline services.
Ready to scale?
Talk to our healthcare engineering team about building, integrating, and shipping faster.
Frequently Asked Questions
Should a health system build or buy a data platform?
How much does a healthcare data platform cost?
How many people does an in-house team need?
When should we hire a partner?
Can we leave a platform vendor later?
What stays with us whichever option we choose?


