[Community Care] Increase the Mapbox radius for both zip code & city search results; increase results from 10 to 15

FranECross commented 3 weeks ago

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

Rails -- API PARAMS PROVIDER LOCATOR XXX -- { :PARAMS => { :address => "38.899818,-77.019911", :radius => 10, :maxResults => 11, :pageNumber => 1, :pageSize => 10, :telehealthSearch => 0, :homeHealthSearch => 0, :specialtycode1 => "122300000X" } }

entered: Washington, DC vets-api

Rails -- API PARAMS PROVIDER LOCATOR XXX -- { :PARAMS => { :address => "38.903797,-77.04013", :radius => 18, :maxResults => 11, :pageNumber => 1, :pageSize => 10, :telehealthSearch => 0, :homeHealthSearch => 0, :specialtycode1 => "122300000X" } }

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

[ ] Increase the minimum radius from 10 to 20 for CCP only (this impacts zip code and city initial searches, not zoomed searches). (Urgent care, Emergency care, Community providers (in VA's network), Community pharmacies (in VA's network))
[ ] Increase the number of search results displayed for CCP only from 10 to 15
[ ] DO NOT MERGE until QA in the linked ticket has been performed/signed off
[ ] Notify PM (Fran Cross) so that she can enlist help for/perform QA

FranECross commented 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

eselkin commented 3 weeks ago

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?

FranECross commented 3 weeks ago

Thank you, @eselkin ! We're good to close the spike.

FranECross commented 3 weeks ago

@eselkin Apologies for context switching.... A couple of questions came up in my meeting with Michelle around this ticket (see bullet items below. :)

I believe the radius update here is only for Community Care facilities. True?
For pagination, can you think of any negative repercussions to also increasing the number of results that display in the results? Say, 20 or 25?

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!

eselkin commented 3 weeks ago

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.

FranECross commented 2 weeks ago

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.

eselkin commented 22 hours ago

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.

FranECross commented 22 hours ago

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.

eselkin commented 21 hours ago

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

FranECross commented 21 hours ago

@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.

eselkin commented 19 hours ago

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.

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