Medicare cardholder: distinguish between Older Adult and Disabled riders

[thekaveman]

Background

Medicare is available to generally two different types of people:

• Those who are 65 years of age and older
• Those who are under 65, but have some sort of qualifying disability

This distinction between different types of Medicare recipients is important for the Benefits application enrollment analytics and reporting purposes.

Current state

The Medicare Cardholder flow will rely on the OIDC exchange of scopes and claims with the CDT Identity Gateway (IdG). The code that implements this exchange is found in:

• https://github.com/cal-itp/benefits/blob/main/benefits/oauth/client.py#L44 (configuring the scope)
• https://github.com/cal-itp/benefits/blob/main/benefits/oauth/views.py#L89 (parsing the claim)

The EnrollmentFlow model contains all the information needed for this exchange: the scope(s), the claim, AND the value eventually needed for analytics (the system name).

We know that the IdG supports receiving multiple scopes with a given request; we also know that the IdG supports sending back multiple associated claims.

Proposal

The dev team discussed various approaches on 10/9 and here's where we landed:

• We'll use the pre-calculated medicare and disabled claims coming out of IdG rather than doing any calculation on the Benefits side
• We'll represent the "main" claim under verification (e.g. medicare) AND any additional claims (e.g. disabled) on the EnrollmentFlow model

Acceptance criteria

• EnrollmentFlow.claims_claim is renamed to something like EnrollmentFlow.eligibility_claim
• New (optional) field EnrollmentFlow.extra_claims -- space separated string of any additional claims for that flow
• The userinfo object returned in the IdG token is parsed for all claims on the given flow
• Session is updated to store one or more verified OAuth claims
• eligibility.verify.eligibility_from_oauth modified to check only the "main" claim of the flow
• TBD analytics is updated with all claims that came back as verified

[thekaveman]

@indexing @o-ram we discussed an approach for this that will work given what we know IdG is capable of supporting.

The last question is, how should this distinction be represented in analytics?

• We currently send the enrollment_flows property with relevant events (this was recently renamed, from eligibility_types)
• The value of this property is the "system name" of the flow, a string that isn't visible to end-users. E.g. for CalFresh, this value is calfresh; for Veterans, veteran. For Older Adults, this string is senior (an example of where the system name doesn't match the user-facing value).

We'll have a new situation here where we only have a single system name (e.g. medicare) but potentially another piece of data coming from IdG, the flag indicating disabled. The major difference is, we don't have a flow/system name/anything that represents disabled other than the value coming from IdG.

(Likely) preferred option

One option is another field on the event to hold these "extra claims" as we are calling them. This would result in e.g. an Enrollment event that looks something like (simplified):

Enrollment event for an under 65 Medicare user

Amplitude event

{
    "event_type": "returned enrollment",
    "event_properties": {
        "status": "success",
        "enrollment_flows": ["medicare"],
        "extra_claims": ["disabled"]
    }
}

Metabase event

event_type	event_properties.status	event_properties.enrollment_flows	event_properties.extra_claims
returned enrollment	success	["medicare"]	["disabled"]

Enrollment event for a 65+ Medicare user

Amplitude event

{
    "event_type": "returned enrollment"
    "event_properties": {
        "status": "success",
        "enrollment_flows": ["medicare"]
        "extra_claims": []
    }
}

Metabase event

event_type	event_properties.status	event_properties.enrollment_flows	event_properties.extra_claims
returned enrollment	success	["medicare"]	[]

Alternative option

An alternative, that may have wider implications if/when we go to a "multiple eligibility checks at the same time" model (and hence probably not our preferred approach until we get deeper into that work), would be to send everything in the enrollment_flows property, a la:

Enrollment event for an under 65 Medicare user

Amplitude event

{
    "event_type": "returned enrollment",
    "event_properties": {
        "status": "success",
        "enrollment_flows": ["medicare", "disabled"]
    }
}

Metabase event

event_type	event_properties.status	event_properties.enrollment_flows
returned enrollment	success	["medicare", "disabled"]

Enrollment event for a 65+ Medicare user

{
    "event_type": "returned enrollment"
    "event_properties": {
        "status": "success",
        "enrollment_flows": ["medicare"]
    }
}

event_type	event_properties.status	event_properties.enrollment_flows
returned enrollment	success	["medicare"]

We don't think there is really a difference from the Amplitude/Metabase side, but wanted to run this by both of you for feedback or any other ideas you may have from your experience reporting out of Metabase.

Related

A related question is, how should this be represented in our local EnrollmentEvent that gets recorded and is visible within the Admin?

Currently this looks like:

Screenshot of EnrollmentEvents table in Admin

[indexing]

@thekaveman Provided we can easily segment enrollment by type using a set of criteria in Amplitude, either option works for me.

Do both options allow using the Filter by and Group by features in Amplitude? I'm wondering if the alternative option would display "medicare" and "disabled" as two separate enrollment flows. I think of Medicare as one flow. In practice, we always want those two attributes concatenated "medicare; disabled." How would extra claims display in Amplitude?

Thinking forward to the enhanced Veteran API, I think I prefer your preferred option. We would need to establish the "base" eligibility qualifier for a Veteran, perhaps service history, and then the options for extra claims would be status (Title 38 status) and disability rating (Service-connected). Maybe this topic warrants a whiteboarding session?

Once we nail down the approach, I will revisit the enrollments list view for Administrator.

[thekaveman]

@indexing yes I think the preferred approach above is more suited to something like you describe for the enhanced Veterans API. We can whiteboard it out at some point 👍

[thekaveman]

https://github.com/cal-itp/benefits/pull/2463/files#r1809151927