Technical Report Writer

The Challenge

Building a health economic model is only half the job. Every model requires a comprehensive technical report that documents its structure, assumptions, parameter sources, and results with enough rigor to satisfy HTA reviewers, payers, and scientific peers. A model without proper documentation is a liability, regardless of how sound the underlying analysis is.

The reporting burden is not just about describing the model. A complete technical report must cover the full scope of the analysis: the rationale behind structural choices, the methods for each modeling domain (population, transitions, efficacy, costs, utilities, and more), the base case results and their interpretation, and the sensitivity analyses that test the robustness of those results. Each of these requires the writer to re-read model inputs, cross-reference specification documents, extract results from the model itself, and translate all of it into clear, technically precise prose.

Beyond the methods narrative, the report must include analytical interpretation. What do the base case results mean for the cost-effectiveness question? Which parameters drive the most uncertainty? How robust is the conclusion across probabilistic and deterministic sensitivity analyses? These interpretive sections require the writer to not only understand the model but to synthesize its outputs into a coherent analytical story. When this work is done manually, a single report can consume two to four weeks of concentrated effort, and the timeline resets whenever the underlying model changes.

How It's Done Today

Technical report writing typically begins after the model is complete, which means it sits directly on the critical path to submission. A writer, often the health economist who built the model or a dedicated medical writer, starts by going back through the model itself: re-reading the specification, extracting parameter values from input sheets, running the model to capture results, and assembling sensitivity analysis outputs. This collection and re-familiarization phase can take days, even though the writer may have been involved in building the model.

The methods section alone requires covering a dozen distinct modeling domains: model overview, patient population, treatment strategies, health states, transitions, efficacy, mortality, discontinuation, clinical events, costs, utilities, and discounting. Each domain must be described accurately and consistently, with the right level of technical detail for the intended audience. The results section requires extracting base case outputs, computing incremental results, and writing interpretive narrative that explains what the numbers mean for the cost-effectiveness question. If sensitivity analyses were performed, the writer must generate figures (tornado diagrams, scatter plots, cost-effectiveness acceptability curves) and write interpretation that synthesizes deterministic and probabilistic findings into a coherent robustness assessment.

The result is a process that routinely takes two to four weeks per report, absorbs significant senior time, and still produces first drafts that require multiple revision cycles. Teams running multiple submissions simultaneously face a near-constant documentation backlog, with report completion regularly delaying HTA submissions and stakeholder approvals.

The AI-Enabled Approach

Technical Report Writer picks up where Model Coder leaves off. Once your health economic model has been built and validated, the system reads directly from the model artifacts: the structural features extracted during model construction, the parameter inputs, the base case results, and the sensitivity analysis outputs. There is no re-uploading, no re-describing, and no manual extraction. The system already has everything it needs because it built the model.

The system begins by generating a model schematic: an AI-created Markov state transition diagram that visually communicates the model structure. From there, it launches twelve parallel writing processes, each producing one section of the methods report: model overview, patient population, treatment strategies, health states, transitions, efficacy, mortality, discontinuation, clinical events, costs, utilities, and discounting. Each section is grounded in the actual structural features and parameters of your specific model, not generic template prose. The twelve sections are then assembled into a formatted Word document with the schematic, summary tables, and consistent terminology throughout.

The system then moves to results and sensitivity analysis. It extracts base case and incremental results, generates trace plots and cost-effectiveness plane figures, and writes interpretive narratives covering base case findings, cost drivers, clinical outcomes, and policy implications. If sensitivity analyses are available, the system generates tornado diagrams, probabilistic scatter plots, and cost-effectiveness acceptability curves, then writes structured interpretation of what those analyses reveal about the robustness of your results. The final deliverable is a combined Word document covering methods, results, and sensitivity analyses, complete with figures, tables, and analytical narrative. This works for both Excel and R models, maintaining the dual-platform consistency established by the Coding module.

What It Means for You

• The reporting step requires no additional input from you. The system reads directly from the model artifacts produced during coding, so there is no re-uploading, no manual extraction, and no re-describing of model structure.
• You receive a complete technical report covering twelve methods sections, base case and incremental results with interpretation, and sensitivity analysis findings with figures. All generated from your actual model, not generic templates.
• Sensitivity analysis outputs are not just presented but interpreted: the system explains which parameters drive the most uncertainty, how robust the base case conclusion is, and what the probabilistic findings mean for the cost-effectiveness question.
• Figures are generated automatically: model schematic, state occupancy traces, cost-effectiveness plane, tornado diagrams, probabilistic scatter plots, and cost-effectiveness acceptability curves. All embedded in the final document.
• Reports are produced for both Excel and R models, maintaining the dual-platform consistency from the Coding module through to final documentation.
• What previously required two to four weeks of concentrated writing effort is delivered as a structured, formatted Word document, removing documentation from the critical path to submission.