Intégrer une borne d'accueil patient à votre système de santé
Une borne d'accueil ne vaut que par sa connexion au logiciel métier : RIS, système de gestion médicale ou plateforme de gestion de rendez-vous. Voici comment cette intégration fonctionne chez Apiborne — avec un contrat REST public que tout éditeur peut implémenter et valider en autonomie.
Chez Apiborne, nous avons fait le choix d'ouvrir la porte. N'hésitez pas : entrez dans l'aventure.
Pourquoi l'intégration est le vrai sujet d'un projet de borne
Sans connexion au système de l'établissement, une borne d'accueil n'est qu'un écran isolé : elle ne reconnaît pas le patient, ne retrouve pas son rendez-vous et n'informe personne de son arrivée. Toute la valeur d'une borne d'accueil patient vient de sa capacité à dialoguer en temps réel avec l'agenda et le dossier administratif du logiciel métier.
C'est pourquoi nous avons fait de l'intégration un produit à part entière : un contrat d'API baptisé Kiosk Integration Contract, documenté publiquement sur developers.apiborne.com, que les éditeurs de RIS et de logiciels de gestion de rendez-vous implémentent sans dépendre d'un développement spécifique de notre côté.
12
opérations REST dans le contrat
5
routes pour un premier parcours
3.0.3
spec OpenAPI, source de vérité
41
types de documents standard
Une architecture directe : la borne parle à votre serveur
Pendant le parcours patient, la borne appelle directement le serveur de l'éditeur : identité, rendez-vous et documents transitent de la borne vers le système de l'établissement, sans intermédiaire. Le serveur Apiborne n'intervient qu'au démarrage de la borne et pour la numérotation des tickets. Trois familles de routes structurent le contrat :
Routes de communication
Borne → votre serveur
Les opérations appelées par la borne pendant le parcours : identifier le patient, lire le rendez-vous, corriger les données administratives, déposer des documents, enregistrer l'arrivée avec ticket.
Routes de configuration
Apiborne → votre serveur
Six routes GET exposant vos référentiels — lieux, types d'examens, praticiens, salles, types de documents — utilisées pour paramétrer les bornes et vérifier l'intégration.
Services serveur
Votre serveur → Apiborne
Le canal sortant : votre système émet un ticket pour une arrivée pointée dans l'agenda, pousse les changements de statut de rendez-vous vers le Cockpit ou déclenche une réimpression.
Authentification : deux en-têtes HTTP
Une clé de compte partagée et l'identifiant de la borne appelante, tous deux disponibles dans l'interface d'administration. La même clé sert aux trois familles de routes, les erreurs sont typées, et le guide dédié du portail couvre CORS et le multi-sites.
Ce que l'intégration fait vivre au patient
Chaque étape du parcours sur la borne correspond à des appels du contrat vers le logiciel de gestion de rendez-vous. Le même contrat alimente aussi Apiborne Pass, le prolongement du parcours sur le smartphone du patient.
Identification
Carte de santé, QR code de convocation ou saisie assistée : la borne interroge le système pour retrouver le patient.
Vérification du rendez-vous
Le rendez-vous est lu dans l'agenda du logiciel métier, avec ses horaires, son examen et son lieu.
Données administratives
Le patient corrige ses coordonnées ; la mise à jour est renvoyée au dossier administratif.
Documents
Ordonnance, carte de mutuelle, pièces requises : les documents sont numérisés et transmis au dossier.
Check-in et ticket
L'arrivée est enregistrée dans le système et la borne délivre un ticket d'appel au patient.
Notification du secrétariat
Le personnel suit les arrivées en temps réel dans le Cockpit ou son logiciel habituel.
Implémenter et valider en autonomie
Le portail développeurs ne se limite pas à la description du contrat : il outille chaque étape, du premier appel de test jusqu'au rapport de conformité.
Exemples prêts à copier
Chaque route est illustrée par des appels curl complets, cas d'erreur compris, pour auto-tester un serveur en local dès le début du développement.
Sonde config-check
L'administration Apiborne interroge automatiquement les routes de configuration et affiche un indicateur de santé ; la configuration des bornes se déverrouille quand les référentiels répondent.
Banc de test des endpoints
Chaque opération du contrat peut être exercée avec vos propres données d'entrée, avec un rapport de conformité détaillé par appel.
Implémentation de référence open-source
Le repo public ApiborneDemoImpl implémente tout le contrat en TypeScript lisible : une vraie borne peut dérouler un parcours complet contre lui.
github.com/ApiBorne/ApiborneDemoImplQuestions fréquentes sur l'intégration
Comment connecter une borne d'accueil à un logiciel de gestion de rendez-vous ?
La connexion se fait par une API REST : le logiciel de gestion de rendez-vous expose un ensemble de routes documentées (identification du patient, lecture du rendez-vous, dépôt de documents, enregistrement de l'arrivée) que la borne appelle pendant le parcours patient. Chez Apiborne, ce contrat d'intégration — le Kiosk Integration Contract — est documenté publiquement sur developers.apiborne.com, avec une spécification OpenAPI et des exemples d'appels prêts à tester.
Faut-il un développement spécifique d'Apiborne pour chaque intégration ?
Non. Le contrat d'intégration est le même pour tous les éditeurs : c'est le logiciel métier qui implémente les routes du contrat, à son rythme, sans dépendre d'un développement côté Apiborne. Un banc de test et une sonde de configuration intégrés à l'administration permettent de valider la conformité de l'implémentation en autonomie, avec un rapport détaillé par appel.
Quels systèmes de santé sont compatibles avec les bornes Apiborne ?
Les bornes fonctionnent avec les RIS (systèmes d'information radiologique) déjà intégrés — comme EDL Xplore — et avec la plateforme EasyDoct pour la prise de rendez-vous en ligne. Au-delà de ces intégrations existantes, tout éditeur de logiciel de gestion médicale ou de gestion de rendez-vous peut implémenter le contrat public : la borne se comporte alors exactement comme avec les intégrations historiques.
Les données patients transitent-elles par les serveurs d'Apiborne ?
Pendant le parcours patient, la borne appelle directement le serveur de l'éditeur : identité, rendez-vous et documents transitent de la borne vers le système de l'établissement sans intermédiaire. Le serveur Apiborne n'intervient qu'au démarrage de la borne (chargement de sa configuration) et pour la numérotation des tickets d'appel. Cette architecture limite par conception la circulation des données de santé.
Combien de routes faut-il implémenter pour démarrer une intégration ?
Le contrat compte 12 opérations couvrant tout le parcours patient, mais 5 routes suffisent pour un premier parcours complet : identification du patient, lecture du rendez-vous, liste des documents, enregistrement de l'arrivée (check-in avec ticket) et vérification du dossier. Les autres opérations admettent une implémentation minimale conforme tant que la fonctionnalité n'est pas gérée par le logiciel.
Chez Apiborne, nous avons fait le choix d'ouvrir la porte
Là où d'autres gardent leur contrat d'intégration sous NDA, nous l'avons publié. Documentation complète en libre accès, spécification OpenAPI téléchargeable, banc de test avec rapport de conformité, implémentation de référence open-source : rien n'est caché, rien n'est verrouillé.
N'hésitez pas : entrez dans l'aventure. Éditeur, 5 routes suffisent pour un premier parcours complet. Établissement, parlez-nous de votre logiciel métier — nous vous dirons où en est son intégration.