Check-in

L'opération critique du parcours : enregistrer l'arrivée du patient, déclencher la suite chez vous (salle d'attente, notification des équipes) et renvoyer le ticket d'appel.

POST/appointments/{appointmentId}/check-in

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

Pourquoi cette route existe

C'est l'aboutissement de tout le parcours : l'instant où l'arrivée du patient devient un fait chez vous — passage en salle d'attente, notification des équipes, ticket d'appel partagé avec le Cockpit et les écrans. C'est aussi l'appel le plus exigeant du contrat : idempotence obligatoire (la borne rejoue sur timeout), adoption du proposedTicket, gestion du multi-RDV — d'où les sections dédiées ci-dessous.

Sémantique

anomalyCodes : codes métier vendor-neutral constatés pendant le parcours (retard, dossier incomplet, prescripteur manquant…). Le référentiel vient de la configuration borne — stockez-les tels quels, n'interprétez que ceux que vous connaissez.
documentsComplete (booléen nullable) : dossier documentaire complet au moment du check-in — tous les types requis fournis. Absent/null quand la borne ne gère pas les documents pour ce parcours. Vous pouvez le tracer comme indicateur « dossier complet/incomplet » à l'arrivée.
Sans file d'appel chez vous : répondez 200 {} — la borne génère un ticket local si sa configuration le demande.

Idempotence : la règle d'or

La borne peut rejouer l'appel après un timeout réseau (les 5xx et erreurs réseau sont retentés). Si le RDV est déjà check-in, renvoyez 200 avec le ticket existant — jamais un doublon. Réservez 409 ALREADY_CHECKED_IN aux états réellement incompatibles (RDV annulé, terminé).

proposedTicket

Quand la configuration est portée par ApiBorne : le numéro est réservé AVANT votre check-in, vous l'adoptez, tout le monde affiche le même ticket.

Quand la configuration borne est portée par ApiBorne, la borne réserve un numéro auprès du serveur ApiBorne avant votre check-in et vous le transmet dans proposedTicket. Vous pouvez l'adopter comme numéro d'appel et devez l'accepter sans erreur si vous ne l'adoptez pas.

Adoptez-le — c'est ce que fait l'implémentation de référence : le ticket imprimé par la borne, votre agenda et le Cockpit ApiBorne affichent alors le même numéro.

Parcours multi-RDV

Quand le patient a plusieurs RDV le même jour, la borne fait un appel par RDV : le premier porte sequence.number: 1 (RDV principal), les suivants référencent le principal via mainAppointmentId. linkedAppointmentIds et otherExamIds donnent le contexte du groupe, otherAppointmentsReadyForCheckIn aide au regroupement de vos notifications.

Requête et réponse

bash

curl -sS "$BASE/appointments/apt-1001/check-in" "${AUTH[@]}" -d '{
  "identifiedWithHealthCard": true,
  "attendantCheckIn": false,
  "anomalyCodes": ["PR"],
  "documentsComplete": true,
  "sequence": { "number": 1, "count": 1 },
  "examId": "exam-77",
  "linkedAppointmentIds": [],
  "otherExamIds": [],
  "proposedTicket": { "number": 12, "formattedNumber": "SC-12" }
}'
# → 200 { "ticketNumber": 12, "ticketNumberFormatted": "SC-12" }

Réponse : ticketNumber / ticketNumberFormatted (nullables si vous ne gérez pas de file d'appel). Après un 409, la borne affiche un message dédié au patient.

Implémentation de référence

src/app/api/apiborneIntegrationService/v1/appointments/[appointmentId]/check-in/route.ts → — idempotence par état, adoption du proposedTicket, repli en numérotation locale, stockage des anomalies et du documentsComplete. Voir aussi la notification readiness appelée juste avant.