RDV par identifiant

Même réponse que by-code (patient + appointment + otherAppointments), mais par identifiant déjà connu : rechargement après un PATCH patient, mode simulation, et re-vérification par le serveur ApiBorne.

GET/appointments/{appointmentId}

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

Pourquoi cette route existe

La borne et le serveur ApiBorne ont régulièrement besoin de recharger un RDV qu'ils connaissent déjà : après une modification patient (le PATCH répond 204 sans corps), au retour d'un écran, ou côté serveur pour re-vérifier un ticket affiché au Cockpit. Cette route est la source canonique de l'état d'un RDV — même forme de réponse que by-code, sans repasser par une recherche.

Sémantique

La borne appelle cette route pour obtenir les données canoniques après une modification (PATCH /patients répond 204 sans corps, le rechargement se fait ici). L'identifiant est celui que vous avez renvoyé dans une réponse précédente — opaque et stable pendant tout le parcours.

Champs ajoutés en 1.1

L'objet appointment (même forme pour identify, by-code, by-ticket et cette route) s'enrichit de champs optionnels, tous nullables :

practitionerLabel et roomLabel : libellés affichables du praticien exécutant et de la salle. Ils complètent practitionerId / roomId — un éditeur sans référentiel praticiens peut ne transporter que le libellé. Affichés tels quels dans le Cockpit, jamais utilisés pour du matching ;
endDate (ISO 8601 avec offset) : permet d'afficher la durée du RDV ; absente, la durée n'est pas affichée ;
status accepte closed : done = soin terminé, patient en attente de sortie ; closed = passage clos, le RDV quitte le tableau d'appel (voir statut d'un RDV) ;
awaitingExternalNotification : le patient est accueilli mais la notification des équipes n'a pas encore été déclenchée (check-in reçu avec deferExternalNotification). Le Cockpit présente ces RDV à part pour qu'un opérateur déclenche la notification. Absent ou false : rien en attente.

Requête

bash

curl -sS "$BASE/appointments/apt-1001" "${AUTH[@]}"

Points d'attention

Le serveur ApiBorne utilise aussi cette route pour re-vérifier les tickets affichés au Cockpit (réconciliation) : renvoyez un status et un startDate exacts — un RDV annulé chez vous disparaît ainsi automatiquement du Cockpit.

L'app patient Pass recharge aussi un RDV par cette route, via le serveur ApiBorne et sans date de naissance : l'identifiant, opaque et non énumérable, fait office de preuve de possession. Le serveur ApiBorne ne relaie au navigateur que id, firstName et lastName du patient — jamais birthDate, socialSecurityId, contacts ni adresse (voir RDV par ticket). Raison de plus pour que vos identifiants de RDV ne soient jamais séquentiels.

Implémentation de référence

src/app/api/apiborneIntegrationService/v1/appointments/[appointmentId]/route.ts →