HIPAA Compliant App Cost: Price The Delta, Not The App

Two agencies quote the same brief. One says $90,000, the other says $400,000. Both are describing a HIPAA compliant app and both numbers are defensible, because they are pricing different things and neither says which.

Published guidance does not help. Search the term and you will find totals from $25,000 for a lean MVP to over $3,000,000 for an enterprise platform, none of which reconcile with each other. The reason is simple: a total mixes the cost of the product with the cost of the regulation, and only one of those is fixed by your feature list.

Price the delta instead. What does HIPAA add over the same app built without it? That number is comparable across vendors, it is defensible to a board, and it is the part you cannot cut.

First, does HIPAA apply to you at all

Worth 20 minutes before anything else, because the answer is sometimes no.

HIPAA reaches you as a covered entity, meaning a provider, health plan or clearinghouse, or as a business associate, meaning you handle protected health information on behalf of one. A wellness app selling directly to consumers with no provider relationship is frequently neither, and pays nothing.

Protected health information is health information tied to an identifier. The de-identification standard names 18 identifier types, and removing all of them is one of the two recognised routes to de-identified data. Step numbers with no name, no account and no device identifier attached are not PHI. The same steps against a patient record are.

Two traps. First, business associate status arrives through a contract you sign, not through a decision you make, so the first enterprise healthcare customer usually brings it. Second, a business associate agreement flows down: your subprocessors need one too, which quietly removes some vendors from your stack.

That second one has a cost attached that never appears in a build estimate. Every analytics tool, error tracker, support desk, email service and model provider that could touch PHI needs an agreement in place or needs to be kept out of the PHI path entirely. On a typical stack that is 8 to 15 vendors to review, some of which will not sign, and the replacement work lands on engineering. Do the vendor review during architecture rather than during procurement, because discovering in month 4 that your error tracker cannot be used is a refactor rather than a form.

If none of this reaches you, the rest of the article is a future problem and the correct budget today is zero.

The delta, and why it is a percentage

Here is the number we use, and it is a percentage because it applies across the build rather than to one module.

HIPAA in scope adds 10 to 15 percent to the whole programme. Not to a compliance module. Business associate agreements, minimum necessary access design, audit logging and retention touch nearly every screen and every table, which is why it does not sit in one line.

Regulated scope adds 25 to 40 percent up front. That is GxP or medical device territory, which is a different regime again, and it is decided in discovery rather than in development.

Those two are not alternatives. A medical device with PHI in it carries both.

Worked example. A $200,000 base build with HIPAA in scope lands at $220,000 to $230,000. The same build inside a regulated device scope lands at $250,000 to $280,000, before the recurring cost below. The reason two agencies can quote $90,000 and $400,000 for the same brief is that they are describing different base builds, and the delta is the smaller half of the disagreement.

Required against addressable, and why it matters to a budget

This distinction is in the Security Rule, most articles skip it, and it changes what you have to build.

Some implementation specifications are required. Others are addressable, which does not mean optional. It means you either implement it, or you document why it is not reasonable and appropriate for your environment and implement an equivalent alternative.

Encryption at rest is addressable, not required. That surprises people. In practice almost everyone implements it, because the alternative is documenting a defensible reason not to, and there rarely is one. But the distinction matters for budget conversations about older systems where full encryption is genuinely hard: there is a documented route, and it amounts to a written analysis with a named owner rather than a loophole.

A risk analysis is required. It is the specification that everything else hangs off, and it is the first thing an investigation asks for. Doing it late means doing the design twice.

The practical use of the distinction is in negotiation rather than in avoidance. When a buyer's questionnaire asks a yes or no question about a control that is addressable, the honest answer is sometimes a paragraph rather than a tick, and having that paragraph written and dated in advance turns a 3 week procurement stall into a 1 day exchange. Teams that treat every addressable specification as mandatory end up over-building in places that never mattered while missing a required one nobody read.

What the delta actually buys

The 10 to 15 percent is not paperwork. It is engineering, and most of it has value beyond compliance.

1. Audit logging over PHI access. Who viewed which record, when, from where, and why where a reason is required. Application logs are not audit logs and the two are frequently confused.

2. Minimum necessary access. Role granularity that limits each role to the data it needs. Admin and user is not a model, and a receptionist who can open clinical notes is a finding.

3. Access review and termination. Provable removal of access when somebody leaves, with a record. This is the control that fails most often in real environments.

4. Encryption in transit and at rest, with key handling that survives a question about who can reach the keys.

5. Retention and disposal. Health record retention is jurisdictional and long, and the software has to hold data for the required period and dispose of it provably afterwards.

6. Breach detection and notification readiness. Individuals have to be notified without unreasonable delay and no later than 60 days, which is only possible if you can determine scope quickly, which is only possible if the audit log is queryable.

The integration line, priced per feed

Healthcare integration is where budgets actually differ, and it is priced per feed rather than as a lump.

1] Each HL7 v2 feed runs 80 to 160 hours, including mapping and certification. The message types you will meet are ADT for admissions and demographics, ORM for orders, ORU for results, SIU for scheduling and DFT for charges. Pipe delimited, decades old, and still carrying most of the traffic.

2] FHIR R4 did not replace it. It is the API layer for new integration and the mandated format for channels such as NPHIES with its Saudi profiles, and it sits alongside HL7 v2 rather than removing it. Plan for both and for a mapping layer that somebody owns.

The second feed is where an interface engine pays for itself. The fifth is comparatively cheap. A build with 1 feed and a build with 6 are not the same project, and a quote that does not name the count is not a quote.

3] Codes are not interchangeable. SNOMED CT for clinical findings, LOINC for observations and lab, ICD for diagnosis and billing, plus a local drug code where a regulator mandates one. Treating these as one lookup table is a rework item rather than a shortcut, and the rework arrives when the first report has to be filed against a code set the model cannot express.

Version the code sets as well as the data. ICD revisions and local drug code updates land on their own schedule, and a historical record has to keep the code that was valid when it was written rather than being silently reclassified by an update. This is the same discipline a claims system needs for policy versions, applied to clinical vocabulary, and it costs almost nothing to design in and a great deal to retrofit.

4] The patient index is the hidden driver. A legacy index carrying years of duplicates needs a review queue, an approver flow and a reversible merge. A clean index needs none of that. Ask for the duplicate rate before quoting, because it changes the number materially and nobody volunteers it.

Reversible is the word doing the work. A merge that cannot be undone is a data loss event waiting for its first false positive, and false positives are guaranteed when matching on name, date of birth and a partial identifier. Design the merge as a link with a survivorship rule rather than a deletion, keep both source records, and give a named clinical or records owner the ability to unlink. Systems that hard merge are the ones where somebody eventually finds two patients' histories in one chart.

The cost nobody quotes, which is the recurring one

Every article prices the build. Almost none price the years after it, and that is where a regulated product's economics are decided.

Regulated scope adds 15 to 30 percent to every subsequent release, permanently. Validation, documentation and change control do not amortise. A team shipping every 2 weeks pays that tax 26 times a year, forever, and over 5 years it dwarfs the up front delta.

Alongside it sit the annual items: risk analysis refresh, penetration testing, business associate agreement reviews as your subprocessor list changes, access review cycles, and incident response exercises. Budget these as a recurring line rather than as a project, because a lapsed control is worse than one you never claimed.

The strategic consequence is worth stating plainly. Keep the regulated boundary as small as it can honestly be. A product where PHI touches 3 services costs materially less to run than one where it touches 12, and that architecture decision is made in month 1 and paid for every year afterwards.

Retrofitting costs more than building

The most expensive version of this project is the one that starts after launch.

Adding audit logging to a system that never had it means adding it to every data access path, then backfilling nothing, because the history does not exist. Adding role granularity to a two role system means revisiting every screen. Adding encryption at rest to a live database means a migration with downtime. Adding minimum necessary to a data model where one table holds everything means splitting the table.

Estimates in the market put a retrofit at several times the cost of building it in, and that matches what we see: the multiple depends almost entirely on how many services touch PHI, which is the thing nobody constrained at the start.

The practical implication is not "do everything on day one". It is that the security architecture is a design decision, and design decisions are cheap in month 1 and expensive in month 18.

There is a middle path that works when a product is already live and a healthcare customer has just arrived. Rather than making the whole system compliant, carve out a PHI-bearing subsystem with its own storage, its own access model and its own audit trail, and keep the existing product talking to it through a narrow interface. That is a real project rather than a trick, usually 400 to 800 hours, and it is frequently cheaper than lifting an entire estate. It also caps the recurring release tax at the subsystem instead of the company.

What it costs, with the hours shown

Published rates, published hours, arithmetic you can argue with. We hold no certifications ourselves. We build the controls and the evidence that let you hold them.

Component	Hours	Note
Risk analysis and written security architecture	40 to 90	Required, and it is the specification
Audit logging over PHI access	120 to 240	Queryable, or the 60 day clock is unachievable
Role granularity and minimum necessary	100 to 220	Scales with your object model
Access review and termination workflow	60 to 130	With evidence, not a spreadsheet
Encryption and key handling	50 to 120	The keys are the question, not the algorithm
Retention and provable disposal	60 to 140	Jurisdictional, and longer than you expect
Each HL7 v2 or FHIR feed	80 to 160	Mapping and certification included
Patient index merge and review queue	100 to 260	Only if the duplicate rate warrants it

At $40 to $100 per hour by role, blending to around $65, the compliance delta on a typical build lands near 530 to 1,200 hours, so roughly $34,000 to $78,000, plus 80 to 160 hours per integration feed. Phase one for a clinic or polyclinic operations scope runs 3 to 5 months, and certification is calendar rather than hours: conformance testing and sign-off consume weeks nobody bills and everybody waits for.

A sequence that keeps the delta small

First, qualify. Covered entity, business associate, or neither. One page, dated. Sometimes it ends the project.

Second, the risk analysis. It is required, it is the specification, and doing it after the design means doing the design twice.

Third, constrain the PHI boundary. Decide which services touch PHI and keep the list short. This single decision moves the recurring cost more than any other.

Fourth, build audit logging and role granularity into the foundation, before feature work, because both touch every path added afterwards.

Fifth, integrate one feed end to end, including certification, before committing to a date for the rest.

Certification is the item most likely to move your launch and the one least under your control. Conformance testing runs on the counterparty's calendar, slots are finite, and a failed run usually means waiting for the next window rather than fixing and resubmitting the same afternoon. Book the slot early, treat the date as fixed, and plan the build backwards from it in the same way a SOC 2 observation window is planned backwards from the report date.

Two questions set your number, and neither is on a feature list. How many services will touch PHI, and how many interface feeds are in scope? Answer those and the delta is arithmetic. Leave them open and you will get quotes ten times apart again, and both will be defensible.