Un examen d'échographie apparaît le mauvais jour : comparez l'heure locale et le décalage UTC

Quelle date l'écran représente-t-il réellement ?

Considérez un ticket d'intervention fictif : un examen d'échographie apparaît le 23 octobre sur l'échographe mais le 22 octobre dans le système d'archivage et de transmission d'images (PACS). Le demandeur suspecte l'horloge de l'échographe. Une capture d'écran de chaque système constate une divergence, mais ne localise pas encore sa cause.

Pour une équipe hospitalière de génie biomédical ou un prestataire de maintenance indépendant, la première décision consiste à déterminer qui doit mener l'investigation. Établissez quel événement et quelle représentation chaque écran affiche avant de traiter la différence calendaire comme un symptôme matériel. L'horloge actuelle de l'échographe, l'heure de début d'un examen et l'heure de réception par une archive répondent à des questions différentes.

Commencez par les définitions d'événements. Les attributs DICOM Study Date et Study Time décrivent le début de l'examen. Acquisition DateTime décrit le début de l'acquisition de données ayant produit l'instance. Aucune de ces définitions ne fait d'un horodatage une garantie mesurée de l'exactitude de l'horloge. ^{7 8}

• Début de l'examen : Comparez (0008,0020) et (0008,0030) à l'événement de début d'examen documenté pour la version installée de l'échographe.
• Début de l'acquisition : Si (0008,002A) est présent, identifiez l'acquisition qu'il décrit. Ne lui substituez pas l'heure de gel, d'enregistrement, de fin d'examen ou d'envoi réseau.
• Création de l'instance : (0008,0012) et (0008,0013) concernent la création de l'instance SOP et l'attribution de son UID, plutôt que la réception par l'archive. ²
• Récepteur et affichage : Demandez au responsable du PACS ce que représente une date de colonne de liste, d'incrustation ou de portail. Consignez toute politique de conversion ainsi que le contexte de fuseau horaire de l'utilisateur ou du client séparément des valeurs sources.

Deux dates peuvent décrire correctement le même instant après conversion. Elles peuvent également décrire des événements différents ou refléter des données sources incorrectes. Traitez chacune d'elles comme une hypothèse jusqu'à ce que les valeurs, la signification des événements et les paramètres système viennent étayer une explication. Une différence plausible de deux heures ne suffit pas, à elle seule, à vérifier l'ensemble de l'enregistrement.

Que doit consigner le registre des preuves avant toute modification des paramètres ?

Conservez un état de référence avant de modifier les paramètres. Dans le cas contraire, une comparaison ultérieure pourrait mêler un objet exporté plus ancien à une horloge nouvellement corrigée ou à un profil d'affichage différent. Consignez qui a recueilli chaque observation, sur quel système et à quel moment. Conservez les éléments de preuve originaux comportant des données patient dans les canaux approuvés par l'établissement ; une demande d'assistance technique doit utiliser des résultats anonymisés ou un exemple synthétique.

Utilisez le registre ci-dessous pour organiser une comparaison autorisée en lecture seule. Pour chaque ligne, conservez la chaîne brute, qu'elle soit absente ou vide, l'objet dont elle provient et l'interprétation proposée. Un inspecteur de balises peut être utile, mais une vue d'en-tête affichée ne doit pas être automatiquement considérée comme une copie inchangée de l'objet initialement transmis. Si nécessaire, demandez aux responsables des systèmes de comparer les instances sources conservées et les instances reçues.

Une comparaison utile énonce un constat et sa limite : « La même instance reçue affiche Study Date 20261023 dans la vue des balises et le 22 octobre dans la liste des examens ; le fuseau horaire de la liste n'est pas encore confirmé. » C'est plus probant que de qualifier l'en-tête de corrompu. Cela indique également au responsable du PACS quel élément de preuve fait exactement défaut.

En quoi des champs de date et d'heure distincts diffèrent-ils d'une date-heure comportant un décalage ?

La représentation de valeur (VR) DICOM détermine la façon dont un champ est encodé. Les trois formes pertinentes sont Date (DA), Time (TM) et DateTime (DT). Distinguez la syntaxe d'encodage de la preuve que l'horloge était correcte. ¹

• DA : Une date calendaire telle que 20261023, sans décalage UTC intégré.
• TM : Une heure telle que 010000, sans date ni décalage intégrés.
• DT : Une valeur de date/heure pouvant inclure un décalage signé, telle que 20261023010000+0200. La précision peut varier. En l'absence de suffixe, l'interprétation locale du créateur s'applique, sauf si l'attribut de décalage distinct en dispose autrement. ¹

Study Date et Study Time nécessitent donc un contexte pour permettre la comparaison avec un affichage UTC. Conservez la paire brute ensemble, puis identifiez le décalage applicable à partir de l'objet ou d'une configuration vérifiée de la source. Ne déduisez pas de fuseau horaire à partir du nom de l'hôpital, de l'emplacement du récepteur ou de l'horloge de la station de travail au moment de l'investigation.

Dans SOP Common, Timezone Offset From UTC est optionnel (Type 3). Il fournit le contexte pour DA/TM et pour les valeurs DT dépourvues de décalage explicite. Une valeur DT dotée de son propre décalage conserve ce contexte de manière indépendante. ²

Si le décalage distinct est absent, cet attribut n'identifie pas le décalage local. L'absence ne constitue pas une déclaration d'UTC. De même, le comportement de repli du récepteur est une question d'implémentation : établissez la politique documentée et le contexte réel de la source avant de décider qu'il a interprété la valeur de manière incorrecte. ²

Un décalage est une relation numérique par rapport à l'UTC, et non le nom d'un fuseau horaire ou une politique complète de passage à l'heure d'été. Deux relevés d'horloge locale identiques peuvent décrire des instants différents si leurs décalages diffèrent. Si le contexte requis ne peut pas être récupéré, préservez cette incertitude plutôt que de reconstituer une chronologie précise à partir d'une seule chaîne de date.

Le module Timezone distinct définit le décalage comme étant de Type 1 au sein de ce module. Son niveau d'exigence doit être lu dans le contexte de la définition d'objet d'information et de l'implémentation applicables. Ni cette ligne ni la ligne optionnelle de SOP Common ne prouvent, à elles seules, qu'un objet d'échographie complet est conforme ou non conforme. ³

Une conversion correcte peut-elle faire basculer un examen d'échographie au-delà de minuit ?

Oui. Comparez un instant unique entièrement spécifié avant de diagnostiquer une anomalie. Les exemples suivants utilisent uniquement des décalages numériques fixes. Ils ne représentent pas une ville désignée, une transition réelle d'heure d'été, un événement patient ou un comportement testé sur un PACS particulier.

Dans un enregistrement de test fictif, le début de l'examen et le début de l'acquisition ont tous deux lieu le 23 octobre 2026 à 01:00 avec un décalage de +02:00. Les valeurs illustratives sont :

• Date de l'examen (0008,0020) : 20261023
• Heure de l'examen (0008,0030) : 010000
• Décalage du fuseau horaire par rapport à l'UTC (0008,0201) : +0200
• Date et heure d'acquisition (0008,002A) : 20261023010000+0200

Si un récepteur affiche cet instant en UTC, la soustraction du décalage de deux heures donne :

2026-10-23 01:00:00 (+02:00) moins 2 heures = 2026-10-22 23:00:00 (UTC)

La date calendaire devient le 22 octobre, tandis que l'instant reste inchangé. La conversion est de deux heures ; il ne s'agit pas d'une modification de 24 heures du temps écoulé. Un affichage UTC correct et un affichage local correct peuvent donc afficher des jours adjacents. Le fait qu'une application particulière effectue cette conversion doit être établi à partir de sa documentation et de sa configuration.

Le cas D nécessite un résultat différent des autres cas : laissez l'interprétation UTC non résolue. Demandez la configuration du fuseau horaire source et la politique de repli du récepteur. Un décalage deviné peut produire une conversion propre tout en étant erroné. Consignez si chaque décalage a été encodé, documenté dans la configuration ou simplement présumé.

Le début de l'examen et l'acquisition pourraient-ils simplement être des événements distincts ?

Des dates d'événements différentes peuvent également expliquer l'observation sans aucune conversion de fuseau horaire. Le début de l'examen n'est pas le début de l'acquisition, pas plus que ne l'est la réception par l'archive. La séquence fictive suivante utilise un décalage fixe de +00:00 d'un bout à l'autre. ^{7 8}

Supposons que l'implémentation de test enregistre les événements suivants. L'exemple illustre la signification des événements ; il ne prétend pas que tous les échographes attribuent des horodatages lors du même appui sur un bouton.

1. Le début de l'examen est enregistré à 23:45 le 22 octobre.
2. L'acquisition des données pour une instance ultérieure commence à 00:15 le 23 octobre.
3. Le récepteur enregistre la réception encore plus tard. Cet horodatage de réception appartient à l'événement du récepteur.

Les deux premières dates peuvent toutes deux être correctes. Vérifiez quel champ l'interface utilisateur désigne comme la date de l'examen et quel champ son filtre utilise. Ne partez pas du principe qu'une date de liste, une incrustation sur l'image et un portail de compte rendu sélectionnent tous le même événement. L'exemple du Lumify ci-dessous montre pourquoi le mappage des événements propre à chaque version est important.

Si les enregistrements suggèrent plutôt un ordre impossible d'événements cliniques, transmettez cette question aux responsables cliniques et aux responsables des dossiers. Ce registre technique ne peut pas établir ce qui est arrivé à un patient. Une équipe de maintenance doit signaler les valeurs observées et l'incertitude sans réétiqueter silencieusement l'examen pour faire concorder deux écrans.

Pourquoi une requête filtrée par date pourrait-elle omettre un enregistrement existant ?

Lorsqu'un examen est absent d'une liste filtrée par date, identifiez d'abord le chemin de recherche. Un filtre de liste de travail applicative peut être une opération de base de données locale ; une requête d'archivage peut utiliser DICOM Query/Retrieve (Q/R) ; un échographe récupérant des demandes programmées peut utiliser Modality Worklist (MWL). Qualifier ces trois opérations de « requête de liste de travail » dissimule les éléments de preuve nécessaires.

Dans le cadre d'une investigation approuvée, un examen connu trouvé grâce à une autre recherche peut démontrer qu'un filtre de date l'a exclu. Cela n'établit pas pourquoi. Conservez les bornes demandées, le champ interrogé, la réponse et tout filtrage client supplémentaire. Demandez au responsable de reproduire la sélection avec un enregistrement synthétique avant de modifier une requête en production.

Pour la correspondance sur valeur unique Q/R, PS3.4 C.2.2.2.1.3 exige un ajustement lorsque l'option Timezone Query Adjustment est négociée et que le décalage est fourni dans l'identifiant. La déclaration de conformité décrit le comportement de l'implémentation. Il n'existe pas de règle générale selon laquelle toute requête non négociée compare des chaînes littérales. ⁴

• Correspondance par plage : Une plage TM ne peut pas chevaucher minuit. Les plages DT prennent en compte les décalages encodés. Une correspondance DA/TM combinée négociée peut traiter les bornes associées comme un intervalle continu ; les règles de plage permettent également l'ajustement du décalage, indépendamment de toute autre négociation étendue. Vérifiez les clés prises en charge et l'implémentation exacte. ⁵
• Requêtes DT à décalage négatif : Un décalage négatif entre en conflit avec le trait d'union utilisé pour distinguer la correspondance par valeur unique de la correspondance par plage. Il s'agit d'une restriction syntaxique de requête, et non d'une invalidité des valeurs DT à décalage négatif dans les objets stockés. La construction des requêtes relève du responsable de l'intégration. ⁴
• Demande d'éléments de preuve : Pour une requête DICOM, conservez le service/la classe SOP, les clés prises en charge, la requête et la réponse brutes, le décalage et la négociation pertinente. Pour un filtre d'interface utilisateur, conservez sa politique de champs et de fuseaux horaires. Une capture d'écran seule ne peut pas établir l'un ou l'autre algorithme de correspondance.

La MWL comporte des conditions de décalage de requête/réponse distinctes dans K.4.1.1.3. K.6 spécifie un intervalle de début planifié continu lorsque les clés de date et d'heure planifiées utilisent toutes deux une correspondance par plage. Ne transposez pas la règle de négociation Q/R à la MWL, et ne supposez pas qu'un filtre de visualiseur implémente l'un ou l'autre de ces services. ^{6 15}

Qu'établissent exactement les documents Lumify et PACS ?

Les documents ci-dessous établissent certains comportements à différents niveaux. Ils ne constituent pas un classement de compatibilité ni une association émetteur/récepteur testée. Un nom de produit sans sa version est insuffisant : récupérez la déclaration correspondant au logiciel installé et demandez au propriétaire du système de confirmer la configuration locale.

Utilisez le comportement documenté pour formuler une question testable. Gardez les inconnues à côté des faits, en particulier lors de la lecture de documents historiques. Une déclaration de conformité décrit une implémentation ; elle ne certifie pas l'état d'une installation.

Le manuel de Dedalus constitue une contre-vérification utile : il explique déjà clairement la présentation du fuseau horaire pour sa propre application. L'apport pratique réside ici dans le dossier de preuves intersystèmes et la décision d'attribution. Pour un incident réel, comparez les étapes de la source, du récepteur et de l'affichage plutôt que de traiter un manuel individuel comme une explication universelle.

À qui incombent les investigations sur l'affichage, les métadonnées sources et l'horloge ?

La matrice d'orientation suivante est une aide rédactionnelle pour une investigation conjointe. Elle ne pose pas de diagnostic à distance et ne remplace pas les responsabilités de l'établissement. Les équipes locales peuvent répartir ces rôles différemment ; identifiez un responsable désigné et la prochaine demande d'éléments de preuve avant de clôturer le ticket.

Orientez selon l'observation vérifiée. Lorsqu'une ligne permet encore plusieurs explications, gardez-les ouvertes jusqu'à ce que la comparaison suivante permette de les distinguer.

Un symptôme d'horloge côté échographe peut justifier une évaluation plus approfondie sans justifier une carte de remplacement. Évitez les procédures improvisées de coupure d'alimentation ou de mesure de tension de batterie issues d'un article générique. Utilisez les instructions existantes pour distinguer un problème de sortie d'une question relative à la carte d'E/S, et orientez les symptômes réels de démarrage ou de maintien de l'horloge vers le circuit de maintenance qualifié du système hôte.

Comment un contrôle de réception synthétique doit-il préserver l'enregistrement ?

Pour une réception ou une modification logicielle/de configuration, convenez d'un test synthétique avec les responsables de la modalité et du PACS. Utilisez un environnement de test approuvé et une identité de test de l'établissement, en maintenant les enregistrements de test hors des listes de travail cliniques, sauf si l'établissement dispose d'un flux de travail contrôlé explicite. Une simulation permet de tester l'arithmétique sans modifier l'horloge d'un échographe en production.

La liste de contrôle ci-dessous propose les éléments de preuve à conserver. Il ne s'agit pas d'une procédure OEM, d'une norme de tolérance d'horloge ni d'une preuve d'aptitude à l'utilisation clinique. Le périmètre, les actions autorisées, les critères d'acceptation et la validation relèvent du plan approuvé par l'établissement.

Préservez le dossier clinique d'origine. N'utilisez pas de réécritures de balises ad hoc, de suppression ou de renvoi comme raccourci pour faire correspondre une date à un écran. Une correction confirmée nécessite le responsable autorisé des dossiers et le processus encadré de l'établissement.

DICOM fournit des mécanismes pour enregistrer les valeurs antérieures des attributs et le contexte de modification. Ces mécanismes ne constituent pas une politique complète d'amendement juridique ou institutionnel. Une explication technique de l'écart doit accompagner toute correction autorisée, précisant ce qui a changé, pourquoi et ce qui demeure incertain. ²

Maintenez les décisions connexes distinctes. Toute incertitude sur l'identité requiert le parcours de réconciliation de l'identité du patient. Une demande effectuée qui reste ouverte relève d'une investigation sur l'état MPPS. La responsabilité d'archivage et la rétention locale exigent des preuves d'engagement de stockage ; le résultat d'un filtre par date ne peut pas trancher cette décision.

Ce qui relève de Rongtao — et ce qui n'en relève pas

Les services publiés de Rongtao comprennent la réparation de cartes et sous-ensembles d'échographie, les diagnostics au niveau du système et les pièces de rechange testées. Ce rapport aide à préparer les éléments de preuve techniques pour une évaluation de service ; il n'établit aucune capacité particulière de réparation de RTC, aucune disponibilité de pièces ni aucun cas résolu de fuseau horaire. ¹⁴

Ce qui relève de Rongtao Medical :

• Lorsque le service sur l'échographe reste pertinent : Transmettez le symptôme de l'appareil observé de manière indépendante ainsi que la configuration installée afin que le périmètre proposé puisse être évalué. Le modèle, la révision de la carte et les éléments de preuve de la panne doivent précéder toute recommandation de pièce.
• Lorsque les éléments de preuve relèvent d'un autre périmètre : La politique d'affichage de l'archivage, l'intégration de la liste de travail et les modifications du dossier clinique nécessitent les équipes responsables de l'établissement et le support du fournisseur. Ce rapport ne constitue pas une offre d'administration de ces systèmes.
• Avant un devis : Consultez le processus de service documenté et convenez de l'évaluation, des tests et des livrables pour l'article concerné. Ne déduisez pas la compatibilité ou la réparabilité d'une différence de date d'un jour.

Rongtao est un fournisseur indépendant de services et de pièces. Les noms d'OEM figurant ici identifient des équipements ou des logiciels documentés ; ils n'impliquent aucune autorisation ni approbation de l'OEM.

• Conservez les examens, en-têtes et journaux identifiables au sein des canaux approuvés par l'établissement. Le simple retrait du nom du patient ne rend pas un objet DICOM complet adapté à une demande commerciale.
• Ne fournissez de photos d'étiquettes ou de cartes existantes que si elles sont accessibles en toute sécurité par une manipulation qualifiée. Ne démontez pas l'équipement simplement pour obtenir une photo destinée à un devis.

Pour une demande de maintenance système anonymisée, indiquez l'OEM, le modèle exact, le logiciel installé, le texte du symptôme/de l'erreur, le moment où l'écart se produit, l'événement affiché par chaque écran et le contexte de décalage connu. Si le matériel est mis en cause, incluez la référence/révision de pièce du fabricant et les photos de l'étiquette ou des deux faces accessibles en toute sécurité. Précisez la quantité et le pays de destination. Demandez une évaluation du symptôme observé plutôt que de désigner une carte défaillante non vérifiée.

Foire aux questions

L'absence de champ de décalage de fuseau horaire signifie-t-elle UTC ?
Non. Ne déduisez pas un décalage nul de cette absence. Un suffixe DT explicite peut fournir un contexte ; sinon, obtenez le contexte source et vérifiez l'interprétation documentée du récepteur avant d'effectuer la conversion.

Un examen peut-il commencer avant minuit et contenir des acquisitions ultérieures ?
Oui. Il s'agit d'événements différents. Vérifiez leurs définitions et leurs décalages avant de qualifier les dates d'incohérentes. Le début de l'acquisition n'est pas automatiquement l'instant du gel ou de la sauvegarde de l'image.

L'envoi réussi d'une image prouve-t-il que la date affichée est correcte ?
Non. Le statut du transfert ne valide pas l'événement sélectionné pour l'affichage ni sa conversion. Confirmez séparément les valeurs réelles et la politique de présentation ; utilisez les directives relatives à la responsabilité de l'archivage pour les décisions de conservation.

La Modality Worklist et le Query/Retrieve d'archivage utilisent-ils une mise en correspondance des dates identique ?
Non. Ils disposent de dispositions de correspondance distinctes. Le filtre de date d'une visionneuse peut encore être différent. Identifiez le service réel et la configuration avant d'appliquer toute règle de requête.

Modifier l'horloge aujourd'hui peut-il corriger les dates déjà stockées dans le PACS ?
La seule modification de l'horloge source ne réécrit pas les instances précédemment générées. Le comportement futur dépend également de la configuration et du mappage d'événements. Les corrections historiques nécessitent le flux de travail autorisé relatif aux dossiers, plutôt que de supposer qu'un changement d'horloge met à jour les anciens examens.

Une différence d'un jour doit-elle déclencher le remplacement d'une carte ?
Non. C'est une preuve insuffisante d'un composant défaillant. Déterminez si le problème concerne la signification de l'événement, l'interprétation du décalage, une requête ou un symptôme de l'échographe observé de manière indépendante. Une évaluation qualifiée doit déterminer tout besoin de réparation.