← back to case studies

← back to case studies

Doctolib | Creating a billing assistant for german healthcare professionals

Doctolib | Creating a billing assistant for german healthcare professionals

product challenge

Empowering users with billing code suggestions to accelerate their work

sector

Healthtech

key users

German healthcare professionals

date

2026

the problem

the problem

The German public billing system (EBM) has thousands of codes grouped by consultation date and insurance type. Doctors fill bills manually, quarter by quarter, across multiple patients and specialties. Most doctors know the codes they use every day by heart, and miss the rest.

The cognitive load is real, the margin for error is high, and the stakes matter: undercoding loses revenue, overcoding risks compliance issues.

We wanted to reduce that cognitive load with AI suggestions surfaced at the right moment, without the assistant feeling like one more thing to manage.

The German public billing system (EBM) has thousands of codes grouped by consultation date and insurance type. Doctors fill bills manually, quarter by quarter, across multiple patients and specialties. Most doctors know the codes they use every day by heart, and miss the rest.

The cognitive load is real, the margin for error is high, and the stakes matter: undercoding loses revenue, overcoding risks compliance issues.

We wanted to reduce that cognitive load with AI suggestions surfaced at the right moment, without the assistant feeling like one more thing to manage.

what made this hard

what made this hard

So many open questions before touching a single component. There was no obvious right answer to any of these. We had to design and test our way through them.

  • Should suggestions appear inside the bill or side by side?

  • Are AI reasonings useful for every code, every time?

  • What changes between specialties?

  • How does this fit within a larger Doctolib assistant?

  • Can we build something generic enough to scale across billing types?

So many open questions before touching a single component. There was no obvious right answer to any of these. We had to design and test our way through them.

  • Should suggestions appear inside the bill or side by side?

  • Are AI reasonings useful for every code, every time?

  • What changes between specialties?

  • How does this fit within a larger Doctolib assistant?

  • Can we build something generic enough to scale across billing types?

step by step design process

step by step design process

  1. Reviewed past research and iterations with the team through individual work, product syncs and peer design sessions.

  1. Built different components using a widget approach, keeping suggestions modular

  1. Used V0 and Figma Make to prototype and refine interactions, as this product is 100% interactive and cannot be tested with classic Figma static screens.

  1. Generated realistic consultation scenarios with Dust to get actual coding data across specialties.

  1. Tested with medical experts.

  1. Iterated again once live with real data from beta testers.

learnings

The first version has been live for beta testers since December 2025. and is still being iterated on. One thing became clear quickly: the quality of suggestions is directly tied to the quality of the data fed to the model.

We moved faster than expected thanks to V0 and Figma Make, but we hit a real wall on user data volume. An AI product like this needs market exposure to reveal its real failure modes.

← back to case studies

← back to case studies

read resume
open linkedin
book calendly call
send email