Open FranECross opened 3 weeks ago
@eselkin Here's the ticket I mentioned I'd be creating in a comment in the Community Care Spike. Will you please review and either feel free to make edits directly, or suggest in a comment and I'm happy to edit. Thanks in advance! cc @jilladams
The action is to "increase the minimum radius from 10 to 20," which would impact zip code and city initial searches (not zoomed search). The description above covers this.
Should we close the spike?
Thank you, @eselkin ! We're good to close the spike.
@eselkin Apologies for context switching.... A couple of questions came up in my meeting with Michelle around this ticket (see bullet items below. :)
If the above are possible, would wrapping all of them into this ticket make it too large (should I have separate tickets?). Also, for the life of me I can't find the estimate you provided. Maybe it was in Slack and I didn't port it over (or maybe I need new 🕶️). Thanks in advance!
We can make it for community care only (right now we apply the radius for all new entered searches no matter the facility or search type when mapbox geocoding is required), it would be a bit more coding to make the range increase specific to CCP, but not much.
RE: increasing the results... CCP is slooow. It sometimes takes a minute for responses, so, I don't think there's a problem in increasing the page size for CCP. I don't think it'll make it much slower.
Created a QA ticket, and added AC to this one (Do Not Merge, and alert PM) so that robust QA may be performed for these changes.
Something that I found while increasing the per page number of CCP requests, the total coming back from vets-api is always the number max per page that you request, even if there are only 3 it will say 15 if you request max 15. So When FL displays Showing 1 - 15 of 15 results for "Community providers (in VA’s network)", "Dentist" near "Newport Coast, California 92657"
It really only has 3 from the data, but we don't count the responses because we trust vets-api, but vets-api is wrong and doesn't count itself.
Something that I found while increasing the per page number of CCP requests, the total coming back from vets-api is always the number max per page that you request, even if there are only 3 it will say 15 if you request max 15. So When FL displays
Showing 1 - 15 of 15 results for "Community providers (in VA’s network)", "Dentist" near "Newport Coast, California 92657"
It really only has 3 from the data, but we don't count the responses because we trust vets-api, but vets-api is wrong and doesn't count itself.
@eselkin Question for you. Is it possible to mimic what the results show for Community Care Pharmacies, where the number is correct? For instance, I used Cannon Beach, Oregon, and selected Community Care Pharmacies. I get three back, and the verbiage is Showing 1 - 3 results for "Community pharmacies (in VA’s network)" near "Cannon Beach, Oregon" (see screenshot).
I'm assuming this is the way it is for CCP providers on prod (where if there are less than 10, it still displays 'Showing 1-10 of 10 results..... "? If so in order not to inflate this ticket, I'm happy to create another ticket to have it mimic the pharmacies results.
Unfortunately, it says the right thing for Pharmacy (/facilities_api/v2/ccp/pharmacy
) because the right thing comes back from that endpoint on vets-api, not because it's doing something different on the frontend. They both use the totalEntries values from the pagination response. But pagination is broken on regular specialities searches on /facilities_api/v2/ccp/provider
and so vets-api just spits back what you requested
@eselkin Thanks so much for that explanation. Is that something that the Facilities team (in the future) could fix, or would that fall on a different team? Just asking in case I need to spin up another ticket to be done in the future. Thanks again for all your hard work on this and entertaining my questions.
I was debugging to see. So, it seems like the data that comes back from
/dws/v1.0/PlaceOfServiceLocator
for Urgent care or /dws/v1.0/ProviderLocator
for CCP providers is not paginated (only pharamacy which is /dws/v1.0/FacilityServiceLocator
is paginated). I see no key/values related to pages, pagination, max entries, total entries, etc on the actual returns from PPMS. So we may be blocked on this and may need to see how to get pagination information (including total values) back from PPMS since it's no longer there (even in a raw request I made to PPMS).
We can temporarily, make a fix on the frontend to count the responses and only show that number on the frontend.
Status
[2024-08-19] [Fran] Eli finished the Spike, and this ticket is the result of his investigation
Description
In an attempt to increase discoverability of Community Care and other in-network providers during Facility Locator searches, we are (for CCP only) increasing the search results radius for both City-searches and Zip code-searches to (the allowed maximum) of 20, as well as increasing the number of search results from 10 to 15.
After this change, the other Community Care tickets (noted below) will be retested/reviewed, as well as the scenario in the Spike, and then decisions will be made as to their disposition.
17646
17649
Additional Information
Michelle shared the following ticket to provide some history as to changes that were made (and then reverted) for non-CCP facilities. We don't want to implement this, but providing as additional information in case it's helpful to know a solution that was implemented and then rolled back due to issues.
Include radius parameter in Lighthouse queries (front end) #34765)
User Story
AS A Veteran, their caregiver or family member I WANT to be able to view all providers withing a given zip code or city when I use that criteria in a Facility Locator search SO THAT I'm aware of all choices near me or within the area I'm interested in.
Engineering Notes
(Findings from the Spike)
entered: 20001 vets-api
entered: Washington, DC vets-api
RADIUS is set in radiusFromBoundingBox in src/applications/facility-locator/actions/mapbox/genBBoxFromAddress.js this is the radius generated by mapbox from the bounding box
The issue is that mapbox knows whether you entered a postalcode or something else (address or city) when it generates a boundingbox (when it’s a postal code the generation of the bounding box gets types: [‘postcode’] added so it must zoom in closer
There’s a step that says is the radius generated smaller than the minimum radius, and sets the value to that if it’s too small. We could probably increase that if we enter a zipcode and the type if CCP to be equal to the entered city radius
Radius generated when a zip code is entered: 2.851955974147978, which is smaller than 10 (minimum) so it is set to 10 (which is smaller than the 18 given when a City is entered)
We cannot control how far mapbox zooms in, but we can set the radius minimum to 18 to make it equivalent to the default city value
Regarding the ability to expand the radius for the city value: We don't know what the radii of cities are (and have no way to get them). Nor do we know what the radii of zip codes are either. We could make both of them 20 which is larger than the current 18 for city and might help. But there's no way to guarantee that the entire city or zip code is contained in the radius given back by mapbox.
The search is also different between when you use the search button and when you zoom in on the map and use the search within this map window button that appears in the map. This is probably expected by the user. The search in this window uses the radius of the map window and the center point of the map window, which makes sense.
Acceptance Criteria