The CHORUS ecosystem
CHORUS is not one platform with one set of users. It is shared infrastructure that several research fields and institutions use at once, each on its own terms.
An institution runs an instance. Within it, communities group people around a research field or an organization - each with its own data, tools and rules, but the same architecture and the same security underneath. One account can belong to several.
Where a community sits
CHORUS organizes work through a handful of building blocks - an instance run by an institution, the organizations registered on it, the communities that group users, and the workspaces where projects actually happen. How CHORUS works defines each one.
A community is the level in between the infrastructure and the project. It is what makes CHORUS usable by a field rather than by an institution alone.
What a community gives a research field
Intracerebral EEG research does not need the same tools, the same data standards, or the same oversight as, say, a hospital's internal analytics. Without communities, either everyone would get the same generic environment, or every field would need its own platform.
So a community brings together:
- Its own data, curated to whatever standard the field works in.
- Its own tools - a catalogue that matches the science, not a lowest common denominator.
- Its own governance - who may join, under what agreements, and who decides.
- Its own documentation and support, in the field's own vocabulary.
CHORUS.HIP is the clearest example: iEEG-specific tooling, the BIDS-iEEG standard, accreditation through EBRAINS, and a governance model built around contributing hospitals.
What every community shares
What communities do not each reinvent is the part that has to be right every time:
- The architecture - isolated workspaces, browser-based sessions, no data on your own machine.
- The security model and the frameworks it is built against.
- The governed lifecycle - controlled import, role-based access, reviewed export, audit.
This is the whole argument for a shared platform. A new community inherits a security posture that has already been built and assessed, rather than assembling one of its own.
Belonging to more than one
A single authenticated user can take part in several communities without separate accounts or separate platforms. A researcher might belong to their institution's community and to a domain community at the same time, using the resources of each according to the permissions they hold there.
The permissions do not travel. Being trusted in one community grants nothing in another - which is what makes belonging to several safe.
Federation
Instances can join a federation, connecting communities across deployments while each institution keeps its own governance intact.
This matters because the data that research needs is often held in several institutions and frequently cannot be moved at all. Federation lets the analysis travel instead - so multi-institution work happens without centralizing sensitive data anywhere.
What's next
Communities lists what is running on CHORUS today.