LogicPearl turns payer policy PDFs into exact rules, reads the patient's chart (even scanned or handwritten notes), and shows whether a case is ready, blocked, or missing evidence, with a versioned audit trail for every result.
Five stages. LogicPearl compiles the policy, reads the packet, and decides. Your systems supply the case and receive the result.
Published payer medical policies, as issued: tables, exceptions, nested criteria and all.
Each policy becomes a versioned set of checkable criteria, and every criterion keeps its verbatim source sentence and page.
Faxes, scans, and handwriting are read, and each finding is marked as present, absent, historical, hypothetical, or family history. Extractors you already run can feed this step too.
Only evidence about the patient, present now, can satisfy a criterion. Weak or missing support goes to review with the reason attached.
Ready, blocked, or missing evidence, with the blocking criterion, what would make it ready, the next action, and a record that can be replayed later.
Three examples of what the evidence layer resolves.
| In the chart | What LogicPearl records | Why it matters |
|---|---|---|
| "Intracept" · "BVN RFA" · "basivertebral nerve ablation" | One requested service | The criterion matches whichever name the chart used. |
| "Mother has rheumatoid arthritis." | Family history, not the patient | It can't satisfy a criterion about the patient. Summaries often get this wrong. |
| "No radiation below the knee." | A documented absence | Exclusion criteria can use it the way the policy says. |
Uncertainty shows up before a case does: the clauses the compiler couldn't cover are kept as review work, and policies without full support stay out of automatic checks.
Measured on the Blue Cross Blue Shield of Massachusetts policy corpus. The same coverage accounting can run against any payer policy set before a pilot starts.
Models help find the evidence; policy rules make the readiness decision. In one experiment, 8 model groups gave 20 approvals and 4 denials on the same packet and policy.
| An AI checklist | A LogicPearl result | |
|---|---|---|
| Source excerpt per criterion | Often omitted or summarized | Every criterion tied to source PDF text |
| Clause coverage accounting | Usually unmeasured | 99.9% measured on BCBSMA; misses preserved as review work |
| Nested AND/OR & exceptions | Can flatten or invert | Preserved in the decision logic |
| Table semantics | Frequently flattened | ~118k rows interpreted into checkable rules |
| Terminology provenance | Implicit / hidden | Explicit mapping status per criterion |
| Repeatable replay | Can vary on the same packet | Same packet and policy version → same result |
| Reviewer state | Answer only | Promotion gated, sign-off tracked |
| Packet-to-policy evidence link | Not guaranteed | Click-through packet and policy excerpts |
Run the same case against the April source set and it routes to review. No covering policy existed yet. Run it against June, where a new policy took effect on the first, and it decides. Same case facts; the source set changed. That is an explanation an auditor accepts, and a model can't give.
When a payer updates a policy PDF, LogicPearl shows what changed between versions and which open cases it affects, before they surprise you.
When a denial comes back, the first question is which criterion it turned on.
LogicPearl keeps the rule, the evidence, and the policy version bound to every result, so an appeal starts from the exact criterion the payer applied and the chart page that meets it.
Results come back in the form your systems already use.
The prior-auth walkthrough runs the whole pipeline in your browser, on published payer policy.