Spike: Research How To Determine Supported Types Of Care For Online Scheduling & Requests

by ADMIN 90 views

Spike: Research How to Determine Supported Types of Care for Online Scheduling & Requests

As we continue to develop and improve the Veterans Affairs Online Scheduling (VAOS) system, it is essential to ensure that we provide accurate and relevant information to users. One critical aspect of this is determining which types of care are supported for online scheduling and requests. In this spike, we will investigate the current approach to identifying supported types of care, identify the data sources that contain this mapping, and determine the best approach for implementing this logic.

To begin, we need to investigate how we currently determine supported types of care. This involves reviewing existing code, documentation, and any relevant APIs or services. We should also identify any existing logic or checks that are in place to determine which types of care are supported.

Existing Logic

Upon reviewing the existing code, we found that there is currently no explicit logic in place to determine supported types of care. However, there are some implicit checks and assumptions made throughout the system. For example, some views and appointment states only display scheduling links and request options for specific types of care. This suggests that there may be some ad-hoc logic or hard-coded values in place.

Data Sources

We also need to identify the data sources that contain the mapping of supported types of care. This could include static lists, API responses, or VAOS services. We should review the data sources and determine which ones are relevant and up-to-date.

Frontend, Backend, or Both

Next, we need to determine whether this logic should live on the frontend, backend, or both. This decision will depend on the complexity of the logic, the performance requirements, and the maintainability of the code. We should consider the following factors:

  • Frontend: If the logic is simple and only affects the user interface, it may be best to implement it on the frontend. This would allow for more flexibility and easier maintenance.
  • Backend: If the logic is complex or affects multiple components, it may be better to implement it on the backend. This would provide a more centralized and maintainable solution.
  • Both: If the logic requires both frontend and backend components, we should consider creating a shared utility or service to centralize the check across views and appointment states.

Shared Utility or Service

A shared utility or service can help centralize the check across views and appointment states. This would allow us to decouple the logic from specific views and appointment states, making it easier to maintain and update. We should consider creating a shared utility or service that can be used across the system.

Edge Cases and Exceptions

Finally, we need to explore any edge cases or exceptions that may exist. This could include special handling for specific facilities or sites. We should review the system and identify any potential edge cases or exceptions that may require special handling.

Based on our research and analysis, we propose the following path forward:

  1. Create a shared utility or service: We will create a shared utility or service that can be used to centralize the check across views and appointment states.
  2. Implement logic on the backend: We will implement the logic on the backend to provide a more centralized and maintainable solution.
  3. Review and update data sources: We will review and update the data sources that contain the mapping of supported types of care.
  4. Test and validate: We will test and validate the new implementation to ensure that it works correctly and meets the requirements.

The following deliverables are expected:

  • Summary of findings: A summary of our research and analysis, including the proposed path forward.
  • Follow-up tickets: Any follow-up tickets needed for implementation.

The following development checklist should be completed:

  • Documentation or comment summary: A documentation or comment summary should be posted in the ticket.
  • Clear recommendation: A clear recommendation on where and how to implement the logic should be provided.
  • Impacted components or flows: The impacted components or flows should be identified.

The following definition of done should be met:

  • All tasks criteria: All tasks criteria should be met.
  • Technical documentation: The technical documentation should be updated (if needed).

By following this proposed path forward, we can ensure that we provide accurate and relevant information to users and improve the overall user experience in VAOS.
Spike: Research How to Determine Supported Types of Care for Online Scheduling & Requests

Q: What is the current approach to determining supported types of care in VAOS? A: Currently, there is no explicit logic in place to determine supported types of care. However, there are some implicit checks and assumptions made throughout the system.

Q: What data sources contain the mapping of supported types of care? A: The data sources that contain the mapping of supported types of care are not yet identified. We need to review the existing code, documentation, and APIs to determine which data sources are relevant and up-to-date.

Q: Where should the logic for determining supported types of care live? A: The logic for determining supported types of care can live on the frontend, backend, or both. We need to consider the complexity of the logic, performance requirements, and maintainability of the code to make this decision.

Q: What are the benefits of implementing the logic on the backend? A: Implementing the logic on the backend provides a more centralized and maintainable solution. It also allows for easier maintenance and updates, as the logic is decoupled from specific views and appointment states.

Q: What is a shared utility or service, and how can it help? A: A shared utility or service is a centralized component that can be used across the system to perform a specific task. In this case, a shared utility or service can help centralize the check across views and appointment states, making it easier to maintain and update.

Q: What are some edge cases or exceptions that may exist? A: Some edge cases or exceptions that may exist include special handling for specific facilities or sites. We need to review the system and identify any potential edge cases or exceptions that may require special handling.

Q: What is the proposed path forward? A: The proposed path forward is to create a shared utility or service, implement the logic on the backend, review and update data sources, and test and validate the new implementation.

Q: What are the expected deliverables? A: The expected deliverables are a summary of findings, follow-up tickets for implementation, and completion of the development checklist.

Q: What is the definition of done? A: The definition of done includes meeting all tasks criteria and updating technical documentation (if needed).

Q: Why is it important to determine supported types of care? A: It is essential to determine supported types of care to ensure that users are provided with accurate and relevant information. This helps to improve the overall user experience and reduces confusion.

Q: How will this change affect users? A: This change will improve the user experience by providing accurate and relevant information. Users will be able to easily determine which types of care are supported and make informed decisions.

Q: What are the next steps? A: The next steps are to create a shared utility or service, implement the logic on the backend, review and update data sources, and test and validate the new implementation.

Determining supported types of care is a critical aspect of the VAOS system. By creating a shared utility or service, implementing the logic on the backend, reviewing and updating data sources, and testing and validating the new implementation, we can improve the user experience and provide accurate and relevant information to users.