What might a stricter version of the standard look like?

Technical
1

I was recently struck by a comment made during a client call: “A standard isn’t a standard if you can drive a truck through it”.

This rings a bell with me. One of the the strengths of HSDS is flexibility: I have been able to map over eight separate data schemas into HSDS with a high degree of fidelity (which I would define as having all data present, consistent, and usable in the new format).

However, as both a user of the data and a provider of data to users, and in the context of providing data for mostly public display, I always have to add additional information before publishing resources.

Here are some additional elements that we have to define ahead of publishing:

  1. Contact information like phone, email, schedule, and URL may be related to multiple tables or “levels” at the same time. For example, if I’m looking at a service at a specific location, and both the service and the location have a phone number, I need to know which phone number to reference first.
  2. Similarly, a service may have more than one phone number. Within the set of phone numbers related to one entity I need to know in which order they should be presented and recommended to users.
  3. Source data often lends itself to a particular method of displaying the names of resources. For example, when looking at a service at a location, often the name is service.name at location.name. If it’s a virtual service, then perhaps service.name by organization.name is better. If it’s a service level display, that might be just the service name, or a concatenation of service name and organization name again. In any case, we have found it necessary to define this on a per-data-source basis.

I would say items 1 and 2 are the most important, but 3 is worth mentioning.

Solutions (?)

Inside Connect 211 we solve these issues by aggregating information at the service_at_location level in ranked lists; these are the source of truth for ordering data. For example, we rank and store phone numbers in an array (as it were) from across all tables. We also format names and descriptions at this level in cases where multiple data elements are concatenated.

This was necessary for our own internal consumption of the data. In a case where we shared data with a national enterprise using strict HDSA they came back with lots of questions about how to parse and prioritize results. When we started exporting our internal data rankings, that ended up answering all their questions, which validates for me that this additional information is generally very useful.

The Conversation

I’m interested in having a conversation about what a strict, or more opinionated, version of HSDS/A might look like. I assume the best mechanism for this would be an application profile, although I’m open to suggestions. I has proven to be so helpful in our experience, and I do think it might warrant even top level recognition in documentation once it’s fleshed out, and perhaps it’s own validator.

What do you think? Have you had to implement similar mechanisms for making data less ambiguous or more usable? Which data fields have proven most tricky for you? Is this a worthwhile Application Profile to invest in?

2

Thanks, Skyler, and bear with me – I’ll ask some questions and depending on the answers I may ask you to reframe this post so that it’s easier for people to see the specific issue at hand.

I think the issue in both #1 and #2 is that there’s a user need to see what contact information is the first contact information that they should use (presumably to access a service; I also assume the answer may vary for other use cases). While HSDS allows for multiple contact points, designers might reasonably want to prioritize among them – and right now there’s no way to indicate that priority in the spec.

Is that right?

If so, then I wonder if the question is: do we think there is a generalizable answer to that question (about what the priority contact point tends to be) which the specification can have an opinion about – or does it just vary from case to case, in which the specification ought to offer a standard method for data publishers to specify the answer within the record?

If I’m understanding correctly, the former seems highly unlikely; the latter seems quite plausible.

But I’m not sure that the latter is a matter of getting stricter, so much as offering the option for publishers to further specify on this matter in a consistent way.

(I think your #3 sounds like a different issue that probably deserves a separate thread.)

As a side note, I’d encourage you to discard that metaphor of truck driving, and politely push back on whomever is using it. I’m sure in a different context that person would readily say “I’m driving a truck here so this standard will only work if I can fit through it.” There may be a particular issue for which driving a truck through an unspecified space is bad; there are certainly other issues in which such truck driving would be considered a critical feature. Let’s get specific about the issue.

3

Flagging this as potentially related - Approaches to extending the HSDS data structure - #8 by robredpath

4

Thanks for the link @Dan-ODS. We may take advantage of profiles as a solution here, but I don’t think this is a duplicate issue.

@bloom I should clarify that when I received feedback about the truck, it wasn’t in relation to HSDS actually, that was just the jumping off point for my line of thinking. Forgive me if I’ve mischaracterized the spec. I depend on HSDS and think it’s an amazing specification.

I think the issue in both #1 and #2 is that there’s a user need to see what contact information is the first contact information that they should use (presumably to access a service; I also assume the answer may vary for other use cases).

Yes that’s right, and also you’ve hit a couple points that we may as well dig into here as well.

  1. Sometimes it’s not as simple as defining a single “main” number, for example. There may be two or more numbers that a user can attempt in order, to access a service.
  2. Something that Connect 211’s basic ranking doesn’t adequately define is what the intended use for numbers is. Users looking for help may only be interested in an ordered list of numbers that are specially for intake.

HSDS tells me whether it’s a voice or fax number, but it doesn’t tell me whether it’s primarily for intake, information, verification, or other purposes.

What are some of those other purposes that phone numbers and other contact info are used for? How do we prioritize, not just the order of phone numbers, but also whether a user should call a phone number or fill out an intake form first?

5

Ok cool. so I encourage you to either revise this thread title and intro or archive it and create a new one (and maybe in either case start a new thread for the naming convention issue in your #3) because I don’t think this is about a “stricter version of the standard” so much as a discussion about potential features pertaining to attributes for contact info.

As for the content I’m not the subject matter expert on these matters but I suspect that the same principle we’ve upheld all along applies here: we assume that the various answers to these questions (about intended use) are many and nuanced and that we probably don’t want to try to standardize it for everyone with our own from-scratch taxonomy. people should feel free to push back on this of course it’s just the default assumption. (maybe there really are only a handful of likely purposes which are known and commonly agreed upon?? kinda doubt it)

It does sound like you might be pointing to a need for extended elements that would enable publishers to specify this information themselves on a record-by-record basis. So maybe you can share how you’ve done that ad hoc so far.