Dans le monde de l'imagerie médicale, la possibilité d'accéder facilement aux études de patients et de les récupérer à partir d'un système d'archivage et de communication d'images (PACS) est fondamentale. Que vous soyez un radiologue reprenant un scan antérieur à des fins de comparaison, un clinicien examinant des images au chevet d'un patient ou un développeur développant une nouvelle application médicale, vous vous fiez à un ensemble de commandes standardisées pour y parvenir.
Les deux commandes les plus discutées et souvent confuses pour cette tâche sont DICOM C-MOVE et C-GET.
À première vue, ils atteignent tous deux un objectif similaire : récupérer des études DICOM. Mais ils fonctionnent de manière fondamentalement différente, ce qui a des implications importantes pour le flux de travail, la configuration du réseau et le développement d'applications. Dans ce guide, nous allons démystifier ces deux commandes essentielles, répondre à vos principales questions et vous aider à comprendre laquelle correspond le mieux à vos besoins.
Allons plus loin et répondons aux grandes questions :
• Quelle est la vraie différence entre C-move et C-get ?
• Est-ce que C-get est retiré ou obsolète ?
• Dois-je utiliser C-move ou C-get pour mon application ?
• Pourquoi est-ce que C-move semble parfois plus lent ?
Avant de pouvoir récupérer une image, vous devez savoir qu'elle existe et où la trouver. Vous ne pouvez pas simplement demander à un PACS de « me faire passer la radiographie pulmonaire de Jane Doe ». « Vous devez d'abord interroger l'archive PACS. C'est là qu'intervient la commande C-FIND.
Pensez à C-FIND comme à la fonction de recherche de la bibliothèque PACS. Vous envoyez une requête avec des critères spécifiques (comme le nom du patient, l'identifiant du patient, la date de l'étude ou la modalité). Le PACS effectue ensuite une recherche dans sa base de données et renvoie une liste d'études correspondant à votre demande. Cela se fait souvent à l'aide d'une requête racine du patient DICOM, qui est un modèle de recherche hiérarchique allant du niveau du patient au niveau de la série et de l'image.
Une fois que C-FIND vous a fourni une liste d'identifiants uniques (UID) pour les études que vous souhaitez, vous êtes prêt à récupérer les données d'image réelles. C'est là que C-MOVE et C-GET entrent en scène.
C-MOVE est de loin la méthode de récupération la plus courante et la plus largement mise en œuvre dans les environnements PACS modernes. Le mot « MOVE » dans son nom est un peu impropre ; il ne déplace pas réellement les données au sens où elles seraient supprimées de la source. Il le copie. Une façon plus précise de considérer C-MOVE est de l'utiliser comme une commande « pousser » ou « avancer ».
Voici comment cela fonctionne :
1. Votre application (le client ou Scu) établit une connexion avec le Pacs (le serveur ou Scp).
2. Vous utilisez C-find pour localiser l'étude souhaitée.
3. Vous envoyez une demande C-move au Pacs. Cette demande comprend deux informations cruciales : les identifiants de l'étude que vous souhaitez récupérer. Le titre de l'entité de candidature (titre AE) de la destination à laquelle vous souhaitez que l'étude soit envoyée.
• Les identifiants de l'étude que vous souhaitez récupérer.
• Le titre de l'entité de candidature (ae title) de la destination à laquelle vous souhaitez envoyer l'étude.
4. Les identifiants de l'étude que vous souhaitez récupérer.
5. Le titre de l'entité de candidature (ae title) de la destination à laquelle vous souhaitez envoyer l'étude.
Cette destination peut être votre propre application, le poste de travail d'un radiologue, un système de planification chirurgicale ou tout autre appareil compatible DICOM sur le réseau.
L'essentiel à comprendre est que le PACS initie une nouvelle connexion distincte vers la destination spécifiée, puis « envoie » les images vers celle-ci à l'aide de la commande C-STORE. Votre application joue simplement le rôle d'orchestrateur, indiquant au PACS ce qu'il doit envoyer et où l'envoyer.
Analogie : utiliser C-MOVE, c'est comme commander un colis dans une boutique en ligne et le faire expédier directement au domicile de votre ami. Vous passez la commande (la demande C-MOVE), mais le magasin (le PACS) est responsable de la livraison effective (le push C-STORE) à l'adresse que vous avez fournie (la destination AE Title).
C-GET, comme son nom l'indique, est un modèle « pull ». Il s'agit d'une méthode de récupération plus simple et plus intuitive.
Voici le flux de travail C-GET :
1. Votre application (le client) établit une connexion avec le Pacs (le serveur).
2. Vous utilisez C-find pour localiser l'étude souhaitée.
3. Vous envoyez une demande C-get au Pacs, en spécifiant l'étude que vous souhaitez.
Le PACS renvoie ensuite les images demandées à votre application via la même connexion que celle que vous avez utilisée pour effectuer la demande. Il n'y a aucun tiers et aucune nouvelle connexion n'est initiée par le serveur.
Analogie : Utiliser C-GET, c'est comme aller dans une bibliothèque, trouver un livre et le consulter à la réception. L'ensemble de la transaction s'effectue directement entre vous et le bibliothécaire (le PACS) au même guichet (la même association réseau).
| Fonctionnalité | C-MOVE (« Poussez ») | C-GET (« Tirer ») |
| Modèle de communication | Modèle tripartite. Le client demande au serveur A d'envoyer des données à la destination B. | Modèle bipartite. Le client demande au serveur A de renvoyer les données au client. |
| Association du réseau | Le PACS (serveur) initie une nouvelle association avec la destination pour l'opération C-STORE. | L'ensemble de l'opération (FIND, GET, STORE) s'effectue via une seule association initiée par le client. |
| Configuration du réseau | Plus complexe. Le serveur PACS doit connaître le titre AE, l'adresse IP et le port de la destination. Les pare-feux doivent permettre au PACS d'établir des connexions vers l'extérieur. | Plus simple. Tant que le client peut accéder au PACS, cela devrait fonctionner. Aucune règle de pare-feu entrant n'est requise pour le client. |
| Adoption par l'industrie | La norme industrielle de facto. Pratiquement tous les fournisseurs de PACS modernes sont pris en charge. | Très faible taux d'adoption. Rarement mis en œuvre par les principaux fournisseurs de PACS. |
| Cas d'utilisation principal | Routage flexible des images dans une entreprise de santé (par exemple, de l'archive à une modalité ou à une station de travail de diagnostic). | Récupération simple et directe des images vers l'application qui fait la demande. |
Il s'agit d'une observation courante et d'un point clé dans le débat dicom entre c-move et c-get speed. Bien que C-GET puisse sembler plus rapide en théorie en raison de sa simplicité, la lenteur perçue de C-MOVE n'est généralement pas due au protocole lui-même, mais plutôt au contexte opérationnel :
1. Frais d'association : C-MOVE demande au PACS de négocier et d'établir une toute nouvelle association réseau avec la destination. Ce processus de prise de contact ajoute un peu de temps et de surcharge de traitement avant même que le premier octet de l'image ne soit envoyé.
2. Problèmes de configuration réseau : La cause la plus fréquente de défaillance ou de lenteur du C-MOVE est une configuration incorrecte. Si le titre AE, l'adresse IP ou le port du PACS ne sont pas corrects pour la destination, le transfert échouera. Les pare-feux qui empêchent le PACS d'établir des connexions sortantes sont un autre responsable fréquent. La résolution de ces problèmes peut prendre beaucoup de temps.
3. Gestion des ressources PACS : les serveurs PACS sont des systèmes très actifs. Ils peuvent mettre les demandes C-MOVE en file d'attente et les traiter en fonction de leur priorité, ce qui entraîne des retards. Comme C-MOVE dissocie la demande du transfert, le PACS a davantage de contrôle sur la planification de cette charge de travail.
Dans un réseau parfaitement configuré, la différence de vitesse pour le transfert des données brutes est négligeable. La « lenteur » est presque toujours liée à la phase de configuration et d'initiation.
Il s'agit d'une question cruciale. Officiellement, non, C-GET n'est pas retiré ou obsolète dans la norme DICOM. Elle reste une partie valide et définie de la spécification.
Cependant, dans la pratique, il est largement considéré comme « obsolète » par convention. « L'écrasante majorité des systèmes PACS et VNA (Vendor Neutral Archive) commerciaux ont choisi de ne pas implémenter le C-GET SCP (le composant côté serveur). Ils ont adopté C-MOVE il y a des décennies, car il offrait la flexibilité nécessaire aux réseaux hospitaliers complexes, où les données doivent être acheminées entre de nombreux systèmes différents.
Bien que vous puissiez trouver le support C-GET dans certaines boîtes à outils DICOM open source ou dans certaines applications de niche, vous ne devez jamais supposer qu'un PACS commercial le prendra en charge.
 - Created by PostDICOM.jpg)
La réponse est sans équivoque : vous devez créer votre application pour utiliser C-MOVE.
Baser la fonctionnalité de récupération de base de votre application sur C-GET est une recette d'incompatibilité. Vous limiteriez votre application à une infime partie des systèmes DICOM du monde.
Pour une compatibilité et une fiabilité maximales et pour garantir que votre application peut fonctionner dans n'importe quel environnement clinique moderne, la mise en œuvre d'une SCU C-MOVE robuste (côté client) est le seul choix professionnel. Bien qu'elle nécessite une gestion de configuration plus minutieuse (votre application devra être un SCP C-STORE pour recevoir les fichiers et être correctement configurée sur le PACS), il s'agit de la méthode de fonctionnement standard et attendue. Lorsque l'on réfléchit à l'utilisation de c-get dans DICOM, la réponse pratique est souvent « non », pour un produit réel. «
La gestion des titres AE, des règles de pare-feu et des nuances entre C-MOVE et C-GET peut être une perte de temps et de ressources importante. Cette gestion des protocoles de bas niveau est exactement le type de complexité que les solutions cloud modernes sont conçues pour éliminer.
PostDicom est un puissant PACS cloud qui simplifie l'ensemble du flux de travail d'imagerie médicale. Notre plateforme gère pour vous les subtilités de la communication DICOM, offrant une expérience fluide, sécurisée et intuitive. Grâce à notre visionneuse à faible encombrement et à nos archives basées sur le cloud, vous pouvez accéder, visualiser et partager des images médicales de n'importe où, sur n'importe quel appareil, sans jamais avoir à vous soucier de configurer une destination C-MOVE.
Arrêtez de vous enliser dans les détails du protocole et concentrez-vous sur ce qui compte le plus : les soins aux patients et l'efficacité clinique. Découvrez l'avenir de la gestion de l'imagerie médicale dès aujourd'hui.
Êtes-vous prêt à simplifier votre flux de travail ? Inscrivez-vous à votre essai gratuit de PostDicom et découvrez à quel point la gestion des images médicales peut être simple !
Cliquez ici pour obtenir votre essai gratuit dès maintenant !
