Billing, in one click, an act that happens in one product and gets invoiced in another
1 · Context
Owner of the design ticket tied to the commercial launch epic.
Tele-expertise lets a practitioner (the “requester”) ask a peer (the “expert”) for a remote opinion on a patient's file, even without the patient present. It's a reimbursable act, billed separately by each practitioner. Two products in the group didn't talk to each other on this: a secure messaging tool between healthcare professionals, where the act happens, and the patient-record and billing software, where it has to be invoiced.
Three documented frictions: a broken flow (the requester copy-pasted information manually between products), a form that didn't fit (the peer's data-entry field was labeled “prescriber,” a term that made no sense here since there's no prescription involved, didn't open automatically, and pre-filled neither the peer's ID nor the date), and an information asymmetry (the expert usually doesn't know the patient and has to trigger a separate data retrieval from National Health Insurance).
The challenge
How do you bill, in one click and with no re-entry, an act that happens in one product and gets invoiced in another, for two practitioners with opposite constraints?
2 · Approach
Two interdependent roles, not two personas
The requester already has the patient's file; the expert usually doesn't. The requester's constraint is not re-entering data that already exists; the expert's is obtaining data they don't have.
A finding that changed the data model
During spec work, the team found that the official billing documentation marked one piece of peer information as mandatory when it wasn't, confirmed by a clarification from the administration, with the official document to be corrected later. On a regulated topic, the source of truth isn't always right. Designing straight off the official text, unchallenged, would have added an unnecessary mandatory field to an already heavy form.
Three configurations, not one flow
- Fully integrated (priority 1): one-click billing, everything pre-filled through an application bridge, billing status synced back to the messaging product.
- Hybrid (priority 2): a guided entry flow, with peer lookup in the directory.
- External (out of scope): the messaging product simply displays the information needed.
Fixes made to the existing form
Renamed “prescriber” to “peer information,” a label that adapts to the role; the window now opens automatically as soon as a tele-expertise procedure code is selected; full third-party payment is pre-checked, since it's systematic on these acts; patient-data retrieval on the expert's side is pre-filled and triggered automatically; status is synced back to the messaging product after validation.
3 · Outcome
Rolled out progressively, in line with the payment-guarantee lesson: beta with a few dozen practitioners with a pre-identified peer, extended to a few hundred, then opened to all users in March 2026. One-click billing after a tele-expertise is closed is live, with the report automatically flowing back into the patient record. Scale of the problem: ≈300,000 tele-expertise acts billed in France in 2023, over 1.5 million cumulative since 2022. Monthly volume post-launch and satisfaction thresholds by role remain targets, not documented outcomes.
4 · Learnings
Designing for two asymmetric roles is harder than designing for two personas — they're not just different, they're interdependent: what the requester provides determines what the expert can have pre-filled. The design had to account for the handoff between them, not two parallel flows. The single most effective design move on this project was renaming one word: renaming “prescriber” isn't spectacular, and it's probably the single most cost-effective fix in the whole project.