How CHORUS works
How CHORUS is put together - the structure that organizes users, data, and tools, how work happens inside secure environments, and how it stays governed.
Each project gets a workspace. Inside it you open a session in your browser and launch the apps you need. Workspaces are sealed off from each other, what enters and leaves is approved by someone accountable for that decision, and every consequential action is logged.
The building blocks
- Instance - one institution's deployment of CHORUS, running on its own infrastructure.
- Organization - an institution registered on that instance: a hospital, a university, a research group.
- Community - a scientific grouping of users on the shared platform, with its own data, tools, and governance (for example CHORUS.HIP).
- Workspace - the secure environment for one project. It holds the data, the people, the tools, and the results.
- Session - your live working environment inside a workspace, opened in the browser.
- Application - a tool you launch inside a session: Jupyter, RStudio, VS Code, a specialised viewer.
- Service - something the workspace runs continuously, independently of anyone's session - a database, for example.
A project is not a separate thing in the platform: a project has a workspace, and the workspace is where it lives.
How work happens
You sign in, pick one of your workspaces, and open a session in it. The session starts empty; you then launch the applications the project needs from the catalogue. Each one appears as a window in your browser, streamed live from inside the workspace.
Because the application and the data both run inside the workspace, nothing is copied to your computer while you work. Several people on the same project can each open their own session in the same workspace and work in parallel.
Applications and services - what is the difference?
An application is something you open inside your session, and it belongs to that session. You can start it, stop it, and run several at once - two notebooks side by side on the same data, for example. Multiple versions of the same application can be available, so you can choose the one your analysis needs.
A service belongs to the workspace, not to any session. A workspace administrator deploys it, and it keeps running whether or not anyone is signed in - which is what you want for something like a database that your analyses connect to. Anyone with access to the workspace can reach it from their own session.
How workspaces stay separate
Workspaces do not share anything. They are isolated at the network, at the level of storage, and at the level of the running processes themselves - and by default a workspace has no outbound internet access at all.
That isolation, the three network modes, and what it means to work in a shared workspace are covered in What a workspace is.
The controlled data lifecycle
Data entering CHORUS is reviewed and authorised rather than simply uploaded. Once inside, its use is confined to the workspace of the project it belongs to, and to the people holding a role in that project. Results leave through a controlled export that requires an explicit human approval - nothing sensitive is released automatically.
Every consequential action along the way is recorded: administrative changes, data movement, and the opening and closing of sessions.
Who can do what
Access in CHORUS is role-based and deliberately narrow. A role is a named bundle of permissions, and every role applies at one of four levels: the whole system, the platform, a single workspace, or a single session.
That layering is what lets you be an ordinary user of the platform while holding wider privileges inside the one project you help run - without those privileges following you anywhere else. Nobody holds more capability than their project requires.
Permissions cover the things that actually matter: administering a workspace, moving files in or out, managing services, approving imports and exports, and reading the audit log. Roles & permissions lists what each role can do.
The Five Safes
Protection is layered rather than resting on any single control: safe people (authorised, verified users), safe projects (approved purposes), safe settings (isolated environments), safe data (de-identified and protected), and safe outputs (reviewed before release).
Even if one layer were bypassed, the others still apply. See The Five Safes for what each one means in practice.
Standards & compliance
Everything above is built to line up with the frameworks institutions are assessed against, and with GDPR-compatible practice, rather than with a vocabulary of its own. What is CHORUS lists the frameworks; Standards covers where CHORUS stands against each one.
Working across institutions
Isolation solves one problem and creates another: research often needs data that sits in more than one institution, and that data frequently cannot be moved at all.
Two things address this. Within one CHORUS instance, a collaborative workspace lets people from different institutions work on the same project without the data leaving the environment that governs it. Where data cannot move even that far, CHORUS can support federated approaches in which only model updates or derived outputs are exchanged, so the analysis travels instead of the data.