Applying a Maturity Model to Trusted Research Environments – Part 2

In the first part of this series we considered the organisational goals of a TRE and how those goals might map to different levels of capability. However, researchers, data stewards, institution PIs and data contributors rarely think in terms of maturity models. A question from researchers, data stewards and institution PIs may be on how their use cases map to that maturity model.

They want to analyse a dataset securely, use a particular software package, to compare their results against another cohort and to collaborate with researchers at another institution. Users also want to make a dataset available for approved use without distributing copies of it, and want to know what data assets their organisation already holds.

Rather than considering the maturity model as a hierarchy of features or levels of “better”, an alternative approach is to think about the common scenarios organisations and researchers encounter and how they map to the maturity model.

Scenario 1: Controlled access to a known dataset

Many TRE deployments begin with a relatively straightforward requirement. Researchers need access to a known dataset, a standard set of analytical tools, and a controlled environment in which to work.

At this level, a layer 2 environment may be considered. The data is typically already known and approved. The researchers are known. The software tools are largely standardised. Governance processes are relatively straightforward because the scope of the work is well understood. An example of this would be a researcher accessing an national prescribing dataset in a TRE run by a government agency or institution.

The trade-off is flexibility.

Researchers are generally restricted to approved software, approved infrastructure configurations, and approved datasets. Bringing in additional data, installing specialist tools, deploying novel workflows, or collaborating outside the original project scope may require additional governance processes or may not be supported at all. For projects with well-defined, constrained requirements this is often entirely appropriate.

However, the challenge arises when researchers begin asking questions the platform was never designed to answer:

• Can I install a specialist package (or can the TRE owner do it)?
• Can I deploy my own pipeline?
• Can I bring in other datasets?
• Can I compare against another cohort?
• Can I build my tools within the environment?
• How do safely egress my outcomes?
• Can I collaborate with another researcher inside or outside my organisation?

These questions are about flexibility and collaborative development beyond just secure access.

Scenario 2: Flexibility in tools and methods

Research (and discovery) is often an evolving process. A project may begin with a single approved dataset and a defined methodology, but successful projects frequently evolve. New datasets become available, new analytical approaches emerge and collaborators like to bring their own tools and workflows. Researchers wish to apply methods that were not anticipated when the environment was originally commissioned.

At this level, a layer 3 environment must be considered. From an organisational perspective, this is also often the point where assurances become a real concern.

Many TREs describe themselves as “aligned” to standards such as ISO 27001, Cyber Essentials Plus, or other recognised frameworks. While alignment may indicate that appropriate controls are being implemented, it should not be confused with independent certification. Organisations procuring a TRE should understand which certifications have actually been achieved, which are in progress, and which remain aspirational.

For organisations working with sensitive health, genomic, or other regulated data, these distinctions matter. A TRE is ultimately expected to provide not only security controls, but also assurance that those controls have been independently assessed and are operating effectively.

Scenario 3: Discovering and combining data assets

As organisations mature, a different challenge begins to emerge. Researchers often spend significant amounts of time trying to determine what data exists, who owns it, whether access can be requested, and whether a suitable cohort has already been assembled by another project. In many institutions there is no easy answer to these questions.

At this point the challenge is now data discovery and stewardship, not infrastructure.

Layer 4 capabilities address this through data catalogues, cohort discovery, embedded access request processes, data engineering services, linkage capabilities, versioning, and support for standards such as OMOP and FHIR. The benefit beyond the catalogue, is the organisational visibility of data assets:

• Researchers can discover what exists.
• Data owners can understand who is requesting access.
• Institutions can understand what data they hold and how it is being used.

At this point the TRE is now helping the organisation see and manage its own data.

Scenario 4: Collaborating without distributing data

While most TREs are designed to protect data, few are designed to share access to data safely. This distinction becomes increasingly important when research extends beyond a single organisation.

These requirements change what is expected of the platform beyond the simple access and tooling from the earlier scenarios:

• How do I allow approved access without distributing copies?
• How do I collaborate across institutions?
• How do I compare datasets held by different organisations?
• How do I participate in a national or international research network?
• How do I support federated analysis while keeping data under local control?

These are typically Layer 5 requirements.

At this level the TRE is no longer supporting a single institution, it is supporting an ecosystem of activities that might include a data mart for secure access to key datasets, metadata federation, federated analysis and learning analysis and secure offline AI.Data remains under the control of the contributing organisation at all time, while still participating in broader research activities. At this layer, the TRE is a key piece of infrastructure for enabling research collaboration at scale.

Scenario 5: Building a strategic research platform

The most mature TREs are characterised by their ability to adapt to changing requirements and environments, rather than a simple list of features.

At this level (Layer 6) the TRE becomes a strategic asset for the organisation:

• attracts collaboration.
• enables participation in national and international programmes.
• supports industry engagement.
• provides a sustainable operating model capable of supporting research at scale.

Summary

TRE Maturity is not a score or a league table. It is about matching capability to what users actually need to deliver.

A university supporting a relatively small internal research community may be well served by a Layer 3 TRE. A national programme or institution aiming to enable collaboration across institutions and jurisdictions may find that its requirements begin at Layer 5. Neither approach is inherently better. The important question is whether the platform capabilities match the ambitions of the organisation and the needs of the researchers it serves.

Many TREs begin life supporting a single project or a specific organisational requirement. However, if the platform is successful, it will inevitably be asked to do more. Additional datasets will need to be onboarded. New collaborations will emerge. Researchers will request different tools and methods. Governance and regulatory expectations will continue to evolve.

The maturity model is intended to support these discussions and assist in planning for the future. What is good enough for short term immediate use-cases is unlikely to provide the scale, security and capabilities demanded as a platform grows. Using this model can avoid expensive short term decisions and support longer term planning as the system evolves.

If you want to know more about the Aridhia DRE and how it can support your TRE journey, please contact us.