Using and implementing the SATRE Specification

Collaboration Café 20th July

Photo by CoWomen on Unsplash

Introduction

On 20th July the SATRE project held its 8th Collaboration Café, which have been running throughout the project to engage external stakeholders in shaping the project and the specification. To register your interest for future Collaboration Cafes, please fill in the form.

SATRE (Standardised Architecture for Trusted Research Environments) is one of 5 ‘driver projects’ funded by DARE UK as part of their Phase 1b funding call.

Any project needs to ensure that its outputs are not only made available but also usable. For SATRE this means that the specification itself is written and presented in such a way that TRE teams and institutions can easily implement it. Otherwise, it would risk becoming an interesting but inconsequential research output.

What better then than to ask potential users of the specification what they would need in order to adopt and implement SATRE?

This is what we did on our Collaboration Café on 20th July, by asking attendees:

  • Does the current structure and content feel like the right approach?
  • What organisational buy-in would we have to have for you to trust it/want to use it?
  • What other existing accreditations, recommendations or architectural blueprints would it need to align with?
  • What barriers would there be to you making your TRE SATRE aligned?

Setup & Discussion

For the session, and after some summer songs recommendations, we split into two breakout rooms to ensure all 22 attendees had the opportunity to share their thoughts and opinions. Additionally, the main room remained open for a general discussion and introductions to the project.

Rather than assign specific questions to each breakout room, we had an open conversation around the questions above. We were joined by professionals deeply engaged in providing and using TREs, as well as those involved in deciding how to access and use research data, meaning we had good representation from those who will actually either implement or adopt the SATRE specification.

Some key points that came up in discussion included:

The specification as an information store: It was pointed out that a positive aspect of it is that it reflects a collection of best practices, some which may seem obvious but need to be stated, which makes the specification useful just by putting them together, regardless of its enforcement.

The problem of adoption:

The challenge of achieving ample adoption without actual enforcement or being required by institutions in order to handle sensitive data, as it happens with NHS’s DSPT, was discussed. This is also related to the existence of numerous accreditations and recommendations. As a solution it was proposed that SATRE should share common principles and a clear way of assessing how much of one specification is already covered by another, in particular this point made reference to ISO27001 and how positive it would be that, if a TRE is already ISO27001 accredited, they could easily understand what aspects of SATRE are immediately met.

Navigating the specification itself:

It was proposed that a clear numeration should be added along with a column to specify if each requirement is ‘mandatory’, ‘recommended’ or ‘optional’. The SATRE team has since implemented this, clearly reflecting how open participation is making SATRE better. Related to this a participant pointed out how some phrasing made it unclear whether the project or the TRE operator were responsible for meeting a specific requirement. The team opened an issue to explore this further.

Photo by Regis F on Unsplash

Next steps

Following the Collaboration Café, and feedback from the community, we are taking the following steps as a project team:

  • Improve readability
    We have already introduced some of the suggested changes above to make the specification easier to navigate- clear numeration has been introduced along with an additional column indicating if a requirement is ‘mandatory’, ‘recommended’ or ‘optional’.
  • Clarify wording on responsibility
    We have changed some wording to better reflect who is responsible for meeting requirements, for example in 1.3 Risk Management, which we did via this issue.
  • Accreditation mapping
    This is important feedback on how to improve the usability of the SATRE specification, TRE teams may have limited capacity to go through the several accreditation processes as each one can be time consuming. Reducing that workload by having a way of bidirectionally matching different requirements would significantly help, and it would be an incentive to implementing SATRE — if you are halfway there, why not make a push and get another accreditation?
    We will explore how this can be achieved, right now we have opened this issue on our repo to continue the conversation.
  • Continue to engage the community and public
    We will have further Collaboration Cafés, for which you can find the schedule and topics here, and keep welcoming any and all contributions directly to the specification repo or by contacting us directly. Additionally, we will strive to ensure the specification continues to grow beyond the current project funding via community ownership of it.

For any questions about the SATRE project, please get in contact with us via satre-contact@dundee.ac.uk.

And to register your interest in any future Collaboration Cafes, please fill in this form

--

--