---
title: "Choosing a health-card reading engine on evidence, not on a demo"
description: "For Santécie, a benchmark that compares OCR and VLM engines for reading supplementary health insurance cards, under health-data constraints, with a human check of every field."
url: "https://mc-stud.io/en/work/scie-ocr-health-insurance-cards"
author: "Matisse Chenavas"
date: "2026-10-05"
lang: "en"
ai: "true"
---

# Choosing a health-card reading engine on evidence, not on a demo

> The choice of a reading engine for supplementary health insurance cards rests on a reproducible benchmark, not on a sales demo.

- **Client**: Santécie
- **Sector**: Healthcare, supplementary health insurance
- **Period**: 2026
- **My role**: Project owner and architect
- **Setting**: Through a partner
- **Team**: Solo · 1 person
- **Status**: Demonstrator
- **Technologies**: Python, NestJS, Docker, TypeScript, Marimo, OCR, VLM
- **Reading time**: 3 min

## At a glance

- **Stake**: Before handing supplementary health card reading to an engine, Santécie needed to know which one is reliable, and where the data is allowed to go.
- **Mechanism**: A shared core drives versioned Python pipelines from NestJS, and every run produces immutable, therefore comparable, artefacts.
- **Proof**: Eleven architecture decisions, an analysis of OCR offers under HDS constraints and 206 automated tests, in a repository I am the sole author of.
- **Impact**: Santécie can decide between local processing, a hosted open-weight model and an external service on measurements, before committing to a vendor.
- **Limits**: It is a demonstrator: no recognition rate is published, and it claims neither production quality nor medical compliance.

## Metrics

- 11 recorded architecture decisions
- 206 automated tests passing locally

## The starting point

Reading a supplementary health insurance card looks simple. In practice, formats vary from one insurer to another, photos are taken in imperfect conditions, and above all the data is health data: where it is processed, by whom and for how long is not an implementation detail[^hds].

The temptation with this kind of subject is to plug in the best-known service and judge it on a few examples. The project takes the opposite stance: first build something to compare with, then choose.

## What I built

The target is a tool that reads the card on the workstation and proposes business fields, each optional and editable, which a person checks before any confirmation. To choose the engine that will make it possible, I built the benchmark first.

Every pipeline is versioned and produces artefacts that never change again: you compare two engines, or two settings, without ambiguity. I separated control (NestJS) from execution (Python) and isolated inference from the workers, to change models without touching the rest. An annotation tool builds the ground truth, field by field, on specimen cards.

> [!TIP] Build something to compare with before choosing
> A benchmark looks slow at first. In fact it speeds everything else up: each new option is tested in a few hours, and the discussion is about results, not demos.

## What the evidence shows

A large part of the work is written down: the architecture decisions, an analysis of hosted OCR vendors and their confidentiality commitments, notes on open-weight model inference. They let the client understand why an option is kept or dropped, and let a new developer pick the project up without rediscovering everything[^git].

The code is checked by an automated test suite[^tests]. Comparisons are read in notebooks, from the immutable artefacts of each campaign.


## What it changes

The question "should the data leave the workstation?" is settled on measurements, not on a sales promise. The target of the next benchmark, on dedicated GPU infrastructure, is decided; its results will feed the choice between local processing, a hosted open-weight model and an external service, with zero retention if an external API is used for the benchmark.

## Limits

- No recognition rate is published: the results of the benchmark on dedicated infrastructure are not available yet.
- The screenshots show the annotation tool and a comparison notebook on synthetic data, not a finished product.
- Real samples stay private and never leave the client's perimeter.
- The system does not check entitlements and makes no automated decision.

[^hds]: HDS stands for hébergement de données de santé, the certification required in France to host health data on behalf of a third party. It guided the analysis of hosted OCR offers.

[^git]: Sole author of the repository: 207 commits, from 14 August to 5 October 2026.

[^tests]: 206 tests pass locally as of 7 October 2026. They check the code, not reading quality.

---

Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/scie-ocr-health-insurance-cards