diff --git a/docs/source/evaluation.md b/docs/source/evaluation.md index 320d74b4..60b08326 100644 --- a/docs/source/evaluation.md +++ b/docs/source/evaluation.md @@ -40,7 +40,7 @@ You should score your TRE against each statement in the SATRE specification usin :0 Not met: The TRE does not meet this requirement (if this is **Mandatory** this means the TRE is not SATRE compliant) :1 Sufficient: The TRE meets this requirement met but there is substantial scope for improvement :2 Satisfied: The TRE meets this requirement met but there may still be scope for improvement -:N/A: Not applicable: The statement is not relevant to a TRE, may apply to **Recommended** or **Optional** statements +:N/A: Not applicable: The statement is not relevant to a TRE, may apply to **Recommended** or **Optional** statements, and a very limited number of **Mandatory\*** statements. A score of **1** or above means you have met the requirement. Optionally you can use **1** and **2** to indicate potential areas of improvement in your TRE. diff --git a/docs/source/pillars/supporting.md b/docs/source/pillars/supporting.md index 86f68a00..746b9481 100644 --- a/docs/source/pillars/supporting.md +++ b/docs/source/pillars/supporting.md @@ -189,18 +189,23 @@ How the {ref}`TRE operator ` involves the public in its pr - Guidance - Importance * - 4.8.1. - - You should ensure that all public engagement activities are representative and inclusive. - - Any public engagement activity carried out by TREs should make sure they are involving a representative sample where possible and that activities are accessible and open. + - All public engagement activities must include a range of perspectives and be inclusive (\*optional for TREs without personal data). + - Any public engagement activity carried out by TREs should involve diverse participants and that activities are accessible. + Recruitment plans should consider how to proactively reach a representative sample of people or target particular groups of people where relevant This could include following guidelines such as [PEDRI](https://www.pedri.org.uk/). - - Recommended + - Mandatory\* * - 4.8.2. - - You could publicly share the details of any projects which use the TRE. - - This may be via the TRE website or annual reports. - - Optional + - Details of TRE operations, data available and projects which have accessed the data should be publicly available (\*optional for TREs without personal data). + - TREs should be as transparent as possible by providing information online. + Where information is made available online this should be written in clear language understandable to general public. + A record of projects which have accessed data via the TRE should be kept and made available. + Where possible it should include name, summaries, public benefit (if relevant) and organisations involved + - Mandatory\* * - 4.8.3. - - You could include members of the public in your approvals process. - - This may be carried out via a separate public panel or by including members of the public on an approvals panel. - - Optional + - Members of the public should be included in TRE operations and/or oversight (\*optional for TREs without personal data). + - Members of the public can be involved via presence on steering groups or project approvals panels. + Alternatively TRE's can establish separate public panels available for both researchers and TRE staff to consult. + - Mandatory\* * - 4.8.4. - You should publicly share details of incidents, near misses, and mitigations in a timely fashion, in line with good practices for responsible disclosure. - This may be via the TRE website or annual reports. diff --git a/docs/source/specification.md b/docs/source/specification.md index d62cbca4..b60ff538 100644 --- a/docs/source/specification.md +++ b/docs/source/specification.md @@ -73,6 +73,9 @@ These components are each labelled with an importance: :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 {ref}`TRE operator ` may actively choose not to implement it. +Some components are mandatory in some circumstances but not others. +These are indicated by an asterisk `Mandatory*`, with details provided in the statement. + {ref}`TRE operator `s 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.