L'interrogation échographique fonctionne mais la récupération échoue : tracer la connexion C-MOVE distincte

Pourquoi l'interrogation peut-elle réussir alors que chaque récupération échoue ?

Peu de symptômes réseau déroutent autant les équipes de maintenance qu'un système d'échographie capable d'effectuer des recherches sans erreur dans le système d'archivage et de transmission d'images (PACS) de l'hôpital, mais qui échoue chaque fois qu'un échographiste tente de récupérer un examen antérieur. La console affiche la liste des examens du patient, l'opérateur en sélectionne un et appuie sur Retrieve, puis, après une pause, le système signale un échec générique de transfert ou de récupération. Le libellé exact varie selon le fabricant et la version logicielle.

L'hypothèse intuitive est que la connectivité réseau est symétrique : si l'échographe peut interroger l'archive, la chaîne fonctionne, de sorte qu'un échec de récupération doit indiquer un défaut interne de l'échographe, une option logicielle corrompue ou une défaillance de la carte d'entrées/sorties (I/O) réseau. Pour la récupération DICOM (Digital Imaging and Communications in Medicine) par C-MOVE, cette hypothèse est erronée. L'interrogation et la récupération font appel à des opérations différentes et, pour C-MOVE, à des associations réseau distinctes ouvertes dans des directions opposées. ^{1 5}

Lorsqu'un système d'échographie exécute une requête, il agit en tant que Service Class User (SCU) de la classe de service Query/Retrieve et utilise l'opération C-FIND. ⁹ L'échographe ouvre une connexion TCP vers l'adresse IP et le port d'écoute configurés de l'archive. Le port 104 est le port DICOM bien connu, mais les ports sont configurés selon le site ; sur la gamme Philips citée ci-dessous, le port d'écoute est défini par défaut sur 104 et passe à 2762 lorsque Secure DICOM est activé. ³ L'échographe demande une association en utilisant son propre AE Title (appelant) et l'AE Title (appelé) de l'archive, envoie la requête C-FIND avec des clés de recherche telles que l'identifiant patient (Patient ID), le nom ou la date d'examen, et reçoit les correspondances sur cette même association.

Lorsque l'échographiste appuie sur Retrieve, l'échographe ne télécharge pas de fichiers sur cette association. Il envoie une requête C-MOVE demandant à l'archive d'acheminer les instances sélectionnées vers un AE Title Move Destination désigné. La section C.4.2 de DICOM PS3.4 stipule que les sous-opérations C-STORE « doivent toujours être accomplies sur une association différente de l'association qui accomplit l'opération C-MOVE », le Query/Retrieve SCP agissant en tant que Storage SCU. ¹

La raison figure dans la même section : l'entité d'application qui reçoit les instances stockées « peut être ou ne pas être l'initiateur de l'opération C-MOVE ». C-MOVE est conçu pour qu'un demandeur puisse envoyer un examen vers un système tiers, tel qu'une station de revue. C'est pourquoi l'archive, et non le demandeur, ouvre la connexion d'acheminement, même lorsque l'échographe demande que les images lui soient renvoyées. ¹

Une interrogation réussie prouve donc uniquement que l'échographe peut joindre le port d'écoute de l'archive. Elle ne prouve pas que le chemin retour, depuis l'archive vers le port d'écoute de la destination, est configuré, autorisé par les pare-feu ou accepté par le récepteur DICOM de l'échographe. Avant de suspecter le matériel, séparez les échecs de stockage côté échographe des échecs dans le sens de la récupération en traçant chaque association séparément.

Quels sont les trois points de terminaison et les deux associations dans une récupération en échographie ?

Pour diagnostiquer avec précision un échec C-MOVE, un ingénieur doit reconnaître qu'une récupération DICOM implique trois points de terminaison logiques distincts et deux associations réseau indépendantes, même lorsque le système d'échographie demande que les images lui soient délivrées. La section C.4.2 de DICOM PS3.4 définit ces rôles avec une précision technique : ¹

• SCU demandeur (console d'échographie) : Le système qui initie l'association 1 vers l'archive, émet les requêtes d'interrogation C-FIND et émet la commande de récupération C-MOVE. Il identifie les examens, séries ou instances à transférer et désigne l'AE Title Move Destination.
• Query/Retrieve SCP (archive PACS ou VNA) : accepte l'association 1, recherche les correspondances avec la requête, reçoit le C-MOVE, consulte le Move Destination AE Title dans sa propre configuration et agit en tant que Storage SCU pour envoyer les instances.
• Move Destination (Storage SCP) : le nœud désigné dans la requête C-MOVE pour recevoir les images. Il s'agit souvent du même échographe que celui qui a émis la demande, mais la norme autorise tout nœud de stockage, tel qu'une station de revue. Sur la gamme Philips citée ici, l'échographe indique son propre AE Title comme destination. ^{1 3 5}

Dans la mesure où la Move Destination peut être un nœud tiers, le protocole C-MOVE a été délibérément conçu de sorte que l'archive initie la connexion d'acheminement. Cela crée deux associations réseau distinctes avec des sens de connexion opposés :

Association 1 (association de requête directe) : initiée par le SCU de l'échographe vers le SCP Q/R du PACS. Cette association prend en charge la négociation A-ASSOCIATE, l'échange de requêtes C-FIND, la requête C-MOVE, les réponses de statut « en attente » (pending) périodiques du C-MOVE et la réponse finale d'achèvement du C-MOVE. Si cette association échoue, l'échographe ne peut pas rechercher de patients ni envoyer la commande initiale de récupération.

Association 2 (association de stockage inverse) : ouverte par l'archive, agissant en tant que Storage SCU, vers la Move Destination, agissant en tant que Storage SCP, après réception par l'archive de la requête C-MOVE. Elle achemine une requête C-STORE par instance, qu'il s'agisse d'une image, d'une boucle ciné ou d'un rapport structuré. Si cette association ne peut pas être ouverte, est bloquée par un pare-feu ou est rejetée par le récepteur, les sous-opérations échouent alors que l'association 1 continue de fonctionner. ^{1 2 6}

L'annexe F de la norme PS3.2 illustre cette même distinction dans un exemple informatif de déclaration de conformité pour un serveur query-retrieve fictif. Dans cet exemple, l'entité d'application QUERY-RETRIEVE-SCP « n'initiera jamais d'associations » ; lors d'un C-MOVE, elle ordonne à une entité d'application STORAGE-SCU distincte « d'initier une association avec l'AE DICOM de destination ». Son tableau F.4.2-8 montre qu'un dépassement de délai, un abandon ou une perte de socket sur cette association d'acheminement est signalé en retour et qu'un statut approprié est envoyé dans la réponse C-MOVE. Les produits réels implémentent cela différemment, mais le sens de la seconde connexion est le même. ²

Que vous indique réellement la réponse C-MOVE finale ?

La plupart des consoles n'affichent qu'une brève fenêtre contextuelle lorsqu'une récupération échoue. Des éléments plus utiles se trouvent dans la réponse C-MOVE renvoyée sur l'association 1, généralement visibles dans le journal DICOM de l'archive et parfois dans le journal de maintenance de l'échographe. Le tableau C.4-2 de la PS3.4 répertorie les statuts C-MOVE sous Failure (refusé, erreur ou impossible à traiter), Cancel, Warning, Success et Pending. ¹

La PS3.4 définit également les attributs de comptage des sous-opérations. Les réponses Pending doivent les comporter. Les réponses finales peuvent en comporter certains, de sorte qu'un comptage manquant ne constitue pas en soi une erreur :

• Number of Remaining Sub-operations (0000,1020) : instances restant à envoyer. Obligatoire dans les réponses Pending, facultatif dans Cancel, et non inclus dans les réponses Warning, Failure ou Success.
• Number of Completed Sub-operations (0000,1021) : sous-opérations C-STORE terminées avec succès. Obligatoire dans les réponses Pending, facultatif dans les réponses finales.
• Number of Failed Sub-operations (0000,1022) : sous-opérations C-STORE ayant échoué. Obligatoire dans les réponses Pending, facultatif dans les réponses finales.
• Number of Warning Sub-operations (0000,1023) : sous-opérations terminées avec un statut d'avertissement.
• Failed SOP Instance UID List (0008,0058) : dans les réponses Cancel, Failure ou Warning, identifiants des instances dont le C-STORE a échoué. Il est absent lorsqu'aucune sous-opération n'a échoué. ¹

Examinez conjointement le statut et les compteurs. Un échec avec zéro sous-opération terminée et la totalité des instances en échec signifie que rien n'a été transmis. Cela oriente généralement vers l'association elle-même, mais une archive peut produire le même schéma lorsque la destination refuse tous les types d'objets. Des compteurs Completed et Failed tous deux supérieurs à zéro signifient que la voie retour fonctionne pour au moins certaines instances, et que le problème concerne des objets, des encodages ou des ressources de destination particuliers. Les compteurs restreignent la recherche ; le journal de l'archive en indique la raison. ^{1 5}

L'attribut Failed SOP Instance UID List (0008,0058) est souvent le plus utile après le statut. En cas de transfert partiel, comparez les UID en échec avec l'enregistrement de chaque objet dans l'archive. Si chaque élément en échec est une séquence ciné multi-images alors que les images fixes sont bien arrivées, une discordance de syntaxe de transfert ou de contexte de présentation constitue une hypothèse privilégiée. Confirmez-le dans le journal d'association de l'archive avant de modifier quoi que ce soit.

Que désigne le statut Refusé : destination de déplacement inconnue (A801) ?

Le statut A801 (Refusé : destination de déplacement inconnue) est l'un des codes les plus précis que vous puissiez recevoir, et un cours de formation PACS neutre décrit une destination inconnue comme la cause la plus fréquente d'échec des déplacements. Il signifie que l'archive n'a pas pu résoudre l'AE Title désigné comme destination. ^{1 4 5}

La requête C-MOVE transporte la destination uniquement sous la forme d'un AE Title dans Move Destination (0000,0600), sans adresse IP ni port. ¹ L'archive doit convertir cet AE Title en une adresse et un port à partir de sa propre configuration. Medical Connections, fournisseur de boîtes à outils DICOM, fait remarquer que, aussi contraignant que cela puisse paraître, « aucune alternative n'est autorisée par DICOM ». ⁶

Si l'archive ne trouve aucune entrée correspondante, elle ne dispose d'aucune adresse à laquelle se connecter et refuse la requête avec A801. Aucune sous-opération n'est tentée. PS3.4 ne répertorie qu'un commentaire d'erreur comme champ associé pour ce statut, ne vous attendez donc pas à des décomptes de sous-opérations significatifs. ^{1 4}

Les causes cliniques courantes du statut A801 comprennent :

• Échographe neuf ou réinstallé : l'échographe a été configuré pour envoyer des examens au PACS, mais personne n'a ajouté son AE Title, son adresse IP et son port comme destination de récupération dans l'archive.
• Non-correspondance exacte de la chaîne : un AE Title comporte au maximum 16 caractères, et PS3.5 considère les espaces de début et de fin comme non significatifs. ¹² Les caractères internes comptent toujours. Comparez les chaînes caractère par caractère, y compris la casse, les tirets bas par rapport aux traits d'union et la lettre O par rapport au zéro, plutôt que de supposer que l'un ou l'autre système les normalisera.
• AE Titles différents pour l'envoi et la réception : certains systèmes permettent à la console d'utiliser un AE Title lors du stockage et d'en désigner un autre comme destination de récupération. Si seul l'AE Title d'envoi est enregistré dans l'archive, l'AE Title de destination est inconnu.
• Destination erronée saisie sur l'échographe : la console indique une destination qui diffère de l'enregistrement créé par l'administrateur PACS. Dans ce cas, la correction doit être effectuée du côté de l'échographe, sous contrôle des modifications.

Un A801 ne donne aucune raison de remplacer le matériel réseau ni de changer les ports de commutateur. La solution consiste à faire correspondre l'AE Title de destination envoyé par l'échographe à un enregistrement de nœud dans l'archive comportant l'adresse IP et le port d'écoute actuels de l'échographe. L'enregistrement dans l'archive relève de l'administrateur PACS ; le réglage de destination propre à l'échographe relève de quiconque assure la maintenance de l'échographe.

Que signifie le rejet par la destination de l'association de l'archive ?

Si l'archive résout la destination, elle tente d'ouvrir l'association 2 vers cette adresse IP et ce port. La manière dont elle signale un échec à ce stade dépend de l'implémentation. Le système de gestion de données Canon HCBA-01, par exemple, documente A702 lorsque « les sous-opérations C-STORE ne peuvent pas être effectuées en raison de l'échec d'une demande d'association ou d'une demande C-STORE ». D'autres archives peuvent utiliser un statut différent ; lisez donc le code en vous référant à la déclaration de conformité propre à cette archive. ⁴

Un échec à ce stade se décompose en deux scénarios techniques distincts : le blocage du transport réseau et le rejet de l'association au niveau applicatif.

1. Blocage du transport réseau (refus de connexion TCP) : Le serveur PACS tente d'envoyer un paquet TCP SYN à l'adresse IP de l'échographe sur son port d'écoute configuré, mais reçoit soit un paquet TCP RST (connexion refusée), soit aucune réponse (dépassement de délai SYN). Cela se produit lorsque :

• Le service d'écoute DICOM de l'échographe est arrêté ou désactivé au niveau logiciel.
• Un pare-feu hôte sur la console, lorsque la plateforme en comporte un, bloque les connexions entrantes sur le port d'écoute.
• Les pare-feu réseau du service ou les listes de contrôle d'accès (ACL) de réseau local virtuel (VLAN) autorisent le trafic sortant des modalités médicales vers le PACS, mais bloquent le trafic entrant initié depuis la salle des serveurs vers les chariots d'échographie cliniques. ⁵

2. Rejet de l'association au niveau applicatif (A-ASSOCIATE-RJ) : la connexion TCP réussit, mais la destination refuse l'association DICOM. Philips documente ce phénomène comme le mécanisme où l'interrogation fonctionne mais la récupération échoue pour la famille EPIQ Elite, Elite Advanced, E7, E5, CVx, CVxi et Affiniti 70/50/30 Release 6.0.x (000737000000163 Rév. A, section 4.1.2.1) : ³

« Un second équipement ‘DICOM Storage Server’ sur le système d'échographie doit être utilisé afin d'ajouter l'AE Title émetteur du serveur pour l'association C-Store initiée par la requête C-Move transmise au serveur Query Retrieve. Sans ce second équipement, l'interrogation réussira, mais la récupération échouera car le système d'échographie rejettera toute demande d'association provenant d'un AE Title ‘inconnu’. »— Philips EPIQ/Affiniti Release 6.0.x DICOM Conformance Statement, 000737000000163 Rév. A, section 4.1.2.1 (orthographe conforme à la source)

La section de configuration de ce même document ajoute deux précisions importantes lors de la maintenance. Premièrement, l'archive « utilisera généralement un AE Title différent » pour le C-STORE de celui que l'échographe interroge ; l'échographe nécessite donc une entrée Storage Device supplémentaire comportant cet AE Title émetteur et l'adresse IP ou le nom d'hôte de l'archive. Deuxièmement, comme l'archive n'émet depuis aucun port fixe, Philips indique qu'un port fictif tel que 9999 peut être saisi, et la vérification automatique après l'enregistrement de cette entrée est censée échouer ; « Ce n'est pas une erreur. » Pour les envois non sollicités, le document exige également que l'AE Title et l'adresse IP de l'émetteur soient configurés à l'avance. ³

Sur cette gamme, l'échographe accepte jusqu'à cinq associations de stockage simultanées (Tableau 4.4), une valeur que le tableau de configuration indique comme non configurable. Si une archive ouvre vers une destination davantage d'associations de transmission en parallèle que ce que la destination accepte, les associations supplémentaires peuvent être refusées ; comparez donc le paramètre de simultanéité par destination de l'archive avec la limite documentée de la destination. Ne présumez pas que cette limite s'applique à d'autres modèles ou versions. ³

Sur cette même gamme, Query/Retrieve est une option : la note de bas de page de la présentation générale indique qu'elle « Nécessite l'option “Ultrasound Query Retrieve” ou “Multi-Modality Query Retrieve” ». Confirmez que l'option est présente sur le système exact avant de procéder au dépannage du réseau, en particulier après une réinstallation logicielle ou sur un système d'occasion dont les options peuvent différer de la commande d'origine. ³

Décodage du rejet d'association : télémétrie PDU et codes de diagnostic

Lorsque l'association 2 est rejetée, une capture ou un journal d'archivage montre comment. La section 9.3.4 de DICOM PS3.8 définit le PDU A-ASSOCIATE-RJ, qui comporte les champs d'un octet Result, Source et Reason/Diag. ¹¹

Comprendre ces codes de diagnostic permet d'éviter des remplacements matériels inutiles en distinguant les rejets liés aux règles de sécurité des pannes de transport réseau :

• Result : 1 correspond à rejected-permanent ; 2 correspond à rejected-transient. ¹¹
• Source : 1 est l'utilisateur de service DICOM UL (l'application réceptrice) ; 2 est le fournisseur de service UL (fonction liée à l'ACSE) ; 3 est le fournisseur de service UL (fonction liée à la présentation).
• Reason/Diag. : avec la Source 1, 1 correspond à no-reason-given, 2 à application-context-name-not-supported, 3 à calling-AE-title-not-recognized et 7 à called-AE-title-not-recognized. Avec la Source 3, 1 correspond à temporary-congestion et 2 à local-limit-exceeded. ¹¹

Un rejet avec la Source 1 et la Reason 3 (calling-AE-title-not-recognized) constitue une preuve solide que la liaison TCP fonctionne et que l'application de destination a refusé le calling AE Title de l'archive. Le fait qu'un échographe donné renvoie ce code de motif exact ou un code moins précis dépend de son implémentation ; lisez donc le code dans la capture ou le journal. Dans tous les cas, remplacer les cartes réseau ou les câbles ne résoudra pas le problème.

Autres plateformes d'échographie : consulter la déclaration de conformité de cette version

Les détails ci-dessus concernant Philips sont spécifiques à une famille de versions documentée. Les autres fabricants et versions configurent le Query/Retrieve, les appelants acceptés et les ports d'écoute à leur propre manière, et ce guide ne généralise pas les menus ou messages d'erreur d'un système à un autre. Pour tout autre échographe, procurez-vous la déclaration de conformité DICOM correspondant exactement au modèle et à la version logicielle, puis vérifiez les points suivants :

• Statut de l'option : si Query/Retrieve est inclus en standard ou s'il s'agit d'une option sous licence.
• Identité de la destination : quel AE Title l'échographe désigne comme Move Destination et s'il peut différer de l'AE Title qu'il utilise pour le stockage.
• Appelants acceptés : si les émetteurs de stockage doivent être préalablement enregistrés par AE Title, par adresse IP ou par les deux.
• Port d'écoute et sécurité : le port par défaut et configurable, et si un mode TLS (DICOM sécurisé) le modifie.
• Limites d'association : combien d'associations de stockage simultanées l'échographe accepte.
• Objets acceptés : les classes SOP et les syntaxes de transfert que l'échographe accepte en tant que Storage SCP.

Si la déclaration de conformité ne répond pas à un point précis, notez-le comme inconnu et adressez-vous au service d'assistance du fabricant. Ne comblez pas cette lacune avec des hypothèses provenant d'une autre marque.

Quand la requête elle-même est-elle erronée (erreurs A900 et erreurs de niveau) ?

Les échecs de C-MOVE ne sont pas tous causés par des problèmes de connectivité ou de routage. Lorsque l'archive renvoie le statut A900, l'anomalie réside dans la structure même de la requête C-MOVE. La norme DICOM PS3.4, section C.4.2, tableau C.4-2, définit le statut A900 comme « Erreur : le jeu de données ne correspond pas à la classe SOP ». La déclaration de conformité Canon HCBA-01 (tableau 4.2-30) le qualifie de « L'identifiant ne correspond pas à la classe SOP ». ^{1 4}

Une requête C-MOVE transporte un jeu de données Identifier qui spécifie le modèle d'information de recherche et les instances cibles. Le statut A900 survient lorsque cet identifiant enfreint les règles normatives de la classe de service Query/Retrieve :

• QueryRetrieveLevel (0008,0052) manquant : L'identifiant de la requête doit préciser le niveau hiérarchique de récupération : PATIENT, STUDY, SERIES ou IMAGE. Si cet attribut est omis ou contient une chaîne non prise en charge, l'archive rejette la commande. ¹
• Clés uniques obligatoires manquantes : dans le modèle Study Root, une récupération au niveau STUDY nécessite le Study Instance UID (0020,000D) ; une récupération au niveau SERIES nécessite également le Series Instance UID (0020,000E), et une récupération au niveau IMAGE nécessite également le SOP Instance UID (0008,0018). ¹
• Discordance de modèle d'information : l'identifiant ne correspond pas au modèle d'information négocié pour le C-MOVE, par exemple des clés créées pour Study Root envoyées dans un contexte Patient Root.
• Ambiguïté sur le Patient ID : La norme PS3.4 note que l'émetteur du Patient ID est implicite dans une requête C-MOVE, avec « aucune disposition pour envoyer l'Issuer of Patient ID », et qu'« une récupération au niveau STUDY doit être utilisée à la place d'une récupération au niveau PATIENT » lorsque le Patient ID peut être ambigu. Pour les problèmes d'identité multisites, voir lorsque le même Patient ID existe sous deux émetteurs. ¹

Ne confondez pas Modality Worklist et Query/Retrieve. La Worklist utilise C-FIND auprès d'une source de planification pour récupérer les demandes d'examen du jour ; Query/Retrieve recherche des examens terminés dans une archive d'images. Un échographe peut recevoir sa worklist correctement tout en échouant à chaque récupération, car les deux services s'exécutent souvent sur des hôtes différents avec des AE Titles distincts. Séparez l'état de la worklist du query/retrieve de l'archive pendant l'investigation.

Pourquoi certaines images sont-elles arrivées et d'autres ont-elles échoué (avertissement B000 et décomptes) ?

Un statut d'avertissement B000 (Sous-opérations terminées – un ou plusieurs échecs) signifie que certaines sous-opérations ont réussi et que d'autres ont échoué. En pratique, l'échographiste ouvre l'examen récupéré et constate que les images fixes sont présentes, mais que certaines boucles ciné, certains volumes ou certains comptes rendus manquent. ¹

B000 constitue une bonne preuve que les deux associations peuvent être établies : l'archive a atteint la destination et au moins certaines requêtes C-STORE ont réussi. L'échec concerne des instances ou des classes SOP particulières, ou des ressources au niveau de la destination.

Les principales causes des échecs partiels de récupération comprennent :

• Discordance de syntaxe de transfert : l'archive conserve un clip dans un encodage que la destination n'accepte pas (par exemple MPEG-4 AVC/H.264 ou JPEG-LS), et elle ne peut pas ou ne le convertit pas. Les archives diffèrent : la déclaration Canon HCBA-01, par exemple, décrit une liste configurable de syntaxes de transfert par AE Title de destination et des tentatives de transcodage lorsque la destination ne prend pas en charge la syntaxe stockée. ⁴
• Objets non imagés refusés : les examens peuvent inclure des rapports structurés (Structured Reports), des PDF encapsulés ou des états de présentation. Un récepteur qui n'accepte que les classes SOP d'images échographiques refuse le reste. L'acceptation n'équivaut pas à l'affichage : la déclaration Philips Release 6.0.x indique que le système accepte et peut importer des objets SR avec un examen, mais n'affiche pas les SR importés. ³ Pour vérifier les objets de type rapport, rapprochez les instances effectivement reçues de l'acquisition d'origine.
• Espace de stockage de destination : si la console vient à manquer d'espace local lors d'une récupération volumineuse, son récepteur peut refuser les instances ultérieures. Avant de libérer de l'espace, vérifiez les instances conservées avant de vous fier aux copies locales ou de les supprimer.

Pour B000, commencez par la Failed SOP Instance UID List (0008,0058). La mise en correspondance de ces UID avec les enregistrements de l'archive permet d'identifier les classes SOP et les syntaxes de transfert en échec, afin de cibler la correction.

Procédure de diagnostic étape par étape pour les ingénieurs biomédicaux

Pour éviter des modifications non coordonnées entre le génie biomédical, le PACS et le service informatique, suivez la même séquence à chaque échec de récupération. Chaque étape indique qui la réalise habituellement :

1. Étape 1 — Relever le statut et les compteurs : obtenez le statut C-MOVE final (par exemple A801, A702, A900 ou B000) ainsi que les éventuels compteurs signalés dans le journal DICOM de l'archive (administrateur PACS) ou dans le journal de maintenance de l'échographe lorsqu'il les affiche. Comparez ce profil au tableau 2.
2. Étape 2 — Relever l'identité DICOM de l'échographe : son AE Title émetteur, l'AE Title qu'il désigne comme Move Destination, son port d'écoute et son adresse IP actuelle (maintenance de l'échographe).
3. Étape 3 — Vérifier l'enregistrement de destination de l'archive : avec l'administrateur PACS, confirmez qu'une entrée de nœud existe pour cet AE Title de destination avec l'adresse IP et le port actuels de l'échographe, en comparant exactement les chaînes de caractères.
4. Étape 4 — Tester l'accessibilité côté archive : l'équipe réseau ou PACS teste si l'archive peut joindre le port d'écoute de l'échographe, à l'aide de ses outils approuvés. Notez qu'un ping ICMP peut être bloqué par une politique de sécurité même lorsque le port DICOM est ouvert ; un échec du ping ne prouve donc pas grand-chose à lui seul.
5. Étape 5 — Vérifier les appelants acceptés sur l'échographe : sur les systèmes qui pré-enregistrent les émetteurs de stockage, comme la gamme Philips documentée, confirmez que l'AE Title émetteur et l'adresse IP de l'archive sont renseignés (maintenance de l'échographe).
6. Étape 6 — Confirmer l'option : vérifiez que l'option Query/Retrieve requise par le fabricant, le cas échéant, est présente sur le système (maintenance de l'échographe).
7. Étape 7 — Rapprocher les objets et les encodages : pour les transferts partiels, vérifiez si les objets en échec partagent une classe SOP ou une syntaxe de transfert que la destination n'accepte pas (administrateur PACS et maintenance de l'échographe).

Topologies réseau complexes : NAT, VLAN et chariots sans fil sous DHCP

Dans les réseaux d'entreprise hospitaliers modernes, les systèmes d'échographie fonctionnent de plus en plus sur des infrastructures dynamiques ou segmentées, introduisant des complexités de routage qui n'affectent pas les modalités d'imagerie fixes comme la TDM ou l'IRM :

1. Traduction d'adresses réseau (NAT) : si l'échographe se trouve derrière un NAT, par exemple sur un réseau sans fil segmenté, l'archive voit l'adresse de la passerelle, tandis que son enregistrement de nœud pour l'AE Title de destination peut pointer vers une adresse qu'elle ne peut pas joindre directement. Les connexions entrantes non sollicitées vers cette adresse sont rejetées, à moins que le réseau ne soit conçu pour elles. La base de connaissances de Medical Connections décrit les routeurs, le NAT et les pare-feu logiciels comme des facteurs de blocage fréquents de la connexion C-MOVE inverse ; ses solutions de contournement orientées postes de travail, consistant à désactiver les pare-feu ou à ouvrir des ports de routeur, ne sont pas appropriées sur un réseau hospitalier. ⁶

2. Modification des adresses IP : les échographes portables qui se déplacent d'un service à l'autre peuvent recevoir de nouvelles adresses par DHCP. Si l'enregistrement de nœud de l'archive contient une adresse fixe pour l'AE Title de l'échographe, tout changement envoie l'association 2 à l'ancienne adresse et celle-ci expire par dépassement de délai. Les échographes ayant besoin de la récupération nécessitent généralement une adresse stable, telle qu'une attribution statique ou une réservation DHCP, décidée par l'équipe réseau.

3. Inspection avec état et routage asymétrique : Les pare-feu d'entreprise mettent souvent en œuvre une inspection avec état qui autorise automatiquement les paquets de retour entrants pour les connexions initiées depuis une zone protégée. Alors que l'association 1 (de l'échographe vers le PACS) est reconnue comme un flux avec état actif, l'association 2 est une toute nouvelle connexion TCP initiée par le serveur PACS en sens inverse. À moins que l'administrateur du pare-feu ne crée une stratégie bidirectionnelle explicite ou une règle entrante autorisant le trafic depuis le serveur PACS vers le port d'écoute de l'échographe, le pare-feu abandonnera l'association 2 comme un sondage entrant non autorisé.

Négociation des contextes de présentation et discordances de syntaxe

Lorsque l'association 2 établit un socket TCP, l'archive PACS (agissant en tant que SCU de stockage) propose une liste de contextes de présentation au chariot d'échographie (agissant en tant que SCP de stockage). Chaque contexte proposé associe une syntaxe abstraite (l'UID de la classe SOP) à une ou plusieurs syntaxes de transfert (le format de codage et le codec de compression). L'échographe évalue chaque proposition et renvoie un code d'acceptation ou de rejet dans sa réponse A-ASSOCIATE-AC.

Les systèmes d'échographie gèrent une combinaison unique de boucles ciné à cadence d'images élevée, de cartographies de flux couleur multizones et de mesures structurées complexes. Le tableau ci-dessous détaille les conflits de contextes de présentation les plus fréquents rencontrés lors des sous-opérations C-STORE :

Diagnostics au niveau des paquets et capture de trafic non intrusive

N'installez pas d'outils de capture de paquets, de scanners de ports ni d'autres logiciels sur la console d'échographie. Il s'agit d'un dispositif médical soumis au contrôle logiciel du fabricant et à la gestion des changements de l'établissement, et tout logiciel non approuvé peut altérer sa configuration validée et sa sécurité.

Lorsqu'une capture est justifiée, l'équipe réseau peut la réaliser depuis l'infrastructure, par exemple à l'aide d'une mise en miroir de port de commutateur (SPAN) ou d'un TAP réseau passif, et l'analyser sur une station de travail autorisée distincte. Les captures de trafic DICOM non chiffré contiennent des données patient ; elles doivent donc être autorisées, minimisées, conservées et supprimées conformément à la politique de confidentialité et de sécurité de l'établissement. Si le protocole DICOM sécurisé (TLS) est utilisé, la capture montre la connexion TCP mais pas les messages DICOM qu'elle contient ; utilisez plutôt les journaux de l'archive et de l'échographe.

Dans Wireshark, un filtre d'affichage tel que dicom || tcp.port == <port d'écoute>, utilisant les ports configurés du site, permet d'isoler le trafic pertinent. Vérifiez ensuite les deux associations dans l'ordre :

• Vérification de l'association 1 : Repérez la triple poignée de main TCP (SYN, SYN-ACK, ACK) émise depuis le port éphémère de la console d'échographie vers le port d'écoute du PACS. Immédiatement après cette poignée de main, vérifiez la PDU A-ASSOCIATE-RQ (type 01H) contenant les contextes de présentation proposés pour Study Root Query/Retrieve Information Model - FIND et MOVE. Confirmez que le serveur PACS renvoie une PDU A-ASSOCIATE-AC (type 02H) acceptant les deux contextes.
• Envoi de la requête C-MOVE : Suivez la PDU P-DATA-TF contenant la commande C-MOVE-RQ. Vérifiez le Message ID, le QueryRetrieveLevel (par ex. STUDY), la clé de correspondance StudyInstanceUID et l'attribut Move Destination AE Title (0000,0600). Confirmez que la chaîne de destination correspond exactement à l'AE Title d'écoute attendu de l'échographe.
• Initialisation et poignée de main de l'association 2 : Surveillez l'arrivée d'un nouveau paquet TCP SYN indépendant, provenant de l'adresse IP du serveur PACS et ciblant l'IP statique ainsi que le port d'écoute du chariot d'échographie. Il s'agit du point charnière critique du diagnostic. Le comportement de ce paquet identifie immédiatement la cause racine.

Concurrence, gestion des files d'attente et délais d'attente des sockets

Dans les services d'imagerie clinique à haut débit, les échecs de récupération se manifestent souvent de manière intermittente en situation de forte charge de travail. Un échographe sur chariot qui récupère sans difficulté un examen thyroïdien de cinq images peut échouer systématiquement lorsqu'il tente d'importer un examen échocardiographique complexe de 600 images ou un examen vasculaire périphérique complet. Ces échecs dépendants du volume sont causés par les limites des files d'attente réseau et la configuration des délais d'attente des sockets.

1. Régulation du débit de l'archive et délais d'attente du client : les archives limitent souvent les transferts sortants simultanés. Si plusieurs utilisateurs demandent simultanément des examens volumineux, les sous-opérations peuvent être mises en file d'attente. Si l'échographe demandeur applique son propre délai d'attente à l'ensemble de la récupération, il peut abandonner et signaler un échec alors que l'archive est toujours en cours d'envoi. Comparez la chronologie du journal de l'archive avec l'heure à laquelle l'échographe a signalé l'erreur.

2. Écritures lentes au niveau de la destination : une destination qui ne peut pas écrire les données aussi vite qu'elles arrivent ralentit le transfert. Si un blocage dépasse le délai d'attente de message ou de réseau de l'archive, l'archive interrompt l'association 2. L'exemple informatif de la PS3.2 décrit exactement cela : un A-ABORT sur un délai d'attente au niveau message ou de bas niveau, avec un statut d'échec approprié renvoyé dans la réponse C-MOVE. ²

3. Tentatives répétées : chaque appui sur Retrieve envoie une nouvelle requête C-MOVE, ce qui peut mettre en file d'attente des transferts en double et noyer le premier échec dans les journaux. Relevez le statut du premier échec, puis réessayez une seule fois de manière contrôlée après avoir traité la cause.

Validation post-récupération : indexation dans la base de données locale et prévention du fractionnement d'examens

Un statut final 0000 (Success) signifie que chaque sous-opération C-STORE a été transmise et acquittée. Cela ne garantit pas que l'examen se trouve là où l'échographiste s'attend à le trouver sur l'échographe.

Les systèmes d'échographie diffèrent dans leur façon de classer et de répertorier les examens reçus, et la déclaration de conformité ou le manuel d'utilisation de la version exacte fait foi. Les objets reçus sont généralement regroupés selon leurs attributs d'identification, tels que le Patient ID (0010,0020), le Study Instance UID (0020,000D) et l'Accession Number (0008,0050), de sorte que des différences dans ces valeurs modifient l'emplacement où un examen apparaît.

Si les images récupérées n'apparaissent pas sur l'écran de la console malgré la confirmation du statut 0000, les ingénieurs doivent examiner trois anomalies courantes d'ingestion en base de données :

• Examen en cours : certains systèmes peuvent ne pas actualiser leur liste d'examens lorsqu'un examen est en cours. Consultez l'écran de révision ou des examens reçus décrit dans le manuel d'utilisation.
• Classé sous un autre dossier patient : si l'examen archivé porte un Patient ID ou un numéro d'accession différent de la demande du jour, l'échographe peut le répertorier sous une entrée patient distincte. Effectuez une recherche par Study Instance UID ou par date avant de conclure à l'échec de la récupération.
• Échec du stockage local ou de l'indexation : si le stockage local est presque plein ou si le processus d'importation a échoué, le journal de maintenance de l'échographe l'indique généralement. Ne libérez de l'espace qu'en suivant la procédure approuvée par le fabricant et la politique de conservation de l'établissement.

À qui incombe chaque résolution : maintenance de l'échographe, administrateur PACS ou équipe réseau ?

Les équipes de service de génie biomédical jouent un rôle de triage crucial dans le cycle de vie de la gestion des technologies de santé. Lorsque les échographistes cliniciens signalent des échecs de récupération, les techniciens biomédicaux sont souvent les premiers intervenants dans les services hospitaliers. Plutôt que de faire remonter immédiatement le problème à des centres d'assistance informatique externes ou de soumettre une autorisation de retour pour panne matérielle, les ingénieurs biomédicaux devraient établir un état de référence formel de connectivité DICOM lors de la mise en service initiale de l'appareil. Cet état de référence doit documenter l'adresse IP statique vérifiée, le masque de sous-réseau, la passerelle par défaut, l'adresse MAC physique, l'AE Title du Storage SCP local, le port d'écoute et la version logicielle (build) du chariot d'échographie, ainsi que la date et le numéro de ticket de modification de toute modification réseau. La conservation de cet enregistrement de référence de connectivité au sein du système de gestion de la maintenance assistée par ordinateur (GMAO / CMMS) de l'hôpital garantit que les futures réévaluations d'adresses IP, reconfigurations de ports de commutateur ou mises à jour logicielles pourront être instantanément comparées à un état de fonctionnement connu, réduisant considérablement le délai de diagnostic et évitant des interventions de maintenance inutiles.

Puisqu'une récupération DICOM franchit les frontières institutionnelles — englobant le micrologiciel du dispositif médical, les commutateurs réseau de l'hôpital, les pare-feux et les bases de données PACS de l'établissement —, le diagnostic de panne dégénère fréquemment en un renvoi de responsabilités entre services. Les ingénieurs biomédicaux reprochent au service informatique de l'hôpital de bloquer des ports, l'informatique reproche au fournisseur du PACS des bogues logiciels, et les administrateurs du PACS imputent le problème à un matériel défectueux sur le chariot d'échographie.

Pour éliminer les temps d'arrêt inutiles, les équipes techniques hospitalières doivent faire respecter des limites de responsabilité claires fondées sur des preuves protocolaires objectives. Chaque couche de la chaîne de récupération relève d'une discipline professionnelle spécifique :

Que convient-il de consigner avant que quiconque ne modifie un paramètre ?

Enregistrez chaque modification : ce qui a été modifié, par qui, sous quel ordre d'intervention, et le résultat des tests avant et après modification. Si une récupération ultérieure échoue, ce journal indique si la cause est un changement d'infrastructure récent ou une nouvelle défaillance de l'équipement. Lorsque le fabricant fournit une fonction d'exportation de configuration prise en charge, effectuez-en une avant de modifier les paramètres de l'échographe, et conservez-la conformément à la politique de l'établissement afin que la modification puisse être annulée.

Lorsqu'un échographe ne parvient pas à récupérer des examens, le personnel de maintenance doit résister à la tentation de modifier au hasard les paramètres de configuration, de basculer les réglages du pare-feu ou de commander des cartes d'E/S réseau de rechange. Un dépannage non coordonné par essais et erreurs engendre de graves risques pour la sécurité et introduit fréquemment des pannes secondaires qui compliquent la remise en état.

Les erreurs de routage constituent également un risque pour la confidentialité des données. Si quelqu'un tente de corriger un A801 en devinant des AE Titles de destination, ou en faisant pointer la Move Destination vers un autre nœud connu sans confirmer de quoi il s'agit, l'archive enverra les examens de patients à cet appareil. Dans de nombreuses juridictions, cela peut constituer un incident de confidentialité devant faire l'objet d'un signalement ; le responsable de la protection des données de l'établissement décide de la manière dont il doit être traité.

Avant de modifier un fichier de configuration, d'ouvrir un ticket d'assistance ou de demander des composants de rechange, les ingénieurs biomédicaux doivent constituer un dossier de preuves structuré et anonymisé pour la prise en charge technique :

Outils de simulation contrôlée : vérification synthétique sans risquer les données des patients

Lorsqu'une récupération d'échographie échoue de manière intermittente ou que les équipes réseau contestent l'ouverture effective d'un port de pare-feu, les ingénieurs biomédicaux ont besoin d'une méthode objective et reproductible pour isoler le point d'extrémité défaillant sans envoyer de manière répétée de véritables examens de patients à travers les sous-réseaux cliniques. Dans les environnements hospitaliers réglementés, déclencher de façon répétée des transferts infructueux d'examens cliniques réels génère du bruit d'audit et accroît le risque de divulgation accidentelle d'informations de santé protégées.

Pour établir la réalité du terrain, les équipes de génie biomédical peuvent déployer des suites de vérification DICOM standardisées (telles que les utilitaires de la boîte à outils DCMTK ou les outils de test DVTk) exécutées sur un poste de travail de test dédié et autorisé par le service informatique au sein du même sous-réseau clinique :

• Tester le chemin inverse avec un service d'écoute de test : exécutez un service d'écoute de stockage DICOM temporaire sur le poste de travail de test autorisé, sur un port convenu avec l'équipe réseau, et demandez à l'administrateur PACS d'enregistrer son AE Title comme destination. Si un C-MOVE d'un examen de test désigné atteint le service d'écoute, l'archive peut atteindre ce segment réseau, et l'attention se porte alors sur la configuration propre à l'échographe.
• Vérifier le service d'écoute de stockage de l'échographe depuis le réseau : À l'inverse, un ingénieur peut envoyer un examen de test échographique synthétique et anonymisé depuis l'ordinateur portable de test directement vers l'adresse IP et le port d'écoute du chariot d'échographie en utilisant C-STORE. Si l'échographe accepte l'association et ingère l'image de test, le service Storage SCP local du chariot, le pare-feu du système d'exploitation local et la base de données interne sont avérés pleinement opérationnels. Si le chariot rejette l'association avec A-ASSOCIATE-RJ, la configuration du Calling AE Title accepté par l'échographe est immédiatement confirmée comme étant la cause racine.
• Limite de sécurité et de conformité : Les utilitaires de test ne doivent jamais être connectés aux VLAN cliniques sans l'autorisation formelle de la sécurité des systèmes d'information de l'hôpital. De plus, les images de test doivent consister entièrement en des acquisitions sur fantôme ou en des objets DICOM générés synthétiquement ne contenant aucune donnée démographique de patient ni information de santé protégée.

Tests de recette post-intervention et validation clinique

Après tout remplacement de carte, rechargement logiciel, modification de réseau ou changement de configuration, retestez les fonctions DICOM avant de remettre l'échographe en service clinique. Les contrôles de maintenance s'arrêtent souvent à l'envoi d'une seule image au PACS, laissant la récupération non testée jusqu'à ce qu'un échographiste ait besoin d'un examen antérieur.

Utilisez la procédure pour patient de test désignée de l'établissement, afin qu'aucun dossier patient réel ne soit créé ou modifié, et vérifiez chaque fonction configurée :

• 1. Vérification (C-ECHO) : Effectuez un test ping/écho depuis la console d'échographie vers tous les nœuds DICOM configurés (archive PACS, serveur de liste de travail, serveur de Storage Commitment et imprimantes DICOM). Confirmez la réception d'un accusé de réception positif.
• 2. Liste de travail de modalité (C-FIND) : Interrogez les demandes d'examens de patients programmés aujourd'hui. Sélectionnez un patient programmé, renseignez les données démographiques du patient sur l'écran d'acquisition, et confirmez que les numéros d'accession, les descriptions d'examen et les noms des médecins réalisateurs correspondent correctement.
• 3. Acquisition et stockage (C-STORE) : Acquérez une boucle Doppler couleur multi-images et des images statiques en 2D à l'aide d'un fantôme simulant les tissus. Envoyez l'examen complet au PACS. Confirmez que toutes les instances sont transférées sans erreur et que l'archive accuse réception du stockage.
• 4. Interrogation et récupération (C-FIND, C-MOVE) : interrogez l'examen de test venant d'être stocké, récupérez-le sur l'échographe, et confirmez que les images et les boucles ciné s'ouvrent et qu'aucun état d'avertissement tel que B000 n'est consigné dans les journaux. Vérifiez les rapports de mesure uniquement lorsque le système est documenté pour les importer et les afficher.

Ne validez l'intervention de maintenance que lorsque chaque fonction configurée fonctionne avec succès, afin que les échographistes puissent s'appuyer sur les examens antérieurs lors des examens.

Foire aux questions

La réussite d'un C-ECHO ou d'une requête prouve-t-elle que la récupération devrait également fonctionner ?

Non. Une vérification DICOM (C-ECHO) ou une interrogation (C-FIND) teste uniquement le chemin réseau aller initié par l'échographe vers le port d'écoute de l'archive PACS (Association 1). Une récupération C-MOVE exige que l'archive PACS initialise une connexion réseau inverse distincte vers le port d'écoute de l'échographe (Association 2). Comme les pare-feu, les tables de routage réseau et les politiques de sécurité locales de l'échographe traitent fréquemment les connexions entrantes différemment des connexions sortantes, la réussite d'un C-ECHO ou d'un C-FIND ne fournit aucune garantie que l'Association 2 réussira. ^{1 5}

La destination du déplacement est-elle toujours la machine qui a envoyé la requête ?

Pas nécessairement. Dans la norme DICOM PS3.4, section C.4.2, l'attribut Move Destination spécifie l'Application Entity Title du système qui recevra les sous-opérations C-STORE. Bien que les échographistes récupèrent généralement les examens vers le chariot qu'ils utilisent, le protocole C-MOVE autorise explicitement un demandeur à désigner tout nœud de stockage DICOM tiers comme destination — comme une station de travail dédiée, un serveur de visualisation 3D ou une station de relecture hors ligne. L'archive résout toujours l'AE Title de Move Destination de manière indépendante, quel que soit le client qui a initié la requête. ¹

Le déplacement signale un succès mais aucun examen n'est apparu — que vérifier en premier ?

Si la réponse C-MOVE indique le statut 0000 (Succès) et que le nombre de sous-opérations terminées correspond au nombre d'images attendu, le transfert réseau a totalement réussi. Si les images n'apparaissent pas sur l'écran de l'échographe, vérifiez deux facteurs immédiats : premièrement, vérifiez l'index de la base de données patients interne de l'échographe — certains systèmes stockent les examens récupérés dans une archive locale ou un répertoire patient qui doit être actualisé manuellement ou ouvert depuis un onglet « Examens importés ». Deuxièmement, vérifiez si l'AE Title de Move Destination dans la requête n'a pas été configuré par inadvertance sur une machine physique différente (comme un autre échographe ou une station de relecture), auquel cas les images ont été transmises avec succès à cet autre appareil. ^{1 6}

Peut-on simplement ouvrir le pare-feu ou rediriger un port pour faire fonctionner la récupération ?

Non. Dans les environnements hospitaliers cliniques, les échographes sont des dispositifs médicaux mobiles traitant des informations de santé protégées (PHI). Ouvrir des règles de pare-feu sans discernement, désactiver le logiciel de sécurité de l'hôte ou configurer une redirection de port non gérée enfreint les normes de cybersécurité du secteur de la santé et les politiques de sécurité institutionnelles. Les modifications du réseau doivent être formellement coordonnées avec les équipes informatiques et de sécurité réseau de l'hôpital, en restreignant le trafic à des IP sources spécifiques (le serveur PACS), des IP cibles (le chariot échographique) et aux ports d'écoute DICOM désignés, sans exposer les sous-réseaux cliniques à un trafic non autorisé.

Le C-GET ou DICOMweb permettrait-il d'éviter ce problème de connexion inverse ?

En principe, oui. Avec le C-GET (PS3.4, section C.4.3), les sous-opérations C-STORE s'exécutent sur la même association que la requête, et le récepteur est toujours le demandeur. La récupération DICOMweb est de même initiée par le client via HTTP. Aucun des deux ne nécessite que l'archive ouvre une connexion retour vers l'échographe. ¹⁰ Mais les deux extrémités doivent prendre en charge cette alternative. La base de connaissances de Medical Connections, rédigée il y a quelques années, faisait observer que très peu de serveurs DICOM commerciaux prenaient en charge le C-GET. ⁶ Vérifiez les deux déclarations de conformité. Changer de protocole est une question de planification pour le propriétaire du PACS, et non une solution à un échec de C-MOVE aujourd'hui.

Un échec de récupération signifie-t-il que la carte réseau de l'échographe est défectueuse ?

Peu probable, si l'échographe peut interroger, vérifier ou envoyer des examens vers le PACS via la même interface. Le matériel réseau transporte les paquets sans distinction selon qu'ils contiennent une requête C-FIND ou une image C-STORE. Si l'interface était défaillante, le trafic sortant serait normalement perturbé lui aussi. Le DICOM sortant fonctionnant, un échec limité à la seule récupération est bien plus susceptible de relever d'un problème d'AE Title, d'appelant autorisé, de routage ou de pare-feu. Des pertes intermittentes de liaison ou une interface inactive constituent des symptômes différents, traités dans le guide sur la carte d'E/S réseau accessible via le lien ci-dessus.

Que faire si des examens de patients ont été envoyés vers la mauvaise destination ?

Traitez la situation comme un incident potentiel de confidentialité. Interrompez les tests, consignez l'heure, le Study Instance UID et l'AE Title de destination utilisé, puis informez l'administrateur PACS ainsi que le responsable de la confidentialité de l'établissement. Ils décident de la manière dont le dispositif récepteur est vérifié et dont les copies mal acheminées sont supprimées.

Où intervient Rongtao — et où n'intervient-il pas ?

Rongtao Medical est une entreprise indépendante de réparation d'échographes et de pièces de rechange basée à Guangzhou, en Chine, au service des distributeurs, des prestataires de maintenance et des équipes de génie biomédical hospitalières. Définir clairement les domaines dans lesquels nous pouvons intervenir permet à chacun de gagner du temps.

Où intervient Rongtao :

• Isolement des pannes matérielles : lorsque le problème est réellement d'origine matérielle, par exemple l'absence de liaison Ethernet, une perte de liaison intermittente ou la défaillance d'une carte d'E/S ou de la carte principale, Rongtao assure le diagnostic et la réparation au niveau de la carte. Chaque carte réparée fonctionne pendant 48 heures au sein d'un système d'échographie réel avant sa mise à disposition. ⁷
• Cartes et pièces de rechange : réparation de cartes et pièces pour les systèmes OEM pris en charge. Le stock évoluant, veuillez confirmer une référence spécifique via le catalogue en direct ou un devis. ⁸
• Réparation de sondes : diagnostic de panne et réparation de sondes linéaires, convexes, phased-array, endocavitaires, ETO et volumiques, avec une garantie habituelle de 90 jours confirmée par article et par prestation. ⁸
• Conseils lors de la prise en charge : une aide pour déterminer si un symptôme relève du matériel ou d'une configuration externe, afin que vous puissiez préparer les éléments techniques de maintenance côté échographe avant de commander des pièces.

Où Rongtao n'intervient pas :

• Administration du réseau hospitalier et des pare-feu : Rongtao ne configure pas les commutateurs réseau des services hospitaliers, n'administre pas les pare-feu d'entreprise, ne modifie pas les listes de contrôle d'accès des VLAN et ne gère pas les domaines Active Directory de l'hôpital.
• Administration des nœuds d'archivage PACS : Nous ne gérons pas, ne concédons pas de licences pour, et ne configurons pas les archives PACS hospitalières, les archives neutres (VNA, Vendor Neutral Archives) ou les systèmes d'information radiologique. Les modifications apportées aux tables de destination PACS et aux correspondances d'AE Title côté serveur restent sous la responsabilité exclusive de l'administration PACS de l'hôpital.
• Représentation agréée OEM : Rongtao Medical est un prestataire de services indépendant et n'est pas un agent, distributeur ou représentant agréé de GE HealthCare, Philips, Siemens Healthineers, Canon Medical Systems, Mindray ou Samsung Medison.

Lors d'une demande de support technique matériel ou de pièces de rechange pour des défauts de communication persistants, veuillez transmettre les données DICOM anonymisées et les caractéristiques du modèle à notre équipe technique : marque OEM, famille exacte du modèle, version logicielle, références des pièces matérielles et un récapitulatif anonymisé des symptômes d'erreur. N'envoyez jamais de données de santé de patients, d'images de patients ou d'identifiants cliniques via les canaux de devis technique.