DEV Community

Sergey Kasev
Sergey Kasev

Posted on

Building a lab-report assistant as a solo founder (build in public #1)

Every lab prints the same blood test differently: different names, units, column orders. I wanted all my results from different labs in one table, so I started building one. This is the first build-in-public post about ZaZdorovie: an early-stage prototype, built by one person with a lot of help from AI coding tools.

Upfront, so nobody is misled:

  • It's a prototype. It isn't providing services at scale and has no revenue yet.
  • It isn't a medical device and doesn't diagnose.
  • It isn't available to US patients. The hosted version runs in Russia for Russian users.

What it does today

  1. You upload a PDF or a photo of a lab report.
  2. It reads the values, units, the lab's own reference ranges, the patient's name and date of birth.
  3. It matches each line to a marker in a dictionary of 607 markers in 37 sections: CBC, chemistry, lipids, glucose and insulin, iron, vitamins, hormones, thyroid, coagulation, organic acids and more.
  4. It puts every result from every date in one table, with the change in % and a chart.
  5. It calculates 88 indices where the inputs exist: HOMA-IR, TyG, FIB-4, APRI, eGFR, NLR, TSAT and others. Each comes with its formula, thresholds and the published source.
  6. It produces two reports: a detailed one for a clinician and a plain-language one.
  7. It lets you share a link with a doctor, with permissions.

There's an 86-second demo on fictional data on the project page.

The stack (boring on purpose)

  • Backend: Python + FastAPI, PostgreSQL via SQLAlchemy.
  • PDF text: PyMuPDF. Most lab PDFs have a real text layer, which is fast and exact.
  • Scans and photos: a vision model reads the page into text; local Tesseract OCR is the fallback. The model only transcribes. All interpretation happens in our own rules.
  • The "brain": a rules-and-indices engine in plain code and JSON knowledge files, not a chatbot. Every conclusion points back to the markers and thresholds behind it.
  • Frontend: a web app with a practitioner workspace, patient files and page-based billing.

Why not just send the PDF to a big model and ask "what does this mean"? Three reasons:

  • Reproducibility. The same report must give the same result every time.
  • Traceability. A clinician needs to see why a number is flagged.
  • Liability. A free-text answer about someone's health is the hardest thing to make safe.

What was hard

1. Marker names. "Ferritin", "Ферритин", "FER", "Feritină", "Ferritin (CMIA)" are all the same marker. Most of the work is a normalisation dictionary and tests for every lab format we've seen. Each new lab still breaks something.

2. Units and ranges. The lab's own reference range is the source of truth, not a textbook range. Conventional US units (mg/dL) are partly supported. Reports from US labs haven't been tested yet.

3. Photos. Phone photos of crumpled paper are where OCR fails. We ask the user to confirm doubtful values instead of guessing.

4. Dates and people. One upload can contain three reports from different dates, sometimes for different family members. The app reads name and date of birth and suggests the profile, but asks before attaching.

What I got wrong (so far)

  • Privacy shortcut in OCR. For scans, the current recognition step sends the whole page image, including the patient's name, to an external AI service. That's how the current Russian version works, and it's not acceptable for the EU or US. It's the first thing to fix before any deployment outside Russia: crop the header or keep OCR fully local.
  • Too much in one product. It has a symptom concierge, a disease encyclopaedia, metabolic maps… For the US I'm cutting it down to the core: organize results, show trends, a clinician-facing report.
  • Talking about features before regulation. In the US, software that interprets lab results for a patient is likely a medical device. Software that stores and displays lab results is not (FD&C Act 520(o)(1)(D)). Clinician-facing support whose basis the clinician can review may fall outside the device definition (FDA CDS guidance, January 2026). So the US configuration keeps interpretation for clinicians only. I wrote this up properly before writing any US marketing.

What's next

  • Fix the OCR privacy issue.
  • Test reports from the most common US lab formats on fictional or de-identified samples.
  • Find 1–2 US clinics or health-tech teams for an installed pilot: the software runs on their servers, and their patient data never leaves their environment.

We're licensing the software (source-code or white-label, on the buyer's own infrastructure) from $3,500, with an installed pilot from $1,500. Those are honest prototype prices, not enterprise ones.

If you've built anything that parses lab PDFs, I'd love to compare notes: what broke for you? [email protected]

Not medical advice. ZaZdorovie is an information tool and doesn't replace a clinician.

Disclosure: drafted with help from AI tools; the facts, numbers and sources were checked by the author.

Top comments (0)