Implementation reports
Tom Giles, Jonathan Couldridge, Sam Cox, Daniel Lea, Vasiliki Panagi, Simon Thompson, Philip Quinlan (2024):
TRE-FX Technical Documentation - Primary Implementation.
Zenodo
https://doi.org/10.5281/zenodo.10376658
Blaise Thomson, Naaman Tammuz, Thomas Giles, Philip Quinlan, Carole Goble (2024):
TRE-FX Technical Documentation - Bitfount Implementation.
Zenodo
https://doi.org/10.5281/zenodo.10376572
Stuart Wheater, Thomas Giles, Philip Quinlan, Carole Goble (2024):
TRE-FX Technical Documentation - DataSHIELD Implementation.
Zenodo
https://doi.org/10.5281/zenodo.10375984
Videoes
Planned TRE-FX architecture
The below is the originally planned architecture, for the realized implementations, see reports above.
- User submit queries as job packets in a Five Safes RO-Crate via an API on a publicly available Submission portal. Queries are then presented on a query queue.
- The job packets are pulled down into a demilitarised polling zone on a TRE via a secure outbound only API connection. Connection between TREs and the Submission Layer are managed by HUTCH.
- Job packets are authenticated and then presented on an internal queue.
- A second outbound only API pulls the job packets into the main Controlled zone of the TRE.
- The job packet is passed to WfExS which executes published approved workflows on data, generate results and adds them to the job packet, including workflow information and providence.
- Subject to appropriate disclose control the job packet is returned to the TRE Polling zone and stored.
- Further disclosure checks are applied, and the job packet is released back to the submission layer where it is held on a results queue to be collected by the user.
- Subject to deidentification, the job packet is also published on the HDR data use register.
Work packages
The TRE-FX project ran for 9 months starting 2023-02-01 until 2023-09-31.
- WP1: PPIE
- WP2: Transparency
- WP3: Microservice Development
- WP4: TRE integration
- WP5: Federated Analytics Testing