Notification readiness

« Le dossier est-il complet au sens de l'éditeur ? » La borne pose la question juste avant le check-in pour décider d'ajouter l'anomalie dossier incomplet.

GET/appointments/{appointmentId}/notification-readiness

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

Pourquoi cette route existe

Juste avant d'enregistrer l'arrivée, la borne vous demande votre avis : le dossier est-il complet au sens de VOTRE système (documents requis, prescripteur, règles internes) ? Une réponse négative ajoute l'anomalie « dossier incomplet » au check-in — visible du personnel d'accueil au Cockpit — sans jamais bloquer le patient. C'est le seul point du parcours où vos règles métier internes peuvent influencer l'accueil.

Sémantique

ready: true = le check-in ne signalera pas de dossier incomplet (documents requis présents, prescripteur renseigné… selon vos règles) ;
reason (absent quand ready vaut true) : notificationNotConfigured ou notificationDisabled ;
paramètres de contexte fournis par la borne : identifiedWithHealthCard, sequenceNumber, examId, otherExamIds — libres d'usage dans vos règles.

Requête et réponse

bash

curl -sS "$BASE/appointments/apt-1001/notification-readiness?identifiedWithHealthCard=true&sequenceNumber=1&examId=exam-77&otherExamIds=exam-78,exam-79" "${AUTH[@]}"
# → 200 { "ready": false, "reason": "notificationDisabled" }

Cette route doit toujours répondre — au pire { "ready": true }, jamais 501 : la borne bloque le parcours sur une réponse négative ou absente. Un éditeur sans notion de notification renvoie simplement toujours true.

Implémentation de référence

src/app/api/apiborneIntegrationService/v1/appointments/[appointmentId]/notification-readiness/route.ts → — la démo n'a pas de pipeline de notification : elle répond toujours { "ready": true }, l'implémentation minimale conforme.