Build Journal (Authorization Discovery Exploration)

Journal Summary

Generated by ChatGPT

The user validated the retro-authorization and grace-period calculations after generating expanded datasets containing retro-auth and timing fields. Through testing several realistic scenarios, the user confirmed that the deterministic date-validation logic could correctly identify valid grace-period claims and retro-eligible authorizations. Rather than immediately reintegrating the logic into the main application, the user intentionally paused implementation to focus attention on a more advanced third agent: the Authorization Discovery Agent, which would require more sophisticated reasoning and investigative capabilities.

The remainder of the day was devoted to understanding why missing authorizations occur and how investigative search logic should work. The user identified identity normalization as a foundational challenge and introduced the concept of a “member ID crosswalk” to reconcile different member identifiers across claims, authorization, and eligibility systems. Using concrete claim examples, the user manually explored how timing windows, retro-auth rules, drug mappings, and cross-system identities could explain failed matches. This led to an important architectural realization: deterministic systems should generate candidate authorizations and operational clues, while LLMs should reason over those findings to explain why reconciliation failed and recommend next investigative actions.

Starting Point

As mentioned, it turns out that I’m missing a few key fields to calculate the Retro-authorization eligibility. So I need to generate a new version of the source file containing 4 key fields:

• retro_auth_allowed_flag: Indicates whether retro authorization is permitted
• retro_auth_lookback_days: How far back retro-auth can apply
• grace_period_before_days: Allows service before auth start, if applicable
• grace_period_after_days: Allows service after auth end, if applicable

With the new file generated, I can revisit the logic calculations. Here are the results:

Service date:  2026-03-05
Auth start:  2026-02-01
Grace period before:  0
Auth end:  2026-02-28
Grace period after:  3
New start date:  2026-02-01 00:00:00
New end date:  2026-03-03 00:00:00
Authorization is outside grace period window; check retro-authorization eligibility.
Authorization is eligible for retro-authorization; proceeding with erification.
Retro-auth lookback days:  7
Retro-auth start date:  2026-02-26 00:00:00
Retro-auth start date is within grace period window; label as VALID.

==========

Service date:  2026-02-24
Auth start:  2026-03-01
Grace period before:  5
Auth end:  2026-06-01
Grace period after:  14
New start date:  2026-02-24 00:00:00
New end date:  2026-06-15 00:00:00
Authorization is within grace period window; label as VALID.

Right now, I’m not going to move this logic back into the main application. Since I know this is deterministic logic is working, and I know that it can be called from main.py I can always revisit this later. But before I do that, I’ll go ahead and finish populating the agentic solution snapshot template for this agent.

Now that I’ve completed the Exception Explanation Agent and Date / Window Validation Agent, I’d like to focus my attention on a more advanced 3rd agent that employs the use of LLMs and reasoning, and the CrewAI framework. As a sanity check, I asked ChatGPT to rank candidate agents from least to most complex:

The first two agents have been largely deterministic exhibiting fast, cheap, reliable characteristics. Staying with my original plan, the 3rd Authorization Discovery Agent will need to search for plausible related auths and generate hypotheses. This requires high-value, explainable reasoning.

Remember, just because an authorization isn’t found, that doesn’t mean that a service wasn’t rendered. It just means that (for some reason) there isn’t a link between the claim and authorization. There are several reasons for this:

• member ID crosswalk issue (described below)
• timing issue (retro auth)
• payer mismatch
• wrong dependent mapping

As the crosswalk is important for our demonstration, let’s understand this a bit. Can’t I just look up the member ID to see if there are any associated claims for that individual? In theory, yes, but its very likely that each of our participating systems keeps track of member IDs differently:

• Claims system → may use billing/subscriber ID
• Authorization system → may use internal case/member ID
• Eligibility → may use payer-issued member ID

Thus, the member_id on the claim is often not usable without normalization. Normalization addresses the following issues:

• Different systems → different IDs (shown above)
• Dependents vs subscriber IDs
• Legacy vs current ID formats (may use deprecated IDs)
• M&A / platform migrations

Normalization is realized by an entity known as a “crosswalk”, or the member ID crosswalk. It maps different representations of the member (across systems) to a single canonical identity.

Our crosswalk will contain, at a minimum:

• source_system
• source_member_id
• canonical_member_id

For further exploration, I asked ChatGPT to generate a new deterministic matching application, which produced the following results:

claim_id,claim_member_id,enterprise_member_id,auth_id,match_status,exception_category,exception_detail
CLM001,C1001,EM001,AUTH001,Matched,Clean Match,"Member, drug, quantity, date, provider, and eligibility align"
CLM002,C1002,EM002,AUTH002,No Match,Quantity Mismatch,Claim billed quantity 3 exceeds authorized quantity 1
CLM003,C1003,EM003,AUTH003,No Match,Date Mismatch,Service date is outside authorization effective window
CLM004,C1004,EM004,,No Match,Provider Mismatch,Provider mismatch: provider not found / non-normalized
CLM005,C1005,EM005,,No Match,No Matching Authorization,No approved authorization found for resolved member and drug

In our case, we’re focusing on missing authorizations, so this final row applies:

claim_id,claim_member_id,enterprise_member_id,auth_id,match_status,exception_category,exception_detail
CLM005,C1005,EM005,,No Match,No Matching Authorization,No approved authorization found for resolved member and drug

We now are using a member ID crosswalk which is good, but what now? Let’s investigate this manually. First, I’ll examine the claim details:

claim_id = CLM005
claim_member_id = C1005
drug_code = NDC999
billed_quantity = 1
service_date = 2026-01-10
provider_id = P205
claim_received_date = 2026-01-11

Let’s say that this is all the data we have for this claim. In this case, we already matched on a member, so that’s a good start. In this specific case, the drug_code was not found, which would require some additional investigation as to why. However, for this example, let’s assume that the drug was found, and its record looks like this:

drug_code = NDC999
drug_name = DrugZ
retro_auth_allowed_flag = True
retro_auth_lookback_days = 20
grace_period_before_days = 5
grace_period_after_days = 5

The claim’s service date is 2026-01-10, so when we combine that with the drug’s date rules, we end up with an operating period between:

• January 10, 2026 - 5 grace days before (January 5, 2026)
• January 10, 2026 + 5 grace days after (January 15, 2026)

However, this drug allows for retroactive authorizations, so that means that the authorization could have taken place on December 16, 2025 (20 days before January 5, assuming this logic is accurate; see clarification further below).

So, now we can search for authorizations that have occurred between December 16, 2025 and January 15, 2026. We could also identify any that were associated with drug_code NDC999 (“DrugZ”) which could offer additional clues.

Let’s say that we found several authorizations that fit this criteria, but none of them are associated with our member_id. Now what? Ultimately, we need an algorithmic way to search for possible candidates that is deterministic in nature. Yet, we also can benefit from reasoning by asking the LLM to sort through our searches to offer recommendations.

With this understanding, I asked ChatGPT to aid in my understanding. Fortunately, it confirmed that I’m thinking about this correctly:

Your narrative is exactly the right learning move: you are separating deterministic candidate search from LLM-assisted investigation/recommendation. That distinction is the core design principle for a missing authorization agent.

It also framed the agent’s job very well:

The agent is not trying to “invent” a missing authorization. Rather, it is trying to answer:

“Given this claim has no direct approved authorization match, are there nearby authorization records, identity issues, coding issues, timing issues, or operational clues that explain why the match failed?”

It also offered some clarification regarding my date logic. Specifically for retro authorizations, the key question is: “Could an authorization have been created or approved after the service date but still within the retro lookback period?”

In our example, the retro lookback period is 20 days. This means that an auth can still be deemed valid if it appears 20 days after the service date. In our example, the service date is January 10. So, it is possible that the auth was created after January 10th. Ideally, it would have been created between January 10th and January 30th, staying true to the retro lookback period. In our earlier example, this just means that we’re searching within an expanded time window, but we’re still missing a match.

Now, I need to move away from my “exploratory” search method towards one that is more structured. This is what I’ll start with on Thursday.