Contexte de configuration

Toute la configuration des bornes vit dans l'admin ApiBorne ; la borne la charge à son démarrage. Pendant le parcours patient, la borne appelle votre serveur en direct — or certaines de vos décisions dépendent de cette configuration (exemple : faut-il tenter des recherches croisées à deux champs quand l'identification stricte ne trouve rien ?).

Plutôt que de vous obliger à interroger le serveur ApiBorne (avec des identifiants, un cache, une invalidation…), la borne pousse le sous-ensemble utile de sa configuration dans chaque écriture. Votre serveur reste totalement sans état vis-à-vis d'ApiBorne : il lit context.config, applique, et c'est tout.

{
  "context": {
    "locationId": "loc-42",
    "config": {
      "identification": { "twoFieldsIdentification": true },
      "documents": {},
      "checkIn": {}
    },
    "vendorData": { "internalAppointmentKey": 123456 }
  }
}

• locationId — le lieu (site) depuis lequel la borne appelle : c'est l'id d'un de vos lieux (référentiel /config/office-places) ;
• config — le sous-ensemble strict de configuration consommé par l'éditeur, découpé en trois sections (identification, documents, checkIn), chacune optionnelle ;
• vendorData — vos propres données opaques, renvoyées inchangées (voir le guide vendorData : la clé de restitution est l'id de l'entité visée par l'appel).

Seules les écritures (POST/PATCH/PUT) portent un corps, donc un context — les GET n'en ont pas.

Le contrat V1 ne définit qu'un seul réglage effectif — identification.twoFieldsIdentification — dont l'effet attendu chez vous est précis :

POST /patients/identify
{ "context": { "config": { "identification": { "twoFieldsIdentification": true } } },
  "criteria": { "lastName": "DURAND", "firstName": "MARIE", "birthDate": "1980-05-12" } }

→ recherche stricte (les TROIS critères combinés) : 0 résultat
   (ex. prénom enregistré « Marie-Anne » chez vous : le prénom saisi ne matche pas)
→ twoFieldsIdentification = true, alors TENTER les croisements à deux champs :
   nom + date de naissance, prénom + date, nom + prénom
   (ici nom + date suffit : la patiente est retrouvée malgré le prénom divergent)
→ twoFieldsIdentification = false (ou absent) : s'arrêter là, répondre { "patients": [] }

Ce booléen correspond au réglage « identification à deux champs » de l'admin ApiBorne : l'établissement choisit d'élargir ou non la recherche, et votre implémentation applique ce choix sans redéploiement ni configuration chez vous — c'est tout l'intérêt du mécanisme.

Les sections documents et checkIn sont aujourd'hui des objets vides : elles réservent l'emplacement des réglages futurs de ces deux familles.

Pourquoi cette règle est stricte : la configuration visible dans l'admin ApiBorne doit être exactement celle appliquée pendant le parcours. Si vous mainteniez votre propre copie (ou un cache), un réglage changé dans l'admin s'appliquerait chez vous avec retard ou jamais — et le support passerait son temps à comparer deux sources. Avec le push par appel, un changement dans l'admin est effectif au parcours suivant, sans rien toucher côté éditeur.

Si context.config est absent, utilisez votre propre base de configuration (mode legacy direct) : le champ n'est pas garanti, votre implémentation doit avoir un comportement par défaut raisonnable.

Les sections documents et checkIn sont réservées aux évolutions mineures du contrat : ignorez toute propriété inconnue sans lever d'erreur. C'est ce qui permet d'enrichir le contrat sans casser les intégrations existantes — un éditeur qui validerait strictement le schéma du context casserait à la première évolution mineure.