Modelling many service providers at a location

[md5]

I'm trying to model the Altadena Senior Center in Los Angeles County and I think I've hit a limitation of the Ohana data model (or at least the Admin interface).

The situation I'm trying to model is that the LA County Department of Community and Senior Services (CSS) operates the Altadena Senior Center, but other organizations besides CSS offer services there as well. One example is AARP, which offers free income tax preparation services for seniors and caregivers. These services are offered as part of the AARP Foundation's Tax-Aide program.

From what I can see, there is no direct association between a Service and an Organization, only from a Service to a Location or to Program.

I was hoping to be able to create the Altadena Senior Center location connected to the CSS organization, then to create a Tax-Aide program connected to AARP, followed by a Service under the Tax-Aide program offered at the Altadena Senior Center. When I tried to do this, it seemed that I could only choose programs associated with the organization that owned the location where the service was offered.

[monfresh]

Each Organization has its own set of Locations. Even though multiple organizations can be operating out of the same physical building, each organization will have its own Location entity from a database perspective. The HSDS spec specifies a one-to-many relationship between an Organization and Locations. This is because each location can have attributes that are specific to one organization and not shared with other organizations that happen to be in the same building (such as hours of operation).

A Service must belong to a Location because services have to be offered somewhere, whether in a physical location, or a virtual one. In addition, when you perform an API search, it returns Locations. So, if a service were allowed to only belong to an Organization, it would never appear in search results.

The way you would model this would be to create an Organization for AARP, and create the Altadena Senior Center as a location for AARP. Then, you would create a Service for that location that describes the free income tax preparation, and then you can create the Tax-Aide Program for AARP and assign the service to it.

Does that make sense?

[md5]

That doesn't really make a lot of sense. If there are ten organizations providing services at the same physical location and I search for that location by name, then I'm going to get ten listings. This location information can then diverge since it is duplicated across organizations.

[monfresh]

Each of the ten listings is unique because each location belongs to a separate organization and has its own set of unique attributes, such as Contacts, RegularSchedules, HolidaySchedules, Phones, Services, and Mailing Address.

If each organization was pointing to the same Location database entry, how would you differentiate the attributes mentioned above?

Let's say you were looking for AARP, and there was only one Location search result for Altadena Senior Center. When you click on that Location, what would you expect to see? Would it contain every single organization at that location, all the contacts and phone numbers across all organizations, all the services across all organizations, etc.?

[md5]

If each organization was pointing to the same Location database entry, how would you differentiate the attributes mentioned above?

I would think that Contacts, RegularSchedules, HolidaySchedules, and Phones could be associated with a Service. Mailing addresses would be associated with Organizations and possibly Programs.

Let's say you were looking for AARP, and there was only one Location search result for Altadena Senior Center. When you click on that Location, what would you expect to see? Would it contain every single organization at that location, all the contacts and phone numbers across all organizations, all the services across all organizations, etc.?

Yes, I'd expect to see Altadena Senior Center listed once. Right now if I search for "Tax", I'll see "Altadena Senior Center" in the location search results and have to click through to see why it was a search result for "tax" by looking at the list of services offered. If Ohana were offering a service search instead of a location search, I'd expect to see the service listed with part of the search result telling me that it was offered at the Altadena Senior Center. I think having Ohana offer a service search instead of or in addition to a location search would be helpful.

[monfresh]

I would think that Contacts, RegularSchedules, HolidaySchedules, and Phones could be associated with a Service. Mailing addresses would be associated with Organizations and possibly Programs.

Those tables are already associated with Services, but they should be available for Locations as well. A Location could have a central phone number that isn't tied to any specific service, while each service can have its own number.

Some entities can belong to multiple other entities. For example, a Contact can belong to an Organization, Location, and/or Service. The schema is based on the HSDS, which was developed over the past year by many people from various organizations who came to an agreement about how the data should be modeled. If you disagree with the current schema, please open an issue in the HSDS repo.

I think having Ohana offer a service search instead of or in addition to a location search would be helpful.

The API provides a way to search by Category (a Taxonomy term), as described in the Search documentation. This helps narrow down results to only those that have been tagged with that category. So, if you had a Category called "Tax Preparation", a search using the category parameter will only return locations that offer Tax Preparation services. There wouldn't be any confusion about why the result showed up.

The generic keyword search looks for a match in many different attributes across various tables. It's a full-text search that ranks results based on in which attribute the match was found, as explained in the documentation. A full-text keyword search for a vague one-word term like "tax" would result in the same "why was this result returned?" confusion whether the search returned Locations or Services. To be able to use targeted searches, the API provides various filters.

The lack of taxonomy-based search in Ohana Web Search is an Ohana Web Search issue, not an API issue. However, because the keyword search gives a higher weight to Category matches, when you search for a phrase that matches a Category, it will appear higher in the search results, and most people only look at the first few results, as determined by a usability study that was conducted. This is why we provide a way to place common search terms on the Ohana Web Search homepage.

In addition, when you visit a Location in Ohana Web Search, you can see a list of all the Categories across all services offered there. In my opinion, it would be very helpful to turn that text into links that perform a category search, so that you can see which other locations offer that service, but @anselmbradford was arguing against it until there is a corresponding search in the sidebar. We never resolved the issue, and it doesn't look like we created one for it. I think some of the conversation happened here: https://github.com/codeforamerica/ohana-web-search/issues/486

[md5]

Thanks for the links and the background information about the usability study and the previous GitHub discussion.

I'm not sure I'd say that I disagree with the current schema, but as far as I can tell from reading the spec and looking at the attached ERD, there is nothing that requires the organization_id of a Service to be the same as either the Location's organization_id or the organization_id of its optional Program. I'll open an issue against codeforamerica/OpenReferral for clarification.