AI Bio Writer Grounded in Confirmed Facts
DBB Software designed a bio writer that drafts inside the profile page a clinician is already editing, assembled only from facts they have confirmed. Nothing reaches a live profile until the clinician publishes it. The bar: they publish the draft after light edits.
Industry
Healthcare & Biotech
Service
AI Development
Team
1 Product Owner, 1 AI Engineer, 1 Solution Architect
Project State
July 2026 - Ongoing
Country
United Kingdom
About the Client
A UK-based healthcare technology company operates a global platform that enables patients to review and rate healthcare providers while accessing reliable information to make informed care decisions. With a presence in markets like London, Germany, Austria, Australia, Dubai, and Ireland, the company aims to improve transparency and trust in healthcare through patient feedback and data-driven insights.
The Client's Initial Request
DBB Software enabled clinicians to write an accurate bio in their own voice, without leaving the page they were already on. On most profiles, the field is empty, and where it is filled in the text is often pasted from a practice website.
Internal Writing Workload
The staff were writing and heavily editing bios for clinicians who had not written them. That workload grows with every market.
01
Invented Credentials as Safety Risk
An AI claiming a qualification, an affiliation or a clinical interest the clinician does not have creates reputational risk for the clinician and regulatory risk for the platform. It was recorded as the project's top risk before design began.
02
Incomplete Profile Data
Public professional presence varies widely, and some profiles are missing fields a draft needs. The design had to state what happens when the data runs out.
03
Adoption as the Success Bar
The brief set the success condition at what the clinician does with the draft: publish it after light edits. Adoption is the specification.
04
Solutions We Delivered
DBB Software designed a drafting flow that opens in a panel over the Edit Profile page, built on one rule: the model asserts only what the clinician has confirmed or the research evidence. The flow runs on the shared AI layer DBB designed for the client's other AI features, so model access, spending limits, logging rules and WCAG 2.1 AA accessibility carry over.
Grounding in Confirmed Facts
Grounding happens at the input. The clinician confirms the source fields before anything is generated, corrections override the originals, a missing required field halts generation, research is sanitized before it reaches the model, and the clinician is the only actor who can publish.
Name, title and suffix: fixed, verified platform data.
Specialty, practice city and the clinician's practices: editable.
Keywords: specialty-derived suggestions plus a free-text field.
Where a required field is missing, the flow asks for the value.
The specification bars the draft from asserting anything the confirmed data or the research does not support. The same rule bars unsupported medical claims, anything defamatory about another provider, third-party personal data, and superlatives or ranking language.
Those facts arrive through the read-only shared tool layer DBB designed for the client's AI connector. The feature opens no new route into platform data.
Sanitized Web Research
A web search grounds the draft in real professional context, so it can refer to work the clinician has actually done. A web page can also carry text written to instruct an AI.
Every result is stripped of hidden characters, markup and known attack patterns before it goes near the model.
A second layer rewrites the result in the system's own words. If that rewrite cannot run, the stripped version is used.
Research can add context to a draft. It cannot instruct the system.
Synthetic Profiles During Development
No supplier receives a named clinician's information until its data-processing agreement is signed. The design scopes development and testing to synthetic profiles.
The agreement gates the launch date. It does not gate design or development.
The design does not depend on which search provider or drafting model is selected. Neither choice is fixed.
Tone and Voice Intake
Four questions establish tone and emphasis. The clinician sets how the bio reads without composing a sentence.
A clinician who leaves mid-flow and comes back is told whether their answers were kept.
Access follows the profile's own permissions, so someone with read-only access sees an inactive button and is told why.
Clinician-Controlled Publishing
The clinician reviews, edits and publishes. Until they do, the bio live on the profile stays exactly as it was.
Automatic publishing and bulk generation without individual opt-in were both ruled out.
A copy action hands the text to a clinician who wants it somewhere other than their profile.
Specified Failure Paths
Four failures each have a specified path. The published bio is untouched through all four:
Research returns nothing meaningful, and the flow proceeds on profile data alone
The search provider is slow or unavailable, and the flow degrades or retries once
The drafting model errors or returns nothing, and the clinician gets a clear message and a retry
The flow itself is unavailable, and the button surfaces an error
The design sets a ten-second budget for generation, with a visible loading state past that. Search usage is capped and costed per clinician session, counted in one place so the cap holds across the whole system.
Success Metrics and Named Risks
The engagement defined how the feature will be judged and what could stop it.
Three measures were named: the share of clinicians who publish the draft after light edits, the reduction in blank or generic bios across the platform measured before and after, and the reduction in platform-team hours spent writing bios on clinicians' behalf. No baseline exists yet, so no target was set.
Three risks were registered with likelihood and impact before design began:
An AI asserting a qualification, affiliation or clinical interest the clinician does not hold, rated high impact, answered by grounding in confirmed data and requiring clinician review before publish
Weak public presence for a large share of clinicians, answered by falling back to profile data alone
Clinicians declining to adopt the feature, tracked through the light-edit rate as the core measure
Prompts and responses are retained for quality review and dispute resolution, visible to no other platform user.
Results Achieved
0 automatic publishing paths
Automatic publishing and bulk generation were ruled out. The live profile stays as it is until the clinician acts.
4-question intake
The whole intake is four questions about tone and emphasis. No question asks the clinician to write content.
4 specified failure paths
Failed research, an unavailable provider, a failed model and an unavailable flow each have a defined outcome.
1 adoption bar
One number judges the feature: the share of clinicians who publish the draft after light edits.
Build an AI Feature People Actually Finish
DBB Software designs AI that drafts from facts your platform already holds, with the person whose name is on the output deciding what ships.
Contact Us
"Most of our work starts with a 30-minute call where someone describes a product they're trying to ship and one part of the engineering picture they can't get around.
If that's where you are, let's set one up; I'll tell you straight whether we're the right fit.”
Mina Morkos
Business Development Manager
Want a similar outcome for your team?
Ask our AI assistant — it can pull related case studies, talk through the approach, and put you in touch with the team if you want a deeper conversation.
