Why Patients Should Help Design AI Pain Support

Imagine telling a pain app that you want to spend more time with your family. It turns that wish into a daily walking goal. You meant having enough energy to sit through dinner.

The app has understood the words and missed the life around them. That is the sort of mistake patient involvement should catch.

At Stanford’s June 2026 AI for Mental Health symposium, the keynote panel returned repeatedly to the importance of lived experience. The opening remarks placed collaboration across disciplines at the center of responsible development. Applying those ideas to chronic pain leads to a practical question: who gets to decide what counts as useful support?

What does lived experience add to AI design?

It reveals problems that may be hard to see from a clinic, a research dataset, or a product meeting. The burden of an extra task, the meaning of an unexpected warning, or the difficulty of using an app during a flare can change whether a feature is usable.

In the keynote discussion around 25 minutes, One Mind’s Brandon Staglin described patient input changing the design of a charging cap for an investigational device. Concerns about wearing it overnight influenced a different approach. This was an example of design changing in response to lived experience, not evidence that the device or an AI chatbot improves outcomes.

The same principle applies to less conspicuous decisions. A long list of coping suggestions may feel helpful to its author and exhausting to its reader. An upbeat reminder may feel like encouragement one day and pressure the next.

Co-design means being able to change the plan

Vaile Wright argued for involving clinical expertise and lived experience from the beginning, rather than adding them after technical development. That point appears in the discussion of human dignity and product development. The NSW Agency for Clinical Innovation also provides a co-design guide for developing services with people who have lived experience of mental health conditions.

For a pain-support product, meaningful participation could include reviewing sample conversations before launch, choosing which outcomes matter, and rejecting wording that blames people for their symptoms. Participants should be paid for their work and told what changed because of it. Those are our proposed practices, not claims about how every symposium speaker’s organization operates.

Recruiting only enthusiastic users would miss part of the problem. Include people who stopped using a tool, declined AI support, found the interface inaccessible, or preferred another kind of help. They should not have to defend that preference to participate.

Why this matters for ACT and chronic pain

Acceptance and commitment therapy, or ACT, works with psychological flexibility and personally chosen values. The Association for Contextual Behavioral Science’s explanation of ACT emphasizes these processes rather than presenting ACT as one fixed set of techniques.

For an AI adaptation, that means asking what matters to the person before proposing an action. It also means leaving room to revise the action. Being able to say “that is not what I meant” should be part of the design.

Consider the family-dinner example. A useful follow-up might ask whether the priority is preparing food, joining the conversation, or conserving energy for the visit. The person chooses. The app does not infer that a more active day is automatically a better day.

NICE guidance recommends considering ACT or CBT for chronic primary pain when delivered by appropriately trained healthcare professionals. That does not establish that an AI version provides the same benefit. The distinction matters when an app borrows familiar therapy language.

Technical measurements need a human interpretation

In the opening remarks around 17 minutes, Kilian Pohl described the difficulty of establishing clear ground truth in mental health AI. He framed progress as a scientific discovery problem as well as an engineering challenge.

For pain support, our interpretation is that a neat dashboard should not overrule a person’s account. More steps, fewer messages, or a completed exercise can mean different things in different circumstances. The measurement needs context.

A patient review group can help expose those differences. It cannot establish clinical effectiveness by itself. Both careful product evaluation and appropriate clinical research are needed.

Questions worth asking a developer

• Which decisions did people with lived experience actually change?
• Can I correct a remembered preference or withdraw an earlier agreement?
• Can I decline an exercise without repeated persuasion?
• Are people who find the product unhelpful included in its evaluation?

These questions are more revealing than a claim that a product was “built with patients.” Look for a specific example, a clear boundary, and a way to disagree.

Where to read next

For the clinical background, read what ACT for chronic pain involves and how values can guide everyday choices. For the wider care picture, see whole-person chronic pain care.

More from this series

• AI Mental Health Referrals: What Happens After the Chat?
• Human Review in Mental Health AI: What Should Count?