Software Engineering Health Economics

Why this matters in health economics

Every modern health organization is, whether it admits it or not, a software operator. Patient records, prescribing, scheduling, laboratory results, payment claims, and population surveillance all run on code — bought from vendors, built in-house, inherited from predecessors, or stitched together across all three. The money involved is large and recurring: national electronic health record programmes have consumed billions of dollars of public funds, and the running costs of health software — maintenance, integration, upgrades, security — typically dwarf the price that appeared in the original business case. Yet most health-economic training says nothing about how software behaves as an economic asset, and most software-engineering training says nothing about opportunity cost in a system that also buys nurses and medicines.

The gap matters because software fails economically in characteristic ways that ordinary procurement reflexes do not catch. A system is bought on its purchase price and demonstration features; the integration, data migration, and maintenance burden arrive later, against budgets that were never consulted. A vendor relationship hardens into dependence, so each renewal is negotiated from weakness. Shortcuts taken under deadline pressure accumulate invisibly until the system that runs the hospital can no longer be changed safely — at which point the organization faces a modernization bill it never planned and cannot defer, because the software now carries clinical risk. The history of large health-IT programmes, including the UK's National Programme for IT (dismantled in 2011 after an estimated cost of some £10 billion), is a history of these dynamics at national scale.

For a director, the stakes are threefold. First, money: software is a whole-life commitment, and the cheap option at purchase is routinely the expensive option over a decade. Second, safety: in a clinical setting an outage, a data error, or an unmaintainable system is not an inconvenience but a hazard, with costs that land in Chapter 3.11 — Quality and Safety Economics. Third, sovereignty: the choices between building and buying, between proprietary and open systems, and between standard and bespoke interfaces determine how much freedom the organization will have to act in five years — and freedom of action, as this book argues throughout, is an economic asset.

Core concepts

Software engineering is the disciplined design, construction, and maintenance of software — and the word maintenance carries most of the economics. Unlike a building, software is never finished: requirements shift, regulations change, dependencies age, and security threats evolve. Software maintenance — corrective, adaptive, and preventive work on a system in service — commonly absorbs the majority of a system's lifetime cost. The economic unit of analysis is therefore never the purchase; it is the total cost of ownership: acquisition plus integration, data migration, training, hosting, support, upgrades, security, and eventual decommissioning, over the system's realistic life.

The second concept is technical debt: the implied future cost of choosing an expedient design now instead of a sound one. The metaphor is exact enough to use in a finance meeting. Debt is not inherently bad — a deliberate shortcut that ships a needed capability sooner can be a rational loan — but it accrues interest: every future change to the system costs more because of it, and unmanaged debt compounds until change becomes prohibitively expensive or dangerous. A health organization that cannot see its technical debt is carrying an unbooked liability, exactly as if it had unrecorded borrowing.

Third, the legacy system: software that remains in service past the point where it can be economically maintained — often because it works, everyone depends on it, and replacing it is frightening. Legacy is technical debt at organizational scale, and it presents a genuine appraisal problem: the costs of keeping it (rising maintenance, security exposure, staff who can no longer be hired, blocked improvements elsewhere) are diffuse and gradual, while the cost of replacement is concentrated, visible, and politically risky. Health systems worldwide run critical services on software decades old for precisely this reason.

Fourth, dependence. Vendor lock-in is the condition in which switching away from a supplier costs so much — in data migration, retraining, re-integration, and clinical disruption — that the buyer has lost effective bargaining power. In health it is aggravated by data: a decade of patient records held in a proprietary format is a hostage. Lock-in is not an accident; it is a pricing strategy, and the time to price it is before signing, not at renewal. The counterweights are contractual (data-export rights, escrow, exit assistance) and architectural — above all, standards.

Fifth, interoperability: the ability of systems to exchange information and use what is exchanged. Its economics are the economics of the network effect — each system that speaks a common standard raises the value of every other system that does — which is why interoperability is chronically under-supplied by markets: the benefits accrue to the system as a whole while the costs fall on each vendor and buyer, and an incumbent can profit from not interoperating. Standards such as Fast Healthcare Interoperability Resources (FHIR), the HL7 family it belongs to, and openEHR exist to lower these exchange costs, and regulators — for example the United States through the 21st Century Cures Act information-blocking rules, and the European Union through the European Health Data Space — have begun to mandate what the market did not deliver.

Sixth, the make-or-buy spectrum, including open-source software — software whose source code is freely usable and modifiable. Open source is not free: the licence cost disappears, but implementation, hosting, and stewardship remain, and someone must maintain the code. Its economic distinction is different — it removes the lock-in premium and converts the software into a common good that many buyers can co-fund, which is why platforms such as DHIS2 and OpenMRS carry much of the health-information load in low- and middle-income countries. The build-versus-buy decision, likewise, is not a technology preference but a portfolio question: build where the capability is differentiating and the organization can sustain an engineering team; buy where the need is commodity; and never build what you cannot maintain.

Finally, reliability as an economic quantity. Clinical software runs services where downtime has a health cost, so the engineering disciplines that keep systems dependable — including site reliability engineering, which manages reliability against explicit targets and budgets for acceptable failure — are best understood as buying insurance whose premium is engineering effort. Reliability above what the clinical setting needs is waste; below it, the shortfall is paid in incidents. The appraisal machinery for all of this remains Chapter 2.1 — Economic Evaluation and the affordability discipline of Chapter 2.5 — Budget Impact and Affordability; this chapter supplies the software-specific cost structure those methods must be fed with. Evaluating a digital tool as a health intervention — does the app or telehealth service improve outcomes at acceptable cost — belongs to Chapter 5.2 — Digital Health Economics; the economics of AI models specifically to Chapter 5.3 — AI Health Economics.

Best practices

1. Appraise total cost of ownership over the system's realistic life, never the purchase price. Require every software business case to cost acquisition, integration, data migration, training, hosting, support, security, upgrades, and decommissioning over a stated horizon — usually a decade or more — and to name which budget carries each recurring line. A licence fee compared against nothing is not a business case; it is the visible tip of a commitment.

2. Put technical debt on the books. Have engineering leaders maintain a register of the significant shortcuts and ageing components in the estate, with an honest estimate of the interest each is charging — slower changes, higher incident risk, blocked improvements. Review it with the same seriousness as a financial liability, and budget a standing share of engineering capacity (commonly a fifth to a third) for paying it down, because debt service deferred is debt compounded.

3. Fund maintenance as an operating cost from day one. Software that is "finished" is software that is decaying: dependencies age, threats evolve, regulations change. Build the maintenance stream into the original appraisal and the recurring budget, and treat a proposal with no maintenance line as incomplete — the money will be spent either way, and the only question is whether it was planned or extracted by a crisis.

4. Price lock-in before you sign, not at renewal. For every major purchase, cost the exit while you still have alternatives: who owns the data, in what format it can be exported, what exit assistance the vendor must provide, and what a migration would plausibly cost. Negotiate data-export rights and open interfaces into the contract, and treat a vendor's resistance to them as information about the renewal negotiation to come.

5. Buy interoperability deliberately, because the market under-supplies it. Require support for open standards — FHIR and its kin — as a condition of purchase, verify claimed compliance against your actual data flows rather than a brochure, and refuse bespoke interfaces where a standard one exists. Every proprietary interface you accept is a switching cost you have donated to the vendor and a tax on every future integration.

6. Decide build-versus-buy as a portfolio, matched to your engineering capacity. Build only where the capability differentiates your service and you can realistically recruit, retain, and fund a team to maintain what you build — an in-house system without a sustained team is a legacy system with extra steps. Buy commodity needs; consider open-source platforms where a community or public consortium sustains them; and write the sustainment plan into the decision, whichever way it goes.

7. Treat open source as a procurement option with its own cost structure, not as free. Compare it on total cost of ownership: no licence fee, but real implementation, hosting, support, and stewardship costs, whether carried in-house or through a support supplier. Weigh its distinctive benefits — no lock-in premium, inspectable code, the ability to co-fund a common good with other health bodies — and its distinctive obligation: if you depend on it, contribute to sustaining it.

8. Set reliability targets from clinical consequence, and spend to the target. Decide, service by service, what an hour of downtime actually costs — in delayed care, unsafe workarounds, and lost trust — and set availability and recovery objectives accordingly. Then hold the engineering spend to the target from both sides: paying for less reliability than the clinic needs buys incidents, and paying for more than it needs buys gold-plating.

9. Plan legacy replacement before it becomes forced. Review the age and maintainability of critical systems on a cycle, and start replacement while the incumbent still works — a migration executed under failure is the most expensive kind. Prefer incremental migration (strangling the old system interface by interface) to big-bang cutovers, whose failure mode in health is measured in cancelled clinics and lost records.

10. Make data migration a first-class line in every appraisal. Patient data outlives every system that holds it, and moving it — cleanly, completely, with clinical safety assured — is routinely among the largest and most underestimated costs of any transition. Cost it explicitly, test it early with real records, and keep custody of your data in exportable form throughout a system's life so the migration is never hostage to the outgoing vendor.

11. Keep clinical-safety engineering inside the economics. Health software is safety-relevant software: changes need testing, releases need rollback paths, incidents need investigation, and jurisdictions increasingly impose formal clinical-risk standards on health IT. These disciplines cost engineering time and belong in the business case — a "cheaper" delivery that skips them is transferring cost to patients as risk (the cost of harm is Chapter 3.11 — Quality and Safety Economics).

12. Route software decisions through the same value scrutiny as any other health investment. A software programme competes for the same constrained budget as medicines and staff, so it owes the same discipline: a stated benefit, a real comparator (including "improve what we have"), an affordability profile over time, and post-implementation review against the promises made (the machinery is Chapter 2.1 — Economic Evaluation and Chapter 2.5 — Budget Impact and Affordability, and the purchasing craft is Chapter 3.10 — Strategic Purchasing and Commissioning).

Questions to discuss with your team

1. What does our software estate really cost per year, and what share of that did we plan? Most organizations can name their licence fees but not their integration, maintenance, security, and workaround costs, which hide in operational budgets and staff time across the organization. Ask the team to assemble the true annual figure for the top handful of systems and compare it with what the original business cases promised. The tension is that the diffuse costs have no single owner, so no one is accountable for their growth, and the people who approved the purchase are rarely the people paying the upkeep. An honest answer produces a whole-life number, names which budgets carry it, and admits where spend is unplanned — because a cost you discover annually in arrears is a cost you cannot manage.

2. Where is our technical debt, and what interest are we paying on it? Engineering teams usually know exactly where the debt is — the module no one dares touch, the interface held together by manual steps, the platform two versions behind on security support — but the knowledge rarely reaches the board in economic language. Ask for the register: the significant debts, what each one slows down or endangers, and what paying it down would cost. The tension is that debt paydown competes with visible new features and always loses on optics, which is precisely how debt compounds. An honest answer quantifies the interest (slower delivery, incident exposure, blocked projects), commits a standing share of capacity to reduction, and accepts that some debt is rational to carry — provided it is carried knowingly.

3. If we had to leave our main system vendor in three years, could we — and what would it cost? This question surfaces lock-in while there is still time to reduce it. Probe who owns the data and in what format it can leave, what the contract says about exit assistance, how many bespoke interfaces would need rebuilding, and what retraining and clinical disruption a migration would impose. The tension is that everyone hopes never to exercise the exit, so no one wants to pay to keep it open — yet an exit that is impossible is a renewal negotiation already lost. An honest answer prices the exit, identifies the two or three actions that would cheapen it (data-export rights, standard interfaces, documentation), and treats that price as a bargaining position the organization actively maintains.

4. Which systems should we build, which should we buy, and does our engineering capacity match that answer? The build-versus-buy split is a portfolio decision that many organizations make by accretion instead of by choice, ending up building commodities and buying what differentiates them. Ask which of your systems genuinely embody something distinctive about your service and which are commodity needs a market or an open-source community already serves. Then test the capacity claim: for everything built in-house, is there a funded, recruitable team committed to maintaining it for its life — not just the project that created it? The tension is that building flatters ambition and buying flatters prudence, and neither instinct is an analysis. An honest answer names the differentiators, admits where past builds should be retired or replaced with standard products, and refuses to start any build whose maintenance is unfunded.

5. What does an hour of downtime in our most critical system actually cost, and is our reliability spend matched to it? Reliability decisions are often made by engineers without clinical-cost information, or by boards without engineering-cost information, so the spend is matched to habit rather than consequence. Work through a concrete scenario: the electronic record is down across a busy day — what is delayed, what unsafe workarounds appear, what harm plausibly follows, what does recovery cost? Then compare that against what you spend on resilience, backups, failover, and incident response. The tension runs both ways: under-spending buys incidents, but gold-plating a low-stakes system wastes money that another service needs. An honest answer sets an explicit availability and recovery target per critical service, derived from clinical consequence, and can show the engineering spend that meets it — no more, no less.

6. What is our plan for the legacy systems everyone is afraid to touch? Every mature health organization has them: systems past economic maintainability, kept alive because they work and replacement is frightening. Name yours. Ask what each one blocks — integrations not built, improvements not made, security exposure carried — and what the replacement path is: incremental migration, wholesale replacement, or deliberate, planned retention with contained risk. The tension is temporal: the costs of keeping legacy are diffuse and annual while the cost of replacing it is concentrated and career-visible, so rational-seeming deferral is the default until failure forces the issue at the worst possible price. An honest answer schedules replacement while the incumbent still works, prefers strangler-style incremental migration to big-bang cutover, and treats "we will decide next year" as the decision it actually is.

In practice: a health economics example

The Ministry of Health of a fictional East African country faces a renewal decision. For nine years its regional hospitals have run a proprietary hospital-information system supplied by an overseas vendor. The system works, but the renewal quote has risen sharply, every new interface — to the national insurance scheme, to the laboratory network — is a bespoke, vendor-priced project, and the contract is silent on data export. Meanwhile the ministry's district health offices already run DHIS2, the open-source platform used for national health statistics, and a neighbouring country has implemented an open-source medical-record platform with a regional support consortium.

The ministry's health-economics unit reframes the decision from "renew or not" to a whole-life comparison of three options over ten years: renew the incumbent, renew short-term while building exit rights, or migrate incrementally to the open-source platform. Costing the options exposes the real economics. The incumbent's licence is only a third of its true annual cost once bespoke interfaces, mandatory upgrade projects, and overseas support travel are counted. The open-source option carries no licence but requires the ministry to fund a national support team, regional hosting, and a contribution to the platform's community — real, recurring money the "free software" rhetoric had hidden. The decisive line, however, is neither of these: it is data migration. Nine years of patient records sit in a proprietary schema, and the vendor's price for extraction assistance is, in effect, the price of leaving.

The unit prices the exit anyway, and the number changes the negotiation. Armed with a costed alternative, the ministry negotiates a two-year renewal at a lower price that includes contractual data-export in a documented format and standard FHIR interfaces to the insurance scheme and laboratory network — bought, in economic terms, as an option on a cheaper future exit, valued the way Chapter 3.12 — Pandemic and Emergency Preparedness Economics values any option on future freedom of action. During those two years, a pilot migrates three district hospitals to the open-source platform, testing the support consortium, the data-migration tooling, and — critically — whether the ministry can recruit and retain the engineers the platform needs, drawing on the workforce economics of Chapter 3.6 — Health Workforce and Labour Markets.

The pilot succeeds in two hospitals and struggles in the third, where staffing gaps turn every incident into a crisis — a warning about capacity, not software. The ministry proceeds with a phased national migration over five years, hospital by hospital, keeping the incumbent running in parallel until each site's data is verified. The final evaluation makes the lesson explicit: the winning move was not choosing open source over proprietary, but pricing the whole life of each option, buying exit rights before dependence hardened further, and matching the engineering commitment to what the ministry could actually sustain.

Four sector lenses

Startup

A health-software start-up lives the economics of this chapter from the selling side: its valuation rewards shipping speed, which is precisely how technical debt accumulates, and its revenue model may quietly depend on the lock-in its customers should resist. The discipline is to take debt deliberately — a shortcut that wins a pivotal customer can be rational — while keeping a register and a paydown plan, because a codebase that cannot be changed is a company that cannot pivot. Interoperability is strategy, not compliance: standard interfaces (FHIR above all) are how a small product earns a place inside estates dominated by incumbents. And clinical-safety engineering is not bureaucracy to defer until scale; one data-integrity incident in a clinical setting can end a young company.

Small business

A small but established provider — a clinic group, a pharmacy chain, a diagnostic laboratory — buys nearly all its software and has no engineering staff to compensate for a bad purchase, so its economics are the economics of dependence. Total cost of ownership and exit rights matter more here than anywhere, because a mispriced system is proportionally a bigger share of the budget and a failed migration can halt the business. The sensible posture is standardization: mainstream products, open-standard interfaces, hosted services rather than self-run servers, and contracts read for data-export clauses before price. Its distinctive risk is silent legacy — the practice-management system that ages in place until its supplier folds — so even a small buyer should know, each year, what it would cost to leave each system it depends on.

Enterprise

A large hospital group or insurer runs hundreds of systems, so its problem is the portfolio: overlapping products bought by different departments, an integration web nobody fully maps, and technical debt distributed across an estate too large for any one team to see. The mature enterprise manages the estate the way it manages an investment portfolio — an inventory of systems with owners, whole-life costs, debt and risk ratings, and planned replacement horizons — and funds a standing engineering capability for integration, reliability, and paydown rather than treating every improvement as a project to be bid for. Scale also gives it purchasing power the smaller buyer lacks: it can demand standard interfaces, data-export rights, and escrow as conditions of entry, and its architecture choices discipline its vendors rather than the reverse.

Government

A ministry or national payer shapes these economics for everyone else. It sets the interoperability rules that determine whether the market rewards or punishes openness — as the United States did with the 21st Century Cures Act's information-blocking provisions and the European Union with the European Health Data Space — and its own procurement teaches vendors what buyers will tolerate. Its distinctive failure mode is the national mega-programme: centralized, big-bang, politically timetabled software delivery whose collapse is measured in billions, as the UK's National Programme for IT demonstrated. The discipline is the reverse posture — standards and platforms centrally, delivery incrementally, with open-source and locally-maintainable options weighed seriously where commercial markets are thin (the policy machinery is Chapter 3.2 — Health Policy, and the purchasing craft Chapter 3.10 — Strategic Purchasing and Commissioning).

Common failure modes

• Buying the licence, not the life. Approving software on purchase price while integration, migration, maintenance, and exit go uncosted. Fix: require whole-life total cost of ownership, with named budgets for every recurring line, in every business case.

• Invisible debt until it compounds. Letting technical debt accumulate unrecorded until the estate cannot be changed safely. Fix: keep a debt register, report it in economic terms, and commit standing capacity to paydown.

• Sleepwalking into lock-in. Accepting proprietary formats and bespoke interfaces until exit is unaffordable and renewals are dictated. Fix: negotiate data-export rights and standard interfaces at purchase, and price the exit annually.

• Building what you cannot maintain. Commissioning in-house systems without a funded team for their whole life. Fix: no build without a sustainment plan; buy or adopt open-source platforms where capacity is thin.

• Treating open source as free. Adopting community platforms without funding hosting, support, and stewardship. Fix: appraise open source on total cost of ownership and budget the sustainment it needs.

• Reliability by hope. Leaving availability targets unset until an outage reveals the clinical cost of downtime. Fix: set availability and recovery objectives per critical service from clinical consequence, and spend to the target.

• Big-bang legacy replacement under duress. Deferring modernization until failure forces a rushed, wholesale cutover. Fix: plan replacement while the incumbent works, and migrate incrementally with parallel running and verified data.

• Software outside the value discipline. Letting IT programmes skip the scrutiny applied to medicines and services. Fix: same rules — stated benefit, real comparator, affordability profile, post-implementation review.

Maturity model

Checklist

• Appraise every software decision on total cost of ownership over its realistic life, with named budgets for each recurring line.
• Maintain a technical-debt register, report it in economic terms, and commit standing engineering capacity to paydown.
• Fund maintenance as a planned operating cost from the original business case onward.
• Negotiate data-export rights, standard interfaces, and exit assistance into contracts at purchase.
• Price the exit from each major system annually, and keep a costed alternative alive before renewals.
• Require verified open-standards compliance (e.g. FHIR) as a condition of purchase.
• Decide build-versus-buy as a portfolio, and start no build without a funded whole-life sustainment plan.
• Appraise open-source options on total cost of ownership, budgeting hosting, support, and stewardship.
• Set availability and recovery targets per critical service from clinical consequence, and match spend to them.
• Schedule legacy replacement while incumbents still work, preferring incremental migration to big-bang cutover.
• Cost and test data migration early, and keep patient data exportable throughout each system's life.
• Route software programmes through the same value scrutiny as any other health investment, with post-implementation review.

Key sources

• WHO, Global Strategy on Digital Health 2020–2025 — the World Health Organization's frame for digital health investment, including sustainability and interoperability principles.
• HL7 International — the FHIR (Fast Healthcare Interoperability Resources) standard, the dominant open standard for health-data exchange.
• openEHR, DHIS2, and OpenMRS — open-source health-information platforms and specifications widely deployed worldwide, exemplars of community-sustained health software.
• U.S. Office of the National Coordinator for Health IT (now ASTP) — 21st Century Cures Act information-blocking and interoperability rules, a regulatory response to under-supplied interoperability.
• DORA, Accelerate State of DevOps reports — long-running research linking software delivery and reliability practices to organizational performance.
• UK National Audit Office — reports on the National Programme for IT in the NHS, the canonical case study of large-scale health-IT programme failure.

References

1. Software engineering — Wikipedia — https://en.wikipedia.org/wiki/Software_engineering
2. Software maintenance — Wikipedia — https://en.wikipedia.org/wiki/Software_maintenance
3. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
4. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
5. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
6. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
7. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
8. Network effect — Wikipedia — https://en.wikipedia.org/wiki/Network_effect
9. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
10. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
11. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
12. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
13. World Health Organization — Global Strategy on Digital Health 2020–2025 — https://www.who.int/publications/i/item/9789240020924
14. HL7 International — FHIR specification — https://hl7.org/fhir/
15. National Audit Office — The National Programme for IT in the NHS: an update on the delivery of detailed care records systems — https://www.nao.org.uk/reports/the-national-programme-for-it-in-the-nhs-an-update-on-the-delivery-of-detailed-care-records-systems/
16. National Programme for IT — Wikipedia — https://en.wikipedia.org/wiki/National_Programme_for_IT