Aridhia DRE workspaces and the EHDS Secure Processing Environment
This is the second blog in our series detailing how the Aridhia DRE can be used to ensure European Health Data Holders are ready to comply with the secondary use requirements of the European Health Data Space (EHDS) legislation when they come into force in March 2029.
The first blog looked at how FAIR Data Services can help Health Data Holders meet their duties under Article 60. Here we look at the Secure Processing Environment (SPE) where approved data is analysed, and how Aridhia DRE Workspaces line up with the requirements set out in Article 73 and the TEHDAS2 D7.4 technical specification published on 5 June 2026. An SPE is a controlled digital environment for analysis that ensures results can only leave if approved. From March 2029, a researcher granted a data permit will only be given access to data inside an approved SPE.
EHDS Article 73
EHDS Article 73 defines the SPE requirements:
- access is restricted to the people named in the data permit;
- the risk of unauthorised reading, copying, modification or removal of data is minimised through current technical and organisational measures;
- only a limited number of identifiable individuals can input, inspect, modify or delete the hosted data;
- each user can reach only the data covered by their permit, using an individual identity and a confidential access mode;
- identifiable logs of access and activity are retained so that every processing operation can be verified and audited, with access logs kept for at least one year;
- the security measures are monitored on an ongoing basis to address threats.
Article 73(2) adds that data holders upload data in the format named in the permit, users work on it inside the environment, and download requests are reviewed so that only non-personal data, including anonymised statistical results, can be exported. Article 73(3) requires regular audits, including by third parties, with corrective action where problems are found.
The Commission is due to adopt implementing acts detailing the full technical specification, including the tools available to users inside the SPE, by 26 March 2027 (Article 73(5)). Until then, the TEHDAS2 D7.4 technical specification for Health Data Access Bodies (HDABs) is the best available description of how these environments are expected to work in practice. D7.4 distils Article 73 into eighteen practical requirements and names four roles: the HDAB, the SPE Operator, the Data Holder and the Health Data User. The specification recognises that the SPE may be operated as a service by an organisation other than the HDAB itself, which is exactly the position Aridhia occupies today.
How a workspace maps to those requirements
An Aridhia Workspace is a secure, isolated analytical environment. Each one has its own storage, its own dedicated PostgreSQL database, membership and role-based access, and its own independent audit trail, and is isolated from the internet and from every other workspace. That structure already covers most of what Article 73 and D7.4 describe.
Controlled access and verified identity
A workspace can only be entered by people who have been invited to it by administrators. Membership is managed per workspace, and even a Tenant Administrator cannot enter one without an invitation. Every member signs in with their own unique credentials under multi-factor authentication and SSO is available, which matches the Article 73 requirement for individual identities and confidential access. The Reviewer User role gives external collaborators read only access and access can be time-bound using Workspace Restrictions.
Adding or removing members is limited to Administrator aligned roles and all activity is audited, so the set of people who can change who has access stays small and identifiable, as Article 73(1)(c) intends. D7.4 also asks that access rights for a person holding more than one permit be kept logically separate. Because each workspace has its own membership, a user working under two permits works in two separate workspaces, which is the separation the specification is after.
Isolation and protection of the data
Because a workspace has no route to the open internet, data cannot be copied out to an external address. The only outbound traffic permitted is to a fixed allowlist of package and infrastructure repositories (for example CRAN), so researchers can install the analytical packages they need while being prevented from exfiltrating data to a GitHub repository.
All inbound data uploads are scanned for malware, and the platform holds ISO 27001 and ISO 27701 certification, HITRUST, and Cyber Essentials Plus. For the user-facing connection, D7.4 calls for multi-factor authentication, automatic termination of idle sessions, and restrictions on clipboard and file transfer. Workspace access enforces multi-factor sign-in and times out inactive sessions, and the airlock below is how file transfer is controlled rather than left to the user.
The airlock and controlled outputs
Every movement of data into or out of a workspace passes through a fully audited airlock. Data arrives through the inbound airlock (the inbox), which is how a data holder would upload data in the format named in a permit. Anything leaving goes through the outbound airlock, where a reviewer approves or rejects the request and must give a reason for any rejection. In an EHDS deployment that reviewing role sits with the HDAB or its delegate, which is the control Article 73(2) describes. The workspace also supports ‘Four Eyes’ review through available apps and native support for SACRO libraries in both R and Python.
D7.4 separates export control into three cases: the export of anonymous results, the return of clinically significant findings to the original data holders, and the creation of new enriched research datasets. The airlock handles all three as reviewed outbound transfers, and a workspace-to-workspace transfer lets approved data move into another environment without ever touching the open internet.
A complete audit trail
Each workspace keeps its own independent audit trail, and all airlock activity is recorded in the workspace activity tab. Access and processing operations are therefore logged in a way that supports the verification and audit duty in Article 73(1)(e), including the requirement to keep access logs available for at least one year. D7.4 recommends going beyond that floor and retaining logs for five years to support auditing, and workspace logging can be retained accordingly.
The tools available to data users
Article 73(5) specifically covers the tools a user can reach inside the SPE, and D7.4 expects an SPE to provide pre-approved analytical software, commonly R and Python, with installation controlled by the operator rather than left to the user. A workspace comes with an R Development Environment, Jupyter Lab, R Web app development support, a terminal and Collabora Office for working with documents, alongside a low-code Data Table Analytics suite of more than twenty statistical modules that run on tables without any coding. Each module also produces the R code behind its output, so a result can be inspected and reproduced. All apps have access to Gitea for version control inside the workspace boundary.
Further containerised applications, such as a workspace specialised version of VS Code, can be added on demand by administrators if required, hosted on a dedicated container registry with access enabled on a per workspace basis.
Federation and interoperability
Beyond the stand-alone SPE that the regulation requires, D7.4 describes a federated computing ecosystem as the longer term target. Aridhia provides working capability on both fronts. For federated analysis, the open-source Aridhia Federated Node lets approved code be sent to where the data sits, with only aggregate results returned, so multi-site studies run without a dataset leaving its source institution. For federated learning, the DRE provides out of the box support for Flower, with Flower SuperNodes running inside secure workspaces so machine learning models can be trained across organisations while each data owner keeps full control of their data.
Independent and third-party audit
Article 73(3) asks for regular audits, including by external parties, and D7.4 asks for internal audits at least annually and external audits at least every three years. The certifications above (ISO 27001, ISO 27701, HITRUST and Cyber Essentials Plus) are all assessed by independent auditors on a recurring basis, and the published SATRE evaluation adds a further point of external scrutiny across information governance, computing technology, data management and supporting capabilities.
More detailed information on these certifications and more can be found on our Security & Compliance page.
Timely setup and clean termination
D7.4 also sets two requirements on SPE timings. It has to be operational and configured to the permit within two months of the HDAB receiving the data from the holder, and the environment has to be terminated after the permit expires, with the data deleted or rendered unrecoverable within six months, backups included. A workspace can be live within hours rather than weeks or months, so the two-month window is comfortable and leaves the HDAB room for the data preparation that precedes it. Decommissioning a workspace removes its storage, database and backups together, which is the clean termination the specification asks for, while still allowing for archival where reproducibility obligations apply.
The Commission will define the detailed specification of what is expected of an SPE by 26 March 2027 and we will keep the Aridhia Workspace aligned with those specifications as they are published. As it stands, the Aridhia DRE Workspaces provide everything that is required to be an EHDS Secure Processing Environment.
If you would like to know more about the Aridhia DRE please get in touch.