En juillet 2012, le Centre Hospitalier Universitaire de Liège (Belgique) a publié la première version de son projet libre Orthanc. Orthanc est un serveur DICOM qui permet d'améliorer les flux d'imagerie médicale. La version 0.7.1 de ce projet utile aux hôpitaux est disponible depuis aujourd'hui.
Le transfert automatisé des images médicales entre un point A et un point B est un problème auquel tous les hôpitaux sont confrontés, singulièrement dans la prise en charge thérapeutique du cancer. En 2011, face au manque d'offres commerciales permettant de solutionner ce problème, le Département de Physique Médicale du CHU de Liège décide de lancer le développement d'Orthanc. La spécificité de ce logiciel est sa capacité de créer à bas coût des passerelles électroniques entre des logiciels et des équipements gérés par des firmes différentes, voire entre services médicaux distants, permettant ainsi de résoudre les problèmes d'interopérabilité et de compatibilité rencontrés jusqu'alors.
Orthanc se base sur le standard DICOM, qui spécifie le format de fichiers et le protocole réseau de l'imagerie médicale. Cela signifie que tout appareil d'imagerie médicale peut se connecter à Orthanc pour lui envoyer ses images. Quand Orthanc reçoit une image, il indexe celle-ci de manière transparente selon la hiérarchie "Patient, Examen, Série, Instance" du standard DICOM. Il est ensuite possible de consulter à distance cette hiérarchie, puis d'interagir avec elle depuis n'importe quel ordinateur de l'hôpital en se connectant à une interface Web intuitive. Ceci facilite grandement la gestion des images médicales en routine clinique. Depuis la version 0.7.0, les logiciels de visualisation d'images médicales comme OsiriX, Ginkgo CADx ou 3D Slicer peuvent également se connecter à Orthanc pour y télécharger des images (on parle de Query/Retrieve).
L'installation d'une instance d'Orthanc est immédiate, grâce au fait que le logiciel est auto-suffisant : il n'a notamment besoin d'aucun moteur de bases de données externe pour fonctionner. Orthanc peut être utilisé même sur des ordinateurs d'entrée de gamme, car il est basé sur une architecture légère.
Orthanc est flexible et versatile, puisqu'il propose également une interface de programmation de type REST. Un serveur Orthanc peut être piloté depuis n'importe quel langage de programmation afin d'automatiser les flux d'imagerie qui sont propres à chaque hôpital.
L'audience d'Orthanc se compose des administrateurs réseaux d'un hôpital, des physiciens médicaux, des chercheurs actifs dans le domaine de l'imagerie biomédicale, ainsi que des informaticiens qui développent des logiciels d'analyse d'images. Orthanc est d'ores et déjà utilisé en production dans deux hôpitaux belges pour fluidifier plusieurs processus cliniques réels (comme l'anonymisation et le routage automatique entre modalités DICOM). Orthanc peut être téléchargé et utilisé selon les termes de la licence GPLv3. Des exécutables officiels pour Microsoft Windows, Fedora et Debian sont disponibles.
Aller plus loin
- Site officiel (1086 clics)
- Facebook (43 clics)
- Twitter (27 clics)
- Vidéo de présentation pour le Prix Zénobe (385 clics)
# Pas d'existant ?
Posté par mael . Évalué à 2.
J'ai quand même un peu de mal à comprendre : DICOM est un standard, et aucune entreprise ne propose un logiciel qui permette de centraliser facilement la gestion des images qui viennent des différents appareils d'un hôpital ? Ou une question un peu plus générale : à l'heure actuelle, les hôpitaux ne bénéficient pas de logiciels qui centralisent la gestion des images ?
[^] # Re: Pas d'existant ?
Posté par visualstation . Évalué à 10.
C'est un marché de niche, ou seules les solutions liées aux constructeurs sont disponibles.
Que ce soit dans les hôpitaux, en médecine ou en dentisterie ou tout autre domaine médiale où la radiographie est là, à chaque produit (scanner, irm, système radiographique) on te propose le logiciel du constructeur et souvent, le logiciel n'est fait que pour fonctionner avec son produit mais peut lire une image au format DICOM ou seulement l'exporter.
Et vu le prix, les licences et le marché touché, une solution telle que celle proposée ici va permettre (je pense) d'avoir enfin une base saine pour l'archivage, gestion et l'échange des données "médico-radiographiques". Car actuellement, dans le domaine, il y a un monopole par rapport aux sociétés qui éditent les solutions et comme il n'y a pas de réelle norme pour la manière de gérer les radiographies, c'est une jungle.
[^] # Re: Pas d'existant ?
Posté par s.jodogne . Évalué à 7.
Je complète la réponse de visualstation. Bien sûr, tout hôpital possède une solution de centralisation pour son imagerie médicale : il s'agit de leur PACS, système qui est le plus souvent unique pour tout l'hôpital.
Par contre, il n'y a pas de solution commerciale à bas coût qui permette d'automatiser des tâches de routage d'imagerie médicale, entre systèmes propriétaires gérés par des firmes séparées. Les solutions commerciales existantes sont souvent liées au vendeur du PACS (d'où une dépendance technologique pour les hôpitaux), coûteuses et/ou sont lourdes à mettre en oeuvre (contrairement à Orthanc qui s'installe très facilement, même sur un ordinateur bas de gamme ou une machine virtuelle). Ce problème d'interfaçage est particulièrement problématique dans le cas de la radiothérapie, car ce processus médical est rarement entièrement intégré dans les fonctionnalités du PACS (qui est plutôt conçu pour la radiologie).
En outre, des tâches comme l'échange d'images, l'anonymisation, la création de fichiers ZIP ou la consultation/modification des tags DICOM sur un ordinateur de bureau sont encore difficiles à réaliser en routine clinique à l'heure actuelle. Orthanc y apporte une solution possible.
Le logiciel libre Orthanc ne remplacera jamais un PACS d'hôpital. Par exemple, il ne propose pas d'archivage de longue durée, ni d'outils de contourage ou de création de protocoles pour radiologues, ni d'interfaçage avec un système d'information radiologique ou hospitalier, ni de gestion des worklists.
Par contre, le projet Orthanc doit se voir comme un complément ouvert à un tel PACS propriétaire. Son interface de programmation REST et son interface Web sont deux fortes valeurs ajoutées, peu courantes dans le monde du libre, et utiles aux gestionnaires de réseaux hospitaliers.
[^] # Re: Pas d'existant ?
Posté par mael . Évalué à 1.
Merci à tous les deux pour vos réponses. C'est très intéressant.
[^] # Re: Pas d'existant ?
Posté par lolop (site web personnel) . Évalué à 5.
Pour les prochaine appels d'offres pour du matériel d'imagerie, pensez à ajouter systématiquement un point "Export direct vers Orthanc via son API REST"… pour que ça rentre dans les esprits des fabricants.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pas d'existant ?
Posté par visualstation . Évalué à 0.
Dans un cahier des charges publiques, même pour un logiciel libre, il est interdit de spécifier le nom d'une solution.
Tu peux jouer sur des notions vagues, mais pour peu que tu cloisonnes le cahier des charges, tu t'exposes à des ennuis judiciaires.
Si c'est un cahier des charges d'un hôpital privé, ca passera, mais dans le public, c'est une toute autre histoire.
[^] # Re: Pas d'existant ?
Posté par lolop (site web personnel) . Évalué à 3.
Parler de capacités d'export vers un serveur d'images DICOM ça rentre dans l'aspect "solution" ?
Peut-être faudrait-il faire normaliser l'API de transfert d'images, et alors se référer à cette normalisation—long processus. Ou encore parler plus génériquement d'interopérabilité, ou d'utilisation des standards…
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Pas d'existant ?
Posté par Kerro . Évalué à 6.
Le cas décrit ici est autorisé.
[^] # Re: Pas d'existant ?
Posté par NeoX . Évalué à 2.
et ca c'est autorisé ?
" nous voulons une suite bureautique, avec un bandeau/ruban utilisateur en haut, pour simplifier les usages et les formations "
[^] # Re: Pas d'existant ?
Posté par Kerro . Évalué à 2.
Aussi gros, j'en doute :-)
D'autant plus que l'argument de simplification peut-être utilisé par un répondant qui indique que les menus traditionnels sont simples.
Mais cela semble être une pratique courante pour travailler avec un prestataire ou éditeur précis.
Exemple pour de la vidéosurveillance : la résolution des caméras doit être au minimum de yyy x zzz. L'alimentation est obligatoirement simple et le raccordement au PSU se fait par fibre optique.
Or il n'existe qu'un seul modèle de caméra de vidéosurveillance qui ai la bonne résolution, et qui embarque une sortie fibre (donc pas de boîtier convertisseur, donc une seule alimentation).
Tous les répondants ont donné le même modèle de caméra.
Autre exemple toujours dans la vidéosurveillance : pour des raisons de pérénité, les sources du logiciel choisi devront être disponibles.
Parmi les éditeurs contactés, un seul propose du libre. Les autres font du propriétaire est refusent de fournir les sources. Donc l'appel d'offre est remporté par celui choisi au départ.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.