Proposal: revamping HR1 rules for Medicaid Community Engagement

[harrisj]

Hello,

While I appreciate there has been some initial work related to HR1 compliance (see the is_medicaid_eligible variable for instance), I think it has a few issues in its implementation that I would like to correct:

• It seems like it's applying Medicaid work requirements to all when they really just apply to people in the Medicaid expansion population. Is there a definition to tell if a user is in_medicaid_expansion population?
• Grouping compliance into separate major buckets for exemptions, hardships (temp. exemptions for things like disasters, etc.) as well as compliance might be useful. Eligibility is then rolling up those specific categories
• CMS' current interpretation of the rule is that lookback period for an application is the 6 months immediately before the month of the current application date, but that the state can use any single month in that lookback to show compliance (meaning we should test each individual month)
• The review period changes depending on state preferences as well as application type
  • States must decide if they want applicants to show compliance 1, 2 or 3 months. I'd expect states to either pick 1 or 3 months depending on how lenient or punitive they want to be.
  • For new applications, states can decided if compliance needs to be for those months immediately prior to application date
  • For renewal applications, states/applicants can use any of the months (1-3 depending on their choice) in the preceding 6 months to use for verifying compliance.

Here is a non-complete list of the different type of variables at play (more to fill in later), with a check of implementation progress for an associated PR

• Exemptions
  • Pregnant
  • Under 19 or over 65
  • Taking care of a child 13 or younger
  • Taking care of a person with a disability
  • Veteran with a disability rating of 100 (see Reworking HR1 Medicaid Rules #7752 )
  • Is pregnant
  • Blind
  • Deaf
  • Disabling mental health condition (to be defined)
  • Medically frail (to be defined)
  • Has a substance use disorder and/or is in treatment
  • Disabled under SSA definition
  • American Indian or California Indian or receiving services from the IHS
  • Has been incarcerated in the past 3 months
• Compliance
  • Income
    • Earned more than $580 (80xfederal minimum wage) in a
    • Earned more than $580x3 in a single quarter (if it fits in prior 6 months)
    • If a seasonal worker, earned an average income of $580 over prior six months to a given month (seasonal worker defined in IRS code)
  • Worked more than 80 hours in a month (combined from work, volunteering or job training)
  • Enrolled half or full-time in an educational institution
• Hardship (states have options to allow or not)
  • Hospitalization or other intensive services (to be defined)
  • County of residence unemployment the min of (1.5x national avg or 8%).
  • County of residence was declared a federal disaster site
  • Having to travel outside of county long distances to receive medical care

Possible challenges:

• Is identifying if someone is in the Medicaid expansion group straightforward > 1 PFL but <= 1.38x PFL? or does it vary depending on the state and the person's Medicaid category?
• Medicaid uses a 6-month period and a 3-month period for some checks. Is that easy enough to support as periods?
• when should we attempt to compute a variable based on underlying data vs. just accepting a boolean to indicate a determination has been made? It seems like if there are parameters we'd want to simulate chnages for, it might make sense to use them internally.
• harships use county-level data that needs to be updated monthly. Is this something the system can do?

What do you all think? Does this make sense to do here? Should the work be structured as one big PRs or multiple PRs?

[PavelMakarchuk]

@harrisj Thank you for filing this issue. We will take a look!

For future issues, one thing that would be incredibly helpful are the primary sources which we can use to double check and verify.

Based on he initial issue scope I believe this can encoded in one big PR. We will get back to you on specifics around the possible challenges questions shortly.

[harrisj]

Thank you. The main primary sources I have for now are:

• HR 1 text
• Code for America Work Requirements Tookit
• CMCS Informational Bulletin 2025-12-08

[harrisj]

One question for each of the exemptions is how granular to send the data in for it. For instance, in the case of the veteran disability exemption, the system could take a single boolean has_total_veteran_disability or it can do a calculation based on the disability rating ("total" == 100). I chose the latter because it might be useful if we wanted to simulate changes to the disability rating threshold and see the effects (unlikely, but hey)

[PavelMakarchuk]

One question for each of the exemptions is how granular to send the data in for it. For instance, in the case of the veteran disability exemption, the system could take a single boolean has_total_veteran_disability or it can do a calculation based on the disability rating ("total" == 100). I chose the latter because it might be useful if we wanted to simulate changes to the disability rating threshold and see the effects (unlikely, but hey)

I believe for now having a check for is_veteran & is_disabled those are derived from the data.

The individual rating categories are harder to get good data on.

[harrisj]

Unfortunately, is_disabled is too broad for the legislation. It specifically calls for a VA total disability rating (ie, a rating of 100). It's challenging because there are some parts of the law and policy that do seem general (for instance, using the Social Security definition of disabled elsewhere), but then it also has its own specific criteria in places.

[harrisj]

Question for you @PavelMakarchuk: what I have been working towards is how to implement the policy from above in #7752

• CMS' current interpretation of the rule is that lookback period for an application is the 6 months immediately before the month of the current application date, but that the state can use any single month in that lookback to show compliance (meaning we should test each individual month)
• The review period changes depending on state preferences as well as application type
  • States must decide if they want applicants to show compliance 1, 2 or 3 months. I'd expect states to either pick 1 or 3 months depending on how lenient or punitive they want to be.
  • For new applications, states can decided if compliance needs to be for those months immediately prior to application date
  • For renewal applications, states/applicants can use any of the months (1-3 depending on their choice) in the preceding 6 months to use for verifying compliance.

Where this is converging is defining a bunch of variables with a MONTH period type and then I would need to look at specific months and see if they meet one of the exemption or community engagement criteria. But what this would mean is that I would need the following info to be pushed into the system for a specific person:

• The date of their application (so I can derive the lookback period for them)
• Variables set for specific months that show hours worked and/or income

Which is probably pushing the limits of what this simulation system should handle. Is this logic I should push upstream to something like benefits-api (from the MyFriendBen people?)

[harrisj]

Oops, I realize I should have addressed my questions above to @daphnehanse11, apologies!

[harrisj]

Thank you all for your early feedback. I'm beginning to rethink my initial assessments about whether HR1 screening should happen in this tool since I think it would involve tracking information that doesn't quite mesh with the current tool's approach. I am curious what you all think and if I should keep going. Thank you again!