What we are, what we aren't, and every rule that applies.

Our regulatory position, in one paragraph

Medical device law: where the line sits

Software becomes a medical device when it is intended for a medical purpose in respect of an individual — diagnosis, prevention, monitoring, prediction, prognosis or treatment. Intended purpose, not technical sophistication, is what triggers regulation. A registry query is not a device; a model that says “this patient's syrinx is likely to progress” is.

Every AURORA module therefore carries a written intended-purpose statement, and the release process blocks any module whose behaviour has drifted past it. Under EU MDR Rule 11 most clinical decision-support software lands in Class IIa or higher, which requires a notified body — not a self-declaration. We assume Class IIa as the planning baseline for any future decision-support module.

The EU AI Act

AI used as a medical device, or as a safety component of one, is high-risk under the AI Act by way of Annex I — which means AI Act obligations stack on top of MDR rather than replacing them. Any AURORA module that later becomes a device inherits both.

The obligations that matter most in practice are the ones you cannot retrofit: a risk management system that runs across the whole lifecycle, data governance with documented representativeness, technical documentation, automatic logging, human oversight designed into the interface, and declared accuracy and robustness. We are building against them now precisely because retrofitting them after a model exists does not work.

Quality management and safety engineering

These standards are the machinery behind a device claim. Without them a submission has nothing to point at, so they are being built in pilot rather than at the end.

AI-specific practice and reporting

Regulatory readiness is not the same as scientific credibility. These are the commitments that make a result checkable by someone who does not trust us.

• Good Machine Learning Practice — the ten FDA/MHRA/Health Canada principles, including clinical-study-level evaluation and monitoring of deployed performance.
• A model card for every released model: intended use, training and evaluation populations, subgroup performance, failure modes, and the conditions under which it should not be used.
• Reporting to TRIPOD+AI for prediction models, DECIDE-AI for early clinical evaluation, and CONSORT-AI where a trial is involved.
• ISO/IEC 42001 for AI management systems and ISO/IEC 23894 for AI risk, adopted as the internal frame for governance decisions.
• Every claim ships with the code, weights and evaluation script that produced it. If a result stops replicating, the paper says so rather than being quietly withdrawn.
• Equity is a release gate, not a report section: a model that fails subgroup performance thresholds does not ship, even when aggregate metrics look good.

Data protection and patient privacy

AURORA is federated because the alternative — pooling identifiable neurosurgical data into a central lake — creates a risk that no consent form can honestly cover. Institutions keep their data and remain its controller; models and queries travel, patients' records do not.

That architecture is what makes the compliance story credible rather than aspirational. There is no central dataset for us to lose, sell, or be compelled to hand over.

Security

A federated system is only as trustworthy as the node software institutions agree to run. Security work is therefore in the open, and reported vulnerabilities are published once fixed rather than buried.

Interoperability and data standards

Standards are what stop a federation from fragmenting into twelve incompatible dialects. AURORA speaks the formats hospitals already run, so joining does not require a data migration project.

• HL7 FHIR R4/R5 for clinical resources, with profiles published per module.
• DICOM natively for imaging, including structured reports and segmentation objects.
• SNOMED CT, LOINC, ICD-10/11 and RxNorm for coded terminology.
• OMOP CDM mapping for observational cohorts, so studies can be described once and run at every site.
• IHE integration profiles for exchange, and OAuth 2.0 / SMART on FHIR for authorisation.
• Open, versioned APIs — no undocumented endpoints, and no breaking changes without a deprecation window.

Clinical evaluation and evidence

No module reaches clinical use on retrospective performance alone. The staged path below is deliberately slow, and each gate can send a module back rather than forward.

• Stage 1 — retrospective validation on held-out data from sites that took no part in development.
• Stage 2 — silent prospective running alongside standard care, with no output shown to clinicians.
• Stage 3 — prospective evaluation with clinician oversight under ethics approval, reported to DECIDE-AI.
• Stage 4 — comparative evaluation where the question warrants it, reported to CONSORT-AI.
• Post-market — continuous performance monitoring, drift detection, and vigilance reporting; a module that degrades is withdrawn, not patched in place.
• Every stage transition is a public RFC with the evidence attached, so the decision can be argued with.

Ethics, governance and equity

Governance is the part of this that cannot be outsourced to a standard. AURORA's council holds two permanent patient-advocate seats with votes, not observer status, and equity review sits in the release path rather than alongside it.

• Institutional ethics or IRB approval is required at each site before any patient data is touched, including for retrospective work.
• Two patient-advocate seats on the council, with the same voting rights as clinical and technical members.
• Subgroup performance reporting by age, sex, ethnicity where lawfully recorded, and site — published even when unflattering.
• A documented process for withdrawing a model, including who can trigger it and how sites are notified.
• Open RFCs from day one: governance changes are proposed in public and argued in public.
• No secondary commercial use of federated data. Not as a policy we could revise — the architecture does not permit it.

Accessibility

Patients reading this material may be post-operative, medicated, visually affected by their condition, or in acute distress. Accessibility is a clinical requirement here, not a legal checkbox.

Who is responsible for what

Federation splits accountability, and vagueness about that split is where patients get hurt. This is the division we hold ourselves to.

What we are not claiming

Compliance pages usually work by implication — a wall of standards, and you infer certification. Here is the explicit negative list, so nothing is inferred:

• ✕ We do not hold CE marking, UKCA marking, or FDA clearance or approval for any module.
• ✕ We are not ISO 13485, ISO 27001, or SOC 2 certified. Those programmes are in progress or planned, and “in progress” means exactly that.
• ✕ No module is cleared for use in diagnosis, triage, or treatment selection for an individual patient.
• ✕ We do not claim that federated computation makes a model safe, fair, or clinically valid — it addresses data governance, nothing more.
• ✕ We do not claim regulatory coverage in any market not listed above.
• ✕ Nothing on this page has been reviewed by regulatory counsel, a notified body, or a competent authority.
• ✕ We do not claim our patient education has been through clinical sign-off; guides pending review are labelled as such.

Regulatory contact

If you are a regulator, a notified body, a hospital regulatory affairs team, or an ethics committee and something here is wrong or insufficient, write to us and we will correct it in the open. Corrections are logged as RFCs, not quietly edited.