How do you indicate the main or primary phone number for a resource?

Technical
1

I’m just curious how others are indicating (within spec) which phone number is the main phone number for a resource (service, location, etc.).

Are you enumerating description for this? Adding your own field to denote main or priority number? Cross-referencing schedule and displaying the phone that is currently active?

In one of our use cases, we need to indicate the main or default phone number that viewers should call, but list all phone numbers in details.

2

I thought I would followup on this. We have internally implemented a priority field where we add numeric values for ranked phone numbers. “0” is assumed to the the main or primary phone, and the rest are ranked after that. It’s more flexible than a simple boolean, and is useful for more than just phones.

One of the use cases where we use this is to rank service_at_location level contact info. Some of our clients will prioritize contact info from service records, while others prioritize contact info from location records. At this level of granularity, prioritization allows us to reflect which phones and schedules should be shown to end-users first.

3

So I’m not an implementor and therefore don’t have field experience with this, but I’m also very keen to hear what people’s needs and experiences are because this could be addressed in the design of the standard.

In other standards there’s a model of listing a primary object e.g. phone and then having an array called additionalPhones. You can see this in OCDS where Organization has an identifier object (with a field title of “Primary Identifier”), but also an array of additionalIdentifiers which are described as supplemental.

If this is something you’d be keen to see in HSDS, this is definitely achievable as a new and optional feature. Although with field names such as organization.phones[], we’d need to be careful around naming of fields.

Alternatively, we could almost invert this approach and create a reference to a specific phone object in the organization.phones[] array. So we could have organization.primaryPhone which is simple object:

{
  "primaryPhone": {
    "id": "1554f2e2-a373-45db-a3fa-9fc48a61c15e",
    "number": "+44 1234 234567"
  },
  "phones": [
    {
      "id": "1554f2e2-a373-45db-a3fa-9fc48a61c15e",
      "number": "+44 1234 234567",
      "extension": 100,
      "type": "voice",
      "description": "Our main reception phone number. The phones will be available from 0800 (8am) until 1800 (6pm) local time. There may be some slight delays in answering your call if we are busy."
    },
    {
      "id": "0ebab553-bef4-4616-a77e-16fe995d2f25",
      "number": "+44 7890 123567",
      "extension": 200,
      "type": "voice",
      "description": "Another phone number for us but Matt can't think of a good in-universe description"
    }
  ]
}

Technically speaking it could just be a string in the format of UUID, representing the phone.id, however having number duplicated at this level provides some convenience to systems and humans interpreting and displaying the data. Under-the-hood, databases would just need to mark which one is primary and then duplicate the fields into the primaryPhone object when serializing as JSON.

More long-term (and this is looking ahead quite a bit), the next MAJOR version upgrade could seek to streamline and refactor how contact information is handled, with an eye to also integrating lessons from requiring multiple URLs. At the moment I envision this would be something like a single contact_point object which encapsulates web addresses, email addresses, and phones. I reckon that discussion might be out of scope for this thread, though!

4

That’s really interesting @mrshll . I think it’s a step forward and would be an improvement. I’ll note that I’m getting feedback from 211 data managers that they have fall-through logic (or prioritization logic, if you will) that extends beyond just one item though.

A (strangely) related issue we’re noticing is that RFC 6350 isn’t robust enough to describe the types of phone numbers. Another type that really must be included is tty for Text Telephone Devices. I bring it up because 211s have been on a path of including a bunch of custom types that define two separate things: type and priority. I think a more robust solution needs to separately support defining these two aspects separately: more robust types, and a method for ranking all phones related to a given entity.