Using Generative AI for HTA Coding

A practical tool in your R workflow — not a replacement for your expertise

R for HTA (Basics) — Workshop 2026

RRC-HTA, AIIMS Bhopal | HTAIn, DHR

What This Session Is (And Isn’t)

IS: - AI as a coding assistant for translating your HTA logic into R - A tool to speed up model development - Useful for debugging errors and learning R syntax - One tool among many in your workflow

ISN’T: - AI doing your HTA for you - A substitute for clinical expertise - A replacement for validation and peer review - Able to choose model structure or parameters for you

Mindset: AI is a very fast but occasionally unreliable research assistant who knows R syntax but nothing about your clinical question.

The GenAI-Assisted HTA Workflow

Figure 1

When AI Is Useful for HTA Work

AI excels when: - You know what to calculate but not how to write it in R - You have working code and need to modify it - You get an error and need help understanding it - You’re converting Excel-based logic into R - You’re looking up which function or package does something

AI is NOT reliable for: - Choosing model structures - Selecting clinical parameters - Validating whether your model is correct - Replacing peer review or expert input

The Key Principle: Package-Based Prompting

You’ve seen both approaches in this workshop:

• Session 5: Manual Markov from scratch (matrix multiplication, HCC, discounting by hand)
• Session 5 Bonus: Same model with heemod — package handled everything

When using AI: always tell it which package to use.

A naive prompt → raw loops with hidden bugs.

A package-constrained prompt → validated engine does the heavy lifting.

The Golden Rule

Always include this sentence in your prompt:

“Use the [package name] package. Do not write manual loops.”

Model Type	Package
Decision Tree	rdecision
Markov	heemod
PSM	flexsurv + manual wrapper
DSA/PSA	Same as base case package
CE Visualization	BCEA or dampack

The Staged Workflow

Step 1: Prepare parameter file in Excel (your single source of truth)

Step 2: Prompt for base case → “Attached my parameter file. Use heemod.”

Step 3: Validate — cross-check against hand calculations

Step 4: Prompt for DSA + PSA → “Base case works. Add sensitivity analysis.”

Step 5: Prompt for Shiny app → “Wrap validated model in interactive dashboard.”

Stage 2: The Base Case Prompt

I've attached my parameter file (Excel).
Build a Markov cost-effectiveness model using the
heemod package. Do NOT write manual matrix
multiplication. Report ICER with 4-quadrant
interpretation and NMB. Use kable() and ggplot2.

The parameter file carries the detail. The prompt just says what to do with it.

Stage 4: DSA + PSA Prompt

The base case works. Now add sensitivity analysis
using the same model object.

DSA: use define_dsa() with low/high from my file.
PSA: use define_psa() with distributions from my file.
Report mean incremental NMB, P(cost-effective).
Do NOT average ICERs — use NMB instead.

Stage 5: Shiny App Prompt

I have a validated Markov model built with heemod.
Create a Shiny app with:
- Sidebar: sliders for key parameters + "Run PSA" button
- Tab 1: Base case (table + trace plot), updates reactively
- Tab 2: Tornado diagram, updates reactively
- Tab 3: PSA (CE plane + CEAC), updates on button click

Validate Before You Trust

Critical questions to ask:

• Does it use the right package? If you see for (cycle in 1:n) instead of define_transition(), push back.
• Do results match your manual model? Cross-validate at default parameters.
• Are distributions parameterized correctly? Beta needs α/β, not mean/SD.
• Is the ICER interpretation correct? Check all 4 quadrants, not just icer < wtp.

Common Pitfall 1: Wrong Distribution Parameterization

AI might write:

# WRONG: using mean and SD directly
beta_distribution <- rbeta(5000, mean = 0.10, sd = 0.02)  # This doesn't work!

Correct approach:

mean_p <- 0.10
se_p <- 0.02
alpha <- mean_p * (mean_p * (1 - mean_p) / (se_p^2) - 1)
beta <- (1 - mean_p) * (mean_p * (1 - mean_p) / (se_p^2) - 1)
samples <- rbeta(5000, alpha, beta)

Lesson: Always check if distribution parameterization matches your source data.

Common Pitfall 2: Forgotten Half-Cycle Correction

AI-generated Markov models often omit half-cycle correction.

If you don’t see this in the code, ask:

“Add half-cycle correction to this Markov model.”

What it does:

trace_hcc <- (trace[1:n_cycles, ] + trace[2:(n_cycles + 1), ]) / 2

Accounts for the fact that patients spend time both in their current and next state during each cycle.

Common Pitfall 3: Wrong HR for Survival Models

A real bug we found in this workshop:

• Proportional hazards (correct): S(t) = exp(-(λ × HR) × t^γ) — scales hazard
• AFT (different model): S(t) = exp(-λ × (HR × t)^γ) — scales time

Both valid, but give different results when γ ≠ 1. Always specify “proportional hazards, not AFT.”

Common Pitfall 4: Averaging ICERs in PSA

AI-generated PSA code often reports “mean ICER” across iterations.

Problem: A few iterations with near-zero ΔQALYs produce extreme ICERs that distort the average.

Solution: Always use NMB-based reporting in PSA:

inc_nmb <- wtp * inc_qaly - inc_cost  # Per iteration
mean(inc_nmb)                         # Safe to average
mean(inc_nmb > 0)                     # P(cost-effective)

Common Pitfall 5: Hallucinated Functions

AI sometimes invents R functions or packages that don’t exist.

?function_name  # Try this in the R console

If it returns “no documentation found,” the function is fake.

A Sensible Workflow

1. Prepare parameter file in Excel — single source of truth
2. Prompt for base case — short prompt, attach the file, name the package
3. Validate — cross-check against hand calculations or Excel
4. Prompt for DSA + PSA — once base case is solid
5. Prompt for Shiny app — once everything is validated
6. Use AI for debugging — paste errors and get explanations
7. Save working code — it becomes your template for next time

Available AI Tools for HTA Coding

Tool	Strengths	Limitations
Claude	Good at R, explains reasoning well	Limited free tier
ChatGPT	Widely available, fast	Sometimes generic
Copilot	Integrated with VS Code	May suggest outdated packages
Gemini	Free, multimodal	R knowledge variable

Recommendation: Use the tool you have access to. The key is prompt quality, not which tool.

Key Takeaway

Your parameter file + validated package + AI coding = production-ready model

Your expertise determines: model structure, parameter choices, clinical interpretation.

AI helps translate that into working R code — faster, not better.

Think of AI as a very fast but literal-minded colleague: it will do exactly what you ask, so ask precisely.

Final Thought

When you use AI for HTA coding, you are not replacing expertise. You are amplifying it:

• Your clinical knowledge → AI’s coding speed
• Your HTA logic → AI’s syntax accuracy
• Your validation → AI’s suggestions

The HTA work is still yours. The code is now just faster to write.

You have completed Day 2 of the workshop:

• Session 5: Markov models
• Session 6: Probabilistic sensitivity analysis
• Session 7: AI-assisted HTA coding

Next: Day 3 — Advanced topics and practice exercises