{"version":"1.1","schema_version":"1.1.0","plugin_version":"1.1.2","url":"https://tutos-gameserver.fr/2019/07/12/dicom-cest-facile-introduction-a-dicom-bien-choisir-son-serveur-d-impression/","llm_html_url":"https://tutos-gameserver.fr/2019/07/12/dicom-cest-facile-introduction-a-dicom-bien-choisir-son-serveur-d-impression/llm","llm_json_url":"https://tutos-gameserver.fr/2019/07/12/dicom-cest-facile-introduction-a-dicom-bien-choisir-son-serveur-d-impression/llm.json","manifest_url":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","language":"fr-FR","locale":"fr_FR","title":"DICOM c'est facile: Introduction à DICOM\n\n – Bien choisir son serveur d impression","site":{"name":"Tutos GameServer","url":"https://tutos-gameserver.fr/"},"author":{"id":1,"name":"Titanfall","url":"https://tutos-gameserver.fr/author/titanfall/"},"published_at":"2019-07-12T07:47:45+00:00","modified_at":"2019-07-12T07:47:45+00:00","word_count":4987,"reading_time_seconds":1497,"summary":"Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre. Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non? Dans ce post, […]","summary_points":["Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre.","Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non?","Dans ce post, nous discuterons:\n\n\nEntités d’application (AE) – les nœuds du réseau DICOM et leur nom – AE Title\nAssociation: session réseau entre homologues entre deux applications DICOM.","Association Negotiation – La première partie de l’association dans laquelle les deux AE se mettent d’accord sur ce qui peut et ne peut pas être fait pendant l’association\nLe service de vérification utilisant la commande C-ECHO – une classe de service DICOM utilisée pour vérifier une connexion, sorte de «niveau d’application» au niveau de l’application."],"topics":["Serveur d'impression"],"entities":[],"entities_metadata":[{"id":10,"name":"Serveur d'impression","slug":"serveur-dimpression","taxonomy":"category","count":3907,"url":"https://tutos-gameserver.fr/category/serveur-dimpression/"}],"tags":["Serveur d'impression"],"content_hash":"8bdbb3a60da6aab78fe3f7c304f8f788","plain_text":"Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre. Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non?\nDans ce post, nous discuterons:\n\n\nEntités d’application (AE) – les nœuds du réseau DICOM et leur nom – AE Title\nAssociation: session réseau entre homologues entre deux applications DICOM.\nAssociation Negotiation – La première partie de l’association dans laquelle les deux AE se mettent d’accord sur ce qui peut et ne peut pas être fait pendant l’association\nLe service de vérification utilisant la commande C-ECHO – une classe de service DICOM utilisée pour vérifier une connexion, sorte de «niveau d’application» au niveau de l’application.\nLe service de stockage utilisant la commande C-STORE – un service DICOM qui permet à un AE d'envoyer un objet DICOM à un autre AE\n\n\nLes commandes C dans C-ECHO et C-STORE désignent Composite. Si vous vous en souvenez, au chapitre 4 du modèle de données DICOM, nous avons expliqué que les applications DICOM échangent des objets composites (les images DICOM que nous connaissons déjà) qui sont des composites de modules de différents IE, les IE étant les entités d’information des données DICOM normalisées. modèle.\nVoici l'histoire:\n\nPlainte 20123\nBurt Simpson du Springfield Memorial Hospital a déclaré qu’il ne pouvait pas envoyer la capture d’écran au PACS. Il a continué à cliquer sur le bouton vert «Envoyer», mais il a toujours la même erreur: «Échec de l'opération!». Le fichier journal que Burt a copié à partir du système est joint.\n\n\nVous pouvez vous demander quel est l’intérêt d’analyser le journal d’une application que nous n’allons jamais utiliser? Eh bien, la vérité est que tous les journaux DICOM se ressemblent. En fait, la plupart des applications DICOM sont assez similaires car les implémentations logicielles DICOM ont des ancêtres communs. S'il s'agit d'une bibliothèque C, il peut s'agir du nœud de test DICOM, CTN. Si c’est Java, c’est peut-être dcm4che. Même s'il s'agit de PHP ou d'autres langages plus récents, les bibliothèques ont été transcrites et portées à partir des anciennes implémentations C afin que tous les journaux DICOM soient similaires.\nDans ce cas, le fichier journal, nommé DICOM-20111207-093017.log, a une longueur de 250 Mo et lorsque vous double-cliquez dessus, le bloc-notes se bloque pendant quelques minutes avant de se bloquer. Lorsque vous ouvrez le journal avec EXCEL, le même modèle se répète 100 fois, une fois pour chaque clic effectué par Burt. Après avoir isolé une répétition, vous voyez ce modèle relativement court avec exactement quatre entrées de journal que nous allons analyser ensemble.\n2011-12-1022: 22: 25.906000 1508 INFO Paramètres de demande d'association:\n\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\n\nLeur UID de classe d'implémentation: \n\nLeur nom de version d'implémentation: \n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNom de l'application qui répond: Titre de l'APP\n\nNotre Max PDU Receive Size: 32768\n\nLeur taille maximale de réception PDU: 0\n\n Le contexte\nID: 1 (proposé)\n\n Abstrait\nSyntaxe: = VerificationSOPClass\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Proposé\nSyntaxe de transfert:\n\n \n= LittleEndianExplicit\n\n \n= BigEndianExplicit\n\n \n= LittleEndianImplicit\n\n Le contexte\nID: 3 (proposé)\n\n Abstrait\nSyntaxe: = SecondaryCaptureImageStorage\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Transfert proposé\nSyntaxe (es):\n\n \n= LittleEndianExplicit\n\nNégociation prolongée demandée: aucune\n\nNégociation étendue acceptée: aucune\n\n2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Normal\n\nParamètres de réponse d'association:\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\n\nLeur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1\n\nLeur version de mise en œuvre Nom: softlink_jdt103\n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNom de l'application qui répond: PACS\n\nNotre Max PDU Receive Size: 32768\n\nLeur Max PDU Receive Size: 32768\n\n Le contexte\nID: 1 (accepté)\n\n Abstrait\nSyntaxe: = VerificationSOPClass\n\n Rôle proposé du SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Accepté\nSyntaxe de transfert: = LittleEndianImplicit\n\n Le contexte\nID: 3 (Syntaxe abstraite non\nPrise en charge)\n\n Abstrait\nSyntaxe: = SecondaryCaptureImageStorage\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\nNégociation prolongée demandée: aucune\n\nNégociation étendue acceptée: aucune\n\n2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe SOP n'était pas\nnégocié ou non accepté par les pairs. AMADOUER\nClasse UID: 1.2.840.10008.5.1.4.1.1.7, UID Instance UID:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2\n\n2011-12-1022: 22: 31.234000 1508 ERREUR dans DCXREQ, Code: 520, Texte: DIMSE Non valide\nID de contexte de présentation\n\n\nLe problème est clairement indiqué dans la troisième entrée du journal et marqué comme erreur dans la quatrième entrée. Cela dit que l'application homologue, celle que nous voulons envoyer à notre image, refuse de stocker ce type d'objet. Certaines boîtes à outils fournissent des informations utiles supplémentaires. Cependant, nous aurions pu deviner que ce serait déjà le problème dans la deuxième entrée du journal dans la réponse à la demande d'association, où le contexte de présentation pour la capture secondaire était marqué comme n'étant pas pris en charge par l'AE appelé.\nLe journal ci-dessus provient de la courte fonction C # suivante que j’ai écrite pour cet article:\n\n\n\n Publique vide SendSCImage (DCXOBJ o)\n\n DCXAPP app = Nouveau DCXAPP();\n\n app.LogLevel\n= LOG_LEVEL.LOG_LEVEL_INFO;\n\n app.StartLogging ("DICOM.log")\n\n essayer\n\n DCXREQ req = Nouveau DCXREQ();\n\n req.SendObject ("RZDCX", "PACS", "localhost",\n6104, o);\n\n capture (Exception e)\n\n Messagerie.Show (e.Message);\nAvec la fonction CreateSCImage que nous avons écrit ensemble au chapitre 4, nous avons ce petit programme qui crée une image secondaire en mémoire puis tente de l’envoyer:\n\n\n\n DCXOBJ o =\nCreateSCImage ();\n\nAvant d’analyser le journal, examinons le code de SendSCImage et assurez-vous de le comprendre.\nLes trois premières lignes créent une classe DCXAPP et définissent le niveau de journalisation sur un niveau inférieur au niveau le plus élevé ("Debug"). La classe DCXAPP est utilisée pour contrôler les paramètres globaux de RZDCX. Une fois qu'il est hors de portée, les paramètres restent.\nEnsuite, nous avons le bloc try-catch qui est très simple. Nous créons une classe DCXREQ et l’utilisons pour envoyer l’objet que nous avons créé à l’aide de la méthode SendObject. DCXREQ est un demandeur DICOM – une application DICOM qui initie le réseau DICOM avec une autre application et envoie des commandes DICOM. SendObject prend cinq (5) paramètres et encapsule tout le monde de la mise en réseau DICOM. L’ensemble de ce journal a été généré par cette méthode unique car il effectue tout le travail de mise en réseau DICOM pour vous et c’est exactement ce qui est unique dans RZDCX, vous n’aurez pas à traiter tous ces détails. Néanmoins, il est bon de savoir ce qui se passe à l’intérieur. Ainsi, lorsque la situation se gâte, vous avez une idée de ce qui pourrait mal tourner.\nComme toutes les autres méthodes de mise en réseau de DCXREQ, les quatre (4) premiers paramètres de SendObject sont utilisés pour établir la connexion réseau DICOM avec l'application DICOM distante.\nLe premier paramètre est notre titre d'entité d'application. Dans le réseau DICOM, chaque nœud est une entité d'application (AE) et son nom est AE Title. Vous vous demandez peut-être pourquoi nous avons besoin d'un titre AE si nous avons un nom de serveur ou une adresse IP et que la réponse est qu'un titre AE est en quelque sorte un alias pour la combinaison adresse IP et numéro de port. Nous pouvons exécuter de nombreuses applications DICOM sur un seul serveur. Je peux exécuter deux instances de mon PACS sur le même ordinateur, une sur le port 104, qui est le port TCP / IP standard réservé aux communications DICOM, et une autre sur le port 1104. Chaque application peut être complètement indépendante de l'autre. Je peux exécuter autant d'applications DICOM que je le souhaite, toutes ayant la même adresse IP. \nEn passant, DICOM est presque toujours utilisé dans un environnement de réseau local et je déconseille fortement à quiconque d’utiliser DICOM dans un environnement de réseau étendu, même si je sais que certaines personnes le font, mais ce n’est vraiment pas une bonne idée. Le protocole DICOM est interne, privé, sur votre réseau local, de préférence dans son propre sous-réseau dédié.\nLes titres AE sont sensibles à la casse, 16 caractères maximum.\nLe second paramètre est le titre AE de l'application à laquelle nous souhaitons nous connecter. Nous l'appelons parfois l'application cible ou appelé titre AE ou AE répondant ou simplement l'homologue.\nLe troisième paramètre est le nom du serveur (ou l'adresse IP) du serveur sur lequel l'AE appelé est exécuté.\nLe quatrième paramètre est le numéro de port écouté par l'AE appelé.\nCeci conclut les paramètres communs à toutes les méthodes réseau DCXREQ. Avec ces paramètres, nous pouvons commencer une ‘Association’ avec l’AE appelé.\nLe nouveau terme qui nous intéresse ici est Association. Qu'est-ce que c'est? C’est comme une session réseau. C’est un cadre dans lequel la conversation avec l’appelant appelé va avoir lieu.\nNous pouvons diviser la communication réseau DICOM en deux parties. La première partie configure l'association et la seconde échange des commandes DICOM.\n\n99% des difficultés liées à la mise en réseau DICOM sont liées à la première partie – la négociation d’association. \nMême si cette étape est passée et que nous commençons à échanger des commandes, il est probable que les problèmes proviennent de fautes dans la première partie.\n\nLe cinquième paramètre est l'objet que nous aimerions envoyer.SendObject effectue les opérations suivantes:\n\n\n\n\nDémarrer une connexion TCP / IP\nNégocie les paramètres d'association pour convenir de ce qui peut être fait pendant l'association\nEnvoyer l'objet DICOM\nFermer l'association\nFermer la connexion TCP / IP\n\n\nRevenons au journal et examinons maintenant la première partie du journal. C'est ici:\n\n2011-12-1022: 22: 25.906000 1508 paramètres de demande d'association INFO:\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\n\nLeur UID de classe d'implémentation: \n\nLeur nom de version d'implémentation: \n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNom de l'application qui répond: Titre de l'APP\n\nNotre Max PDU Receive Size: 32768\n\nLeur taille maximale de réception PDU: 0\n\nCette partie du journal est une sauvegarde textuelle de la première information envoyée à l'AE appelé et appelée Demande d'association. C’est un ensemble de paramètres décrivant notre application, ses capacités et ses intentions au cours de cette session.\nChaque entrée de journal dans le journal RZDCX commence par un horodatage, un ID de thread (1508 dans ce cas) et le niveau de journal de l'entrée (INFO dans ce cas). Dans le journal complet ci-dessus, j'ai mis en évidence les horodatages au début de chaque entrée du journal.\nLe premier élément de la demande d’association identifie notre implémentation DICOM.\n\n\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\nDans ce cas, il s’agit de l’UID RZDCX et du numéro de version. C’est toujours intéressant, car les boîtes à outils et les systèmes DICOM ont leurs propres petits problèmes. Par conséquent, si vous savez que certains systèmes ont un problème que vous avez déjà identifié et que vous voyez que vous utilisez la même mise en œuvre, vous savez comment le résoudre. Lors de la communication avec l’autre fournisseur d’applications, il est également important de signaler la version de l’application.\nDans le vidage de demandes, nous ne voyons que nos informations d'implémentation, mais plus loin dans le journal du vidage de réponses, nous verrons l'identification de l'AE appelé.\nEnsuite, nous avons le nom du contexte de l'application. Il s'agit d'un UID réservé à DICOM. C'est toujours la meme chose.\n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNous avons ensuite les titres AE: le titre AE appelant et le titre AE appelé.\n\n\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNotez qu’il s’agit simplement de la demande et que ce sont les valeurs que nous avons transmises à SendObject. Dans la réponse, nous aurons également ce qu'ils nous ont renvoyé. Habituellement, l'application qui répond à la demande d'association doit vérifier que l'AE appelé correspond à son propre AE et que l'AE appelant est quelque chose qui se trouve dans son fichier de configuration ou sa base de données. Si cela ne correspond pas, l'AE appelé peut rejeter l'association.\nEnsuite, nous avons la taille maximale de PDU. PDU est un ‘paquet’ au niveau de l’application qui indique quelle est la taille de la mémoire tampon que nous sommes disposés à utiliser pour chaque demande. \n\nNotre Max PDU Receive Size: 32768\n\nDans ce cas, nous ne proposons pas plus de 32K. Un problème connu est que certaines applications envoient une demande d’association si grosse que l’AE appelé ne peut pas consommer. Nous verrons dans une minute pourquoi ils le font et comment l’éviter.\nLe bloc suivant du journal fait toujours partie de la première entrée du journal. La demande d'association comprend une liste de services DICOM. Les éléments de cette liste sont appelés contextes de présentation:\n\n Le contexte\nID: 1 (proposé)\n\n Abstrait\nSyntaxe: = VerificationSOPClass\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Rôle SCP / SCU accepté: par défaut\n\n Proposé\nSyntaxe de transfert:\n\n \n= LittleEndianExplicit\n\n \n= BigEndianExplicit\n\n \n= LittleEndianImplicit\n\n Le contexte\nID: 3 (proposé)\n\n Abstrait\nSyntaxe: = SecondaryCaptureImageStorage\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Proposé\nSyntaxe de transfert:\n\n \n= LittleEndianExplicit\n\nNégociation prolongée demandée: aucune\n\nNégociation étendue acceptée: aucune\n\nNous avons envoyé une liste avec deux éléments. Chaque élément est un contexte de présentation et identifie un service DICOM que nous souhaitons utiliser lors de cette association. Les contextes de présentation sont étrangement numérotés. Le premier est 1, le second est 3 et un troisième aurait été 5. Pourquoi? Je ne sais pas. C'est comme ça. Comme je l'ai dit, ils sont étrangement numérotés.\nLe premier service que nous avons demandé est la vérification. Cette opération est effectuée à l'aide de la commande DICOM C-ECHO. Dans le journal, nous voyons ceci:\n\nSyntaxe abstraite:\n= VerificationSOPClass\n\nChaque service a un UID. Dans le fichier journal, les UID connus sont remplacés par leur nom. Le service de vérification est une sorte de ping de haut niveau. C-ECHO est une commande DICOM qui indique qu’une fois envoyé, l’homologue doit répondre avec un statut de réussite. Notez que nous n'avons pas encore envoyé de commande C-ECHO. Nous venons de demander à l'AE appelé dans notre demande d'association de l'utiliser dans la deuxième partie. Nous n’avons pas non plus dit que nous enverrions un C-ECHO. Une application DICOM qui écoute sur un port et attend les connexions entrantes doit toujours implémenter le service de vérification. Notre petite application n'écoute pas encore de port. À ce stade, nous jouons uniquement le rôle de client ici et nous nous connectons à une autre application. En tant que client, c’est toujours une bonne habitude de demander le service de vérification. Si nous ne le demandons pas et que l’application à laquelle nous nous connectons ne prend en charge aucun des autres services que nous demandons, elle nous le raccrochera. En ajoutant la vérification à notre demande, nous obligeons le serveur à dire oui pour au moins une chose que nous demandons.\nLe deuxième service que nous avons demandé est le stockage secondaire d’images de capture:\n\n\n\n\nSyntaxe abstraite:\n= SecondaryCaptureImageStorage\nSi vous vous en souvenez, lorsque nous avons parlé de SOP Class UID au chapitre 4, j’ai dit que SOP est une paire de services et de définition d’objet. Nous avons donc cette combinaison. Nous demandons à l'application homologue de stocker un objet que nous allons envoyer et nous lui dirons qu'il s'agira d'une image de capture secondaire. Si nous avions également un autre type d'objet, par exemple une image CT, nous aurions dû demander un troisième contexte de présentation. L'AE appelé peut autoriser ou interdire chacun des services. Il est donc possible de créer une application qui accepte des types d’objets spécifiques. Par exemple, si nous écrivons un poste de travail de reconstruction 3D pour les tomodensitogrammes, nous ne pouvons accepter que les images CT et obliger ainsi l’application d’envoi à nous envoyer ce type d’objets. Cependant, ce n’est pas une très bonne idée car les applications envoient généralement des études complètes et il peut y avoir dans une étude des images de différentes classes, par exemple une série avec un scanner, une autre avec un rapport et une autre avec un rayonnement. rapport de dose et si nous limitons notre poste de travail à accepter uniquement les images CT, l'application implémentée pour envoyer des études complètes conservera les échecs de rapport car ils ne peuvent pas envoyer les autres objets même si les images CT dont nous avions besoin sont arrivées. Une meilleure conception consisterait à autoriser tous les types d’objets et à ignorer ceux dont nous n’avons pas besoin.\nCe mécanisme de négociation de chaque type d’objet a conduit certains vendeurs à la très mauvaise habitude de simplement demander tous les objets possibles qu’ils connaissent. Cela peut entraîner une requête d'association longue de 50 Ko et si l'implémentation AE appelée ne peut lire que des requêtes de 32 Ko, elle peut facilement planter sur le bogue de débordement de mémoire tampon le plus simple. En outre, l'envoi d'une demande d'association 50K à chaque fois que vous souhaitez simplement vérifier une connexion à l'aide d'une commande C-ECHO est une pure perte de temps.\nSendObject de RZDCX ne négocie que les UID de classe SOP requis. La méthode d'envoi DCXREQ envoie un ensemble de fichiers DICOM. Tout d'abord, il passe en revue tous les fichiers, crée une liste de toutes leurs classes SOP, puis négocie cette liste avec le AE appelé.\nCeci conclut notre demande d'association. Nous nous sommes identifiés et avons déclaré ce que nous appelons. Voyons maintenant ce que l’AE appelé va dire. Après l'envoi de la demande d'association, l'AE appelé lit la demande et renvoie une réponse d'association. C'est presque identique à la demande. L’appelant AE remplit simplement le formulaire que nous avons envoyé. La deuxième entrée de ce journal est un vidage de cette réponse.\n\n\n\n\n2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Ordinaire\n\nParamètres de réponse d'association:\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\n\nLeur UID de classe d'implémentation: 1.2.826.0.1.3680043.2.60.0.1\n\nLeur nom de version d'implémentation: softlink_jdt103\n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNom de l'application qui répond: PACS\n\nNotre Max PDU Receive Size: 32768\n\nLeur taille maximale de réception PDU: 32768\n\n Le contexte\nID: 1 (Accepté)\n\n Abstrait\nSyntaxe: = VerificationSOPClass\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Accepté\nSyntaxe de transfert: = LittleEndianImplicit\n\n Le contexte\nID: 3 (Syntaxe abstraite non prise en charge)\n\n Abstrait\nSyntaxe: = SecondaryCaptureImageStorage\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\nNégociation prolongée demandée: aucune\n\nNégociation étendue acceptée: aucune\n\nD'après l'horodatage, vous pouvez voir qu'il est revenu juste un dixième de seconde après l'envoi de la demande et que l'état de la réponse est Normal (j'ai mis en surbrillance les paramètres qui étaient vides ou qui ont changé auparavant). Vous pouvez également voir que leur identification d'implémentation est maintenant renseignée avec la valeur softlink_jdt103, qui identifie un package utilitaire Java très pratique de Tiani. Leur titre AE est bien «PACS» et ils ont accepté notre demande d'association. Il y a quelques cas ici. Un cas est qu'ils ne répondent tout simplement pas. Dans ce cas, notre demande expirera sans obtenir de réponse. Un autre cas est ce que nous avons ici, c'est-à-dire que la demande d'association a été acceptée et que nous sommes maintenant connectés à l'AE appelé. Le troisième cas est que l’appelant appelé décide qu’il ne veut pas nous parler et envoie une réponse de rejet d’association. Par exemple, si son titre AE n'est pas «PACS», le message «Mauvais titre AE appelé» apparaît alors. Le motif du rejet est codé dans le statut de la réponse et comporte parfois une explication textuelle supplémentaire.\nNous avons également reçu la liste des services. La vérification a été acceptée, mais pas le stockage de capture secondaire. Cela signifie que si nous le souhaitons, nous pouvons envoyer une commande C-ECHO mais nous ne pouvons pas envoyer notre image de capture secondaire à l’aide d’un C-STORE. Parce que c’est ce que nous voulions faire dans cette association, vous voyez les deux prochaines entrées du journal:\n\n2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe d'opération n'a pas été négociée ou acceptée\npar les pairs. SID de classe UID:\n1.2.840.10008.5.1.4.1.1.7, UID d’instance SOP:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2\n\n2011-12-1022: 22: 31.234000 ERREUR 1508 dans DCXREQ, Code: 520, Texte: DIMSE Aucune présentation valide\nID de contexte\nCela signifie que nous ne pouvons pas stocker l’objet car l’homologue ne prend pas en charge ce service. Yippy! Nous pourrions en fait comprendre ce qui ne va pas ha?! Maintenant, Burt peut aller voir l’administrateur du PACS et lui demander pourquoi son PACS ne peut pas stocker les captures secondaires et l’administrateur du PACS va probablement demander à Burt sur quel serveur il a essayé de se connecter et sur quel port, puis indiquer que le port 6104 est le gestionnaire de listes de travail. qui servent les demandes de liste de travail de modalité et d’étapes de procédure effectuées (qui sont des services DICOM, nous en apprendrons plus tard) et que si nous voulons envoyer quelque chose au PACS, nous devons essayer de vous connecter au port 104. Cas résolu.\nOK, renouvelons cette opération et connectez-vous cette fois au port 104. C’est une bonne idée de pouvoir configurer le titre, l’adresse IP et le numéro de port de l’AE appelé dans notre application afin que nous n’ayons pas à compiler à chaque fois. La plupart des applications DICOM ont une telle configuration. Il s’agit généralement d’une table avec au moins les colonnes: Titre AE, hôte et port et éventuellement un identifiant et un commentaire. Voici le journal d’un envoi réussi. Cette fois, le niveau de journalisation a été défini sur Debug.\n\n2011-12-1512: 22: 51.000000 Association 4296 INFO\nParamètres de demande:\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\n\nLeur UID de classe d'implémentation: \n\nLeur nom de version d'implémentation: \n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNom de l'application qui répond: Titre de l'APP\n\nNotre Max PDU Receive Size: 32768\n\nLeur taille maximale de réception PDU: 0\n\n Le contexte\nID: 1 (proposé)\n\n Abstrait\nSyntaxe: = VerificationSOPClass\n\n Rôle proposé du SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Proposé\nSyntaxe de transfert:\n\n \n= LittleEndianExplicit\n\n \n= BigEndianExplicit\n\n \n= LittleEndianImplicit\n\n Le contexte\nID: 3 (proposé)\n\n Abstrait\nSyntaxe: = SecondaryCaptureImageStorage\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Proposé\nSyntaxe de transfert:\n\n \n= LittleEndianExplicit\n\nNégociation prolongée demandée: aucune\n\nNégociation étendue acceptée: aucune\n\n2011-12-1512: 22: 51.000000 4296 PDU RQ d'associé de construction DEBUG\n\n2011-12-1512: 22: 51.000000 4296 DEBUG WriteToConnection, longueur: 310, octets écrits:\n310, numéro de boucle: 1\n\n2011-12-1512: 22: 51.015000 4296 Type de PDU DEBUG: accepteur de partenariat, longueur de PDU: 216 +\nEn-tête PDU 6 octets\n\n 02 00\n00 00 00 d8 00\n01 00 00\n50 41 43\n53 20 20\n\n 20 20\n20 20 20 20 20\n20 20 20\n52 5a 44\n43 58 20\n\n 20 20\n20 20 20 20 20\n20 20 20\n00 00 00\n00 00 00\n\n 00 00\n00 00 00 00 00\n00 00 00\n00 00 00\n00 00 00\n\n 00 00\n00 00 00 00 00\n00 00 00\n10 00 00\n15 31 2e\n\n 32 2e\n38 34 30 2e 31\n30 30 30\n38 2e 33\n2e 31 2e\n\n 31 2e\n31 21 00 00 19\n01 00 00\n00 40 00\n00 11 31\n\n 2e 32\n2e 38 34 30 2e\n31 30 30\n30 38 2e\n31 2e 32\n\n 21 00\n00 1b 03\n00 00 00\n40 00 00\n13 31 2e\n32 2e\n\n 38 34\n30 2e 31 30 30\n30 38 2e\n31 2e 32\n2e 31 50\n\n 00 00\n3b 51 00 00 04\n00 00 80\n00 52 00\n00 1c 31\n\n 2e 32\n2e 38 32 36 2e\n30 2e 31\n2e 33 36\n38 30 30\n\n 34 33\n2e 32 2e\n36 30 2e\n30 2e 31\n55 00 00\n0f 73\n\n 6f 66\n74 6c 69 6e 6b\n5f 6a 64\n74 31 30 33\n\n2011-12-1512: 22: 51.015000 4296 INFO Résultat de la demande d'association: Normal\n\nParamètres de réponse d'association:\n\nNotre classe d'implémentation UID: 2.16.124.113543.6021.2\n\nNotre version de mise en œuvre Nom: RZDCX_2_0_1_8\n\nLeur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1\n\nLeur version de mise en œuvre Nom: softlink_jdt103\n\nNom du contexte d'application: 1.2.840.10008.3.1.1.1\n\nNom de l'application appelante: RZDCX\n\nNom de l'application appelée: PACS\n\nNom de l'application qui répond: PACS\n\nNotre Max PDU Receive Size: 32768\n\nLeur Max PDU Receive Size: 32768\n\n Le contexte\nID: 1 (Accepté)\n\n Abstrait\nSyntaxe: =VérificationSOPClass\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Accepté\nSyntaxe de transfert: = LittleEndianImplicit\n\n Le contexte\nID: 3 (Accepté)\n\n Abstrait\nSyntaxe: =SecondaryCaptureImageStorage\n\n Proposé\nRôle SCP / SCU: Par défaut\n\n Accepté\nRôle SCP / SCU: Par défaut\n\n Accepté\nSyntaxe de transfert: = LittleEndianExplicit\n\nNégociation prolongée demandée: aucune\n\nNégociation étendue acceptée: aucune\n\n2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE Commande à envoyer:\n\n# Used TransferSyntax: UnknownTransferSyntax\n\n(0000,0000) UL 0 # 4, 1 CommandGroupLength\n\n(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID\n\n(0000,0100) US 1 n ° 2, 1 CommandField\n\n(0000,0110) US 1 # 2, 1 MessageID\n\n(0000,0700) US 0 # 2, 1 priorité\n\n(0000,0800) US 1 # 2, 1 DataSetType\n\n(0000,1000) UI [2.16.124.113543.6021.1.3.3727584845.720.1323944568.6]\n# 52, 1 AffectedSOPInstanceUID\n\n2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 146 octets\n\n2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1\n\n2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 146, octets écrits:\n146, numéro de boucle: 1\n\n2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 7894 octets\n\n2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1\n\n2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 7894, octets\nécrit: 7894, boucle no: 1\n\n2011-12-1512: 22: 51.046000 4296 INFO DIMSE receiveCommand\n\n2011-12-1512: 22: 51.062000 4296 INFO DIMSE receiveCommand: 1 pdv (178 octets),\npresID = 3\n\n2011-12-1512: 22: 51.062000 4296 Commande DEBUG DIMSE reçue:\n\n# Used TransferSyntax: LittleEndianImplicit\n\n(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID\n\n(0000,0100) US 32769 N ° 2, 1 CommandField\n\n(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo\n\n(0000,0800) US 257 N ° 2, 1 DataSetType\n\n(0000,0900)\nUS 45056\n# 2, 1 Statut\n\n(0000,0902)\nLO [set InstanceNumber to 0]\n# 24, 1 ErrorComment\n\n(0000,1000) UI\n[2.16.124.113543.6021.1.3.3727584845.720.1323944568.6] # 52, 1 AffectedSOPInstanceUID\n\n2011-12-1512: 22: 51.062000 4296 DEBUG WriteToConnection, longueur: 10, octets écrits:\n10, numéro de boucle: 1\n\nLa commande de stockage a réussi, mais nous avons récupéré un statut d'avertissement (45056 = 0xB000) au lieu de succès (0x0000). Nous avons également reçu un commentaire d’avertissement indiquant que l’appelant appelé avait changé l’élément numéro d’instance de null à 0, peut-être afin de l’indexer correctement dans sa base de données.\nNous aurions dû parler de syntaxes de transfert, mais ceci est déjà un long post, je vais donc laisser les syntaxes de transfert pour une autre fois. \nRésumons ce que nous avons couvert dans cet article.\n\n\n\nLes nœuds du réseau DICOM sont appelés entités d'application (AE) et sont identifiés à l'aide d'un nom respectant la casse, appelé titre AE.\nLa communication DICOM se fait toujours entre deux AE, c’est-à-dire qu’elle est peer-to-peer.\nLa «session» DICOM s’appelle Association\nL'association est divisée en deux étapes. La première étape s'appelle la négociation d'association. Dans la deuxième étape, les commandes DICOM échangées par les deux AE\nDans la négociation d'association, l'AE demandeur envoie une liste de contextes de présentation identifiant les services DICOM qu'il souhaite utiliser, et l'AE répondant renvoie la même liste marquée des services acceptés et utilisables et des services qu'il a refusés et ne peuvent pas être utilisés. utilisé dans cette association.\nLe service de vérification est un service de niveau application utilisé pour vérifier la communication entre deux AE.\nLe service de stockage est utilisé pour transférer des objets DICOM entre AE. Le service de stockage est négocié séparément pour chaque classe SOP. Par exemple, une application peut autoriser le stockage d’images CT et interdire le stockage d’images MR. Ce n'est pas un bon design cependant.\n\nC'est tout. J'espère que vous me croyez toujours que DICOM est facile. Comme toujours, les commentaires sont les bienvenus.\n\n\nClick to rate this post!\r\n \r\n [Total: 0 Average: 0]","paragraphs":["Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre. Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non?\nDans ce post, nous discuterons:","Entités d’application (AE) – les nœuds du réseau DICOM et leur nom – AE Title\nAssociation: session réseau entre homologues entre deux applications DICOM.\nAssociation Negotiation – La première partie de l’association dans laquelle les deux AE se mettent d’accord sur ce qui peut et ne peut pas être fait pendant l’association\nLe service de vérification utilisant la commande C-ECHO – une classe de service DICOM utilisée pour vérifier une connexion, sorte de «niveau d’application» au niveau de l’application.\nLe service de stockage utilisant la commande C-STORE – un service DICOM qui permet à un AE d'envoyer un objet DICOM à un autre AE","Les commandes C dans C-ECHO et C-STORE désignent Composite. Si vous vous en souvenez, au chapitre 4 du modèle de données DICOM, nous avons expliqué que les applications DICOM échangent des objets composites (les images DICOM que nous connaissons déjà) qui sont des composites de modules de différents IE, les IE étant les entités d’information des données DICOM normalisées. modèle.\nVoici l'histoire:","Plainte 20123\nBurt Simpson du Springfield Memorial Hospital a déclaré qu’il ne pouvait pas envoyer la capture d’écran au PACS. Il a continué à cliquer sur le bouton vert «Envoyer», mais il a toujours la même erreur: «Échec de l'opération!». Le fichier journal que Burt a copié à partir du système est joint.","Vous pouvez vous demander quel est l’intérêt d’analyser le journal d’une application que nous n’allons jamais utiliser? Eh bien, la vérité est que tous les journaux DICOM se ressemblent. En fait, la plupart des applications DICOM sont assez similaires car les implémentations logicielles DICOM ont des ancêtres communs. S'il s'agit d'une bibliothèque C, il peut s'agir du nœud de test DICOM, CTN. Si c’est Java, c’est peut-être dcm4che. Même s'il s'agit de PHP ou d'autres langages plus récents, les bibliothèques ont été transcrites et portées à partir des anciennes implémentations C afin que tous les journaux DICOM soient similaires.\nDans ce cas, le fichier journal, nommé DICOM-20111207-093017.log, a une longueur de 250 Mo et lorsque vous double-cliquez dessus, le bloc-notes se bloque pendant quelques minutes avant de se bloquer. Lorsque vous ouvrez le journal avec EXCEL, le même modèle se répète 100 fois, une fois pour chaque clic effectué par Burt. Après avoir isolé une répétition, vous voyez ce modèle relativement court avec exactement quatre entrées de journal que nous allons analyser ensemble.\n2011-12-1022: 22: 25.906000 1508 INFO Paramètres de demande d'association:","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","Leur UID de classe d'implémentation:","Leur nom de version d'implémentation:","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Nom de l'application qui répond: Titre de l'APP","Notre Max PDU Receive Size: 32768","Leur taille maximale de réception PDU: 0","Le contexte\nID: 1 (proposé)","Abstrait\nSyntaxe: = VerificationSOPClass","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Proposé\nSyntaxe de transfert:","= LittleEndianExplicit","= BigEndianExplicit","= LittleEndianImplicit","Le contexte\nID: 3 (proposé)","Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Transfert proposé\nSyntaxe (es):","= LittleEndianExplicit","Négociation prolongée demandée: aucune","Négociation étendue acceptée: aucune","2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Normal","Paramètres de réponse d'association:","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1","Leur version de mise en œuvre Nom: softlink_jdt103","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Nom de l'application qui répond: PACS","Notre Max PDU Receive Size: 32768","Leur Max PDU Receive Size: 32768","Le contexte\nID: 1 (accepté)","Abstrait\nSyntaxe: = VerificationSOPClass","Rôle proposé du SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Accepté\nSyntaxe de transfert: = LittleEndianImplicit","Le contexte\nID: 3 (Syntaxe abstraite non\nPrise en charge)","Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Négociation prolongée demandée: aucune","Négociation étendue acceptée: aucune","2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe SOP n'était pas\nnégocié ou non accepté par les pairs. AMADOUER\nClasse UID: 1.2.840.10008.5.1.4.1.1.7, UID Instance UID:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2","2011-12-1022: 22: 31.234000 1508 ERREUR dans DCXREQ, Code: 520, Texte: DIMSE Non valide\nID de contexte de présentation","Le problème est clairement indiqué dans la troisième entrée du journal et marqué comme erreur dans la quatrième entrée. Cela dit que l'application homologue, celle que nous voulons envoyer à notre image, refuse de stocker ce type d'objet. Certaines boîtes à outils fournissent des informations utiles supplémentaires. Cependant, nous aurions pu deviner que ce serait déjà le problème dans la deuxième entrée du journal dans la réponse à la demande d'association, où le contexte de présentation pour la capture secondaire était marqué comme n'étant pas pris en charge par l'AE appelé.\nLe journal ci-dessus provient de la courte fonction C # suivante que j’ai écrite pour cet article:","Publique vide SendSCImage (DCXOBJ o)","DCXAPP app = Nouveau DCXAPP();","app.LogLevel\n= LOG_LEVEL.LOG_LEVEL_INFO;","app.StartLogging ("DICOM.log")","essayer","DCXREQ req = Nouveau DCXREQ();","req.SendObject ("RZDCX", "PACS", "localhost",\n6104, o);","capture (Exception e)","Messagerie.Show (e.Message);\nAvec la fonction CreateSCImage que nous avons écrit ensemble au chapitre 4, nous avons ce petit programme qui crée une image secondaire en mémoire puis tente de l’envoyer:","DCXOBJ o =\nCreateSCImage ();","Avant d’analyser le journal, examinons le code de SendSCImage et assurez-vous de le comprendre.\nLes trois premières lignes créent une classe DCXAPP et définissent le niveau de journalisation sur un niveau inférieur au niveau le plus élevé ("Debug"). La classe DCXAPP est utilisée pour contrôler les paramètres globaux de RZDCX. Une fois qu'il est hors de portée, les paramètres restent.\nEnsuite, nous avons le bloc try-catch qui est très simple. Nous créons une classe DCXREQ et l’utilisons pour envoyer l’objet que nous avons créé à l’aide de la méthode SendObject. DCXREQ est un demandeur DICOM – une application DICOM qui initie le réseau DICOM avec une autre application et envoie des commandes DICOM. SendObject prend cinq (5) paramètres et encapsule tout le monde de la mise en réseau DICOM. L’ensemble de ce journal a été généré par cette méthode unique car il effectue tout le travail de mise en réseau DICOM pour vous et c’est exactement ce qui est unique dans RZDCX, vous n’aurez pas à traiter tous ces détails. Néanmoins, il est bon de savoir ce qui se passe à l’intérieur. Ainsi, lorsque la situation se gâte, vous avez une idée de ce qui pourrait mal tourner.\nComme toutes les autres méthodes de mise en réseau de DCXREQ, les quatre (4) premiers paramètres de SendObject sont utilisés pour établir la connexion réseau DICOM avec l'application DICOM distante.\nLe premier paramètre est notre titre d'entité d'application. Dans le réseau DICOM, chaque nœud est une entité d'application (AE) et son nom est AE Title. Vous vous demandez peut-être pourquoi nous avons besoin d'un titre AE si nous avons un nom de serveur ou une adresse IP et que la réponse est qu'un titre AE est en quelque sorte un alias pour la combinaison adresse IP et numéro de port. Nous pouvons exécuter de nombreuses applications DICOM sur un seul serveur. Je peux exécuter deux instances de mon PACS sur le même ordinateur, une sur le port 104, qui est le port TCP / IP standard réservé aux communications DICOM, et une autre sur le port 1104. Chaque application peut être complètement indépendante de l'autre. Je peux exécuter autant d'applications DICOM que je le souhaite, toutes ayant la même adresse IP. \nEn passant, DICOM est presque toujours utilisé dans un environnement de réseau local et je déconseille fortement à quiconque d’utiliser DICOM dans un environnement de réseau étendu, même si je sais que certaines personnes le font, mais ce n’est vraiment pas une bonne idée. Le protocole DICOM est interne, privé, sur votre réseau local, de préférence dans son propre sous-réseau dédié.\nLes titres AE sont sensibles à la casse, 16 caractères maximum.\nLe second paramètre est le titre AE de l'application à laquelle nous souhaitons nous connecter. Nous l'appelons parfois l'application cible ou appelé titre AE ou AE répondant ou simplement l'homologue.\nLe troisième paramètre est le nom du serveur (ou l'adresse IP) du serveur sur lequel l'AE appelé est exécuté.\nLe quatrième paramètre est le numéro de port écouté par l'AE appelé.\nCeci conclut les paramètres communs à toutes les méthodes réseau DCXREQ. Avec ces paramètres, nous pouvons commencer une ‘Association’ avec l’AE appelé.\nLe nouveau terme qui nous intéresse ici est Association. Qu'est-ce que c'est? C’est comme une session réseau. C’est un cadre dans lequel la conversation avec l’appelant appelé va avoir lieu.\nNous pouvons diviser la communication réseau DICOM en deux parties. La première partie configure l'association et la seconde échange des commandes DICOM.","99% des difficultés liées à la mise en réseau DICOM sont liées à la première partie – la négociation d’association. \nMême si cette étape est passée et que nous commençons à échanger des commandes, il est probable que les problèmes proviennent de fautes dans la première partie.","Le cinquième paramètre est l'objet que nous aimerions envoyer.SendObject effectue les opérations suivantes:","Démarrer une connexion TCP / IP\nNégocie les paramètres d'association pour convenir de ce qui peut être fait pendant l'association\nEnvoyer l'objet DICOM\nFermer l'association\nFermer la connexion TCP / IP","Revenons au journal et examinons maintenant la première partie du journal. C'est ici:","2011-12-1022: 22: 25.906000 1508 paramètres de demande d'association INFO:","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","Leur UID de classe d'implémentation:","Leur nom de version d'implémentation:","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Nom de l'application qui répond: Titre de l'APP","Notre Max PDU Receive Size: 32768","Leur taille maximale de réception PDU: 0","Cette partie du journal est une sauvegarde textuelle de la première information envoyée à l'AE appelé et appelée Demande d'association. C’est un ensemble de paramètres décrivant notre application, ses capacités et ses intentions au cours de cette session.\nChaque entrée de journal dans le journal RZDCX commence par un horodatage, un ID de thread (1508 dans ce cas) et le niveau de journal de l'entrée (INFO dans ce cas). Dans le journal complet ci-dessus, j'ai mis en évidence les horodatages au début de chaque entrée du journal.\nLe premier élément de la demande d’association identifie notre implémentation DICOM.","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8\nDans ce cas, il s’agit de l’UID RZDCX et du numéro de version. C’est toujours intéressant, car les boîtes à outils et les systèmes DICOM ont leurs propres petits problèmes. Par conséquent, si vous savez que certains systèmes ont un problème que vous avez déjà identifié et que vous voyez que vous utilisez la même mise en œuvre, vous savez comment le résoudre. Lors de la communication avec l’autre fournisseur d’applications, il est également important de signaler la version de l’application.\nDans le vidage de demandes, nous ne voyons que nos informations d'implémentation, mais plus loin dans le journal du vidage de réponses, nous verrons l'identification de l'AE appelé.\nEnsuite, nous avons le nom du contexte de l'application. Il s'agit d'un UID réservé à DICOM. C'est toujours la meme chose.","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nous avons ensuite les titres AE: le titre AE appelant et le titre AE appelé.","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Notez qu’il s’agit simplement de la demande et que ce sont les valeurs que nous avons transmises à SendObject. Dans la réponse, nous aurons également ce qu'ils nous ont renvoyé. Habituellement, l'application qui répond à la demande d'association doit vérifier que l'AE appelé correspond à son propre AE et que l'AE appelant est quelque chose qui se trouve dans son fichier de configuration ou sa base de données. Si cela ne correspond pas, l'AE appelé peut rejeter l'association.\nEnsuite, nous avons la taille maximale de PDU. PDU est un ‘paquet’ au niveau de l’application qui indique quelle est la taille de la mémoire tampon que nous sommes disposés à utiliser pour chaque demande.","Notre Max PDU Receive Size: 32768","Dans ce cas, nous ne proposons pas plus de 32K. Un problème connu est que certaines applications envoient une demande d’association si grosse que l’AE appelé ne peut pas consommer. Nous verrons dans une minute pourquoi ils le font et comment l’éviter.\nLe bloc suivant du journal fait toujours partie de la première entrée du journal. La demande d'association comprend une liste de services DICOM. Les éléments de cette liste sont appelés contextes de présentation:","Le contexte\nID: 1 (proposé)","Abstrait\nSyntaxe: = VerificationSOPClass","Proposé\nRôle SCP / SCU: Par défaut","Rôle SCP / SCU accepté: par défaut","Proposé\nSyntaxe de transfert:","= LittleEndianExplicit","= BigEndianExplicit","= LittleEndianImplicit","Le contexte\nID: 3 (proposé)","Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Proposé\nSyntaxe de transfert:","= LittleEndianExplicit","Négociation prolongée demandée: aucune","Négociation étendue acceptée: aucune","Nous avons envoyé une liste avec deux éléments. Chaque élément est un contexte de présentation et identifie un service DICOM que nous souhaitons utiliser lors de cette association. Les contextes de présentation sont étrangement numérotés. Le premier est 1, le second est 3 et un troisième aurait été 5. Pourquoi? Je ne sais pas. C'est comme ça. Comme je l'ai dit, ils sont étrangement numérotés.\nLe premier service que nous avons demandé est la vérification. Cette opération est effectuée à l'aide de la commande DICOM C-ECHO. Dans le journal, nous voyons ceci:","Syntaxe abstraite:\n= VerificationSOPClass","Chaque service a un UID. Dans le fichier journal, les UID connus sont remplacés par leur nom. Le service de vérification est une sorte de ping de haut niveau. C-ECHO est une commande DICOM qui indique qu’une fois envoyé, l’homologue doit répondre avec un statut de réussite. Notez que nous n'avons pas encore envoyé de commande C-ECHO. Nous venons de demander à l'AE appelé dans notre demande d'association de l'utiliser dans la deuxième partie. Nous n’avons pas non plus dit que nous enverrions un C-ECHO. Une application DICOM qui écoute sur un port et attend les connexions entrantes doit toujours implémenter le service de vérification. Notre petite application n'écoute pas encore de port. À ce stade, nous jouons uniquement le rôle de client ici et nous nous connectons à une autre application. En tant que client, c’est toujours une bonne habitude de demander le service de vérification. Si nous ne le demandons pas et que l’application à laquelle nous nous connectons ne prend en charge aucun des autres services que nous demandons, elle nous le raccrochera. En ajoutant la vérification à notre demande, nous obligeons le serveur à dire oui pour au moins une chose que nous demandons.\nLe deuxième service que nous avons demandé est le stockage secondaire d’images de capture:","Syntaxe abstraite:\n= SecondaryCaptureImageStorage\nSi vous vous en souvenez, lorsque nous avons parlé de SOP Class UID au chapitre 4, j’ai dit que SOP est une paire de services et de définition d’objet. Nous avons donc cette combinaison. Nous demandons à l'application homologue de stocker un objet que nous allons envoyer et nous lui dirons qu'il s'agira d'une image de capture secondaire. Si nous avions également un autre type d'objet, par exemple une image CT, nous aurions dû demander un troisième contexte de présentation. L'AE appelé peut autoriser ou interdire chacun des services. Il est donc possible de créer une application qui accepte des types d’objets spécifiques. Par exemple, si nous écrivons un poste de travail de reconstruction 3D pour les tomodensitogrammes, nous ne pouvons accepter que les images CT et obliger ainsi l’application d’envoi à nous envoyer ce type d’objets. Cependant, ce n’est pas une très bonne idée car les applications envoient généralement des études complètes et il peut y avoir dans une étude des images de différentes classes, par exemple une série avec un scanner, une autre avec un rapport et une autre avec un rayonnement. rapport de dose et si nous limitons notre poste de travail à accepter uniquement les images CT, l'application implémentée pour envoyer des études complètes conservera les échecs de rapport car ils ne peuvent pas envoyer les autres objets même si les images CT dont nous avions besoin sont arrivées. Une meilleure conception consisterait à autoriser tous les types d’objets et à ignorer ceux dont nous n’avons pas besoin.\nCe mécanisme de négociation de chaque type d’objet a conduit certains vendeurs à la très mauvaise habitude de simplement demander tous les objets possibles qu’ils connaissent. Cela peut entraîner une requête d'association longue de 50 Ko et si l'implémentation AE appelée ne peut lire que des requêtes de 32 Ko, elle peut facilement planter sur le bogue de débordement de mémoire tampon le plus simple. En outre, l'envoi d'une demande d'association 50K à chaque fois que vous souhaitez simplement vérifier une connexion à l'aide d'une commande C-ECHO est une pure perte de temps.\nSendObject de RZDCX ne négocie que les UID de classe SOP requis. La méthode d'envoi DCXREQ envoie un ensemble de fichiers DICOM. Tout d'abord, il passe en revue tous les fichiers, crée une liste de toutes leurs classes SOP, puis négocie cette liste avec le AE appelé.\nCeci conclut notre demande d'association. Nous nous sommes identifiés et avons déclaré ce que nous appelons. Voyons maintenant ce que l’AE appelé va dire. Après l'envoi de la demande d'association, l'AE appelé lit la demande et renvoie une réponse d'association. C'est presque identique à la demande. L’appelant AE remplit simplement le formulaire que nous avons envoyé. La deuxième entrée de ce journal est un vidage de cette réponse.","2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Ordinaire","Paramètres de réponse d'association:","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","Leur UID de classe d'implémentation: 1.2.826.0.1.3680043.2.60.0.1","Leur nom de version d'implémentation: softlink_jdt103","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Nom de l'application qui répond: PACS","Notre Max PDU Receive Size: 32768","Leur taille maximale de réception PDU: 32768","Le contexte\nID: 1 (Accepté)","Abstrait\nSyntaxe: = VerificationSOPClass","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Accepté\nSyntaxe de transfert: = LittleEndianImplicit","Le contexte\nID: 3 (Syntaxe abstraite non prise en charge)","Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Négociation prolongée demandée: aucune","Négociation étendue acceptée: aucune","D'après l'horodatage, vous pouvez voir qu'il est revenu juste un dixième de seconde après l'envoi de la demande et que l'état de la réponse est Normal (j'ai mis en surbrillance les paramètres qui étaient vides ou qui ont changé auparavant). Vous pouvez également voir que leur identification d'implémentation est maintenant renseignée avec la valeur softlink_jdt103, qui identifie un package utilitaire Java très pratique de Tiani. Leur titre AE est bien «PACS» et ils ont accepté notre demande d'association. Il y a quelques cas ici. Un cas est qu'ils ne répondent tout simplement pas. Dans ce cas, notre demande expirera sans obtenir de réponse. Un autre cas est ce que nous avons ici, c'est-à-dire que la demande d'association a été acceptée et que nous sommes maintenant connectés à l'AE appelé. Le troisième cas est que l’appelant appelé décide qu’il ne veut pas nous parler et envoie une réponse de rejet d’association. Par exemple, si son titre AE n'est pas «PACS», le message «Mauvais titre AE appelé» apparaît alors. Le motif du rejet est codé dans le statut de la réponse et comporte parfois une explication textuelle supplémentaire.\nNous avons également reçu la liste des services. La vérification a été acceptée, mais pas le stockage de capture secondaire. Cela signifie que si nous le souhaitons, nous pouvons envoyer une commande C-ECHO mais nous ne pouvons pas envoyer notre image de capture secondaire à l’aide d’un C-STORE. Parce que c’est ce que nous voulions faire dans cette association, vous voyez les deux prochaines entrées du journal:","2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe d'opération n'a pas été négociée ou acceptée\npar les pairs. SID de classe UID:\n1.2.840.10008.5.1.4.1.1.7, UID d’instance SOP:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2","2011-12-1022: 22: 31.234000 ERREUR 1508 dans DCXREQ, Code: 520, Texte: DIMSE Aucune présentation valide\nID de contexte\nCela signifie que nous ne pouvons pas stocker l’objet car l’homologue ne prend pas en charge ce service. Yippy! Nous pourrions en fait comprendre ce qui ne va pas ha?! Maintenant, Burt peut aller voir l’administrateur du PACS et lui demander pourquoi son PACS ne peut pas stocker les captures secondaires et l’administrateur du PACS va probablement demander à Burt sur quel serveur il a essayé de se connecter et sur quel port, puis indiquer que le port 6104 est le gestionnaire de listes de travail. qui servent les demandes de liste de travail de modalité et d’étapes de procédure effectuées (qui sont des services DICOM, nous en apprendrons plus tard) et que si nous voulons envoyer quelque chose au PACS, nous devons essayer de vous connecter au port 104. Cas résolu.\nOK, renouvelons cette opération et connectez-vous cette fois au port 104. C’est une bonne idée de pouvoir configurer le titre, l’adresse IP et le numéro de port de l’AE appelé dans notre application afin que nous n’ayons pas à compiler à chaque fois. La plupart des applications DICOM ont une telle configuration. Il s’agit généralement d’une table avec au moins les colonnes: Titre AE, hôte et port et éventuellement un identifiant et un commentaire. Voici le journal d’un envoi réussi. Cette fois, le niveau de journalisation a été défini sur Debug.","2011-12-1512: 22: 51.000000 Association 4296 INFO\nParamètres de demande:","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","Leur UID de classe d'implémentation:","Leur nom de version d'implémentation:","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Nom de l'application qui répond: Titre de l'APP","Notre Max PDU Receive Size: 32768","Leur taille maximale de réception PDU: 0","Le contexte\nID: 1 (proposé)","Abstrait\nSyntaxe: = VerificationSOPClass","Rôle proposé du SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Proposé\nSyntaxe de transfert:","= LittleEndianExplicit","= BigEndianExplicit","= LittleEndianImplicit","Le contexte\nID: 3 (proposé)","Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Proposé\nSyntaxe de transfert:","= LittleEndianExplicit","Négociation prolongée demandée: aucune","Négociation étendue acceptée: aucune","2011-12-1512: 22: 51.000000 4296 PDU RQ d'associé de construction DEBUG","2011-12-1512: 22: 51.000000 4296 DEBUG WriteToConnection, longueur: 310, octets écrits:\n310, numéro de boucle: 1","2011-12-1512: 22: 51.015000 4296 Type de PDU DEBUG: accepteur de partenariat, longueur de PDU: 216 +\nEn-tête PDU 6 octets","02 00\n00 00 00 d8 00\n01 00 00\n50 41 43\n53 20 20","20 20\n20 20 20 20 20\n20 20 20\n52 5a 44\n43 58 20","20 20\n20 20 20 20 20\n20 20 20\n00 00 00\n00 00 00","00 00\n00 00 00 00 00\n00 00 00\n00 00 00\n00 00 00","00 00\n00 00 00 00 00\n00 00 00\n10 00 00\n15 31 2e","32 2e\n38 34 30 2e 31\n30 30 30\n38 2e 33\n2e 31 2e","31 2e\n31 21 00 00 19\n01 00 00\n00 40 00\n00 11 31","2e 32\n2e 38 34 30 2e\n31 30 30\n30 38 2e\n31 2e 32","21 00\n00 1b 03\n00 00 00\n40 00 00\n13 31 2e\n32 2e","38 34\n30 2e 31 30 30\n30 38 2e\n31 2e 32\n2e 31 50","00 00\n3b 51 00 00 04\n00 00 80\n00 52 00\n00 1c 31","2e 32\n2e 38 32 36 2e\n30 2e 31\n2e 33 36\n38 30 30","34 33\n2e 32 2e\n36 30 2e\n30 2e 31\n55 00 00\n0f 73","6f 66\n74 6c 69 6e 6b\n5f 6a 64\n74 31 30 33","2011-12-1512: 22: 51.015000 4296 INFO Résultat de la demande d'association: Normal","Paramètres de réponse d'association:","Notre classe d'implémentation UID: 2.16.124.113543.6021.2","Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1","Leur version de mise en œuvre Nom: softlink_jdt103","Nom du contexte d'application: 1.2.840.10008.3.1.1.1","Nom de l'application appelante: RZDCX","Nom de l'application appelée: PACS","Nom de l'application qui répond: PACS","Notre Max PDU Receive Size: 32768","Leur Max PDU Receive Size: 32768","Le contexte\nID: 1 (Accepté)","Abstrait\nSyntaxe: =VérificationSOPClass","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Accepté\nSyntaxe de transfert: = LittleEndianImplicit","Le contexte\nID: 3 (Accepté)","Abstrait\nSyntaxe: =SecondaryCaptureImageStorage","Proposé\nRôle SCP / SCU: Par défaut","Accepté\nRôle SCP / SCU: Par défaut","Accepté\nSyntaxe de transfert: = LittleEndianExplicit","Négociation prolongée demandée: aucune","Négociation étendue acceptée: aucune","2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE Commande à envoyer:","# Used TransferSyntax: UnknownTransferSyntax","(0000,0000) UL 0 # 4, 1 CommandGroupLength","(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID","(0000,0100) US 1 n ° 2, 1 CommandField","(0000,0110) US 1 # 2, 1 MessageID","(0000,0700) US 0 # 2, 1 priorité","(0000,0800) US 1 # 2, 1 DataSetType","(0000,1000) UI [2.16.124.113543.6021.1.3.3727584845.720.1323944568.6]\n# 52, 1 AffectedSOPInstanceUID","2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 146 octets","2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1","2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 146, octets écrits:\n146, numéro de boucle: 1","2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 7894 octets","2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1","2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 7894, octets\nécrit: 7894, boucle no: 1","2011-12-1512: 22: 51.046000 4296 INFO DIMSE receiveCommand","2011-12-1512: 22: 51.062000 4296 INFO DIMSE receiveCommand: 1 pdv (178 octets),\npresID = 3","2011-12-1512: 22: 51.062000 4296 Commande DEBUG DIMSE reçue:","# Used TransferSyntax: LittleEndianImplicit","(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID","(0000,0100) US 32769 N ° 2, 1 CommandField","(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo","(0000,0800) US 257 N ° 2, 1 DataSetType","(0000,0900)\nUS 45056\n# 2, 1 Statut","(0000,0902)\nLO [set InstanceNumber to 0]\n# 24, 1 ErrorComment","(0000,1000) UI\n[2.16.124.113543.6021.1.3.3727584845.720.1323944568.6] # 52, 1 AffectedSOPInstanceUID","2011-12-1512: 22: 51.062000 4296 DEBUG WriteToConnection, longueur: 10, octets écrits:\n10, numéro de boucle: 1","La commande de stockage a réussi, mais nous avons récupéré un statut d'avertissement (45056 = 0xB000) au lieu de succès (0x0000). Nous avons également reçu un commentaire d’avertissement indiquant que l’appelant appelé avait changé l’élément numéro d’instance de null à 0, peut-être afin de l’indexer correctement dans sa base de données.\nNous aurions dû parler de syntaxes de transfert, mais ceci est déjà un long post, je vais donc laisser les syntaxes de transfert pour une autre fois. \nRésumons ce que nous avons couvert dans cet article.","Les nœuds du réseau DICOM sont appelés entités d'application (AE) et sont identifiés à l'aide d'un nom respectant la casse, appelé titre AE.\nLa communication DICOM se fait toujours entre deux AE, c’est-à-dire qu’elle est peer-to-peer.\nLa «session» DICOM s’appelle Association\nL'association est divisée en deux étapes. La première étape s'appelle la négociation d'association. Dans la deuxième étape, les commandes DICOM échangées par les deux AE\nDans la négociation d'association, l'AE demandeur envoie une liste de contextes de présentation identifiant les services DICOM qu'il souhaite utiliser, et l'AE répondant renvoie la même liste marquée des services acceptés et utilisables et des services qu'il a refusés et ne peuvent pas être utilisés. utilisé dans cette association.\nLe service de vérification est un service de niveau application utilisé pour vérifier la communication entre deux AE.\nLe service de stockage est utilisé pour transférer des objets DICOM entre AE. Le service de stockage est négocié séparément pour chaque classe SOP. Par exemple, une application peut autoriser le stockage d’images CT et interdire le stockage d’images MR. Ce n'est pas un bon design cependant.","C'est tout. J'espère que vous me croyez toujours que DICOM est facile. Comme toujours, les commentaires sont les bienvenus.","Click to rate this post!\n \n [Total: 0 Average: 0]"],"content_blocks":[{"id":"text-1","type":"text","heading":"","plain_text":"Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre. Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non?\nDans ce post, nous discuterons:","html":"

Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre. Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non?\nDans ce post, nous discuterons:

"},{"id":"text-2","type":"text","heading":"","plain_text":"Entités d’application (AE) – les nœuds du réseau DICOM et leur nom – AE Title\nAssociation: session réseau entre homologues entre deux applications DICOM.\nAssociation Negotiation – La première partie de l’association dans laquelle les deux AE se mettent d’accord sur ce qui peut et ne peut pas être fait pendant l’association\nLe service de vérification utilisant la commande C-ECHO – une classe de service DICOM utilisée pour vérifier une connexion, sorte de «niveau d’application» au niveau de l’application.\nLe service de stockage utilisant la commande C-STORE – un service DICOM qui permet à un AE d'envoyer un objet DICOM à un autre AE","html":"

Entités d’application (AE) – les nœuds du réseau DICOM et leur nom – AE Title\nAssociation: session réseau entre homologues entre deux applications DICOM.\nAssociation Negotiation – La première partie de l’association dans laquelle les deux AE se mettent d’accord sur ce qui peut et ne peut pas être fait pendant l’association\nLe service de vérification utilisant la commande C-ECHO – une classe de service DICOM utilisée pour vérifier une connexion, sorte de «niveau d’application» au niveau de l’application.\nLe service de stockage utilisant la commande C-STORE – un service DICOM qui permet à un AE d'envoyer un objet DICOM à un autre AE

"},{"id":"text-3","type":"text","heading":"","plain_text":"Les commandes C dans C-ECHO et C-STORE désignent Composite. Si vous vous en souvenez, au chapitre 4 du modèle de données DICOM, nous avons expliqué que les applications DICOM échangent des objets composites (les images DICOM que nous connaissons déjà) qui sont des composites de modules de différents IE, les IE étant les entités d’information des données DICOM normalisées. modèle.\nVoici l'histoire:","html":"

Les commandes C dans C-ECHO et C-STORE désignent Composite. Si vous vous en souvenez, au chapitre 4 du modèle de données DICOM, nous avons expliqué que les applications DICOM échangent des objets composites (les images DICOM que nous connaissons déjà) qui sont des composites de modules de différents IE, les IE étant les entités d’information des données DICOM normalisées. modèle.\nVoici l'histoire:

"},{"id":"text-4","type":"text","heading":"","plain_text":"Plainte 20123\nBurt Simpson du Springfield Memorial Hospital a déclaré qu’il ne pouvait pas envoyer la capture d’écran au PACS. Il a continué à cliquer sur le bouton vert «Envoyer», mais il a toujours la même erreur: «Échec de l'opération!». Le fichier journal que Burt a copié à partir du système est joint.","html":"

Plainte 20123\nBurt Simpson du Springfield Memorial Hospital a déclaré qu’il ne pouvait pas envoyer la capture d’écran au PACS. Il a continué à cliquer sur le bouton vert «Envoyer», mais il a toujours la même erreur: «Échec de l'opération!». Le fichier journal que Burt a copié à partir du système est joint.

"},{"id":"text-5","type":"text","heading":"","plain_text":"Vous pouvez vous demander quel est l’intérêt d’analyser le journal d’une application que nous n’allons jamais utiliser? Eh bien, la vérité est que tous les journaux DICOM se ressemblent. En fait, la plupart des applications DICOM sont assez similaires car les implémentations logicielles DICOM ont des ancêtres communs. S'il s'agit d'une bibliothèque C, il peut s'agir du nœud de test DICOM, CTN. Si c’est Java, c’est peut-être dcm4che. Même s'il s'agit de PHP ou d'autres langages plus récents, les bibliothèques ont été transcrites et portées à partir des anciennes implémentations C afin que tous les journaux DICOM soient similaires.\nDans ce cas, le fichier journal, nommé DICOM-20111207-093017.log, a une longueur de 250 Mo et lorsque vous double-cliquez dessus, le bloc-notes se bloque pendant quelques minutes avant de se bloquer. Lorsque vous ouvrez le journal avec EXCEL, le même modèle se répète 100 fois, une fois pour chaque clic effectué par Burt. Après avoir isolé une répétition, vous voyez ce modèle relativement court avec exactement quatre entrées de journal que nous allons analyser ensemble.\n2011-12-1022: 22: 25.906000 1508 INFO Paramètres de demande d'association:","html":"

Vous pouvez vous demander quel est l’intérêt d’analyser le journal d’une application que nous n’allons jamais utiliser? Eh bien, la vérité est que tous les journaux DICOM se ressemblent. En fait, la plupart des applications DICOM sont assez similaires car les implémentations logicielles DICOM ont des ancêtres communs. S'il s'agit d'une bibliothèque C, il peut s'agir du nœud de test DICOM, CTN. Si c’est Java, c’est peut-être dcm4che. Même s'il s'agit de PHP ou d'autres langages plus récents, les bibliothèques ont été transcrites et portées à partir des anciennes implémentations C afin que tous les journaux DICOM soient similaires.\nDans ce cas, le fichier journal, nommé DICOM-20111207-093017.log, a une longueur de 250 Mo et lorsque vous double-cliquez dessus, le bloc-notes se bloque pendant quelques minutes avant de se bloquer. Lorsque vous ouvrez le journal avec EXCEL, le même modèle se répète 100 fois, une fois pour chaque clic effectué par Burt. Après avoir isolé une répétition, vous voyez ce modèle relativement court avec exactement quatre entrées de journal que nous allons analyser ensemble.\n2011-12-1022: 22: 25.906000 1508 INFO Paramètres de demande d'association:

"},{"id":"text-6","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-7","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8

"},{"id":"text-8","type":"text","heading":"","plain_text":"Leur UID de classe d'implémentation:","html":"

Leur UID de classe d'implémentation:

"},{"id":"text-9","type":"text","heading":"","plain_text":"Leur nom de version d'implémentation:","html":"

Leur nom de version d'implémentation:

"},{"id":"text-10","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-11","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-12","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-13","type":"text","heading":"","plain_text":"Nom de l'application qui répond: Titre de l'APP","html":"

Nom de l'application qui répond: Titre de l'APP

"},{"id":"text-14","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-15","type":"text","heading":"","plain_text":"Leur taille maximale de réception PDU: 0","html":"

Leur taille maximale de réception PDU: 0

"},{"id":"text-16","type":"text","heading":"","plain_text":"Le contexte\nID: 1 (proposé)","html":"

Le contexte\nID: 1 (proposé)

"},{"id":"text-17","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = VerificationSOPClass","html":"

Abstrait\nSyntaxe: = VerificationSOPClass

"},{"id":"text-18","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-19","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-20","type":"text","heading":"","plain_text":"Proposé\nSyntaxe de transfert:","html":"

Proposé\nSyntaxe de transfert:

"},{"id":"text-21","type":"text","heading":"","plain_text":"= LittleEndianExplicit","html":"

= LittleEndianExplicit

"},{"id":"text-22","type":"text","heading":"","plain_text":"= BigEndianExplicit","html":"

= BigEndianExplicit

"},{"id":"text-23","type":"text","heading":"","plain_text":"= LittleEndianImplicit","html":"

= LittleEndianImplicit

"},{"id":"text-24","type":"text","heading":"","plain_text":"Le contexte\nID: 3 (proposé)","html":"

Le contexte\nID: 3 (proposé)

"},{"id":"text-25","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","html":"

Abstrait\nSyntaxe: = SecondaryCaptureImageStorage

"},{"id":"text-26","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-27","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-28","type":"text","heading":"","plain_text":"Transfert proposé\nSyntaxe (es):","html":"

Transfert proposé\nSyntaxe (es):

"},{"id":"text-29","type":"text","heading":"","plain_text":"= LittleEndianExplicit","html":"

= LittleEndianExplicit

"},{"id":"text-30","type":"text","heading":"","plain_text":"Négociation prolongée demandée: aucune","html":"

Négociation prolongée demandée: aucune

"},{"id":"text-31","type":"text","heading":"","plain_text":"Négociation étendue acceptée: aucune","html":"

Négociation étendue acceptée: aucune

"},{"id":"text-32","type":"text","heading":"","plain_text":"2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Normal","html":"

2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Normal

"},{"id":"text-33","type":"text","heading":"","plain_text":"Paramètres de réponse d'association:","html":"

Paramètres de réponse d'association:

"},{"id":"text-34","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-35","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8

"},{"id":"text-36","type":"text","heading":"","plain_text":"Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1","html":"

Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1

"},{"id":"text-37","type":"text","heading":"","plain_text":"Leur version de mise en œuvre Nom: softlink_jdt103","html":"

Leur version de mise en œuvre Nom: softlink_jdt103

"},{"id":"text-38","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-39","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-40","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-41","type":"text","heading":"","plain_text":"Nom de l'application qui répond: PACS","html":"

Nom de l'application qui répond: PACS

"},{"id":"text-42","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-43","type":"text","heading":"","plain_text":"Leur Max PDU Receive Size: 32768","html":"

Leur Max PDU Receive Size: 32768

"},{"id":"text-44","type":"text","heading":"","plain_text":"Le contexte\nID: 1 (accepté)","html":"

Le contexte\nID: 1 (accepté)

"},{"id":"text-45","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = VerificationSOPClass","html":"

Abstrait\nSyntaxe: = VerificationSOPClass

"},{"id":"text-46","type":"text","heading":"","plain_text":"Rôle proposé du SCP / SCU: Par défaut","html":"

Rôle proposé du SCP / SCU: Par défaut

"},{"id":"text-47","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-48","type":"text","heading":"","plain_text":"Accepté\nSyntaxe de transfert: = LittleEndianImplicit","html":"

Accepté\nSyntaxe de transfert: = LittleEndianImplicit

"},{"id":"text-49","type":"text","heading":"","plain_text":"Le contexte\nID: 3 (Syntaxe abstraite non\nPrise en charge)","html":"

Le contexte\nID: 3 (Syntaxe abstraite non\nPrise en charge)

"},{"id":"text-50","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","html":"

Abstrait\nSyntaxe: = SecondaryCaptureImageStorage

"},{"id":"text-51","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-52","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-53","type":"text","heading":"","plain_text":"Négociation prolongée demandée: aucune","html":"

Négociation prolongée demandée: aucune

"},{"id":"text-54","type":"text","heading":"","plain_text":"Négociation étendue acceptée: aucune","html":"

Négociation étendue acceptée: aucune

"},{"id":"text-55","type":"text","heading":"","plain_text":"2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe SOP n'était pas\nnégocié ou non accepté par les pairs. AMADOUER\nClasse UID: 1.2.840.10008.5.1.4.1.1.7, UID Instance UID:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2","html":"

2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe SOP n'était pas\nnégocié ou non accepté par les pairs. AMADOUER\nClasse UID: 1.2.840.10008.5.1.4.1.1.7, UID Instance UID:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2

"},{"id":"text-56","type":"text","heading":"","plain_text":"2011-12-1022: 22: 31.234000 1508 ERREUR dans DCXREQ, Code: 520, Texte: DIMSE Non valide\nID de contexte de présentation","html":"

2011-12-1022: 22: 31.234000 1508 ERREUR dans DCXREQ, Code: 520, Texte: DIMSE Non valide\nID de contexte de présentation

"},{"id":"text-57","type":"text","heading":"","plain_text":"Le problème est clairement indiqué dans la troisième entrée du journal et marqué comme erreur dans la quatrième entrée. Cela dit que l'application homologue, celle que nous voulons envoyer à notre image, refuse de stocker ce type d'objet. Certaines boîtes à outils fournissent des informations utiles supplémentaires. Cependant, nous aurions pu deviner que ce serait déjà le problème dans la deuxième entrée du journal dans la réponse à la demande d'association, où le contexte de présentation pour la capture secondaire était marqué comme n'étant pas pris en charge par l'AE appelé.\nLe journal ci-dessus provient de la courte fonction C # suivante que j’ai écrite pour cet article:","html":"

Le problème est clairement indiqué dans la troisième entrée du journal et marqué comme erreur dans la quatrième entrée. Cela dit que l'application homologue, celle que nous voulons envoyer à notre image, refuse de stocker ce type d'objet. Certaines boîtes à outils fournissent des informations utiles supplémentaires. Cependant, nous aurions pu deviner que ce serait déjà le problème dans la deuxième entrée du journal dans la réponse à la demande d'association, où le contexte de présentation pour la capture secondaire était marqué comme n'étant pas pris en charge par l'AE appelé.\nLe journal ci-dessus provient de la courte fonction C # suivante que j’ai écrite pour cet article:

"},{"id":"text-58","type":"text","heading":"","plain_text":"Publique vide SendSCImage (DCXOBJ o)","html":"

Publique vide SendSCImage (DCXOBJ o)

"},{"id":"text-59","type":"text","heading":"","plain_text":"DCXAPP app = Nouveau DCXAPP();","html":"

DCXAPP app = Nouveau DCXAPP();

"},{"id":"text-60","type":"text","heading":"","plain_text":"app.LogLevel\n= LOG_LEVEL.LOG_LEVEL_INFO;","html":"

app.LogLevel\n= LOG_LEVEL.LOG_LEVEL_INFO;

"},{"id":"text-61","type":"text","heading":"","plain_text":"app.StartLogging ("DICOM.log")","html":"

app.StartLogging ("DICOM.log")

"},{"id":"text-62","type":"text","heading":"","plain_text":"essayer","html":"

essayer

"},{"id":"text-63","type":"text","heading":"","plain_text":"DCXREQ req = Nouveau DCXREQ();","html":"

DCXREQ req = Nouveau DCXREQ();

"},{"id":"text-64","type":"text","heading":"","plain_text":"req.SendObject ("RZDCX", "PACS", "localhost",\n6104, o);","html":"

req.SendObject ("RZDCX", "PACS", "localhost",\n6104, o);

"},{"id":"text-65","type":"text","heading":"","plain_text":"capture (Exception e)","html":"

capture (Exception e)

"},{"id":"text-66","type":"text","heading":"","plain_text":"Messagerie.Show (e.Message);\nAvec la fonction CreateSCImage que nous avons écrit ensemble au chapitre 4, nous avons ce petit programme qui crée une image secondaire en mémoire puis tente de l’envoyer:","html":"

Messagerie.Show (e.Message);\nAvec la fonction CreateSCImage que nous avons écrit ensemble au chapitre 4, nous avons ce petit programme qui crée une image secondaire en mémoire puis tente de l’envoyer:

"},{"id":"text-67","type":"text","heading":"","plain_text":"DCXOBJ o =\nCreateSCImage ();","html":"

DCXOBJ o =\nCreateSCImage ();

"},{"id":"text-68","type":"text","heading":"","plain_text":"Avant d’analyser le journal, examinons le code de SendSCImage et assurez-vous de le comprendre.\nLes trois premières lignes créent une classe DCXAPP et définissent le niveau de journalisation sur un niveau inférieur au niveau le plus élevé ("Debug"). La classe DCXAPP est utilisée pour contrôler les paramètres globaux de RZDCX. Une fois qu'il est hors de portée, les paramètres restent.\nEnsuite, nous avons le bloc try-catch qui est très simple. Nous créons une classe DCXREQ et l’utilisons pour envoyer l’objet que nous avons créé à l’aide de la méthode SendObject. DCXREQ est un demandeur DICOM – une application DICOM qui initie le réseau DICOM avec une autre application et envoie des commandes DICOM. SendObject prend cinq (5) paramètres et encapsule tout le monde de la mise en réseau DICOM. L’ensemble de ce journal a été généré par cette méthode unique car il effectue tout le travail de mise en réseau DICOM pour vous et c’est exactement ce qui est unique dans RZDCX, vous n’aurez pas à traiter tous ces détails. Néanmoins, il est bon de savoir ce qui se passe à l’intérieur. Ainsi, lorsque la situation se gâte, vous avez une idée de ce qui pourrait mal tourner.\nComme toutes les autres méthodes de mise en réseau de DCXREQ, les quatre (4) premiers paramètres de SendObject sont utilisés pour établir la connexion réseau DICOM avec l'application DICOM distante.\nLe premier paramètre est notre titre d'entité d'application. Dans le réseau DICOM, chaque nœud est une entité d'application (AE) et son nom est AE Title. Vous vous demandez peut-être pourquoi nous avons besoin d'un titre AE si nous avons un nom de serveur ou une adresse IP et que la réponse est qu'un titre AE est en quelque sorte un alias pour la combinaison adresse IP et numéro de port. Nous pouvons exécuter de nombreuses applications DICOM sur un seul serveur. Je peux exécuter deux instances de mon PACS sur le même ordinateur, une sur le port 104, qui est le port TCP / IP standard réservé aux communications DICOM, et une autre sur le port 1104. Chaque application peut être complètement indépendante de l'autre. Je peux exécuter autant d'applications DICOM que je le souhaite, toutes ayant la même adresse IP. \nEn passant, DICOM est presque toujours utilisé dans un environnement de réseau local et je déconseille fortement à quiconque d’utiliser DICOM dans un environnement de réseau étendu, même si je sais que certaines personnes le font, mais ce n’est vraiment pas une bonne idée. Le protocole DICOM est interne, privé, sur votre réseau local, de préférence dans son propre sous-réseau dédié.\nLes titres AE sont sensibles à la casse, 16 caractères maximum.\nLe second paramètre est le titre AE de l'application à laquelle nous souhaitons nous connecter. Nous l'appelons parfois l'application cible ou appelé titre AE ou AE répondant ou simplement l'homologue.\nLe troisième paramètre est le nom du serveur (ou l'adresse IP) du serveur sur lequel l'AE appelé est exécuté.\nLe quatrième paramètre est le numéro de port écouté par l'AE appelé.\nCeci conclut les paramètres communs à toutes les méthodes réseau DCXREQ. Avec ces paramètres, nous pouvons commencer une ‘Association’ avec l’AE appelé.\nLe nouveau terme qui nous intéresse ici est Association. Qu'est-ce que c'est? C’est comme une session réseau. C’est un cadre dans lequel la conversation avec l’appelant appelé va avoir lieu.\nNous pouvons diviser la communication réseau DICOM en deux parties. La première partie configure l'association et la seconde échange des commandes DICOM.","html":"

Avant d’analyser le journal, examinons le code de SendSCImage et assurez-vous de le comprendre.\nLes trois premières lignes créent une classe DCXAPP et définissent le niveau de journalisation sur un niveau inférieur au niveau le plus élevé ("Debug"). La classe DCXAPP est utilisée pour contrôler les paramètres globaux de RZDCX. Une fois qu'il est hors de portée, les paramètres restent.\nEnsuite, nous avons le bloc try-catch qui est très simple. Nous créons une classe DCXREQ et l’utilisons pour envoyer l’objet que nous avons créé à l’aide de la méthode SendObject. DCXREQ est un demandeur DICOM – une application DICOM qui initie le réseau DICOM avec une autre application et envoie des commandes DICOM. SendObject prend cinq (5) paramètres et encapsule tout le monde de la mise en réseau DICOM. L’ensemble de ce journal a été généré par cette méthode unique car il effectue tout le travail de mise en réseau DICOM pour vous et c’est exactement ce qui est unique dans RZDCX, vous n’aurez pas à traiter tous ces détails. Néanmoins, il est bon de savoir ce qui se passe à l’intérieur. Ainsi, lorsque la situation se gâte, vous avez une idée de ce qui pourrait mal tourner.\nComme toutes les autres méthodes de mise en réseau de DCXREQ, les quatre (4) premiers paramètres de SendObject sont utilisés pour établir la connexion réseau DICOM avec l'application DICOM distante.\nLe premier paramètre est notre titre d'entité d'application. Dans le réseau DICOM, chaque nœud est une entité d'application (AE) et son nom est AE Title. Vous vous demandez peut-être pourquoi nous avons besoin d'un titre AE si nous avons un nom de serveur ou une adresse IP et que la réponse est qu'un titre AE est en quelque sorte un alias pour la combinaison adresse IP et numéro de port. Nous pouvons exécuter de nombreuses applications DICOM sur un seul serveur. Je peux exécuter deux instances de mon PACS sur le même ordinateur, une sur le port 104, qui est le port TCP / IP standard réservé aux communications DICOM, et une autre sur le port 1104. Chaque application peut être complètement indépendante de l'autre. Je peux exécuter autant d'applications DICOM que je le souhaite, toutes ayant la même adresse IP. \nEn passant, DICOM est presque toujours utilisé dans un environnement de réseau local et je déconseille fortement à quiconque d’utiliser DICOM dans un environnement de réseau étendu, même si je sais que certaines personnes le font, mais ce n’est vraiment pas une bonne idée. Le protocole DICOM est interne, privé, sur votre réseau local, de préférence dans son propre sous-réseau dédié.\nLes titres AE sont sensibles à la casse, 16 caractères maximum.\nLe second paramètre est le titre AE de l'application à laquelle nous souhaitons nous connecter. Nous l'appelons parfois l'application cible ou appelé titre AE ou AE répondant ou simplement l'homologue.\nLe troisième paramètre est le nom du serveur (ou l'adresse IP) du serveur sur lequel l'AE appelé est exécuté.\nLe quatrième paramètre est le numéro de port écouté par l'AE appelé.\nCeci conclut les paramètres communs à toutes les méthodes réseau DCXREQ. Avec ces paramètres, nous pouvons commencer une ‘Association’ avec l’AE appelé.\nLe nouveau terme qui nous intéresse ici est Association. Qu'est-ce que c'est? C’est comme une session réseau. C’est un cadre dans lequel la conversation avec l’appelant appelé va avoir lieu.\nNous pouvons diviser la communication réseau DICOM en deux parties. La première partie configure l'association et la seconde échange des commandes DICOM.

"},{"id":"text-69","type":"text","heading":"","plain_text":"99% des difficultés liées à la mise en réseau DICOM sont liées à la première partie – la négociation d’association. \nMême si cette étape est passée et que nous commençons à échanger des commandes, il est probable que les problèmes proviennent de fautes dans la première partie.","html":"

99% des difficultés liées à la mise en réseau DICOM sont liées à la première partie – la négociation d’association. \nMême si cette étape est passée et que nous commençons à échanger des commandes, il est probable que les problèmes proviennent de fautes dans la première partie.

"},{"id":"text-70","type":"text","heading":"","plain_text":"Le cinquième paramètre est l'objet que nous aimerions envoyer.SendObject effectue les opérations suivantes:","html":"

Le cinquième paramètre est l'objet que nous aimerions envoyer.SendObject effectue les opérations suivantes:

"},{"id":"text-71","type":"text","heading":"","plain_text":"Démarrer une connexion TCP / IP\nNégocie les paramètres d'association pour convenir de ce qui peut être fait pendant l'association\nEnvoyer l'objet DICOM\nFermer l'association\nFermer la connexion TCP / IP","html":"

Démarrer une connexion TCP / IP\nNégocie les paramètres d'association pour convenir de ce qui peut être fait pendant l'association\nEnvoyer l'objet DICOM\nFermer l'association\nFermer la connexion TCP / IP

"},{"id":"text-72","type":"text","heading":"","plain_text":"Revenons au journal et examinons maintenant la première partie du journal. C'est ici:","html":"

Revenons au journal et examinons maintenant la première partie du journal. C'est ici:

"},{"id":"text-73","type":"text","heading":"","plain_text":"2011-12-1022: 22: 25.906000 1508 paramètres de demande d'association INFO:","html":"

2011-12-1022: 22: 25.906000 1508 paramètres de demande d'association INFO:

"},{"id":"text-74","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-75","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8

"},{"id":"text-76","type":"text","heading":"","plain_text":"Leur UID de classe d'implémentation:","html":"

Leur UID de classe d'implémentation:

"},{"id":"text-77","type":"text","heading":"","plain_text":"Leur nom de version d'implémentation:","html":"

Leur nom de version d'implémentation:

"},{"id":"text-78","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-79","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-80","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-81","type":"text","heading":"","plain_text":"Nom de l'application qui répond: Titre de l'APP","html":"

Nom de l'application qui répond: Titre de l'APP

"},{"id":"text-82","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-83","type":"text","heading":"","plain_text":"Leur taille maximale de réception PDU: 0","html":"

Leur taille maximale de réception PDU: 0

"},{"id":"text-84","type":"text","heading":"","plain_text":"Cette partie du journal est une sauvegarde textuelle de la première information envoyée à l'AE appelé et appelée Demande d'association. C’est un ensemble de paramètres décrivant notre application, ses capacités et ses intentions au cours de cette session.\nChaque entrée de journal dans le journal RZDCX commence par un horodatage, un ID de thread (1508 dans ce cas) et le niveau de journal de l'entrée (INFO dans ce cas). Dans le journal complet ci-dessus, j'ai mis en évidence les horodatages au début de chaque entrée du journal.\nLe premier élément de la demande d’association identifie notre implémentation DICOM.","html":"

Cette partie du journal est une sauvegarde textuelle de la première information envoyée à l'AE appelé et appelée Demande d'association. C’est un ensemble de paramètres décrivant notre application, ses capacités et ses intentions au cours de cette session.\nChaque entrée de journal dans le journal RZDCX commence par un horodatage, un ID de thread (1508 dans ce cas) et le niveau de journal de l'entrée (INFO dans ce cas). Dans le journal complet ci-dessus, j'ai mis en évidence les horodatages au début de chaque entrée du journal.\nLe premier élément de la demande d’association identifie notre implémentation DICOM.

"},{"id":"text-85","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-86","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8\nDans ce cas, il s’agit de l’UID RZDCX et du numéro de version. C’est toujours intéressant, car les boîtes à outils et les systèmes DICOM ont leurs propres petits problèmes. Par conséquent, si vous savez que certains systèmes ont un problème que vous avez déjà identifié et que vous voyez que vous utilisez la même mise en œuvre, vous savez comment le résoudre. Lors de la communication avec l’autre fournisseur d’applications, il est également important de signaler la version de l’application.\nDans le vidage de demandes, nous ne voyons que nos informations d'implémentation, mais plus loin dans le journal du vidage de réponses, nous verrons l'identification de l'AE appelé.\nEnsuite, nous avons le nom du contexte de l'application. Il s'agit d'un UID réservé à DICOM. C'est toujours la meme chose.","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8\nDans ce cas, il s’agit de l’UID RZDCX et du numéro de version. C’est toujours intéressant, car les boîtes à outils et les systèmes DICOM ont leurs propres petits problèmes. Par conséquent, si vous savez que certains systèmes ont un problème que vous avez déjà identifié et que vous voyez que vous utilisez la même mise en œuvre, vous savez comment le résoudre. Lors de la communication avec l’autre fournisseur d’applications, il est également important de signaler la version de l’application.\nDans le vidage de demandes, nous ne voyons que nos informations d'implémentation, mais plus loin dans le journal du vidage de réponses, nous verrons l'identification de l'AE appelé.\nEnsuite, nous avons le nom du contexte de l'application. Il s'agit d'un UID réservé à DICOM. C'est toujours la meme chose.

"},{"id":"text-87","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-88","type":"text","heading":"","plain_text":"Nous avons ensuite les titres AE: le titre AE appelant et le titre AE appelé.","html":"

Nous avons ensuite les titres AE: le titre AE appelant et le titre AE appelé.

"},{"id":"text-89","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-90","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-91","type":"text","heading":"","plain_text":"Notez qu’il s’agit simplement de la demande et que ce sont les valeurs que nous avons transmises à SendObject. Dans la réponse, nous aurons également ce qu'ils nous ont renvoyé. Habituellement, l'application qui répond à la demande d'association doit vérifier que l'AE appelé correspond à son propre AE et que l'AE appelant est quelque chose qui se trouve dans son fichier de configuration ou sa base de données. Si cela ne correspond pas, l'AE appelé peut rejeter l'association.\nEnsuite, nous avons la taille maximale de PDU. PDU est un ‘paquet’ au niveau de l’application qui indique quelle est la taille de la mémoire tampon que nous sommes disposés à utiliser pour chaque demande.","html":"

Notez qu’il s’agit simplement de la demande et que ce sont les valeurs que nous avons transmises à SendObject. Dans la réponse, nous aurons également ce qu'ils nous ont renvoyé. Habituellement, l'application qui répond à la demande d'association doit vérifier que l'AE appelé correspond à son propre AE et que l'AE appelant est quelque chose qui se trouve dans son fichier de configuration ou sa base de données. Si cela ne correspond pas, l'AE appelé peut rejeter l'association.\nEnsuite, nous avons la taille maximale de PDU. PDU est un ‘paquet’ au niveau de l’application qui indique quelle est la taille de la mémoire tampon que nous sommes disposés à utiliser pour chaque demande.

"},{"id":"text-92","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-93","type":"text","heading":"","plain_text":"Dans ce cas, nous ne proposons pas plus de 32K. Un problème connu est que certaines applications envoient une demande d’association si grosse que l’AE appelé ne peut pas consommer. Nous verrons dans une minute pourquoi ils le font et comment l’éviter.\nLe bloc suivant du journal fait toujours partie de la première entrée du journal. La demande d'association comprend une liste de services DICOM. Les éléments de cette liste sont appelés contextes de présentation:","html":"

Dans ce cas, nous ne proposons pas plus de 32K. Un problème connu est que certaines applications envoient une demande d’association si grosse que l’AE appelé ne peut pas consommer. Nous verrons dans une minute pourquoi ils le font et comment l’éviter.\nLe bloc suivant du journal fait toujours partie de la première entrée du journal. La demande d'association comprend une liste de services DICOM. Les éléments de cette liste sont appelés contextes de présentation:

"},{"id":"text-94","type":"text","heading":"","plain_text":"Le contexte\nID: 1 (proposé)","html":"

Le contexte\nID: 1 (proposé)

"},{"id":"text-95","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = VerificationSOPClass","html":"

Abstrait\nSyntaxe: = VerificationSOPClass

"},{"id":"text-96","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-97","type":"text","heading":"","plain_text":"Rôle SCP / SCU accepté: par défaut","html":"

Rôle SCP / SCU accepté: par défaut

"},{"id":"text-98","type":"text","heading":"","plain_text":"Proposé\nSyntaxe de transfert:","html":"

Proposé\nSyntaxe de transfert:

"},{"id":"text-99","type":"text","heading":"","plain_text":"= LittleEndianExplicit","html":"

= LittleEndianExplicit

"},{"id":"text-100","type":"text","heading":"","plain_text":"= BigEndianExplicit","html":"

= BigEndianExplicit

"},{"id":"text-101","type":"text","heading":"","plain_text":"= LittleEndianImplicit","html":"

= LittleEndianImplicit

"},{"id":"text-102","type":"text","heading":"","plain_text":"Le contexte\nID: 3 (proposé)","html":"

Le contexte\nID: 3 (proposé)

"},{"id":"text-103","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","html":"

Abstrait\nSyntaxe: = SecondaryCaptureImageStorage

"},{"id":"text-104","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-105","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-106","type":"text","heading":"","plain_text":"Proposé\nSyntaxe de transfert:","html":"

Proposé\nSyntaxe de transfert:

"},{"id":"text-107","type":"text","heading":"","plain_text":"= LittleEndianExplicit","html":"

= LittleEndianExplicit

"},{"id":"text-108","type":"text","heading":"","plain_text":"Négociation prolongée demandée: aucune","html":"

Négociation prolongée demandée: aucune

"},{"id":"text-109","type":"text","heading":"","plain_text":"Négociation étendue acceptée: aucune","html":"

Négociation étendue acceptée: aucune

"},{"id":"text-110","type":"text","heading":"","plain_text":"Nous avons envoyé une liste avec deux éléments. Chaque élément est un contexte de présentation et identifie un service DICOM que nous souhaitons utiliser lors de cette association. Les contextes de présentation sont étrangement numérotés. Le premier est 1, le second est 3 et un troisième aurait été 5. Pourquoi? Je ne sais pas. C'est comme ça. Comme je l'ai dit, ils sont étrangement numérotés.\nLe premier service que nous avons demandé est la vérification. Cette opération est effectuée à l'aide de la commande DICOM C-ECHO. Dans le journal, nous voyons ceci:","html":"

Nous avons envoyé une liste avec deux éléments. Chaque élément est un contexte de présentation et identifie un service DICOM que nous souhaitons utiliser lors de cette association. Les contextes de présentation sont étrangement numérotés. Le premier est 1, le second est 3 et un troisième aurait été 5. Pourquoi? Je ne sais pas. C'est comme ça. Comme je l'ai dit, ils sont étrangement numérotés.\nLe premier service que nous avons demandé est la vérification. Cette opération est effectuée à l'aide de la commande DICOM C-ECHO. Dans le journal, nous voyons ceci:

"},{"id":"text-111","type":"text","heading":"","plain_text":"Syntaxe abstraite:\n= VerificationSOPClass","html":"

Syntaxe abstraite:\n= VerificationSOPClass

"},{"id":"text-112","type":"text","heading":"","plain_text":"Chaque service a un UID. Dans le fichier journal, les UID connus sont remplacés par leur nom. Le service de vérification est une sorte de ping de haut niveau. C-ECHO est une commande DICOM qui indique qu’une fois envoyé, l’homologue doit répondre avec un statut de réussite. Notez que nous n'avons pas encore envoyé de commande C-ECHO. Nous venons de demander à l'AE appelé dans notre demande d'association de l'utiliser dans la deuxième partie. Nous n’avons pas non plus dit que nous enverrions un C-ECHO. Une application DICOM qui écoute sur un port et attend les connexions entrantes doit toujours implémenter le service de vérification. Notre petite application n'écoute pas encore de port. À ce stade, nous jouons uniquement le rôle de client ici et nous nous connectons à une autre application. En tant que client, c’est toujours une bonne habitude de demander le service de vérification. Si nous ne le demandons pas et que l’application à laquelle nous nous connectons ne prend en charge aucun des autres services que nous demandons, elle nous le raccrochera. En ajoutant la vérification à notre demande, nous obligeons le serveur à dire oui pour au moins une chose que nous demandons.\nLe deuxième service que nous avons demandé est le stockage secondaire d’images de capture:","html":"

Chaque service a un UID. Dans le fichier journal, les UID connus sont remplacés par leur nom. Le service de vérification est une sorte de ping de haut niveau. C-ECHO est une commande DICOM qui indique qu’une fois envoyé, l’homologue doit répondre avec un statut de réussite. Notez que nous n'avons pas encore envoyé de commande C-ECHO. Nous venons de demander à l'AE appelé dans notre demande d'association de l'utiliser dans la deuxième partie. Nous n’avons pas non plus dit que nous enverrions un C-ECHO. Une application DICOM qui écoute sur un port et attend les connexions entrantes doit toujours implémenter le service de vérification. Notre petite application n'écoute pas encore de port. À ce stade, nous jouons uniquement le rôle de client ici et nous nous connectons à une autre application. En tant que client, c’est toujours une bonne habitude de demander le service de vérification. Si nous ne le demandons pas et que l’application à laquelle nous nous connectons ne prend en charge aucun des autres services que nous demandons, elle nous le raccrochera. En ajoutant la vérification à notre demande, nous obligeons le serveur à dire oui pour au moins une chose que nous demandons.\nLe deuxième service que nous avons demandé est le stockage secondaire d’images de capture:

"},{"id":"text-113","type":"text","heading":"","plain_text":"Syntaxe abstraite:\n= SecondaryCaptureImageStorage\nSi vous vous en souvenez, lorsque nous avons parlé de SOP Class UID au chapitre 4, j’ai dit que SOP est une paire de services et de définition d’objet. Nous avons donc cette combinaison. Nous demandons à l'application homologue de stocker un objet que nous allons envoyer et nous lui dirons qu'il s'agira d'une image de capture secondaire. Si nous avions également un autre type d'objet, par exemple une image CT, nous aurions dû demander un troisième contexte de présentation. L'AE appelé peut autoriser ou interdire chacun des services. Il est donc possible de créer une application qui accepte des types d’objets spécifiques. Par exemple, si nous écrivons un poste de travail de reconstruction 3D pour les tomodensitogrammes, nous ne pouvons accepter que les images CT et obliger ainsi l’application d’envoi à nous envoyer ce type d’objets. Cependant, ce n’est pas une très bonne idée car les applications envoient généralement des études complètes et il peut y avoir dans une étude des images de différentes classes, par exemple une série avec un scanner, une autre avec un rapport et une autre avec un rayonnement. rapport de dose et si nous limitons notre poste de travail à accepter uniquement les images CT, l'application implémentée pour envoyer des études complètes conservera les échecs de rapport car ils ne peuvent pas envoyer les autres objets même si les images CT dont nous avions besoin sont arrivées. Une meilleure conception consisterait à autoriser tous les types d’objets et à ignorer ceux dont nous n’avons pas besoin.\nCe mécanisme de négociation de chaque type d’objet a conduit certains vendeurs à la très mauvaise habitude de simplement demander tous les objets possibles qu’ils connaissent. Cela peut entraîner une requête d'association longue de 50 Ko et si l'implémentation AE appelée ne peut lire que des requêtes de 32 Ko, elle peut facilement planter sur le bogue de débordement de mémoire tampon le plus simple. En outre, l'envoi d'une demande d'association 50K à chaque fois que vous souhaitez simplement vérifier une connexion à l'aide d'une commande C-ECHO est une pure perte de temps.\nSendObject de RZDCX ne négocie que les UID de classe SOP requis. La méthode d'envoi DCXREQ envoie un ensemble de fichiers DICOM. Tout d'abord, il passe en revue tous les fichiers, crée une liste de toutes leurs classes SOP, puis négocie cette liste avec le AE appelé.\nCeci conclut notre demande d'association. Nous nous sommes identifiés et avons déclaré ce que nous appelons. Voyons maintenant ce que l’AE appelé va dire. Après l'envoi de la demande d'association, l'AE appelé lit la demande et renvoie une réponse d'association. C'est presque identique à la demande. L’appelant AE remplit simplement le formulaire que nous avons envoyé. La deuxième entrée de ce journal est un vidage de cette réponse.","html":"

Syntaxe abstraite:\n= SecondaryCaptureImageStorage\nSi vous vous en souvenez, lorsque nous avons parlé de SOP Class UID au chapitre 4, j’ai dit que SOP est une paire de services et de définition d’objet. Nous avons donc cette combinaison. Nous demandons à l'application homologue de stocker un objet que nous allons envoyer et nous lui dirons qu'il s'agira d'une image de capture secondaire. Si nous avions également un autre type d'objet, par exemple une image CT, nous aurions dû demander un troisième contexte de présentation. L'AE appelé peut autoriser ou interdire chacun des services. Il est donc possible de créer une application qui accepte des types d’objets spécifiques. Par exemple, si nous écrivons un poste de travail de reconstruction 3D pour les tomodensitogrammes, nous ne pouvons accepter que les images CT et obliger ainsi l’application d’envoi à nous envoyer ce type d’objets. Cependant, ce n’est pas une très bonne idée car les applications envoient généralement des études complètes et il peut y avoir dans une étude des images de différentes classes, par exemple une série avec un scanner, une autre avec un rapport et une autre avec un rayonnement. rapport de dose et si nous limitons notre poste de travail à accepter uniquement les images CT, l'application implémentée pour envoyer des études complètes conservera les échecs de rapport car ils ne peuvent pas envoyer les autres objets même si les images CT dont nous avions besoin sont arrivées. Une meilleure conception consisterait à autoriser tous les types d’objets et à ignorer ceux dont nous n’avons pas besoin.\nCe mécanisme de négociation de chaque type d’objet a conduit certains vendeurs à la très mauvaise habitude de simplement demander tous les objets possibles qu’ils connaissent. Cela peut entraîner une requête d'association longue de 50 Ko et si l'implémentation AE appelée ne peut lire que des requêtes de 32 Ko, elle peut facilement planter sur le bogue de débordement de mémoire tampon le plus simple. En outre, l'envoi d'une demande d'association 50K à chaque fois que vous souhaitez simplement vérifier une connexion à l'aide d'une commande C-ECHO est une pure perte de temps.\nSendObject de RZDCX ne négocie que les UID de classe SOP requis. La méthode d'envoi DCXREQ envoie un ensemble de fichiers DICOM. Tout d'abord, il passe en revue tous les fichiers, crée une liste de toutes leurs classes SOP, puis négocie cette liste avec le AE appelé.\nCeci conclut notre demande d'association. Nous nous sommes identifiés et avons déclaré ce que nous appelons. Voyons maintenant ce que l’AE appelé va dire. Après l'envoi de la demande d'association, l'AE appelé lit la demande et renvoie une réponse d'association. C'est presque identique à la demande. L’appelant AE remplit simplement le formulaire que nous avons envoyé. La deuxième entrée de ce journal est un vidage de cette réponse.

"},{"id":"text-114","type":"text","heading":"","plain_text":"2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Ordinaire","html":"

2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Ordinaire

"},{"id":"text-115","type":"text","heading":"","plain_text":"Paramètres de réponse d'association:","html":"

Paramètres de réponse d'association:

"},{"id":"text-116","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-117","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8

"},{"id":"text-118","type":"text","heading":"","plain_text":"Leur UID de classe d'implémentation: 1.2.826.0.1.3680043.2.60.0.1","html":"

Leur UID de classe d'implémentation: 1.2.826.0.1.3680043.2.60.0.1

"},{"id":"text-119","type":"text","heading":"","plain_text":"Leur nom de version d'implémentation: softlink_jdt103","html":"

Leur nom de version d'implémentation: softlink_jdt103

"},{"id":"text-120","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-121","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-122","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-123","type":"text","heading":"","plain_text":"Nom de l'application qui répond: PACS","html":"

Nom de l'application qui répond: PACS

"},{"id":"text-124","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-125","type":"text","heading":"","plain_text":"Leur taille maximale de réception PDU: 32768","html":"

Leur taille maximale de réception PDU: 32768

"},{"id":"text-126","type":"text","heading":"","plain_text":"Le contexte\nID: 1 (Accepté)","html":"

Le contexte\nID: 1 (Accepté)

"},{"id":"text-127","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = VerificationSOPClass","html":"

Abstrait\nSyntaxe: = VerificationSOPClass

"},{"id":"text-128","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-129","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-130","type":"text","heading":"","plain_text":"Accepté\nSyntaxe de transfert: = LittleEndianImplicit","html":"

Accepté\nSyntaxe de transfert: = LittleEndianImplicit

"},{"id":"text-131","type":"text","heading":"","plain_text":"Le contexte\nID: 3 (Syntaxe abstraite non prise en charge)","html":"

Le contexte\nID: 3 (Syntaxe abstraite non prise en charge)

"},{"id":"text-132","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","html":"

Abstrait\nSyntaxe: = SecondaryCaptureImageStorage

"},{"id":"text-133","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-134","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-135","type":"text","heading":"","plain_text":"Négociation prolongée demandée: aucune","html":"

Négociation prolongée demandée: aucune

"},{"id":"text-136","type":"text","heading":"","plain_text":"Négociation étendue acceptée: aucune","html":"

Négociation étendue acceptée: aucune

"},{"id":"text-137","type":"text","heading":"","plain_text":"D'après l'horodatage, vous pouvez voir qu'il est revenu juste un dixième de seconde après l'envoi de la demande et que l'état de la réponse est Normal (j'ai mis en surbrillance les paramètres qui étaient vides ou qui ont changé auparavant). Vous pouvez également voir que leur identification d'implémentation est maintenant renseignée avec la valeur softlink_jdt103, qui identifie un package utilitaire Java très pratique de Tiani. Leur titre AE est bien «PACS» et ils ont accepté notre demande d'association. Il y a quelques cas ici. Un cas est qu'ils ne répondent tout simplement pas. Dans ce cas, notre demande expirera sans obtenir de réponse. Un autre cas est ce que nous avons ici, c'est-à-dire que la demande d'association a été acceptée et que nous sommes maintenant connectés à l'AE appelé. Le troisième cas est que l’appelant appelé décide qu’il ne veut pas nous parler et envoie une réponse de rejet d’association. Par exemple, si son titre AE n'est pas «PACS», le message «Mauvais titre AE appelé» apparaît alors. Le motif du rejet est codé dans le statut de la réponse et comporte parfois une explication textuelle supplémentaire.\nNous avons également reçu la liste des services. La vérification a été acceptée, mais pas le stockage de capture secondaire. Cela signifie que si nous le souhaitons, nous pouvons envoyer une commande C-ECHO mais nous ne pouvons pas envoyer notre image de capture secondaire à l’aide d’un C-STORE. Parce que c’est ce que nous voulions faire dans cette association, vous voyez les deux prochaines entrées du journal:","html":"

D'après l'horodatage, vous pouvez voir qu'il est revenu juste un dixième de seconde après l'envoi de la demande et que l'état de la réponse est Normal (j'ai mis en surbrillance les paramètres qui étaient vides ou qui ont changé auparavant). Vous pouvez également voir que leur identification d'implémentation est maintenant renseignée avec la valeur softlink_jdt103, qui identifie un package utilitaire Java très pratique de Tiani. Leur titre AE est bien «PACS» et ils ont accepté notre demande d'association. Il y a quelques cas ici. Un cas est qu'ils ne répondent tout simplement pas. Dans ce cas, notre demande expirera sans obtenir de réponse. Un autre cas est ce que nous avons ici, c'est-à-dire que la demande d'association a été acceptée et que nous sommes maintenant connectés à l'AE appelé. Le troisième cas est que l’appelant appelé décide qu’il ne veut pas nous parler et envoie une réponse de rejet d’association. Par exemple, si son titre AE n'est pas «PACS», le message «Mauvais titre AE appelé» apparaît alors. Le motif du rejet est codé dans le statut de la réponse et comporte parfois une explication textuelle supplémentaire.\nNous avons également reçu la liste des services. La vérification a été acceptée, mais pas le stockage de capture secondaire. Cela signifie que si nous le souhaitons, nous pouvons envoyer une commande C-ECHO mais nous ne pouvons pas envoyer notre image de capture secondaire à l’aide d’un C-STORE. Parce que c’est ce que nous voulions faire dans cette association, vous voyez les deux prochaines entrées du journal:

"},{"id":"text-138","type":"text","heading":"","plain_text":"2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe d'opération n'a pas été négociée ou acceptée\npar les pairs. SID de classe UID:\n1.2.840.10008.5.1.4.1.1.7, UID d’instance SOP:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2","html":"

2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe d'opération n'a pas été négociée ou acceptée\npar les pairs. SID de classe UID:\n1.2.840.10008.5.1.4.1.1.7, UID d’instance SOP:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2

"},{"id":"text-139","type":"text","heading":"","plain_text":"2011-12-1022: 22: 31.234000 ERREUR 1508 dans DCXREQ, Code: 520, Texte: DIMSE Aucune présentation valide\nID de contexte\nCela signifie que nous ne pouvons pas stocker l’objet car l’homologue ne prend pas en charge ce service. Yippy! Nous pourrions en fait comprendre ce qui ne va pas ha?! Maintenant, Burt peut aller voir l’administrateur du PACS et lui demander pourquoi son PACS ne peut pas stocker les captures secondaires et l’administrateur du PACS va probablement demander à Burt sur quel serveur il a essayé de se connecter et sur quel port, puis indiquer que le port 6104 est le gestionnaire de listes de travail. qui servent les demandes de liste de travail de modalité et d’étapes de procédure effectuées (qui sont des services DICOM, nous en apprendrons plus tard) et que si nous voulons envoyer quelque chose au PACS, nous devons essayer de vous connecter au port 104. Cas résolu.\nOK, renouvelons cette opération et connectez-vous cette fois au port 104. C’est une bonne idée de pouvoir configurer le titre, l’adresse IP et le numéro de port de l’AE appelé dans notre application afin que nous n’ayons pas à compiler à chaque fois. La plupart des applications DICOM ont une telle configuration. Il s’agit généralement d’une table avec au moins les colonnes: Titre AE, hôte et port et éventuellement un identifiant et un commentaire. Voici le journal d’un envoi réussi. Cette fois, le niveau de journalisation a été défini sur Debug.","html":"

2011-12-1022: 22: 31.234000 ERREUR 1508 dans DCXREQ, Code: 520, Texte: DIMSE Aucune présentation valide\nID de contexte\nCela signifie que nous ne pouvons pas stocker l’objet car l’homologue ne prend pas en charge ce service. Yippy! Nous pourrions en fait comprendre ce qui ne va pas ha?! Maintenant, Burt peut aller voir l’administrateur du PACS et lui demander pourquoi son PACS ne peut pas stocker les captures secondaires et l’administrateur du PACS va probablement demander à Burt sur quel serveur il a essayé de se connecter et sur quel port, puis indiquer que le port 6104 est le gestionnaire de listes de travail. qui servent les demandes de liste de travail de modalité et d’étapes de procédure effectuées (qui sont des services DICOM, nous en apprendrons plus tard) et que si nous voulons envoyer quelque chose au PACS, nous devons essayer de vous connecter au port 104. Cas résolu.\nOK, renouvelons cette opération et connectez-vous cette fois au port 104. C’est une bonne idée de pouvoir configurer le titre, l’adresse IP et le numéro de port de l’AE appelé dans notre application afin que nous n’ayons pas à compiler à chaque fois. La plupart des applications DICOM ont une telle configuration. Il s’agit généralement d’une table avec au moins les colonnes: Titre AE, hôte et port et éventuellement un identifiant et un commentaire. Voici le journal d’un envoi réussi. Cette fois, le niveau de journalisation a été défini sur Debug.

"},{"id":"text-140","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.000000 Association 4296 INFO\nParamètres de demande:","html":"

2011-12-1512: 22: 51.000000 Association 4296 INFO\nParamètres de demande:

"},{"id":"text-141","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-142","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8

"},{"id":"text-143","type":"text","heading":"","plain_text":"Leur UID de classe d'implémentation:","html":"

Leur UID de classe d'implémentation:

"},{"id":"text-144","type":"text","heading":"","plain_text":"Leur nom de version d'implémentation:","html":"

Leur nom de version d'implémentation:

"},{"id":"text-145","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-146","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-147","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-148","type":"text","heading":"","plain_text":"Nom de l'application qui répond: Titre de l'APP","html":"

Nom de l'application qui répond: Titre de l'APP

"},{"id":"text-149","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-150","type":"text","heading":"","plain_text":"Leur taille maximale de réception PDU: 0","html":"

Leur taille maximale de réception PDU: 0

"},{"id":"text-151","type":"text","heading":"","plain_text":"Le contexte\nID: 1 (proposé)","html":"

Le contexte\nID: 1 (proposé)

"},{"id":"text-152","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = VerificationSOPClass","html":"

Abstrait\nSyntaxe: = VerificationSOPClass

"},{"id":"text-153","type":"text","heading":"","plain_text":"Rôle proposé du SCP / SCU: Par défaut","html":"

Rôle proposé du SCP / SCU: Par défaut

"},{"id":"text-154","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-155","type":"text","heading":"","plain_text":"Proposé\nSyntaxe de transfert:","html":"

Proposé\nSyntaxe de transfert:

"},{"id":"text-156","type":"text","heading":"","plain_text":"= LittleEndianExplicit","html":"

= LittleEndianExplicit

"},{"id":"text-157","type":"text","heading":"","plain_text":"= BigEndianExplicit","html":"

= BigEndianExplicit

"},{"id":"text-158","type":"text","heading":"","plain_text":"= LittleEndianImplicit","html":"

= LittleEndianImplicit

"},{"id":"text-159","type":"text","heading":"","plain_text":"Le contexte\nID: 3 (proposé)","html":"

Le contexte\nID: 3 (proposé)

"},{"id":"text-160","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage","html":"

Abstrait\nSyntaxe: = SecondaryCaptureImageStorage

"},{"id":"text-161","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-162","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-163","type":"text","heading":"","plain_text":"Proposé\nSyntaxe de transfert:","html":"

Proposé\nSyntaxe de transfert:

"},{"id":"text-164","type":"text","heading":"","plain_text":"= LittleEndianExplicit","html":"

= LittleEndianExplicit

"},{"id":"text-165","type":"text","heading":"","plain_text":"Négociation prolongée demandée: aucune","html":"

Négociation prolongée demandée: aucune

"},{"id":"text-166","type":"text","heading":"","plain_text":"Négociation étendue acceptée: aucune","html":"

Négociation étendue acceptée: aucune

"},{"id":"text-167","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.000000 4296 PDU RQ d'associé de construction DEBUG","html":"

2011-12-1512: 22: 51.000000 4296 PDU RQ d'associé de construction DEBUG

"},{"id":"text-168","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.000000 4296 DEBUG WriteToConnection, longueur: 310, octets écrits:\n310, numéro de boucle: 1","html":"

2011-12-1512: 22: 51.000000 4296 DEBUG WriteToConnection, longueur: 310, octets écrits:\n310, numéro de boucle: 1

"},{"id":"text-169","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.015000 4296 Type de PDU DEBUG: accepteur de partenariat, longueur de PDU: 216 +\nEn-tête PDU 6 octets","html":"

2011-12-1512: 22: 51.015000 4296 Type de PDU DEBUG: accepteur de partenariat, longueur de PDU: 216 +\nEn-tête PDU 6 octets

"},{"id":"text-170","type":"text","heading":"","plain_text":"02 00\n00 00 00 d8 00\n01 00 00\n50 41 43\n53 20 20","html":"

02 00\n00 00 00 d8 00\n01 00 00\n50 41 43\n53 20 20

"},{"id":"text-171","type":"text","heading":"","plain_text":"20 20\n20 20 20 20 20\n20 20 20\n52 5a 44\n43 58 20","html":"

20 20\n20 20 20 20 20\n20 20 20\n52 5a 44\n43 58 20

"},{"id":"text-172","type":"text","heading":"","plain_text":"20 20\n20 20 20 20 20\n20 20 20\n00 00 00\n00 00 00","html":"

20 20\n20 20 20 20 20\n20 20 20\n00 00 00\n00 00 00

"},{"id":"text-173","type":"text","heading":"","plain_text":"00 00\n00 00 00 00 00\n00 00 00\n00 00 00\n00 00 00","html":"

00 00\n00 00 00 00 00\n00 00 00\n00 00 00\n00 00 00

"},{"id":"text-174","type":"text","heading":"","plain_text":"00 00\n00 00 00 00 00\n00 00 00\n10 00 00\n15 31 2e","html":"

00 00\n00 00 00 00 00\n00 00 00\n10 00 00\n15 31 2e

"},{"id":"text-175","type":"text","heading":"","plain_text":"32 2e\n38 34 30 2e 31\n30 30 30\n38 2e 33\n2e 31 2e","html":"

32 2e\n38 34 30 2e 31\n30 30 30\n38 2e 33\n2e 31 2e

"},{"id":"text-176","type":"text","heading":"","plain_text":"31 2e\n31 21 00 00 19\n01 00 00\n00 40 00\n00 11 31","html":"

31 2e\n31 21 00 00 19\n01 00 00\n00 40 00\n00 11 31

"},{"id":"text-177","type":"text","heading":"","plain_text":"2e 32\n2e 38 34 30 2e\n31 30 30\n30 38 2e\n31 2e 32","html":"

2e 32\n2e 38 34 30 2e\n31 30 30\n30 38 2e\n31 2e 32

"},{"id":"text-178","type":"text","heading":"","plain_text":"21 00\n00 1b 03\n00 00 00\n40 00 00\n13 31 2e\n32 2e","html":"

21 00\n00 1b 03\n00 00 00\n40 00 00\n13 31 2e\n32 2e

"},{"id":"text-179","type":"text","heading":"","plain_text":"38 34\n30 2e 31 30 30\n30 38 2e\n31 2e 32\n2e 31 50","html":"

38 34\n30 2e 31 30 30\n30 38 2e\n31 2e 32\n2e 31 50

"},{"id":"text-180","type":"text","heading":"","plain_text":"00 00\n3b 51 00 00 04\n00 00 80\n00 52 00\n00 1c 31","html":"

00 00\n3b 51 00 00 04\n00 00 80\n00 52 00\n00 1c 31

"},{"id":"text-181","type":"text","heading":"","plain_text":"2e 32\n2e 38 32 36 2e\n30 2e 31\n2e 33 36\n38 30 30","html":"

2e 32\n2e 38 32 36 2e\n30 2e 31\n2e 33 36\n38 30 30

"},{"id":"text-182","type":"text","heading":"","plain_text":"34 33\n2e 32 2e\n36 30 2e\n30 2e 31\n55 00 00\n0f 73","html":"

34 33\n2e 32 2e\n36 30 2e\n30 2e 31\n55 00 00\n0f 73

"},{"id":"text-183","type":"text","heading":"","plain_text":"6f 66\n74 6c 69 6e 6b\n5f 6a 64\n74 31 30 33","html":"

6f 66\n74 6c 69 6e 6b\n5f 6a 64\n74 31 30 33

"},{"id":"text-184","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.015000 4296 INFO Résultat de la demande d'association: Normal","html":"

2011-12-1512: 22: 51.015000 4296 INFO Résultat de la demande d'association: Normal

"},{"id":"text-185","type":"text","heading":"","plain_text":"Paramètres de réponse d'association:","html":"

Paramètres de réponse d'association:

"},{"id":"text-186","type":"text","heading":"","plain_text":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2","html":"

Notre classe d'implémentation UID: 2.16.124.113543.6021.2

"},{"id":"text-187","type":"text","heading":"","plain_text":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8","html":"

Notre version de mise en œuvre Nom: RZDCX_2_0_1_8

"},{"id":"text-188","type":"text","heading":"","plain_text":"Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1","html":"

Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1

"},{"id":"text-189","type":"text","heading":"","plain_text":"Leur version de mise en œuvre Nom: softlink_jdt103","html":"

Leur version de mise en œuvre Nom: softlink_jdt103

"},{"id":"text-190","type":"text","heading":"","plain_text":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1","html":"

Nom du contexte d'application: 1.2.840.10008.3.1.1.1

"},{"id":"text-191","type":"text","heading":"","plain_text":"Nom de l'application appelante: RZDCX","html":"

Nom de l'application appelante: RZDCX

"},{"id":"text-192","type":"text","heading":"","plain_text":"Nom de l'application appelée: PACS","html":"

Nom de l'application appelée: PACS

"},{"id":"text-193","type":"text","heading":"","plain_text":"Nom de l'application qui répond: PACS","html":"

Nom de l'application qui répond: PACS

"},{"id":"text-194","type":"text","heading":"","plain_text":"Notre Max PDU Receive Size: 32768","html":"

Notre Max PDU Receive Size: 32768

"},{"id":"text-195","type":"text","heading":"","plain_text":"Leur Max PDU Receive Size: 32768","html":"

Leur Max PDU Receive Size: 32768

"},{"id":"text-196","type":"text","heading":"","plain_text":"Le contexte\nID: 1 (Accepté)","html":"

Le contexte\nID: 1 (Accepté)

"},{"id":"text-197","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: =VérificationSOPClass","html":"

Abstrait\nSyntaxe: =VérificationSOPClass

"},{"id":"text-198","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-199","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-200","type":"text","heading":"","plain_text":"Accepté\nSyntaxe de transfert: = LittleEndianImplicit","html":"

Accepté\nSyntaxe de transfert: = LittleEndianImplicit

"},{"id":"text-201","type":"text","heading":"","plain_text":"Le contexte\nID: 3 (Accepté)","html":"

Le contexte\nID: 3 (Accepté)

"},{"id":"text-202","type":"text","heading":"","plain_text":"Abstrait\nSyntaxe: =SecondaryCaptureImageStorage","html":"

Abstrait\nSyntaxe: =SecondaryCaptureImageStorage

"},{"id":"text-203","type":"text","heading":"","plain_text":"Proposé\nRôle SCP / SCU: Par défaut","html":"

Proposé\nRôle SCP / SCU: Par défaut

"},{"id":"text-204","type":"text","heading":"","plain_text":"Accepté\nRôle SCP / SCU: Par défaut","html":"

Accepté\nRôle SCP / SCU: Par défaut

"},{"id":"text-205","type":"text","heading":"","plain_text":"Accepté\nSyntaxe de transfert: = LittleEndianExplicit","html":"

Accepté\nSyntaxe de transfert: = LittleEndianExplicit

"},{"id":"text-206","type":"text","heading":"","plain_text":"Négociation prolongée demandée: aucune","html":"

Négociation prolongée demandée: aucune

"},{"id":"text-207","type":"text","heading":"","plain_text":"Négociation étendue acceptée: aucune","html":"

Négociation étendue acceptée: aucune

"},{"id":"text-208","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE Commande à envoyer:","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE Commande à envoyer:

"},{"id":"text-209","type":"text","heading":"","plain_text":"# Used TransferSyntax: UnknownTransferSyntax","html":"

# Used TransferSyntax: UnknownTransferSyntax

"},{"id":"text-210","type":"text","heading":"","plain_text":"(0000,0000) UL 0 # 4, 1 CommandGroupLength","html":"

(0000,0000) UL 0 # 4, 1 CommandGroupLength

"},{"id":"text-211","type":"text","heading":"","plain_text":"(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID","html":"

(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID

"},{"id":"text-212","type":"text","heading":"","plain_text":"(0000,0100) US 1 n ° 2, 1 CommandField","html":"

(0000,0100) US 1 n ° 2, 1 CommandField

"},{"id":"text-213","type":"text","heading":"","plain_text":"(0000,0110) US 1 # 2, 1 MessageID","html":"

(0000,0110) US 1 # 2, 1 MessageID

"},{"id":"text-214","type":"text","heading":"","plain_text":"(0000,0700) US 0 # 2, 1 priorité","html":"

(0000,0700) US 0 # 2, 1 priorité

"},{"id":"text-215","type":"text","heading":"","plain_text":"(0000,0800) US 1 # 2, 1 DataSetType","html":"

(0000,0800) US 1 # 2, 1 DataSetType

"},{"id":"text-216","type":"text","heading":"","plain_text":"(0000,1000) UI [2.16.124.113543.6021.1.3.3727584845.720.1323944568.6]\n# 52, 1 AffectedSOPInstanceUID","html":"

(0000,1000) UI [2.16.124.113543.6021.1.3.3727584845.720.1323944568.6]\n# 52, 1 AffectedSOPInstanceUID

"},{"id":"text-217","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 146 octets","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 146 octets

"},{"id":"text-218","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1

"},{"id":"text-219","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 146, octets écrits:\n146, numéro de boucle: 1","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 146, octets écrits:\n146, numéro de boucle: 1

"},{"id":"text-220","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 7894 octets","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 7894 octets

"},{"id":"text-221","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1

"},{"id":"text-222","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 7894, octets\nécrit: 7894, boucle no: 1","html":"

2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 7894, octets\nécrit: 7894, boucle no: 1

"},{"id":"text-223","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.046000 4296 INFO DIMSE receiveCommand","html":"

2011-12-1512: 22: 51.046000 4296 INFO DIMSE receiveCommand

"},{"id":"text-224","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.062000 4296 INFO DIMSE receiveCommand: 1 pdv (178 octets),\npresID = 3","html":"

2011-12-1512: 22: 51.062000 4296 INFO DIMSE receiveCommand: 1 pdv (178 octets),\npresID = 3

"},{"id":"text-225","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.062000 4296 Commande DEBUG DIMSE reçue:","html":"

2011-12-1512: 22: 51.062000 4296 Commande DEBUG DIMSE reçue:

"},{"id":"text-226","type":"text","heading":"","plain_text":"# Used TransferSyntax: LittleEndianImplicit","html":"

# Used TransferSyntax: LittleEndianImplicit

"},{"id":"text-227","type":"text","heading":"","plain_text":"(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID","html":"

(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID

"},{"id":"text-228","type":"text","heading":"","plain_text":"(0000,0100) US 32769 N ° 2, 1 CommandField","html":"

(0000,0100) US 32769 N ° 2, 1 CommandField

"},{"id":"text-229","type":"text","heading":"","plain_text":"(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo","html":"

(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo

"},{"id":"text-230","type":"text","heading":"","plain_text":"(0000,0800) US 257 N ° 2, 1 DataSetType","html":"

(0000,0800) US 257 N ° 2, 1 DataSetType

"},{"id":"text-231","type":"text","heading":"","plain_text":"(0000,0900)\nUS 45056\n# 2, 1 Statut","html":"

(0000,0900)\nUS 45056\n# 2, 1 Statut

"},{"id":"text-232","type":"text","heading":"","plain_text":"(0000,0902)\nLO [set InstanceNumber to 0]\n# 24, 1 ErrorComment","html":"

(0000,0902)\nLO [set InstanceNumber to 0]\n# 24, 1 ErrorComment

"},{"id":"text-233","type":"text","heading":"","plain_text":"(0000,1000) UI\n[2.16.124.113543.6021.1.3.3727584845.720.1323944568.6] # 52, 1 AffectedSOPInstanceUID","html":"

(0000,1000) UI\n[2.16.124.113543.6021.1.3.3727584845.720.1323944568.6] # 52, 1 AffectedSOPInstanceUID

"},{"id":"text-234","type":"text","heading":"","plain_text":"2011-12-1512: 22: 51.062000 4296 DEBUG WriteToConnection, longueur: 10, octets écrits:\n10, numéro de boucle: 1","html":"

2011-12-1512: 22: 51.062000 4296 DEBUG WriteToConnection, longueur: 10, octets écrits:\n10, numéro de boucle: 1

"},{"id":"text-235","type":"text","heading":"","plain_text":"La commande de stockage a réussi, mais nous avons récupéré un statut d'avertissement (45056 = 0xB000) au lieu de succès (0x0000). Nous avons également reçu un commentaire d’avertissement indiquant que l’appelant appelé avait changé l’élément numéro d’instance de null à 0, peut-être afin de l’indexer correctement dans sa base de données.\nNous aurions dû parler de syntaxes de transfert, mais ceci est déjà un long post, je vais donc laisser les syntaxes de transfert pour une autre fois. \nRésumons ce que nous avons couvert dans cet article.","html":"

La commande de stockage a réussi, mais nous avons récupéré un statut d'avertissement (45056 = 0xB000) au lieu de succès (0x0000). Nous avons également reçu un commentaire d’avertissement indiquant que l’appelant appelé avait changé l’élément numéro d’instance de null à 0, peut-être afin de l’indexer correctement dans sa base de données.\nNous aurions dû parler de syntaxes de transfert, mais ceci est déjà un long post, je vais donc laisser les syntaxes de transfert pour une autre fois. \nRésumons ce que nous avons couvert dans cet article.

"},{"id":"text-236","type":"text","heading":"","plain_text":"Les nœuds du réseau DICOM sont appelés entités d'application (AE) et sont identifiés à l'aide d'un nom respectant la casse, appelé titre AE.\nLa communication DICOM se fait toujours entre deux AE, c’est-à-dire qu’elle est peer-to-peer.\nLa «session» DICOM s’appelle Association\nL'association est divisée en deux étapes. La première étape s'appelle la négociation d'association. Dans la deuxième étape, les commandes DICOM échangées par les deux AE\nDans la négociation d'association, l'AE demandeur envoie une liste de contextes de présentation identifiant les services DICOM qu'il souhaite utiliser, et l'AE répondant renvoie la même liste marquée des services acceptés et utilisables et des services qu'il a refusés et ne peuvent pas être utilisés. utilisé dans cette association.\nLe service de vérification est un service de niveau application utilisé pour vérifier la communication entre deux AE.\nLe service de stockage est utilisé pour transférer des objets DICOM entre AE. Le service de stockage est négocié séparément pour chaque classe SOP. Par exemple, une application peut autoriser le stockage d’images CT et interdire le stockage d’images MR. Ce n'est pas un bon design cependant.","html":"

Les nœuds du réseau DICOM sont appelés entités d'application (AE) et sont identifiés à l'aide d'un nom respectant la casse, appelé titre AE.\nLa communication DICOM se fait toujours entre deux AE, c’est-à-dire qu’elle est peer-to-peer.\nLa «session» DICOM s’appelle Association\nL'association est divisée en deux étapes. La première étape s'appelle la négociation d'association. Dans la deuxième étape, les commandes DICOM échangées par les deux AE\nDans la négociation d'association, l'AE demandeur envoie une liste de contextes de présentation identifiant les services DICOM qu'il souhaite utiliser, et l'AE répondant renvoie la même liste marquée des services acceptés et utilisables et des services qu'il a refusés et ne peuvent pas être utilisés. utilisé dans cette association.\nLe service de vérification est un service de niveau application utilisé pour vérifier la communication entre deux AE.\nLe service de stockage est utilisé pour transférer des objets DICOM entre AE. Le service de stockage est négocié séparément pour chaque classe SOP. Par exemple, une application peut autoriser le stockage d’images CT et interdire le stockage d’images MR. Ce n'est pas un bon design cependant.

"},{"id":"text-237","type":"text","heading":"","plain_text":"C'est tout. J'espère que vous me croyez toujours que DICOM est facile. Comme toujours, les commentaires sont les bienvenus.","html":"

C'est tout. J'espère que vous me croyez toujours que DICOM est facile. Comme toujours, les commentaires sont les bienvenus.

"},{"id":"text-238","type":"text","heading":"","plain_text":"Click to rate this post!\n \n [Total: 0 Average: 0]","html":"

Click to rate this post!\n \n [Total: 0 Average: 0]

"}],"sections":[{"id":"text-1","heading":"Text","content":"Nous allons aujourd'hui diagnostiquer un problème de communication entre deux applications DICOM et, espérons-le, en trouver la cause et le résoudre. Je sais, nous n’avons même pas commencé à parler du protocole réseau DICOM, mais nous ne lirons pas ensemble ces 3 000 pages standard avant de nous salir les mains, non?\nDans ce post, nous discuterons:"},{"id":"text-2","heading":"Text","content":"Entités d’application (AE) – les nœuds du réseau DICOM et leur nom – AE Title\nAssociation: session réseau entre homologues entre deux applications DICOM.\nAssociation Negotiation – La première partie de l’association dans laquelle les deux AE se mettent d’accord sur ce qui peut et ne peut pas être fait pendant l’association\nLe service de vérification utilisant la commande C-ECHO – une classe de service DICOM utilisée pour vérifier une connexion, sorte de «niveau d’application» au niveau de l’application.\nLe service de stockage utilisant la commande C-STORE – un service DICOM qui permet à un AE d'envoyer un objet DICOM à un autre AE"},{"id":"text-3","heading":"Text","content":"Les commandes C dans C-ECHO et C-STORE désignent Composite. Si vous vous en souvenez, au chapitre 4 du modèle de données DICOM, nous avons expliqué que les applications DICOM échangent des objets composites (les images DICOM que nous connaissons déjà) qui sont des composites de modules de différents IE, les IE étant les entités d’information des données DICOM normalisées. modèle.\nVoici l'histoire:"},{"id":"text-4","heading":"Text","content":"Plainte 20123\nBurt Simpson du Springfield Memorial Hospital a déclaré qu’il ne pouvait pas envoyer la capture d’écran au PACS. Il a continué à cliquer sur le bouton vert «Envoyer», mais il a toujours la même erreur: «Échec de l'opération!». Le fichier journal que Burt a copié à partir du système est joint."},{"id":"text-5","heading":"Text","content":"Vous pouvez vous demander quel est l’intérêt d’analyser le journal d’une application que nous n’allons jamais utiliser? Eh bien, la vérité est que tous les journaux DICOM se ressemblent. En fait, la plupart des applications DICOM sont assez similaires car les implémentations logicielles DICOM ont des ancêtres communs. S'il s'agit d'une bibliothèque C, il peut s'agir du nœud de test DICOM, CTN. Si c’est Java, c’est peut-être dcm4che. Même s'il s'agit de PHP ou d'autres langages plus récents, les bibliothèques ont été transcrites et portées à partir des anciennes implémentations C afin que tous les journaux DICOM soient similaires.\nDans ce cas, le fichier journal, nommé DICOM-20111207-093017.log, a une longueur de 250 Mo et lorsque vous double-cliquez dessus, le bloc-notes se bloque pendant quelques minutes avant de se bloquer. Lorsque vous ouvrez le journal avec EXCEL, le même modèle se répète 100 fois, une fois pour chaque clic effectué par Burt. Après avoir isolé une répétition, vous voyez ce modèle relativement court avec exactement quatre entrées de journal que nous allons analyser ensemble.\n2011-12-1022: 22: 25.906000 1508 INFO Paramètres de demande d'association:"},{"id":"text-6","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-7","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8"},{"id":"text-8","heading":"Text","content":"Leur UID de classe d'implémentation:"},{"id":"text-9","heading":"Text","content":"Leur nom de version d'implémentation:"},{"id":"text-10","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-11","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-12","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-13","heading":"Text","content":"Nom de l'application qui répond: Titre de l'APP"},{"id":"text-14","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-15","heading":"Text","content":"Leur taille maximale de réception PDU: 0"},{"id":"text-16","heading":"Text","content":"Le contexte\nID: 1 (proposé)"},{"id":"text-17","heading":"Text","content":"Abstrait\nSyntaxe: = VerificationSOPClass"},{"id":"text-18","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-19","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-20","heading":"Text","content":"Proposé\nSyntaxe de transfert:"},{"id":"text-21","heading":"Text","content":"= LittleEndianExplicit"},{"id":"text-22","heading":"Text","content":"= BigEndianExplicit"},{"id":"text-23","heading":"Text","content":"= LittleEndianImplicit"},{"id":"text-24","heading":"Text","content":"Le contexte\nID: 3 (proposé)"},{"id":"text-25","heading":"Text","content":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage"},{"id":"text-26","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-27","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-28","heading":"Text","content":"Transfert proposé\nSyntaxe (es):"},{"id":"text-29","heading":"Text","content":"= LittleEndianExplicit"},{"id":"text-30","heading":"Text","content":"Négociation prolongée demandée: aucune"},{"id":"text-31","heading":"Text","content":"Négociation étendue acceptée: aucune"},{"id":"text-32","heading":"Text","content":"2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Normal"},{"id":"text-33","heading":"Text","content":"Paramètres de réponse d'association:"},{"id":"text-34","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-35","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8"},{"id":"text-36","heading":"Text","content":"Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1"},{"id":"text-37","heading":"Text","content":"Leur version de mise en œuvre Nom: softlink_jdt103"},{"id":"text-38","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-39","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-40","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-41","heading":"Text","content":"Nom de l'application qui répond: PACS"},{"id":"text-42","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-43","heading":"Text","content":"Leur Max PDU Receive Size: 32768"},{"id":"text-44","heading":"Text","content":"Le contexte\nID: 1 (accepté)"},{"id":"text-45","heading":"Text","content":"Abstrait\nSyntaxe: = VerificationSOPClass"},{"id":"text-46","heading":"Text","content":"Rôle proposé du SCP / SCU: Par défaut"},{"id":"text-47","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-48","heading":"Text","content":"Accepté\nSyntaxe de transfert: = LittleEndianImplicit"},{"id":"text-49","heading":"Text","content":"Le contexte\nID: 3 (Syntaxe abstraite non\nPrise en charge)"},{"id":"text-50","heading":"Text","content":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage"},{"id":"text-51","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-52","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-53","heading":"Text","content":"Négociation prolongée demandée: aucune"},{"id":"text-54","heading":"Text","content":"Négociation étendue acceptée: aucune"},{"id":"text-55","heading":"Text","content":"2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe SOP n'était pas\nnégocié ou non accepté par les pairs. AMADOUER\nClasse UID: 1.2.840.10008.5.1.4.1.1.7, UID Instance UID:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2"},{"id":"text-56","heading":"Text","content":"2011-12-1022: 22: 31.234000 1508 ERREUR dans DCXREQ, Code: 520, Texte: DIMSE Non valide\nID de contexte de présentation"},{"id":"text-57","heading":"Text","content":"Le problème est clairement indiqué dans la troisième entrée du journal et marqué comme erreur dans la quatrième entrée. Cela dit que l'application homologue, celle que nous voulons envoyer à notre image, refuse de stocker ce type d'objet. Certaines boîtes à outils fournissent des informations utiles supplémentaires. Cependant, nous aurions pu deviner que ce serait déjà le problème dans la deuxième entrée du journal dans la réponse à la demande d'association, où le contexte de présentation pour la capture secondaire était marqué comme n'étant pas pris en charge par l'AE appelé.\nLe journal ci-dessus provient de la courte fonction C # suivante que j’ai écrite pour cet article:"},{"id":"text-58","heading":"Text","content":"Publique vide SendSCImage (DCXOBJ o)"},{"id":"text-59","heading":"Text","content":"DCXAPP app = Nouveau DCXAPP();"},{"id":"text-60","heading":"Text","content":"app.LogLevel\n= LOG_LEVEL.LOG_LEVEL_INFO;"},{"id":"text-61","heading":"Text","content":"app.StartLogging ("DICOM.log")"},{"id":"text-62","heading":"Text","content":"essayer"},{"id":"text-63","heading":"Text","content":"DCXREQ req = Nouveau DCXREQ();"},{"id":"text-64","heading":"Text","content":"req.SendObject ("RZDCX", "PACS", "localhost",\n6104, o);"},{"id":"text-65","heading":"Text","content":"capture (Exception e)"},{"id":"text-66","heading":"Text","content":"Messagerie.Show (e.Message);\nAvec la fonction CreateSCImage que nous avons écrit ensemble au chapitre 4, nous avons ce petit programme qui crée une image secondaire en mémoire puis tente de l’envoyer:"},{"id":"text-67","heading":"Text","content":"DCXOBJ o =\nCreateSCImage ();"},{"id":"text-68","heading":"Text","content":"Avant d’analyser le journal, examinons le code de SendSCImage et assurez-vous de le comprendre.\nLes trois premières lignes créent une classe DCXAPP et définissent le niveau de journalisation sur un niveau inférieur au niveau le plus élevé ("Debug"). La classe DCXAPP est utilisée pour contrôler les paramètres globaux de RZDCX. Une fois qu'il est hors de portée, les paramètres restent.\nEnsuite, nous avons le bloc try-catch qui est très simple. Nous créons une classe DCXREQ et l’utilisons pour envoyer l’objet que nous avons créé à l’aide de la méthode SendObject. DCXREQ est un demandeur DICOM – une application DICOM qui initie le réseau DICOM avec une autre application et envoie des commandes DICOM. SendObject prend cinq (5) paramètres et encapsule tout le monde de la mise en réseau DICOM. L’ensemble de ce journal a été généré par cette méthode unique car il effectue tout le travail de mise en réseau DICOM pour vous et c’est exactement ce qui est unique dans RZDCX, vous n’aurez pas à traiter tous ces détails. Néanmoins, il est bon de savoir ce qui se passe à l’intérieur. Ainsi, lorsque la situation se gâte, vous avez une idée de ce qui pourrait mal tourner.\nComme toutes les autres méthodes de mise en réseau de DCXREQ, les quatre (4) premiers paramètres de SendObject sont utilisés pour établir la connexion réseau DICOM avec l'application DICOM distante.\nLe premier paramètre est notre titre d'entité d'application. Dans le réseau DICOM, chaque nœud est une entité d'application (AE) et son nom est AE Title. Vous vous demandez peut-être pourquoi nous avons besoin d'un titre AE si nous avons un nom de serveur ou une adresse IP et que la réponse est qu'un titre AE est en quelque sorte un alias pour la combinaison adresse IP et numéro de port. Nous pouvons exécuter de nombreuses applications DICOM sur un seul serveur. Je peux exécuter deux instances de mon PACS sur le même ordinateur, une sur le port 104, qui est le port TCP / IP standard réservé aux communications DICOM, et une autre sur le port 1104. Chaque application peut être complètement indépendante de l'autre. Je peux exécuter autant d'applications DICOM que je le souhaite, toutes ayant la même adresse IP. \nEn passant, DICOM est presque toujours utilisé dans un environnement de réseau local et je déconseille fortement à quiconque d’utiliser DICOM dans un environnement de réseau étendu, même si je sais que certaines personnes le font, mais ce n’est vraiment pas une bonne idée. Le protocole DICOM est interne, privé, sur votre réseau local, de préférence dans son propre sous-réseau dédié.\nLes titres AE sont sensibles à la casse, 16 caractères maximum.\nLe second paramètre est le titre AE de l'application à laquelle nous souhaitons nous connecter. Nous l'appelons parfois l'application cible ou appelé titre AE ou AE répondant ou simplement l'homologue.\nLe troisième paramètre est le nom du serveur (ou l'adresse IP) du serveur sur lequel l'AE appelé est exécuté.\nLe quatrième paramètre est le numéro de port écouté par l'AE appelé.\nCeci conclut les paramètres communs à toutes les méthodes réseau DCXREQ. Avec ces paramètres, nous pouvons commencer une ‘Association’ avec l’AE appelé.\nLe nouveau terme qui nous intéresse ici est Association. Qu'est-ce que c'est? C’est comme une session réseau. C’est un cadre dans lequel la conversation avec l’appelant appelé va avoir lieu.\nNous pouvons diviser la communication réseau DICOM en deux parties. La première partie configure l'association et la seconde échange des commandes DICOM."},{"id":"text-69","heading":"Text","content":"99% des difficultés liées à la mise en réseau DICOM sont liées à la première partie – la négociation d’association. \nMême si cette étape est passée et que nous commençons à échanger des commandes, il est probable que les problèmes proviennent de fautes dans la première partie."},{"id":"text-70","heading":"Text","content":"Le cinquième paramètre est l'objet que nous aimerions envoyer.SendObject effectue les opérations suivantes:"},{"id":"text-71","heading":"Text","content":"Démarrer une connexion TCP / IP\nNégocie les paramètres d'association pour convenir de ce qui peut être fait pendant l'association\nEnvoyer l'objet DICOM\nFermer l'association\nFermer la connexion TCP / IP"},{"id":"text-72","heading":"Text","content":"Revenons au journal et examinons maintenant la première partie du journal. C'est ici:"},{"id":"text-73","heading":"Text","content":"2011-12-1022: 22: 25.906000 1508 paramètres de demande d'association INFO:"},{"id":"text-74","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-75","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8"},{"id":"text-76","heading":"Text","content":"Leur UID de classe d'implémentation:"},{"id":"text-77","heading":"Text","content":"Leur nom de version d'implémentation:"},{"id":"text-78","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-79","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-80","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-81","heading":"Text","content":"Nom de l'application qui répond: Titre de l'APP"},{"id":"text-82","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-83","heading":"Text","content":"Leur taille maximale de réception PDU: 0"},{"id":"text-84","heading":"Text","content":"Cette partie du journal est une sauvegarde textuelle de la première information envoyée à l'AE appelé et appelée Demande d'association. C’est un ensemble de paramètres décrivant notre application, ses capacités et ses intentions au cours de cette session.\nChaque entrée de journal dans le journal RZDCX commence par un horodatage, un ID de thread (1508 dans ce cas) et le niveau de journal de l'entrée (INFO dans ce cas). Dans le journal complet ci-dessus, j'ai mis en évidence les horodatages au début de chaque entrée du journal.\nLe premier élément de la demande d’association identifie notre implémentation DICOM."},{"id":"text-85","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-86","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8\nDans ce cas, il s’agit de l’UID RZDCX et du numéro de version. C’est toujours intéressant, car les boîtes à outils et les systèmes DICOM ont leurs propres petits problèmes. Par conséquent, si vous savez que certains systèmes ont un problème que vous avez déjà identifié et que vous voyez que vous utilisez la même mise en œuvre, vous savez comment le résoudre. Lors de la communication avec l’autre fournisseur d’applications, il est également important de signaler la version de l’application.\nDans le vidage de demandes, nous ne voyons que nos informations d'implémentation, mais plus loin dans le journal du vidage de réponses, nous verrons l'identification de l'AE appelé.\nEnsuite, nous avons le nom du contexte de l'application. Il s'agit d'un UID réservé à DICOM. C'est toujours la meme chose."},{"id":"text-87","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-88","heading":"Text","content":"Nous avons ensuite les titres AE: le titre AE appelant et le titre AE appelé."},{"id":"text-89","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-90","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-91","heading":"Text","content":"Notez qu’il s’agit simplement de la demande et que ce sont les valeurs que nous avons transmises à SendObject. Dans la réponse, nous aurons également ce qu'ils nous ont renvoyé. Habituellement, l'application qui répond à la demande d'association doit vérifier que l'AE appelé correspond à son propre AE et que l'AE appelant est quelque chose qui se trouve dans son fichier de configuration ou sa base de données. Si cela ne correspond pas, l'AE appelé peut rejeter l'association.\nEnsuite, nous avons la taille maximale de PDU. PDU est un ‘paquet’ au niveau de l’application qui indique quelle est la taille de la mémoire tampon que nous sommes disposés à utiliser pour chaque demande."},{"id":"text-92","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-93","heading":"Text","content":"Dans ce cas, nous ne proposons pas plus de 32K. Un problème connu est que certaines applications envoient une demande d’association si grosse que l’AE appelé ne peut pas consommer. Nous verrons dans une minute pourquoi ils le font et comment l’éviter.\nLe bloc suivant du journal fait toujours partie de la première entrée du journal. La demande d'association comprend une liste de services DICOM. Les éléments de cette liste sont appelés contextes de présentation:"},{"id":"text-94","heading":"Text","content":"Le contexte\nID: 1 (proposé)"},{"id":"text-95","heading":"Text","content":"Abstrait\nSyntaxe: = VerificationSOPClass"},{"id":"text-96","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-97","heading":"Text","content":"Rôle SCP / SCU accepté: par défaut"},{"id":"text-98","heading":"Text","content":"Proposé\nSyntaxe de transfert:"},{"id":"text-99","heading":"Text","content":"= LittleEndianExplicit"},{"id":"text-100","heading":"Text","content":"= BigEndianExplicit"},{"id":"text-101","heading":"Text","content":"= LittleEndianImplicit"},{"id":"text-102","heading":"Text","content":"Le contexte\nID: 3 (proposé)"},{"id":"text-103","heading":"Text","content":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage"},{"id":"text-104","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-105","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-106","heading":"Text","content":"Proposé\nSyntaxe de transfert:"},{"id":"text-107","heading":"Text","content":"= LittleEndianExplicit"},{"id":"text-108","heading":"Text","content":"Négociation prolongée demandée: aucune"},{"id":"text-109","heading":"Text","content":"Négociation étendue acceptée: aucune"},{"id":"text-110","heading":"Text","content":"Nous avons envoyé une liste avec deux éléments. Chaque élément est un contexte de présentation et identifie un service DICOM que nous souhaitons utiliser lors de cette association. Les contextes de présentation sont étrangement numérotés. Le premier est 1, le second est 3 et un troisième aurait été 5. Pourquoi? Je ne sais pas. C'est comme ça. Comme je l'ai dit, ils sont étrangement numérotés.\nLe premier service que nous avons demandé est la vérification. Cette opération est effectuée à l'aide de la commande DICOM C-ECHO. Dans le journal, nous voyons ceci:"},{"id":"text-111","heading":"Text","content":"Syntaxe abstraite:\n= VerificationSOPClass"},{"id":"text-112","heading":"Text","content":"Chaque service a un UID. Dans le fichier journal, les UID connus sont remplacés par leur nom. Le service de vérification est une sorte de ping de haut niveau. C-ECHO est une commande DICOM qui indique qu’une fois envoyé, l’homologue doit répondre avec un statut de réussite. Notez que nous n'avons pas encore envoyé de commande C-ECHO. Nous venons de demander à l'AE appelé dans notre demande d'association de l'utiliser dans la deuxième partie. Nous n’avons pas non plus dit que nous enverrions un C-ECHO. Une application DICOM qui écoute sur un port et attend les connexions entrantes doit toujours implémenter le service de vérification. Notre petite application n'écoute pas encore de port. À ce stade, nous jouons uniquement le rôle de client ici et nous nous connectons à une autre application. En tant que client, c’est toujours une bonne habitude de demander le service de vérification. Si nous ne le demandons pas et que l’application à laquelle nous nous connectons ne prend en charge aucun des autres services que nous demandons, elle nous le raccrochera. En ajoutant la vérification à notre demande, nous obligeons le serveur à dire oui pour au moins une chose que nous demandons.\nLe deuxième service que nous avons demandé est le stockage secondaire d’images de capture:"},{"id":"text-113","heading":"Text","content":"Syntaxe abstraite:\n= SecondaryCaptureImageStorage\nSi vous vous en souvenez, lorsque nous avons parlé de SOP Class UID au chapitre 4, j’ai dit que SOP est une paire de services et de définition d’objet. Nous avons donc cette combinaison. Nous demandons à l'application homologue de stocker un objet que nous allons envoyer et nous lui dirons qu'il s'agira d'une image de capture secondaire. Si nous avions également un autre type d'objet, par exemple une image CT, nous aurions dû demander un troisième contexte de présentation. L'AE appelé peut autoriser ou interdire chacun des services. Il est donc possible de créer une application qui accepte des types d’objets spécifiques. Par exemple, si nous écrivons un poste de travail de reconstruction 3D pour les tomodensitogrammes, nous ne pouvons accepter que les images CT et obliger ainsi l’application d’envoi à nous envoyer ce type d’objets. Cependant, ce n’est pas une très bonne idée car les applications envoient généralement des études complètes et il peut y avoir dans une étude des images de différentes classes, par exemple une série avec un scanner, une autre avec un rapport et une autre avec un rayonnement. rapport de dose et si nous limitons notre poste de travail à accepter uniquement les images CT, l'application implémentée pour envoyer des études complètes conservera les échecs de rapport car ils ne peuvent pas envoyer les autres objets même si les images CT dont nous avions besoin sont arrivées. Une meilleure conception consisterait à autoriser tous les types d’objets et à ignorer ceux dont nous n’avons pas besoin.\nCe mécanisme de négociation de chaque type d’objet a conduit certains vendeurs à la très mauvaise habitude de simplement demander tous les objets possibles qu’ils connaissent. Cela peut entraîner une requête d'association longue de 50 Ko et si l'implémentation AE appelée ne peut lire que des requêtes de 32 Ko, elle peut facilement planter sur le bogue de débordement de mémoire tampon le plus simple. En outre, l'envoi d'une demande d'association 50K à chaque fois que vous souhaitez simplement vérifier une connexion à l'aide d'une commande C-ECHO est une pure perte de temps.\nSendObject de RZDCX ne négocie que les UID de classe SOP requis. La méthode d'envoi DCXREQ envoie un ensemble de fichiers DICOM. Tout d'abord, il passe en revue tous les fichiers, crée une liste de toutes leurs classes SOP, puis négocie cette liste avec le AE appelé.\nCeci conclut notre demande d'association. Nous nous sommes identifiés et avons déclaré ce que nous appelons. Voyons maintenant ce que l’AE appelé va dire. Après l'envoi de la demande d'association, l'AE appelé lit la demande et renvoie une réponse d'association. C'est presque identique à la demande. L’appelant AE remplit simplement le formulaire que nous avons envoyé. La deuxième entrée de ce journal est un vidage de cette réponse."},{"id":"text-114","heading":"Text","content":"2011-12-1022: 22: 26.062000 1508 INFO Résultat de la demande d'association: Ordinaire"},{"id":"text-115","heading":"Text","content":"Paramètres de réponse d'association:"},{"id":"text-116","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-117","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8"},{"id":"text-118","heading":"Text","content":"Leur UID de classe d'implémentation: 1.2.826.0.1.3680043.2.60.0.1"},{"id":"text-119","heading":"Text","content":"Leur nom de version d'implémentation: softlink_jdt103"},{"id":"text-120","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-121","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-122","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-123","heading":"Text","content":"Nom de l'application qui répond: PACS"},{"id":"text-124","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-125","heading":"Text","content":"Leur taille maximale de réception PDU: 32768"},{"id":"text-126","heading":"Text","content":"Le contexte\nID: 1 (Accepté)"},{"id":"text-127","heading":"Text","content":"Abstrait\nSyntaxe: = VerificationSOPClass"},{"id":"text-128","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-129","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-130","heading":"Text","content":"Accepté\nSyntaxe de transfert: = LittleEndianImplicit"},{"id":"text-131","heading":"Text","content":"Le contexte\nID: 3 (Syntaxe abstraite non prise en charge)"},{"id":"text-132","heading":"Text","content":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage"},{"id":"text-133","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-134","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-135","heading":"Text","content":"Négociation prolongée demandée: aucune"},{"id":"text-136","heading":"Text","content":"Négociation étendue acceptée: aucune"},{"id":"text-137","heading":"Text","content":"D'après l'horodatage, vous pouvez voir qu'il est revenu juste un dixième de seconde après l'envoi de la demande et que l'état de la réponse est Normal (j'ai mis en surbrillance les paramètres qui étaient vides ou qui ont changé auparavant). Vous pouvez également voir que leur identification d'implémentation est maintenant renseignée avec la valeur softlink_jdt103, qui identifie un package utilitaire Java très pratique de Tiani. Leur titre AE est bien «PACS» et ils ont accepté notre demande d'association. Il y a quelques cas ici. Un cas est qu'ils ne répondent tout simplement pas. Dans ce cas, notre demande expirera sans obtenir de réponse. Un autre cas est ce que nous avons ici, c'est-à-dire que la demande d'association a été acceptée et que nous sommes maintenant connectés à l'AE appelé. Le troisième cas est que l’appelant appelé décide qu’il ne veut pas nous parler et envoie une réponse de rejet d’association. Par exemple, si son titre AE n'est pas «PACS», le message «Mauvais titre AE appelé» apparaît alors. Le motif du rejet est codé dans le statut de la réponse et comporte parfois une explication textuelle supplémentaire.\nNous avons également reçu la liste des services. La vérification a été acceptée, mais pas le stockage de capture secondaire. Cela signifie que si nous le souhaitons, nous pouvons envoyer une commande C-ECHO mais nous ne pouvons pas envoyer notre image de capture secondaire à l’aide d’un C-STORE. Parce que c’est ce que nous voulions faire dans cette association, vous voyez les deux prochaines entrées du journal:"},{"id":"text-138","heading":"Text","content":"2011-12-1022: 22: 31.234000 1508 INFO Impossible de stocker un objet car la classe d'opération n'a pas été négociée ou acceptée\npar les pairs. SID de classe UID:\n1.2.840.10008.5.1.4.1.1.7, UID d’instance SOP:\n2.16.124.113543.6021.1.3.3727584845.5056.1323548540.2"},{"id":"text-139","heading":"Text","content":"2011-12-1022: 22: 31.234000 ERREUR 1508 dans DCXREQ, Code: 520, Texte: DIMSE Aucune présentation valide\nID de contexte\nCela signifie que nous ne pouvons pas stocker l’objet car l’homologue ne prend pas en charge ce service. Yippy! Nous pourrions en fait comprendre ce qui ne va pas ha?! Maintenant, Burt peut aller voir l’administrateur du PACS et lui demander pourquoi son PACS ne peut pas stocker les captures secondaires et l’administrateur du PACS va probablement demander à Burt sur quel serveur il a essayé de se connecter et sur quel port, puis indiquer que le port 6104 est le gestionnaire de listes de travail. qui servent les demandes de liste de travail de modalité et d’étapes de procédure effectuées (qui sont des services DICOM, nous en apprendrons plus tard) et que si nous voulons envoyer quelque chose au PACS, nous devons essayer de vous connecter au port 104. Cas résolu.\nOK, renouvelons cette opération et connectez-vous cette fois au port 104. C’est une bonne idée de pouvoir configurer le titre, l’adresse IP et le numéro de port de l’AE appelé dans notre application afin que nous n’ayons pas à compiler à chaque fois. La plupart des applications DICOM ont une telle configuration. Il s’agit généralement d’une table avec au moins les colonnes: Titre AE, hôte et port et éventuellement un identifiant et un commentaire. Voici le journal d’un envoi réussi. Cette fois, le niveau de journalisation a été défini sur Debug."},{"id":"text-140","heading":"Text","content":"2011-12-1512: 22: 51.000000 Association 4296 INFO\nParamètres de demande:"},{"id":"text-141","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-142","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8"},{"id":"text-143","heading":"Text","content":"Leur UID de classe d'implémentation:"},{"id":"text-144","heading":"Text","content":"Leur nom de version d'implémentation:"},{"id":"text-145","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-146","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-147","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-148","heading":"Text","content":"Nom de l'application qui répond: Titre de l'APP"},{"id":"text-149","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-150","heading":"Text","content":"Leur taille maximale de réception PDU: 0"},{"id":"text-151","heading":"Text","content":"Le contexte\nID: 1 (proposé)"},{"id":"text-152","heading":"Text","content":"Abstrait\nSyntaxe: = VerificationSOPClass"},{"id":"text-153","heading":"Text","content":"Rôle proposé du SCP / SCU: Par défaut"},{"id":"text-154","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-155","heading":"Text","content":"Proposé\nSyntaxe de transfert:"},{"id":"text-156","heading":"Text","content":"= LittleEndianExplicit"},{"id":"text-157","heading":"Text","content":"= BigEndianExplicit"},{"id":"text-158","heading":"Text","content":"= LittleEndianImplicit"},{"id":"text-159","heading":"Text","content":"Le contexte\nID: 3 (proposé)"},{"id":"text-160","heading":"Text","content":"Abstrait\nSyntaxe: = SecondaryCaptureImageStorage"},{"id":"text-161","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-162","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-163","heading":"Text","content":"Proposé\nSyntaxe de transfert:"},{"id":"text-164","heading":"Text","content":"= LittleEndianExplicit"},{"id":"text-165","heading":"Text","content":"Négociation prolongée demandée: aucune"},{"id":"text-166","heading":"Text","content":"Négociation étendue acceptée: aucune"},{"id":"text-167","heading":"Text","content":"2011-12-1512: 22: 51.000000 4296 PDU RQ d'associé de construction DEBUG"},{"id":"text-168","heading":"Text","content":"2011-12-1512: 22: 51.000000 4296 DEBUG WriteToConnection, longueur: 310, octets écrits:\n310, numéro de boucle: 1"},{"id":"text-169","heading":"Text","content":"2011-12-1512: 22: 51.015000 4296 Type de PDU DEBUG: accepteur de partenariat, longueur de PDU: 216 +\nEn-tête PDU 6 octets"},{"id":"text-170","heading":"Text","content":"02 00\n00 00 00 d8 00\n01 00 00\n50 41 43\n53 20 20"},{"id":"text-171","heading":"Text","content":"20 20\n20 20 20 20 20\n20 20 20\n52 5a 44\n43 58 20"},{"id":"text-172","heading":"Text","content":"20 20\n20 20 20 20 20\n20 20 20\n00 00 00\n00 00 00"},{"id":"text-173","heading":"Text","content":"00 00\n00 00 00 00 00\n00 00 00\n00 00 00\n00 00 00"},{"id":"text-174","heading":"Text","content":"00 00\n00 00 00 00 00\n00 00 00\n10 00 00\n15 31 2e"},{"id":"text-175","heading":"Text","content":"32 2e\n38 34 30 2e 31\n30 30 30\n38 2e 33\n2e 31 2e"},{"id":"text-176","heading":"Text","content":"31 2e\n31 21 00 00 19\n01 00 00\n00 40 00\n00 11 31"},{"id":"text-177","heading":"Text","content":"2e 32\n2e 38 34 30 2e\n31 30 30\n30 38 2e\n31 2e 32"},{"id":"text-178","heading":"Text","content":"21 00\n00 1b 03\n00 00 00\n40 00 00\n13 31 2e\n32 2e"},{"id":"text-179","heading":"Text","content":"38 34\n30 2e 31 30 30\n30 38 2e\n31 2e 32\n2e 31 50"},{"id":"text-180","heading":"Text","content":"00 00\n3b 51 00 00 04\n00 00 80\n00 52 00\n00 1c 31"},{"id":"text-181","heading":"Text","content":"2e 32\n2e 38 32 36 2e\n30 2e 31\n2e 33 36\n38 30 30"},{"id":"text-182","heading":"Text","content":"34 33\n2e 32 2e\n36 30 2e\n30 2e 31\n55 00 00\n0f 73"},{"id":"text-183","heading":"Text","content":"6f 66\n74 6c 69 6e 6b\n5f 6a 64\n74 31 30 33"},{"id":"text-184","heading":"Text","content":"2011-12-1512: 22: 51.015000 4296 INFO Résultat de la demande d'association: Normal"},{"id":"text-185","heading":"Text","content":"Paramètres de réponse d'association:"},{"id":"text-186","heading":"Text","content":"Notre classe d'implémentation UID: 2.16.124.113543.6021.2"},{"id":"text-187","heading":"Text","content":"Notre version de mise en œuvre Nom: RZDCX_2_0_1_8"},{"id":"text-188","heading":"Text","content":"Leur classe d'implémentation UID: 1.2.826.0.1.3680043.2.60.0.1"},{"id":"text-189","heading":"Text","content":"Leur version de mise en œuvre Nom: softlink_jdt103"},{"id":"text-190","heading":"Text","content":"Nom du contexte d'application: 1.2.840.10008.3.1.1.1"},{"id":"text-191","heading":"Text","content":"Nom de l'application appelante: RZDCX"},{"id":"text-192","heading":"Text","content":"Nom de l'application appelée: PACS"},{"id":"text-193","heading":"Text","content":"Nom de l'application qui répond: PACS"},{"id":"text-194","heading":"Text","content":"Notre Max PDU Receive Size: 32768"},{"id":"text-195","heading":"Text","content":"Leur Max PDU Receive Size: 32768"},{"id":"text-196","heading":"Text","content":"Le contexte\nID: 1 (Accepté)"},{"id":"text-197","heading":"Text","content":"Abstrait\nSyntaxe: =VérificationSOPClass"},{"id":"text-198","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-199","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-200","heading":"Text","content":"Accepté\nSyntaxe de transfert: = LittleEndianImplicit"},{"id":"text-201","heading":"Text","content":"Le contexte\nID: 3 (Accepté)"},{"id":"text-202","heading":"Text","content":"Abstrait\nSyntaxe: =SecondaryCaptureImageStorage"},{"id":"text-203","heading":"Text","content":"Proposé\nRôle SCP / SCU: Par défaut"},{"id":"text-204","heading":"Text","content":"Accepté\nRôle SCP / SCU: Par défaut"},{"id":"text-205","heading":"Text","content":"Accepté\nSyntaxe de transfert: = LittleEndianExplicit"},{"id":"text-206","heading":"Text","content":"Négociation prolongée demandée: aucune"},{"id":"text-207","heading":"Text","content":"Négociation étendue acceptée: aucune"},{"id":"text-208","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE Commande à envoyer:"},{"id":"text-209","heading":"Text","content":"# Used TransferSyntax: UnknownTransferSyntax"},{"id":"text-210","heading":"Text","content":"(0000,0000) UL 0 # 4, 1 CommandGroupLength"},{"id":"text-211","heading":"Text","content":"(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID"},{"id":"text-212","heading":"Text","content":"(0000,0100) US 1 n ° 2, 1 CommandField"},{"id":"text-213","heading":"Text","content":"(0000,0110) US 1 # 2, 1 MessageID"},{"id":"text-214","heading":"Text","content":"(0000,0700) US 0 # 2, 1 priorité"},{"id":"text-215","heading":"Text","content":"(0000,0800) US 1 # 2, 1 DataSetType"},{"id":"text-216","heading":"Text","content":"(0000,1000) UI [2.16.124.113543.6021.1.3.3727584845.720.1323944568.6]\n# 52, 1 AffectedSOPInstanceUID"},{"id":"text-217","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 146 octets"},{"id":"text-218","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1"},{"id":"text-219","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 146, octets écrits:\n146, numéro de boucle: 1"},{"id":"text-220","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG DIMSE sendDcmDataset: envoi de 7894 octets"},{"id":"text-221","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 12, octets écrits:\n12, boucle no: 1"},{"id":"text-222","heading":"Text","content":"2011-12-1512: 22: 51.031000 4296 DEBUG WriteToConnection, longueur: 7894, octets\nécrit: 7894, boucle no: 1"},{"id":"text-223","heading":"Text","content":"2011-12-1512: 22: 51.046000 4296 INFO DIMSE receiveCommand"},{"id":"text-224","heading":"Text","content":"2011-12-1512: 22: 51.062000 4296 INFO DIMSE receiveCommand: 1 pdv (178 octets),\npresID = 3"},{"id":"text-225","heading":"Text","content":"2011-12-1512: 22: 51.062000 4296 Commande DEBUG DIMSE reçue:"},{"id":"text-226","heading":"Text","content":"# Used TransferSyntax: LittleEndianImplicit"},{"id":"text-227","heading":"Text","content":"(0000,0002) UI = SecondaryCaptureImageStorage #\n26, 1 AffectedSOPClassUID"},{"id":"text-228","heading":"Text","content":"(0000,0100) US 32769 N ° 2, 1 CommandField"},{"id":"text-229","heading":"Text","content":"(0000,0120) US 1 # 2, 1 MessageIDBeingRespondedTo"},{"id":"text-230","heading":"Text","content":"(0000,0800) US 257 N ° 2, 1 DataSetType"},{"id":"text-231","heading":"Text","content":"(0000,0900)\nUS 45056\n# 2, 1 Statut"},{"id":"text-232","heading":"Text","content":"(0000,0902)\nLO [set InstanceNumber to 0]\n# 24, 1 ErrorComment"},{"id":"text-233","heading":"Text","content":"(0000,1000) UI\n[2.16.124.113543.6021.1.3.3727584845.720.1323944568.6] # 52, 1 AffectedSOPInstanceUID"},{"id":"text-234","heading":"Text","content":"2011-12-1512: 22: 51.062000 4296 DEBUG WriteToConnection, longueur: 10, octets écrits:\n10, numéro de boucle: 1"},{"id":"text-235","heading":"Text","content":"La commande de stockage a réussi, mais nous avons récupéré un statut d'avertissement (45056 = 0xB000) au lieu de succès (0x0000). Nous avons également reçu un commentaire d’avertissement indiquant que l’appelant appelé avait changé l’élément numéro d’instance de null à 0, peut-être afin de l’indexer correctement dans sa base de données.\nNous aurions dû parler de syntaxes de transfert, mais ceci est déjà un long post, je vais donc laisser les syntaxes de transfert pour une autre fois. \nRésumons ce que nous avons couvert dans cet article."},{"id":"text-236","heading":"Text","content":"Les nœuds du réseau DICOM sont appelés entités d'application (AE) et sont identifiés à l'aide d'un nom respectant la casse, appelé titre AE.\nLa communication DICOM se fait toujours entre deux AE, c’est-à-dire qu’elle est peer-to-peer.\nLa «session» DICOM s’appelle Association\nL'association est divisée en deux étapes. La première étape s'appelle la négociation d'association. Dans la deuxième étape, les commandes DICOM échangées par les deux AE\nDans la négociation d'association, l'AE demandeur envoie une liste de contextes de présentation identifiant les services DICOM qu'il souhaite utiliser, et l'AE répondant renvoie la même liste marquée des services acceptés et utilisables et des services qu'il a refusés et ne peuvent pas être utilisés. utilisé dans cette association.\nLe service de vérification est un service de niveau application utilisé pour vérifier la communication entre deux AE.\nLe service de stockage est utilisé pour transférer des objets DICOM entre AE. Le service de stockage est négocié séparément pour chaque classe SOP. Par exemple, une application peut autoriser le stockage d’images CT et interdire le stockage d’images MR. Ce n'est pas un bon design cependant."},{"id":"text-237","heading":"Text","content":"C'est tout. J'espère que vous me croyez toujours que DICOM est facile. Comme toujours, les commentaires sont les bienvenus."},{"id":"text-238","heading":"Text","content":"Click to rate this post!\n \n [Total: 0 Average: 0]"}],"media":{"primary_image":""},"relations":[{"rel":"canonical","href":"https://tutos-gameserver.fr/2019/07/12/dicom-cest-facile-introduction-a-dicom-bien-choisir-son-serveur-d-impression/"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/07/12/dicom-cest-facile-introduction-a-dicom-bien-choisir-son-serveur-d-impression/llm","type":"text/html"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/07/12/dicom-cest-facile-introduction-a-dicom-bien-choisir-son-serveur-d-impression/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}