Most digital health builds do not fail on the clever part. They fail on a date field, an unsigned Business Associate Agreement, and an HL7 v2 feed that someone on the kickoff call described as "basically a webhook." (It is not basically a webhook. It is a pipe-delimited message from a different era, and it has opinions.)
So this page compares the realistic ways to get a regulated health product built: hiring in-house, a generalist agency, staff augmentation, a healthcare-software engineering company, building inside an EHR vendor's app ecosystem, and a large consultancy. Same criteria for each. No vendor adjectives.
We are a healthcare-software engineering company, so we are one of the options on the table. We will say where the others win.
The short answer
Pick the model that matches your hardest constraint.
If the hardest constraint is clinical access to data, you need interoperability depth before you need design polish. If the hardest constraint is a funding or pilot deadline, you need a delivery team that has already shipped an audit trail and does not have to invent one. If the hardest constraint is long-term cost per engineer, in-house wins eventually, and "eventually" is the word doing the work in that sentence.
Our position, stated plainly: a healthcare-focused engineering partner is the right call when you have a live workflow, one or more integration targets, and a date. An in-house team is the right call when the product is your entire company and you can afford twelve months of hiring before the first release.
Six Ways To Build A Digital Health Product, Compared
| Option | Who carries HIPAA and audit evidence | HL7 v2 / FHIR depth assumed | Ramp before first useful release | Cost shape | Breaks down when |
|---|---|---|---|---|---|
| In-house team you hire | You, fully. Policies, BAAs, access reviews, training records | Whatever you hire for. Senior interop engineers are hard to source | Longest. Recruiting plus onboarding plus first architecture decisions | Fixed payroll, rises with headcount | You need a release before the hiring pipeline closes |
| Generalist software agency | Split and often unclear. They code, you own the regulatory posture | Rarely assumed. Usually learned on your budget | Fast to start, slow to get compliance right | Project or retainer | The first ADT feed, consent model, or OCR question arrives |
| Staff augmentation | You. Contractors execute your decisions | Per-CV, not per-team. Varies by person | Medium. Depends on your own architect's bandwidth | Hourly per person | Nobody on your side owns the architecture end to end |
| Healthcare-software engineering company (what we do) | Shared and documented. Code review, release approvals, audit trails on our side. Policy ownership stays with you | Assumed as table stakes: FHIR R4, HL7 v2, SMART App Launch, OAuth scopes | Short. Patterns exist already | Fixed-scope phases or retainer | Your spec is frozen and you only need hands on keyboards |
| Build inside an EHR vendor's app ecosystem | Partly inherited from the platform, partly yours | High, but narrow to that vendor's profile of the standard | Medium. Vendor review cycles set the pace | Platform program plus build cost | You need a second EHR, or data the platform does not expose |
| Large consultancy | Documented thoroughly. Also slowly | Available, usually staffed from a pool | Longest to first code, strongest on governance paperwork | Highest, tiered by role | The product is one workflow and you needed it last quarter |
Basis of comparison: the structural properties of each delivery model, not vendor quotes or pricing. Compliance obligations referenced throughout come from the HIPAA Security Rule, 45 CFR Part 164 Subpart C and the standardized API certification criterion in ONC's Cures Act Final Rule (2020), documented at HealthIT.gov.
Decision framework: pick by your hardest constraint
Read these as rules, not as suggestions.
One workflow, one integration target, a date in the next two quarters. Go with a healthcare-focused engineering partner. The interop patterns and the audit trail already exist, so you are paying for your product rather than for someone's education in FHIR.
The product is your company and you expect five years of roadmap. Hire in-house, and bring in a healthcare partner for the first release while you recruit. The worst version of this is waiting to hire before you learn anything from real users.
You already have a strong internal architect and a clear spec. Staff augmentation is the cleanest option. You are buying throughput, and you have someone who can say no to a bad schema.
Your distribution depends on being inside one specific EHR. Build in that vendor's ecosystem, and design the data layer so a second EHR is a config change rather than a rewrite. Vendor review cycles will set your release calendar, so plan backwards from them.
You are a hospital system or payer with procurement, a security review board, and a multi-year program. A large consultancy will survive your governance process. So will a specialist partner, as long as they can produce documentation on request.
Your spec is genuinely frozen and signed off. You do not need a discovery phase. Skip to build.
What "healthcare-grade" Means Once You Are In The Codebase
Every vendor says HIPAA-aware. The difference shows up in specific engineering decisions, and you can check all of them in a code review.
PHI never lands in application logs. The scrub happens at the serializer, not at the log sink. If your team is filtering log lines downstream, PHI has already crossed a network boundary.
Free text is treated as PHI by default. Any field a clinician or patient can type into will eventually contain a name, a diagnosis, or a phone number. Nobody plans for that. It happens in week three of a pilot.
Audit logging is append-only, and it covers reads. Most teams log writes and feel good about themselves. The question an investigator asks is who viewed a record and when.
Access control is role-based and enforced server side, with tenant isolation checked at the query layer. A UI that hides a button is a design choice. It is not a control.
Encryption in transit at TLS 1.2 or higher, encryption at rest with managed keys, and a signed BAA with every subprocessor that can touch PHI, cloud provider included. No BAA, no PHI. That rule has no exceptions and no clever workaround.
De-identification follows a documented method rather than a vibe. Removing the name column is not de-identification, and HHS publishes guidance on the two acceptable methods.
There is a breach runbook, written before it is needed. The Breach Notification Rule requires notification to affected individuals without unreasonable delay and no later than 60 days from discovery, and breaches affecting 500 or more individuals must be reported to HHS within that same window. Sixty days sounds generous until day one is a Saturday.
Our HIPAA-compliant software development practice goes deeper on the control mapping and what we hand over at the end of a phase.
The artifact checklist to ask any vendor for
Send this list to every option you are considering. The answers separate the specialists from the enthusiastic.
- A sample threat model or data-flow diagram from previous work, PHI redacted
- Their access model: who on their team can reach production, and how that access is reviewed
- A BAA they are willing to sign, in advance, not "once we get to that stage"
- Evidence of release approvals: who signs off, where it is recorded
- A FHIR resource mapping they have written, for any workflow
- Their position on PHI in non-production environments (the only correct answer is synthetic or de-identified data)
- Incident response: who gets paged, who notifies you, in what timeframe
- Code ownership and repository transfer terms, in the contract, not the pitch
Basis: the administrative, physical, and technical safeguards required under the HIPAA Security Rule, plus standard software delivery controls. Use it as a scoring sheet across vendors rather than a pass or fail.
Interoperability Decides Your Roadmap, Not Your UI
Here is the part most comparison pages skip, because it is not fun to write and it is where the money goes.
Your product's real scope is defined by how data gets in and out. FHIR R4 is the modern path, and it is the standard behind the certified API criterion in the Cures Act rule, so it is where new work should start. The HL7 FHIR specification is public, which means any vendor can read it. Reading it and having shipped against three different vendors' interpretations of it are separate skills.
HL7 v2 has not gone anywhere. ADT, ORM, ORU messages still move most of the operational traffic inside hospitals. If your product needs to know that a patient was admitted, you are probably reading a v2 feed, possibly through an interface engine, possibly over a VPN that somebody configured during a different presidential administration.
Three decision rules we apply on every integration:
Who launches the app decides the identity model. If a clinician opens your product from inside the chart, build SMART App Launch first and inherit the EHR's session. If a patient opens it, own your identity stack and treat the EHR as a data source. Teams that try to serve both from one auth path spend a quarter learning why that was expensive.
If the product writes to the chart, prove the write in a sandbox before anyone designs a screen. Read access is usually available. Write access is a negotiation, and sometimes the answer is a flowsheet row instead of the structured field you drew in Figma. Find out in week one.
Past two integration partners, put a canonical internal model between you and them. Point-to-point mapping grows as the square of your partner count, and each mapping is a separate maintenance contract with your future self. One internal model, adapters at the edges, done.
Also worth knowing before you sign anything: information blocking rules apply to health IT developers of certified health IT, not just to providers. If your roadmap touches certification, that changes what you are allowed to charge for and how you respond to data requests. The detail lives on HealthIT.gov's information blocking resources.
Our healthcare API integration work covers FHIR, HL7 v2, SMART launch, and the less photogenic middle layer that keeps them honest.
How Delivery Runs, And Where Builds Go Sideways
Our team runs discovery, then fixed-scope phases, with code review on every change and release approvals recorded. Access, not assets: we hold credentials needed to deliver, you hold the accounts. Repositories and infrastructure are yours from day one, not at the end of the engagement.
The failure patterns are consistent across the industry, and none of them are exotic.
Designing the UI before confirming data access. The team ships a beautiful intake flow, then discovers the field it depends on is not exposed by the API. Everything downstream shifts.
Treating compliance as a launch task. Retrofitting audit logging and tenant isolation into a working application costs multiples of building it in. We have seen rewrites triggered by a single missing read log.
A pilot that was never designed to scale past the pilot. Three clinics is a different system from three hundred, mostly in the integration layer and the on-call burden.
No owner for the clinical workflow. Engineers build what the spec says. The spec says what the product manager understood. If no clinician reviewed the actual click path, you will find out during training, in a room, with an audience.
Scope that grows through the back door. Each new "quick" report pulls in a new data source. This is how a four-month build becomes a fourteen-month build, one reasonable request at a time. A situation that really compounds on you.
The fix for most of these is boring and effective: confirm data access first, build the compliance layer in phase one, and put a clinician in the review loop with authority to reject a screen.
What To Compare When Every Vendor Says Yes
Everyone on your shortlist will say they can do healthcare. Compare on these instead of on the pitch.
Ask them to describe a FHIR resource mapping out loud. Not the concept, an actual mapping. The specialists will immediately complain about something specific, usually extensions or how one vendor handles identifiers. That complaint is the qualification.
Ask what they do with PHI in staging. Hesitation is the answer.
Ask who signs off on a production release and where that signature is recorded. If the answer is "the developer merges it," your audit evidence does not exist yet.
Ask what they would cut from your scope. A partner who cannot name something to cut has not read your requirements closely enough to disagree with them.
Ask how they price change. Regulated builds change. The question is whether change goes through a documented scope conversation or through a surprise invoice.
If you want that conversation before a commitment, we run a paid technical advisory engagement and an AI prototype sprint for teams testing a model-driven workflow before funding the full build. Or you can estimate your project and we will come back with scope, sequence, and a number.
Related Work
Work we do adjacent to this, for digital-health platforms, provider groups, and expert-led healthcare operators:
- EHR software development, including FHIR-based data layers and clinician-facing modules
- Patient portal software development for scheduling, results, messaging, and consent
- Workflow automation for intake, eligibility checks, and documentation handoffs, built on existing systems rather than replacing them
- Technical advisory for teams choosing between a platform ecosystem build and a standalone product
Compare the options honestly, confirm your data access before you draw a single screen, and pick the partner who tells you what to cut. We will fix the integration layer. We will also make exactly one terrible joke about your CSV exports, which is included at no extra charge.
