Claims Implementation Specification Worksheet
An editable source-to-analysis specification for claims fields, enrollment and benefit capture, code lists, dates, medication episodes, outcome validation, follow-up, and algorithm QA cases.
On this page
What this is
A field-level specification that turns protocol and SAP choices into reviewable claims algorithms. It includes a source-field map, observability records, code-list register, date and exposure rules, endpoint specification, follow-up events, and synthetic implementation tests.
When to use
Complete it with the data holder, analyst, and clinical/methods owners before cohort construction. Revisit it when the data release, terminology, benefit coverage, or algorithm changes. Keep source-specific behavior explicit rather than inferring it from familiar column names.
What it requires
Specify member identifiers, actual table/field names, enrollment and medical/pharmacy capture, source/version, code-list releases, claim date semantics, paid/rejected/reversed transactions, duplicate and episode rules, days supply, early refills, switches, and restart. Distinguish drug-supply runout from claims adjudication lag and data maturity. Document outcome validation and the consequence of each end-of-follow-up event for the target estimand.
Synthetic tests
The worksheet supplies cases for basic supply runout, overlapping refills, a reversal, duplicate inpatient lines, loss of observation, and a setting-specific phenotype. Expected outputs depend on the chosen and approved algorithm. Passing these cases tests programming logic; it does not establish clinical phenotype validity.
When not to use
Missing pharmacy or medical records do not prove no treatment or no event. A plausible code list does not establish sensitivity or predictive value. Do not silently select a grace period, stockpiling cap, censoring rule, or phenotype because a worksheet field is blank.
How it maps to the catalog
Pair with the payer observability checklist, protocol-to-SAP handoff, STaRT-RWE, and analysis readiness templates. FDA guidance informs data relevance and reliability; RECORD-PE supports transparent reporting.
Downloads
Word template · Markdown · Excel workbook · Build prompt · Review prompt
Model assistance
Complete kit ZIP · Instructions · Portable SKILL.md. Keep the folder together. Use the separate review prompt on the actual completed artifacts; the model must preserve missing facts and unapproved choices as unresolved.
Checklist
- Map actual source fields and extract versions to every analytic input.
- Confirm benefit and care-setting capture before interpreting absence of claims.
- Version code lists and explicitly select transaction, date, episode, runout, and follow-up rules.
- Record phenotype validation evidence or its absence, plus synthetic input and expected-output cases.
- Have data, clinical, and methods owners resolve consequential choices before implementation.
Citations
- [1]U.S. Food and Drug Administration. Real-World Data: Assessing Electronic Health Records and Medical Claims Data To Support Regulatory Decision-Making for Drug and Biological Products. Guidance for Industry. July 2024.
- [2]Wang SV, Pinheiro S, Hua W, et al. STaRT-RWE: structured template for planning and reporting on the implementation of real world evidence studies. BMJ. 2021;372:m4856.
- [3]Langan SM, Schmidt SAJ, Wing K, et al. The reporting of studies conducted using observational routinely collected health data statement for pharmacoepidemiology (RECORD-PE). BMJ. 2018;363:k3532.