Pain therapy more than 23 insurers pay for.

Every insurer pays on its own terms. ARAG covers three months and issues the access code itself, by email, against a policy number. SDK covers six, for fully insured members only, with three of its tariffs excluded, and the member asks for the code inside the app. In neither case does the patient pay and claim it back.

Written as conditions in the app, the twenty-fourth insurer is a release and the thirtieth is a rewrite. So an insurer is data — who they are, how a member proves they are one, for how long, and how it is billed — and adding one is a configuration change and a landing page. That is the difference between a sales pipeline the business controls and a backlog item it has to queue behind everything else.

In 2024 medicalmotion launched Pain Lab, a data pool for pain analysis and health services research. It reads what the product already collects — the pain profile, the plan that profile produced, the sessions actually done — rather than a second pipeline built beside the product to feed studies.

That is only possible if therapy data was modelled from the beginning as a record of what happened rather than as the app’s current state. It is a decision you make once, early, and cannot retrofit cheaply: the version where the app overwrites last week’s plan is quicker to build and permanently unable to answer why a patient improved.

The patient app, the tooling the therapists work in, the personalisation engine that turns a pain profile into a plan, and the data platform the research reads are one system, not four products with contracts between them. A therapist’s change to a plan is the patient’s next session and, later, a row somebody studies.

Where those pieces belong to different vendors, the seams are exactly where the meaning of the data gets lost: a field one team treats as advisory becomes another team’s primary key. Keeping them in one team is not tidiness, it is the cheapest way to keep a single definition of what a therapy session is.