Implement "eligibility check" phase of vaccine expanded registration processing

[patrickvinograd]

Given a successful submission to the covid_vaccine/v0/expanded_registration endpoint aka KMIv2, we need to move that submission from its initial "sequestered" state to either "eligible" or "ineligible" based on inspecting the data and looking up against VA data sources. This all happens asynchronously from the initial form submission, and nothing about this process is fed back to the user. It is only used to bin submissions into whether they should be submitted on to enrollment service and vetext.

Processing flow

• [ ] Implement a service method that will look at an individual record in sequestered state, do the necessary MPI/EMIS lookups and calculations, write the results of those checks to the eligibility_info column of the submission, and save the submission back to the DB with state = {eligible|ineligible} as appropriate.
• [ ] Write a rake task that will iterate through records in sequestered state, and for each one spawn a worker that does the above step. Maybe with appropriate pagination so as to kick them off in batches of 1000 or so.
• [ ] Write a scheduled sidekiq job that does the same as the rake task and schedule it on some freuquent interval so it is continually moving entries through the pipeline.

References:

Discharge character of service codes available from EMIS: https://github.com/department-of-veterans-affairs/vets-api/blob/master/app/models/emis_redis/military_information_v2.rb#L10

Eligibility calculation

The following represents the eligibility calculation as I have had it verbally described to me. Subject to change:

1. If self-submitted applicant_type == veteran, look at self-submitted character of service.
   • If character of service == {Honorable|General|Other than Honorable|Undesirable}, continue
   • if character of service == {Dishonorable|Bad Conduct}, go to step 6, eligible = false
2. If self-submitted application_type == veteran, look at self-submitted service start/end date.
   • If start/end date encompass 24 months, continue.
   • If start/end date encompass fewer than 24 months, go to step 6, eligible = false.
3. For all applicant_types, use self-submitted first/last/dob/ssn to query MPI. If MPI returns result, record ICN. In all cases, continue
4. If application_type == veteran and we have an ICN, use ICN to query EMIS. Examine last service episode.
   • TODO which codes are considered eligible/ineligible?
5. If non-veteran, or veteran not found in MPI or EMIS, eligible = true.
6. Populate eligibility_info object with following attributes:

   {
   eligible: true|false,
   ineligible_reason: null|self_character_of_service|self_period_of_service|emis_character_of_service,
   icn: <icn>,
   mpi_query_timestamp: <ts>,
   emis_query_timestamp: <ts>,
   emis_character_of_service_code: <code>,
   }

7. Update expanded_registration_submission object to set eligibility_info field with above hash and update state to either eligible or ineligible.

[batemapf]

Before I read the above, my idea of this was actually the opposite order of events. My objective here is maximize the number of eligible records we return:

1. For ~all applicant_types~ only self-submitted applicant type == veteran, use self-submitted first/last/dob/ssn to query MPI. If MPI returns result, record ICN. In all cases, continue.[1]

2. If application_type == veteran and we have an ICN from step 1, use ICN to query EMIS. Examine last service episode.

   • If character of service == {Honorable|General|Other than Honorable|Undesirable} --> eligible = true; ineligible_reason = null [go to step 5]
   • if character of service == {Dishonorable|Bad Conduct}, go to step 6, eligible --> eligible = false; ineligible_reason = emis_character_of_service [go to step 5]

3. If application_type == veteran and we do not have an ICN from step 1, use self-submitted service history values to calculate eligibility based on:

   • If period of service >=24 months AND discharge status != {dishonorable|bad conduct} --> eligible = true [go to step 5]
   • If period of service <24 months OR discharge status == {dishonorable|bad conduct} --> eligible = false; ineligible_reason = {self_character_of_service|self_period_of_service} [go to step 5]

4. For self-submitted applicant_types != 'veteran', --> eligible = true [go to step 5]

5. Populate eligibility_info object with following attributes:

   {
   eligible: {true|false},
   ineligible_reason: {null|self_character_of_service|self_period_of_service|emis_character_of_service},
   icn: {null|<icn>}
   mpi_query_timestamp: <ts>,
   emis_query_timestamp: {null|<ts>},
   emis_character_of_service_code: {null|<code>},
   }

   ---

   [1] Unless it is value-add for the VistA team to send records over with ICN appended if we know; in that case, query MPI for ICNs for any applicant type. If it does not add incremental value or detracts for the VistA team, only query MPI for self-submitted applicant type == veteran. Rationale: the only reason we are querying MPI is to get an ICN to feed to EMIS; we only need that for self-submitted applicant type == veteran.

[patrickvinograd]

That works. Also any EMIS code other than the ones you list basically amount to "unknown" in which case we will assume eligible.

[batemapf]

Worth noting again that work related to #2 in my write up is highly likely to not be necessary in by morning light. Same goes for the self-submitted discharge status part of #3, which is highly likely to not be considered for eligibility purposes.

[patrickvinograd]

This is obsolete at this point - per product direction, records move straight from received to enrollment_pending. I will leave the eligibility calculation logic branch here for posterity: pv-vax-expansion-eligibility-archive