Standardising UK Trusted Research Environments in the Open

Dr Christian Cole

Health Informatics Centre, University of Dundee

The Need for SATRE

Our Approach

Lessons Learned

The Need for TREs

Huge potential benefits
Enabling researchers to work with sensitive data
Enforcing and encouraging good security
Keeping the confidence of data controllers, subjects and the public

The Current TRE Landscape

Fragmented
Diverse approaches
Narrow focus
No TRE standard

- Fragmented, not coordinated - Some commercial offerings - Many universities/institutions building/operating their own TREs - Variety of approaches - Secure rooms - Remote desktops (direct data access) - Query based (no direct data acess) - TREs may be fairly bespoke, focused on a particular use or domain - No TRE standard - No accepted definition of what a TRE is - Existing standards (ISO27001, DSPT, DEA) do not make your infrastructure a TRE - Some community groups to share expertise, coordinate, unify - LINK: - Current situation - The need for TREs is clear - But not much coordination or agreement on what is a TRE or what one should be

A Standard Architecture

Define a TRE baseline
Co-created by the community
Supports accreditation
Move towards interoperability

- A mark of quality for UK TREs - Enable comparison across TREs - Encourage all TREs to raise standards - Designed by the community - Ensure buy in, which is necessary for adoption - Includes designers, operators, users - What is important - Balance productivity and security - Supports accreditation - Could be used as the basis for an accreditation - Self assessment or evidence based - Encourage interoperability - Potential for better research working easily across TREs

The Need for SATRE

Our Approach

Lessons Learned

Diverse Collaboration

Working in the Open

github.com/sa-tre

satre-specification.readthedocs.io

medium.com/satre

Contribution Governance

Consensus through discussion and feedback
Code of conduct to enforce community standards
Clear consensus mechanism
Open to contributions from anyone

- Build consensus through discussion and review - Discussion issues - PRs require approval - CoC standards reassure and welcome contributors - Consensus mechanism - avoids disputes or strong personalities controlling the process - helps coordinate many contributors - lazy consensus - explicit approval - Link: - This kind of governance enables contribution - However, it does not guarantee it - We have spoken about the rules, but not how we work

Collaborative Work

Collaboration Cafés, coworking, work package meetings
Synchronous events help focus and reach agreement
Can directly support community involvement
Asynchronous work respects time
We do both

- Collaboration Cafés foster discussion on narrow topics - Weekly team and work package meetings - Frequent ad-hoc coworking sessions - Synchronous events can help focus effort on a particular topic - Particularly important when engaging the community - Unfair and unrealistic to expect long term dedication - Asynchronous work saves time - Reply when you are available - Different time zones and commitments - Link: - Events and asynchronous tools, particularly collaboration cafés, help us engage people - Many of these people will want to contribute - We need to support them contributing - In particular, many are unfamiliar with GitHub

Community Co-creation

Enabled by working in the open
Support and recognise other contribution routes
Team members translate non-GitHub contributions to Markdown
Contributions all end up on GitHub and the site

- Enabled by working in the open - Critical for us to support those who don't use GitHub - Not everyone is 'technical' and knows how - Not reasonable to expect everyone to learn - Other ways to contribute - Form - Email - Collaboration Cafés (shared note taking) - Public engagement events - Team members/community members translate to GH items - Contributions ultimately appear in GitHub and the specification site - Contribution routes are all valid - Maintains history - Link: - We have engaged and enabled collaborations from enthusiastic people - We also worked to actively approach important stakeholder groups

Stakeholder Focus

strategic stakeholders	builders and operators	users
influential organisations	make or run TREs	work in TREs
set requirements	technical and process experts	focus on productivity
direct engagement	collaboration cafés, GitHub	user testing sessions

- Active effort to involve key stakeholders - Groups identified and engaged in different ways - Recognising the different skills, domains of those groups - Strategic stakeholders - Influential in TRE space - _E.g._ ONS, NHS - Direct engagement - Builder and operators - Those who make or control TREs for their organisation - Engaged mostly through collaboration cafés - Invited to contribute directly - TRE Users - People who work in TREs - Greater focus on productivity, familiarity, results - User testing sessions - Link: - There is another key stakeholder group that we made a particular effort to enage - The public

Public Engagement

TREs rely on trust
Two public members
Public engagement sessions
Influenced specification and processes

Leading by Example

Follow our own rules
Evaluating our implementations
Commitment to bridge the gap

Sustainability

Standard needs to live on
Laying the groundwork
Dedicated time needed for stewardship
Seeking future funding and community support
Using the standard is contributing

- To be successful, the standard needs to live on - Evaluations against the standard - Building upon the standard - Contributing to the standard - We are laying the groundwork for a sustainable, community project - Open documents - Established governance - Established community - However, future funding needed - Needed for stewardship - Engagement - Future - Seeking funding for dedicated time - DARE phase 2 - Support from Dundee, Turing - Working with community leadership to adopt, maintain, build on the standard

The Need for SATRE

Our Approach

Lessons Learned

The Benefits of Working in the Open

Better engagement
Transparency and trust
Governance doesn't have to be perfect
Recognising contributions

- Our key message - Open working is not just beneficial to OSS - Particularly important when you need engagement, trust - An open project means - People can see and comment on your work in progress - There are clear routes to contribution - Being able to see what you are doing - Builds trust - Shows you have good intentions - You should start open, from the first contribution - Good practice from the beginning - Clear distinction between public and private (e.g. survey) - Making a project open later is difficult - Contribution process, code of conduct _etc._ helps people to contribute - Codifying this takes time. It is OK to be good enough and change your processes when there is a need - Link: - We could have taken better advantage to get early feedback

Get Feedback Early

Avoid wasted effort
105 survey responses from 55 organisations
Could have been more effective
Take advantage of version control and open working
Changes are more frequent but take less time

- Wasted effort - Trying to produce complete items without feedback - Finding that what we had done was not right - For example the survey - Around two months to create, share, analyse, process results - We are proud - 105 responses, 55 organisations - Strong feedback that survey wasn't particularly helpful, asking wrong questions, wrong focus - Now we take advantage of version control and open working to get feedback earlier - Open discussion about ideas early - Propose changes and ask for feedback - Use collaboration cafés to show what we are working on and improve - More comfortable committing 'draft' items to development branch (releases remain) - Community feedback leads to many, sometimes large changes - Overall it saves effort as we do not invest in the wrong things - LINK: - Collaboration cafés are an excellent way to get feedback

The Power of Collaboration Cafés

The best way to get community input
Led directly to significant changes
Preparation, promotion, processing
Facilitators are necessary

- Collaboration cafés have been the best way to get community input - Breakout room discussions have led directly to significant changes - Recognising the important of information governance - Switch from feature focus to capability focus - Modifying the specification - Adjusting project governance and routes to contribution - Changing evaluation process - You need to prepare in advance. A collaboration café should have an agenda and materials prepared - After a collaboration café the discussion needs to be summarised and translated into actions - Facilitators keep discussion on topic, help ensure everyone has their say. Especially when many people attend - LINK: - We are proud of the number and diversity of people attending. Active promotion and engagement was very worth the investment - It took a lot of effort to make them as successful as they were

Effective Engagement Takes Effort

Provide scope and context
Make good use of people's time
Be flexible and accommodating
Lead by example
Value roles like PIE Professionals, Community Managers, Application Managers

- Our initial approach was "participant-driven", asking attendees what they wanted to talk about at events - It was difficult for us to keep focus and it was difficult for collaborators to know how they could help - Moved to preparing focused events, asking specific questions - More productive and clear when our approach is not aligned with the community - Time is limited, particularly when engaging with the public - They are not paid to help us, we must respect their time and not waste it - Focus on short and direct engagements with clear goals - Don't expect people to devote time or be engaged over long periods - You must enable people to contribute - Not everyone can/will use GitHub - Support how the community wants to work - Help adapt contributions - Your "core team" should be active and visible at collaboration events - It is important to avoid an "us and them" perception - Roles focused on community and engagement have been critical - They bring expertise and a desire to do work RSEs (or other tech focused roles) lack

Public Involvement Matters

Bring knowledge and perspectives you may lack
Helps communicate your message
Public as valued, core team members ensure voice is heard
Recruiting the public is challenging

Reflections

Need for standardisation
Community consensus is critical
It takes effort to engage the community

We encourage others to adopt these processes whenever community involvement is important

Acknowledgements

This work is funded by UKRI Grant MC_PC_23008 as part of Phase 1 of the DARE UK programme, delivered in partnership with HDR UK and ADR UK

Also supported by the Ecosystem Leadership Award under EPSRC Grant EP/X03870X/1 and The Alan Turing Institute

Everyone who has contributed

Join Us

Read The Specification

satre-specification.readthedocs.io

Read Our Blog Posts

medium.com/satre

Get Involved

satre-specification.readthedocs.io/en/stable/contributing
satre-contact@dundee.ac.uk