ArtVision: radiology workflow

ArtVision has developed medical software since 2004. According to the company website (October 2026), its platform covers 3,000+ radiologist workstation licences and 40+ integrations with hospital information systems.

I worked on it from December 2021 to March 2026 as a designer in a product team, alongside analysts and developers. Most of my time went to the radiology information system (RIS) for radiologists. I also designed study scheduling, a protocol builder and an interface for lab technicians (2023), and developed the shared component system.

Beyond that, I took part in designing the interfaces of platform functions described on the company website: PACS/RIS, diagnostic workstation and web viewer, report templates, voice input, digital pathology (LIS), teleradiology, CT post-processing and AI modules (CT annotation, second opinion, study prioritisation). I do not disclose the internal logic, technology or results of these modules; that is covered by NDA.

In clinical software, every interface decision is tied to a physician's workflow. The designer's job was therefore less about laying out screens and more about defining which actions the system should support, and in what order.

SYSTEM. New solutions had to fit an existing product with established logic. Every change was checked together with its effect on connected workflows.

DOMAIN. Field names, statuses and actions stand for the working processes of physicians and lab staff. Designing the interface first meant understanding what the data means and where each task ends.

FLEXIBILITY. Medical documents and workflows need configurability, and each extra capability adds decisions for users and for the development team.

I started from requirements and terminology: what the user needs to accomplish, which data they need, what they can change and where they go next. I developed workflows in designs and prototypes, clarified ambiguities with the team, and documented states and notes for development.

Alongside this I developed the design system shared across the product line: a UI kit with documentation, light and dark themes, and colour styles built on primitives and tokens. A change made once applies to every interface instead of being repeated in each design by hand. I also worked on how designs are handed over to developers.

The diagram shows roles and hand-offs in the protocol builder: an administrator sets up a template, a physician fills it in, and the result becomes a printed document. It shows flows only; internal rules are outside this publication.

Decision 1. Two roles, one document
In the protocol builder, an administrator configures medical protocol templates and a physician fills them in. The two tasks differ, but they produce a single coherent printed document. I designed configuration and completion as separate workflows that have to converge on one result, and checked how decisions for one role affect the other.
The trade-off: more configuration options make the product more complex, so I weighed each option against how people would use its result.

Decision 2. One change, every interface
I developed the design system so that colours are defined once and apply across all interfaces. Colour styles were moved onto primitives and tokens, and light and dark themes became part of the system.
I do not claim a measurable effect: I have no measurements of this change.