Передача медицинских изображений: техническое руководство

Одно КТ-исследование сердца занимает от 500 МБ до 2 ГБ, изображение цифровой патологии целого препарата — 4 ГБ, а исследовательский набор фМРТ на одного субъекта достигает 40 ГБ. Передача медицинских изображений через электронную почту или публичные файловые хранилища нарушает требования 152-ФЗ к защите персональных данных и создаёт реальные риски для пациентов. Правильный метод передачи зависит от формата, размера файла, типа получателя и от того, поддерживает ли принимающая сторона DICOM нативно или ей нужен совместимый формат.

DICOM, NIFTI и что именно вы перемещаете

Прежде чем выбирать метод передачи, определитесь с форматом. DICOM (Digital Imaging and Communications in Medicine) объединяет пиксельные данные с тегами метаданных — имя пациента в (0010,0010), UID исследования в (0020,000D), модальность в (0008,0060). Типичное МРТ-исследование представляет собой папку из сотен файлов .dcm, каждый из которых — один срез. NIFTI (.nii или .nii.gz) — исследовательский формат нейровизуализации, упаковывающий весь объём в один файл.

Диапазоны размеров:

Рентгеновский снимок грудной клетки: 10–30 МБ
КТ головы: 50–200 МБ
МРТ брюшной полости: 300 МБ–1 ГБ
МРТ сердца с кино: 500 МБ–2 ГБ
Патология целого препарата (.svs, .ndpi): 1–4 ГБ на препарат
Одна серия фМРТ: 500 МБ–2 ГБ; полное исследование: 10–40 ГБ

Выбирайте инструмент передачи, исходя из самого крупного файла, который вы будете отправлять, а не из среднего размера.

DICOMweb: современный протокол обмена

DICOMweb, определённый в DICOM PS3.18, заменяет старый протокол DIMSE на HTTP. Три базовых сервиса:

STOW-RS — POST-запрос с DICOM-экземплярами на /studies.
WADO-RS — GET-запрос /studies/{StudyInstanceUID} для получения данных.
QIDO-RS — поиск исследований и серий с параметрами запроса.

DICOMweb работает поверх TLS 1.3 и совместим с токенами OAuth 2.0, именно поэтому современные PACS-системы, такие как Orthanc, dcm4chee и Ambra Health, его поддерживают. Если вы интегрируете две больничные системы и обе поддерживают DICOMweb, отдельный инструмент передачи не нужен — достаточно настроенного шлюза.

Когда DICOMweb недоступен

Большинство реальных передач происходит между системами, не имеющими общего шлюза. Районная больница отправляет травматологическое КТ в специализированный центр. Пациент несёт МРТ к специалисту. Исследовательский центр передаёт данные фМРТ в координационный центр. В таких случаях:

SFTP (RFC 4253 с OpenSSH) — надёжен для плановых передач между известными конечными точками, но слаб с точки зрения UX аудита.
IHE XDS-I.b — профиль интероперабельности для кросс-корпоративной визуализации. Требователен к развёртыванию.
Веб-зашифрованная загрузка — прагматичный выбор для разовых или нерегулярных передач, особенно когда в процессе участвует пациент.
Физический носитель — записанный CD с профилем IHE PDI всё ещё встречается, хотя и уходит в прошлое.

Деидентификация перед передачей

Заголовки DICOM насыщены персональными данными. Стандарт DICOM PS3.15 Annex E определяет Базовый профиль деидентификации, перечисляющий 400+ тегов для удаления, замены или очистки. Распространённые ошибки:

Оставление аннотаций, сгоревших в пиксельных данных, — они требуют OCR-редакции, а не просто изменения заголовков.
Пропуск частных тегов в диапазонах (0009,xxxx), где производители хранят серийные номера сканеров.
Сохранение Study Instance UID, позволяющего провести повторную идентификацию при наличии оригинала.

Для исследовательских данных по GDPR деидентификация плюс TLS 1.3 плюс AES-256-GCM в состоянии покоя является минимальным стандартом. Клинические данные, передаваемые между лечащими врачами, не требуют деидентификации, но всё равно нуждаются в шифровании.

В России 152-ФЗ определяет персональные данные широко: любая информация, позволяющая прямо или косвенно идентифицировать физическое лицо, подпадает под его действие. ФСТЭК России устанавливает технические требования к защите информационных систем, обрабатывающих персональные данные.

Сжатие, синтаксис передачи и пропускная способность

Файлы DICOM могут храниться несжатыми (Implicit VR Little Endian, Transfer Syntax UID 1.2.840.10008.1.2) или с применением JPEG 2000 Lossless (1.2.840.10008.1.2.4.90), JPEG-LS или RLE. Сжатие без потерь для КТ-данных обычно экономит 50–60%.

Если у вас симметричный канал 100 Мбит/с, МРТ сердца 2 ГБ передаётся примерно за 3 минуты на максимальной скорости. При загрузке 10 Мбит/с — 30 минут. Планируйте соответственно или используйте сервис передачи с поддержкой возобновления при разрыве соединения.

Передачи по инициативе пациента

Растущий сценарий: пациент сидит в кабинете специалиста, передаёт флешку или логин портала, и специалист загружает изображения. Для этого нужен метод передачи, которым может воспользоваться нетехнический пациент. Веб-форма, где пациент перетаскивает файлы, которые шифруются на стороне клиента с парольной фразой, и отправляет парольную фразу в клинику по другому каналу — рабочее решение. Без учётной записи, без обращения в IT.

HexaTransfer соответствует этой схеме — клиентское AES-256-GCM, совместная ссылка, парольная фраза по отдельному каналу. Попробуйте на hexatransfer.com — бесплатно, без учётной записи, максимум 10 ГБ.

Цепочка хранения для телерадиологии

Службы телерадиологии полагаются на конвейеры передачи, которые аудиторы отслеживают почасово. Необходимые компоненты:

Хэш SHA-256, зарегистрированный в отправляющей PACS и проверенный на рабочей станции чтения.
Хронологически меченный журнал событий, включающий номер доступа и идентификатор читающего радиолога.
Хранение журналов передачи в течение срока, определённого законами о медицинской документации.
Автоматическое удаление промежуточной области хранения после подтверждения получения, чтобы сервер не превращался в теневой архив.

Работа с ограничением в 10 ГБ для веб-передач

Большинство веб-сервисов передачи ограничивают отдельные передачи 2–10 ГБ. HexaTransfer предоставляет 10 ГБ бесплатно без учётной записи.

Для передач выше ограничения варианты следующие:

Разбивка на логические блоки — один визит, одна модальность, одна серия за передачу.
Физическая отправка — зашифрованный диск LUKS или VeraCrypt для нерегулярных случаев.
Выделенный канал — VPN или прямое соединение для регулярных высокообъёмных потоков.

Знайте своё ограничение до того, как обещать сроки.

Интеграция с PACS без нарушения рабочего процесса

Главное правило: не нарушайте список работ радиолога. Если ваш рабочий процесс передачи затрагивает PACS, маршрутизируйте через промежуточный узел (Orthanc или dcm4chee как маршрутизатор DICOM работает хорошо), чтобы производственная PACS получала только проверенные исследования.

Для исходящих передач одним кликом «Отправить внешнему» в PACS, перенаправляющим в инструмент передачи, радиолог исключается из рабочего процесса шифрования — что именно им и нужно. Они перетаскивают исследование, инструмент шифрует, и клиницист на другом конце получает ссылку.

Верификация и передача

После каждой передачи проверяйте:

Количество файлов совпадает (количество файлов .dcm или томов NIFTI).
SHA-256 архива совпадает у отправителя и получателя.
Хотя бы одно изображение открывается в просмотрщике получателя.
Метаданные не повреждены — имя пациента, дата исследования и номер доступа читаются.

Фиксируйте верификацию в записи передачи. «Мы отправили» — не защита; «мы отправили и подтвердили целостность на уровне байтов» — да. Передача медицинских изображений — это не просто перемещение байтов, это перемещение диагностической записи, от которой зависит чья-то медицинская помощь, иногда в течение нескольких минут.