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

Technical
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!