← WORKSHEET 03 / 072025PRIVATE

Body Chart

An interactive anatomical body chart for physiotherapy consultations. Clinicians pin a patient’s symptoms region by region, recording pain level, quality and duration straight onto the figure, and the assessment is built from those marks. Full-stack, from the SVG interaction to the clinical data model.

PRIVATE · NO PUBLIC URL

Role
Full-Stack
Frontend
Vue · Pinia
Backend
NestJS · Prisma
Data
PostgreSQL
Client
Wexelcode
Timeline
2025

70+

front and back, pin to the pain

CONTEXT

A physiotherapist taking a new patient needs to record where it hurts, how badly, what kind of pain it is, and how long it has been going on. Traditionally that lands in free text, which is fine for one appointment and useless across six.

Body Chart replaces the paragraph with the figure. The clinician works directly on an anatomical body, front and back, across 70+ distinct regions, marking each affected area and attaching pain level, quality and duration to it.

THE HARD PART

The data model is the anatomy. A symptom stored as a coordinate on an image cannot be compared between visits, aggregated across patients, or read by anything downstream, and it breaks the moment somebody redraws the illustration.

So the interaction and the data model had to be designed together. Every clickable area on the figure needed to correspond to a clinical region the backend already understands.

WHAT I BUILT

  • The interactive figure: 70+ selectable regions across front and back views, each one individually addressable.
  • Per-region symptom capture for pain level, quality and duration, feeding one in-progress assessment.
  • The clinical data model and API behind it, on NestJS and Prisma over PostgreSQL.
  • Vue and Pinia frontend, wired end to end with the backend.

REVISIONS · THE CALLS I MADE

A

Every mark keys to a named region

A click at (x, y) means nothing clinically, and it dies as soon as the artwork changes. Naming the region instead makes the record queryable, comparable between visits, and stable across redraws of the figure.

B

SVG for the figure rather than canvas

Each region has to be its own hit-testable element, which SVG gives you directly. It also means a region can be focused, labelled and reached by keyboard, instead of being a pixel lookup in a bitmap.

C

One Pinia store owns the in-progress assessment

The figure, the per-region detail panel and the running summary all read the same state. Keeping separate copies is how a consultation ends up showing two different answers halfway through an appointment.

D

Types generated from the Prisma schema

The clinical model has to outlast the UI. Generating types from the schema keeps the frontend honest about what a region and a symptom actually are, rather than describing them a second time by hand.

OUTCOME

  • 70+ regions across front and back views, each carrying its own structured symptom record.
  • Assessments that can be compared between visits and between clinicians instead of read as prose.