Designing responsibility for radiotherapy

Designing responsibility for radiotherapy

Designing responsibility for radiotherapy

How I defined the ownership model and built two clinical interfaces for RadPass, a safety system for radiation-controlled environments.

How I defined the ownership model and built two clinical interfaces for RadPass, a safety system for radiation-controlled environments.

Role
Role

Founding Product Designer (0โ†’1) ยท Co-founder

Products
Products

Admin web app + Clinical tablet

marketing site
marketing site

01 โ€” Context

In radiotherapy, the wrong person operating a machine can cause irreversible harm.

In radiotherapy, the wrong person operating a machine can cause irreversible harm.

In radiotherapy, the wrong person operating a machine can cause irreversible harm.

Linacs are high-radiation devices operated across rotating shifts by radiographers, physicists, and engineers. When RadPass was founded, there was no system that knew who was responsible for a machine at any given moment. Responsibility was verbal. Machine state was a whiteboard. Audit trails didn't exist.

Both products share tokens, but diverge at the architecture level. I separated foundation from architecture:

14

centres audited

centres audited

70โ€“93%

compliance range

compliance range

95%+

regulatory target

regulatory target

Scores are generated monthly. An auditor cross-references calendar events against manual notes, looking for evidence that responsibility changed hands.

That wasn't a design gap. It was a clinical risk.

Environment

Radiotherapy. Multi-role. Radiation-controlled. High-stakes.

Problem

Compliance failing across all 14 centres. No record of who held responsibility or when it changed.

My role

Sole designer. Defined the model and designed both interfaces.

Environment

Radiotherapy. Multi-role. Radiation-controlled. High-stakes.

Problem

Compliance failing across all 14 centres. No record of who held responsibility or when it changed.

My role

Sole designer. Defined the model and designed both interfaces.

On-site โ€” controlled area signage and early responsibility mapping on the wall

Both products share tokens, but diverge at the architecture level. I separated foundation from architecture:

02 โ€” System design

No formal model existed.
Everything was done manually.

No formal model existed.
Everything was done manually.

No formal model existed.
Everything was done manually.

Through interviews with clinical staff, I mapped how responsibility moved in practice โ€” finding that each role implies a specific default machine state when taking ownership.

Both products share tokens, but diverge at the architecture level. I separated foundation from architecture:

System map โ€” role, responsibility, and machine state modelled as one connected system

Both products share tokens, but diverge at the architecture level. I separated foundation from architecture:

03 โ€” The hard problem

I challenged the original model.

I challenged the original model.

I challenged the original model.

My co-founder's original model was built around handovers. Designing the actual flow revealed a structural failure, so I proposed a different model entirely.

System map โ€” role, responsibility, and machine state modelled as one connected system

The handover model

The handover model

Creates a state no one owns.

Creates a state no one owns.

The claim model

The claim model

Ownership is always explicit.

Ownership is always explicit.

Responsibility is no longer transferred.
It is claimed in real time.

The founder's model made sense conceptually โ€” one person hands over to another. But when I started designing the actual flow in software, the problem became clear: what happens when the receiving person doesn't accept? You get a blocked state with no owner. That's when I went back to the physical board and noticed people were already claiming responsibility themselves on arrival. The software model needed to match that behaviour โ€” not the conceptual one.

04 โ€” Iterations

Testing the model.

Testing the model.

Testing the model.

Before landing on the final flow, I tested three ownership models โ€” each revealing a different failure mode until the claim-based approach resolved them all.

Shift

This eliminated handover as a failure point in a safety-critical system.

Final

Clear ownership + simplified flow while maintaining safety.

05 โ€” Output

One system. Two interfaces.

One system. Two interfaces.

One system. Two interfaces.

The same underlying model surfaces differently depending on context and user need.

TAblet
Real-time operation

Used inside the controlled area. Fast, minimal, high-pressure. Designed for gloved hands and zero ambiguity.

Used inside the controlled area. Fast, minimal, high-pressure. Designed for gloved hands and zero ambiguity.

- Claim area responsibility
- Update machine state
- PIN-verified actions

WebApp - Admin
System governance

Used by physics leads. Full visibility across machines, locations, and shifts. Audit-ready by design.

Used by physics leads. Full visibility across machines, locations, and shifts. Audit-ready by design.

- Live monitor across all linacs
- Role and permissions config
- State timeline + audit log

06 โ€” Results

What success looks like.

What success looks like.

What success looks like.

No live metrics yet โ€” the system is in its first hospital integration. Success was defined before a single screen was built. Target: 95%+ compliance across all 14 centres, measured at 3 and 6 months.

Two hospital pilots launching.

01

Responsibility always owned

Any authorised person can identify who is responsible for a given area at any moment. No verbal communication, no manual records required. Replaces a system scoring 70โ€“93% compliance.

02

Full audit trail, automatically

Compliance teams can reconstruct the complete responsibility and machine state history of any area, for any time period. No manual documentation needed. Replaces manual spreadsheet entry.

03

Transitions match real behaviour

Staff complete responsibility transitions without friction. The flow mirrors how people already acted at the physical board.

04

Operational analytics, for the first time

Machine state data is captured continuously across all linacs. No baseline exists to compare against โ€” this capability didn't exist before. Enables departments to identify patterns in machine usage, downtime, and shift coverage over time.

07 โ€” Reflection

Two things I'd do differently: test edge cases with clinical staff earlier (some decisions took longer than they needed to). And I'd have pushed for real usage data before scoping additional features; the model was built on interviews alone, and live data would have sharpened what to prioritise next.

Two things I'd do differently: test edge cases with clinical staff earlier (some decisions took longer than they needed to). And I'd have pushed for real usage data before scoping additional features; the model was built on interviews alone, and live data would have sharpened what to prioritise next.

ยฉ Dimitra 2026

ยฉ Dimitra 2026

ยฉ Dimitra 2026

Create a free website with Framer, the website builder loved by startups, designers and agencies.