DoctorFill

Auto-remplissage de formulaires médicaux par IA — Application qui extrait automatiquement les informations depuis des documents médicaux (rapports, lettres, notes cliniques) pour remplir les formulaires XFA/PDF standards suisses.

Architecture

  Frontend (React)              Backend (Docker Compose — DGX Spark)
┌──────────────────┐     ┌──────────────────────────────────────────┐
│  Cloudflare Pages│────▶│  Orchestrator (:8080) ── FastAPI + RAG  │
│  doctorfill.ch   │     │     ├── Marker OCR (:8082) ── 3.8 Go   │
└──────────────────┘     │     ├── TEI (:8081) ────────── 4.5 Go   │
   Cloudflare Tunnel     │     └── vLLM (:8000) ──────── 17.7 Go  │
   api.doctorfill.ch     └──────────────────────────────────────────┘

Composant	Technologie	Rôle
Frontend	React 19, Vite 7, Tailwind, shadcn/ui, Tauri 2	Interface utilisateur (web + desktop)
Orchestrator	FastAPI, ChromaDB, httpx	Coordination pipeline RAG + remplissage XFA
Marker OCR	marker-pdf (FastAPI)	Extraction texte/layout depuis PDF → Markdown
TEI	BAAI/bge-m3, BAAI/bge-reranker-v2-m3	Embeddings + Reranking sémantique
vLLM	Qwen/Qwen2.5-14B-Instruct-AWQ	Extraction de champs par LLM

Formulaires supportés

Formulaire	Description	Champs
AVS	Assurance vieillesse et survivants	~100
Cardio	Formulaire de cardiologie	~60
LAA	Accident (loi fédérale)	~23

Quickstart

Backend (DGX Spark)

cd services/orchestrator
python -m tools.gen_catalog --list tools/catalog_fr.txt --write   # PDF vierges, non versionnés
cd ..
cp .env.example .env    # Configurer les variables
./build.sh              # Build + lancement des 4 services
docker compose ps       # Vérifier la santé

Premier lancement : ~10 min (téléchargement et chargement des modèles en VRAM)

build.sh injecte version, commit et horodatage dans l'image ; /health et l'en-tête de l'application les affichent. Sans l'étape gen_catalog, aucun formulaire n'est exposé.

Frontend

cd frontend
npm install
npm run dev             # Dev server (http://localhost:5173)

Build production

cd frontend
npm run build           # Output dans dist/

Documentation

Ressource	Lien
Architecture détaillée	docs/wiki/Architecture.md
Déploiement Backend	docs/wiki/Deploiement-Backend-DGX-Spark.md
Déploiement Frontend	docs/wiki/Deploiement-Frontend-Cloudflare.md
Pipeline RAG	docs/wiki/Pipeline-RAG.md
Templates	docs/wiki/Templates.md
Services (détails)	services/README.md

Structure du projet

doctorfill/
├── frontend/                 # Application React + Tauri
│   ├── src/
│   │   ├── App.tsx           # Composant principal (drag & drop, API calls)
│   │   ├── Landing.tsx       # Page d'accueil
│   │   └── components/       # Composants UI (shadcn)
│   └── package.json
├── services/                 # Backend microservices
│   ├── orchestrator/         # Pipeline RAG + remplissage PDF
│   │   ├── app.py            # FastAPI principal
│   │   ├── core/             # Modules (extract, fill, inject, checkbox)
│   │   ├── template/         # Définitions JSON des formulaires
│   │   └── forms/            # Templates PDF vierges
│   ├── marker_ocr/           # Service OCR (marker-pdf)
│   ├── tei/                  # Service Embeddings + Reranking
│   ├── vLLM/                 # Configuration LLM
│   ├── docker-compose.yml    # Orchestration Docker
│   └── .env.example          # Variables d'environnement
├── eval/                     # Framework d'évaluation RAG
│   ├── run_eval.py           # Script d'évaluation
│   ├── generate_docs.py      # Générateur de documents synthétiques
│   └── ground_truth.json     # Vérité terrain (Form_AVS)
└── docs/wiki/                # Documentation wiki

Tests

cd services/orchestrator
pip install -r requirements-dev.txt
python -m pytest tests      # sans GPU : OCR, TEI et vLLM sont simulés

Exécutés en CI à chaque MR (.gitlab-ci.yml) : les 21 formulaires et les 25 dossiers de eval/dossiers/ (un par formulaire, plus 4 variantes) de bout en bout. La qualité d'extraction du vrai modèle se contrôle avec eval/regression.py contre une référence. Détails, et réglage de GitLab pour bloquer une fusion rouge : docs/wiki/Tests.md.

Publier une version

Le backend en production suit les versions publiées, pas chaque fusion dans main. Numérotation SemVer : MAJEUR.MINEUR.CORRECTIF.

1. Une MR monte le numéro dans VERSION (par exemple 0.3.0), fusionnée dans main.
2. Deploy → Releases → New release : tag v0.3.0 sur main, avec les notes de version. La CI vérifie que le tag correspond à VERSION et repasse les tests.
3. La mise en production de cette version est alors proposée par une merge request côté infrastructure, à valider.

Seules les versions finales (v1.2.3) partent en production ; un tag v1.2.3-rc1 sert aux essais. Un tag publié ne se déplace pas : pour corriger, publier une nouvelle version.

Évaluation RAG

cd eval
pip install -r requirements.txt

# Générer des documents de test
python generate_docs.py --count 60 --noise 10

# Lancer l'évaluation
python run_eval.py --api http://localhost:8080 --api-key <KEY>

Non-régression sur les 25 dossiers (vérité terrain dérivée des scénarios) : python eval/regression.py --api http://localhost:8080 --api-key <KEY> — voir docs/wiki/Tests.md.

Dernière mesure connue, avant septembre 2026 : 84.6% sur Form_AVS (26 champs) — voir #21 pour le plan d'amélioration.

Roadmap

Voir #18 — Roadmap et les milestones pour le planning détaillé.

Phase	Statut	Échéance
Phase 0 — Sécurité	✅ Complété	—
Phase 1 — MVP Stable	🚧 En cours	25 mars 2026
Phase 2 — RAG Quality	⏳ Planifié	8 avril 2026
Phase 3 — Eval & Monitoring	⏳ Planifié	22 avril 2026