Documentation API pour intégrer les données d'appareils
Glucomètres et montres connectées vers un dossier patient électronique : endpoints REST, payloads JSON et XML, authentification OAuth et profils FHIR côté suisse. De quoi tester un premier flux avant de planifier un déploiement.
Vue d'ensemble de l'architecture
L'API Vitalink reçoit les données d'appareil, les normalise, puis les expose ou les écrit vers votre système cible. Elle s'appuie sur les conventions REST et sur des ressources FHIR. Votre application cliente dialogue avec nos endpoints; nous gérons la conversion et la normalisation, ce qui vous évite d'écrire un parseur par fabricant.
Glucomètre ou montre qui émet ses mesures; vous ne modifiez rien de son côté.
Reçoit, convertit et normalise les mesures en ressources FHIR prêtes à lire.
Appelle les endpoints et décide de la suite: affichage, écriture ou file d'attente.
Dossier patient électronique, ou une couche middleware que vous préférez garder maître.
Endpoints REST principaux
Lecture · écriture · rechercheLes routes suivent les conventions web modernes pour récupérer et écrire des ressources. Chaque endpoint précise les paramètres acceptés et les codes de réponse. Les noms de routes et les schémas exacts figurent dans la référence complète; la liste ci-dessous sert à vous orienter.
Les droits d'accès à ces routes sont cadrés par OAuth et par votre architecture clinique; la référence complète reprend chaque paramètre et chaque code de réponse.
Authentification OAuth
L'accès aux endpoints passe par OAuth. Vous obtenez un jeton, puis l'utilisez pour vos requêtes. Les périmètres d'autorisation sont définis par rôle et par ressource, ce qui limite ce qu'un client peut lire ou écrire. Les droits d'accès doivent être pensés avec votre architecture clinique et votre environnement de déploiement, dès la phase conceptuelle.
Les flux de mesure circulent chiffrés et les journaux d'accès restent rattachés au périmètre autorisé de chaque client. Le détail des algorithmes, des clés et de la conservation est décrit sur la page sécurité et chiffrement, avec la répartition des responsabilités entre Vitalink et votre établissement.
Voir la page sécurité et chiffrementFormats JSON et XML
FHIR s'appuie sur REST, JSON et XML selon la documentation consultée. Vous choisissez le format adapté à votre stack.
- JSON Confortable pour les applications web et mobiles, et pour les tests rapides.
- XML Encore présent dans certains environnements hospitaliers et outils anciens.
- Même ressource Les deux formats respectent la même structure; le choix n'engage pas le modèle de données.
Profils FHIR et ressources
Ressources par type de mesureUne mesure de glycémie se représente via une ressource d'observation, rattachée à un patient et à un appareil. Les séries temporelles issues d'une montre demandent une structure adaptée au volume. Vitalink documente les ressources utilisées pour chaque type de mesure; vous alignez ensuite ces ressources sur les profils de votre établissement.
Glycémie ponctuelle
Une mesure datée, reliée à un patient et à un appareil identifiés. C'est le cas le plus direct à valider dans l'environnement de test.
- Ressource d'observation et ses composants
- Unité de mesure normalisée avant écriture
- Lien vers l'appareil émetteur
Série d'une montre
Plusieurs points rapprochés dans le temps: la structure de transport compte autant que la mesure elle-même, surtout sur de longues périodes.
- Envoi par lots plutôt qu'appel par mesure
- Fenêtre temporelle explicite dans la requête
- Ordre et horodatage conservés
Vos profils
Un profil CH Core ou un profil interne de l'établissement: vous gardez la main sur la version finale des ressources.
- Alignement sur le profil cible de l'hôpital
- Champs obligatoires identifiés avant l'écriture
- Contrôle de conformité côté votre pipeline
Normalisation des données d'appareils
Les appareils grand public varient en unités, codes et formats de date. L'API applique une normalisation sémantique avant l'écriture. Sans cette étape, chaque intégration devient une traduction à part entière.
Les unités de mesure sont ramenées à un référentiel unique avant l'écriture, pour comparer des mesures issues de fabricants différents.
Un même type de mesure doit porter le même code, sinon votre dossier patient reçoit des séries éclatées.
Les formats de date et de fuseau sont unifiés, ce qui évite les décalages silencieux dans les séries longues.
Les codes cliniques sont alignés sur des référentiels reconnus comme SNOMED CT, que votre établissement emploie déjà ou non.
La normalisation ne s'arrête pas aux unités. Les codes d'observation, les types d'appareil et les référentiels cliniques doivent être alignés sur votre cible. Vitalink documente les terminologies prises en charge et la façon de mapper vos codes; vous gardez la main sur le profil final.
Écriture dans l'EHR et middleware
Vous pouvez écrire directement dans votre système ou passer par une couche middleware. Cette couche absorbe les flux, applique les règles d'autorisation et alimente le système cible. Elle évite de disperser la logique d'appareil dans plusieurs services. Le choix dépend de votre architecture et de vos contraintes de conformité.
Écriture directe quand votre équipe maîtrise déjà le profil cible et les règles d'accès. Passage par middleware quand plusieurs sources d'appareils, plusieurs unités de soins ou plusieurs systèmes cibles doivent cohabiter.
Tests, environnements et versionnage
Un environnement de test permet de valider vos flux avant la mise en production. Vous y reproduisez les cas d'usage: glycémie ponctuelle, série temporelle, métadonnées patient. Les réponses y suivent le même format qu'en production, ce qui réduit les surprises lors du déploiement.
Consulter les tarifs entrepriseQue faut-il préparer avant de tester un flux ? Ouvrir
Un jeu de mesures représentatif de vos appareils, les identifiants de patient et d'appareil de test, et le profil cible de votre établissement. Préparer ces trois éléments avant la première requête évite la plupart des allers-retours.
Comment le versionnage est-il géré ? Ouvrir
Les endpoints évoluent avec les profils FHIR et les besoins cliniques. Le versionnage permet de garder une intégration stable pendant qu'une nouvelle version se prépare. Les changements sont documentés avant leur mise à disposition; prévoyez cette étape dans votre planning.
Quels droits prévoir pour les utilisateurs de votre côté ? Ouvrir
Les périmètres d'autorisation sont définis par rôle et par ressource. Une équipe de développement n'a pas besoin des mêmes droits qu'un service de soins. Définir ces rôles tôt simplifie la mise en production et l'audit interne.
Où trouver la référence complète des routes ? Ouvrir
La référence complète reprend chaque route, ses paramètres et ses codes de réponse. Elle est transmise avec l'accès à l'environnement de test, afin que votre équipe travaille sur la même version que celle déployée en production.
Conformité et protection des données
Les données de santé relèvent de règles strictes. Vitalink HealthData AG documente sa conformité à la loi suisse sur la protection des données (FADP) et au règlement européen (GDPR) sur la page dédiée, qui précise les bases de traitement, les durées de conservation et les droits des personnes concernées.
- Loi suisse sur la protection des données Traitements, conservation et droits des personnes, décrits pour un contexte d'établissement de santé.
- Règlement européen Le GDPR s'applique aux flux qui dépassent la Suisse; la répartition des rôles y est expliquée sans jargon.
- Sous-traitance Ce que Vitalink traite pour votre compte, et ce qui reste sous votre responsabilité d'établissement.
Vitalink HealthData AG, Seefeldstrasse 45, 8008 Zürich. Support du lundi au vendredi, 09h00 – 18h00 (CET).
Avant de commencer l'intégration
Faut-il un serveur FHIR de notre côté ? Ouvrir
Non. Vous pouvez consommer les endpoints depuis votre application existante. Un serveur FHIR dédié devient utile si vous souhaitez héberger vous-même certaines ressources ou croiser plusieurs sources d'appareils.
Pouvons-nous garder nos propres codes cliniques ? Ouvrir
Oui. La normalisation s'applique en amont, et le mapping vers vos référentiels internes reste documenté. Vous décidez du profil final utilisé par votre établissement.
Combien de temps prend une première intégration ? Ouvrir
Le premier flux validé dans l'environnement de test arrive en général avant le travail sur les profils propres à l'établissement. La durée totale dépend ensuite de vos règles d'accès et du nombre de types de mesures à couvrir.
Comment obtenir l'accès à l'environnement de test ? Ouvrir
La demande se fait depuis la page contact, en précisant votre établissement, les types d'appareils concernés et le système cible. Un échange technique suit pour cadrer les périmètres avant l'ouverture des accès.
Un premier flux, puis un déploiement planifié
L'objectif de cette documentation est simple: vous permettre de tester un premier flux avant de planifier un déploiement. Une fois les endpoints, les formats et les droits compris, la suite relève de votre architecture et de vos contraintes de conformité.