[Development] Move HLR schema to JSON schema repo

[YanaRoy]

User Story or Problem Statement

As a Front-end developer on the Benefits and Memorials team, I need move the HLR schema to JSON schema repo so the Back-end developer can be able to provide data to the front-end.

Goal

HLR schema needs to be on the JSON schema repo

Before moving:

• [ ] Add necessary changes for the redesigned opt out of legacy issues step
• [ ] Validate schema to make sure it includes all necessary end point data

After moving:

• [ ] Use schema builder to add the country & state enum data to the form in the build process
• [ ] Add unit tests

Acceptance Criteria

• [ ] HLR schema has been successfully moved to JSON schema repo

[Mottie]

The following issues that need to be addressed before proceeding:

• [ ] When posting, should a unique UUID versus the veteran SSN/VA file number be used? We shouldn't be posting the veteran's SSN
• [ ] sameOffice needs to be modified in the design & front-end (FE) schema to be made global instead of specific to each issue.
• [ ] benefitType needs to be determined on the FE. Does the user choose this type? Or can it be calculated from the available data?
• [ ] addressLine3 exists in other forms, but does not appear to be included in the API.
• [ ] phoneNumberCountryCode and phoneNumberExt, for both the veteran & the veteran's representative, are not included in the design or FE. It is also not part of other forms (e.g. 526), but may be crucial to the veteran's needs. We could modify the FE to accept longer than a 10 digit phone number to work around this issue for now.
• [ ] informalConferenceTimes values in the API do not appear to be in a 24 hour format: ["800-1000", "1000-1230", "1230-200", "200-430"]
• [ ] Contested issues inside of the includes section: should only need to submit the ID of the issue along with the note.

Data posted to API (/higher_level_reviews endpoint)

{
  data: {
    type: 'HigherLevelReview',
    attributes: {
      receiptDate: '2019-01-10', // required
      sameOffice: false, // Needs to be modified in FE form schema
      legacyOptInApproved: true, // required
      benefitType: 'pension', // or 'compensation' - required
      // required block
      veteran: {
        // fileNumberOrSsn: '123456789', // We shouldn't be posting SSN - REMOVE
        addressLine1: '123 Main St',
        addressLine2: 'Apt 7',
        // addressLine3: '', // missing in API
        city: 'Kansas City',
        stateOrProvinceCode: 'KS',
        zipPostalCode: '66160',
        phoneNumber: '8005551212',
        phoneNumberCountryCode: '1', // optional; but not populated by FE
        phoneNumberExt: '123', // optional; but not populated by FE
        emailAddress: 'me@veteran.com'
      },
      informalConference: true, // required
      informalConferenceTimes: [ // API is using 12 hour time ranges
        '0800-1000',
        '1000-1230'
      ],
      informalConferenceRep: {
        name: 'Fred Flintstone',
        phoneNumber: '8885551212',
        phoneNumberCountryCode: '1', // optional; but not populated by FE
        phoneNumberExt: '123' // optional; but not populated by FE
      },
      // Claimant section will not included in HLR MVP
      claimant: {
        participantId: '1234567',
        payeeCode: '01'
      }
    }
  },
  included: [{
    type: 'ContestableIssue',
    attributes: {
      notes: 'Lorem ipsum',
      ratingIssueId: '100',
      // The following are accepted by the API, but may not be necessary
      decisionIssueId: 999,
      ratingDecisionIssueId: '1000',
      legacyAppealIssues: [] // To be removed from API
    }
  }]
}

[edmangimelli]

benefitType needs to be determined on the FE. Does the user choose this type? Or can it be calculated from the available data?

this corresponds to PART I / 12 of VA form 20-0996 https://www.vba.va.gov/pubs/forms/VBA-20-0996-ARE.pdf

[Mottie]

Yes, but the choice isn't part of our design or front-end. I guess we could split out our choices in the wizard - like the original design - to determine this value; but as it stands right now, we don't know the value

[edmangimelli]

Currently the API only supports compensation, so it could be hardcoded (if you so choose --to be clear, i'm not weighing in on the FE design, just explaining the API)

[edmangimelli]

addressLine3 exists in other forms, but does not appear to be included in the API. ... phoneNumberCountryCode and phoneNumberExt ... are not included in the design or FE...

Contact info fields were a compromise between what was received on VA form 20-0996 and what vet360 expects. For the most part, the rule of thumb was: receive exactly what the paper form receives (20-0996) but using vet360 style fields.

For instance, 20-0996 has 2 lines for street, so we're receiving address1 and address2 (which are the names vet360 uses). Same goes for the telephone numbers.

[edmangimelli]

We could modify the FE to accept longer than a 10 digit phone number to work around this issue for now

Not specifying country code will assume "1", or you could even hardcode "1" if you want.

[edmangimelli]

informalConferenceTimes values in the API do not appear to be in a 24 hour format: ["800-1000", "1000-1230", "1230-200", "200-430"]

This was intentional, and was a compromise of having the simplest possible strings that matched 20-0996

[edmangimelli]

Contested issues inside of the includes section: should only need to submit the ID of the issue along with the note.

A contestable issue may have more than one ID, as far as I understand (e.g. it may have both a rating ID and a decision ID).

I think notes was meant to be stricken. Philip can correct me on that

[Mottie]

I think notes was meant to be stricken

We actually allow the veteran to add notes to each contested issue (max 400 characters), so that they can explain why they are submitting an HLR.

[edmangimelli]

When posting, should a unique UUID versus the veteran SSN/VA file number be used?

The veteran's SSN or file number should be provided. This might be changed shortly

[edmangimelli]

We actually allow the veteran to add notes to each contested issue (max 400 characters), so that they can explain why they are submitting an HLR.

Let's bring this up in the next touchpoint. The notes field does not get transmitted beyond caseflow into the outside systems (like VBMS). For the compensation benefit type, someone working this case won't see these notes (i believe)

[Mottie]

For instance, 20-0996 has 2 lines for street, so we're receiving address1 and address2 (which are the names vet360 uses). Same goes for the telephone numbers.

We are trying to maintain consistency across forms. Form 526 has 3 street address inputs.

Not specifying country code will assume "1", or you could even hardcode "1" if you want.

We were discussing how veterans located outside of the U.S. would add their phone number; or veterans that are at an extension behind a number. Our design doesn't account for this. We may end up not including these inputs in the MVP.

This was intentional, and was a compromise of having the simplest possible strings that matched 20-0996

If I only saw one entry of '200-430', I'd call them at 2 o'clock in the morning. I know it corresponds to the form, but it might be confusing during troubleshooting? /shrug

A contestable issue may have more than one ID, as far as I understand (e.g. it may have both a rating ID and a decision ID).

But do we need to submit both?

We should probably have this conversation in Slack so that others can respond more easily.

[edmangimelli]

A contestable issue may have more than one ID, as far as I understand (e.g. it may have both a rating ID and a decision ID).

But do we need to submit both?

Yep.