Case · 09
Designing the operating layer of a clinical platform
Administration as a first-class surface: hospitals, roles, modules, recovery.
Hospitals, users, modules and permissions had to be configured before any clinician could use VoxelBox.
Errors at this layer could expose the wrong capability, create access conflicts or make a deployment difficult to recover.
I designed the administration model as part of the product, not as a secondary internal tool.
The problem
The platform needed to support multiple hospitals and groups, radiologists, neurosurgeons and technicians, different product modules, organisation-level configuration, role-based access, evolving customer agreements, and both internal and customer administrators.
A simple user-and-role table would not be enough.
Key decisions
Separate organisation structure from user access
A user’s access depended on more than their job title. It depended on the organisation, enabled modules, clinical responsibility and workflow they were expected to perform.
Make configuration understandable before saving
Administrators needed to see the effect of enabling a role or module before applying it. The interface was designed to reduce accidental combinations and make important dependencies visible.
Support recovery
Administrative work often happens under time pressure during deployment. Drafts, autosave, confirmation for destructive actions and clear change states helped reduce the cost of mistakes.
Avoid hiding policy inside the interface
The administration model exposed unresolved product-policy questions. For example, whether a role should be allowed to report could not be decided only by adding a checkbox. The organisation first needed a clear reporting and accountability model.
Why this work matters
Clinical software is only as reliable as the operating system around it.
A strong product experience depends on safe configuration, understandable access and the ability to recover when something goes wrong.