Transfert d'imagerie médicale : guide technique complet

Le transfert d'imagerie médicale déplace des formats DICOM, NIFTI et radiologiques propriétaires entre systèmes PACS, médecins référents, spécialistes et patients — typiquement via DICOMweb (WADO-RS, STOW-RS, QIDO-RS), IHE XDS-I, SFTP direct ou uploads web chiffrés. Une seule étude de scanner cardiaque pèse 500 Mo à 2 Go, une image histologique de lame entière atteint 4 Go, et un dataset d'IRM fonctionnelle de recherche peut dépasser 40 Go par sujet. Le RGPD et les recommandations de l'ANSSI imposent AES-256-GCM au repos et TLS 1.3 en transit pour tout fichier d'imagerie contenant des données personnelles de santé. La bonne approche de transfert dépend de la taille des fichiers, du type de destination, et de si l'autre extrémité parle DICOM nativement ou a besoin d'un format qu'un Mac peut ouvrir directement.

DICOM, NIFTI et ce que vous déplacez réellement

Avant de choisir une méthode de transfert, connaître le format. DICOM (Digital Imaging and Communications in Medicine) encapsule les données pixel avec des tags de métadonnées — nom du patient en (0010,0010), UID d'étude en (0020,000D), modalité en (0008,0060). Une étude IRM typique est un dossier de centaines de fichiers .dcm, chacun représentant une coupe. NIFTI (.nii ou .nii.gz) est le format de neuroimagerie de recherche qui compresse un volume entier dans un seul fichier. Les formats propriétaires comme les exports GE Advantage Workstation ou les fichiers Siemens syngo.via arrivent parfois sous forme d'archives .tar qu'un visionneur DICOM doit décompresser.

Plages de tailles : radiographie thoracique (10 à 30 Mo) ; scanner crânien (50 à 200 Mo) ; IRM abdominale (300 Mo à 1 Go) ; IRM cardiaque avec ciné (500 Mo à 2 Go) ; histologie de lame entière (.svs, .ndpi : 1 à 4 Go par lame) ; run IRM fonctionnelle (500 Mo à 2 Go, étude complète : 10 à 40 Go).

Adapter l'outil de transfert au fichier le plus volumineux que vous expédierez, pas à la taille moyenne.

DICOMweb : le protocole filaire moderne

DICOMweb, défini dans DICOM PS3.18, remplace l'ancien protocole DIMSE par HTTP. Trois services centraux : STOW-RS (Store Over the Web, RESTful) — envoyer des instances DICOM via HTTP POST vers /studies ; WADO-RS (Web Access to DICOM Objects, RESTful) — récupérer via HTTP GET /studies/{StudyInstanceUID} ; QIDO-RS (Query based on ID) — rechercher des études et séries avec des paramètres de requête.

DICOMweb fonctionne sur TLS 1.3 et s'intègre bien aux tokens OAuth 2.0, ce qui explique pourquoi les PACS modernes comme Orthanc, dcm4chee et Ambra Health le prennent en charge. Si vous intégrez deux systèmes hospitaliers parlant tous deux DICOMweb, vous n'avez pas besoin d'un outil de transfert séparé — vous avez besoin d'une passerelle configurée.

Quand DICOMweb n'est pas une option

La plupart des transferts réels se produisent entre systèmes ne partageant pas de passerelle. Un hôpital communautaire envoie un scanner de traumatologie à un centre tertiaire. Un patient apporte son IRM d'un établissement externe chez un spécialiste. Un site de recherche expédie des données d'IRMf à un centre de coordination des données. Dans ces cas :

SFTP (RFC 4253 avec OpenSSH) — fiable pour les transferts planifiés entre points de terminaison connus, mais faible sur l'expérience utilisateur d'audit. IHE XDS-I.b — le profil d'interopérabilité pour l'imagerie inter-entreprises, utilisé par les HIE comme Carequality ; lourd à déployer. Upload web chiffré — le choix pragmatique pour les transferts ponctuels ou ad hoc, surtout quand un patient est impliqué. Support physique — un CD gravé avec le profil IHE PDI se produit encore, mais s'estompe rapidement à mesure que les hôpitaux suppriment les lecteurs optiques.

Dépersonnalisation avant le transfert

Les en-têtes DICOM sont denses en données personnelles. Le Standard DICOM PS3.15 Annexe E définit le Profil de Base pour la dépersonnalisation, qui liste plus de 400 tags à supprimer, remplacer ou vider. Outils qui l'implémentent correctement : DicomAnonymizer, CTP (Clinical Trial Processor), dcmdeid de dcm4che. Erreurs courantes : laisser des annotations en surimpression dans les données pixel (celles-ci nécessitent une OCR et une rédaction, pas seulement des modifications d'en-tête) ; oublier les tags privés dans les plages (0009,xxxx) où les fournisseurs stockent les numéros de série des scanners ; conserver l'UID d'instance d'étude, qui permet la réidentification si l'attaquant possède l'original.

Pour les données de recherche sous RGPD, dépersonnalisation plus TLS plus AES-256-GCM au repos constitue le socle. Les données cliniques circulant entre médecins traitants sous l'exception de traitement HIPAA n'exigent pas de dépersonnalisation mais nécessitent tout de même le chiffrement.

Compression, syntaxe de transfert et bande passante

Les fichiers DICOM peuvent être stockés non compressés (Implicit VR Little Endian, Transfer Syntax UID 1.2.840.10008.1.2) ou avec JPEG 2000 Lossless (1.2.840.10008.1.2.4.90), JPEG-LS ou RLE. La compression sans perte sur les données de scanner économise généralement 50 à 60 %. La compression avec perte est un champ de mines médico-légal — de nombreux services de radiologie l'interdisent entièrement pour l'usage diagnostique.

Pour l'histologie de lame entière, JPEG 2000 ou le tiling du supplément DICOM 145 réduit considérablement la taille du transfert. Pour l'IRMf, gzip sur NIFTI (.nii.gz) est standard et réduit les fichiers de 3 à 5 fois.

Sur un lien symétrique à 100 Mbps, une IRM cardiaque de 2 Go prend environ 3 minutes à la vitesse maximale. Sur un site avec 10 Mbps en upload, ce sera 30 minutes. Planifier en conséquence — ou utiliser un service de transfert qui reprend automatiquement en cas de déconnexion.

Transferts contrôlés par le patient

Un workflow en croissance : le patient est dans le cabinet du spécialiste, remet une clé USB ou un identifiant pour son portail patient, et le spécialiste importe les images. Les règles anti-blocage d'information du 21st Century Cures Act font de cela un droit du patient.

Pour cette voie, vous avez besoin d'une méthode de transfert qu'un patient non technique peut utiliser. Un formulaire web où il dépose des fichiers, chiffrés côté client avec une passphrase, et envoie par SMS la passphrase à la clinique fonctionne — sans compte, sans ticket informatique. HexaTransfer s'adapte à ce schéma — AES-256-GCM côté client, lien partageable, passphrase hors bande. Testez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.

Chaîne de garde pour la téléradiologie

Les services de téléradiologie s'appuient sur des pipelines de transfert que les auditeurs tracent heure par heure. Les éléments essentiels : hash SHA-256 journalisé au PACS émetteur et vérifié à la station de lecture ; journal d'événements horodaté incluant le numéro d'accession et l'identifiant du radiologue lecteur ; rétention des journaux de transfert pour la période spécifiée par les lois étatiques sur les dossiers médicaux — souvent 7 à 10 ans après la dernière visite du patient, plus long pour les dossiers pédiatriques ; purge automatique de la zone de staging de transfert après confirmation de réception, pour éviter que le serveur de staging ne devienne une archive fantôme.

Gérer le plafond de 10 Go sur les transferts web

La plupart des services de transfert web plafonnent les transferts individuels à 2 à 10 Go. WeTransfer Pro atteint 200 Go par transfert mais nécessite un compte payant. SwissTransfer permet 50 Go gratuitement. HexaTransfer offre 10 Go gratuits sans compte.

Pour les transferts dépassant le plafond, les options sont : diviser en bundles logiques (une visite, une modalité, une série par transfert) ; expédition physique (AWS Snowball Edge contient 80 To ; un envoi express avec un disque chiffré LUKS ou VeraCrypt fonctionne pour les cas ponctuels) ; lien dédié (connexion directe ou VPN hospitalier pour les flux récurrents à volume élevé).

Connaître votre plafond avant de promettre un délai.

Intégrer avec le PACS sans perturber les lectures

La règle unique : ne pas casser la liste de travail du radiologue. Si votre workflow de transfert touche le PACS, router via un nœud de staging (Orthanc ou dcm4chee comme routeur DICOM fonctionne bien) pour que le PACS de production ne reçoive que des études validées. Étiqueter les transferts entrants avec un AE Title distinctif pour qu'ils apparaissent dans une liste de travail séparée jusqu'à ce qu'un technicien effectue un contrôle qualité.

Pour les transferts sortants, une action « Envoyer vers Externe » en un clic dans le PACS qui route vers votre outil de transfert retire le radiologue du workflow de chiffrement — ce qu'il souhaite. Il dépose l'étude, l'outil chiffre, et le clinicien à l'autre extrémité reçoit un lien.

Vérification et remise

Après chaque transfert, vérifier : le nombre de fichiers correspond (comptage des fichiers .dcm ou volumes NIFTI) ; le SHA-256 de l'archive correspond entre l'expéditeur et le destinataire ; au moins une image s'ouvre dans le visionneur destinataire ; les métadonnées n'ont pas été corrompues — nom du patient, date de l'étude et numéro d'accession sont lisibles.

Journaliser la vérification dans votre dossier de transfert. « Nous l'avons envoyé » n'est pas une défense ; « nous l'avons envoyé et confirmé l'intégrité au niveau des octets » l'est. Le transfert d'imagerie médicale ne consiste pas simplement à déplacer des octets — c'est déplacer un dossier diagnostique dont dépend la prise en charge d'un patient, parfois en quelques minutes.