Saxsons Group

Knowledge Hub · RMS Server

Six area monitors and four paper logs — or one console.

A modern cyclotron / PET / theranostic facility runs ten to thirty radiation channels. Without central aggregation, every channel is its own paper trail; inspection day means assembling a stack of printouts and trying to align timestamps across them. With an RMS server, the radiation-safety dossier is already built — every event correlated, every alarm acknowledgement timestamped, every archive query a few clicks deep.

Why this matters

Six things RMS aggregation delivers, explained simply

Site-wide correlation

One screen, every channel — events become evidence

Without a central server, every area monitor produces its own local trace; correlating a vault-side neutron rise with a stack-monitor reading means walking two corridors and reading two charts. The RMS server puts every channel on one screen. When an event happens — a high-activity dispensing run, an HVAC anomaly, an unscheduled vault entry — the radiation-safety officer correlates the timeline directly instead of reconstructing it from disconnected logs.

Based on: IAEA Safety Reports Series 47 — Particle Accelerator Facilities.

Read source ↗

Modular architecture

Scales from one PET cluster to a multi-vault facility

A first-year PET centre may have three area monitors and one contamination frisker — the RMS server runs that cluster fine. Year three the centre adds a second cyclotron and a theranostic ward. Year five it federates with a sister site for centralised radiation-safety oversight. The same architecture scales across that growth — modular software, federated server design, RDU-02 cluster aggregation between field detectors and the central hub.

Based on: Manufacturer product page — architecture section.

Read source ↗

Archive trending

The AERB-inspection-ready dose-rate record

AERB inspection looks for documented dose-rate history across the inspection window — not just current readings. Without a central archive, the radiation-safety officer reactively compiles printouts when the inspector arrives. With the RMS archive, the data has been collecting continuously; the export is the inspection record. The narrative shifts from "what happened on the day" to "what happened across the year".

Based on: AERB Atomic Energy (Radiation Protection) Rules 2004; AERB inspection framework.

Read source ↗

Alarm management

Escalation logic + acknowledgement audit trail

Each channel carries per-channel alarm thresholds; alarms feed an escalation chain (operator → radiopharmacist → RSO → emergency response) with acknowledgement at each tier logged with timestamp and identity. The audit trail is what an AERB inspector or an internal-incident reviewer reads after a contamination event — it answers who knew, when, and what they did.

Based on: IAEA Safety Standards Series GSR Part 3 — Radiation Protection and Safety of Radiation Sources.

Read source ↗

Federated multi-site design

One radiation-safety officer, multiple PET centres

A hospital network with multiple PET centres or theranostic wards can run one RMS architecture across sites — site-local servers federate to a central administration console. The network-level radiation-safety officer monitors every site from one console; site-specific tracking happens on the local servers. Useful for the multi-hospital theranostic networks emerging across Indian metros.

Based on: Saxsons multi-site architecture framing; consistent with manufacturer modular-architecture documentation.

Read source ↗

Heterogeneous monitor compatibility

Same server, every monitor type the site deploys

A theranostic-and-PET centre deploys area gamma (AGM-03), neutron (MDN-01), hand-foot contamination (HF-4), stack / effluent (PET-01), environmental, air and liquid monitors. The RMS server connects to the full fleet — directly via LAN / RS-485, or via RDU-02 cluster aggregators. The site does not need separate software stacks per monitor family.

Based on: Manufacturer product page — connectivity section.

Read source ↗