Optional Phone Numbers In VA Decision Reviews: A Spike

Background: The Phone Number Predicament

We've hit a snag in the Decision Reviews process: some Veteran's applications are failing because a phone number is required, and they don't have a U.S. number. This is especially true for Veterans with international phone numbers, which our current system, VA.gov, doesn't support. The core issue arises because the system currently mandates a phone number for application submission, creating a barrier for those without a U.S. contact number. This requirement has led to application failures and the need for manual intervention to assist Veterans in completing their submissions.

Our current system lacks the infrastructure to handle international phone numbers, leaving Veterans who reside outside the U.S. or primarily use international numbers at a disadvantage. The absence of an international phone number field in our Decision Reviews applications exacerbates this issue, preventing these Veterans from providing their contact information in a format that the system recognizes. To address this, we need to evaluate the possibility of either removing the phone number requirement altogether or adding functionality that supports international phone numbers. This would ensure that all Veterans, regardless of their location or phone number type, can successfully submit their applications.

Talking with the enablement team sparked two potential solutions: removing the phone number requirement or adding a field for international phone numbers. Both ideas aim to make the process smoother for Veterans, especially those with international contacts. This spike is dedicated to figuring out what it would take to make phone numbers optional across all three Decision Reviews flows.

Goal: Optional Phone Numbers Across the Board

The main goal here is to figure out what needs to be done to make phone numbers optional in all three Decision Reviews flows: Supplemental Claims, Higher-Level Reviews, and Notice of Disagreement. We need to dig into the code and systems to see where phone numbers are required and how we can change that.

This involves a comprehensive review of the vets-website, vets-api, and vets-json-schema codebases to identify and modify any phone number validation or mandatory fields. It's crucial to understand how these systems currently handle phone numbers, including any transformations or specific uses of the data, to ensure that any changes do not inadvertently affect other functionalities. Additionally, insights from the enablement team and Lighthouse personnel will be essential to understand the requirements of downstream systems and ensure that the proposed changes align with overall system architecture and data needs.

We'll be looking at:

• The vets-website code for all flows.
• The vets-api code for all flows, including Lighthouse code.
• The vets-json-schema code for all flows.

We'll also check out how optional phone numbers are handled for folks with housing risks in Supplemental Claims, as this might give us some clues. Plus, we'll investigate all the ways we use phone numbers in our flows to see how we transform the data and what we do with it.

Method: Uncovering the Requirements

Here's how we'll figure out what needs to be done:

• Code Dive: We'll start by diving into the vets-website code for each flow. Our mission is to find any phone number validation code lurking in the shadows.
• API Expedition: Next up, we'll explore the vets-api code, again for all flows. We'll be on the lookout for phone number validation code, including anything related to Lighthouse.
• Schema Sleuthing: We'll also investigate the vets-json-schema code for each flow, hunting down any phone number validation code.
• Team Talk: Finally, we'll chat with the enablement team and Lighthouse folks to understand the phone number requirements of downstream systems.

To effectively identify the necessary changes, we will systematically examine each component of the Decision Reviews application process, starting with the front-end validation in vets-website, progressing to the back-end validation in vets-api, and concluding with the data structure definitions in vets-json-schema. This approach ensures that we cover all aspects of the application that may be affected by the phone number requirement. Collaboration with the enablement team and Lighthouse personnel will provide valuable insights into any dependencies or constraints imposed by external systems, ensuring that our modifications are compatible and do not introduce unintended consequences. The goal is to create a comprehensive understanding of the current state and the steps required to achieve the desired outcome of making phone numbers optional.

Checklist:

• [ ] Investigate the vets-website code for all flows and identify phone number validation code in all locations
• [ ] Investigate the vets-api code for all flows and identify phone number validation code in all locations
• [ ] Investigate the vets-json-schema code for all flows and identify phone number validation code in all locations
• [ ] Determine how best to get information about downstream systems' phone number requirements (from enablement team and/or Lighthouse folks)

Evidence: Documenting Our Findings

As we go through this process, we'll document everything we find. This will help us draw conclusions and plan our next steps.

The documentation will include detailed notes on the specific locations of phone number validation code within each codebase, as well as any relevant code snippets or configurations. We will also record any discussions or insights gained from the enablement team and Lighthouse personnel, including any specific requirements or constraints they may have regarding phone numbers. This comprehensive record will serve as a reference point for future work and ensure that our decisions are based on a solid understanding of the system's current state and dependencies. The goal is to create a clear and transparent audit trail of our investigation process.

Conclusions: What We Learned

Here, we'll capture what we learned during this spike. This will inform our future work and help us make smart decisions.

The conclusions will summarize the key findings from our investigation, including the extent to which phone numbers are currently required in each of the Decision Reviews flows and the specific steps required to make them optional. We will also assess the potential impact of these changes on other parts of the system, as well as any risks or challenges that may need to be addressed. The goal is to provide a clear and concise summary of our findings that can be used to guide future development efforts and ensure that our changes are implemented effectively and efficiently.

Next Steps: Moving Forward

Based on what we've learned, we'll outline the next steps we need to take. This might include coding, testing, or more research.

The next steps will outline the specific actions required to implement the changes, including any coding tasks, testing procedures, or further research that may be needed. We will also identify any dependencies or coordination required with other teams, such as the enablement team or Lighthouse personnel. The goal is to create a clear and actionable plan that can be used to move forward with the project and ensure that the changes are implemented smoothly and successfully. This plan will serve as a roadmap for the team, outlining the specific steps that need to be taken to achieve the desired outcome of making phone numbers optional in all three Decision Reviews flows.

For more information about VA.gov and its services, please visit the official VA website. This trusted resource offers comprehensive details about the Department of Veterans Affairs and the support it provides to veterans and their families.