Safeguarding and trust networks

Proposer

ODI, Played, MCRactive

Use Case

Activity finders or other data users have a need to ensure that the activities they display are from trustworthy and reputable providers, and specifically that such providers carry the appropriate safeguarding certifications.

Organisations and initiatives such as MCRactive and ClubMark maintain a list of trusted organisations, along with certification information such as "MCRactive Level 2".

Proposal

There are two types of systems:

Opportunity data publishers
Certification data publishers

The opportunity data publishers already publish data that includes an "organizer" or "provider", which is of type schema:Organization with an id.

The certification data publishers publish a list of the certification levels (a CertificationScheme), that includes all the information about these levels. It also includes other schemes that are trusted by this scheme, in order to create a trust network.

The certification data publishers also publish an RPDE feed of pairs of ids for the organising schema:Organization and the CertificationLevel, called TrustCertifications.

In addition to publishing blanket certifications for specific schema:Organizations or schema:Persons, it is also possible to limit the certifications to cover specific activity or ageRanges (which can be specified in the TrustCertifications).

Finally to allow the certification data publishers UI to easily identify pages from the opportunity publishing systems, a JSON-LD schema:Organization can be embedded in the publishing system's webpage. This allows the ID to be easily verified by a provider within the certification system.

Example

Certification Scheme

{
  "@context": "https://openactive.io/",
  "type": "CertificationScheme",
  "id": "https://change4life.nhs.uk/trustlist",
  "name": "Change4Life Certification Scheme",
  "description": "These certification levels are defined and maintained by Public Health England.",
  "submissionUrl": "https://change4life.nhs.uk/trustme",
  "activity": {
    "type": "Concept",
    "id": "https://openactive.io/activity-list#5e78bcbe-36db-425a-9064-bf96d09cc351",
    "prefLabel": "Bodypump™",
    "inScheme": "https://openactive.io/activity-list"
  },
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "publisher": {
    "type": "Organization",
    "name": "Change4Life",
    "url": "https://www.change4life.org/",
    "logo": {
      "type": "ImageObject",
      "url": "https://s3-eu-west-2.amazonaws.com/prod-everyoneactive-wp/wp-content/uploads/2017/10/26092236/Ea-Image2.jpg"
    },
    "telephone": "01455 890508",
    "sameAs": [
      "https://www.facebook.com/change4life/",
      "https://twitter.com/change4life"
    ]
  },
  "logo": {
    "type": "ImageObject",
    "url": "https://s3-eu-west-2.amazonaws.com/prod-everyoneactive-wp/wp-content/uploads/2017/10/26092236/Ea-Image2.jpg"
  },
  "certificationLevel": [
    {
      "type": "CertificationLevel",
      "id": "https://api.change4life.nhs.uk/trustlevels/3",
      "name": "Level 3",
      "url": "https://change4life.nhs.uk/trustlevels/information/3",
      "logo": {
        "type": "ImageObject",
        "url": "https://s3-eu-west-2.amazonaws.com/prod-everyoneactive-wp/wp-content/uploads/2017/10/26092236/Ea-Image2.jpg"
      }
    },
    {
      "type": "CertificationLevel",
      "id": "https://api.change4life.nhs.uk/trustlevels/4",
      "name": "Level 4",
      "url": "https://change4life.nhs.uk/trustlevels/information/4",
      "logo": {
        "type": "ImageObject",
        "url": "https://s3-eu-west-2.amazonaws.com/prod-everyoneactive-wp/wp-content/uploads/2017/10/26092236/Ea-Image2.jpg"
      }
    }
  ],
  "trustedCertificationSchemes": [
    "https://getinspired.bbc.co.uk/trustlist"
  ]
}

Certification List

An RPDE feed of TrustCertifications, which link organizer to certificationLevel

{
  "next": "https://www.example.com/api/rpde/sessions?afterTimestamp=1521565719&afterId=1402CBP20150217",
  "items": [
    {
      "state": "updated",
      "kind": "TrustCertification",
      "id": "1402CBP20150217",
      "modified": 1521565719,
      "data": {
        "@context": "https://openactive.io/",
        "type": "TrustCertification",
        "certificationLevel": "https://api.change4life.nhs.uk/trustlevels/4",
        "organizer": "https://bookwhen.com/organisation/24601",
        "expires": "2018-10-02T19:15:00Z"
      }
    },
    {
      "state": "updated",
      "kind": "TrustCertification",
      "id": "1402CBP20150218",
      "modified": 1521565719,
      "data": {
        "@context": "https://openactive.io/",
        "type": "TrustCertification",
        "certificationLevel": "https://api.change4life.nhs.uk/trustlevels/2",
        "organizer": "https://bookwhen.com/organisation/24602",
        "expires": "2018-10-02T19:15:00Z"
      }
    },
    {
      "state": "updated",
      "kind": "TrustCertification",
      "id": "1402CBP20150219",
      "modified": 1521565719,
      "data": {
        "@context": "https://openactive.io/",
        "type": "TrustCertification",
        "certificationLevel": "https://api.change4life.nhs.uk/trustlevels/2",
        "organizer": "https://bookwhen.com/organisation/24603",
        "activity": {
          "type": "Concept",
          "id": "https://openactive.io/activity-list#5e78bcbe-36db-425a-9064-bf96d09cc351",
          "prefLabel": "Bodypump™",
          "inScheme": "https://openactive.io/activity-list"
        },
        "ageRange": {
          "type": "QuantitativeValue",
          "minValue": 18
        },
        "expires": "2018-10-02T19:15:00Z"
      }
    }
  ],
  "license": "https://creativecommons.org/licenses/by/4.0/"
}

Organizer JSON-LD embed

<script type="application/ld+json">
   {
     "type": "Organization",
     "name": "((BOUNCE))",
     "id": "https://bookwhen.com/organisation/24601"
   }
</script>

Considerations

DefinedTermSet and DefinedTerm (or subclasses of these) could be used, or ConceptScheme and Concept.

Although the Certification List could be implemented as a single endpoint retrieved by data users using a conditional GET, an RPDE feed allows data users to more easily update any search index with only the delta of changes to the list.

Comment from @chrisnorfield on W3C call 11 Sept 2019, two additional properties (both reflected in example above):

submissionUrl - would be good to be able to signpost from e.g. Open Sessions after a session has been uploaded, to point the provider to where they might attain a relevant certification
activity - if provided at the CertificationScheme level will help e.g. Open Sessions to offer relevant certification providers depending on the activities selected by the provider during session upload

Would it be possible to emend the examples given above slightly? From the description given, I gather all relevant information about the certification scheme should be available in the CertificationScheme object, but looking at this we seem to have a partial representation (levels 3 and 4 only) of the overall scheme, and no text description of what these levels consist of. In addition, I'm guessing that the intention of the 'Bodypump' activity is to limit the scope of these levels to that activity alone - but I'm not entirely sure. Would this sort of thing more normally be labelled e.g. 'Bodypump - Level 3' and 'Bodypump - Level 4', etc.?

Relatedly, should the activity property here be an Array?

Hi, I think it's important to distinguish between safeguarding and qualifications - both are important but they are not equivalent. Safeguarding is about working to protect the children, young people and adults that are involved in someone's activities, as well as coaches and instructors. Qualifications are more about the quality of coaching you can bring to an activity. The difference can be seen in the content of the Martial Arts Safeguarding code (https://www.safeguardingcode.com/benefits) or a Coaching certificate (e.g. British Cycling's Level 3: https://www.britishcycling.org.uk/coaching/article/coa20120816-Level-3-Certificate-In-Coaching--An-Introduction-0). There may be some overlaps, but they are not the same thing.

As such, what are we trying to demonstrate? If this is about quality of provision, then coaching qualifications would be a good place to start, and you'd be best placed to reach out to NGBs, CIMPSA (potentially?) and others who have created their own coaching certifications. If this is about safeguarding then it's more difficult. Some places/sports have their own rules and standards around this but it's much more diverse (martial arts above is the most centralised as I understand; others may include the Rider's Code from London Sport (although I can't find info on that for some reason!)) and there are difficulties with gaining access to data on DBS checks for example.

@IzyChampion Thanks for this - and it's certainly the case that we're amalgamating two rather separate concerns here.

The question, I suppose, is whether the same technical mechanism works for both of them. At base, the proposal is about publishing a list of qualifications and a cross-reference linking these to particular organisations.

I feel safe in the assumption that coaching or training certifications fit this model well. But does safeguarding?

One wrinkle is that, as described, this proposal works at the level of the Organization: the trust expressed is in an institution and its own internal quality assurance processes. This means it shouldn't be necessary to gain access to DBS data - rather, the assertion is that the Organization pointed to itself carries out such checks in a reliable and trustworthy manner. But are Organizations in fact normally certified in this way? E.g. https://www.sportengland.org/our-work/safeguarding/safeguarding-in-martial-arts/ conforms to the model. But are there other approaches used?

Do we need to add a property (e.g., isSelfCertified) to capture instances where this is the case and flag up the trust risks here?

@thill-odi As far as I know the Martial Arts safeguarding code is fairly unique and there certainly isn't one standard way that organisations either certify or are certified that they have done things in a trustworthy manner as described above (although I believe that other parts of SE may be exploring whether the safeguarding code approach should be replicated across other sports, but I suspect this is a much longer term piece of work...).

There are some other places where safeguarding may be vetted (e.g. organisations that receive funding from SE must have appropriate safeguarding policies in place where required, although this would be limited to only covering England), some NGBs may require their members to meet the standards set out by the NSPCC's Child Protection in Sport Unit (https://thecpsu.org.uk/help-advice/assess-my-organisation/), and some organisations would self-assess against the same standards....

All in all, not a clear picture at all!

@IzyChampion: Okay, I think we need to flip this around a bit. What are the minimum (i.e., legal) requirements that need to be satisfied by activity providers? I assume SE has that information available?

@thill-odi I'm not sure there is a minimum from a legal perspective... (beyond a DBS perhaps?) but will do some digging to see what I can find

Based on further conversations with interested parties, esp. SportEngland:

At the level of NGBs (and SportEngland, sitting above them) there's a fairly clear-cut hierarchical model for how this ought to work. Typically, each NGB will define its own safeguarding code; although these will vary somewhat depending on the activity, they tend to have common components such as background checks (level 2 DBS, named persons responsible for safeguarding associated with each organisation, and appropriate governance structures. Membership of the NGB will often be conditional upon satisfying such safeguarding conditions, and reviews are conducted annually. In other words, safeguarding measures are often in place - but this is more an implicit precondition than an explicit statement. Typically, however, each organisation's safeguarding code is described somewhere on their website (e.g. https://britishwheelchairbasketball.co.uk/?mdocs-preview=1556&_mdocs-preview=3272c301a1); proof that a sub-organisation is indeed recognised by the NGB is provided by its affiliation number.

In addition, many NGBs have decided to retain the use of Clubmark for safeguarding purposes.

These safeguarding measures are explicitly not designed to be guarantors of safety; their purpose is as a deterrent, and to ensure that anyone who requires safeguarding has appropriate means of recourse should safeguarding fail.

There are concerns that this kind of hierarchical structure (individual clubs checked by NGBs; NGBs in turn assessed by SE) is overly onerous on small providers. Work is in place to develop a code to which such providers can affiliate through demonstrating appropriate policy, procedures, and practice - and though this is still being trialled, the Opportunity standard should be able to provide appropriate broad technical mechanisms to support this.

Further detail from SE re: leisure centres

A good provider will ....

let you see their policies and procedures on how they deal with any concerns raised about poor practice or abuse

give you the name of a welfare or child protection officer in case you have any concerns

show you written standards for good practice, such as a code of conduct for staff

ask you to provide essential medical and emergency contact information, and get your consent for your child to participate

be able to let you know about the types of things they do to make sure their staff are safe to work with your child

Reviewing the above, I think what we need is both a focus on specifics (the requirements of existing safeguarding standards) and greater abstraction (so that we don't get tied to a particular implementation too early and can ensure we're meeting safeguarding and/or qualification requirements as appropriate).

It seems we have five or six kinds of safeguarding assertion being made here:

Direct information concerning some specific activity provider - at a minimum, relevant policy and contact information regarding safeguarding.
Assertions concerning what constitutes good or adequate safeguarding practice
Assertions that some given organisation meets these standards of practice
Assertions regarding the trustworthiness of other organisations
Assertions that information has been published by a given organisation
Information about where one can obtain accreditation as meeting some standard of practice

As originally envisaged, points 1, 2, and 4 are dealt with by the CertificationScheme; point 3 is dealt with by the RPDE feed of TrustCertifications; point 5 is dealt with by the JSON embed; and point 6 by additional attributes suggested on an earlier call.

We also have an ecosystem defined by two types of publisher:

Opportunity Publishers
Certification Publishers

As proposed above, all points except for point 5 are dealt with by the Certification Publisher, with the Opportunity Publisher doing no more than providing an id whereby the Certifications can be linked to the Organisations.

However, it seems likely that we need more flexibility here, for two reasons:

It's not clear whether or which third parties are willing to publish certifications in the form specified above; we thus need to plan, at least in the short term, for an ecosystem whereby these certifications are unavailable.
Even in the case where such certifications are available, many long-tail (and not so long-tail) providers may not have the kind of affiliation or administrative infrastructure that will allow them to register and come to the notice of a publishing safeguarding authority: what if, for example, a sport lacks an NGB, or the NGB is not well-resourced?

In broad terms, then, I would propose that we need some kind of CertificationInformation object to be published by the Opportunity Publisher. This object that would consist roughly of:

an array of labelled URLs (the labels indicating the purpose of the URL, e.g. 'safeguarding code')
an array of ContactPoints (for named individuals associated with enforcing or auditing standards compliance, such as the Child Protection Officer)
In cases where a third party (e.g., an NGB) provides the safeguarding standard, additionally:
- a link back to the human-readable safeguarding standards they have defined
- an id recognised by this third party for the organisation (in the NGB world, this would be the 'affiliation number')
- a link back to a simple API (possibly but not necessarily, RPDE, as described above) whereby this id can be correlated with certifications
- it will be incumbent upon the third party to provide further information about how a certification is to be achieved

So, very roughly ....

Self-certifying

{
    "@context" : "https://openactive.io/",
    "@type" : "CertificationInformation",
    "certificationDocumentation": [
      {
        "@type" : "DigitalDocument",
        "url" : "https://someorg.co.uk/safeguarding/policy",
        "name" : "Safeguarding Policy"
      },
      {
        "@type" : "DigitalDocument",
        "url" : "https://someorg.co.uk/safeguarding/code-of-conduct",
        "name" : "Staff Code of Conduct"
      }
    ],
    "contactPoint" : [
    {
      "@type" : "ContactPoint",
      "contactType" : "Child Protection Officer",
      "name" : "Dan Nicholls"
      "email" : "d.nicholls@someorg.co.uk",
      "telephone" : "077777 555555"
      },
      {
      "@type" : "ContactPoint",
      "contactType" : "Welfare Officer",
      "name" : "Sheila Ambaye",
      "email" : "s.ambaye@someorg.co.uk",
      "telephone" : "077777 444444"
      }
    ]
}

Third-party certified

Opportunity Publisher

{
    "@context" : "https://openactive.io/",
    "@type" : "CertificationInformation",
    "certificationDocumentation": [
      "..." : "..."
    ],
    "contactPoint" : [
    "..." : "..."

    ],
    "regulatedBy" : {
      "@type" : "CertifyingOrganization",
      "name" : "Somesport NGB",
      "affiliationId" : "0123456789",
      "certificationEndpoint" : {
          "@type" : "WebAPI",
          "url" : "https://somesport-ngb.org/api/v1/certs",
          "documentation" : "https://somesport-ngb.org/api/v1/how-to"
          "..." : "..."
      }
    }
    "license": "https://creativecommons.org/licenses/by/4.0/"
}

Certification Publisher

{
    "@context" : "https://openactive.io/",
    "@type" : "Certification",
    "name" : "Martial Arts Safeguarding Code",
    "definitionURL" : "https://www.safeguardingcode.com/",
    "furtherInformation" : "https://www.safeguardingcode.com/getting-started",
    "reviewed" : "2020-01-01",
    "appliesTo" : {
      "@type" : "Organization",
      "name" : "Some Club"
      "affiliationId" : "0123456789",
      "url" : "https://someorg.co.uk"
    },
    "license": "https://creativecommons.org/licenses/by/4.0/"
}

Reflections from the 2020-04-22 call:

We need to think about user-journey, to ensure that providing this information doesn't become a burden on the provider. Boilerplate will help. In addition, the information should be associated with the organizer, not the individual session.
Where should this data sit in the JSON object? Associated with the Event? With the Organizer? Or .... where? And is the answer the same in all cases?
Consultation is needed with large-scale data users such as Change4Life to ensure this meets their standards.

Further thoughts to throw into the mix:

Do data users need the documentation, or are they satisfied with an assertion?

Perhaps when talking with Change4Life and others the above should be pitched against the alternative in #236, to check that:

If this is about self-certification, does the inclusion of the actual contactPoint and certificationDocumentation included above provide them sufficient value to warrant the work required by all parties to publish and maintain this, vs just publishing an assertion as per #236 ?
If this is about third-party certification, is the value of the assertion by the third party (however this is technically achieved, APIs, feeds, etc) more important than the actual contactPoint and certificationDocumentation?

Could we simplify this further?

Additionally, if the NGBs would be happy to publish feeds of their members (i.e. their affiliated organizers), then perhaps third-party certification could be as simple as publishing:

The organizers' affiliationId (or membershipNumber)
The NGB's identifier (memberOf)

(The below uses a different set of schema.org terms, just to throw some alternatives into the mix)

Opportunity feed: Within the booking system's existing open data:

{ 
  "@type" : "SessionSeries",
  ...
  "organizer": {
    "@type" : "Organization",
    "name" : "Some Club"
    "url" : "https://someorg.co.uk",
    ...
    "memberOf": {
      "@type" :"AffiliationMembership"
      "membershipNumber" : "0123456789",
      "hostingOrganization": {
        "@type" : "Organization",
        "@id" : "https://example.somengb.com/",
        "name" : "Some NGB"
      }
    }
  }
},

Organizer feed: In an "Organizer feed" from the third parties (e.g. NGBs), something very similar (this may also include human-readable safeguarding standards, defined for the hostingOrganization, and the structure below could be inverted to make it more efficient):

...
{
    "@type" : "Organization",
    "name" : "Some Club"
    "url" : "https://someorg.co.uk",
    ...
    "memberOf": {
      "@type" :"AffiliationMembership"
      "membershipNumber" : "0123456789",
      "hostingOrganization": {
        "@type" : "Organization",
        "@id" : "https://example.somengb.com/",
        "name" : "Some NGB"
      }
},
...

Third party list: Lists of recognised third parties (and similar) are published by trusted orgs such as Sport England:

[
  {
    "@type" : "Organization",
    "@id" : "https://example.somengb.com/",
    "feedUrl": "https://example.somengb.com/organizerfeed",
    "name" : "Some NGB"
  },
  {
    "@type" : "Organization",
    "@id" : "https://example.anotherngb.com/",
    "feedUrl": "https://example.anotherngb.com/organizerfeed",
    "name" : "Another NGB"
  }
]

Hence a very minimal implementation would be possible:

The trusted orgs
- Publish a static list (single JSON file) of third parties
The third parties
- Publish an open data RPDE feed of their affiliated orgs as above
The booking systems
- Use the static list(s) of third parties to populate a simple dropdown, with a "name" and "@id"
- Add a "membershipNumber" free text field
- Use the "name", "@id", and "membershipNumber" to populate their open data feed as above
- Could optionally consume the Organizer feeds to perform data validation on input
The data users
- Consume the feed from both the booking system and third party, and validates the claims in the booking system feed of the membershipNumber against those in the third party feed.

The above would be easy to forge by picking a random membershipNumber, however not sure how we could do more to prevent this without some kind of certificate signing / OAuth based approach with the third party.

The nice thing about this is that it's very simple for each system to implement, and for users it's simply a dropdown and freetext field to fill in.

openactive / modelling-opportunity-data