Contents7
At a glance
In thirty seconds- StakeBefore 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.
- MechanismA shared core drives versioned Python pipelines from NestJS, and every run produces immutable, therefore comparable, artefacts.
- ProofEleven architecture decisions, an analysis of OCR offers under HDS constraints and 206 automated tests, in a repository I am the sole author of.
- ImpactSantécie can decide between local processing, a hosted open-weight model and an external service on measurements, before committing to a vendor.
- LimitsIt is a demonstrator: no recognition rate is published, and it claims neither production quality nor medical compliance.
- Client
Santécie- My role
- Project owner and architect
- Setting
- Through a partner
Silico - Team
- Solo · 1 person
- Technologies
Python
NestJS
Docker
TypeScript- Marimo
- OCR
- VLM
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 detail1.
HDS stands for hébergement de données…
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.
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.
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 everything2.
Sole author of the repository: 207…
Sole author of the repository: 207 commits, from 14 August to 5 October 2026.
The code is checked by an automated test suite3. Comparisons are read in notebooks, from the immutable artefacts of each campaign.
206 tests pass locally as of…
206 tests pass locally as of 7 October 2026. They check the code, not reading quality.
- recorded architecture decisions
- 11
- automated tests passing locally
- 206
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.
Share and reuse
The link, the plain text and visuals ready for LinkedIn.