Every coverage answer this tool gives comes from a document a payer published. That sounds reassuring until you actually open one. Formulary files are built for compliance filing, not for reading at the point of care, and the gap between “the data is public” and “the data is usable” is where most of the work lives.
Here is the process we run before any category goes live, and why each step exists.
Parse, then distrust the parse
Machine extraction from a PDF is the fastest way to be confidently wrong. A column that shifts by one row halfway down a page produces output that looks perfectly well-formed and is entirely wrong. Nothing about the file’s structure tells you it happened.
So the parse is never the deliverable. It is a first draft that gets checked category by category against the source document before anything ships.
Where a value cannot be confirmed, it stays NULL and gets flagged for review. An empty field a clinician can see is honest. A plausible guess is not, and at the point of prescribing the difference matters.
What gets checked
Each category goes through the same five checks. They are deliberately boring; the failures they catch are not.
| Check | What it catches | Method |
|---|---|---|
| Row alignment | Column drift mid-page | Spot-check first, middle and last row of every page against the PDF |
| Tier integrity | Tiers outside the plan’s declared range | Assert against the plan’s own tier legend |
| Flag parity | Prior-auth / step / quantity flags dropped in extraction | Count flags in source vs parsed, per category |
| Orphan drugs | Entries with no matching category | Reject on load; never silently bucket |
| Effective date | Stale files presented as current | Every row carries its source and effective date |
Why the effective date travels with the row
Formularies change. A file that was correct in January is a liability in June, and the clinician has no way to tell the difference from the answer alone. Attaching the source and its effective date to every individual row rather than to the dataset as a whole means the interface can always say how old a given answer is.
The tool is decision support. It should make it easy to see what it knows, and just as easy to see what it does not.
The limits, stated plainly
Three things this process does not fix, and we would rather say so than let a prescriber discover them:
- Published data can lag the payer’s live system. A formulary file reflects the payer’s position when it was filed, not necessarily this morning.
- Coverage is not the same as adjudication. Benefit design, accumulators and pharmacy contracts all sit between “on formulary” and “what the patient pays”.
- Category-level review is not row-level proof. We check categories thoroughly and sample within them; we do not claim to have hand-verified every row.
What that means in the room
It means the answer on screen is a strong prior, not a determination. It narrows the search from “which of these forty drugs might be covered” to “these three probably are, and here is what the plan wants for each”. The callback to the pharmacy does not disappear. It gets much shorter, and much less frequent.
Not a coverage determination. Always verify coverage and any utilization-management requirements with the payer before relying on them for a specific patient.
Sources
- Centers for Medicare & Medicaid Services. Prescription Drug Plan Formulary Public Use File. cms.gov
- South Carolina Department of Health and Human Services. Preferred Drug List. scdhhs.gov