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
Par défaut, 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. 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. Optionnelles : les référentiels peuvent aussi être fournis en JSON statique, sans implémenter ces routes.
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.
Deux modes de connectivité, selon votre politique réseau
Votre serveur n'a pas à s'adapter à la borne : c'est la connectivité qui s'adapte à votre réseau. Le message essentiel pour votre DSI tient en une phrase — votre RIS n'a pas besoin d'être exposé sur Internet.
Mode direct — le défaut
La borne appelle votre serveur en direct, y compris sur une adresse locale de votre réseau (ex. 192.168.x.x) invisible depuis Internet. Le chiffrement de bout en bout, systématique, sécurise les échanges même sur une URL http interne : le parcours patient ne quitte pas votre établissement.
Mode relais chiffré — l'alternative
Si vos bornes ne peuvent pas joindre votre serveur directement, elles passent par le serveur Apiborne, qui relaie les appels tels quels. Les données patient y transitent chiffrées de bout en bout : le relais ne peut pas les lire (zero-knowledge), il ne fait que transporter.
Référentiels : routes HTTP ou JSON statique
Les référentiels — lieux, examens, praticiens, salles, types de documents — sont servis au choix par les routes de configuration du contrat, ou par un simple fichier JSON déposé dans l'administration. Dans ce second cas, l'éditeur peut se concentrer sur le seul parcours patient et ne jamais implémenter les routes de configuration.
Gardez votre RIS isolé : l'architecture bastion
Pour les DSI qui veulent pousser l'isolement jusqu'au bout, nous recommandons en mode direct une architecture en bastion : une machine dédiée, placée en DMZ ou dans un VLAN technique, héberge un programme qui expose le contrat Apiborne côté bornes et le traduit en interne vers votre système, dans son protocole natif — FHIR (Patient, Appointment, DocumentReference…) ou HL7 v2 (ADT, SIU…). Votre RIS ne subit aucune modification et reste seul dans son VLAN métier : le bastion est l'unique système autorisé à lui parler.
Pendant le parcours patient, les bornes joignent le bastion à travers un tunnel OpenVPN fourni par Apiborne : chaque borne et le bastion embarquent un certificat et montent leur tunnel vers le serveur VPN Apiborne — aucun VPN à monter côté DSI. Dans le tunnel, le chiffrement de bout en bout systématique rend le https superflu : le contrat peut circuler en http simple. Le serveur applicatif Apiborne, lui, reste hors du VPN : les bornes le joignent en HTTPS classique pour la configuration au démarrage et la numérotation des tickets, et il ne joint jamais le bastion — les référentiels sont fournis en JSON statique dans l'administration.
RIS jamais exposé
Ni sur Internet, ni même aux bornes : seul le bastion dialogue avec le RIS, à l'intérieur du VLAN métier.
Surface d'attaque minimale
Le VLAN métier est conservé tel quel ; le bastion est l'unique point de passage — un seul programme, un seul port.
Défense en profondeur
Isolation réseau (VLAN, VPN), chiffrement de bout en bout systématique et authentification par clé de compte et identifiant de borne se cumulent.
Tunnel OpenVPN fourni par Apiborne
Certificats déployés sur les bornes et le bastion, tunnel terminé par le serveur VPN Apiborne : aucun VPN à monter côté DSI — et le serveur applicatif, qui ne joint jamais le bastion (référentiels en JSON statique), reste hors du VPN.
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 ?
Par défaut, non : pendant le parcours patient, la borne appelle directement le serveur de l'éditeur — y compris sur une adresse locale du réseau de l'établissement, sans que le RIS soit exposé sur Internet. 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. Un mode relais existe pour les bornes qui ne peuvent pas joindre l'éditeur directement : le serveur Apiborne transporte alors les appels, mais les données patient y restent chiffrées de bout en bout et illisibles pour lui (relais zero-knowledge).
Faut-il exposer le serveur du RIS sur Internet pour connecter une borne ?
Non. En mode direct, la borne appelle le serveur de l'éditeur sur le réseau local de l'établissement, via une adresse interne invisible depuis Internet — au besoin à travers un serveur bastion en DMZ — joint par un tunnel OpenVPN fourni par Apiborne — qui traduit le contrat vers FHIR ou HL7, le RIS restant isolé dans son VLAN ; le chiffrement de bout en bout, systématique, sécurise les échanges même sur une URL http locale. À l'inverse, si la borne ne peut pas joindre l'éditeur, un relais chiffré zero-knowledge par le serveur Apiborne prend le relais. Les référentiels (lieux, examens, praticiens) peuvent en outre être fournis en JSON statique, sans exposer les routes de configuration.
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.