Yesterday, I created an official project for the Auth-to-Claim Reconciliation Engine using Linear (and using April’s engineering journal to help reverse engineer portions of it). Currently, I have 6 initiatives, the first focusing on the Core Reconciliation Engine (i.e., the deterministic foundation). This Reconciliation Engine initiative is supported by 4 projects (subject to change), each of which answers a specific question:
- Business Domain Foundation - What problem am I solving?
- Synthetic Data Foundation - What data do I need?
- Deterministic Matching Engine - How do I identify & reconcile claims and authorizations?
- Identity Resolution - How do I know which records belong to the same person?
Since it’s been several months since I’ve worked on this project, it’s worth revisiting the project objective and take inventory of what I’ve built so far.
In short, I’m focusing on verifying the authorization status of a healthcare service (or prescription medication) against the corresponding payment claim. The POC falls between the prior authorization and the claim.
My initial goal via the Core Reconciliation Engine initiative is to find and begin understanding the matching exceptions.
The first program I created (auth_to_claim_matcher.py) loads five (5) CSV datasets (authorizations, claims, member eligibility, providers, and drug reference), matches claims to prior authorizations and runs a rules-based matching pipeline to classify each claim (e.g., clean match, quantity mismatch, date mismatch, provider mismatch, or no matching authorization found). This program also provides an explanation and a recommended next action (neither of which uses LLMs). For date mismatches, the script populates a separate CSV file with additional fields for downstream review.
Here are two sample outputs, formatted for readability:
Auth-to-Claim Reconciliation Results
claim_id: CLM-9001
auth_id: AUTH-1001
match_status: MATCH
exception_category: CLEAN_MATCH
explanation: Member, provider, normalized drug, quantity, service date window, and site of service align.
recommended_action: No action required. Claim aligns to authorization.
claim_id: CLM-9003
auth_id: AUTH-1003
match_status: MISMATCH
exception_category: DATE_MISMATCH
explanation: Service date 2026-03-05 is after authorization end date 2026-02-28. Route to date/window validation.
recommended_action: Confirm grace-period applicability, retro-auth eligibility, and whether the service date can be accepted or requires manual review.As indicated, there are numerous exceptions, each of which requires its own logic:
From this larger set, I decided to focus my attention on just two “agents”:
- One specifically for date mismatches
- A second for when there is a missing authorization - i.e., “is there anything that can explain why the match failed?”
The current exploration can be visualized as follows:
Tomorrow, I’ll revisit the Missing Authorization logic and introduce LLM connectivity (via Crew.ai) to provide natural-language explanations for tiered search results.