Linking a service to app stores

I’ve had a query from a UK project that wants to do a proof of concept with an Open Referral UK API feed for services. (I’ll leave them to add further details if they wish.) The question is:

How do I link a service to its addresses in the iOS App Store and the Android Play Store?

I think this is analogous to providing multiple links for a services in different social media. I can’t remember how we addressed this. Would someone advise here and/or link to the relevant documentation please?

Hi Mike

Without speaking to Profiles, the method to do this in HSDS is via the services.additional_urls field. This is an array of url objects, so for each item in the array you can provide any of the properties from the url schema:

url.id (uuid) and url.url (uri) are the only required fields in the url schema, but I think it would be best practice to provide url.label as a descriptor for what this URL is.

For the UK Profile specifically — assuming that you’re still using the schemas you provide in your Github repo — this is based off of the version of HSDS before we added the url schema, so you currently don’t have access to it. You have a few options here:

  1. Re-implement it yourself as part of your profile. This would involve copying the schema file from the HSDS Specification repo, but you’d also need to make sure you made appropriate changes in other parts of your profile schemas such as to the service schema etc.
  2. “Rebase” your Profile on HSDS 3.1, where this change was added. This should bring through the change for you, but will also bring through the other changes we made in HSDS 3.1 which you will need to either accept as part-and-parcel, or negate out explicitly through your Profile.

Either of these are acceptable approaches as far as Profiles go. I can support in making the necessary changes in either case.

From a standard governance perspective, it’s great that we’re seeing this so soon. It’s a great test of how Profiles interact with the “vanilla” Standard where each are versioned separately, and we should capture any lessons from this for both tooling and processes.

1 Like

If you’re choosing to rebase your Profile, you can use the HSDS Schema Tools included in the profile repo with a branch to base your profile off of:

hsds_schema.py profile-all https://github.com/OpenReferralUK/uk-profile --branch 3.1

This will “rebase” your Profile off of the 3.1 branch of the HSDS Specification, which includes the url schema.

1 Like

Thanks very much for that @mrshll.

I’ll discuss implementing a profile based on version 3.1 (or 3.1.1) with the technical team commissioned by MHCLG to support Open Referral UK.

In the interim, as the validation is permissive, I’ll tell the team that wants to reference app stores to add and populate the services.additional_urls array field.

1 Like

Excellent. I think this is the best approach, that way we don’t have different re-implementations or conflicts.

Just to outline your steps:

  1. Inside your UK Profile git repo, activate the Python environment to get access to the hsds_schema.py script
  2. Decide which of the features you want to keep from HSDS 3.1 and which of these you feel don’t have a place within the UK Profile
  3. Override/null out anything you don’t want to keep (this is basically what you’ve done for other things so is just a repeat of this step for the new schemas/fields in 3.1)
  4. Run hsds_schema.py profile-all https://github.com/OpenReferralUK/uk-profile --branch 3.1 to generate your Profile

Some things to note:

  • You don’t need to differentiate between HSDS 3.1 and 3.1.1. Our process for PATCH releases is to merge them into the branch for the relevant MINOR release, so you just need to rebase the profile off of the 3.1 branch.
  • Most of your work is going to be deciding which of the 3.1 features you want vs ones to remove. I’d recommend doing the planning up front and deciding on the principles. Nothing is set in stone unless your versioning/governance process dictates it. At a technical level, you can choose to only pull through the url schema initially, and then decide at a later date that you actually want e.g. service_capacity as well.
1 Like