INAHTA HTA Checklist
A 17-item, 5-domain transparency checklist developed by the International Network of Agencies for Health Technology Assessment (INAHTA) to promote consistent, transparent reporting of health technology assessment reports — explicitly a reporting/transparency aid, not a quality scorecard.
What it is
— The INAHTA HTA Checklist (formally the Checklist for HTA Reports, Hailey 2003) is a 17-item instrument, grouped into five domains, developed and maintained by the International Network of Agencies for Health Technology Assessment (INAHTA) — the global network of publicly funded HTA bodies (NICE, CADTH, IQWiG, HAS, and ~50 others). It was built by summarizing the key elements of HTA reports, drawing on agency experience and existing HTA guidelines, then circulating for consensus among member agencies. Its purpose is narrow and explicit: to further a consistent and transparent approach to reporting HTA, so that a reader can tell what question was asked, how the assessment was done, what was found, and what it implies. The five domains are: (1) preliminary information (authorship, contact, review status, links to other reports); (2) why and how the assessment was prepared (the policy/research question, scope, methods for retrieving and appraising evidence, sources of data); (3) the results of the assessment (findings on effectiveness, safety, and economic considerations, with stated assumptions and uncertainty); (4) implications and limitations (medico-legal, ethical, social, and organizational implications; limitations of the report); and (5) conclusions and recommendations (clearly distinguished from results). It is a short, agency-level reporting/transparency tool — not a measurement method and not a critical-appraisal/risk-of-bias instrument.
When to use
— Use the INAHTA checklist when producing or reading a full HTA report intended for a coverage, reimbursement, or health-system decision — i.e., a document that integrates clinical effectiveness, safety, and economic evidence (cost-effectiveness/cost-utility, budget impact) plus organizational/ethical/social implications, rather than a single primary study. It is the natural transparency backbone for an HTA/payer dossier and for agency-issued assessments. Decision rules for choosing this tool versus siblings: if you are reporting the economic model itself, CHEERS 2022 is the correct reporting guideline and INAHTA sits above it as the report-level wrapper; if you are reporting the systematic-review component, use PRISMA 2020 for the synthesis and INAHTA for the overall report; if you are appraising the methodological quality/risk of bias of the included evidence, INAHTA is the wrong instrument entirely (use ROBINS-I, RoB 2, AMSTAR 2, or GRADE). INAHTA governs how the assessment as a whole is reported and made transparent, not how any one piece of evidence was generated or graded.
What it requires
— Framed for real-world-evidence-heavy HTA submissions, the checklist's domains demand explicit documentation of: the policy and research question and scope (population, intervention, comparator, outcomes, setting — the PICOTS that anchors the assessment); the methods for identifying, selecting, and synthesizing evidence, including which data sources were used and why (claims, EHR, registry, linked data) and their fitness for the decision question; the design and analytic choices behind any real-world comparative analysis (time-zero alignment, comparator selection, confounding control, attrition/missing data, and the estimand actually targeted); the results with assumptions and uncertainty made visible (effectiveness, safety, and economic findings, with sensitivity/scenario analyses); the implications (transferability/generalizability to the decision context, plus ethical, legal, social, and organizational consequences); and conclusions kept distinct from results. For RWE used in HTA, the checklist effectively forces a reader to see whether the real-world evidence is fit for purpose, whether the comparison is causally interpretable, and where residual uncertainty lies — without itself prescribing the methods.
When NOT to use — limitations and common misapplications
— The single most important caveat is INAHTA's own: the checklist "is not intended to be viewed or used as a scorecard to rate HTA reports," and reports "may be valid and useful without meeting all the criteria." Treating item counts as a quality score is the canonical misuse — it is a reporting/transparency aid, not a risk-of-bias tool and not a quality rating. Other failure modes: (1) Completing the checklist does not make the underlying evidence sound — a fully transparent report can rest on a confounded, immortal-time-biased real-world analysis; transparency reveals problems, it does not cure them. (2) Wrong instrument for the layer of work — using INAHTA to appraise an individual study (use ROBINS-I/RoB 2), to grade certainty of a body of evidence (use GRADE), to appraise a systematic review's conduct (use AMSTAR 2), or to report an economic evaluation in detail (use CHEERS 2022). (3) Checklist-as-theater — pasting a completed checklist into an appendix while the body of the report still omits the comparator rationale, data-source fitness, or sensitivity analyses; the checklist is satisfied in form but defeats its own purpose. (4) Over-reach onto primary research — it was designed for agency-style HTA reports, not for a stand-alone pharmacoepidemiology manuscript, where STROBE/RECORD-PE/HARPER apply.
How it maps to this catalog
— Each checklist domain points to the concept(s) in this repo that actually implement the requirement. Scope / research question: picots-framework-rwe structures the population-intervention-comparator-outcome-timing-setting frame the checklist's "why and how" domain demands. Data identification and fitness: fit-for-purpose-data-assessment-rwe and claims-analysis establish whether the claims/EHR/registry source can answer the decision question. Design and causal interpretability of any RWE comparison: target-trial-emulation, active-comparator-new-user, time-zero-index-date-alignment-rwe, diagnosis-phenotype-algorithm-1ip-2op-time-window-rwe (case-finding/phenotype validity), high-dimensional-propensity-score-hdps-rwe (confounding control), estimands-ate-att-intercurrent-events-rwe (the estimand actually reported), and attrition-and-loss-to-follow-up-rwe (follow-up completeness). Results, uncertainty, and sensitivity: quantitative-bias-analysis-toolkit-rwe and e-value-sensitivity-analysis make residual-confounding uncertainty explicit; the economic findings draw on cost-effectiveness, cost-utility, icer-net-monetary-benefit-rwe, budget-impact, and (for long-run modeling) survival-extrapolation-hta-rwe. Implications / transferability: generalizability-transportability-external-validity-rwe addresses whether the evidence carries to the decision context. Applied note (claims/EHR/registry RWE): when an HTA dossier leans on a claims-based comparative analysis, the checklist's transparency domains are satisfied only if the report names the database and its FFS/MA/commercial coverage limits, defines the phenotype/outcome algorithms and their validation, fixes time zero, states the comparator and confounding-adjustment strategy, reports attrition through the analytic funnel, and shows sensitivity/quantitative-bias analyses — i.e., the checklist is a transparency wrapper that the listed concepts fill in.