Capacity to take referrals

[MikeThacker1]

People are asking me how a services API feed might denote if a service currently has capacity to take referrals.

One person has suggested "being able to ‘switch’ on and off according to their capacity", but this is rather inelegant.

How are others dealing with this please?

[greggish]

I believe Status of Service is for this purpose, and i've seen it used as a binary: Active or Inactive which seems to address the use case mentioned.

Many have expressed interest in more details on capacity, but frankly I haven't seen any examples in the wild. I think generally this is not information that exists in digital form, usually because organizations don't have incentives to publish it.

I'd be eager to see other examples out there, though I assume they're going to be very context-dependent.

[MikeThacker1]

Ahh yes @greggish. I see the HSDS tabular data package says this is an enumeration of ["active", "inactive", "defunct", "temporarily closed"]. I'll see how that works.

I can imagine people might ask for more like "No vacancies until January 2021" but this is a good start.

[greggish]

Yeah as per the other enumerations, those seem like examples to me that could be easily challenged. Maybe Defunct and Temporarily Closed would be optional binary extensions below Inactive? Who knows what other kind of variations could be out there.

[klambacher]

I'm not sure it's helpful, but we have a vacancy capacity module and we've had many organizations make a solid run at in and give up within a year or a few months, because the maintenance burden is extremely high. Only in cases where people were maintaining their own internal vacancy status has it been successful. In the end, most organizations trying to track the vacancy or waitlist status of external organizations cease doing so because of the high chance of invalid status leading to problematic expectations by clients, or an invalid failure to refer. That said, I can share our vacancy / capacity structure, I just honestly wouldn't recommend it in the vast majority of cases. In general, most cases of service disruption (for instance) are best served by a public bulletin field, which is used extensively and highly effective.

[greggish]

Ugh Kate I wish I could make you into a bot and just @ you whenever people don't believe me when I try to manage expectations about stuff like this.

[greggish]

Oh also @klambacher – that public bulletin field you mentioned, does that seem possibly related to (#216)?

[klambacher]

Yes @greggish it seems to be the same kind of thing. We've got 3 comment / memo field types and they are each structurally different and used for different purposes. The public bulletin is usually displayed prominently (e.g. at the top of the record) to both staff and the public, intended to provide notice of issues of special concern. It allows data managers to indicate, for instance, that the availability of a specific service might be limited or paused and they should contact XYZ for confirmation, or that a service is scheduled to close in the future, or any number of crucial details about a service's status. This is different from the comments field, which is intended for the private consumption of I&R staff, or the Internal Memo, which for us is a running historical record of issues or questions for data management staff only that can be individually archived when no longer applicable.

[greggish]

Sounds like your public bulletin model would be a great example to consider w/r/t #216. Can I repost this there? (Or, feel free to chime in there!)

[Cskyleryoung]

Two related lessons my team has learned from client (211) data sets:

1. Aside from the status method described above, they also have a "weight" field. In the data is an arbitrary number, but it reflects the reality of their call center staff wanting to prioritize certain resources that provide the best results. It adds a layer of nuance that's useful. I don't suggest adding arbitrary values to our data, but I think they are on to something in concept.

2. We also added an emergency_info field to be displayed at the top of services, used as a public bulletin board exactly as @klambacher described. It's been used extensively throughout COVID to display important and fast changing information.

[devinbalkind]

I love both of these ideas.

[klambacher]

Looks like I've already done some commenting on this issue, but I'll expand with some specifics of the structure we have in place for Vacancy / Capacity.

Each Service record can have multiple linked service capacity entries with the following data elements:

1. UUID (required)
2. Title (required - language specific): these titles are somewhat standardized and a list of typical / standard service capacity titles is set up on a database level but can be customized at the time of data entry. Examples might be "30-day detox program" or "Emergency shelter service" or "Full-day child care"
3. Unit Type (required): the name of the service delivery unit, selected from a list of pre-configured types. For example, "beds", "spaces", "units", "nursing visits", "monitored clients" etc. (can be anything)
4. Target Population (optional): one or more target populations for the service capacity, for example "Women", "Men", "Toddlers", "Families", "Youth", etc.
5. Capacity (required): an integer maximum simultaneous service delivery units
6. FundedCapacity (optional): an integer representing the number of units for which the service receives funding
7. Vacancy (optional): an integer, less than Capacity, representing the number of service delivery units available
8. Notes (optional - language specific):
9. WaitList Available (optional): boolean indicating whether a waitlist is provided
10. WaitList Date (optional): the currently anticipated service availability date based on the waitlist size
11. Last Modified (required): the date and time the service capacity / availability was last changed
12. History: accounting of changes to the vacancy over time, including the amount of change (+/- amount), the Vacancy amount after the change, the date and time of the change, and the person who made the change. This is mainly for reporting / accountability.

There some other fields we have that are not likely to be broadly useful, such as the hours per day, days per week, weeks per year, and/or the full-time equivalent persons connected to the service delivery.

Some examples of what an entry might look like:

Emergency Men's Shelter: Capacity of 25 bed(s) for men; Vacancy of 3 bed(s) as of March 31, 2024. Clients seeking service must register at shelter intake before 7pm.

Emergency Family Shelter: Capacity of 10 unit(s) for women, families, youth. Vacancy of 0 unit(s) as of June 1, 2024. Waitlist is available (July 10, 2024).

Transitional Housing: Capacity of 6 room(s) for men. Vacancy of 0 room(s) as of July 1, 2024. Waitlist is available. Client must have a current case worker and transition management plan before being added to the waitlist.

Full-time Licensed Care: Capacity of 20 space(s) for toddlers. Vacancy of 1 space(s) as of August 9, 2024. Waitlist is available.

Part-time Licensed Care: Capacity of 30 space(s) for preschoolers. Vacancy of 0 space(s) as of August 15, 2024. Waitlist is available.

[mrshll1001]

@klambacher, that's incredibly useful thank you so much for sharing that.

We see ways of modelling things such as unit type in other standards as well, which I'll synthesise with this in order to come up with something that approaches modelling capacity. I like how vacancy is modelled here too, as this would make it trivial to perform analysis on overall service capacity within a given area or even a grouping of services.

[kathryn-ods]

Not started yet - moving back to backlog