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.