Federation
Data is heavier than code. Move the code.
AURORA-FED · RFC-0001
AURORA is not a model — it's a substrate. Each module composes the same six layers so what works for glioma generalises to spina bifida, and what works in one hospital generalises to the next.
Federated registries of imaging, omics, surgical video, follow-up and patient-reported outcomes. Permissive defaults, strict provenance.
Five commitments the architecture is built around. Each one is the answer to a specific failure mode we've seen in hospital AI.
Data is heavier than code. Move the code.
Provenance is a load-bearing element, not an audit checkbox.
Equity belongs in the loss, not in a slide deck.
The clinician keeps the override. The system keeps the receipt.
If the patient isn't in the room, the room hasn't started yet.
Three reference deployments. The code, the weights and the signatures are identical across all three.
Single GPU box or Apple-silicon laptop. Useful for local research and one-off analyses. No federation. No PACS integration.
Containerised inside the hospital network. DICOM and FHIR connectors. Federation node optional. Default for pilot sites.
Compute travels to data across a permissioned mesh of hospital nodes. Differential-privacy budgets enforced per registry.
AURORA's six layers are a mental model. This is what a single case actually does as it moves through the substrate, and the environments the substrate is tested against. Every hop is observable, every output is signed, and nothing about the path is hidden from the hospital running it.
Eight hops, all observable, all signed. The numbers in brackets are the SLOs the substrate enforces on a reference workstation; modules inherit and tighten them.
What we test against on every release. "Supported" means a passing CI run on dedicated hardware; "best-effort" means a community run we accept but do not gate on.
AURORA is decision-support and research infrastructure, not a marketed medical device. Where it touches Protected Health Information it does so as a Business Associate, on the hospital's own estate. Here is exactly how that works — at the substrate, and module by module.
AURORA never asks for more PHI than a subsystem needs. Identifiers in DICOM headers and free text are stripped at ingest; models receive de-identified tensors, not charts. The covered entity remains the data steward — AURORA is a Business Associate, not a new owner of the record.
All three required safeguard families are implemented at the substrate: documented access policy and workforce roles (administrative), deployment inside the hospital's own physically-controlled estate (physical), and encryption, unique user identity and audit controls (technical).
The hash-chained audit log makes unauthorised access detectable and tamper-evident. AURORA surfaces the forensic trail; the covered entity's existing breach-notification workflow (within 60 days, per §164.404) is the binding legal mechanism. AURORA does not relocate that duty.
A signed BAA governs every pilot deployment, scoping permitted uses, mandating safeguards, and requiring return-or-destruction of any PHI on termination. Because AURORA runs on-prem and federates compute, in most deployments no PHI is ever disclosed to AURORA at all.
§164.308–312 require administrative, physical and technical safeguards. AURORA implements all three at the substrate, so every module inherits them.
Before any disease-specific handling, every module is bound by the same substrate-level controls.
Every module handles a different slice of the chart. This is the PHI each one touches and the specific controls applied to it.
AURORA is not a substitute for a covered entity's own compliance programme, and nothing here is legal advice. Specific modules destined for clinical use are validated and submitted to the relevant regulator by the deploying institution. The BAA, not this page, is the binding document.