Policy Evidence File · local only
Collect the observations that a policy claim would need.
This workbench keeps authority, implementation, exposure, measurements, comparison, rival explanations, and owner translation in one inspectable local file. It does not upload records, calculate a policy effect, or approve causal language.
Before you begin
Keep records elsewhere; use coded locators here.
The workbench is designed for public sources and coded references to authorized local records. It checks for a small set of obvious direct identifiers and credentials before export, but it cannot determine whether a file is confidential, privileged, de-identified, contractually restricted, or legally shareable.
Exact policy dates are allowed because adoption, effect, and operation must be distinguishable. Do not include exact patient event dates or patient-level data.
1 · Decision boundary
Name the policy, jurisdiction, exposure, and claim.
A broad label such as “insurance reform” is not a unit of analysis. Select one mechanism and write the decision question it is supposed to inform.
2 · Authority and implementation
Do not use one date for three different events.
Adoption, legal effect, and operational exposure can occur months or years apart. Preserve each separately.
3 · Measurement rows
Collect each link and its counterevidence.
Values remain text because one metric can be dollars, days, people, rates, counts, or a verified status. Define the unit explicitly and keep missing observations blank.
What operational event made the policy usable or enforceable?
Which plans, practices, clinicians, patients, services, products, and periods were actually affected?
Did the relevant allowed amount, benefit, award, premium use, or patient obligation change?
Did submission, denial, rework, credentialing, recoupment, payment fee, or days-to-cash change?
Did applications, eligibility, privilege issuance, accepted offers, vacancy duration, or retained clinical days change?
Did participation, staffing, hours, clinical capacity, payer mix, capital, or owner behavior change?
Did completed access, wait time, avoidable ED use, owner runway, or another pre-specified outcome change?
What comparable unit or time series estimates what would have occurred without the policy?
What evidence shows no change, an unintended effect, or a different mechanism?
4 · Calibration checks
One failed safety check can limit the conclusion.
These states are not averaged. “Met” should identify the supporting document; “Failed” should explain the defect.
Controlling authority
The official authority, version, scope, exclusions, and jurisdiction are verified.
Operational implementation
The required implementation event and operational date are verified rather than assumed from enactment.
Exposure denominator
Affected and unaffected units are defined with an inspectable denominator.
Stable measurement
Numerator, denominator, unit, geography, product, and data-generation process are stable or breaks are documented.
Baseline and lag
The pre-period and implementation lag are long enough for the proposed mechanism.
Comparison design
The comparison case or time-series design addresses changes that would have occurred without the policy.
Rival explanations
Concurrent policy, economic, payer, workforce, ownership, coding, technology, and enforcement changes are tested.
Owner translation
Public observations are connected to the target practice through exact contracts, operations, costs, cash, capacity, and household facts.
Requested level: Source discovery only. This status is a workflow warning, not an expert determination or validation score.
5 · Interpretation
Write the case against your preferred explanation.
6 · Portable local record
Export the evidence—not a prediction.
JSON resumes the full local draft. CSV carries the ten measurement rows. Print creates a review copy.
Project code is required; Policy mechanism is required; Jurisdiction is required; Decision question is required