Quel DPI choisir pour alimenter le DEP en Suisse : les 4 critères décisifs en 2026

L'essentiel en 30 secondes

‍

En Suisse, les établissements de soins sont confrontés à une décision structurante : quel Dossier Patient Informatisé (DPI) choisir pour les dix prochaines années ? La pression vient de trois directions à la fois. Elle est réglementaire avec la nLPD, la stratégie eHealth Suisse et le déploiement du Dossier Électronique du Patient (DEP). Elle est opérationnelle avec la pénurie de soignants. Et elle est sécuritaire avec la recrudescence des cyberattaques sur les hôpitaux.

Le DPI est au cœur de cette équation. C'est lui qui produit, structure et transmet les données cliniques, notamment vers le DEP. Un DPI mal choisi ne se contente pas de ralentir les équipes : il bloque la capacité de l'établissement à s'inscrire dans le système de santé numérique suisse.

Galeon accompagne aujourd'hui 19 hôpitaux dont 2 CHU, avec plus de 3 millions de dossiers patients et 10 000 soignants actifs sur la plateforme. Ce retour d'expérience de terrain, couplé à une architecture blockchain et IA, permet d'identifier les quatre critères vraiment décisifs pour un DSI ou DG d'établissement hospitalier suisse.

Cet article détaille ces critères un par un, les compare aux pratiques du marché et propose une grille de décision opérationnelle.

‍

DPI et DEP : deux outils distincts qui doivent fonctionner ensemble

Avant d'aborder les critères de choix, il est utile de clarifier deux notions que l'on confond souvent.

Le DPI (Dossier Patient Informatisé) est le logiciel de gestion clinique et administrative de l'hôpital. Il contient l'intégralité du dossier patient produit au sein de l'établissement : antécédents, diagnostics, prescriptions, résultats d'examens, notes de soins. Il est géré par l'hôpital, pour l'hôpital.

Le DEP (Dossier Électronique du Patient) est le carnet de santé numérique du patient, créé par la loi fédérale sur le dossier électronique du patient (LDEP). Il est accessible à tous les professionnels de santé autorisés par le patient, quelle que soit leur institution. Il ne remplace pas le DPI : il en reçoit les informations pertinentes.

Un DPI n'est pas un DEP. Mais un bon DPI est celui qui alimente le DEP de façon fluide, sécurisée et conforme aux standards nationaux.

C'est là que la qualité du DPI devient stratégique. Un DPI qui ne peut pas se raccorder au DEP via HL7 FHIR expose l'établissement à des difficultés de coordination des soins, des risques réglementaires et une exclusion progressive du système de santé numérique suisse.

Pourquoi le codage automatique des actes est-il devenu incontournable en Suisse ?

Le codage des actes médicaux est la colonne vertébrale de la facturation hospitalière suisse. Chaque acte non codé ou mal codé représente une perte directe de revenu pour l'établissement, avec une charge supplémentaire qui pèse sur des soignants déjà sous pression.

Qu'est-ce que le codage automatique des actes ?

Le codage automatique consiste à associer, en temps réel ou en fin de consultation, des codes TARMED, SwissDRG ou CHOP aux actes documentés dans le DPI. Une IA analyse les notes cliniques, les diagnostics et les prescriptions pour suggérer automatiquement les codes les plus pertinents. Le soignant valide ou corrige en un clic.

En Suisse, la complexité est amplifiée par la coexistence de plusieurs systèmes tarifaires selon le type de soin (ambulatoire, stationnaire, psychiatrique). Un DPI sans module de codage intelligent devient rapidement un fardeau administratif, et les écarts de codage entre établissements restent une réalité documentée par les fédérations hospitalières.

Quels bénéfices concrets attendre d'un DPI avec IA de codage ?

• Réduction significative de la charge administrative liée à la saisie et à la vérification des codes
• Détection des incohérences de codage avant soumission à l'assureur, limitant les litiges de facturation
• Amélioration de la traçabilité des actes et de la qualité des données transmises aux registres nationaux
• Possibilité pour les soignants de se recentrer sur les tâches cliniques à forte valeur ajoutée

Pour les DSI, le critère clé est l'intégration native du moteur de codage dans le DPI, et non sous forme de module externe qui multiplie les points de friction et les risques d'erreur de synchronisation.

Comment un DPI doit-il protéger l'hôpital contre les cyberattaques ?

Les hôpitaux sont devenus des cibles prioritaires des cybercriminels. L'Office fédéral de la cybersécurité (OFCS) a enregistré presque le double de cyberincidents au second semestre 2023 par rapport à la même période en 2022, avec 30 331 incidents signalés contre 16 951 (source : Rapport semestriel OFCS 2023/2). La tendance de fond est claire et durable.

Le secteur de la santé est particulièrement exposé. Selon une étude IBM citée par la RTS, un dossier médical peut se négocier à plus de 300 francs suisses sur le darknet, soit bien au-delà de ce que rapporte une carte de crédit. Cette valeur intrinsèque des données médicales explique l'intensité du ciblage.

La question n'est plus de savoir si un hôpital sera attaqué, mais quand. Et surtout : sera-t-il capable de continuer à soigner pendant l'incident ?

Quelles architectures DPI résistent le mieux aux ransomwares ?

Les architectures centralisées (un seul serveur, une seule base de données) présentent un risque systémique : une attaque réussie paralyse l'intégralité du système. À l'inverse, les architectures décentralisées limitent la surface d'attaque.

• Architecture monolithique centralisée : un seul point de compromission suffit à bloquer tout l'hôpital
• Architecture microservices : cloisonnement des données, la compromission d'un module n'affecte pas les autres
• Architecture blockchain décentralisée : les données sont réparties sur plusieurs nœuds, aucun attaquant ne peut les chiffrer en totalité

Dans l'architecture Galeon, les données ne quittent jamais les serveurs de l'hôpital. C'est le principe fondateur du Blockchain Swarm Learning® et le premier rempart contre les ransomwares.

Quels critères de résilience exiger dans l'appel d'offres ?

• Temps de reprise d'activité (RTO) garanti contractuellement en cas d'incident
• Existence d'un plan de continuité d'activité (PCA) testé annuellement
• Chiffrement des données au repos et en transit (AES-256 minimum)
• Journalisation immuable de toutes les actions (piste d'audit blockchain)
• Certification ISO 27001 de l'éditeur

Le Cloud Act américain : pourquoi la souveraineté des données est un enjeu suisse concret ?

La question de l'hébergement des données de santé est souvent reléguée en bas de la liste des critères. C'est une erreur stratégique majeure pour tout établissement suisse.

Qu'est-ce que le Cloud Act et pourquoi concerne-t-il les hôpitaux suisses ?

Le Clarifying Lawful Overseas Use of Data Act (Cloud Act) de 2018 autorise les autorités américaines à exiger l'accès aux données hébergées par toute entreprise de droit américain, quelle que soit la localisation physique de ces données. Concrètement :

• Un DPI hébergé sur AWS, Microsoft Azure ou Google Cloud, même en région européenne, est soumis au droit américain
• Les données de patients suisses peuvent théoriquement être transmises aux autorités US sans accord judiciaire suisse préalable
• Cette situation est en contradiction directe avec la nLPD (nouvelle Loi fédérale sur la Protection des Données, en vigueur depuis septembre 2023) et avec le principe de souveraineté des données médicales

Héberger un DPI sur un cloud américain, c'est exposer les données de vos patients au droit américain. La souveraineté numérique n'est pas une option en Suisse. C'est une obligation légale.

Quelles alternatives souveraines existent pour les hôpitaux suisses ?

• Hébergement on-premise sur les serveurs propres de l'établissement
• Cloud souverain suisse (ex : SWITCH, Exoscale) hors juridiction Cloud Act
• Architecture décentralisée type blockchain inter-hôpitaux, où chaque établissement héberge localement ses propres données

Galeon a retenu cette troisième voie. Dans le Blockchain Swarm Learning®, les données restent physiquement sur les serveurs de chaque hôpital. Seuls les modèles d'IA se déplacent pour être entraînés de façon décentralisée. Les données brutes, elles, ne bougent pas.

Comment un DPI se connecte-t-il au DEP en Suisse ?

L'interopérabilité entre le DPI et le DEP est devenue le critère technique le plus structurant pour les hôpitaux suisses. Un DPI qui ne peut pas alimenter le DEP exclut l'établissement d'un écosystème numérique de santé qui devient progressivement obligatoire.

Quelle est la norme de raccordement entre DPI et DEP en Suisse ?

Depuis juin 2025, les interfaces HL7 FHIR (Fast Healthcare Interoperability Resources) sont ancrées dans la législation suisse (source : eHealth Suisse, État des lieux du DEP, 2025). Tout DPI souhaitant alimenter le DEP doit implémenter ce standard. C'est le protocole qui permet au dossier produit dans l'hôpital d'être transmis de façon structurée et lisible dans le DEP du patient.

• HL7 FHIR R4 : standard d'échange pour les données cliniques (diagnostics, prescriptions, résultats de labo)
• IHE XDS / XUA : protocole pour le partage de documents médicaux dans le DEP
• SNOMED CT / LOINC / CIM-11 : terminologies médicales standardisées pour la codification des pathologies

Un DPI sans conformité HL7 FHIR native ne peut pas alimenter correctement le DEP. C'est un blocage réglementaire, pas seulement technique.

Pourquoi la connexion DPI-DEP est-elle critique pour la continuité des soins ?

En Suisse, un patient atteint d'une pathologie chronique est pris en charge par de multiples acteurs : médecin traitant, spécialistes, hôpital, pharmacie, laboratoire. Le DEP est justement conçu pour que chacun de ces acteurs dispose des informations pertinentes au bon moment. Si le DPI de l'hôpital ne transmet pas ses données au DEP, c'est l'ensemble de la coordination qui s'effondre.

Les risques concrets d'un DPI non raccordé au DEP sont les suivants :

• Redondance des examens diagnostiques faute d'accès aux résultats existants
• Risques d'erreurs médicamenteuses liés à une absence de vision du traitement en cours
• Impossibilité pour le médecin traitant d'accéder aux comptes rendus hospitaliers
• Non-conformité progressive avec les exigences de la LDEP et de la stratégie DigiSanté 2025-2034

Comment évaluer concrètement la compatibilité DEP d'un DPI en appel d'offres ?

• Le DPI est-il certifié pour le raccordement au DEP suisse ?
• Propose-t-il une API RESTful HL7 FHIR R4 documentée et accessible ?
• Supporte-t-il les profils IHE requis par la LDEP (XDS, XUA, PIX, PDQ) ?
• Offre-t-il un tableau de bord de monitoring des flux d'envoi vers le DEP ?
• A-t-il participé aux tests d'interopérabilité organisés par eHealth Suisse (Projectathon DEP) ?

‍

DPI traditionnel vs DPI IA/Blockchain : tableau comparatif

Quelles sont les limites et les enjeux à anticiper lors du déploiement d'un DPI IA ?

Un choix éclairé de DPI implique aussi de regarder en face les défis réels du déploiement. Voici les cinq limites principales que tout DSI doit anticiper.

1. La résistance au changement des équipes soignantes

L'adoption d'un nouveau DPI génère inévitablement une phase de friction. Les soignants formés à un outil depuis des années résistent aux nouvelles interfaces. La conduite du changement, avec les formations, les référents internes et le déploiement progressif, représente une part souvent sous-estimée du coût réel d'un projet de migration DPI.

2. La migration des données historiques

Transférer des millions de dossiers patients d'un système à l'autre sans perte d'information ni rupture de continuité clinique est techniquement complexe. La qualité de la donnée source, souvent incomplète, mal structurée ou bloquée dans des formats propriétaires, est le premier obstacle. Un calendrier réaliste doit être négocié contractuellement dès l'appel d'offres.

3. La maturité variable des standards HL7 FHIR en Suisse

Si HL7 FHIR est légalement ancré depuis juin 2025, son implémentation réelle reste hétérogène selon les cantons et les éditeurs. Un DPI conforme sur le papier peut présenter des lacunes d'implémentation. Il est indispensable de tester les flux d'échange avec le DEP en conditions réelles avant toute signature de contrat.

4. Le coût total de possession (TCO) difficile à anticiper

Le prix de licence affiché ne représente qu'une fraction du coût réel. Licences, maintenance, hébergement, formations, personnalisations et intégrations tierces peuvent significativement dépasser l'investissement initial prévu. Exiger un TCO détaillé sur 5 ans est non négociable dans tout appel d'offres sérieux.

5. La gouvernance des données dans un modèle multi-hôpitaux

Quand un DPI est partagé entre plusieurs établissements, comme dans le modèle Galeon, la question de la gouvernance devient centrale : qui décide de l'utilisation des données agrégées ? Quel hôpital a droit de regard sur quelles informations ? Ces règles doivent être contractuellement fixées avant tout démarrage.

FAQ

Quelle est la différence entre un DPI et le DEP ?

Le DPI (Dossier Patient Informatisé) est le logiciel de gestion clinique propre à l'hôpital. Il contient l'ensemble du dossier médical produit au sein de l'établissement et est géré par l'hôpital. Le DEP (Dossier Électronique du Patient) est le carnet de santé numérique du patient, accessible à tous ses soignants autorisés, quelle que soit leur institution. Les deux sont complémentaires : le DPI produit les données, le DEP les partage. Un hôpital ne peut pas remplacer son DPI par le DEP, ni inversement.

Un DPI peut-il alimenter le DEP sans certification HL7 FHIR ?

Non. Depuis juin 2025, les interfaces HL7 FHIR sont ancrées dans la législation suisse pour le raccordement au DEP. Un DPI qui ne supporte pas ce standard ne peut pas transmettre les données au DEP de façon structurée et conforme. Il peut exister des contournements techniques, mais ils génèrent des coûts de maintenance élevés et des risques de non-conformité croissants avec la montée en charge du DEP et du futur Dossier Électronique de Santé (DES).

Le codage automatique des actes est-il fiable pour la facturation SwissDRG ?

Les moteurs de codage IA atteignent aujourd'hui des niveaux de précision élevés sur les actes courants, mais ils ne remplacent pas la validation médicale finale. Ils la facilitent et la rendent plus rapide. Pour SwissDRG, l'IA suggère les DRG les plus probables à partir des données cliniques documentées dans le DPI. Le gain réel se mesure surtout en temps de vérification et en réduction des rejets de facturation.

Un hôpital suisse est-il légalement contraint de choisir un hébergement en Suisse ?

La nLPD n'interdit pas formellement l'hébergement à l'étranger, mais impose des garanties équivalentes de protection. En pratique, un hébergement aux États-Unis expose l'établissement au Cloud Act, en contradiction avec les principes de la nLPD et la politique du Préposé fédéral à la protection des données. L'hébergement en Suisse ou dans l'UE (RGPD) est fortement recommandé par les juristes spécialisés en droit de la santé numérique.

Qu'est-ce que le Blockchain Swarm Learning® de Galeon et pourquoi c'est pertinent pour la sécurité ?

Le Blockchain Swarm Learning® (BSL®) est une architecture propriétaire de Galeon dans laquelle les données médicales restent sur les serveurs de chaque hôpital, sans jamais être centralisées. Seuls les algorithmes d'IA se déplacent entre les nœuds pour être entraînés. Cette approche élimine le point de défaillance unique, neutralise le risque Cloud Act et permet aux hôpitaux d'être rémunérés via le token $GALEON pour leur contribution aux données d'entraînement.

Quel est le délai réaliste pour déployer un nouveau DPI dans un hôpital ?

Il varie fortement selon la taille de l'établissement, la qualité des données existantes et le périmètre du déploiement. Un phasage par services (urgences, médecine interne, chirurgie) permet de limiter les risques opérationnels et de tirer des enseignements avant le déploiement complet. Les phases de migration des données historiques et de formation des équipes sont invariablement les plus longues.

Comment Galeon est-il déployé actuellement dans les hôpitaux ?

Galeon est présent dans 19 hôpitaux dont 2 CHU, avec plus de 3 millions de dossiers patients et plusieurs milliers de soignants actifs. Le déploiement suit une approche progressive par service, avec des référents Galeon intégrés aux équipes locales pendant la phase de transition. La plateforme est conçue pour s'intégrer aux systèmes existants via API, sans remplacement brutal de l'écosystème informatique en place.

En résumé : les 4 critères non-négociables pour choisir un DPI connecté au DEP en Suisse en 2026

Choisir un DPI en Suisse en 2026, c'est choisir la brique centrale qui alimente le DEP, protège les données des patients et structure le travail quotidien de milliers de soignants. Les quatre critères décisifs, à savoir le codage automatique des actes, la résilience aux cyberattaques, la souveraineté des données face au Cloud Act et la conformité HL7 FHIR pour le raccordement au DEP, forment un socle indissociable. Un DPI qui excelle sur l'un et faillit sur un autre expose l'établissement à des risques opérationnels, juridiques ou financiers majeurs.

Les solutions fondées sur l'IA et la blockchain décentralisée, comme Galeon, répondent structurellement à ces quatre exigences. Le codage IA réduit la charge administrative. L'architecture BSL® neutralise les ransomwares. L'hébergement local garantit la souveraineté. Les API HL7 FHIR permettent le raccordement au DEP et la continuité des soins entre établissements.

Galeon accompagne déjà 19 hôpitaux, dont 2 CHU, avec plus de 3 millions de dossiers patients sous gestion. La preuve de concept est établie. Il ne s'agit plus d'un pari technologique, mais d'un choix de maturité pour les DSI et DG qui veulent construire l'hôpital de demain sans compromettre la sécurité et la souveraineté d'aujourd'hui.

Un DPI bien choisi ne se contente pas de gérer le dossier patient. Il alimente le DEP, protège les données et prépare l'hôpital à la médecine de demain.

‍

Sources

Cybersecurity

• Federal Office for Cybersecurity (OFCS), Semi-Annual Report 2023/2, published 6 May 2024. Cyber incidents reported: 30,331 in H2 2023 vs. 16,951 in H2 2022.
• RTS / IBM study, Medical data increasingly vulnerable to cyberattacks, December 2023. A medical file can sell for over CHF 300 on the dark web.

Data sovereignty and the Cloud Act

• CLOUD Act (Clarifying Lawful Overseas Use of Data Act), US federal law enacted 23 March 2018. Authorises extraterritorial access to data held by US-incorporated companies.
• CNIL, Cloud: the risks of a European certification framework allowing foreign authorities to access sensitive data. Outlines Cloud Act risks for health data hosted with US-law providers.

Data protection in Switzerland

• Swiss Confederation, New Federal Act on Data Protection (nFADP), in force since 1 September 2023.

PED, interoperability and standards

• eHealth Switzerland, Exchange formats: data structuring. Adoption of HL7 FHIR for the Patient Electronic Dossier (PED).
• eHealth Switzerland, Status of the PED in Switzerland, 2025. HL7 FHIR legally mandated since June 2025 as the basis for the future Electronic Health Record framework.
• Federal Office of Public Health (FOPH) / eHealth Switzerland, Electronic health record: technical aspects, 2025. IHE (FHIR), HL7 and SNOMED standards applied to the PED.
• DigiSanté Programme 2025-2034, National strategy for digital transformation in healthcare, Swiss Confederation. Built on HL7 FHIR, IHE and SNOMED CT standards.

‍