Building a Federated Trusted Research Environment

In his previous blog Ross introduced the DARE UK TREvolution project and explained Aridhia’s involvement in it. At the end of the blog he promised an update once we had submitted our interim project report to DARE UK, that report has now been submitted and is available here:

https://zenodo.org/records/17573488

This blog provides more detail on the work carried out so far, and details our plans for Q1 2026.

Workspaces as federated infrastructure

Our experience of working on data federation projects suggests that one of the biggest blockers to the creation of scalable federated networks is the timely provision of suitable infrastructure.

For some time we have believed that a DRE workspace could be used as pop up federated infrastructure, with data hosted in a workspace database, and the hub Azure Container Registry (ACR) holding the approved analytical code. If possible this would allow data owners to quickly and securely join federated networks by spinning up a workspace, avoiding a lengthy central provisioning process with their own IT department.

The TREvolution project has provided us with an opportunity to test this theory in practice. As the interim report details, a Federated Node (FN) was deployed to a hub subscription, we then mapped to data hosted in a workspace database, and used the hub ACR as its query library.

To test this:

This proved that in principle a DRE workspace can be used as federated infrastructure, but also clarified the current limitations of this approach.

Current limitations

Proving that the above is possible was an important first step, however setting up the FN and associating with the workspace database and ACR was heavily manual process. While it would be repeatable on a relatively small scale, a more self-service user experience is required to make the process truly scalable.

Each DRE hub can be subdivided into organisations, each organisation has its own users and workspaces. We believe this concept can be expanded to allow an organisation to own a FN. Where desired this would allow a hub organisation to be mapped to a deployed FN, making it possible for a workspace administrator to connect a workspace database to the organisations FN without any additional support.

The scenario below explains how this will work in practice

Future workflow

Research Hospital X (RHX) has a requirement to join a federated data sharing network with collaborators in another country, and want to use one of their Aridhia workspaces to host the data.

1. Setting up the FN

They contact the Aridhia service desk and ask for federation to be enabled in their hub organisation. To do this the service desk deploys a federated node into the RHX hub subscription and maps it to the DRE organisation which contains all RHX members and workspaces. This includes all networking and admin updates required to allow a workspace to interact with the FN.

2. Mapping the data

The RHX team push the data for the network into a workspace, and use it to create tables in the workspace database. A workspace administrator from the RHX team now chooses to connect the workspace to their organisations FN. The workspace database is now available to the FN.

3. Securing the workspace

Once the mapping is complete the administrator uses the DREs native data usage conditions framework to apply a ‘data federation’ condition to the workspace, warning users that the workspace is connected to a federated network and limiting their ability to push further data into it.

Enabling data access requests

The data owner can now create a metadata record in the FAIR catalogue and associate this with the organisations FN, this allows them to manage access requests and issue auth tokens for the federated data via Aridhia’s integrated data access request (DAR) process.

How far away is this?

The ability to map a deployed FN to a FAIR metadata record already exists, and can be managed by data owners without any assistance. The DRE already has a native conditions framework, and adding a dedicated federation condition would be a relatively small piece of work.

However, our focus in Q1 of 2026 as we come to the end of the TREvolution project will be introducing organisational ownership of Federated Nodes, as this will provide the biggest boost to making data federation truly self-service.