Practical CEA in Healthcare: What Actually Works
Most cost-effectiveness analyses in healthcare fail not because the math is wrong, but because the inputs are pulled from thin air. I spent seven years building these models for provincial health technology assessment bodies before moving into private consulting. The gap between textbook methodology and what gets produced on a real deadline is enormous. Start with the question, not the model. Define the comparator, the perspective (payer? societal? patient?), and the time horizon before opening any software. I once watched a team spend three weeks building a Markov model for a diabetes intervention, only to realize halfway through that the comparator was the wrong drug class. That could have been caught in two hours of stakeholder mapping. The standard approach uses quality-adjusted life years as the outcome measure. You calculate incremental cost per QALY gained by subtracting the costs and outcomes of the comparator from the intervention. The formula itself is trivial. The hard part is everything around it.
For transition probabilities, I use one-to-one correspondence between health states and clinical evidence whenever possible. If your model has four states, you need a full transition matrix plus one constraint row. I set up my matrices in a way that missing probabilities auto-populate as 1 minus the sum of the row. Catches errors before they propagate. Discounting is where most people make visible mistakes. The standard is 3% per annum for both costs and outcomes, but different jurisdictions use different rates. The UK uses 1.5% for health effects and 3.5% for costs. Canada uses 5% for both. Get this wrong and your ICER shifts by enough to change a reimbursement decision. I keep a reference table of discount rates by agency in my template workbook. Parametric uncertainty is usually handled with Monte Carlo simulation. Run 10,000 iterations minimum. Anything less and your confidence intervals are noisy enough to be misleading. I use @RISK or TreeAge for this. Both handle the probability distributions well - Beta for rates and proportions, Gamma for costs. Log-normal works for skewed cost data but people forget to check that the underlying normal distribution isn't creating impossible values in the tails.
Structural uncertainty is the bigger problem. Most decision makers don't test whether the model structure itself is reasonable. I once built a model for a cancer drug where the base case assumed constant treatment effect over time. When I tested a waning effect assumption, the ICER moved from 45,000 to 112,000 per QALY. The manufacturer's submission had only reported the base case. The regulatory body accepted it anyway because the waning scenario wasn't required by their guidance at the time. Boundary conditions matter more than sensitivity analysis. I always define the stopping rules for my models upfront. At what point does adding another health state change the conclusion? When do I stop refining the cost parameters? Without these boundaries, models tend to expand until they consume the entire project timeline. A practical tip that saves hours: build your input table separately from your calculation layer. When I separate the assumption sheet from the logic sheet, I can validate inputs without risking formula corruption. I've seen colleagues lose days fixing broken models because someone entered a cost parameter directly into a formula cell.
Get the Full Details
The most overlooked aspect is perspective. A payer perspective and a societal perspective can produce wildly different results for the same intervention. Home care programs look expensive from a hospital budget view but show cost savings when you include reduced emergency department visits. The difference is purely about which costs get counted. Validation is rarely done properly. Face validity checks - showing the model to clinicians who know the disease - catch structural errors that no mathematical validation will find. Internal consistency checks catch calculation errors. External validation against published studies catches both. I run all three before submitting any model. Software choice depends on the complexity. Simple models with fewer than five health states work fine in Excel. Anything beyond that benefits from dedicated software. TreeAge Pro handles Markov models and decision trees cleanly. R packages like heemod and Panthura are free but have a steeper learning curve. I recommend starting with Excel for simple analyses and moving to specialized tools only when necessary.
The biggest mistake I see is treating the ICER as a definitive answer. It's an estimate with wide confidence intervals built on assumptions. Decision makers who present it as fact are doing their stakeholders a disservice. Report the full distribution, not just the mean. Show what the model can and cannot tell you. Documentation should be thorough enough that another analyst could recreate your results from scratch. I include a version-controlled assumption register, a source document for every parameter, and a changelog for model updates. This takes extra time initially but prevents costly disputes later. Time estimates for a complete analysis: a straightforward one-drug versus comparator model with good data takes about two weeks of focused work. Complex models with multiple comparators, long time horizons, and structural uncertainty can run three to four months. Budget accordingly.
If you're new to this, start with published models in your area of interest. Reverse-engineer them to understand the structure. Then try rebuilding a simpler model from a published paper. This approach builds intuition faster than any textbook.
