DEV Community: John Alexander Kamau

Who sees your cycle data? What a 2021 FTC order teaches builders about sensitive health data

John Alexander Kamau — Mon, 09 Nov 2026 09:00:00 +0000

Cycle-tracking apps now use AI to predict periods and fertile windows. Many people find that useful, and I'm not here to tell anyone to delete theirs. But the data is some of the most sensitive a person creates: it can show whether someone is trying to conceive, pregnant, or unwell.

One case

In 2021 the US Federal Trade Commission finalised an order against Flo Health. The FTC alleged that the app told users their health data would stay private while sharing it with analytics and marketing providers, including those of Facebook and Google. Flo has said the settlement was not an admission of wrongdoing. The order requires affirmative consent before sharing health information and an independent privacy review. Sources: the FTC press release and news coverage.

That is one case from a few years ago. I'm not saying every app does this, and I have not audited any app.

The questions, for users and builders

Who sees my data? As a builder, write the list of every system that touches it, including analytics and error tracking.
Why? If you cannot say why a recipient needs it, it should not get it.
For how long, and can I delete it? Retention is a feature, not a footnote.

How I answered them in Tabibu

When someone uploads a document, the file is not stored. The answer is kept for about 48 hours, and there is an opt-in "Keep for 30 days". Those are design choices I can state in a sentence, which is the test I use. They are not a security audit, and I would not call them one.

The lesson

For builders: sensitive health data needs a clear answer to "who sees this, why, and for how long?" before launch, not after a complaint. For users: ask the same three questions of any app you give it to.

Do you know who your cycle app shares data with?

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

Authorized is not proven: what the FDA's AI device list does and doesn't tell you

John Alexander Kamau — Fri, 06 Nov 2026 09:00:00 +0000

If you want to see where AI actually works in health, don't look at chatbots. Look at scans.

The US FDA keeps a list of AI-enabled medical devices. When I counted the list on the FDA's page on 22 October 2026, it had 1,614 entries, the latest decided on 29 June 2026, and 1,230 of them (about 76%) were listed under radiology. That is my own count of the published table, so check it against the page before you repeat it.

Reading the fine print

The list includes hardware with AI inside, not only software.
The FDA says on its own page that the list is not comprehensive: devices were identified mainly by AI-related terms in their authorization summaries.
It counts authorizations. It does not count whether patients got better.

So "authorized" is a statement about a regulatory process. It is not the same as "proven to improve outcomes in a real clinic".

The evidence gap, from England

NICE has put some imaging-adjacent tools in an "early-use" category: promising, but keep collecting evidence. A June 2026 summary reports four AI echocardiography tools there, with evidence not yet strong enough for routine funding. That is the same field, seen through a different gate.

Questions I'd ask of any imaging AI

These are my questions, not findings:

Tested at how many sites, and do they look like mine?
Compared against what baseline: a radiologist alone, or a radiologist with the tool?
Is there any data on outcomes, not just detection?
What happens when it disagrees with the human?

What I chose not to build

Tabibu does not read X-ray, CT or MRI images, or photos of skin. If you upload one, it says so. Interpreting those is a medical-device question, and I would rather say "I can't" than guess. What it does handle is a radiology report: it explains the report by quoting what the radiologist wrote. In my testing, radiology reports sometimes end on a safe fallback instead of a full explanation, about 1 in 8.

The field is real, regulated and growing, and the question is moving from "does it work in a lab" to "does it improve care in a real clinic". Would you want an AI to read your scan, with a radiologist checking?

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

AI in mental health: support is not treatment, and what builders can learn from Woebot

John Alexander Kamau — Wed, 04 Nov 2026 09:00:00 +0000

If you or someone you know is in crisis, please contact your local emergency number or crisis line. I'm an engineer, not a clinician, and this is not advice.

Millions of people tell an AI things they have not told anyone else. Is that okay?

First, why it happens. Therapy can be expensive, far away, or have a long waiting list. A chatbot is there at three in the morning. That access gap is real.

What happened to Woebot

Woebot was one of the best-known therapy chatbots. It closed its consumer app in 2025. STAT reported that its founder, Alison Darcy, attributed the shutdown largely to the cost and challenge of meeting the FDA's requirements for marketing authorization, made more pressing by large language models the FDA had not yet worked out how to regulate.

What an FDA committee worried about

In November 2025, the FDA's Digital Health Advisory Committee met to discuss generative AI therapy chatbots. A law-firm summary of the meeting (Orrick) reports risks the experts raised: hallucinations, missed or worsened harm from undetected deterioration, uneven performance across different groups of people, and privacy and security weaknesses. It also reports a strong emphasis on clear paths to a human, such as predefined escalation plans and one-tap urgent support. I could not read the STAT coverage of the meeting past its paywall, and I have not checked whether any generative AI therapy tool has been authorized since.

The line I draw

I'm not telling you what works. I'm telling you what the experts worried about, and then what I do about the same risks in my own product.

My line: a support tool can help with access. Anything that acts like treatment needs evidence, clear limits and a way to reach a person.

For Tabibu that became three rules:

It does not diagnose and does not present itself as treatment.
Its emergency check uses deterministic rules, not a model, so a message about suicidal thoughts shows emergency numbers before anything else. The rules were written by me and no clinician has reviewed them yet. I treat that as a floor, not a safety certificate.
It does not try to be the last stop. The point is to get someone to a person.

Agreeing too much, the "sycophancy" risk, is the one I find hardest as a builder, because a pleasant answer is the easiest thing for a model to produce. I do not have a complete answer to it.

Where do you think the line should be?

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

How I ship fixes to open-source projects maintainers actually merge (with AI in the loop)

John Alexander Kamau — Mon, 02 Nov 2026 14:47:06 +0000

Last month six of my pull requests were merged into other people's projects: an Android keyboard, a Python OAuth library and a reverse-engineering toolkit. Seven more are in review in Hyperledger Besu, Qwen Code, ParadeDB and Ratatui. Rust, Java, TypeScript, Kotlin and Python.

I use AI heavily to get there. I also know how maintainers feel about drive-by AI pull requests, because I read their issue threads. So here's the workflow I've settled on: fast because of AI, and still something a maintainer is glad to review.

1. Read the project's rules before the code

Every project I contribute to gets the same first pass: CONTRIBUTING.md, any AGENTS.md, the PR template, and the AI policy if there is one.

The policies vary a lot. Ratatui welcomes AI-assisted PRs and asks you to say so. pandas wants the human to open the PR and do the talking, and to say which tools were used. Some projects ban AI-generated contributions outright, and I don't contribute to those. Others need a signed CLA or a DCO sign-off on every commit.

I keep a small policy file per repo so I never have to rediscover this, and so I never send a PR the project said it doesn't want.

2. Reproduce first, then write the failing test

A fix isn't real until a test fails without it.

In Ratatui, Japanese halfwidth sound marks (ﾞﾟ) started taking two cells instead of one. Nothing in Ratatui had changed. The unicode-width crate's 0.2.3 release had corrected those characters from width 0 to width 1, and Ratatui had a workaround that added +1 for them. Both "fixes" were now applying at once.

I ran the existing test suite on both dependency versions: everything passed on 0.2.2, and eight tests failed on 0.2.3. That told me the bug was real, where it was, and which tests would prove the fix.

3. Make the smallest change that turns it green

.filter(|c| {
    matches!(*c, '\u{FF9E}' | '\u{FF9F}')
        && c.width() == Some(0) // only compensate when unicode-width doesn't
})

One condition. It's correct on both versions of the dependency, so nobody has to pin anything. I didn't bump the dependency floor, refactor the width code or "clean up" anything nearby. Maintainers review for free, and every extra line is a cost I'd be putting on them.

4. Ask when the fix is a design decision

Not every bug has one right answer. In Qwen Code, a /loop that had been told to stop could still resume, because a wakeup that had already fired was sitting in a queue the cancel path couldn't reach. Fixing the queue properly changes behaviour for people who chat while a loop runs.

So instead of guessing and sending a large PR, I wrote up what I'd traced, offered three scoped options, and asked which semantics they wanted. A five-paragraph comment costs the maintainer two minutes. A 300-line PR in the wrong direction costs them an hour and a polite rejection.

5. Review my own work like it's someone else's

Before anything is pushed I go through it as a reviewer would:

Correctness: edge cases, error paths, callers that might break.
Tests: does each new test fail if the fix is removed (a revert check)?
Security: anything touching input handling, auth or dependencies.
Honesty: the PR text says exactly what the diff does. If it fixes half an issue it says "Refs", not "Fixes", and explains what's left.

That last one matters more than it sounds. Two of my Besu PRs this week fix part of an issue and say so. Changing the rest would have broken existing API clients, and that's the maintainers' call to make.

Where AI fits

AI makes the slow parts fast: searching big codebases, reading unfamiliar modules, drafting tests and first versions of a change, running checks, keeping track of a dozen open PRs. It's also good at finding the issues worth doing. Fresh bugs in popular repos get claimed within hours, so speed of triage matters.

What it doesn't do is decide. Which issue is worth my time, whether a fix belongs in the code or the docs, when to stop and ask, what not to change: that's still engineering, and it's still my name on the commit. Where a project asks contributors to disclose AI use, I disclose it.

What's next

I'm focusing on a few projects where I can become a regular contributor rather than a one-off: Qwen Code on the AI-tooling side, Besu on Ethereum infrastructure, and one more AI infrastructure project. Reviews, bug triage and docs count too. They're some of the most useful work you can give a maintainer.

If you maintain a project and have issues that need hands, I'd like to hear about them.

John Alexander Kamau, Senior AI & Full-Stack Engineer. github.com/Xander-AJ

“Promising, now prove it”: how NICE's early value assessment works as a rulebook for health AI builders

John Alexander Kamau — Mon, 02 Nov 2026 09:00:00 +0000

Who decides which health AI gets used? It isn't only the companies.

NICE is the body that produces guidance for the NHS and the wider health and care system in England. For digital and AI tools it has a middle path called early value assessment (EVA). It can say: this looks promising, you may use it early, but evidence has to be collected. Or it can say the evidence is not there yet.

What it has done so far

A June 2026 summary from the British Society of Echocardiography reports that NICE's early value assessment HTG779 reviewed four AI echocardiography tools for heart failure and concluded there is currently insufficient evidence for routine NHS adoption or funding, placing them in an early-use category. NICE has also published an early value assessment (HTG746) on AI for skin lesion triage. I read these from summaries and one NICE page; I did not read the full guidance documents, so check the wording before you quote them.

The US looks different

The National Institutes of Health shapes health AI differently, mostly through research funding and data priorities. It asked the public for input on an AI strategy in 2025. I have not confirmed where that stands now, so I won't say.

Why I like the rule

"Promising, now prove it" gives patients the benefit early and keeps the evidence coming. For a builder it is also a spec, and I'd use it even where no regulator is asking:

Write the evidence plan before launch. What will you measure while the tool is in use, and what result would make you pull it back?
Measure the right thing. A lab score is not an outcome. I ran HealthBench on Tabibu and published that my own pipeline scored 0.426 against 0.522 for the bare model, on my own 150-conversation re-run, not the official leaderboard. Write-up here.
Publish the limits. Tabibu has no clinician review yet, and says so at tabibu.health/trust.

Tabibu is an information tool and is not going through a medical-device process. I mention the rulebook because it is a good one to borrow, not because I meet it.

Should an AI health tool have to prove itself before it is used, or while it is being used? I lean toward "while, with a plan", and I'd like to hear the case against.

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

Who maintains the truth? A nonprofit wiki, a UK clinical AI, and the question behind both

John Alexander Kamau — Fri, 30 Oct 2026 09:00:00 +0000

Not every medical knowledge tool is a startup. One of the biggest is a wiki.

A nonprofit that doctors edit

WikEM describes itself as the world's largest open-access emergency medicine reference. It is a project of the OpenEM Foundation, a US nonprofit, and clinicians contribute and edit. Its site lists more than 71,000 pages in 15 languages, and it has added an AI search bar, WikEM.AI. The figures are from WikEM's own site (71,428 pages when I looked on 17 October 2026); I have not audited them, and it describes OpenEM as a 501(c)(3) nonprofit public charity.

A commercial UK assistant built on guidelines

iatroX is a UK clinical AI assistant. Its FAQ says it draws on official clinical guidance and peer-reviewed research, synced within 24 to 48 hours of publication, and describes its guideline Q&A tool as a UKCA-marked, MHRA-registered Class I medical device. Its exam-prep tools are described as not being medical devices. I have not checked the MHRA register, so treat the registration as the company's claim.

The same hard question

A wiki can be fast and a bit uneven. A company can be polished and still make mistakes. I'm not ranking them. For both, the question that matters to a builder is the same: who checks the content, and how fast does it update?

Three things I took from this for my own work:

Anchor answers to a source you can name. Tabibu answers from a set of Kenyan clinical guidelines and cites them. When a question falls outside that set, the answer starts with a fixed label saying it is general information, not from those guidelines, and it does not invent citations.
Write down the update path. Medical knowledge changes. If you cannot say how a changed guideline reaches an answer, and how quickly, you do not have a knowledge system, you have a snapshot.
Say what you do not know. For some facts (prices, helpline numbers, vaccine schedules, the essential medicines list) Tabibu must get them from a retrieved source or a tool. Without one it says it cannot find it, rather than guessing.

Why I like the nonprofit model, and where it stops

An open, clinician-edited reference has a weaker incentive to flatter the reader, and anyone can see the edits. The cost is that funding is thinner and quality depends on who is watching. A commercial product can fund review but may have other pressures. Neither model removes the need for a checker.

Would you trust a medical wiki edited by clinicians, or would you want a company behind it? Tell me why.

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

A benchmark score without a method is marketing: six checks for any health AI claim

John Alexander Kamau — Wed, 28 Oct 2026 09:00:00 +0000

While reading about clinical AI tools this week I found a page with a bar chart showing a product beating several large models. The test was not named. There was no method and no date. So I did not copy the numbers anywhere, because nobody can check them.

I hold my own product to the same standard. Here are the six questions I now ask about any health AI score, mine included.

1. What is the test called?

If the chart does not name the benchmark, stop. A score with no test behind it is a decoration.

2. Who ran it?

A company running its own test on its own product is not the same as an independent group running it. Both can be honest, but you should know which one you are looking at.

When I ran HealthBench on Tabibu, I wrote down that it was my own re-run on 150 conversations, not the official leaderboard.

3. How big and how recent?

A sample size and a date turn a claim into something you can argue with. Models change monthly. A score with no date is already expired.

4. Against what baseline?

A number alone means nothing. My bare model scored 0.522 and my full pipeline scored 0.426. Without the 0.522 next to it, the 0.426 looks like a fine result. With it, it looks like what it is: my safety layer deliberately says less, and this benchmark rewards saying more.

5. What does it not measure?

HealthBench rewards completeness. A safety layer that refuses to give a dose will lose points for that choice. I think that is the right trade, but I should say so, and say that a benchmark score is not a clinical validation. Tabibu has no clinician review yet.

6. Did they publish a bad number?

This is the one I trust most. Anyone can publish the chart where they win. Showing a result where you lose, and what you found when you read the failures, tells me the team is measuring and not marketing.

Reading my per-criterion failures is how I found that the system could quote prescription doses from a retrieved formulary. I fixed it and wrote regression tests. I would not have found it from a good score.

A related number, with its limits

In a 2026 Mount Sinai study in Communications Medicine, a short safety reminder cut potentially harmful clinical choices across 20 AI models from 16.6% to 10.1% (more than 10 million responses; 19 of the 20 models improved). I read Mount Sinai's press release (the paper appeared in Communications Medicine on 26 September 2026), not the paper, so I'd check the exact definition of "potentially harmful" before building on it. It is a good example of a number with a named test, a named group and a stated limit: better, and not zero.

If you build health AI, which of these six do you skip most often? Mine was number 2, until I made myself write it down.

The full write-up of my HealthBench run, with the tables, is here.

General information, not medical advice.

I post short videos in this series on LinkedIn and TikTok; come say hi.

Who pays for the answer? Health AI business models and what they do to your architecture

John Alexander Kamau — Mon, 26 Oct 2026 09:00:00 +0000

A medical AI that is free for doctors makes me ask one question first: who is paying?

STAT reported in January 2026 that OpenEvidence, a tool clinicians use to ask medical questions and get cited answers, is free to US clinicians who verify with a national provider number, and that advertising is its primary business model. The same report covers a $250 million raise.

That is a clever way to put a tool in front of doctors. It also raises a fair question: if an ad sits next to a medical answer, how do we know the ad is not shaping the answer? The company's advertising policy says advertisers cannot influence the information it provides, and that the answer system and the ad system are fully unconnected. That is the company describing itself. I have seen no independent test either way, and I'm not claiming a problem. The funding details above are from press reporting.

Why an engineer should care

The business model is an architecture decision, whether or not anyone writes it down.

If ads are the revenue, there should be a hard wall between the system that writes the answer and the system that picks the ad. The answer generator should never see the ad inventory. I would want that to be testable, not a promise.
If a subscription is the revenue, the pressure goes the other way: keep users happy and engaged. That can push a product toward agreeable answers. In health, agreeable is not always safe.
If a nonprofit or an open reference is the source, funding is thinner and updates can lag, but the incentive to flatter the reader is weaker.

None of these is automatically good or bad. Each one tells you what to test.

What I do, and what I cannot claim

Tabibu is a free health-information assistant that started in Kenya, with paid Basic and Pro plans for features like document reading. I know the pull of "keep the user happy", which is why the safety rules are written as tests: it does not diagnose, does not call a result normal, and does not change a dose. It has no clinician review yet, and the site says so.

I am not claiming my model is cleaner than anyone else's. I am saying one habit would help the whole field.

The rule I would apply to any health AI

Show who pays. Show how the answer was built.

Not in a footer nobody reads. Next to the answer, in plain words: where the sources came from, whether anything was paid for, and what the tool will not do.

Should a medical answer ever sit next to an ad? I can see arguments on both sides and would like to hear yours.

General information, not medical advice.

I post short videos in this series on LinkedIn and TikTok; come say hi.

The AI that listens to your doctor's visit: what an engineer should ask about ambient scribes

John Alexander Kamau — Thu, 22 Oct 2026 10:03:56 +0000

Your doctor might soon have a third person in the room: an AI, listening.

It's called an ambient scribe. It records the visit and writes the clinical note, so the clinician looks at you instead of the screen. Heidi Health is one of the best known. Its own site says it goes beyond notes into coding, referral triage, refills and pre-charting, and Fierce Healthcare reported in September 2026 that it landed $340 million: a $100 million Series C at a $900 million valuation, plus a $240 million growth investment. I have not tested any scribe, so everything here about the companies comes from their sites and the press.

The promise is simple: less typing, more eye contact. The engineering questions are just as simple, and they are the ones I would ask before trusting one.

1. Where is the recording stored?

Audio of a medical visit is some of the most sensitive data there is. As a builder I'd want to know whether the audio is kept at all once the note exists, for how long, and in which country. The safest design is the one that keeps the least.

2. Who can access it?

Not just "is it encrypted", but who inside the vendor and the clinic can open it, and whether that access is logged. A recording nobody can audit is a liability.

3. Who checks the note before it enters the record?

This is the one I'd care about most. A scribe's worst failure is a line that was never said, written in a calm clinical voice. Two things would make a sign-off real: the transcript sits next to the note so the clinician can check one against the other, and the note is not filed until someone signs it.

What I could not find

I have not seen independent data on how often scribe notes are wrong, so I won't invent a number. That evidence is exactly what I'd want to see before anyone claims these tools are safe.

What I did differently

Tabibu has the same shape of problem on the patient side. When someone uploads a lab report, the file is not stored, the answer is kept for about 48 hours, and there is an opt-in "Keep for 30 days" for people who want it. I chose the shortest default because I'd rather someone choose to keep their data than have to chase me to delete it. The limit: it is a design choice, not an audit.

If your clinic uses a scribe, you are allowed to ask those three questions. Would you be comfortable with an AI listening to your visit? I'd like to know why or why not.

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

Four kinds of health AI, and what each one asks of an engineer

John Alexander Kamau — Wed, 21 Oct 2026 09:00:00 +0000

I'm a senior AI and full-stack engineer. For the past year I have been building a health AI, and this week I read up on what everyone else ships. The first thing I noticed is that "health AI" is used for four different products. They fail in different ways, so each needs a different kind of engineering.

1. The scribe

It listens to a visit and writes the note. Ambient scribes such as Heidi sit here.

The failure to design for: a line in the record that was never said, written in a calm clinical voice. My rule would be that nothing reaches the chart without a clinician reading it, and the transcript stays next to the note so that reading is real and not a click-through.

2. The answer engine for clinicians

A doctor asks a question and gets an answer with citations. OpenEvidence and Vera Health are examples.

According to STAT (January 2026), OpenEvidence is free to US clinicians and advertising is its main business model; the same report covers a $250 million raise. Vera Health says on its site that it searches more than 60 million peer-reviewed papers and links every key statement to its original source.

The failure to design for: a citation that exists but does not support the sentence next to it. A link is not evidence. The check I would build is a test that takes each claim and its cited passage and asks whether the passage actually says it.

3. The chart copilot

It reads the whole record so the doctor does not have to. Navina describes itself on its site as pulling records from the EHR, health exchanges and claims data into one view, and surfacing evidence for what it flags.

The failure to design for: noise. A copilot that flags everything trains people to ignore it. The check is boring and measurable: of the things it flagged, how many mattered, and what did it miss?

4. The patient assistant

This is the one I build, so I'll say it plainly. Tabibu is a free health-information assistant that started in Kenya. The person on the other end is not a clinician and cannot judge the answer.

The failures to design for are false reassurance and dosing. So the rules are written as tests, not as hopes: it does not diagnose, does not call a result normal, and does not tell you to start, stop or change a medicine. It has no clinician review yet. That limit is listed on the site, because a limit you hide is worse than one you publish.

What this changed for me

Before this I picked the model first and added safety later. Now I pick the failure first. Ask "what is the worst believable wrong answer for this kind of product?", then build the check that would catch it.

It also matters that safety work is real but not magic. In a 2026 Mount Sinai study of 20 AI models, published in Communications Medicine and described in a Mount Sinai press release, a short safety reminder cut potentially harmful clinical choices from 16.6% to 10.1%. That is progress. It is also not zero.

Which of the four do you think is hardest to get right? I would like to hear where you disagree.

Descriptions of other companies come from their own sites or from the press named above; I have not tested those products. General information, not medical advice.

I post short videos in this series on LinkedIn and TikTok; come say hi.

Why health is the hardest place to put AI: three things that changed how I build

John Alexander Kamau — Mon, 19 Oct 2026 09:00:00 +0000

In most jobs, when an AI is wrong, you fix the draft. In health, you might not get the chance.

I'm John, a senior AI and full-stack engineer. I spent the last year building a health-information assistant, Tabibu, and I'm starting this series with the question I get asked most: why is health so much harder than the other places I have shipped AI?

1. A mistake costs more

A wrong dose is not a typo. In a normal product, a bad answer costs a retry. In health, someone may act on it. So I stopped asking "is the answer good?" and started asking "what is the worst believable wrong answer here?" For Tabibu the answer was a dose, so the system does not tell anyone to start, stop or change a medicine.

2. The AI sounds equally sure whether it is right or wrong

This is the one that surprised me as an engineer. A model gives a calm, fluent answer when it knows and when it is guessing. A patient usually cannot tell the difference, because telling the difference is the expert's job.

So I stopped trusting tone as a signal. Answers from Tabibu show their sources, and when the guidelines do not cover a question it says so and labels the answer as general information. A confident voice is not a reason to trust anything.

3. The rules are strict for good reasons

Where software influences a medical decision, regulators in many places treat it as a medical device, and that takes evidence. I do not make that claim for Tabibu: it is an information tool, it has no clinician review yet, and the limits are listed at tabibu.health/trust.

For a builder, the lesson is to design the product so its boundaries are written down and testable, not implied.

Is it hopeless?

No. A 2026 Mount Sinai study in Communications Medicine tested 20 AI models on more than 10 million responses. Adding a short safety reminder cut potentially harmful clinical choices from 16.6% to 10.1%, with reductions in 19 of the 20 models. I read Mount Sinai's press release, not the paper itself. Its lead researcher said a reminder is one safeguard, not a substitute for clinical oversight. That is the shape I trust: safety work helps, and it does not reach zero.

ECRI's 2026 patient safety report ranks AI in clinical diagnosis first on its top-10 list of concerns, which fits what I have seen: the question is not whether AI is good or bad for health, but where it is safe enough, and who checks.

What I'd ask you

What is one health decision you would never leave to an AI? Over the next few weeks I'll cover who builds these tools, how they make money, who sets the rules, and where it fails.

I post short videos in this series on LinkedIn and TikTok; come say hi.

General information, not medical advice.

Tabibu Update #1: Tabibu can now read your documents

John Alexander Kamau — Fri, 16 Oct 2026 11:03:46 +0000

This is the newest Tabibu update. Tabibu can now read your documents.

Tabibu is a free health-information assistant. It started in Kenya and is built for people in other countries too. Until now you could only type a question. Now, on the website, you can add a lab report, a prescription, a PDF, a Word file or a photo of one. Tabibu reads it, explains it in plain words, and gives you questions to ask your clinician.

What it accepts

PDF (text or scanned), Word (.docx), plain text and Markdown, and JPG, PNG or WEBP photos, up to 8 MB. The feature is for Basic and Pro plans. Free accounts cannot upload files.

How it works, in two steps

A vision model transcribes the file into text.
The normal text-only Tabibu pipeline explains that text.

The second step is the same one that answers typed questions, with the same safety rules. The file never goes straight to the part that talks to you.

What it will not do

It will not diagnose you.
It will not tell you a result is "normal" or "fine".
It will not tell you to start, stop or change a medicine. Doses are repeated only as printed on the document.
It does not read X-ray, CT or MRI images, or photos of skin. If you upload one, it says so. A radiology report is different: Tabibu explains it by quoting what the radiologist wrote.

I kept image reading out on purpose. Interpreting a scan or a skin photo is a medical-device question, and I would rather say "I can't" than guess.

What happens to your file

The file and the text read from it are not stored or logged. Photos have their location data (EXIF) removed. Only your question and Tabibu's answer are saved, for about 48 hours, like any chat. There is now an opt-in "Keep 30 days" button if you want to come back to a chat after you have seen a doctor. It is off unless you turn it on, and chats that involved a file cannot be kept. Answers about files never enter the shared answer cache.

How I tested it

I used made-up documents only, never real patient files: lab reports, a prescription, a Word note, radiology reports, a DICOM file. What I checked:

A prescription: doses came back exactly as printed.
An X-ray report: the answer quoted the radiologist and did not say the scan was fine.
A file with a hidden instruction telling the model to call every result normal: it ignored the instruction and said it had.
A DICOM file: it refused.

The limits, which matter more than the wins

In my testing, about 1 in 8 radiology reports ended on a safe fallback: "here is the text I read, and questions for your clinician" instead of a full explanation. It is never a wrong claim, but it is not the full answer, and I am not counting it as a success.
These were spot checks on a small set of made-up documents. I have not run a full evaluation, so I am not publishing an accuracy number.
There is no clinician review of the policy yet. Kiswahili answers are AI-reviewed only.
WhatsApp document reading is in testing and is not open to everyone.
I have not measured the cost per file end to end yet.

The limits are listed on the trust page, and I update them when they change.

One question

On a public health benchmark, a plain AI model scored higher than Tabibu on my own re-run (0.522 against 0.426, not the official leaderboard). I wrote about why here. So the test does not tell me what you want. Do you want a health AI that tells you what you have and what to take, one that explains and sends you to a clinician, or something in between? Tell me in the comments.

Tabibu gives general health information, not a diagnosis or medical advice.