Required components of a 211 Application Profile for HSDS

Technical
1

I’m starting a thread where we can document discussion of the requirements of a 211 Applicaiton Profile. As a starting point I’m just keeping track of what components are needed. This will be a growing list as the 211 Best Practices working group continues their work.

I’ll be centralizing discoveries in this public document (README - Google Docs), but I ask that discussion primarily be here in the forum :slight_smile:

Here’s a summary of what I know is needed so far:

  • taxonomy_term needs additional, HSIS specific fields (synonyms, see also, etc.)
  • phone.type may need a different / more robust list than what is provided by RFC 6350 ( https://datatracker.ietf.org/doc/html/rfc6350). @PollyM indicated there is already significant (but not universal) consensus around what to use inside the 211 community. There are potentially two rubrics to track: A) the technology this number is for (similar to RFC 6350 but needs more options such as “tty”), and B) the priority or ranking in when there are more than one number present. Currently, the 211 rubric used by Lindsay Paulsen and others combine the two using terms like “Main” which connotes both “voice” for type, and “primary / number one” for priority.
  • There is a need for “redacted” or “confidential” location types that hide addresses for sensitive locations such as Domestic Violence Shelters. See discussion here: Handling confidential addresses in HSDS 3.0 - Technical - Open Referral community forum
  • There is a need for grouping multiple sets of schedule records (based on RRULEs) to a single service. The use case is that a service may have multiple seasonal schedules attached to it. Since RRULEs often require more than one rule to define a schedule, it’s difficult to know which sets of schedule records belong together in the presence of multiple schedules. Further, the original or human readable description will be denormalized across RRULE sets wherever multiple rules are required, even in the presence of a single schedule. See discussion here: Challenges with the schedule table for organizations in the USA - Technical - Open Referral community forum

@HannahN @bloom

2

I think this depends on whether you effectively want to put a taxonomy in the HSDS data or just link out to the taxonomy term in the full taxonomy. I understand that some owners of taxonomies that are not completely open are happy for resources to be referenced against their taxonomy terms but they don’t want terms not used published and they may not want extra information (taken from the taxonomy) about each term published openly.

3

That’s a great point @MikeThacker, and one that’s very relevant here. There are some aspects of HSIS which are useful, I might even say necessary, for effective public consumption, but it’s not clear at all if those aspects (or any aspects) of HSDS are intended to be publicly useable.