Methodology
How CLV Intelligence monitors, scores, and verifies
Every alert in CLV Intelligence is the output of the same disciplined process — sourced from official government records, scored by impact, priced to the CMS fee schedules, and linked back to the document it came from. This page explains exactly how that works, so you can judge the alerts on their methodology, not on our word for it.
1. How we monitor
CLV Intelligence ingests from official government and regulatory sources every business day: the CMS Medicare Coverage Database (LCDs and NCDs), CMS Transmittals (Publication 100-04), the Physician Fee Schedule and OPPS, NCCI edits, the Federal Register, the OIG, and FDA drug approvals. Local Coverage Determinations and Billing & Coding Articles from every Medicare Administrative Contractor — all 16 MAC jurisdictions, both A/B and DME — reach us through the CMS Medicare Coverage Database, which is where the contractors publish them and where we read them. We do not poll contractor sites. Ingestion runs on a fixed daily schedule; you can see the live status, including the last run and the 9 source families monitored, at /data-status. The complete list of sources is documented on the data sources page.
1b. What we watch, and what we publish
Those are the sources our alerts are built from. Separately, a monitoring service reads a small set of primary endpoints that are notalert sources — the Federal Register’s public-inspection desk filtered to CMS, the eCFR amendment log for 42 CFR (the part of the regulations the Medicare programme lives in), and the change timestamps CMS publishes for its own coverage, LCD, NCD and transmittal pages. It records each item with its source link and stores it for review.
Watching a source is not the same as publishing from it, and we keep the two apart on purpose. Nothing that service records appears in your feed by virtue of having been recorded. It becomes an alert only by passing the same verification, scoring and source-link check described in the sections below — the identical gate every alert already goes through. So this widens what we are looking at; it does not change what we have published, and the alert counts on this site are unaffected by it.
The last of those closes a specific gap. Everything else we do with a coverage determination assumes we already hold it — so until now, nothing told us when a determination was newly published or revised. Watching the change timestamps is what detects that. It is detection, not delivery: it tells us to go and look, and what we find still has to clear the gate above before it reaches you.
We are deliberately not putting a speed or freshness figure next to this. A claim about how much earlier we see something is only worth making with a published method and enough run history to stand behind the number, and we do not have that yet. When we do, it will appear with both.
2. How we score — the signal score
A date-ordered list of changes assumes you have time to read everything. We don’t make that assumption. Every change is rated by a signal score built from four factors, so the changes most likely to cost revenue or trigger a denial surface first:
Recency
How recently the change was published. Newer changes weigh more, because the window to act is widest right after publication.
Effective-date urgency
How soon the change takes effect. A change with a near-term effective date is more urgent than one effective next year.
Source authority
The weight of the issuing source. A CMS National Coverage Determination or final rule outranks a routine administrative notice.
Change type
What kind of change it is. A coverage restriction or code deletion outranks an informational update — it’s more likely to cause a denial.
The combined score sorts the feed into tiers — critical, high, and routine — so a coverage restriction with a near-term effective date leads the feed while administrative notices settle to the bottom. The same scoring powers the action guidance attached to each alert: a plain-language summary of what changed and what to do.
3. How we verify
Every alert links directly to the originating government document — the transmittal, LCD, NCD, or Federal Register notice it came from — and those source links are verified at ingestion. We do not paraphrase a change and ask you to trust the summary: the summary is there to triage, and the source is there to confirm. That source-first design is also what makes the alerts usable as audit documentation, because a reviewer can follow every claim back to its government origin.
4. How we track what payers changed
Each year every Medicare Advantage plan files a Plan Benefit Package with CMS, recording — among much else — whether a benefit category requires prior authorization. CMS publishes those filings. We hold four plan years of them and compare a plan against itselfa year earlier, then attribute the result to the parent organization using CMS’s own contract file.
This is what plans reported, not what we observed. We do not see adjudication, we hold no payer contracts, and nothing here predicts how an individual claim will be handled. It is a public filing, read carefully.
- · A plan that stopped answering has not dropped the requirement.The filing allows three states — yes, no, and no answer. Counting “stopped answering” as “removed prior authorization” would tell a biller to stop obtaining it, so a change involving a blank is recorded as a change in disclosure and never as a change in what the plan requires.
- · Only plans present in both years are compared.A plan launched this year has no prior posture to have changed from; counting it would manufacture movement out of a plan’s first year.
- · Medicare Advantage contracts only.PACE and Section 1876 Cost contracts appear in the same CMS extract and are excluded — they are not Part C, and including them would inflate every figure.
- · Each year is its initial filing. CMS also publishes mid-year amendments; mixing those in would report amendment churn as annual change.
The result is public at prior-auth changes. Percentages are computed over plans that answered; blanks are excluded from the denominator rather than counted as “no”.
5. How we price exposure
The dollar exposure on an alert is not a heuristic — it is priced from the actual CMS fee schedules, code by code, at the national payment amount (2026). Three fee schedules cover the codes an alert can touch, and each priced line names the exact government file it came from:
- Physician Fee Schedule (PFS) — physician and procedure codes, from the CMS PPRRVU national payment file.
- Clinical Laboratory Fee Schedule (CLFS) — lab and molecular diagnostic codes, at the national rate.
- DMEPOS — durable medical equipment, orthotics, and prosthetics. DME is paid by the beneficiary’s state of residence, so a DME figure uses your billing state and is labeled a benchmark, not a single national number.
A code that none of these schedules prices renders “—”, never a guessed dollar figure — the same NULL-over-fabricated rule that governs our dates. That is why the exposure number is auditable: every line traces to a named CMS file and year, or it is honestly blank.
6. How we hold a policy as of a date
CMS serves the current version of a coverage policy; it does not serve the versions that came before. So on a fixed schedule we capture the full text of every policy we hold, hash it, and keep each distinct version with the date we captured it and the document’s own effective and revision dates. When a denial check or an appeal packet asks what the policy said on a date of service, it is answered from the version whose window covers that date — and when the version we hold cannot be shown to have been in force on that date, the result says so in those words rather than presenting today’s text as if it had been.
The same rule governs the free denial check and the partner packet: a finding is offered only when a policy we hold for that state lists the diagnosis and the version is verified for the date. Otherwise the answer is a refusal that states its reason — no policy held, the diagnosis not listed, or the date unverified — and nothing is charged. Live counts of versions held are on /data-status.
7. How we keep the WISeR program rules current
Which procedures WISeR reviews, in which states, and what CMS lists for the record come from the CMS WISeR Provider and Supplier Operational Guide, which CMS revises several times a year. The authorization check shows its documentation checklist for the service word for word, with the guide’s version and last-updated date and a link to the guide. Only CMS’s own sections and procedure codes are kept; the code descriptions in the guide’s tables are licensed text, and we do not reproduce them.
Every week we fetch the guide again, keep each new version, and compare it with what the check shows. A difference is reviewed by a person before the check changes. The check never switches to new rules on its own, because a changed rule that nobody has read is the kind of error this process exists to prevent.
What we deliberately don’t do
- We don’t process PHI. CLV Intelligence reads only publicly available government policy — never patient data or claims. No protected health information enters the platform, so there’s no HIPAA exposure and no BAA required.
- We don’t give legal or compliance advice. Alerts surface and summarize official changes so you can act in time; they are not an audit certification or a substitute for qualified compliance counsel.
- We don’t fabricate dates or details. When a source doesn’t publish a real date, the field stays empty rather than guessed — a NULL is always preferable to a fabricated value.