ApiBorne
Sommaire du guide

Identifier un patient

Le premier appel du parcours : rechercher les patients correspondant aux critères (lecture carte de santé ou saisie manuelle) et renvoyer, pour chacun, ses rendez-vous du jour.

POST/patients/identify
Base : {editorBaseUrl}/api/apiborneIntegrationService/v1Auth : X-Kiosk-Auth-Key + X-Kiosk-Device-IdRoute obligatoire

Pourquoi cette route existe

C'est la porte d'entrée du parcours : le patient lit sa carte de santé ou saisit ses informations, et la borne doit retrouver chez vous LE bon patient et ses RDV du jour. Tout le reste (vérification d'identité, documents, check-in) s'appuie sur les identifiants renvoyés ici — c'est l'étape 1 de la séquence ci-dessous.

C'est aussi l'appel le plus sensible du contrat : trop laxiste, il expose les RDV d'un homonyme ; trop strict, il renvoie le patient au guichet. D'où les règles de combinaison des critères qui suivent.

Séquence du parcours patient : identification, correction, documents, prescripteur, readiness, check-in.Borne ApiBorneparcours patientVotre serveur/api/apiborneIntegrationService/v11 · POST /patients/identify (ou GET /appointments/by-code/{code})patients + RDV du jour2 · PATCH /patients/{id} puis GET /appointments/{id}correction des données, rechargement canonique3 · GET /appointments/{id}/documentsdocuments présents + types attendus → manquants4 · POST /documents (DELETE puis POST si remplacement)pages base64 — ≥ 10 Mo acceptés, réponse < 60 s5 · PUT /appointments/{id}/prescriber (optionnel)si le patient valide une proposition d'analyse6 · GET /appointments/{id}/notification-readiness{ "ready": true } — toujours répondre7 · POST /appointments/{id}/check-in (un appel par RDV)ticket d'appel — idempotent au rejeuÉtapes 2 à 5 : seulement si nécessaires (données à corriger, documents manquants, analyse fournie)
Le parcours complet, dans l'ordre réel des appels. Chaque flèche pleine est une requête de la borne ; les pointillés sont vos réponses.

Sémantique

  • Tous les critères fournis sont combinés ; le NIR prime quand il est présent et doit tolérer les espaces. Attention aux cartes famille : le NIR seul est partagé par tous les bénéficiaires — ce sont les critères d'identité qui les discriminent.
  • Aucun résultat n'est pas une erreur : 200 avec patients: [].
  • Un patient trouvé sans RDV du jour est renvoyé avec appointments: [] (la borne affiche un message adapté).
  • Avec config.identification.twoFieldsIdentification: true, tentez aussi les recherches croisées à deux champs (nom+date, prénom+date, nom+prénom) quand la recherche stricte ne donne rien.

Requête

bash
curl -sS "$BASE/patients/identify" "${AUTH[@]}" -d '{
  "context": { "locationId": "loc-42", "config": { "identification": { "twoFieldsIdentification": true } } },
  "criteria": { "socialSecurityId": "280057510612345", "lastName": "DURAND", "firstName": "MARIE", "birthDate": "1980-05-12" }
}'

birthDate en ISO YYYY-MM-DD. Les variables $BASE et $AUTH sont définies dans le démarrage rapide.

Réponse

200
{
  "patients": [
    {
      "patient": {
        "id": "pat-77", "firstName": "Marie", "lastName": "Durand",
        "birthDate": "1980-05-12", "sex": "female",
        "email": "marie.durand@example.com", "mobilePhone": "+33612345678",
        "address": { "line1": "12 rue des Lilas", "line2": null, "zipCode": "75011", "city": "Paris" },
        "socialSecurityId": "280057510612345", "heightCm": 168, "weightKg": 62,
        "referringPractitioner": { "name": "MARTIN Paul", "rppsId": "10101010101" },
        "vendorData": { "patientKey": 77 }
      },
      "appointments": [
        {
          "id": "apt-1001", "patientId": "pat-77",
          "startDate": "2026-07-19T10:30:00+02:00", "convocationDate": "2026-07-19T10:15:00+02:00",
          "locationId": "loc-42", "examId": "exam-77", "examTypeId": "examtype-9",
          "examLabel": "IRM lombaire", "status": "scheduled",
          "prescriber": null, "ticketNumber": null, "ticketNumberFormatted": null,
          "managementPageUrl": "https://ris.example.com/p/apt-1001",
          "vendorData": { "appointmentKey": 1001 }
        }
      ]
    }
  ]
}

Points d'attention

Sécurité : ne renvoyez jamais des RDV appartenant à des patients d'identité manifestement différente de celle demandée — dans le doute, patients: []. Limitez raisonnablement le nombre de patients renvoyés (10 max recommandé).

Ne proposez que des RDV éligibles au parcours : un RDV cancelled ne doit pas apparaître dans appointments — la borne ferait dérouler tout le flux au patient pour échouer au check-in.

Implémentation de référence

src/app/api/apiborneIntegrationService/v1/patients/identify/route.ts → — recherche multi-critères combinés (SQL) avec normalisation du NIR, cap à 10 résultats, RDV annulés exclus.