Quickstart
A node is a container stack: an API, a worker pool, a local Postgres, an object store for derived artefacts, and a DICOM adapter that talks to your PACS. It never opens an inbound path to patient data from outside your network.
- A Linux host or Kubernetes namespace inside your network — 8 vCPU / 32 GB RAM for a registry-only node; a CUDA-capable GPU if you enable imaging models.
- Container runtime and an internal registry mirror, if your site blocks external image pulls.
- Read access to the PACS or VNA you intend to index, plus a DICOM AE title for the adapter.
- A service account for your EHR's FHIR endpoint, scoped to the resources the module declares.
- Ethics or IRB approval covering the intended use, before any patient data is indexed.
- A pilot agreement and node credentials issued by the AURORA council.
Fetch and verify the node bundle
Every release is signed. Verify before you run it — a node that cannot prove its provenance should not be trusted with your data.
aurora node fetch --version 0.1.0-pilot
aurora node verify --signature aurora-0.1.0-pilot.sig
# expect: signature OK · issuer: AURORA Council · sha256 matchConfigure the node
Configuration is declarative and reviewable. Nothing is enabled by default, and the config is the artefact your governance team signs off.
# aurora.node.yaml
site:
id: karolinska-neuro
region: eu-north
modules:
- AURORA-CHIARI
- AURORA-HYDRO
sources:
dicom:
ae_title: AURORA_SCP
peer: pacs.internal:11112
fhir:
base_url: https://ehr.internal/fhir/R4
scopes: [Patient.read, Condition.read, ImagingStudy.read]
federation:
advertise_cohorts: true
egress: aggregates_onlyBring the stack up
The node runs entirely inside your perimeter. The only outbound connection is to the federation coordinator, and it carries aggregates — never records.
aurora node up --config aurora.node.yaml
aurora node status
# api ready
# worker ready (2 replicas)
# dicom listening on 11112
# federation connected · egress: aggregates_onlyIndex, then validate locally
Index a small cohort first and check module performance in your own population before anything is relied upon. Local validation is not optional — see the regulatory page for why.
aurora index run --module AURORA-CHIARI --limit 250
aurora eval local --module AURORA-CHIARI --report out/eval.html
# writes a signed evaluation report you can hand to your review boardFederation & deployment
Joining a federation means agreeing to a protocol, not shipping a dataset. Your node advertises which cohorts it can answer questions about; a study runs where the data already lives, and only aggregates or model updates return.
- Egress is allowlisted and defaults to aggregates only; there is no mode that ships records to us.
- The federation coordinator never initiates inbound connections to your node.
- Every job carries a signed manifest, so you can audit exactly what ran, on which cohort, under which module version.
- A site can withdraw at any time; withdrawal removes your node's contribution from subsequent training rounds.
- Air-gapped operation is supported for indexing and local evaluation, with federation disabled.
Module reference
Nine disease modules, each a full vertical over the same substrate. Enable only the ones your programme carries — a module you don't enable never runs and never touches your data.
Tech stack
Six layers, deliberately boring where boring is safer. Every layer is versioned and signed, so a result can be traced to the exact code and weights that produced it.
FAQ
Does any patient data reach AURORA?
No. The architecture has no endpoint that accepts records. Aggregates, model updates and evaluation metrics leave your node only when your config allows it, and identifiers never do.
Can we use this clinically?
Not today. AURORA is research software and holds no device clearance in any market. Any clinical use would require the module in question to complete a conformity route first — the regulatory page sets out exactly where each framework stands.
What if our PACS or EHR is unusual?
The adapters speak standard DICOM and FHIR, and sites with older or bespoke systems have been onboarded with a translation shim. That work is done with your team during pilot onboarding rather than left to you.
Do we have to enable every module?
No. Enable only what your programme carries. A module that is not enabled is not deployed and cannot touch your data.
What happens if we want to leave?
You withdraw the node. Your contribution stops being included in subsequent training rounds, and because we never held your data there is nothing for us to delete on your behalf.
Is it really MIT licensed?
At public alpha, yes — including the module code and the evaluation harness. During the private pilot, node images are issued under a pilot agreement while the security review completes.
Who do we call when it breaks?
Pilot sites have a named engineer and a private channel. Anything that isn't site-specific gets answered in the public issue tracker so the next site doesn't hit it.