Nous fêtons la norme

Ce n’est pas uniquement VISUS qui célèbre cette année un anniversaire important, mais également deux des plus fidèles compagnons de l’entreprise : DICOM et IHE. DICOM a déjà 25 ans, et IHE 20 ans. Une raison suffisante pour se pencher sur les débuts et les facteurs de réussite de ces deux institutions. Dr. Jörg Riesmeier, aujourd’hui consultant indépendant et développeur de logiciels, fait partie de ceux qui se sont penchés sur les deux normes depuis le début. De plus, il est étroitement lié à VISUS et n’est pas étranger à la conception du système qui a précédé JiveX.

Monsieur Riesmeier, voici ma première question : qu’est-ce qui vous lie à VISUS ?

J’ai travaillé pendant de nombreuses années chez OFFIS, un institut de recherche en informatique appliquée issu de l’Université d’Oldenbourg. Même avant la publication de la première version de la norme DICOM en 1993, OFFIS a participé à l’implémentation d’un prototype mandatée par l’éditrice de la norme, NEMA. Le logiciel qui en a résulté a été développé dans les années suivantes pour devenir une boîte à outils DICOM, actuellement le DCMTK. Surtout au début, l’industrie qui appuie cette norme a montré un vif intérêt à ce que la compatibilité à la pratique de DICOM soit vérifiée et que les résultats soient présentés au public spécialisé. Ainsi, il y a eu de nombreux appels d’offres au fil des ans pour développer des implémentations de prototypes sur des sujets très différents. L’une d’elles était la représentation d’image cohérente, combinée avec les états de présentation Softcopy. Il s’agissait concrètement de pouvoir afficher de la même manière les images radiologiques sur différents moniteurs et imprimantes. Et il était question également que les paramètres effectués sur l’image par le radiologue dans le cadre du diagnostic – fenêtrage en niveaux de gris, annotations graphiques et textuelles, etc. – ne soient pas perdus dès que les données étaient appelées sur un autre poste de travail. Chez OFFIS, nous connaissions bien DICOM et la visualisation d’images médicales, mais pas le développement d’interfaces utilisateur graphiques.

Et c’est là qu’interviennent Klaus Kleber et Jörg Holstein qui, à l’époque, travaillaient sur une interface utilisateur basée sur Java pour les applications médicales à l’Institut de microthérapie chez le Prof. Dr. Dietrich Grönemeyer à Bochum. Nous avons donc envoyé ensemble notre candidature pour le projet et nous avons gagné l’appel d’offres. Le logiciel que nous avons présenté pour la première fois en 1999 à l’ECR à Vienne, puis à la RSNA à Chicago, portait le nom DICOMscope et un coup d’œil rétrospectif permet de dire que ce fut le précurseur du JiveX actuel.

Vous êtes donc un véritable pionnier de DICOM et vous avez contribué à ce que la norme soit expérimentée. Et cela remonte à 25 ans maintenant. Qu’est-ce qui s’est passé pendant tout ce temps ?

Beaucoup de choses. La norme DICOM comptait au début 750 pages, elle en compte aujourd’hui plus de 6 000. Il est évident que l’on ne peut pas s’en imprégner simplement en la lisant. Cependant, si vous étiez là depuis le début et si vous avez étudié la question pendant toutes ces années, vous pouvez vous considérer comme un expert. Les nombreuses nouveautés qui ont rempli ses pages au fil du temps sont de nature très différente. Une extension majeure fut, à la fin des années 90, la consistance de l’affichage mentionnée ci-dessus avec les états de présentation. Toutefois, dans les 15 à 20 dernières années, le champ d’application de la norme a considérablement augmenté. Au début, il ne s’agissait que de l’échange d’images radiologiques, quel que soit le fabricant. Plus tard, les services de cardiologie, de radiothérapie, d'ophtalmologie, de chirurgie, etc. sont venus la compléter. Parallèlement, des structures de données pour les données de signal et les rapports de résultats médicaux ont été définies. Depuis de nombreuses années, la tendance est également à la reproduction et à l’automatisation d’une grande partie du flux de travail dans un établissement de santé, non seulement en interne, mais également en externe. Et c’est précisément sur ce point que les spécifications de la norme IHE entrent en jeu, car DICOM comporte certaines limites en matière d’échange de documents médicaux entre établissements.

Quel est le secret de la réussite de DICOM ? Après tout, il n’existe pas d’alternative aujourd’hui, aucun concept alternatif en vue nulle part.

Pour comprendre cela, il faut revenir en arrière au prédécesseur de DICOM, la norme ACR-NEMA. Cette approche remonte aux années 1980, lorsque le souhait fut exprimé de transférer des images de grands appareils, notamment CT et IRM, vers un autre appareil afin de pouvoir les visualiser. Déjà à l’époque, les utilisateurs étaient attentifs au fait de ne pas dépendre des fabricants de ces appareils. Cependant, cette norme était trop imprécise sur certains points et laissait trop de marge de manœuvre dans la mise en œuvre, de sorte que les fabricants ont développé des « dialectes » qui n’étaient pas compris de tous. De plus, les fabricants étaient intéressés par une standardisation, car après tout leurs appareils ont été utilisés pendant très longtemps et généraient des données qui pouvaient être parfois archivées jusqu’à 30 ans et être toujours lues. C’est dans ce contexte que la norme DICOM a vu le jour et a adopté certains concepts de base d’ACR-NEMA, en tirant toutefois des leçons de ses erreurs. Ce développement a été conduit à la fois par les utilisateurs et par l’industrie.

Du point de vue actuel, les concepts à la base de DICOM peuvent sembler un peu démodés, et on voit bien que dans le fond, c’est un produit des années 80/90. Mais ils fonctionnent toujours très bien. Du point de vue de l’industrie, il n’y a aucune raison de changer quoi que ce soit. Après tout, ils ont consacré des dizaines d’années de travail au développement de DICOM et à sa mise en œuvre.

Mais depuis longtemps, il existe en informatique le concept opposé des solutions propriétaires, qui a également connu un certain succès.

Ce sont surtout les grandes entreprises qui préféraient tout vendre d’une même source, et le veulent probablement encore aujourd’hui. En effet, jusqu’à il y a quelques années, les grands fabricants pouvaient encore définir leurs propres normes en raison de leur taille. Mais cela ne fonctionne plus aujourd'hui, pour deux raisons. Premièrement, il n’existe plus d'entreprises dominantes dont personne ne peut se passer. Et deuxièmement, les clients ne sont plus disposés à accepter de telles approches car la pression des coûts et des résultats les obligent à utiliser la meilleure solution. Et cela n’est possible que si un système s’appuie sur des normes établies.

Les choses semblent un peu différentes pour les profils IHE, ils ne sont pas impérativement utilisés comme avec la norme DICOM. Quelle en est la raison ?

Il existe de nombreux domaines IHE et leurs profils respectifs ont des degrés de réussite différents. Mais prenons les profils XDS pour l’échange de documents entre établissements. Pendant des années, les établissements ont géré ce processus eux-mêmes dans des interconnexions ou des réseaux , que ce soit via des supports de données, des connexions VPN ou par e-mail. L’intérêt de modifier une infrastructure existante, c’est-à-dire de remplacer complètement un processus bien établi, n’est pas toujours évident. C’est pourquoi il faut offrir des avantages significatifs pour passer à un processus basé sur IHE.

Un autre point important : le papier souffre tout et on attend parfois en vain qu’une écriture prenne vie. Avec IHE, ces fichiers « morts » ne sont pas aussi rares qu’avec DICOM. C’est peut-être également dû au fait que les cas d’application ne viennent pas toujours de la pratique, mais ont été parfois développés du point de vue scientifique ou à la table de réunion. Pour IHE XDS, ce n’est certainement pas le cas. Ceci est également démontré par l’engagement au niveau national dans nos pays voisins, en Autriche et Suisse, qui rendent obligatoire l’utilisation de IHE dans les fichiers ou dossiers numériques.

Quelle est la recette du succès d’une bonne norme ?

La norme doit être librement accessible. Aussi bien les spécifications de DICOM que de HL7 étaient payantes au début. Cela a ensuite changé, beaucoup plus tôt avec DICOM qu’avec HL7. Ainsi, les petites entreprises innovantes ont eu la possibilité d’utiliser ces normes gratuitement. Généralement, elles n'ont pas à commencer de zéro et peuvent utiliser l’un des kits d’outils disponibles gratuitement. De plus, l’utilisateur doit bénéficier d'un réel avantage, d'une amélioration qui va de pair avec une norme, car ces interfaces sont souvent des options payantes. Enfin, l’industrie doit apporter son soutien. Il ne faut pas oublier que les entreprises doivent engager des employés ayant des connaissances approfondies sur le sujet et qui développent des spécifications techniques d’un point de vue économique et pratique.