Vitalink HealthData, interopérabilité clinique suisse
Vitalink HealthData développe une API qui relie les données de glucomètres et de montres connectées aux dossiers patients électroniques. Notre travail se situe entre les appareils grand public et les systèmes cliniques suisses. Cette page présente notre mission, notre approche technique et les principes qui guident nos décisions.
Une couche d'intégration, pas un remplacement de votre EHR
Nous voulons rendre les données d'appareils utilisables dans un contexte clinique suisse, sans imposer une refonte des systèmes existants. Cela signifie absorber des flux hétérogènes, les normaliser et les transmettre via FHIR. Notre rôle est celui d'une couche d'intégration, pas d'un remplacement de votre EHR. Cette position guide nos choix techniques.
- Ce que nous absorbons
- Des séries de glycémie et des relevés de montres connectées, avec des formats, des cadences et des qualités de signal différentes selon les fabricants.
- Ce que nous ne touchons pas
- Votre dossier patient reste la référence. Nous n'écrivons pas par-dessus votre modèle clinique : nous livrons des ressources lisibles à votre système cible.
- Pourquoi ce choix
- Une refonte d'EHR prend des années et mobilise des équipes entières. Une couche d'intégration se déploie projet par projet, sans geler votre feuille de route.
- Ce que vous gardez
- La maîtrise de votre architecture, de vos données et de vos décisions cliniques. Notre API s'insère dans vos règles d'accès existantes.
FHIR comme socle, la réalité hospitalière comme cadre
HL7 FHIR, développé par Health Level Seven International, repose sur REST, JSON et XML. Ce standard modulaire est plus simple à implémenter que les mécanismes antérieurs. Nous nous appuyons dessus, tout en tenant compte des réalités hospitalières suisses. Le dossier patient électronique reste la référence, mais FHIR n'y est pas déployé de bout en bout.
REST et JSON d'abord
Les équipes applicatives retrouvent des verbes HTTP et des payloads lisibles, plutôt qu'un protocole à réimplémenter de zéro.
Profils plutôt qu'inventions
Nous partons des profils et guides d'échange reconnus, puis nous documentons chaque écart assumé plutôt que de le masquer.
Le dossier patient reste maître
L'EHR conserve l'autorité clinique. Notre API achemine et normalise, elle ne décide pas à sa place.
Le contexte suisse
En Suisse, l'usage de FHIR dans le dossier patient électronique est décrit comme limité à certains cas, notamment la vaccination et la médication.
Les exigences d'échange sont encadrées par des guides spécifiques. Travailler ici demande de composer avec cet environnement, pas de l'ignorer. Nos intégrations s'alignent sur ces contraintes, et nous documentons explicitement les cas où un flux sort du périmètre couvert par les guides. Cette honnêteté évite les surprises en phase de recette.
L'héritage hospitalier et les architectures récentes
Notre équipe réunit des profils d'intégration et de développement logiciel. Nous connaissons HL7 v2, IHE, DICOM et XDS, ainsi que les API modernes. Cette double culture aide à faire dialoguer l'héritage hospitalier et les architectures récentes. Nous ne prétendons pas remplacer vos équipes; nous les outillons.
Standards historiques
HL7 v2, IHE, DICOM, XDS : les formats que vos systèmes exploitent déjà au quotidien.
Pile moderne
REST, JSON, OAuth, files d'attente : ce que vos développeurs attendent d'une API aujourd'hui.
Rôle dans vos projets
Nous outillons vos équipes : documentation, environnements de test, accompagnement sur les profils.
Ce que nous demandons
Un interlocuteur technique côté client et une définition claire du système cible dès le premier échange.
La sécurité se conçoit avec l'architecture clinique
La sécurité n'est pas une option ajoutée en fin de projet. Chiffrement en transit et au repos, authentification OAuth, contrôle d'accès par rôle et journalisation font partie de la base.
Les droits d'accès doivent être pensés avec l'architecture clinique dès la phase conceptuelle. Notre travail s'inscrit dans le cadre de la loi suisse sur la protection des données (FADP) et du règlement européen (RGPD), que nous détaillons dans notre politique de confidentialité.
Lire la politique de confidentialitéCette exigence revient dans chaque projet, et elle influence nos choix de schémas de chiffrement comme notre modèle d'autorisation. Pour le détail technique, consultez la page dédiée à la sécurité et au chiffrement.
Voir les schémas de chiffrementNos limites assumées
Dire clairement ce que nous ne faisons pas fait partie de notre approche. Cela vous évite de bâtir un projet sur une attente que nous ne pourrons pas tenir.
Ce que notre API fait
- Transporter des séries de mesures issues d'appareils grand public.
- Normaliser des formats hétérogènes en ressources FHIR lisibles.
- Acheminer vers votre EHR ou un middleware intermédiaire.
Ce que nous ne faisons pas
- Nous ne fabriquons pas d'appareils médicaux.
- Nous ne fournissons ni diagnostic ni interprétation clinique.
- Nous ne remplaçons pas la responsabilité clinique de votre institution.
Notre API transporte et normalise des données; l'usage clinique reste de votre responsabilité. Cette frontière est écrite noir sur blanc dans nos échanges de projet.
Nous nous insérons dans ces architectures sans les remplacer
Nous nous concentrons sur l'absorption des flux de capteurs et leur acheminement vers l'EHR ou un middleware. D'autres briques restent à leur place, avec leurs propres standards et leurs propres équipes.
- Flux de capteurs
- Notre cœur de métier : réception, normalisation et acheminement des mesures d'appareils grand public.
- Partage documentaire
- Relève d'autres standards comme XDS, portés par les infrastructures institutionnelles.
- Modélisation clinique
- Peut passer par openEHR, avec ses archétypes et sa gouvernance propres.
- Notre place
- Une couche d'intégration entre les appareils et ces architectures, documentée et sans surprise.
Comment démarre un projet
Le devis suit la validation technique. Nous ne chiffrons pas une intégration que nous n'avons pas comprise.
-
1
Décrire votre cas d'usage
Appareils concernés, volumes attendus, systèmes cibles et contraintes de vos équipes. C'est ce qui détermine tout le reste.
-
2
Identifier les endpoints et profils FHIR
Nous déterminons les ressources concernées, les profils applicables et les écarts à documenter avant d'écrire la moindre ligne d'intégration.
-
3
Valider par une démonstration technique
Une session avec vos développeurs, sur un jeu de données représentatif, pour confirmer que l'approche tient dans votre environnement.
-
4
Recevoir le devis
Le chiffrage s'appuie sur le périmètre validé. Pour les volumes importants, les tarifs entreprise s'adaptent au nombre de flux et de sites.
Les tarifs entreprise sont détaillés sur la page dédiée, avec les options de support et d'accompagnement. Notre équipe est joignable du lundi au vendredi, de 09h00 à 18h00 (CET).
Poursuivre la lecture selon votre besoin
Selon votre rôle dans le projet, une page sera plus utile qu'une autre. Voici par où commencer.
Vitalink HealthData AG · Seefeldstrasse 45, 8008 Zürich, Schweiz
+41 21 581 78 71 · [email protected]