DICOM Partage de fichiers en Santé: Bonnes pratiques

Le partage moderne de fichiers DICOM utilise le standard DICOMweb (WADO-RS, STOW-RS, QIDO-RS) sur HTTPS plutôt que le transfert physique sur CD ou l'ancien protocole DIMSE. Un scanner thoracique standard génère 300 à 800 Mo ; une IRM cardiaque avec plusieurs séquences peut atteindre 2 Go ; une image histologique de lame entière pèse 1 à 10 Go. Le RGPD et les référentiels de l'ANSSI exigent que ces données de santé à caractère personnel soient chiffrées avec AES-256-GCM au repos et transitent via TLS 1.3 — avec une traçabilité complète de chaque accès. La pile de référence : un PACS (GE Centricity, Sectra, Fujifilm Synapse, ou cloud-natif via Google Healthcare API) comme archive d'images, une archive neutre de fournisseur (VNA) pour le stockage long terme, une plateforme cloud d'échange d'images (Ambra Health, LifeImage, PocketHealth) pour le partage interprofessionnel et patient, et HexaTransfer pour les transferts ponctuels chiffrés.

Pourquoi le transfert d'images sur CD est en voie de disparition

Pendant deux décennies, les hôpitaux ont expédié les études DICOM sur CD avec un visionneur intégré. Ce workflow était familier mais douloureux : 3 à 5 minutes de gravure par CD au centre d'imagerie ; 10 à 20 % des CD arrivent illisibles à l'établissement destinataire ; le visionneur intégré ne fonctionne souvent pas sur macOS ou Linux modernes ; le transit physique — livraison rapide pour les transferts urgents — prend souvent 18 à 24 heures ; un pourcentage mesurable de CD n'arrivent jamais à destination.

Les plateformes cloud comme Ambra, LifeImage et PocketHealth ont rendu le partage d'images dirigé par le patient la norme par défaut dans les grands centres hospitaliers universitaires.

DICOMweb : le standard moderne

DICOMweb est la version HTTP du protocole réseau DICOM. Trois services clés :

• STOW-RS (Store over Web) : envoyer des objets DICOM vers un serveur via HTTP POST
• WADO-RS (Web Access to DICOM Objects) : récupérer des objets DICOM via HTTP GET
• QIDO-RS (Query based on ID) : interroger par étude, série ou instance via HTTP

Les trois fonctionnent sur HTTPS avec TLS 1.3, ce qui les rend compatibles avec les pare-feu d'une manière que le DIMSE DICOM hérité (port 104 ou 11112) n'a jamais été. L'authentification utilise OAuth 2.0 ou des certificats client.

La plupart des PACS modernes exposent désormais des points DICOMweb. Les plateformes cloud-natives — Google Cloud Healthcare API, AWS HealthImaging, Azure DICOM Service — sont DICOMweb-first.

Tailles des données par modalité et planification de la bande passante

Les tailles des études varient considérablement selon la modalité : radiographie thoracique (5 à 15 Mo non compressée, 1 à 3 Mo en JPEG 2000) ; scanner crânien (100 à 300 Mo) ; scanner thoracique (300 à 800 Mo) ; scanner abdomino-pelvien avec contraste (500 Mo à 1,5 Go) ; IRM cérébrale multi-séquences (150 à 400 Mo) ; IRM cardiaque (500 Mo à 2 Go) ; mammographie avec tomosynthèse (500 Mo à 1,5 Go par examen) ; imagerie histologique de lame entière (1 à 10 Go par lame) ; échocardiographie 3D (200 à 500 Mo).

Un service de radiologie traitant 500 études par jour génère 150 Go à 1 To de nouvelles images quotidiennement. Planifier la bande passante en conséquence ; des liens dédiés à 1 Gbps vers les principaux partenaires référents sont de plus en plus courants.

Compression : avec et sans perte, et la question diagnostique

DICOM prend en charge plusieurs syntaxes de transfert : non compressé (Explicit VR Little Endian, taille maximale) ; JPEG Lossless (compression 2 à 3x, entièrement réversible) ; JPEG 2000 Lossless (compression 3 à 4x, recommandation sans perte actuelle) ; JPEG 2000 avec perte (compression 10 à 20x, avec perte d'information) ; HTJ2K (JPEG 2000 Haute Performance, ratios similaires, décodage plus rapide).

Pour l'usage diagnostique primaire, les recommandations de l'ACR préconisent la compression sans perte. Pour la revue secondaire, la téléconsultation ou la visualisation patient, la compression avec perte est défendable avec une documentation explicite. Ne jamais appliquer de compression avec perte à la mammographie de dépistage — des restrictions similaires s'appliquent à la coloscopie virtuelle par scanner et à d'autres examens spécifiques.

Partage d'images dirigé par le patient

Les règles anti-blocage d'information du Cures Act s'étendent à l'imagerie. Les patients ont le droit d'accéder à leurs propres images par voie électronique. Plateformes dédiées : PocketHealth (accès patient, intègre plus de 700 centres d'imagerie) ; LifeImage (désormais partie de Mach7, professionnel-vers-patient et professionnel-vers-professionnel) ; Ambra Health (Intelerad, échange cloud d'images, portail patient) ; Apple Santé (tire de plus en plus les images via les ressources FHIR ImagingStudy).

Pour les services de radiologie, proposer l'un de ces services est désormais pratiquement obligatoire. Ne pas offrir l'accès patient est interprété par l'OCR comme un blocage d'information et peut déclencher une procédure de sanction civile.

Dépersonnalisation pour la recherche et l'enseignement

Les études de recherche, les présentations en conférence et les dossiers pédagogiques ont besoin de données DICOM sans PHI. DICOM définit des tags spécifiques à supprimer ou remplacer (Profil de Confidentialité de Base de l'Application et profils supplémentaires dans DICOM PS 3.15 Annexe E).

Tags clés à traiter : PatientName (0010,0010) ; PatientID (0010,0020) ; PatientBirthDate (0010,0030) ; StudyDate (0008,0020) — peut être décalé d'un offset aléatoire par patient ; ReferringPhysicianName (0008,0090) ; InstitutionName (0008,0080) ; StationName (0008,1010) ; UID — à remplacer par des UID de recherche en préservant l'intégrité référentielle.

Outils qui gèrent cela correctement : Posda (basé sur CTP), RSNA MIRC CTP, pydicom avec des scripts personnalisés, le module de dépersonnalisation de MIM, dcm4che. Toujours valider séparément que les annotations en surimpression dans les pixels sont supprimées — le texte gravé dans les pixels d'image n'est pas un tag DICOM qu'on peut simplement effacer.

Rapports structurés et captures secondaires

Les rapports de radiologie voyagent avec les images. Les workflows modernes utilisent : les messages HL7 v2 ORU (résultats d'observation), hérités mais universels ; les ressources FHIR DiagnosticReport, modernes et de plus en plus exigées ; les rapports structurés DICOM (SR), données de rapport lisibles par machine intégrées aux images ; les images de capture secondaire DICOM, pour les captures d'écran annotées.

Un package de transfert d'imagerie complet inclut l'étude DICOM, le SR si disponible, et le rapport final signé (souvent en PDF via Document encapsulé). Expédier l'étude sans le rapport oblige le radiologue destinataire à relire l'ensemble.

Journalisation des audits et contrôles d'accès

HIPAA et le profil IHE ATNA (Audit Trail and Node Authentication) spécifient la journalisation pour chaque événement DICOM : qui a accédé (utilisateur authentifié) ; ce qui a été accédé (UID d'étude, série, instance) ; quand (horodatage) ; depuis où (IP source) ; quelle action (visualisation, téléchargement, modification, suppression).

La plupart des PACS et VNA modernes génèrent ces journaux nativement. Les transmettre vers un SIEM (Splunk, Sentinel, QRadar, Datadog) avec une rétention d'au moins 6 ans — le minimum HIPAA pour les dossiers.

Imagerie cloud : Google, AWS, Azure

Les fournisseurs cloud proposent désormais des services DICOM natifs : Google Cloud Healthcare API (magasin DICOM avec points DICOMweb, couvert par BAA) ; AWS HealthImaging (stockage DICOM optimisé avec chargement par frame à la demande) ; Azure DICOM Service (point DICOMweb géré, intégré à Azure FHIR).

La tarification est d'environ 0,02 à 0,05 € par Go stocké par mois plus les coûts de transfert de données et d'appels API. Pour un service de radiologie de taille moyenne (10 To de volume annuel), cela représente environ 200 à 500 €/mois hors sortie. Ces services signent des BAA et gèrent une grande partie de l'ingénierie de conformité. La contrepartie est l'enfermement propriétaire et le coût récurrent par rapport à l'investissement en capital sur site.

Une configuration pratique d'échange DICOM

Pour un cabinet de radiologie : PACS (fournisseur entreprise existant ou DICOM cloud Google/AWS/Azure) ; VNA (Hyland, IBM Merge, Visage ou cloud-natif) ; échange d'images (Ambra, LifeImage ou PocketHealth) ; livraison des rapports (intégrée au PACS ou via FHIR) ; dépersonnalisation (RSNA MIRC CTP ou MIM pour la recherche) ; transferts chiffrés ponctuels (HexaTransfer avec chiffrement de bout en bout et BAA) ; rétention des journaux d'audit : 6 ans minimum dans le SIEM.

Testez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.