Logiciels de dossier patient : 9 critères pour comparer sans se tromper

DOSOBE édite Betz, une couche d’interopérabilité citée dans ce comparatif parmi d’autres familles de solutions ; les mêmes critères s’appliquent à toutes.

L’erreur la plus fréquente dans le choix d’un logiciel de dossier patient tient en une scène : un comité de sélection assiste à trois démonstrations d’une heure, retient la plus fluide, puis découvre pendant le déploiement que la solution n’échange pas avec le laboratoire, que l’export des données est payant et que les infirmiers saisissent deux fois les mêmes constantes. La démonstration montrait un parcours idéal. Le comité n’avait pas de grille pour juger le reste.

Ce comparatif propose cette grille : neuf critères, appliqués de la même manière à quatre grandes familles de solutions. Il ne classe pas d’éditeurs et n’attribue aucune note. Il aide à poser les bonnes questions, puis à exiger des preuves.

Quatre familles de solutions, quatre logiques

Avant de comparer des produits, il faut savoir quelle famille correspond à votre situation. Un ministère qui veut un dossier partagé à l’échelle d’un pays n’a pas le même besoin qu’une clinique de quarante lits.

La suite hospitalière intégrée couvre l’essentiel des besoins d’un établissement dans un seul logiciel : admissions, dossier médical et de soins, prescription, pharmacie, plateau technique, facturation. Sa force est la cohérence ; sa contrainte, l’ampleur de la migration et la dépendance envers un seul fournisseur.

Le logiciel de spécialité ou de cabinet sert un métier précis (médecine générale, cancérologie, dialyse, imagerie, soins de suite). Il est souvent plus ergonomique pour ce métier, mais il ajoute une brique de plus à relier au reste.

La plateforme ouverte, construite sur un socle open source (OpenMRS en est un exemple répandu dans les systèmes de santé de plusieurs pays à revenu faible ou intermédiaire), laisse une grande liberté d’adaptation et supprime les licences. Elle demande en échange une équipe capable de la paramétrer, de la maintenir et de la faire évoluer dans la durée.

La couche d’interopérabilité ne remplace pas les logiciels existants : elle les fait dialoguer pour constituer un dossier partagé entre établissements, avec un index des patients, un registre des documents et des règles d’accès. C’est la famille à laquelle appartient Betz. Elle suppose que les logiciels en place sachent échanger, ou puissent y être amenés.

Les neuf critères

Chaque critère est formulé comme une question à laquelle le candidat doit répondre par une preuve : un document, un test, une référence vérifiable.

1. L’adéquation aux parcours de soin réels

Le logiciel suit-il la façon dont vos équipes soignent, ou oblige-t-il à soigner comme le logiciel est conçu ? La seule façon de le savoir est de dérouler, pendant l’évaluation, deux ou trois parcours que vous avez décrits vous-mêmes : une admission aux urgences suivie d’une hospitalisation, une consultation avec prescription d’examens, un transfert entre établissements.

2. L’interopérabilité, prouvée sur un échange

Une liste de normes dans une plaquette ne prouve rien. Les références utiles sont connues : HL7 FHIR pour les échanges par API (la version R4 est la plus déployée, la R5 a été publiée en 2023), HL7 v2 pour les flux hospitaliers historiques, DICOM pour l’imagerie, les profils IHE pour les scénarios de partage de documents. Demandez un échange réel avec un de vos systèmes, sur un jeu de données de test, pendant la phase d’évaluation.

3. Les terminologies

Un diagnostic codé est exploitable ; un diagnostic en texte libre l’est beaucoup moins. Vérifiez quelles classifications le logiciel gère (CIM-10 ou CIM-11 de l’OMS pour les diagnostics, LOINC pour la biologie, SNOMED CT là où le pays dispose d’une licence) et qui maintient les tables à jour.

4. La sécurité et la traçabilité

Qui a consulté quel dossier, quand, et depuis quel poste ? Le journal des accès doit être complet, infalsifiable et consultable par le responsable de la sécurité, et, selon le droit applicable, par le patient lui-même. Demandez aussi la politique de mise à jour de sécurité et le délai de correction des vulnérabilités.

5. Le consentement et les droits d’accès

Les droits doivent pouvoir se définir par rôle (médecin traitant, interne, infirmier, secrétaire médicale), par contexte (urgence, hospitalisation en cours) et selon le consentement du patient, y compris son opposition au partage de certaines informations. Les accès exceptionnels, dits « bris de glace », doivent être possibles et systématiquement tracés.

6. L’hébergement et la conformité

Les données de santé sont des données sensibles au sens du RGPD (article 9) et de la plupart des lois de protection des données. Certains pays imposent un cadre propre : en France, l’hébergement de données de santé par un tiers exige un hébergeur certifié HDS. Ailleurs, la loi peut exiger un hébergement sur le territoire national. À l’échelle européenne, le futur espace européen des données de santé, qui a fait l’objet d’un accord politique en 2024, ajoutera des exigences d’échange et d’accès des patients à leurs données.

7. La réversibilité

Pouvez-vous récupérer l’intégralité de vos données, dans un format documenté, à un coût et dans un délai connus ? C’est le critère le plus souvent oublié et celui qui coûte le plus cher quand on le découvre en fin de contrat.

8. La charge de saisie

Mesurez le nombre d’écrans et de clics pour les actes les plus fréquents : saisir des constantes, renouveler une prescription, rédiger une lettre de sortie. Faites tester par les soignants eux-mêmes, pas seulement par la direction des systèmes d’information. Prévoyez aussi le fonctionnement en mode dégradé : que se passe-t-il quand le réseau tombe ?

9. Le coût total et la capacité d’exploitation

Le prix d’acquisition n’est qu’une partie de la dépense. Il faut y ajouter le paramétrage, la reprise des données, les interfaces, la formation, l’hébergement, la maintenance et les évolutions réglementaires, sur une durée réaliste de dix ans. Vérifiez aussi qui assurera le support, dans quelle langue et dans quel fuseau horaire.

Les familles face aux critères

Le tableau ci-dessous indique, pour chaque famille, le point d’attention principal sur chaque critère. Il ne remplace pas l’évaluation d’une solution précise : il signale où chercher.

Un dossier patient se choisit pour la décennie qui vient, pas pour l’heure de démonstration.

Passer de la grille au dossier de consultation

Une grille n’a de valeur que si elle se traduit en exigences vérifiables. Dans un appel d’offres public comme dans une consultation privée, quelques pièces changent la qualité des réponses.

• Trois parcours de soin décrits par vos équipes, à dérouler en démonstration avec vos données de test.
• Un scénario d’échange imposé avec un système existant (laboratoire, imagerie ou dossier d’un autre établissement).
• Une matrice des droits d’accès type, que le candidat doit montrer paramétrée.
• Un export complet d’un jeu de test, à réaliser avant l’attribution, avec sa documentation.
• Un tableau de coût sur dix ans, poste par poste, exploitation et évolutions incluses.
• Une séance d’essai par des soignants, avec mesure du temps passé sur les actes fréquents.

Ces exigences ne favorisent aucune famille : elles obligent chacune à montrer ce qu’elle sait faire sur votre terrain. Pour les ministères et les réseaux qui envisagent un dossier partagé entre établissements, notre expertise santé numérique commence toujours par une cartographie des systèmes et des flux existants. Si vous préparez un appel d’offres et souhaitez une comparaison sans parti pris, notre activité benchmark et appels d’offres applique précisément ce type de grille.

1. HL7 International, spécification FHIR (Fast Healthcare Interoperability Resources), versions R4 et R5.
2. Organisation mondiale de la santé, Classification internationale des maladies (CIM-10 et CIM-11).
3. Règlement (UE) 2016/679 (RGPD), article 9 relatif aux catégories particulières de données.
4. IHE International, cadres techniques et profils d’intégration.
5. Organisation mondiale de la santé, Stratégie mondiale pour la santé numérique 2020-2025.

Questions fréquentes

Faut-il choisir un logiciel de dossier patient unique pour tous les établissements ?

Pas nécessairement. Un logiciel unique simplifie l'exploitation mais impose une migration lourde et une dépendance forte. Relier les logiciels existants par une couche d'interopérabilité est souvent plus réaliste, surtout lorsque les établissements ont des tailles et des métiers différents.

Quelles normes d'interopérabilité exiger dans un cahier des charges ?

HL7 FHIR pour les échanges modernes par API, HL7 v2 pour les flux hospitaliers existants, DICOM pour l'imagerie, et des terminologies reconnues (CIM, LOINC, SNOMED CT selon les licences du pays). L'important est de demander des cas d'échange précis, testés pendant l'évaluation.

Comment vérifier la réversibilité d'un logiciel de dossier patient ?

En demandant, avant signature, un export complet d'un jeu de données de test dans un format documenté, puis en le réimportant dans un autre outil. Le contrat doit préciser le format, le délai et le coût de la restitution des données en fin de contrat.

Une solution open source est-elle moins sûre ?

Non par principe. La sécurité dépend de la maintenance, des mises à jour et de l'exploitation. Une solution open source sans équipe pour la maintenir est risquée ; une solution propriétaire mal exploitée l'est aussi.