Bringing Research Code Into Clinical R&V Workflows in Australia

For Australian medical physicists, the gap between a clever prototype and a clinically usable record-and-verify system feels enormous. A script that produces beautiful dose distributions on a Linux workstation rarely survives contact with a busy radiotherapy department in Sydney, Brisbane, or Perth. The lessons captured at the COMP 2014 Banff meeting remain directly relevant a decade on.

Australia's radiotherapy sector is small enough that physicists know each other across institutions, yet vast enough that a site in Perth may run completely different vendor stacks than one in Melbourne. Throw in ARPANSA safety guides, state-based credentialing, and the ACPSEM certification pathway, and the path is clear: research-grade software must be rebuilt, not merely relocated, before it can touch a patient.

This piece walks through the practical realities of that rebuild — documentation, testing culture, and the human factors that determine whether a research tool earns a place on a treatment console.

Why Research Software Rarely Survives Handover

Research code is usually written by one physicist juggling a PhD and a clinical load. The codebase lives on a personal drive, comments are sparse, and only the author understands the input flags. When that physicist finishes a fellowship overseas, the code often disappears with them.

Clinical R&V systems demand reproducible behaviour across hundreds of sessions per linac, with every script auditable, version-controlled, and recoverable. Australian centres running mixed-vendor fleets — a Varian TrueBeam beside an Elekta Versa HD — feel this sharply, because the same workflow may need reimplementing twice to suit each API. The cultural shift matters as much as the technical one: a researcher can iterate freely and publish the negative result, while a clinical physicist must defend every change to a multidisciplinary team and prove patient safety has not been compromised.

Documentation, Verification, and the Quality System

Documentation becomes the single most important deliverable once research software moves toward clinical use. Specifications, test plans, traceability matrices, and risk assessments must exist in a form an external auditor — or a registrar joining on their first arvo — can follow without oral history lessons.

Verification shifts from "the output looks right on a few cases" to a structured suite of end-to-end tests covering normal operation, boundary cases, and recovery. Many departments now run overnight continuous integration suites that replay recorded clinical scenarios against a frozen reference set, comparing output line by line. Risk assessment aligned with the Therapeutic Goods Administration's software-as-a-medical-device expectations must be embedded from day one, because retrofitting a risk file after the code is written is painful, expensive, and produces artefacts nobody fully trusts.

State-Based Regulation and Local Credentialing

Australian radiotherapy does not operate under a single national software framework. Each state health department issues its own licence conditions, and each site must satisfy both ARPANSA guides and local credentialing before a new tool is loaded onto a treatment console. A script signed off in a New South Wales public hospital may still require fresh documentation before deployment in South Australia.

The quiet upside of this variation is that it forces developers to write portable, well-encapsulated code. Anything tightly coupled to one vendor's API fails the moment it crosses a border. Teams that build with portability in mind — using containerised environments and explicit configuration files — find their tools travel more easily between Sydney, Adelaide, and the occasional outreach clinic in regional Western Australia.

ACPSEM's TEAP training program reinforces the habit by sending registrars through multiple sites during training, so a registrar who has worked at two or three departments arrives at consultancy already accustomed to the documentation discipline clinical software demands.

Bridging Scripting Languages With Vendor Platforms

Most medical physics research relies on Python, MATLAB, or C++. Clinical R&V platforms, however, expect scripts in their own proprietary languages — ESAPI for Varian, MOSAIQ Scripting for Elekta, the scripting hooks in RayStation. The translation layer is where many projects quietly lose momentum.

A pragmatic approach used across several Australian centres is to keep heavy computation in the original research language, exposed through a small, well-defined service the R&V platform calls. The clinical shell handles workflow, user interface, and safety interlocks, while the research engine handles the novel physics. This separation makes it easy to update the research component without re-certifying the entire workflow.

Versioning is critical at this interface. The R&V platform may upgrade on its own vendor schedule, breaking the contract the research component was written against. Pinning supported versions, writing contract tests, and keeping a sandbox identical to production pay for themselves quickly in any multi-vendor Australian department.

Workflow Integration at Busy Treatment Centres

Even perfectly engineered software fails if it disrupts the rhythm of a busy department. Australian radiotherapy centres typically treat sixty to eighty patients per linac per day, with physicists juggling planning, second checks, and on-call cover. Any new R&V tool must slot into that pace without adding keystrokes or waiting time.

Sitting with radiation therapists during a morning list and timing each step is often more valuable than any code review. A tool that adds two minutes per patient represents several hours of unplanned treatment time across a full day and a real risk of overruns. Integration also covers the unglamorous tasks: configuring DICOM exporters, mapping treatment fields to R&V field names, and ensuring audit logs capture every action the new tool performs. None of it is publishable, but every bit determines whether the tool survives its first audit.

Training and Long-Term Stewardship

Software deployed clinically needs a custodian who is paid, trained, and available. Australian departments that have successfully transitioned research tools into routine R&V use assign explicit ownership to a named physicist, with documented handover when that person goes on long service leave or moves interstate.

Training the broader team — registrars, radiation therapists, dosimetrists — is the other half of stewardship. A tool only its author understands will be turned off the moment that author goes on leave. Walk-through sessions, written quick-reference guides, and short video walkthroughs stored on the hospital intranet help embed the tool into collective muscle memory.

The planning and contouring tools captured at the 2014 meeting illustrate exactly this lifecycle: a research technique, carefully packaged and handed over, eventually running quietly on dozens of machines.

Recommendations for Teams Making the Move

• Build the documentation template before writing the first clinical line of code, and treat it as a living artefact.
• Insist on automated regression tests replayed against frozen clinical scenarios, not just synthetic benchmarks.
• Decouple the research engine from the vendor R&V shell through a narrow, versioned interface.
• Map every state and territory credentialing requirement early, and reuse a single risk file across sites where regulators permit it.
• Assign a named custodian with allocated time, and require written handover whenever that custodian changes role.
• Budget at least as much effort for end-user training and workflow observation as for the original research implementation.
• Plan for the vendor upgrade cycle from day one, and keep a sandbox matching production exactly.

If you are weighing whether to bring a research tool into clinical service, start by talking to colleagues who have already done it. The materials archived from the 2014 Banff meeting still reflect the practical questions that come up whenever a physicist tries to move a clever idea from a workstation to a treatment couch. Share your own lessons, mentor the next generation of Australian medical physicists, and help the community spend less time reinventing the same documentation scaffolds. Reach out to the organising committee, swap war stories over a flat white, and keep the conversation going.