Implement payer_type-specific eligibility date logic for claims enrollment

[chase-jones]

Is your feature request related to a problem? Please describe.
Currently, the enrollment flagging logic uses a one-size-fits-all approach for determining member eligibility based on claim dates. However, different payer types have different rules for when eligibility should be evaluated. Specifically, traditional Medicare (from CCLF data) requires eligibility to be based on the claim end date, while Commercial and Medicare Advantage populations should use the claim start date. This difference is critical for MSSP and ACO REACH programs where financial risk and member attribution depend on accurate eligibility determination.

Describe the solution you'd like
Enhance the enrollment flagging logic to use payer_type column values to determine which date to use for eligibility checks:

• Medicare (traditional/CCLF): Use claim end date (claim_end_date) for eligibility determination
• Commercial: Use claim start date (claim_start_date) for eligibility determination
• Medicare Advantage: Use claim start date (claim_start_date) for eligibility determination
• Medicaid: (I'm not sure which of the two is used here, might not be standard)
• Self-insured: Use claim start date (claim_start_date) for eligibility determination

For example, a claim running from Jan 14, 2025 to Feb 15, 2025 where a member has eligibility only in January would:

• Traditional Medicare: No eligibility/accrual (based on Feb end date)
• Commercial/MA: Has eligibility/accrual (based on Jan start date)

Describe alternatives you've considered

• Adding a separate configuration variable to control date logic instead of using payer_type
• Creating separate models for each payer type
• Adding the logic as a post-processing step rather than in the core enrollment flagging

Additional context
This is essential for accurate financial reporting in value-based care contracts, particularly MSSP and ACO REACH programs where CMS has specific rules about member eligibility timing that differ from commercial contracts.

[jansenpa]

@jansenpa to research MA vs. Medicare date standards. Commercial and Medicaid will vary by state/payer etc...

[amartinson193]

@chase-jones Good synopsis!

@chase-jones @jansenpa I would really boil this down to 2 options imo:

1. Update the date flag (which is joined to the member months table for the member enrollment flag) logic from a coalesce to a case when instead. The case when would be based on payer type. Alternatively, this can also be put into a separate lookup table and joined in to avoid a case when. This is the approach that it seems @chase-jones proposed up above.
2. Create 2 member enrollment flag columns (one based on start date and the other on end date).

I would vote for option 1 since it makes the data model more clean. It automates the logic that others would have to use anyway for determining which field to use. The only reason I would think we would split the field into 2 separate columns would be because there would be exceptions for specific payers on which field to use.

I would argue we wait to do option 2 until we have evidence that there are even companies out there that would want to make an exception.

The Tuva project is going to have to make opinionated decisions. Part of the reason people use the Tuva project is the simplicity of business logic being built in. This seems like going with option 1 fits more closely with what Tuva is intending to do.

Finally, option 1 is simpler to implement. Adding 2 fields increases complexity without as much benefit from my perspective.

[jansenpa]

@chase-jones @amartinson193, I am ok waiting on option 2 because I agree it makes the data model more messy. I do not think option 1 is viable because I don't think the conditions are that straightforward outside of the case of Medicare ACO Reach, MSSP and FFS. This leaves all other data sources relying on the first of the month.

[davidshimamoto]

If those are really the only two options, I dont feel like option 2 is that complicated - we'd have a "claim start based enrollment flag" and a "claim end based enrollment flag", and then at the mart-layer we could implement "option 1" a lookup table based on payer (or payer type) for which one to use.
Am I missing some other complication?