ApiBorne
Sommaire du guide

Le parcours borne en 7 étapes

La borne appelle directement votre serveur pendant l'accueil du patient. Voici l'ordre réel des opérations — c'est la colonne vertébrale de toute l'intégration.

Le principe

Pendant le parcours patient, la borne dialogue uniquement avec votre serveur, sur le base path imposé /api/apiborneIntegrationService/v1. Le serveur ApiBorne n'intervient qu'au démarrage de la borne (chargement de sa configuration) et pour la numérotation des tickets — jamais votre serveur ne doit le rappeler pendant un parcours (voir context.config).

Côté matching (quel message afficher, quels critères poser, quelles anomalies lever), tout est calculé par la borne à partir de sa configuration : votre serveur n'implémente aucune règle d'affichage.

Les 7 étapes du parcours

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.
  1. 1Identification. POST /patients/identify (carte de santé ou saisie manuelle) ou GET /appointments/by-code/{code} quand le patient scanne le QR de sa convocation.
  2. 2Correction des données administratives. PATCH /patients/{patientId} puis rechargement canonique via GET /appointments/{id}.
  3. 3État documentaire. GET /appointments/{id}/documents — documents présents et types attendus ; la borne calcule les manquants.
  4. 4Dépôt de documents. POST /appointments/{id}/documents (et DELETE de l'ancien en cas de remplacement).
  5. 5Prescripteur. PUT /appointments/{id}/prescriber — si le patient valide une proposition issue de l'analyse d'ordonnance (analysis).
  6. 6Le dossier est-il complet ?. GET /appointments/{id}/notification-readiness — la borne en déduit l'anomalie « dossier incomplet ».
  7. 7Check-in. POST /appointments/{id}/check-in — enregistrement de l'arrivée, ticket d'appel en retour. Un appel par RDV si le patient en a plusieurs le même jour.

Toutes les routes sont obligatoires

Cinq routes suffisent au parcours minimal : identify, by-code, GET appointment, check-in et notification-readiness — commencez par elles. Mais les 12 routes du contrat sont obligatoires : pas de routes optionnelles, pas de déclaration de support, donc pas d'exception dans la configuration ApiBorne. Une fonctionnalité que vous n'avez pas se traduit par l'implémentation minimale conforme, en quelques lignes.

Les formes minimales prévues : listes de documents vides (la borne saute le flow), 204 sans effet (PATCH patient, prescripteur), 404 systématique (codes de convocation non gérés), 401 systématique (pas de comptes personnel), toujours { "ready": true } (pas de notion de notification), check-in 200 {} sans ticketNumber (pas de file d'appel), analysis omis (pas d'analyse d'ordonnance).