ORUK criteria in a nutshell

UK community
1

Hi all,

I’m wondering if anyone can summarise the compliance criteria for the UK standard in a very simple way for me. I have been browsing the new ORUK website and can’t seem to find anything which spells out clearly what conditions have to be met. From memory I the following which may or may not be correct:

Data checked at least every 3 months
Data available to other sites via an published API
Core fields must be populated as a minimum (service name and description…and?)

This would really help me out in articulating to stakeholders what ORUK actually means in practical terms.

Thanks!

2

Hello Abigail. I’m sorry you’ve not had a reply so far. I’ve been away and have now discussed your message with colleagues and have agreed we need some simple text in addition to the current online resources. We’ll be producing that. In the interim, here’s aa summary:

Compliance means:

  • providing an open API feed that can be accessed by anyone
  • the feed providing endpoints (also know as “web methods”) that conform to the API specification

There are nine endpoints all of which query (that is “GET”) data. We expect the endpoints to:

  • be named according to the specification
  • use the same query parameters many of which are optional
  • provide responses in the JSON format given by the specification

Three of the nine endpoints are most important. These are:

  • GET / - giving basic metadata about the API feed
  • GET /services - giving a paginated list of services
  • GET /services/{id} - giving full details of a single service

The tool to check compliance will consider a feed to “pass” if these three endpoints comply. It will simply “warn” if other endpoints don’t exists or comply. The “Sample reports” on that page show what complies. Take a look at the text at the bottom of the samples (e.g. for Pass) for more details.

Regarding your points:

Data checked at least every 3 months

This is not a compliance rule but considered good practice. The service entity has an “assured_date” field which we recommend should be populated with a date less than three months old for each service.

Data available to other sites via an published API

Yes the API should be completely public for anyone to use.

Core fields must be populated as a minimum (service name and description…and?)

Yes, the Data model page provides a “Schema” for each entity (e.g. service). Within the schema, fields which must be populated are shown as “Required”. So for a service, just these fields must be populated:

  • id
  • organization_id - linking to the organisation providing the service
  • name
  • status

I hope that helps. Let us know if you have any further questions.

3

Thanks so much Mike, this is SUPER useful!

Can I just check, for the final part about service/organisation records, this means there are two categories of record: organisation and services provided by? So in theory, for every service (such as a memory café for people with dementia taking place every Thursday at 9 at a set location), there would HAVE to be a linked organisation record for the provider of that service e.g. Age UK?

Do the organisation records have a similar data model with required fields?

Thanks :blush:

4

Can I just check, for the final part about service/organisation records, this means there are two categories of record: organisation and services provided by?

Well in theory there are many “categories” - these are what I call “entities”, each of which has fields (and possibly their own entities). The most important are organization and service. Required fields for organization are:

  • id
  • name
  • description

We deliberately split organization and service to allow for more focused searches rather than just listing organisations (such as Age UK) that have a multitude of different types of service.

So in theory, for every service (such as a memory café for people with dementia taking place every Thursday at 9 at a set location), there would HAVE to be a linked organisation record for the provider of that service e.g. Age UK?

Correct. Note that there is another entity of schedule where you can specify the timing of services and link to their location. All of that is optional. The hope is that publishers will start to publish the minimum (organization and service) but over time increase the richness of their structured data.

5

Thanks so much Mike,

Can I also just check something; regarding the availability of the data via the public API (the essence of the whole thing!), are people wanting to make use of the data via harvesting the API needing to contact the data assurer/API publisher first to obtain any sort of key etc? Or should this simply be a website URL they can tap into and pull from, with no obligation to ask or inform that it’s being used?

Thanks :slight_smile:

6

Sorry again for my delay in replying.

We ask that the API link (a URL returning the data in a compliant JSON format - see this example for the first page of services from Bristol) is made public, so it should exclude anything private and should not need an API key.

People can consume how they use the data much as they do for other open data, such as transport data, some will harvest it and merge it with other open datasets.