A use case for `service_area` attached to `service_at_location`

One of our resource directories in Hawaii may have just discovered a use case for attaching service_area to service_at_location:

A program is offered at two locations on two neighboring islands. Technically, the service_area encompasses both islands. However, there is no ferry service between islands in Hawaii, so residents on one island cannot realistically reach the other one without taking a plane or hiring a boat. Our customer asked us about scoping service areas to the more granular service_at_location level so that residents of one island will not see a pin on the other island. It’s a small, but relevant, user experience improvement.

From a user experience standpoint, we can approximate this outcome by using distance radius filtering, but that will return inexact results.

Is this a use case for allowing service_area to be connected to service_at_location as well as service?

@devin @MikeThacker @mrshll

1 Like

That’s a field I would expect to already be associated with service_at_location, especially for statewide agencies with locality-specific services…

service_area is linked to service which is linked to service_at_location. Services can have an array of service_area objects attached at service.service_areas.

I might be missing something, but could the service just contain two different service_areas for the different islands, and then the service_at_location object just provide the link to the service?

Hi @mrshll, we do indeed need a link to service_at_location as you say, but at the moment there is no such link.

The context here is that in the four table model, there are essentially three levels of increasingly granular data management:

  1. organization
  2. service/location
  3. service_at_location

For example, a 211 will frequently have phone numbers defined for services at the service level. However, even where a service has a phone number, situationally they may need end users to call a different number for that service a specific location. So they will then attach that phone number to the service_at_location level instead of (or in addition to) the service level. My team is expected to then use the service_at_location number first, and fall back to the service number.

We have just uncovered a similar use case for service_area. This falls into the category of “the service is definitely the same, but information about interacting with the service changes based on location”.

Does that answer your question?

Hi all, I have another use case, contributed by Karen Henry at the 211 for Finger Lakes Region, New York:

When pulling the details for a program, the service area should be related to the location, not the program. Such as Food Pantry at High Street Food Pantry is only available for Chemung County residents, and the Food Pantry at Schuyler Outreach Food Pantry is only available for Schuyler County residents. They are both food pantries offered by Catholic Charities of Chemung and Schuyler Counties. Currently, the service area shows Chemung and Schuyler counties for both locations. It is the same program in our database, but different locations with different eligibility.

I think we have definitely found a case for adding adding a service_at_location_id to the service_area table. I would like to propose this for the next minor version of HSDS.

@mrshll @Dan-ODS @bloom

Thanks Skyler. I’ll reiterate my comment upthread, which is that I would have expected this feature to already have been in place. Of course service area is going to be one of the aspects of a service that may vary from one location to the next.

Is there any reason not to have service_area in the service_at_location table?

@bloom @mrshll Matt is back tomorrow so will get his rekons asap.

So sorry for taking a few weeks to get to this!

I’ve reviewed this and reloaded it into my brain, and the additional comments from Skyler make sense. I think it’s a good idea to add a service_area to the service_at_location table for now; at the very least it’s fairly harmless in terms of the overall structure of the data and — as Skyler notes — it enables some use-cases a bit more easily.

I think this is straightforward enough to include in the scope for the upcoming 3.1. @skyler, just a quick sense-check: do you think that the link should be 1-to-1 or 1-to-many? I.e. should we be adding service_at_location.service_area or service_at_location.service_areas?

Hi @mrshll, welcome back!

I think it should be service_at_location.service_areas in plural. Functionally, it will operate the same as service.service_areas, just at a more granular level.

I’m excited for this to be added in 3.1.

1 Like