Using a Digital Body Chart in Clinic Intake Forms

Every physiotherapy clinic has the same first question on the same sheet of paper: an outline of a body, front and back, and an instruction to mark where it hurts. It survives because it is faster and more accurate than any text field. Patients point. They do not describe.

The digital version should keep that property and add one thing: the answer comes back as data instead of a pencil mark someone has to interpret later.

What the digital chart is good at

Speed on a phone. Most intake forms are filled in on a phone in a waiting room now. A tap beats a dropdown of anatomical terms, and the patient never has to know the word “cervical”.

Consistency. Ten clinicians reading ten pencil marks produce ten slightly different interpretations. A zone key does not have that problem.

No vocabulary barrier. Patients who do not share a first language with the clinic, or who simply do not use clinical terms, can answer accurately. The model is the same in every language, and only the labels change.

Reporting. Once locations are keys rather than prose, you can count them. Which areas walk through the door, how that shifts seasonally, which presentations a given clinician sees most.

What it is not

A body chart is an input component. It records where the patient pointed.

It records where the patient pointed and stops there. No diagnosis, no triage, no severity score, no suggested treatment, no opinion about who gets seen first. PersoScan does none of that, and a widget claiming otherwise is making a regulatory claim it probably cannot support.

Where the line sits

The moment a tool interprets the input and returns a clinical conclusion, it stops being a form control. That is a different product category with a different approval path. Keep the chart on the input side of that line and do the interpretation in your own clinical workflow.

Capturing the selection

The widget emits an event per selection. For intake you usually want the confirmed variant rather than the raw click, so a stray tap while rotating the model does not become a record:

const WIDGET_ORIGIN = new URL('https://widget.persoscan.com').origin;

window.addEventListener('message', (event) => {
  if (event.origin !== WIDGET_ORIGIN) return;
  const msg = event.data;
  if (msg?.source !== 'persoscan-widget' || msg.version !== 'v1') return;

  if (msg.type === 'zone-confirmed') {
    form.painLocation.value = msg.data.zoneId;
    form.painLocationLabel.value = msg.data.zoneName;
    form.bodyModel.value = msg.data.sex;
  }
});

zone-confirmed only fires when the confirmation modal is enabled and the patient presses confirm, which is exactly the behaviour an intake form wants. Turn it on with confirmModalOnClick=true on the embed URL.

In detailed mode the payload also carries region, side and aspect, so “left knee, lateral” arrives as three structured fields rather than a sentence someone has to parse.

Store the key, not the phrase

Put zoneId in the database. Keep zoneName alongside it if you want a human-readable copy for printouts, but treat the key as the truth.

The reason is boring and important. Free-text body parts accumulate variants. Lower back, low back, lumbar, L4/L5, back (lower). Six months of intake later, your “which areas do we see most” report is a data cleaning project. Zone keys are stable strings, and they stay comparable across languages.

If you already have a coding scheme, map zone keys to it once, in one place, at the boundary of your system. Not scattered across three form handlers.

The compliance part

Here is the distinction that matters, and it is easy to get backwards.

A zone click inside the widget is a navigation signal. Nobody is identified, nothing is stored on our side, and it is the same category of event as clicking a category link.

The moment you attach that selection to a patient record, it becomes health data in your system, under whatever regime applies to you. GDPR in the EU, HIPAA in the US, plus your own national rules.

That is not an argument against the chart. It just means being honest about where the sensitive processing happens: your form handler and your database, not the widget. Practically, that means the widget needs no special data agreement, and your intake pipeline needs the same care it already needed for every other field on the form.

PersoScan does not receive, store or process the patient record. The selection is emitted to your page and your code decides what happens next. Details on how PersoScan handles data.

Design notes from real intake flows

Put the chart first. It is the easiest question on the form and the one patients answer without hesitation. Opening with something effortless tends to get more forms finished, which is the same instinct behind paper forms that start with name and date of birth.

Allow more than one area. Patients rarely have exactly one complaint. If your form only accepts a single location, you will get the loudest one and lose the context.

Keep a free-text box underneath. “Anything the chart could not capture” catches referred pain, intermittent symptoms and the things that do not map to a surface region. The chart handles where. Prose handles the rest.

Do not make it mandatory. Some presentations are systemic and have no location. A required body-area field forces those patients to lie to your form.

Match the model to the patient. Offer both body models and let the patient pick. Defaulting to one and hiding the switch is a small thing that a portion of your patients will notice.

Is it worth the change

If your intake is already digital and the only paper left is the pain diagram, yes, almost certainly. You remove the last scanning step and gain a reportable field.

If your intake is still entirely on paper, the body chart is not where to start. Get the form digital first. A clickable body attached to a workflow that still ends in a filing cabinet only moves the problem.