Somewhere in your organization right now, there is a feature that clinicians asked for six months ago. The design is done. The engineers understand it. Everyone in the steering meeting agreed it mattered. And it is still not in production — not because anyone is slow, but because it has to pass a HIPAA review, talk to an EHR interface that behaves differently at every site, fit into a clinical workflow nobody can afford to disrupt, and leave an audit trail a compliance officer will sign.
Meanwhile, somewhere else in your organization, an AI pilot that impressed everyone in a demo is quietly stalling. The model is fine. What it can’t do is make sense of data scattered across the EHR, the scheduling system, the claims platform and a dozen departmental tools — or prove to a reviewer where its answer came from.
That’s the quiet tax of building software in healthcare. The code is rarely the hard part. Everything around the code is. And the organizations pulling ahead aren’t the ones with the cleverest models or the biggest budgets. They’re the ones with enough experienced engineering capacity to push through that tax, one workflow at a time.
The Wall Every Healthcare Team Eventually Hits
Demand for healthcare technology has never been stronger. Neither has the pressure to get it right.
| Signal | Number | Source |
|---|---|---|
| U.S. hospitals using predictive AI integrated with their EHR (2024) | 71%, up from 66% in 2023 | ASTP/ONC |
| System-affiliated vs. independent hospitals using it | 86% vs. 37% | ASTP/ONC |
| Physicians who want strong data privacy assurances before adopting AI | 86% | AMA, 2026 |
| Primary care physicians’ EHR time per 30-minute scheduled visit | 36.2 minutes | JAMA Network Open, 2024, via AMA |
| Individuals affected by large healthcare data breaches in 2024 | 242.9 million | HHS OCR, via HIPAA Journal |
| Average cost of a healthcare data breach (highest of any industry, 14th year running) | $7.42 million | IBM, 2025 |
Read those numbers together and a pattern appears. Hospitals with deep engineering benches — typically large, system-affiliated organizations — are adopting AI at more than twice the rate of independent ones. Clinicians are drowning in software that was supposed to help them. And the cost of getting security wrong is higher in healthcare than anywhere else.
Everyone else is being asked to deliver AI-enabled, well-integrated, secure experiences with a fraction of the people. That’s not a talent problem. It’s a capacity and experience problem.
Why Healthcare Engineering Takes Longer
Healthcare software isn’t harder because the code is exotic. Most of it is ordinary: APIs, databases, user interfaces, data pipelines. It’s harder because four constraints apply at the same time, on every release.
Protected health information changes everything
In most industries, security is a layer. In healthcare, it’s the foundation. Every data flow, log file, test environment, analytics query and AI prompt has to be designed around HIPAA from the first line of code. Test data has to be de-identified or synthetic. Logs can’t casually capture patient details. Third-party services need business associate agreements before anyone can call them.
Teams that treat privacy as a final review gate discover the problems late, when fixing them means rework. That’s how a two-week feature becomes a two-quarter feature.
Nothing lives alone
Healthcare products almost never stand on their own. They exchange data with EHRs, labs, pharmacies, payers, devices and health information exchanges — usually through HL7 v2 messages and FHIR APIs. On paper, these are standards. In practice, every implementation has its own quirks, custom fields and undocumented behavior.
An integration that works perfectly with one health system can fail at the next because of a local configuration choice made a decade ago. Engineers who have seen those patterns before can anticipate them. Engineers meeting them for the first time spend weeks in discovery.
Clinical workflows are unforgiving
Primary care physicians already spend more time in the EHR than the length of the visit itself. Any feature that adds clicks, screens or seconds to their day will be ignored, worked around or actively resisted — no matter how elegant the technology underneath.
That means healthcare engineering requires something most software teams skip: time with the people who will actually use it, in the context where they’ll use it. Design reviews with clinicians, shadowing workflows, testing in realistic conditions. It’s slower up front and dramatically faster overall.
Audits are part of the product
Healthcare organizations need to show who accessed what data, when, and why. With AI, the bar rises again: they need to show why a model said what it said, what data it used, and whether it was allowed to see that data in the first place.
Auditability can’t be retrofitted. It has to be designed into how data moves, how models are called and how outputs are stored. Systems built without it tend to get stuck at the compliance review — exactly where so many healthcare AI pilots quietly die.
“Won’t Hiring More Engineers Fix This?”
Eventually, yes. But hiring doesn’t solve the problem on the timeline most roadmaps require.
Senior engineers who already understand HIPAA, HL7, FHIR and clinical workflows are scarce, expensive and heavily recruited. Finding one can take months. Onboarding them into a regulated codebase takes more months. And general-purpose engineers, however talented, still have to learn healthcare’s constraints on the job — which is exactly where the delays come from.
There’s also a mismatch in shape. Many healthcare organizations don’t need a permanent team of forty. They need a focused, experienced team for a specific push: a new product module, an AI capability, an integration backlog, a platform modernization. When the push is done, the need changes.
That’s why more organizations are pairing their core team with embedded engineering partners who bring healthcare experience on day one — and who leave behind working software and documentation their own team can own.
Two Teams, Same Wall
We see two kinds of organizations hit this wall from opposite directions.
Healthtech companies
EHR vendors, digital health startups and health SaaS companies have a product roadmap that outruns their headcount. Their symptoms look like this:
- Customer-requested features wait quarters for engineering capacity
- Every new customer brings a new integration that pulls engineers off the roadmap
- AI features get announced, prototyped and then stuck in security review
- Senior engineers spend their time on compliance plumbing instead of product
- Competitors with bigger teams ship faster, and sales cycles get harder
For these companies, engineering velocity is the product. Every quarter of delay is a quarter a competitor spends shipping.
Health systems and payers
Hospitals, clinic groups and health plans aren’t selling software, but they’re building more of it than ever: AI assistants for clinicians, automation for revenue cycle and prior authorization, analytics for population health, internal tools for operations. Their symptoms look different:
- IT teams are fully consumed keeping core systems running
- Innovation lives in pilots that never reach production
- Departments buy point solutions that don’t talk to each other
- Staff experiment with consumer AI tools outside any governance
- Every new initiative waits in the same integration queue
Different starting points. Same bottleneck: not enough experienced engineering capacity pointed at the work that matters most.
Seven Ways Healthcare Builds Break in Production
If you’ve been through a few healthcare technology projects, some of these will look familiar:
- The integration that worked in test. Test environments use clean, predictable data. Production feeds carry decades of local conventions, missing fields and edge cases.
- The feature clinicians won’t use. It works, it’s compliant, and it adds 40 seconds per patient. Adoption flatlines.
- The privacy review that arrives too late. A data flow nobody questioned in design becomes a blocker the week before launch.
- The AI answer nobody can trace. A model gives a plausible response, and no one can show which record it came from or whether the user was allowed to see it.
- The pilot with no owner. The innovation team built it; operations never agreed to run it. It lives in a sandbox forever.
- The point solution that becomes a silo. A department buys a tool to solve today’s problem, creating tomorrow’s integration problem.
- The security gap nobody budgeted for. Monitoring, access controls and incident response get deferred — until an audit or a breach makes them urgent and expensive.
None of these are exotic failures. They’re the predictable result of building healthcare software without enough people who’ve done it before.
Where AI Stalls: It’s a Context Problem
Most healthcare organizations now have AI pilots. Far fewer have AI in production. As we wrote inYour AI Pilot Isn’t a Model Problem. It’s a Context Problem, models fail in production when they don’t understand what your data means.
In healthcare, that problem is sharper than almost anywhere else:
- The same word means different things. An “encounter” in the EHR, a “visit” in scheduling and a “claim” in billing may or may not describe the same event.
- Data lives in many systems. A single question about a patient population can require data from five platforms with five access models.
- Permissions matter as much as answers. An AI assistant that returns the right answer to the wrong person has created a privacy incident.
- Provenance is non-negotiable. Clinicians and compliance teams need to know where an answer came from before they’ll act on it.
The cost of ignoring this is rising. IBM’s 2025 research found that organizations with high levels of unsanctioned “shadow AI” paid $670,000 more per breach, and 97% of organizations that experienced AI-related breaches lacked proper AI access controls (IBM, 2025).
The fix is to build the context layer first: a governed map of what your data means, where it came from and who is allowed to see it. Once an AI agent has that map, its answers become traceable, permission-aware and auditable — the three things a healthcare compliance reviewer will ask about first.
The Trade-Offs Worth Naming
There’s no single right answer to how healthcare organizations should build. There are trade-offs, and the teams that move fastest are explicit about them.
Build versus partner
Building everything in-house gives maximum control and long-term ownership, at the cost of speed and hiring risk. Partnering gives speed and experience, at the risk of dependency. The middle path — an embedded partner that builds alongside your team, inside your environment, and hands over working code and documentation — captures most of both.
Speed versus compliance
This is usually framed as a tension. It doesn’t have to be. Compliance slows teams down when it arrives late. When privacy, security and auditability are designed in from the first sprint, they stop being a gate and become part of the architecture.
Custom versus platform
Custom-built systems fit your workflows exactly but carry maintenance costs forever. Off-the-shelf platforms are faster to start but rarely fit healthcare workflows cleanly. A containerized, open-source foundation that deploys in your environment lets you customize what matters without rebuilding the plumbing every time.
A Worked Example: The Referral Queue
Consider an illustrative scenario that plays out in many health systems.
A specialty department has a referral backlog. Referrals arrive by fax, EHR message and portal. Staff manually read each one, check insurance, look for missing information and route it to the right scheduler. Patients wait. Referring physicians call to ask what happened.
The tempting move is to buy an AI tool that reads referrals. The pilot works on a sample of clean documents. Then it meets production: handwritten notes, missing insurance data, inconsistent specialty codes, and a scheduling system the tool can’t write to. The pilot stalls.
The engineering-first approach looks different:
- Map the workflow and the data. Where do referrals arrive, what fields matter, which systems hold insurance and scheduling data, and who is allowed to see what?
- Build the context. Define what a “complete” referral means, reconcile specialty codes across systems and connect to the scheduling system through a governed integration.
- Automate the predictable part. Use AI to extract and validate referral details, flag what’s missing and route complete referrals automatically.
- Keep humans on the exceptions. Staff handle incomplete or unusual referrals, with the AI’s reasoning and sources visible.
- Measure and audit. Track turnaround time, error rates and access logs from day one.
The model is only one piece of that system. The value comes from the engineering around it.
What a Good Engineering Partner Actually Looks Like
If you’re considering outside help, the bar should be higher than “can write code.” Look for a partner that:
- Has built regulated healthcare products before, not just read about them
- Deploys inside your environment, so patient data never leaves your control
- Designs for compliance from sprint one, including access controls, audit logging and de-identified test data
- Understands clinical workflow, and builds time with clinicians into the plan
- Works as an embedded pod, alongside your team rather than as a black box
- Starts with a scoped pilot, with a clear deliverable and a baseline to measure against
- Leaves you stronger, with documentation, knowledge transfer and code your team can own
How NStarX Works With Healthcare Teams
NStarX is an AI engineering firm. We embed small, senior pods alongside your team and ship working software.
- We’ve built healthcare products before. Our engineering team played a pivotal role in building the cloud-native OneEHR platform, which was certified by HHS and remains a core offering within athenahealth. Read more about the evolution of EHRs.
- Your cloud, your data. Our containerized, open-source platform deploys inside your environment, with no vendor lock-in.
- Context before models. We map your systems and data definitions first, so AI outputs hold up to clinical and compliance review.
- Built for production. Security, observability and governance are part of the architecture from the start, not a later phase.
- Easy to engage. Through our strategic partnership with SHI International, many organizations can work with us under purchasing agreements they already have.
A Six-Week Pilot That Respects Your Calendar
The fastest way to find out whether a partner can help is to ship something real together.
Weeks 1–2: Discover
Pick one workflow that matters — a documentation bottleneck, a referral queue, a product feature stuck in the backlog, an AI use case waiting on security review. Map the systems, data, users and compliance requirements it touches. Agree on the baseline and on what success looks like.
Deliverable: a one-page scope with the workflow map, data sources, success metrics and risks.
Weeks 3–5: Build
Ship a working version inside your environment, with access controls, audit logging and monitoring in place from the first commit. Review it with the clinicians or users who will actually rely on it, and adjust.
Deliverable: a working system in a production-like environment, with security and audit controls live.
Week 6: Prove
Measure the result against the baseline from week one. Review it with operations, IT and compliance together. Decide with real data whether to scale it, change it or stop.
Deliverable: a results readout and a clear recommendation, plus documentation your team can own.
Ten Questions Before You Fund the Next Build
- Which single workflow would free the most clinician or engineer time if it shipped this quarter?
- Does the data it needs live in one system or five?
- Who signs off on privacy and security, and when do they get involved?
- How will you know it worked — what’s the baseline today?
- Do you have the people to build it without pausing something else?
- Who will own and run it after launch?
- Can every AI answer be traced to its source and checked against the user’s permissions?
- Have the clinicians or staff who will use it seen a prototype?
- What happens to patient data in test environments and logs?
- If it works, what would it take to scale to the next department or site?
If more than three of those don’t have a clear answer, the project isn’t ready to fund yet. That’s useful to know before the budget is spent.
The Unglamorous Truth
Healthcare doesn’t need more pilots. It needs more things in production: features clinicians use, automation that gives staff time back, AI answers that survive an audit, and integrations that work at the next site as well as the first.
Getting there isn’t about a better model or a bigger team. It’s about experienced engineers who know where the traps are, working inside your environment, designing for privacy and auditability from the start, and shipping one workflow at a time. That’s not glamorous. It’s how healthcare software actually gets built.
Have Questions?
We’re here to help. Whether you’re building a healthcare product or bringing AI into your health system, our team is ready to talk through your roadmap. Get in Touch