264 lines
6.0 KiB
Markdown
264 lines
6.0 KiB
Markdown
# Protocole de validation humaine
|
|
|
|
## 1. Objet
|
|
|
|
Ce protocole sert a valider la fonction d'anonymisation avant diffusion ou activation
|
|
d'une nouvelle version du moteur, d'une nouvelle regle ou d'une nouvelle famille de
|
|
documents.
|
|
|
|
Il ne remplace pas les tests automatiques. Il les complete sur le point qui compte
|
|
le plus pour le projet : **le document anonymise est-il conforme et exploitable ?**
|
|
|
|
## 2. Quand la validation humaine est obligatoire
|
|
|
|
La validation humaine est obligatoire si l'un des points suivants est vrai :
|
|
|
|
- modification du coeur d'anonymisation ;
|
|
- ajout ou modification d'une regle de masquage globale ;
|
|
- ajout ou modification d'une regle de preservation ;
|
|
- changement sur les noms patients, dates de naissance ou identifiants structurants ;
|
|
- nouvelle famille documentaire ;
|
|
- ecart constate sur le corpus synthetique complet ou le corpus reel annote ;
|
|
- demande explicite du responsable qualite ou du metier.
|
|
|
|
## 3. Entrees minimales requises
|
|
|
|
Avant la revue humaine, il faut disposer de :
|
|
|
|
- l'identifiant de version ou de commit ;
|
|
- la liste des changements ;
|
|
- les resultats des tests unitaires ;
|
|
- les resultats de la suite `tests/synthetic_regression/` ;
|
|
- les resultats de la suite `tests/synthetic_review/` ;
|
|
- les resultats du corpus reel annote si la modification est large ;
|
|
- pour chaque cas relu, le triplet :
|
|
- source ;
|
|
- attendu ;
|
|
- produit reel.
|
|
|
|
## 4. Roles
|
|
|
|
### 4.1 Operateur de revue
|
|
|
|
Prepare les elements de preuve :
|
|
|
|
- sorties texte ;
|
|
- diffs ;
|
|
- rapport d'audit ;
|
|
- resume des ecarts ;
|
|
- liste des regles impactees.
|
|
|
|
### 4.2 Relecteur metier
|
|
|
|
Verifie que :
|
|
|
|
- les donnees sensibles ne fuient pas ;
|
|
- le document reste lisible ;
|
|
- l'information utile au controle est preservee.
|
|
|
|
### 4.3 Responsable qualite / referent
|
|
|
|
Prend la decision finale :
|
|
|
|
- accepte ;
|
|
- accepte avec reserve ;
|
|
- refuse ;
|
|
- renvoie en correction.
|
|
|
|
## 5. Corpus a relire
|
|
|
|
### 5.1 Revue minimale
|
|
|
|
Pour une correction locale :
|
|
|
|
- les cas synthetiques impactes ;
|
|
- les cas complets de `tests/synthetic_review/` impactes ;
|
|
- au moins 2 documents reels proches du probleme corrige.
|
|
|
|
### 5.2 Revue standard
|
|
|
|
Pour une evolution de regles :
|
|
|
|
- tous les cas complets de `tests/synthetic_review/` ;
|
|
- un sous-ensemble reel annote representatif ;
|
|
- un echantillon de documents non annotes mais proches de la production.
|
|
|
|
### 5.3 Revue renforcee
|
|
|
|
Pour une release importante :
|
|
|
|
- toutes les familles documentaires critiques ;
|
|
- un echantillon reel relu manuellement pour chaque famille ;
|
|
- une analyse des nouveaux faux positifs et faux negatifs.
|
|
|
|
## 6. Support de revue
|
|
|
|
### 6.1 Pour les cas synthetiques complets
|
|
|
|
Utiliser :
|
|
|
|
- `tests/synthetic_review/cases/<cas>/test.txt`
|
|
- `tests/synthetic_review/cases/<cas>/expected.txt`
|
|
- `tests/synthetic_review/actual/<cas>/actual.txt`
|
|
- `tests/synthetic_review/actual/<cas>/diff.txt`
|
|
|
|
### 6.2 Pour les cas reels
|
|
|
|
Utiliser :
|
|
|
|
- le document source autorise ;
|
|
- le texte pseudonymise ;
|
|
- le PDF de sortie si disponible ;
|
|
- l'audit JSON/JSONL ;
|
|
- le rapport de fuite ;
|
|
- le rapport d'evaluation si le document est annote.
|
|
|
|
## 7. Checklist de revue dossier par dossier
|
|
|
|
### 7.1 Fuites interdites
|
|
|
|
Verifier l'absence de :
|
|
|
|
- nom et prenom du patient ;
|
|
- date de naissance ;
|
|
- adresse, code postal, ville de residence ;
|
|
- telephone et email ;
|
|
- IPP, NDA, RPPS, FINESS, OGC, numero d'examen, numero interne ;
|
|
- identifiants visibles en en-tete, pied de page, tableau ou bloc structure ;
|
|
- identifiants coupes sur plusieurs lignes ;
|
|
- variantes compactes ou prefixees type `N°1234567`.
|
|
|
|
### 7.2 Preservation fonctionnelle
|
|
|
|
Verifier que restent lisibles :
|
|
|
|
- la structure du document ;
|
|
- les services, actes et formulations metier legitimes ;
|
|
- les dates non sensibles si elles doivent etre conservees ;
|
|
- les libelles utiles au controle ;
|
|
- les phrases metier explicitement preservees.
|
|
|
|
### 7.3 Exploitabilite
|
|
|
|
Verifier que le document reste :
|
|
|
|
- comprehensible ;
|
|
- utilisable par le controle ;
|
|
- pas sur-caviarde au point de perdre sa valeur.
|
|
|
|
## 8. Classification des anomalies
|
|
|
|
### 8.1 Bloquant
|
|
|
|
- fuite de PII patient ;
|
|
- fuite d'un identifiant administratif critique ;
|
|
- regression majeure sur plusieurs familles ;
|
|
- regle active sans preuve de validation.
|
|
|
|
Decision :
|
|
|
|
- pas de release ;
|
|
- correction obligatoire.
|
|
|
|
### 8.2 Majeur
|
|
|
|
- faux positif important qui rend le document difficilement exploitable ;
|
|
- preservation non respectee sur un bloc metier cle ;
|
|
- comportement instable ou non explicable.
|
|
|
|
Decision :
|
|
|
|
- correction avant activation large ;
|
|
- ou activation limitee a un perimetre test.
|
|
|
|
### 8.3 Mineur
|
|
|
|
- ecart de forme sans perte de conformite ;
|
|
- difference de rendu mineure ;
|
|
- bruit d'audit sans impact document.
|
|
|
|
Decision :
|
|
|
|
- peut etre accepte si documente.
|
|
|
|
## 9. Decision de validation
|
|
|
|
Chaque revue doit se conclure par une decision explicite :
|
|
|
|
- `ACCEPTE`
|
|
- `ACCEPTE_AVEC_RESERVE`
|
|
- `REFUSE`
|
|
- `A_CORRIGER_PUIS_REVOIR`
|
|
|
|
La decision doit citer :
|
|
|
|
- la version revue ;
|
|
- le nom du relecteur ;
|
|
- la date ;
|
|
- les cas relus ;
|
|
- les anomalies ouvertes ;
|
|
- la portee de la decision.
|
|
|
|
## 10. Preuves a conserver
|
|
|
|
Conserver a minima :
|
|
|
|
- identifiant de commit ;
|
|
- resultat des tests automatiques ;
|
|
- liste des cas relus ;
|
|
- fiche de validation humaine ;
|
|
- rapport de diff ;
|
|
- decision signee ou attribuee nominativement.
|
|
|
|
## 11. Workflow operationnel recommande
|
|
|
|
### Etape 1
|
|
|
|
Executer les tests automatiques :
|
|
|
|
- `pytest ...`
|
|
- `python3 tools/run_synthetic_review_corpus.py`
|
|
|
|
### Etape 2
|
|
|
|
Preparer le lot de revue :
|
|
|
|
- cas impactes ;
|
|
- textes attendus ;
|
|
- textes reels ;
|
|
- synthese des ecarts.
|
|
|
|
### Etape 3
|
|
|
|
Faire la revue humaine avec la fiche standard.
|
|
|
|
### Etape 4
|
|
|
|
Classer chaque anomalie :
|
|
|
|
- bloquant ;
|
|
- majeur ;
|
|
- mineur.
|
|
|
|
### Etape 5
|
|
|
|
Prendre une decision de version :
|
|
|
|
- go ;
|
|
- go limite ;
|
|
- no go.
|
|
|
|
## 12. Regle simple de gouvernance
|
|
|
|
Une regle nouvelle n'est **jamais** activee directement en production si :
|
|
|
|
- elle n'a pas de cas de test associe ;
|
|
- elle n'a pas ete simulee ;
|
|
- personne n'a valide ses effets visibles.
|
|
|
|
## 13. Fichier associe
|
|
|
|
Le modele de fiche a remplir est dans :
|
|
|
|
- [fiche-validation-humaine-modele.md](/home/dom/ai/anonymisation/docs/fiche-validation-humaine-modele.md:1)
|