Cartes et scénarios de test
Le mode test ne touche ni l’Assurance Maladie ni une vraie carte. Chaque scénario se choisit par son identifiant et rend toujours le même résultat.
curl https://api.ophelix.fr/v1/test-helpers/card-reads \
-H "Authorization: Bearer sk_test_…" \
-H "Content-Type: application/json" \
-d '{"card_type": "vitale", "scenario": "vitale_rights_closed"}'GET /v1/test-helpers/scenarios donne la liste à jour. Ces routes refusent une clé de production : test_mode_only.
Un scénario sert aussi de carte aux ressources : POST /v1/practitioners avec {"card": "cps_doctor"} crée un praticien, POST /v1/coverages avec {"source": "vitale_card", "card": "vitale_ok"} crée un patient et ses droits.
Cartes Vitale
| Scénario | Résultat |
|---|---|
vitale_ok | Assuré aux droits ouverts |
vitale_exempted | Assuré exonéré du ticket modérateur |
vitale_child | Enfant ayant droit, sur la carte de son parent |
vitale_rights_closed | Droits fermés : la validation refuse la facture |
vitale_unreadable | Carte illisible : card_unreadable |
Cartes CPS
| Scénario | Résultat |
|---|---|
cps_doctor | Médecin généraliste, une situation d’exercice |
cps_nurse_multi | Infirmier, deux situations d’exercice |
cps_adeli | Orthophoniste identifié par son numéro ADELI |
cps_replacement | Remplaçant, qui facture sous la situation du remplacé |
cps_health_center | Médecin salarié d’un centre de santé |
cps_no_situation | Carte sans situation de facturation : le praticien reste à compléter |
cps_blocked | Carte bloquée après trois codes faux : card_blocked |
Factures de test
POST /v1/test-helpers/claims lit deux cartes et ouvre un brouillon avec une prestation fictive. Par défaut, cps_doctor et vitale_ok. {"patient_card": "vitale_rights_closed"} donne une facture que la validation refuse. Voir Factures.
Les parts AMO, AMC et assuré viennent d’un taux fictif en mode test : ne vous en servez pas comme référence.
Retours
POST /v1/test-helpers/claims/{id}/returns avec {"scenario": "…"}, sur une facture sécurisée.
| Scénario | Depuis | Résultat |
|---|---|---|
arl_positive | secured, batched, transmitted | acknowledged, en passant par batched et transmitted |
arl_negative | secured, batched, transmitted | rejected, rejection_code à arl_negative |
payment | acknowledged | paid |
partial_payment | acknowledged | partially_paid, la moitié de ce que les organismes doivent |
rejection | acknowledged | rejected, rejection_code à rejected_by_fund |
Un retour hors de ce cycle répond 409 conflict. Chaque état traversé émet son événement.
Toutes ces données sont fictives. Un NIR de test commence par 9, un chiffre qu’aucun NIR réel ne porte.
Cartes simulées dans l’agent
Sur un poste appairé en mode test, l’écran Scénarios de l’agent insère une CPS et une carte Vitale simulées, et simule une panne de la liaison. Le poste remonte alors un lecteur simulé à deux fentes : GET /v1/workstations, les événements reader.connected, card.inserted et card.removed et le tableau de bord se comportent comme avec un vrai lecteur. Une carte simulée ne touche aucune carte réelle. Un poste de production n’a pas cet écran. Voir Postes.