Healthcare Software Development Cost: Eight Modules, Priced

A clinical system phase one runs 1,640 hours across eight modules. At $40 per hour that is $65,600, at $100 per hour $164,000, and about $106,600 at a $65 blended rate. The full span across the eight, every minimum to every maximum, is 1,160 to 2,270 hours. Five to six people at 600 to 700 useful hours a month puts that at three to five months.

The largest line is not the one most buyers expect. It is clinical documentation and charge capture at 250 to 500 hours, because it is where the clinician's workflow meets the billing code, and getting it wrong costs either clinical time or revenue. Scheduling is second at 200 to 400.

HIPAA does not appear as a module in that list, and that is deliberate. It is not a thing you build, it is a multiplier on three things you were building anyway — identity and audit, the compliance layer, and the integrations. Quotes that show a line item called "HIPAA compliance" are usually hiding where the work actually falls.

The ordinary failure in this category is not a failed build. It is a clinic that specified a system around how its clinicians say they work, discovers at go-live that documentation takes eleven minutes per encounter instead of four, and watches adoption collapse while the software works exactly as specified.

Phase one, module by module

Module	Worked example	Published range
Discovery and regulated-scope determination	90 h	60 to 120
Identity, access model and audit log	240 h	180 to 320
Patient master with MRN merge	160 h	120 to 220
Scheduling with provider and room rules	290 h	200 to 400
Clinical documentation and charge capture	350 h	250 to 500
HL7 v2 interfaces, first two feeds	120 h	80 to 160
Eligibility and prior authorisation	210 h	150 to 300
Compliance layer, retention and legal hold	180 h	120 to 250
Total	1,640 h	1,160 to 2,270

Note the first row. Discovery here is regulated-scope determination, which means establishing which parts of what you are building are subject to which rules before anyone designs them. That is 60 to 120 hours spent deciding what the project legally is, and skipping it is how a system gets built on an assumption about scope that a compliance review later overturns.

Note also the sixth row: HL7 interfaces, first two feeds. Two. A third lab, a second imaging system or another downstream registry is more work, sized by that vendor's interface at your version rather than by the standard in the abstract.

Clinical documentation is the largest line

250 to 500 hours, and the range is wide because the requirement is not "a form".

Documentation has to produce two things from one act of typing: a clinical record a colleague can rely on, and the structured codes that produce a bill. Those two audiences want different things. The clinician wants to describe a patient in the order they thought about them. The billing system wants discrete, coded, complete fields in a fixed order. Software that serves one well usually serves the other badly.

The measure that decides whether this module succeeded is minutes per encounter, and it is worth agreeing a target before the build rather than discovering the number after it. A system that adds four minutes per encounter to a clinician seeing thirty patients a day has taken two hours from them, which no amount of feature richness compensates for.

Charge capture is the half that pays for the project. If a procedure performed is not captured as a code, it is not billed, and the revenue leak is invisible because nothing errors. The design rule that works is capture at the point of care rather than reconstruction afterwards, because reconstruction depends on memory and memory is where margin goes.

There is a structural choice underneath it that decides how the module ages. Store the clinical note and the derived codes as separate things, linked, rather than treating the codes as a property of the note. Coding rules change on the payer's schedule, and a system that can re-derive codes from a stored note adapts to that with a rule change. One that wrote the codes into the note at the time can only adapt by asking clinicians to revisit records, which is a request no clinic grants twice.

Scheduling is not a calendar

200 to 400 hours, and the published description names the reason: provider and room rules.

A clinical appointment consumes several resources at once. A clinician, a room, sometimes equipment, sometimes a second clinician or an interpreter. Each has its own availability, and an appointment is only bookable when all of them intersect. That is a constraint problem rather than a calendar lookup, and it is where the hours go.

Then the rules layer on top. Appointment types with different durations. Buffers for cleaning or turnover. Double-booking that is forbidden for one appointment type and standard for another. Cancellation and no-show policy that differs by payer. Licensure, where a clinician may only see patients in jurisdictions they are licensed in — a rule that belongs in the scheduler and is almost never specified there.

The upper end of the range is multi-site, multi-speciality scheduling, where the same clinician works across locations and the system has to account for travel between them.

One specific worth insisting on: the scheduler must be able to say why a slot is unavailable. A system that simply shows no availability generates phone calls, because the person booking cannot tell whether the clinician is busy, the room is taken, or a rule forbids that combination. Exposing the binding constraint turns a call into a rebooking, and it costs little if designed in and a great deal if retrofitted into a solver afterwards.

The patient master and the MRN merge

120 to 220 hours for a module most specifications reduce to "patient records".

The hard part is identity. The same person arrives as a new registration at a second site, with a misspelled name and a different phone number, and the system now holds two medical record numbers for one human. Merging them is not deleting one: the clinical history under both has to survive, the audit trail has to show the merge happened and who approved it, and anything already billed under the old number has to stay reconcilable.

Unmerging matters too, because merges are sometimes wrong, and a merge that cannot be reversed turns a data-entry error into a permanent clinical record error. That is the requirement that makes this a 220-hour module rather than a 120-hour one, and it is worth asking any vendor whether their merge is reversible before you ask anything about their interface.

Prevention costs less than cure here. A duplicate avoided at registration is worth several merges, and the mechanism is a search that is forgiving about spelling and strict about confirmation: fuzzy matching on name and date of birth that surfaces likely existing patients before a new record is created, with the final decision left to the person at the desk rather than to the algorithm. That is a modest piece of work inside the same module and it reduces the merge queue permanently.

Eligibility and prior authorisation pays for itself

150 to 300 hours, and it is the module most often cut first and regretted first.

Eligibility is the check that a patient's cover is active and covers what is about to happen. Run it before the appointment and a problem becomes a conversation at booking. Run it after, or not at all, and the problem becomes a denied claim weeks later, by which time the patient has been treated, the clinician's time is spent and the money is a collections exercise rather than a payment.

Prior authorisation is the same logic with a longer clock. Some procedures need the payer's agreement before they happen, that agreement takes days, and the authorisation has its own validity window and its own reference number that the eventual claim has to carry. The expensive failure is a procedure performed against an authorisation that expired, which is clinically fine and financially void.

What makes this a build rather than a form is that both are integrations, each payer has its own interface, and the responses are not uniform. A system that handles three payers well and the fourth by exception will route a growing share of work to the exception path, which is a person with a phone.

The reason it earns its hours is that it moves money forward. Scheduling and documentation make the operation work; eligibility decides whether the work gets paid for. If budget is tight, cutting this before cutting a reporting dashboard is almost always the wrong order.

HIPAA is a multiplier, not a module

This is the part that reframes most quotes. HIPAA does not sit in the module list because it is not separable work. It raises the cost of three modules you already have.

Identity and audit, at 180 to 320 hours, is where most of it lands. The audit log stops being a developer convenience and becomes a product feature with a retention period and a query interface, because someone will eventually have to answer who accessed which record and when. Access control becomes role-based and minimum-necessary rather than whatever is convenient for the team.

The compliance layer, at 120 to 250, carries retention and legal hold, enforced by the system rather than by a policy document. A record under legal hold must survive a routine purge, and proving that it did is part of the feature.

The integrations carry it too, because every feed is a point where protected data crosses a boundary and the crossing has to be logged, encrypted and authorised.

If you operate outside the United States, substitute your own regime and redo this section against the regulator's own text. The structure holds — audit, access, retention — but the specifics do not travel, and borrowing another country's requirements is a common and expensive error.

The BAA chain nobody inventories

Every vendor that touches protected health information needs a business associate agreement, and the list is longer than the one in most project plans.

The obvious ones get caught: the cloud provider, the hosting platform. The ones that do not are the error-tracking service that might capture a patient identifier in a stack trace, the analytics tool, the transcription service, the email provider that sends appointment reminders containing a name and a time.

HHS has stated plainly that using a cloud provider to maintain electronic protected health information without a business associate agreement violates the rules, and that the conduit exception is narrow — it covers transmission-only services with transient access. A provider that stores, processes or retains the data is a business associate, and lacking the encryption key does not exempt it.

Build the vendor inventory during discovery, not during an audit. It is a list, it takes an afternoon, and the alternative is discovering a gap at the point where discovering it is most expensive.

The inventory is also the thing that keeps being true. Vendors get added quietly — a new monitoring tool, a feature flag service, a support widget — and each addition is a decision about patient data that nobody framed as one. Reviewing the list on a fixed cadence, and requiring a named owner before any new service reaches production, is cheaper than the alternative and takes minutes.

What sits outside the number

Six things, each its own decision, and each deliberately excluded from the 1,640.

Claims generation and remittance posting, which is a billing system rather than a clinical one. Lab accessioning. EDC and trial systems, which belong to research rather than care. The patient portal, which is a second product with its own authentication and its own support burden. An offline mobile app, for the same reasons it costs what it does anywhere else. And telehealth, which has its own post and its own numbers — this one prices the clinic and hospital system, not the consultation.

The regulated and HIPAA multipliers also sit outside as multipliers rather than lines, applied to the modules named above once scope is known.

Build, buy, or configure

Most clinic groups should not build all eight modules, and the honest split follows the same logic as any other sector.

Buy the parts where you are ordinary. Billing, claims and statutory reporting are solved problems with established vendors, and your practice does not bill differently from another practice of the same speciality in the same country.

Build the parts where your operation is the product. For a multi-site group that is usually scheduling and the patient master, because how you route patients between sites, how you handle shared clinicians and how you resolve identity across locations is the operational difference that a package will ask you to abandon.

Configure, carefully, in between. A package that permits extension is not the same as one that permits configuration, and the distinction is the cost line. Ask during evaluation which of your requirements are settings and which need code, because demos rarely separate them and the answer changes the five-year number more than the licence does.

Where clinical builds fail

Not in the modules, which are well understood and published above.

They fail on documentation time, when a system specified around how clinicians say they work meets how they actually work, and the minutes-per-encounter figure nobody agreed turns out to be unacceptable. They fail on the MRN merge, when duplicates accumulate because merging was built and unmerging was not. They fail on the BAA chain, when a vendor nobody listed turns out to have been receiving identifiers in logs for two years. And they fail on scope, when regulated-scope determination was skipped as paperwork and a compliance review later reclassifies half the system.

Every one of those is cheaper to settle in the 60 to 120 hours of discovery than at any point afterwards. That is the entire argument for not quoting a clinical system from a feature list: the feature list cannot tell you which rules apply, and the rules decide the number.