Companion notes for the Epicurrents poster at the International Congress of Clinical Neurophysiology. A poster has room for a claim but not for its boundaries; this page states both.

In brief

Epicurrents is a self-hosted platform for viewing, annotating and managing clinical neurophysiological recordings. Each institution runs its own instance and keeps its own data; there is no central service anyone manages or logs into. One instance can grant another scoped, expiring, revocable read access to specific material, and the receiving side’s users never hold credentials on the granting side.

The claim for the federated data sharing mechanism is controlled, attributable, revocable disclosure from the source. It does not imply anonymity, enforced non-retention, or regulatory compliance as a property of the software. The sections below explain why.

How federated access works

Each instance holds an Ed25519 key pair and publishes the public half at a well-known URL. Every inter-instance request carries its own short-lived signed token — sixty seconds by default, one per request, with a nonce cache so that a token cannot be presented twice. Tokens can be further scoped to specific method, path (including the resource), and request header properties.

Trust between two instances is explicit and manual in both directions. Registering a peer fetches its key and stores it untrusted; an administrator promotes it only after verifying the key fingerprint, ideally through a channel other than the network — a phone call, a meeting. Registration is not trust.

A grant is a per-object access right whose target is a named peer institution, optionally narrowed to a single named user on that peer, optionally carrying an expiry. There is deliberately no way to grant access to a group on the remote instance: that would delegate the access decision to an administrator outside the data owner’s trust boundary. The invariant is that only the owner of the data decides who sees it.

Traffic is server to server. A user talks only to their own institution’s instance, which authenticates to the peer on their behalf and relays the result. End users join no network and hold no federation credentials; only the institutions participate.

What actually leaves the institution

The source recording does not leave. What leaves is a de-identified projection computed per request.

That distinction is architectural rather than rhetorical. Sanitisation runs on the serving side, before any byte leaves the owning instance, as a pipeline over the recording structure: header anonymisation and annotation-text stripping by default, with channel dropping and downsampling available. Because it is applied per request, the de-identified view exists in no file, on either side. There is no sanitised copy on our disk to leak, because it is regenerated every time it is asked for. The platform’s zero-copy delivery path — where the web server hands a file directly to the operating system to send — is hard-interlocked against ever being used for a sanitised request, precisely because those bytes exist nowhere on disk to hand over.

Sanitisation is a per-grant switch, so the owner decides the applied measures per recipient rather than once per dataset.

What this does not do. Once a recipient holds the projection, we cannot prevent them retaining or copying it. Nothing in this design removes the element of trust. What it changes is that the copy is a copy of the shared view rather than of the source record; that every access is attributable to a named institution and a named remote user at both ends; that a bulk pull is bounded by a per-peer byte budget and visible in the log while it is happening; and that access to anything not yet taken ends the moment it is revoked.

We describe that as bounded, instrumented trust — not as enforced non-retention, and not as “no data ever leaves the institution”, which is accurate only for architectures where individual-level data are never transmitted at all.

De-identification, and why we do not say anonymous

De-identification is applied twice: once when a recording is ingested, and again on the wire. Identification fields in the file header are blanked. Channel labels are normalised to a canonical set, failing closed to a neutral placeholder when a label cannot be resolved, so an unrecognised site-specific naming convention is removed rather than passed through. Transducer and prefiltering strings are rewritten, and channels are permuted into a canonical order so that the acquisition template’s own ordering does not survive as a fingerprint. Original values can be retained for the recording’s author and are visible to nobody else.

This is meaningful de-identification. It is not anonymisation, and we do not present it as such. Depending on the interpretation, an EEG recording remains personal data under GDPR, and we treat it that way throughout — which is the reason erasure exists in the platform at all. If the data were anonymous, there would be nothing to erase.

Revocation: what it reaches

Revocation is prospective and immediate. Every read — including each read through the optional mounted-filesystem interface, where remote recordings appear to analysis software as ordinary local files — re-runs the access decision at the owning instance. Withdrawing a grant therefore stops further disclosure at once, including through a session already in progress.

It cannot reach what has already been disclosed (or, “what has been seen cannot be unseen”). Data already transferred, and data held in operating-system or application caches on the receiving side, are outside its reach by construction. Revocation is forward-acting, and we state it that way rather than as a general power to retract.

The audit trail is tamper-evident, not tamper-proof

Every write to the data model produces a hash-chained change-log entry: a keyed hash over the change, carrying a pointer to the previous entry in its stream, so that both modification and reordering become detectable. Verifying a chain is a first-class operation rather than an offline forensic exercise. Separately, every inbound federated request that reaches an access decision is recorded — which peer, which remote user, which object, what outcome — in an append-only log.

Two boundaries worth stating. The mechanism detects alteration; it does not prevent it. And it observes changes that went through the application: a write made directly against the database or the storage volume, by someone who has already obtained that level of access, would leave the chain internally valid while no longer describing reality. Off-host publication of chain heads, so that a party who cannot alter our records holds a record of what they said, is currently being tested and is among the next pieces of work in this area.

Where the trust boundary sits

The institution holding the data authenticates the peer institution cryptographically, and relies on that peer’s assertion about which of its users is acting. It does not independently authenticate that user.

This matches where the agreement between two institutions actually sits, and we would defend it as the right primitive for institutional sharing. It is nonetheless a real trust assumption, and it has a consequence worth naming: a compromise of the peer instance, or a sufficiently privileged administrator at that site, could issue requests under the identity of an otherwise authorised user. Extending the protocol so that the data owner validates an identity assertion issued by the peer institution’s own identity provider — rather than by the peer’s Epicurrents instance — is the direction we are taking. In practice that means an OIDC assertion from the partner’s own institutional login, checked by the receiving instance rather than taken on trust. The platform already has OIDC validation for its own login path, so this extends existing code rather than introducing a new subsystem.

Data subject rights, stated precisely

The platform implements specific technical measures. Article 15 subject access export is implemented, with a deployment-time check that fails a deployment when a model linking to a person has not been classified for it. Article 17 erasure removes registered personal data from the permanent audit trail, then tombstones and re-seals each affected entry so that the chain still verifies afterwards: erasure does not have to break tamper-evidence, and tamper-evidence does not get to override erasure.

Implementing those measures is not the same as the processing operation being compliant. Compliance depends on the legal basis, the controller and processor roles, purpose limitation, data minimisation, retention, access governance, the security measures around the deployment, and the institution’s own risk assessment. Those are properties of a deployment and its operator, not of software. We describe what is implemented and leave the assessment where it belongs.

The same reasoning is visible in the sharing design. A sealed dataset snapshot — a create-only, canonically ordered, hashed record of exactly which recordings were members at a given moment — makes “this analysis used this cohort” a checkable claim. It pins identities rather than content, so when a subject exercises erasure the snapshot survives as verifiable but no longer satisfiable. It continues to prove what the cohort was without holding anything erasure removed. Erasure wins by construction, and reproducibility degrades visibly instead of silently: the sealed list still names every original member, so what erasure removed shows up as a mismatch the moment anyone checks — rather than the cohort quietly shrinking and the next person to run the analysis getting different numbers with no way to find out why.

On using this to train models

We are cautious here, and the caution is architectural rather than about throughput.

Streaming recordings from their source institution over a wide-area network gives analysis software a transparent view of remote data. But training reads small windows, repeatedly and in random order, which is close to the worst case for that access pattern — and the standard remedies, prefetching and caching, progressively erode the very property that motivated streaming from the source. Cache enough and remote access becomes indistinguishable from holding a local copy, at which point the custody argument has quietly been given up.

This platform’s contribution to this problem is data custody, cohort definition, provenance and evaluation — not serving as the transport for a training loop. Federated learning has a standing gap in exactly the place a sealed snapshot is strong: an aggregation process observes model updates and has no independent way to establish which cohort produced them.

Relationship to larger infrastructures

Epicurrents is not an alternative to EBRAINS or comparable infrastructures, and we do not position it as one. Where federated sharing develops further here, alignment to existing interfaces and vocabularies — BIDS and BIDS-EEG, openMINDS, GA4GH interfaces, established federated identity and delegated authorisation — is the right course rather than a bespoke protocol.

On FAIR: findability and interoperability apply to metadata, provenance and access conditions. They do not imply open access to patient-level recordings, and the two are compatible. Descriptive metadata and the conditions under which access may be requested can be discoverable while the clinical data behind them stay restricted.

Current status and known limitations

The platform is version 0.1. It is in real use for teaching and for research (annotation) work; the federation mechanism described here was built for that use and is deployed at that scale. It is not a mature multi-institutional data-sharing infrastructure and we do not present it as one.

• No independent security assessment has been performed. An institutional security assessment is currently underway. However, we regard an external review and penetration test as necessary before wider clinical deployment or stronger security claims.
• Recipient-side retention cannot be prevented, as described above.
• Revocation is prospective only, and does not reach external caches on the receiving side.
• The audit trail observes changes mediated by the application, not direct access to the database or the storage volume.
• The end user is authenticated by their own institution, not by the institution holding the data.
• The authentication protocol is being extended to bind each token to the specific operation it authorises, and to require its replay-protection field unconditionally.
• Permissions are currently coarse. Reading metadata, retrieving a byte range and retrieving a complete recording are one permission today; they have different governance implications and should be distinguishable.
• Attached media files — documents and video today, images later — cross to a peer without an equivalent de-identification concept. Signal data has one; media does not.
• The optional evidence host is append-only today but not yet multi-tenant. Backup repositories separate cleanly per instance, each encrypted under its own key. Shipped log streams do not: one shared credential and host labels asserted by the sender mean two institutions cannot yet be isolated from one another’s records on a shared host. That is not only a technical gap. The shipped logs carry IP addresses and actor identifiers in the clear, where the backups are encrypted per repository under keys the host never holds — so an institution hosting another’s evidence becomes a processor of their personal data, and needs an agreement saying so.
• Off-host anchoring of the audit chain is designed and not yet running. Within an instance the chain is tamper-evident; publishing each chain head somewhere the instance’s own administrator cannot reach is what would extend that guarantee past them, and is among the next pieces of work.

An optional WireGuard mesh can carry inter-instance traffic, so that an instance need not be published to the public internet at all. It is defence in depth and never the authority: a mesh node identity is a software secret, so a cloned node still has to pass per-peer cryptographic authentication before it receives anything. The network layer hardens the wire; it does not replace application-level trust, and it is strictly optional.

Source and contact

The platform is open source: github.com/epicurrents/platform — roughly 46,000 lines of application code against about 2,900 automated tests. Questions, corrections and collaboration enquiries are welcome, particularly from anyone working on federated identity, secure aggregation, or data governance for clinical neurophysiology.

The poster states its claims narrowly and deliberately. This page is the reasoning underneath them, together with the boundaries we would want anyone to know before relying on any of it.

Attachments