[Rated Disabilities to Lighthouse] Implement logic for determining if a disability rating is considered Service Connected or not

Background

Currently we are planning on using the decision field returned by Lighthouse to determine if a disability rating is considered 'Service-connected' or not (this is relevant to the way that the FE displays the disability ratings). EVSS had a similar field (decisionCode) that returned one of two values (SVCCONNCTED or NOTSVCCON) to indicate that the disability rating was either Service Connected or not. Lighthouse can return a number of different values (listed under the "Context" section below), not just the two. We need to come up with an implementation that will allow us to properly indicate to the Veteran whether their disability ratings are considered to be Service connected or not by the VA.

We have decided to go with a backend solution approach.

Context

Full list of values Lighthouse can return for decision field:

1151 Denied
1151 Granted
Service Connected
Pension
Deferred
Not Service Connected
Willful Misconduct
Voc Rehab Purposes
Chapter 17
38 USC 109(c)
PEB Referred Proposed DES Not Service Connected
PEB Referred Proposed DES Service Connected
Proposed DES Service Connected
Proposed DES Not Service Connected
Active Psychosis/GW Mental
BIRTH - DENY
SPINA - DENY

The two that should be considered equivalent to Service Connected (or SVCCONNCTED) are:

1151 Granted
Service Connected

All other values can be considered "Not Service Connected"

Example JSON of disability rating:

{
    "decision": "Service Connected", <-- This is the relevant field
    "diagnosticText": "Sarcoma Soft-Tissue",
    "diagnosticTypeName": "Soft tissue sarcoma (neurogenic origin)",
    "effectiveDate": "2018-08-01",
    "ratingPercentage": 80
}

Possible solutions

Frontend approach

Update the rated disabilities application to evaluate the values 1151 Granted or Service Connected as being service connected Pros:

Easier to complete the work (merging is almost always easier with FE stuff)

Cons:

Introduces additional business logic to the frontend
Not scalable (ie. every frontend application that uses our service needs to know what values are considered Service connected or not)

Backend approach ✅

Update the response returned by the controller to include a flag (something like is_service_connected) that has the value true when the decision field has the value1151 Granted or Service Connected to indicate that the disability rating is considered to be service connected Pros:

Avoids introducing additional logic to frontend applications
Less barrier to entry for other applications to use our service going forward

Cons:

Potentially longer time to get out the door (merging is almost always harder with BE stuff)

Tasks

FE tasks

[ ] update code to accept Boolean field for service connected
[ ] update tests to account for new field

BE tasks

[ ] add new Boolean field
[ ] add model for LH response
[ ] make sure we're not breaking the FE

Acceptance Criteria

[ ] When a disability rating has a decision value of either 1151 Granted or Service Connected, the application indicates to the Veteran that the disability rating is considered Service connected by the VA
[ ] When a disability rating has a decision value that is not one of the two values that are considered Service connected, the application indicates to the Veteran that the disability rating is not considered to be service connected
[ ] Update JSON to include Boolean field value that indicates connected or not.
[ ] Ensure FE is able to accept new Boolean field.

department-of-veterans-affairs / va.gov-team