AI pain assessment for clinicians
MyPain · AI product build, web and WhatsApp
OpenKit built the first working version of MyPain, a pain assessment for people living with chronic pain that runs on the web and in WhatsApp. It cannot invent a condition, because every suggestion comes from a table clinicians control, and a clinician can open any assessment afterwards to follow how it got there.
Overview
MyPain’s founding clinician had spent years watching patients arrive at appointments with answers from general-purpose assistants, some of them useful and a lot of them not. Ask one about a symptom and a rare, vivid condition can appear with nothing behind it. In a pain product an invented condition is a safety problem and no instruction in a prompt makes it structurally impossible.
Before anyone wrote product code, OpenKit produced a written specification and a go or no-go decision that MyPain signed off. OpenKit then built the first working version of the service: the conversation, the search that answers a patient’s questions and the goal-setting side. This is decision support under clinical supervision. It is not a regulated medical device and it was designed that way from the first architecture session.
424
conditions in the clinician-curated set, every one driven through the simulator.
6,725
indexed sections behind the answers to a patient’s questions.
17
attributes held for each condition.
The service
What a patient meets
The assessment happens on the web and the goal it produces arrives in WhatsApp as a SMART goal card set from what the patient described in their own words. Both sides read one record, so picking the thread up later does not mean starting again.
Approach
What OpenKit built
The patient talks to one assistant, which follows the order a GP consultation takes. The safety boundary sits in the data:
- The assistant cannot generate a diagnosis.
- Every suggestion is drawn from the curated table, so a condition that is not in it cannot be returned by any route.
- Emergency indicators are checked against what the patient described before the conversation is allowed to raise one.
The scope put accuracy for the common presentations first. Uncommon and rare conditions come back with guidance that a medical opinion is recommended.
Testing
How it was tested
A scenario simulator plays a patient for every condition twice, once answering directly and once hedging the way people do with "about a week" or "I think it started after". A separate model scores every run.
The simulator found one symptom presentation where the conversation raised a very common condition and a rare emergency at the same time, which a reviewing clinician would refuse to sign off. Clinical history moved to the front of the conversation, with new questions that establish whether the pain is new or already long understood. Pain already lasting beyond three months now rules out the non-conditional emergencies. The remaining emergency indicators became conditional on criteria checked against what the patient described.
Result
What the clinical team controls
The clinical team alone maintains the condition set through the admin dashboard, with each condition’s attributes, management plan and emergency criteria. When the clinical position changes, the service changes with it.
Any patient journey can be read back in full. The service grades anomalies so the team knows what to look at first: a wrong suggestion or a missed emergency is critical, a false emergency is high and a conversation past twelve turns or a skipped clinical question is medium. It operates to UK GDPR and keeps its data in the UK.
Other engagements
What could your business do with AI?
Find out with experts who become part of your team. We uncover opportunities, get ideas working, and help your people build on the results. We reply within one working day.
Get in touch Governance & compliance