ApiBorne
Sommaire du guide

Notifier le système externe

Certaines organisations valident l'accueil avant de prévenir les équipes : la borne enregistre l'arrivée, puis un opérateur déclenche la notification depuis le Cockpit. Cette route est ce déclencheur — appelée par le serveur ApiBorne, pas par la borne.

POST/appointments/{appointmentId}/notify-external-system
Base : {editorBaseUrl}/api/apiborneIntegrationService/v1Auth : X-Kiosk-Auth-Key seuleRoute obligatoire

Pourquoi cette route existe

Dans le parcours standard, le check-in fait tout d'un coup : état du RDV, ticket, et notification des équipes (RIS, HL7, écran de salle…). Certains établissements veulent un contrôle humain entre les deux — vérifier la pièce d'identité, encaisser, compléter un dossier — avant que le patient n'apparaisse chez les manipulateurs. C'est l'« accueil RIS différé » : la borne accueille, l'opérateur notifie.

Le flux en trois temps

  1. La borne appelle le check-in avec deferExternalNotification: true. Vous faites tout le reste du check-in (état checkedIn, adoption du proposedTicket, anomalies) mais vous sursoyez à la notification ;
  2. le RDV expose awaitingExternalNotification: true tant que rien n'a été déclenché : le Cockpit présente ces patients à part, en attente d'une action de l'opérateur ;
  3. l'opérateur déclenche : le serveur ApiBorne appelle cette route, vous notifiez, et remettez awaitingExternalNotification à false.

Sémantique

  • Idempotence recommandée : un RDV déjà notifié renvoie 200 sans renotifier — l'opérateur peut cliquer deux fois ;
  • 409 si l'état du RDV rend la notification impossible : non accueilli, annulé… ;
  • RDV inconnu → 404 UNKNOWN_APPOINTMENT ;
  • réponse { "notified": true } — la notification a bien été émise.
Comme le statut et la connexion du personnel, l'appel vient du serveur ApiBorne : seul X-Kiosk-Auth-Key est requis, pas de device id.

Requête et réponse

bash
curl -sS -X POST "$BASE/appointments/apt-1001/notify-external-system" -H "X-Kiosk-Auth-Key: $KEY"
# → 200 { "notified": true }

Sans accueil différé chez vous

Vous notifiez toujours au check-in ? Ignorez deferExternalNotification (ne le rejetez jamais) et notifiez comme d'habitude : le défaut false est le comportement historique. Cette route reste obligatoire ; sa forme minimale conforme est 200 { "notified": true } idempotent — vous n'avez jamais rien en attente, awaitingExternalNotification reste absent.

Implémentation de référence

L'accueil différé n'est pas encore couvert par l'implémentation de référence : elle notifie au check-in et ignore le champ, ce qui est exactement la forme minimale décrite ci-dessus. Le handler de check-in montre où intervenir : après l'adoption du ticket, avant l'émission de la notification.