Patients
Un patient (Patient, pat_…) est une personne soignée. Aucune route ne le crée directement : il naît de la lecture de ses droits.
Droits de clé : patients:read pour le lire, patients:write pour lire ses droits.
Cycle de vie
Un patient n’a pas d’état. La lecture d’une carte retrouve le patient déjà connu, et met à jour son identité si elle a changé. Ophelix le reconnaît sans jamais exposer son NIR.
Je veux…
| Je veux… | Appel |
|---|---|
| Créer un patient | POST /v1/coverages, il naît avec sa première lecture |
| Lire un patient | GET /v1/patients/{id} |
| Les lister | GET /v1/patients |
| Lire ses droits successifs | GET /v1/patients/{id}/coverages |
| Voir ses factures | GET /v1/claims?patient=pat_… |
Ce qui en sort
first_name, last_name, birth_date, rank et quality, et l’assuré qui ouvre droit quand ce n’est pas le patient. Du NIR, seuls les quatre derniers chiffres : nir_last4.
Chaque patient rendu laisse une trace dans le journal d’audit de votre organisation, y compris par expand[]=patient. Ne lisez que ce dont vous avez besoin.
Événements
| Type | Quand |
|---|---|
patient.updated | Son identité a changé à une nouvelle lecture |
patient.updated porte changed, le nom des champs modifiés, sans leur valeur : un événement ne porte jamais de donnée de santé. Relisez le patient.
Pièges
- Il n’y a pas d’événement
patient.created. Écoutezcoverage.retrieved, qui nomme le patient. - Un enfant ayant droit a son propre patient, avec son
ranketquality: child.vitale_childle simule. - Un patient de test n’existe pas pour une clé de production, et l’inverse.