909e051cc9
- Multi-modèles : 4 rôles LLM (coding=gemma3:27b-cloud, cpam=gemma3:27b-cloud, validation=deepseek-v3.2:cloud, qc=gemma3:12b) avec get_model(role) - Prompts externalisés : 7 templates dans src/prompts/templates.py - Cache Ollama : modèle stocké par entrée (migration auto ancien format) - call_ollama() : paramètre role= (priorité: model > role > global) - Quality engine : veto_engine + decision_engine + rules_router (YAML) - Benchmark qualité : scripts/benchmark_quality.py (A/B, métriques CIM-10) - Fix biologie : valeurs qualitatives (troponine négative) non filtrées - Fix CPAM : gemma3:27b-cloud au lieu de deepseek (JSON tronqué par thinking) - CPAM max_tokens 4000→6000, viewer admin multi-modèles - Benchmark 10 dossiers : 100% DAS valides, 10/10 CPAM, 243s/dossier Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
69 lines
1.9 KiB
Markdown
69 lines
1.9 KiB
Markdown
# Règles (vetos + décisions)
|
||
|
||
Ce dossier contient la configuration "métier" pour piloter le moteur qualité.
|
||
|
||
## Fichiers
|
||
|
||
- `base.yaml` : socle commun (règles activées par défaut).
|
||
- `enabled.yaml` : choisit les overlays à activer (site/spécialité).
|
||
- `specialties/*.yaml` : overrides par spécialité.
|
||
- `sites/*.yaml` : overrides par établissement.
|
||
|
||
## Principe
|
||
|
||
- Une règle **non listée** est considérée **activée**.
|
||
- Ça évite de casser le comportement historique lors d'une montée de version.
|
||
- Une règle listée peut être :
|
||
- `enabled: false` → désactivée
|
||
- (VETO) `force_severity: "HARD"|"MEDIUM"|"LOW"` → force la sévérité
|
||
|
||
## Exemple d'override
|
||
|
||
Créer `config/rules/sites/chu_poitiers.yaml` :
|
||
|
||
```yaml
|
||
version: 1
|
||
rules:
|
||
VETO-12:
|
||
enabled: false
|
||
VETO-09:
|
||
force_severity: "HARD"
|
||
```
|
||
|
||
Puis activer dans `enabled.yaml` :
|
||
|
||
```yaml
|
||
active:
|
||
site: "chu_poitiers"
|
||
specialty: ""
|
||
extra: []
|
||
```
|
||
|
||
|
||
## Routage automatique (router.yaml)
|
||
|
||
Le fichier `router.yaml` permet d’activer automatiquement des **packs** de règles en fonction des signaux du dossier (codes, biologie, extraits). Concrètement :
|
||
|
||
- Par défaut, seuls les packs listés dans `defaults.enabled_packs` sont actifs.
|
||
- Quand un trigger match, on ajoute ses `enable_packs`.
|
||
- Le routage est appliqué **par dossier** (et re-appliqué sur la version fusionnée).
|
||
|
||
### Mode strict
|
||
|
||
Quand `mode: strict`, une règle *non listée* dans `base.yaml` est considérée **désactivée** dès que le routage runtime est actif.
|
||
|
||
Ça force une approche “catalogue explicite” : tout ce qui tourne en prod est visible et gouvernable.
|
||
|
||
### Exemple
|
||
|
||
Activer les règles ionogramme uniquement si un code `E87.*` est détecté ou si la biologie mentionne Sodium/Potassium :
|
||
|
||
```yaml
|
||
triggers:
|
||
- id: TRG-ELECTROLYTES
|
||
enable_packs: [bio_electrolytes]
|
||
when_any:
|
||
codes_prefix: ["E87."]
|
||
lab_tests: ["sodium", "potassium"]
|
||
```
|