[Change]: Review of Specification page

[jawsgrant]

Summary

Suggestions on specifications page

Source

Personal contribution

Detail

Order seems a little disjointed and I don't quite follow the structure section
Starts with capabilities, then Structure of the specification, which gives importance label of components, then structure, which has four 'parts'? but only seems to define 'three categories'?

Refactoring could rearrange to: Overview, Structure, Arcitecture Principles, Specification Pillars and Capabilties, and improve consistency
Are roles needed here?, if so, should they have a heading here as well
Similarly/oppositely should Specification Pillars and Capabilities be shorter here, and have its own separate page, or an overview page in its own section.

Where

https://satre-specification.readthedocs.io/en/latest/specification.html

Proposal

The SATRE specification

The specification is presented in terms of the capabilities that a team running a TRE should aim for across all aspects of TRE provision.

This page explains what the specification is, and how it’s structured and how the importance of components is categorised. Consult the FAQs for more on what the specification is not.

Structure

The SATRE specification contains four, how many, only three seem to be listed key parts:

Figure (with alt text?)

Architectural Principles:
The principles that all TRE operators looking to use the specification should hold themselves accountable to.

Specification Pillars:
The broad areas of TRE provisioning the specification covers. Each pillar comprises one or more capabilities. Each capability consists of one or more components.

Roles:
Roles that are necessary for the operation and use of a TRE.

Together, these provide a framework that TRE operators can measure themselves against.

Categorisation

(!) Note

Throughout this document, we will use the term “TRE operator” to refer to the team running a particular TRE.

The TRE capabilities are broken down into components. Each component is a statement of a process, method or practice that the operators should have in place to ensure they fulfil the capability requirements. These components are each labelled with an importance:

Mandatory:
This is required: if this component is not supported, then the capability, and therefore the specification, is not met.

Recommended:
Most TREs should have this component, but it is not essential.

Optional:
Many TREs would benefit from this component, however, we recognise there are reasons a TRE operator may actively choose not to implement it.

TRE operators are able to demonstrate that they meet the specification by showing they can fulfil all mandatory components. Future versions of the specification may introduce more granular levels of evaluation, for instance tiered level of accreditation based on fulfilment of mandatory, recommended and optional components respectively.

Any particular TRE implementation should be able to score itself against each capability.

Might it also be useful to mention that when we evaluate against these we also have, Not met, sufficient and Satisifed, to give a complete, spec<->eval picture?

Architectural Principles

The SATRE specification has been developed based on the following architectural principles:

• Usability
• Maintaining public trust
• Observability
• Standardisation

Is the figure needed for specification pillars? can this not be an overview to the specification pullas section? Or a page in its own right per Arch. P.s, Roles, FAQs?
Some TRE Operator links in this section miss out the 's' where plural

Specification Pillars and Capabilities

1. Information governance
   What the TRE operators do to ensure information risk is measured and managed to an acceptable level.

2. Computing technology
   What the TRE operators do to manage systems for storing, retrieving, and sending information.

3. Data management
   What the TRE operators do to manage data assets and ensure information remains secure.

4. Supporting capabilities
   A TRE operator will need to possess various supporting capabilities, such as complying with legal requirements and managing relationships with stakeholders.

Roles

A TRE needs to consider many different stakeholders. SATRE provides specific roles which may or may not match titles used in your organisation. However each of these are important to the successful operation of a TRE. Roles are grouped into:

1. Project Roles
   Roles for TRE end-users conducting research or analysing data in the TRE and others involved in managing this research.
2. Data Management Roles
   Roles for people managing data and databases used in a TRE
3. Infrastructure Management Roles
   The IT professionals and software engineers who will be responsible for developing, deploying and managing instances of a TRE conforming to the SATRE specification.
4. Governance Roles
   Roles that uphold the governance of TREs. Such governance responsibilities typically involve establishing policies and procedures to ensure the responsible use of data, protecting the privacy and confidentiality of research participants, and promoting transparency and accountability in research activities.
5. Public Roles
   Roles that concern members of the public with regard to TREs and TRE research.

Who can help

No response