Home Blogs & News

Applying a Maturity Model to Trusted Research Environments – Part 1

Trusted Research Environments (TREs) have been in existence for well over 10 years now and during that time have developed in a variety of different ways depending on the requirements and the approach taken to their implementation. They range from relatively simple infrastructure configurations (compute, storage, applications, authentication, and networking), to feature rich environments which offer higher layer services (data catalogues, federated capabilities, billing & re-charge, AI sandboxes etc.).
Despite this wide disparity in capabilities, each implementation is often simply referred to as a TRE, implying a parity in the services being offered. As noted in the recent UK Health Data Research Service Ecosystem Analysis Report, TRE maturity and user experience varies considerably.

This presents significant difficulties to organisations and to research teams. For an organisation trying to gauge what level of TRE capability to offer (and therefore what funding is needed) which implementation should be used as a reference model? Similarly for an organisation with an existing TRE, how should it benchmark its services against its peers? For a research team requiring access to several TREs, what differences in features and in user experience is it likely to encounter?

In part one of two blogs on this topic, we will consider the organisational goals of a TRE, how a capability maturity model can be used to express those goals, and what a strawman TRE capability maturity model looks like.

SATRE and EHDS

In the UK, the Standardised Architecture for Trusted Research Environments (SATRE) specification has been developed to help address this issue. SATRE captures a set of guidelines and best practices which can be used to evaluate a TRE and its capabilities. At Aridhia, we have evaluated our Digital Research Environment against SATRE, a detailed exercise looking at a broad range of categories with over 160 different evaluation questions at the last count. Organisations will determine what the comparative scores in different areas mean when taken together.

We can also expect that as the European Health Data Space standard is established, different TRE (known as Secure Processing Environments or SPEs in this context) models will be promoted. These models will all conform to the EHDS regulation, albeit the current detail on what should constitute a SPE is currently limited compared to SATRE, but we would expect this to change when specifications are published in 2027.

ESOC-Entrust is another TRE framework, focussing on the creation of a blueprint for federated data and analysis. A mapping of high-level requirements and best practices is currently being captured by a survey for publication later this year.

What are the organisational goals of the TRE?

An organisation will likely need a TRE to conform with information governance and cyber security standards, whilst providing a suitable feature set for its user-base. However, there are many other aspects to consider, for example:

• Is the TRE needed purely to serve an internal user-base?
• What is the diversity and skill set of that user-base?
• What range of tooling and compute is required?
• Is there a requirement to collaborate with other organisations?
• Will the TRE be local, national or international in scope?
• Will the TRE be funded internally, or does it aim to attract funding through external collaborations?
• To what extent is regulatory engagement a requirement? (MHRA, EMA, FDA)

For an organisation starting out on their TRE journey, SATRE may present a layer of implementation detail which is difficult to digest and put into the context of these organisational goals (also SATRE does not yet cover some of the higher level services mentioned earlier). At this stage, a simpler framework may therefore be needed, where institutions can clearly map their requirements against capabilities, before conducting a deeper dive into what the applicable features should be.

As a comparison, the Five Safes framework allows organisations to consider how to safely provide research access to data. It breaks this down into the five categories of safe projects, safe people, safe data, safe settings, and safe outputs, allowing organisations to evaluate each area and consider what high-level controls may be needed. However, it is not a standard or a specification, it does not tell you what to do or how to do it. An organisation can use five safes as a useful starting point to guide them, before jumping into the implementation layer detail of an information security standard such as ISO27001.

Similarly, as a pre-cursor to conducting a detailed evaluation using SATRE or some other framework, organisations could first consider how a TRE maps to a maturity model.

Capability maturity models

Maturity models are a common way of measuring an organization’s maturity within a particular discipline. It allows them to understand their current layer of capability, to plan for improvements, and to allow for comparisons across peer organisations.

The Capability Maturity Model was originally developed to measure and improve software development processes but can essentially be tailored to many different disciplines and technologies. In healthcare, the HIMMS community has developed several models, such the Electronic Medical Record Adoption Model (EMRAM). EMRAM measures an organisation’s adoption of electronic medical records (EMR), looking at clinical outcomes, patient engagements, and clinician’s use of EMRs. Hospitals who engage with this model, work towards achieving stage 7, which represents the highest degree of digital maturity. Organisations working at this layer have highly integrated and digitised medical records, which demonstrably improve care quality and operational efficiency.

A strawman maturity model for TREs

A maturity model will help organisations map their goals to the different TRE implementations which exist and provide a roadmap for continuous improvement.

At Aridhia we have spent the last 12 years working with a broad group of constituents in this field, including clinicians, academic scientists, data scientists, data stewards, data contributors, IT teams, and information security specialists, and then using that knowledge to build out our Digital Research Environment service. Based on that experience we have put together the following maturity model as a strawman for consideration.

Maturity in this context is therefore several different dimensions including organisational capabilities, technical sophistication, data availability, governance processes, certification, scale, and interoperability.

Layer	Capability
0	Ad hoc data access
1	Foundational infrastructure
2	Controlled environment
3	Certified platform
4	Integrated data & research services
5	Multi-organisation and federated research platform
6	Strategic research platform

Taking each layer in turn:

Layer 0 assumes no TRE capability is in place. Data exports to researchers (e.g. emailing spreadsheets around) are done on an ad hoc basis, with little or no formal tracking of where data has gone or who has access.

Layer 1 consists of a basic infrastructure service, where structured data is accessed either through a workspace or user based segregation. The infrastructure will likely consist of virtual compute, storage, networking, and basic authentication, presented to the user as a virtual desktop. This TRE could be deployed in on-premises or on cloud environments.

Layer 2 adds enhanced authentication (MFA), authorisation (RBAC), audit, and an airlock for controlled export of data. Users are given a suite of standard software packages and tools. A basic service desk is provided with support for user onboarding.

Up to this point the TRE will likely have been built by an internal IT team in response to demand from end users primarily wishing to work with pre-approved structured datasets which come from a datastore upstream of the TRE.

There is typically a lack of flexibility at this layer, with users limited in their choice of software tools, compute options, and the ability to bring their own data.

EHDS as currently defined is equivalent to Layer 2, albeit this may change as the legislation develops.

At Layer 3, the environment is certified to an appropriate standard with governance controls in place. In the UK for example this would be ISO 27001 and Cyber Essentials Plus. The TRE would be delivered to transparent Service Level Agreements, with clear user documentation and training options available for users. DevOps processes would be in place supporting automated deployments, ideally with zero-downtime for most upgrades.

Users can also bring their own software tools and data, subject to approval, for use with multi-modal data. Data ingestion options and API level integrations are offered. Flexible and scalable compute, storage, and other infrastructure services would be available to researchers.

At this Layer we can expect that an external vendor would provide the TRE, or that the internal IT team which has built the TRE has involved their Information Governance department and a Data Steward team to extend their in-house development to gain the relevant certifications. The TRE user interface would have progressed beyond a simple virtual desktop to a modern user-centric design based around journeys and workflows.

We would expect an organisation which has evaluated its TRE against SATRE and scored well, to be operating at Layer 3.

For Layer 4, we see increasing levels of maturity in data management and research enablement. FAIR data principles would be emphasized, ensuring that data is Findable, Accessible, Interoperable and Re-Usable. This would likely be a data catalogue with a cohort builder. Access to datasets and cohorts would be subject to an embedded software-driven approval mechanism. These capabilities are viewed as outside of the scope of a TRE by some, nevertheless for a TRE to operate efficiently we would argue that reducing barriers to data discovery and acquisition are fundamental to its success.

Enhanced data engineering capabilities would be supported at this layer, which could be in OMOP data modelling, data linkage, pseudonymisation, curation pipelines, code repositories, versioning, and disclosure control. Access to a variety of source data repositories would be available including API based access and support for standards such as FHIR. The internal Data Steward team would be heavily involved in bringing these capabilities to their user base.

From this layer onwards it becomes operationally challenging for a TRE to be an internally built service, given the range of functionality needed and the considerable overheads involved in ongoing maintenance. Many organisations will therefore choose to collaborate with an external vendor at this point.

At Layer 5, the TRE offers multi-organisation research collaboration, nationally and potentially internationally. This could be a multi-tenanted model, implemented across multi-cloud and hybrid configurations if required. For example, federated analysis could allow queries to be run across distributed datasets, with row level data would remain in situ, while the federated node would return aggregated results to the researcher.

A TRE at this level could also support seamless participation in a Federated Learning network, providing the network secure environment for data combined with out of the box capability to orchestrate and participate in a geographically distributed network across multiple tenants.

Four eyes airlock review with appropriate tooling and instrumentation within the workspace would allow for multi-modality data review against business rules and testing for disclosure risk. Secure AI can assist in the review of this data, while not participating in the decision directly.

Enhanced certifications (e.g. HiTRUST for US HIPAA compliance, ISO 27701 for GDPR) could support various deployment configurations which respect data sovereignty and different regulatory bodies. The organisation’s Information Governance team would be heavily involved given the onus on data sharing across institutions.

For Layer 6, we see a fully sustainable TRE working at scale, with industry, academic and clinical collaborations. Internal and external billing and re-charge features would underpin this sustainable funding model.

Operating at scale requires the capacity to serve researchers demand for data across modalities at the enterprise scale. This demands the operation of high numbers of workspaces in parallel. However, this significantly increases the number of simultaneous egress airlock requests. At layer 6, the integration of enhanced SDC techniques, provides appropriate tooling and instrumentation for researchers and reviewers by supporting dynamic rule-sets, and AI driven recommendation engines to assist in semi-automated airlock governance. This builds on previous layers four eyes approach, to quantitively determine the risks of re-identification of airlocked data. This includes not only data, but machine learning models developed inside the workspace.

The TRE would focus on innovation, with prototypes of new services and technologies in development. Access to internally hosted LLMs through a secure sandbox architecture is likely to be the main priority for a TRE operating at a higher layer. The organisation would need access to the compute resource needed for AI workloads and be actively working on the risks and challenges brought by AI (disclosure, reproducibility, governance etc.).

Hybrid support would provide the facility for platform owners to run inference on local GPU clusters, while ensuring data governance remains within the scope of the TRE environment.

Secure AI enabled TRE environments allow for the capability to develop ‘data aware’ applications and dynamic research reports and analysis. Where AI can assist on optimising analysis and reporting using data and associated metadata as context but governed within a secure environment.

In parallel with this, gaining the appropriate regulation to support these services, such as ISO 42001 for AI management, would be in progress.

This model is a reference guide – not a formal specification

Clearly the model needs to reflect that a TRE is much more than a technology stack. It is a set of services underpinned by technology, process, people, and culture, all driven by the needs of the organisation. An institution which views the TRE as an IT service to serve a largely internal user base is unlikely to move beyond layer 3 or 4, which may be perfectly acceptable in their context (and should score well as a SATRE compliant TRE).

In comparison, an organisation which views a TRE as a way of positioning itself as a leader in the field which attracts external collaboration, funding and industry engagement, will establish a roadmap to get to the higher layer services in 5 and 6. Getting to this level where the TRE is a strategic differentiator for the organisation will require a sustained and long term investment.

The above model should not be considered as a formal specification with absolute boundaries, it is not objectively scored, and a degree of interpretation is necessary. We can debate where individual features belong in this stack and whether they should move up or down, whether certain layers should change or indeed be combined in some way. We can also envisage TREs with well-established operational processes but lacking in technologies such as federation for example, compared to federated TREs operating with largely ad hoc processes. Which is the more mature?

In our next blog on this topic, we will consider the questions a researcher should ask of a TRE and how the capability maturity model helps put those answers into context.