Рубрика: Статьи

01.04.2023 Статьи

Что такое Заявление о соответствии стандарту DICOM?

Некоторые поставщики и заказчики медицинской аппаратуры, заявляя в своей документации о соответствии стандарту Dicom, не понимают о чем, собственно заявляют, как собственно необходимо "заявлять" и что такое вообще "Заявление о соответствии стандарту Dicom". Краткий ликбез на эту тему.

Перевод статьи Bimba Shrestha с исправлениями и дополнениями.

Стандарт DICOM сложен, и разные медицинские устройства поддерживают его в разной степени. Например, компьютерный томограф может поддерживать определенный набор функций DICOM, а архив изображений (PACS) может поддерживать другой. Оба устройства совместимы с DICOM, но если они не поддерживают определенные дополнительные функции, они не будут работать вместе.Что это означает для покупателей, продавцов и пользователей медицинского оборудования? Это означает, что не каждое DICOM-совместимое устройство обязательно будет взаимодействовать с другим DICOM-совместимым устройством!Здесь вступает в действие Заявление о соответствии стандарту DICOM ( DICOM Conformance Statement — DCS). DCS — это подробный технический ДОКУМЕНТ, сопровождающий большинство устройств, в котором точно указывается КАКИЕ конкретно функции стандарта поддерживаются. Возвращаясь к нашему примеру, в Заявлении о соответствии стандарту КТ-сканера должно быть указано, что он поддерживает функции, перечисленные как требуемые в Заявлении о соответствии стандарту архива изображений, чтобы они могли работать вместе.
SOP, SCU и SCP
DCS используют множество специфических терминов. Некоторыми распространенными из них являются SOP (пара объектов службы), SCU (пользователь класса службы) и SCP (поставщик класса службы). Эти термины имеют очень специфические значения в стандарте DICOM, но на данный момент вы можете думать о SOP как о «некоторой желательной функции устройства», а SCU/SCP — как о дополнительных частях этой функции. Половина SCP обеспечивает функцию, а половина SCU использует ее.Чтобы продолжить наш предыдущий пример: чтобы компьютерный томограф мог отправлять изображения в архив изображений он должен быть SCU для SOP «Хранение изображений CT», а архив изображений должен быть SCP для него. Если обе половины этой функции отсутствуют, два устройства не будут работать вместе. Даже если они оба помечены как совместимые с DICOM!DCS (среди прочего) — это список поддерживаемых SOP, определенных как роли SCU/SCP. Сравнив этот список между устройствами, вы сможете определить их совместимость.Также смотрите ликбез системному администратору на эту тему.
Структура DCS
Несмотря на сложность, большинство DCS имеют одинаковую структуру документов. Это сделано намеренно, и разработчики стандарта DICOM приложили большие усилия, чтобы предоставить подробные шаблоны для DCS. Вот высокоуровневая структура DCS (подробности смотрите в официальном стандарте ) :
  • Титульная страница : первая страница, содержащая название устройства и дату.
  • Обзор заявления о соответствии : описание устройства непрофессионалом.
  • Оглавление
  • Введение : общая информация, соответствующие отказы от ответственности и условия.
  • Сеть : Описание услуг, связанных с сетью.
  • Медиа-обмен : Описание несетевых служб обмена.
  • Поддержка наборов символов : какие наборы символов и кодировки поддерживаются (подробнее о проблемах кириллических кодировок см. в описании программы Dicom AutoExport).
  • Безопасность : Соответствующие вопросы безопасности, описания и заявления об отказе от ответственности.
  • Приложения
Для покупателей медицинского оборудования
Если вы являетесь покупателем, оценивающим медицинское устройство, вам всегда следует запрашивать DCS. Как упоминалось выше, то, что устройство совместимо с DICOM, ещё не означает, что оно обязательно будет работать с вашими существующими информационными системами. Например, вот несколько случаев, в которых что-то может пойти не так, если вы не изучите подробно DCS поставщика:

  • Если вы покупаете устройство, которое не поддерживает SOP SCP для проверки DICOM, вы никогда не сможете проверить подключение DICOM к этому устройству с другого устройства DICOM. Сообщения с подтверждением, отправленные на него, останутся без ответа, как будто устройство либо не существует, либо имеет разорванное сетевое соединение.
  • Если вы покупаете архив, который поддерживает SOP SCP хранилища MR, это не означает, что он должен поддерживать SOP SCP хранилища CT, и вы, возможно, не сможете перенести свои данные CT в тот же архив.
  • Если у вас есть рабочая станция, которая поддерживает C-Find (Query) SCU, но не поддерживает C-Find (Query) SCP, вы никогда не сможете запросить эту рабочую станцию ​​с другой рабочей станции или из архива. Только SCP-запросы могут отвечать на запросы, передавая эти ответы другим устройствам.
  • Если вы покупаете телерадиологический сервер DICOM, который не поддерживает сжатие изображений для передачи изображений C-Store, вы не сможете отправлять сжатые изображения. И т. д. ...

Список потенциальных проблем длинный, поэтому будьте внимательны и всегда просите DCS.

Для продавцов медицинского оборудования
Если вы являетесь продавцом медицинского оборудования, в ваших же интересах поставлять свой продукт с сопроводительной DCS. Это единственный способ, которым ваши потенциальные клиенты могут оценить совместимость вашего устройства с их существующей настройкой.

 Пример Заявления о соответствии:

Сервер XrayPACS. Заява про відповідність стандарту Dicom

 

01.04.2023 Статьи

Почему существует стандарт DICOM?

О назначении стандарта. Просто для начинающих.

Перевод статьи David Giese с некоторыми моими дополнениями и уточнениями.

Стандарт DICOM предназначен для облегчения взаимодействия между системами медицинской визуализации от разных поставщиков. Стандарт определяет формат файла для хранения медицинских изображений, протоколы, чтобы приложения могли ими обмениваться, и формат соответствия, чтобы покупатели могли определить, какие системы могут (надеюсь) взаимодействовать. Но, возможно, самое главное, DICOM обеспечивает стандартизированную модель реальности. Эта информационная модель является основой, в которой заложена интероперабельность, т. е. способность продуктов или систем взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации.

Что такое DICOM?

Стандартный документ DICOM имеет краткое описание области применения в разделе 1.1 стандарта :

Цифровая визуализация и коммуникация в медицине (DICOM) — это стандарт для передачи и управления информацией о медицинских изображениях и связанными с ними данными. Стандарт DICOM облегчает взаимодействие медицинского оборудования для визуализации, определяя:

  • Для сетевой связи - набор протоколов, которым должны следовать устройства, заявляющие о соответствии Стандарту.
  • Синтаксис и семантику команд и связанная с ними информация, которой можно обмениваться с использованием этих протоколов.
  • Для медиа-коммуникации - набор услуг хранения медиа, которым должны следовать устройства, заявляющие о соответствии Стандарту, а также формат файла и структура медицинского каталога для облегчения доступа к изображениям и связанной с ними информации, хранящейся на обменном носителе.
  • Информацию, которая должна быть предоставлена ​​с реализацией, для которой заявлено соответствие Стандарту.

DICOM обеспечивает совместимость в двух смыслах. Во-первых, это облегчает техническую «синтаксическую» совместимость:

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

Разработка программного обеспечения, которое точно следует этим техническим деталям, может быть сложной задачей. К счастью, есть несколько приличных библиотек, которые очень помогают в этом.

Помимо чисто технической совместимости, DICOM также способствует «семантической» совместимости.

Семантическая совместимость

Эта общая модель реальности облегчает взаимодействие, потому что без нее у разных поставщиков, вероятно, были бы слегка (или радикально) разные модели реальности, что затрудняло бы взаимодействие.Например, один поставщик может не утруждать себя включением объекта «Исследование» в свою модель реальности, а другому поставщику могут потребоваться определенные фрагменты данных, которые другой поставщик опускает. В обоих случаях интеграция оборудования и программного обеспечения от этих двух разных поставщиков будет более сложной, а в некоторых случаях и невозможной.

Основная проблема в том, что реальность сложна!

Точно смоделировать ее сложно, и в зависимости от вашего приложения может иметь или не иметь смысл включать определенные детали в вашу модель. Существует компромисс между точностью и простотой.

Фактически, сам DICOM признает, что его модель не идеальна.

Эта информационная модель представляет собой упрощение реальных концепций и действий медицинской визуализации; для модальностей сбора исследование приблизительно эквивалентно упорядоченной процедуре, а серия приблизительно эквивалентна выполненному элементу протокола сбора данных. В других областях, таких как лучевая терапия, исследование и серия менее четко связаны с реальными объектами или действиями, но все же необходимы для согласованности. Эта упрощенная модель достаточна для прагматических нужд управления изображениями и соответствующими данными, собранными в повседневной практике.

К счастью, несмотря на эти упрощения, модель DICOM довольно хороша. И, на наш взгляд, гораздо лучше иметь одну бракованную модель, чем десятки бракованных моделей — по одной на каждого производителя!

Конечно, DICOM не устраняет полностью проблемы интеграции по нескольким причинам:

  1. Приложения не реализуют должным образом стандарт
  2. Приложения реализуют разные версии стандарта
  3. Большая часть метаинформации является необязательной (поэтому приложение может не предоставлять ее).
  4. Стандарт неоднозначный.

Еще раз, DICOM достаточно осведомлен , чтобы сообщить вам о своих ограничениях , если вы не можете сделать вывод самостоятельно:

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

Вывод
Цель стандарта DICOM — облегчить взаимодействие между системами медицинской визуализации от разных поставщиков. Это достигается за счет стандартизации технических деталей реализации сети и хранилища, но, возможно, что более важно, за счет предоставления согласованной модели реальности.
10.07.2022 Статьи

DICOM: цифровые снимки в медицине — ликбез для системного администратора

Одним из самых компьютеризированных разделов медицины является радиодиагностика. Медицинские исследования генерируют большое количество данных, которые затем обрабатываются передовыми методами визуализации, 3D-реконструкции по срезам и даже машинного обучения. Этот топик призван помочь системным администраторам погрузиться в тематику передачи и хранения медицинских изображений.
Авторские права на данную статью принадлежат Владиславу Россу - gag_fenix . Она была недавно опубликована на популярном у программистов, админов и широкого круга околокомпьютерной публики веб-сайте — https://habr.com/ru/post/217761/ А здесь публикуется с любезного разрешения её автора с некоторыми сокращениями и моими комментариями.

0920b6d7c1c8d090551342d4ec3ea3a1

Фото автора

Техминимум

DICOM (Digital Imaging and Communications in Medicine) — стандарт обработки, хранения, передачи, печати и визуализации медицинских изображений. DICOM определяет формат файлов радиологических исследований и сетевой протокол, который в качестве транспорта использует TCP/IP. DICOM разрабатывается с 80-х годов, ежегодно обновляется, став на сегодняшний день стандартом де-факто — поддерживается всеми современными цифровыми устройствами: томографами, УЗИ-аппаратами, маммографами, рентгеновскими аппаратами и т.д.

Основная «фишка» DICOM — интероперабельность. За счет различных механизмов DICOM позволяет передавать данные между очень разным медицинским оборудованием и ПО.

Сама спецификация протокола интересна в первую очередь разработчикам медицинского софта. Мы рассмотрим основные моменты, касающиеся эксплуатации с точки зрения ИТ-отдела, не углубляясь в дебри.

c01b3d7f26b35dd60d320cf0d822f629

 

Информация о пациенте и запланированном исследовании поступает на аппарат из радиологической информационной системы. По завершении диагностики аппарат уведомляет РИС и отправляет снимки в центральный архив. Рентгенолог получает снимки на рабочую станцию (со специально откалиброванным монитором) и составляет заключение. Пациенту файлы исследования могут быть записаны на диск или распечатаны.

Основные понятия

Modality (модальность) — медицинский аппарат, создающий (acqusition) медицинское изображение определенного типа. Типы обозначаются аббревиатурой, например:

CR Рентгенография
CT Компьютерная томография (КТ)
MG Маммография
MR Магнитно-резонансная томография (МРТ)
PT Позитронно-эмиссионная томография (ПЭТ)
US Ультразвуковая диагностика (УЗИ)
XA КТ-ангиография
SC Secondary capture — импорт из не-DICOM источника (например, сканирование пленки)
SR Структурированный текстовый отчет
OT Прочее

PACS — Picture Archiving and Communication System — центральный сервер хранения медицинских изображений в организации, который получает исследования от модальности и по запросу выдает на рабочие станции радиологов или в другие отделения. Может быть интегрирован с RIS и/или HIS;

HIS — Hospital Information System — медицинская информационная система (МИС) — общая система электронного документооборота мед. учреждения;

RIS — радиологическая информационная система (РИС) — система информатизации диагностического отделения, содержащая данные от пациентов, расписание приёма на исследование и т.д.

DICOM-файл — файл (стандартное расширение .dcm), содержащий графическую информацию, а также метаданные. Для большинства модальностей в одном файле хранится единственное изображение, но иногда это может быть серия кадров. Используются различные алгоритмы сжатия: Lossy JPEG, JPEG2000 или Loseless JPEG. Также DICOM поддерживает хранение waveform данных (ЭКГ, аудио).

Файл является нижним элементом иерархии: пациент (patient) → исследование (study) → серия (series) → изображение (image/instance).

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

  • patient demographics — персональные данные пациента: ФИО с разделителем кареткой (??????^????^?????????), возраст: число и буква (0???), пол (M/F/O), вес и т.д.;
  • уникальный идентификатор (UID) study и series по ISO 8824;
  • patient ID;
  • модальность;
  • сведения о медицинском учреждении, ФИО радиолога;
  • дата и время обследования;
  • марка и модель аппарата;
  • другая информация об исследовании; полный список можно посмотреть тут.

Анонимизация (anonymize) — функция удаления персональных данных из DICOM-файлов;

DICOMDIR — файл с метаинформацией о снимках в папке. Используется при записи снимков на CD/DVD;

SCU (Service Class User) и SCP (Service Class Provider): в терминологии DICOM SCU инициирует запрос, а SCP предоставляет ему сервис. Иначе говоря, SCU — клиент, а SCP — сервер. При этом один и тот же узел DICOM может быть в каких-то случаях SCU (например, когда он запрашивает список), а в каких-то SCP (когда получает снимки);

AE — Application Entity — отдельный сервис DICOM. В простом случае на физическом устройстве (станции, PACS, модальности) «живет» один AE, но по стандарту их может быть и несколько, в т.ч. на одном TCP-порте;

AE Title — название узла (AE), уникальное в сети, до 16 символов ASCII, обычно заглавными. Бо́льшая часть DICOM-софта работает в режиме whitelist, т.е. обмен данными разрешается только с AE, заранее занесенными в список. Как правило, для успешной передачи снимков на обоих сторонах в ПО нужно указать IP, порт и AE Title;

IOD — Information Object Definition — шаблон, определяющий список атрибутов для объектов реального мира. Для атрибутов задается тип данных, длина и флаг множественности. Для повторного использования атрибуты группируются в модули. Например, атрибут Patient's Birth Date входит в модуль Patient, который используют разные IOD. Если IOD содержит модули для нескольких объектов, он называется композитным (composite). Например, IOD снимка томографа содержит не только само изображение, но также наследует информацию о пациенте, исследовании, серии, frame of reference и оборудовании. IOD и команда комбинируются в SOP Class (Service Object Pair), например, класс «CT Storage» — это комбинация команды C-Store и КТ-изображения. Подробно останавливаться на модели данных DICOM мы не будем; отсылаю интересующихся к литературе в конце.

Transfer syntax — режим кодирования информации при передаче, задает порядок бит implicit/explicit little/big endian, формат сжатия графики. Иногда его приходится указывать явно;

Association — процесс установления сетевой сессии в DICOM; подразумевает обмен информацией о поддерживаемых Abstract и Transfer syntax. Ошибка на этапе Association говорит либо о неверных настройках TCP или AE Title либо о несовместимом Transfer syntax или неподдерживаемом/отключенном в софте SOP;

DICOMweb — стандарт REST-API для просмотра снимков через web.

Сервисы DICOM

Сервисы DICOM обеспечивают взаимодействие модальностей, PACS, RIS и рабочих станций по сети, поддерживая набор композитных операций над объектами (DIMSE):
C-STORE — отправка снимков с SCU на SCP («пуш»), например, с аппарата в архив;
C-GET — получение снимков от SCP на SCU («пулл»), например, из архива на рабочую станцию;
C-FIND — поиск исследований по атрибутам (например, ФИО пациента, дате и др.);
C-MOVE — запрос от SCU на отправку снимков с SCP на какой-то третий хост (который может быть самим SCU); SCP должен «знать» AE Title хоста назначения;
C-ECHO — проверка связи («пинг»).

Подробнее об операциях DICOM можно почитать в топике [6].

Сервис Query/Retrieve (Q/R) комбинирует C-FIND и C-MOVE (реже C-GET) для поиска объектов на SCP с последующим получением на SCU.

Сервис Storage предназначен для согласования и передачи объектов от SCU к SCP с помощью команды C-STORE. При этом на принимающей стороне (SCP) может производиться процесс добавления/изменения информации Coercion, если какие-то из обязательных атрибутов не заполнены, например автоматически генерироваться Patient ID.

Modality Worklist (MWL) — предварительное получение информации о пациенте, для которого запланировано исследование, из RIS на модальность. Таким образом, специалист, проводящий исследование, избавляется от необходимости заполнять эту информацию вручную, что экономит его время и уменьшает количество ошибок.

MPPS (Modality Performed Procedure Step) — фиксация статусов проведенных исследований, количества изображений, полученной дозы радиации и т.п. в RIS.

Print — печать hard copy снимка на пленочном принтере.
Администрирование DICOM

PACS-сервер

В самом примитивном случае никакого центрального сервера вообще нет. Снимки с аппаратов сыпятся на рабочие станции, а врачи гоняют их между компьютерами в одноранговой сети. Такой подход по понятным причинам является тупиковым.

Необходимо выделение центрального архива — PACS, который будет круглосуточно обеспечивать доступ к полному собранию обследований. Если выбор PACS лежит на ИТ-отделе, стоит обратить внимание на бесплатные проекты:

  • dcm4chee — open-source PACS на Java с web-интерфейсом. Работает на Linux, Mac OS X или Windows.
  • Orthanc — легковесный и быстрый open-source mini-PACS под Linux, Mac OS X или Windows, написанный на С++. Поддерживает REST API и систему плагинов;
  • Dicoogle — еще один кроссплатформенный open-source PACS;
  • microsoft/dicom-server — облачное решение от Microsoft, можно развернуть локально в Docker, но, кажется, что оно заточено под небесплатный Azure;
  • PacsOne — freeware (до 1 млн. снимков) PACS для Windows/Mac/Linux;

Из перечисленных PACS я работал только с dcm4chee (но на всех трёх платформах). По своему опыту могу сказать, что он способен обслуживать крупные архивы, а для конфигурирования доступна масса параметров — в Tomcat и XML-файлах. К сожалению, не все из них хорошо задокументированы, поэтому приходилось обращаться за помощью на форум.

Финальным шагом автоматизации является интеграция PACS с RIS/HIS с реализацией MWL и MPPS. Без интеграции с общей системой архив PACS быстро превращается в «кашу»: данные пациента вводят на аппарате непосредственно перед исследованием, поэтому нет сквозного ID пациента, а ФИО часто заводится транслитом (*т. к. аппаратура, производящая снимки, использует нестандартную для Dicom кодировку символов кириллицы. Например, win-1251. Для исправления кодировки в таких файлах существует программа Dicom AutoExport . Прим. Александра Кузнецова — А.К.). В результате потом невозможно автоматически сопоставить исследование и историю болезни: например, Юлия Жукова из общей HIS может числиться в PACS как Yuliya Zhukova, Julia Jukova или даже Iulia Dzukova. До кучи появляются опечатки. Если же на аппарат будут автоматически приходить данные пациентов из RIS/HIS, то такой проблемы не возникнет.

Сеть

Пропускная способность сети должна быть не ниже 1 Гбит/c. Используйте выделенную локальную сеть, лучше всего физически изолированную от других сетей и Интернет или хотя бы в отдельном VLAN. Для увеличения скорости и надежности подключения PACS-сервера можно использовать bonding.

Что может затруднить задачу построения сети для радиологии: файрволлы или трансляция адресов между модальностями/станциями, динамические адреса, динамическое назначение порта в операции C-GET.

Стандартные TCP-порты DICOM: 104, 11112, 2762 (TLS).

Хранилище

Основная нагрузка на аппаратное обеспечение PACS ложится на диски.
Хранилище необходимо проектировать, исходя из двух параметров:
а) Необходимого интервала хранения архива. (*Для разных категорий исследований устанавливаются разные сроки храненения — от трех до десяти лет, и даже пожизненно— для некоторых видов патологий. Прим. А.К).
б) Количества поступающих новых данных в единицу времени. Эта величина сильно зависит от количества и типов оборудования, а также режима работы конкретного ЛПУ. (*Обычно самый большой размер имеют ангиографические исследования (видео), затем МРТ и КТ (много срезов), флюороскопия (многокадровые серии), маммография (т. к. изображения имеют высокое разрешение), затем рентгенография. Всё остальное «весит» значительно меньше. Прим. А.К.)

Таким образом, главной головной болью администратора является построение относительно большого по объему хранилища с высокой степенью надежности. Требования же к пропускной способности и IOPS не столь существенны, если клиентов (модальностей и рабочих станций) не очень много. В большинстве случаев подойдут обычные (СMR) жесткие диски (кажется, что диски с черепичной PMR записью плохо подходят для DICOM, но у нас опыта с ними не было). Однако современные PACS при желании позволяют организовать и многоуровневое хранилище, например: свежие снимки на SSD → архив на HDD → «холодный» архив на ленте или S3.

Если сервер, который выделили под PACS, не может вместить необходимое количество дисков (например, он одноюнитовый), решением может стать закупка СХД или дисковой полки, подключаемой к серверу.

Тут нужно отдельно отметить, что PACS, как правило, ведут реляционную базу данных с пациентами, исследованиями и снимками. Вот её, возможно, стоит хранить на быстром хранилище на SSD или HDD RAID0, чтобы ускорить Q/R поиск по большому архиву.

Обеспечение надежности и резервное копирование

Как следует из предыдущего пункта снимки нужно хранить до 10 лет, а рядовой жесткий диск может прожить значительно меньше. Стандартным способом увеличения надежности является использование RAID-массива. Если позволяет бюджет, то для обеспечения наилучшей производительности рекомендуется использование уровня RAID10, которые требует х2 пространства хранения и выдерживает отказ, как минимум, одного диска. Более бюджетным, но менее производительным является уровень RAID6, который выдержит отказ двух дисков. Уровни RAID0 и RAID5 использовать не рекомендуются из-за низкой надежности. Хранилище без RAID (JBOD) можно использовать только, если у вас есть вторая полная резервная копия архива.

Важно: используйте hot-spare диски или держите оперативный запас дисков того же объема на складе на случай отказа одного из HDD.

Немаловажным аспектом использования RAID является резервирование RAID-контроллера. Если используется аппаратный RAID, существует ли надежный план восстановления в случает отказа контроллера? Есть ли на складе идентичная модель? Возможно, стоит сразу использовать софтверный RAID, у которого не будет проблем с восстановлением на другой машине?

Желательно использовать сервера с двумя блоками питания, питающимися от разных фаз/вводов. Необходимо наличие ИБП. Если сервер/ИБП конструктивно может быть запитан только от одного источника, то для повышения надежности можно использовать специальный PDU с возможностью питания от двух источников.
Старая админская мудрость гласит, что использование RAID не является заменой резервному копированию. Вообще стандарт DICOM не поддерживает операций удаления из архива, поэтому уничтожения данных из-за ошибки оператора, как правило, можно не бояться. Однако существуют другие опасности, например, разрушение файловой системы, отказ нескольких дисков или физическое уничтожение сервера в результате пожара, затопления и т.п. серверного помещения. В таких случаях может спасти только настоящий бекап.

Для восстановления PACS нужно сохранять дамп БД и резервную копию файлов исследований. Особенностью DICOM в данном случае является то, что PACS, как правило, хранят каждый снимок отдельно, так что на диске будут лежать миллионы мелких файлов. В результате полный бекап десятилетнего хранилища может занять дни или даже недели. Возможно, для снимков оптимальной стратегией будет разово сделать полную копию и настроить инкрементальное резервное копирование, например, раз в сутки. Хорошей новостью является то, что файлы DICOM обычно неплохо сжимаются, поэтому бекап может занимать значительно меньше места, чем оригинал.

Несколько лет назад мы заводили для резервного копирования open source ПО Bacula и роботизированную ленточную (LTO) библиотеку. В 2022 году уже кажется, что исходя из совокупной стоимости владения и простоты администрирования для бекапа предпочтительно использовать обычный сервер с HDD. При этом желательно, чтобы архивная копия физически находилась как можно дальше от основного PACS на случай пожара: в другом корпусе, на другом этаже или хотя бы в другом помещении. Не стоит делать бекап на тот же сервер, где «живёт» PACS — это серьезно его «обесценивает».

Нужно помнить, что авария центрального хранилища может привести к приостановке лечебной деятельности, поэтому разумно завести PACS горячего резерва на отдельной физической машине. Основной PACS следует настроить на автоматическую отправку свежих снимков на резервный. В принципе такой «брат-близнец» может быть альтернативой резервному копированию. Если же бюджет не позволяет зеркалировать архив за всё время, можно держать в горячем резерве только свежие исследования, например за последний месяц. Т.к. клиентов обычно не так много, не обязательно держать настоящий балансер (типа HAProxy) на случай отказа — достаточно оповестить медицинский персонал, что есть резервный архив, которым они могут пользоваться, и завести его AE Title на всех локальных узлах.

Наконец, немаловажным элементом устойчивой эксплуатации является мониторинг. Помимо использования обычного шаблона мониторинга аппаратного обеспечения и ОС для PACS-сервера, следует обратить пристальное внимание на мониторинг сервиса PACS и его резерва (с помощью утилит отправки C-ECHO, см. ниже), свободного места, свободных inode (для Linux), специфических метрик используемой СУБД. Обязательно также настроить оповещения от диагностики дисков S.M.A.R.T. и RAID-контроллера. Резервное копирование также должно быть покрыто мониторингом.

Если модальности или сопутствующие системы поддерживают сбор метрик (через snmp или т.п.) их также стоит замониторить. В зависимости от тяжести аварийной ситуации стоит настроить алертинг вплоть до автоматического экстренного звонка на телефон дежурного сотрудника — например, отказ воздушного контура охлаждения МРТ может привести к кипению дорогостоящего жидкого гелия и сбросу его через аварийный клапан, что приведет к финансовым потерям и простою сканера.

Мониторинг может также служить подспорьем в планировании закупок (capacity planning), прежде всего HDD под хранилище. Для этого нужно организовать сбор метрик об объеме новой информации поступающей в неделю/месяц/год — можно экстраполировать график и заранее узнать, когда понадобятся новые диски.

Клиенты и утилиты

Просмотрщиков для DICOM очень много, упомянем некоторые:
Horos — открытый и бесплатный просмотрщик для Mac OS X;
OsiriX — популярный платный просмотрщик для Mac OS X, может работать как PACS, есть бесплатная Lite версия;
Weasis — открытый кроссплатформенный просмотрщик для Linux, Mac OS X и Windows; есть portable версия; может быть интегрирован в dcm4chee как веб-просмотрщик;
Oviyam 2 — HTML5 просмотрщик для web;
MultiVox DICOM Viewer — бесплатный отечественный просмотрщик для Windows;
MicroDicom — бесплатный для некоммерческого использования просмотрщик для Windows;
Vidar Dicom Viewer — просмотрщик DICOM исследований для Windows, Linux систем, есть бесплатная версия.
Сайт IDoImaging.com содержит большую подборку бесплатного софта медицинской визуализации.

dcm4che3 — открытый кроссплатформенный набор утилит для манипуляций с DICOM — например, миграции исследований по сети или мониторинга ответа C-ECHO;
DCMTK — открытий кроссплатформенный набор утилит и библиотек для DICOM.

Ещё почитать
  1. Сайт стандарта DICOM
  2. DICOM Standard Browser — удобная навигация по атрибутам
  3. Типы данных
  4. Basic DICOM Operations
  5. Глоссарий OTpedia
  6. PACS-сервер своими руками
  7. Серия постов «DICOM Tutorial» на сайте «DICOM is Easy»
  8. Introduction to DICOM
  9. Пьяных, О.С. Digital Imaging and Communications in Medicine (DICOM). A Practical Introduction and Survival Guide— Springer, 2008. ISBN: 978-3-540-74571-6
19.03.2022 Статьи

Кодировка dicom-элементов типа Code String

Небольшое исследование об отображении кириллического текста в dicom-элементах типа Code String (CS). Не всё так просто, как оказалось. Инструкцию читать надо! 🙂

Один из пользователей программы Dicom AutoExport версии 1.9.1 прислал несколько файлов с указанием того, что кириллица в тегах такого типа все-равно неправильно отображается после конвертации.

Что выяснилось? А оказалось, что тип кодировки, указанный в элементе (0008,0005) совершенно не влияет на отображение символов в элементах Code String.

В стандарте Dicom он определяется как строка символов длиной не более 16 байт, которая может содержать прописные буквы, цифры 0-9, пробел и нижнее подчеркивание.  Кодировка символов в стандарте не указана, но вот на одном из сайтов нашёл, что она должна быть ASCII, и понятно, что латиница. Откуда они взяли, что должно быть именно ASCII непонятно, но, по-видимому, многие вьюверы ожидают именно её.

Взял, что было под рукой из вьюверов. Оказалось, что это Microdicom, Weasis и Радиант. Dicom-файл "сделан" на аппаратуре и ПО компании Телеоптик, программой экспорта кодировка всех текстовых тегов, в том числе и CS, конвертирована в UTF-8.

Microdicom и weasis однозначно не опознают здесь УТФ8.
То, что там УТФ я убедился через онлайн-конвертер.

MD Weasis UTF8

А Радиант нормально всё видит.

readiant utf8

Есть ещё один нюанс.
DicomDump указывает, что ошибка также в том, что значения тегов взяты не из словаря, т. е. не соответствуют стандарту.

DicomDump

Например, для (0018,5101) это должны быть двух-трехбуквенные значения, обозначающие позицию пациента: https://dicom.innolitics.com/ciods/cr-image/cr-series/00185101

А для (0018,0015) есть приложение "L" в стандарте с перечислением возможных значений: https://dicom.nema.org/medical/dicom/current/output/chtml/part16/chapter_L.html#chapter_L

Я не думаю, что те вьюверы, которые неправильно отображают Юникод в этих тегах, ориентируются на стандартные значения из словаря и типа кроме них ничего не умеют видеть.

Начал экспериментировать. Взял аналогичные файлы, где все теги в кодировке 1251 и всё, кроме CS конвертировал в UTF-8. Т.е. (0018,0015) и (0018,5101) остались в кодировке win-1251.

Теперь MicroDicom все отображает корректно:

2 MD

А Weasis все-равно не понимает кириллицу в CS:

2 weasis

И Радиант перестал правильно смотреть:

2 radiant

Т.о. вывод:
Первый вьювер в этих тегах читает кодировку в вин-1251, второй — непонятно, что ждет, а Радиант ждет то, что указано в (0008,0005).

Добавил функцию конвертации из 1251-ansi в ascii и применил ее только к тегам CS.
Т.е. всё в UTF-8, а CS в ASCII
Теперь MicroDicom показывает какую-то хрень, а точнее пытается ascii отобразить как 1251:

3 md

Weasis все равно кириллицу не видит:

3 weasis

И Радиант тоже:

4 radiant

Вывод: Нет одного единого подхода у вьюверов при отображении этих тегов. Единственный вариант, когда все вьюверы не отображают иероглифы в этих тегах — латиница. Т.е., чтобы всех удовлетворить, нужно CS записывать латиницей, а ещё лучше конкретные значения брать из словаря.
Для (0018,5101) в «людской» рентгенографии это всего-то восемь возможных значений: AP, PA, LL, RL, RLD, LLD, RLO, LLO. Для ветеринарии, конечно, посложнее 🙂 и для лаборанта там вообще китайская грамота будет. Но, наверное, стоит эти значения жестко занести в список для выбора без возможности его редактирования.
Для (0018,0015) всё ещё сложнее. Укладок хренова туча и все их проблематично внести. А если даже они и будут доступны для выбора, то кто же их выбирать будет, когда мало кто из персонала смыслит в этих названиях. Когда укладка выбирается на графическом шаблоне, то лаборанты ещё справляются как-то, а выбрать из списка непонятных слов на латинице — это нереально 🙂

В версии 1.9.3 программы Dicom AutoExport была добавлена для элементов типа Code String была специально добвлена опция, определяющая, каким образом их обрабатывать.

02.11.2021 Статьи

К вопросу о подключении медицинских информационных систем к имеющимся в рентгенотделениях PACS-системам

На сегодняшний день этот вопрос становится всё более актуальным, т. к. внедряемые МИС либо предлагают хранение рентгеновских исследований в своих облачных хранилищах по заоблачным ценам, либо вообще ничего не предлагают. И почти никто не горит желанием использовать уже имеющиеся в отделениях PACS-серверы по одной простой причине — просто «не умеют» работать с ними.Проблемы, конечно, есть. Самая большая проблема, на мой взгляд, в большом количестве рентгеновской аппаратуры, которая в лучшем случае может «сделать» снимок в формате «примерно» соответствующем dicom. Таких аппаратов огромное количество. Столько же, а может и больше, аппаратов, которые вообще просто пленочные и про «цифру» только «мечтают». В данном случае мы пока их вообще не рассматриваем.

Вернёмся к «как-бы» цифровым аппаратам. Они производят снимки «почти» dicom. И хранят их, а также информацию о них, как правило, на лаборантских рабочих станциях, используя при этом какие-либо СУБД типа InterBase, Firebird или MS Access. Описание этих снимков производится на врачебных рабочих станциях с использованием специально именно для них разработанного ПО, т. к. универсальные dicom-вьюверы такие снимки не читают без дополнительной обработки. Передавать самостоятельно исследования в PACS такие системы также не умеют. Для этого обычно можно использовать программу DicomAutoExport . Но зато в таких системах имеются удобные для врачей инструменты описания снимков, ведения истории исследований, печати снимков на пленку, печати описаний на бумаге.

В последнее время всё больше внедряется цифровых аппаратов, которые имеют все необходимые функции для полноценной работы с PACS и МИС. Но функции эти не используются, т. к. нет либо PACS, либо МИС, либо и того, и другого. В итоге хороший цифровой аппарат при отсутствии информационных систем используется даже более примитивно, чем рассмотренные выше аппараты. Зачастую такие системы вообще не имеют врачебных рабочих станций, т. к. предполагается, что все описания будут совершаться рентгенологом на рабочей станции, подключенной к МИС. Но МИС то нет, соответственно «писать» не на чем. И описывают врачи снимки просто, глядя на экран в лучшем случае своего, а не лаборантского, компьютера, используя какой-нибудь самостоятельно установленный dicom-вьювер и чернильную ручку с бумагой. Да, аппарат цифровой, а результаты на выходе получаются «аналоговые».

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

Поиск исследований в PACS осуществляется либо по ИД, либо по дате, т. к. поиск по ФИО часто некорректен из-за недостаточно полной поддержки кириллических шрифтов. Но ИД одного и того же пациента на каждом аппарате даже в пределах одного отделения разный, т. к. присваивается или вручную по какому-то установленному правилу, или автоматически программой, производящей снимки. Не говоря уже о других модальностях типа УЗИ, ЭКГ и т.д.

С внедрением МИС вопрос единообразия ИД теоретически должен решиться. Осталось решить его практически. И здесь не всё так просто оказывается, как со стороны МИС, так и со стороны отделений.
Теоретически схема взаимодействия МИС и отделения должна выглядеть так (поправьте, если я чего-то упускаю или неправильно понимаю):

misAndRis

Здесь:

PACS (Picture Archiving and Communication System) - Программно-аппаратные комплексы, реализующие функции передачи и хранения изображений.

Storage - DICOM служба, обеспечивающая передачу и хранение изображений (файлов в формате DICOM).

Query/Retrieve - DICOM служба, обеспечивающая получение информации об изображениях, хранящихся на DICOM сервере, а также обеспечивающая выполнение команд по передаче изображений.

MWL (Modality Worklist Management) - DICOM служба, обеспечивающая передачу сведений о пациентах и их исследованиях из медицинской информационной системы на медицинское оборудование.

MPPS (Modality Performed Procedure Step) - DICOM служба,  обеспечивающая передачу сведений о выполненных на медицинском оборудовании исследованиях в медицинскую информационную систему.

SCP (Service Class Provider) - Программное обеспечение, функционирующее как серверная часть некоторой DICOM службы.

SCU (Service Class User) - Программное обеспечение, функционирующее как клиент некоторой DICOM службы.

Теперь словами.

Здесь предполагается, что медицинское оборудование (рентгенаппарат) поддерживает все необходимые dicom-службы.

Итак, МИС путём посылки HL7-сообщений формирует для модальностей (рентгенаппаратов в нашем случае) список заданий на сервере рабочих листов (сервис MWL SCP). Этот сервер может быть как в составе МИС, так и на одной платформе с PACS. Задание (Worklist) содержит сведения о пациенте (ИД, демографические данные и т.д.), наименовании модальности, которая должна его выполнить, идентификатор направления на исследование, перечень процедур, которые должны быть выполнены этой модальностью и другую необходимую информацию.

Модальность «читает» свои задачи с сервера MWL и выполняет их. Сообщение (HL7) о выполнении отправляется на сервис MPPS, а результаты в виде dicom-файлов на сервер PACS.

МИС теперь после получения сообщения на MPPS «знает», что задание выполнено (не выполнено) и результаты его сохранены с переданными идентификаторами. По известным теперь идентификаторам (Study UID, Series UID, SOP Instance UID) МИС может запросить исследования из PACS для передачи их на рабочие станции врачей-специалистов. Точнее даже не запросить, а дать рабочей станции врача ссылку на объект исследования, по которой она «вытащит» себе для отображения нужное исследование.

Рабочие станции врачей имеют простейшие средства для просмотра изображений и диагнозов, поставленных врачами-рентгенологами.

Рабочие станции врачей рентгенологов должны иметь более «продвинутые» просмотрщики исследований и средства для их описания. Результаты описаний должны сохраняться в виде DSR и отправляться в PACS с тем же Study UID.

Так в теории по идее должно быть.

Что в реальности — выше уже частично сказано.

Что делать, с чего начать движение к соответствию теории?

Начнём от обратного. Снимки уже есть и хранятся они на сервере. Каким образом клиенты, например та же МИС, могут запрашивать их для просмотра? Снова немного теоретических измышлений.

Любой PACS использует для обмена информацией с клиентами такие DICOM-методы, как C-FIND, C-GET, C-MOVE. Клиент (просмотрщик, МИС) готовит и отправляет серверу сообщение-запрос C-FIND, с ключами, по которым сервер должен произвести поиск, и перечнем атрибутов, которые он должен вернуть в результате этого поиска. Например, запросить перечень исследований, т. е. список УИДов исследований, для конкретного ИД пациента. Сервер отправляет обратно клиенту список ответных сообщений C-FIND, каждое из которых также является списком атрибутов DICOM, заполненных значениями для каждого совпадения. Клиент извлекает интересующие атрибуты из объектов ответных сообщений.

Изображения (и другие составные экземпляры, такие как состояния представления и структурированные отчеты) затем извлекаются с сервера PACS через запрос C-MOVE или C-GET с использованием сетевого протокола DICOM по полученным в C-FIND результатам. Извлечение может быть выполнено на уровне исследования, серии или изображения (экземпляра). Запрос C-MOVE указывает, куда следует отправлять извлеченные экземпляры (используя отдельные сообщения C-STORE по одному или нескольким отдельным соединениям) с идентификатором, известным как заголовок целевого объекта приложения (AETitle). Чтобы C-MOVE работал, сервер должен заранее знать все AETitle (а также их IP и порты), которым ему будет предложено отправить изображения. А клиент, соответственно, должен иметь запущенный экземпляр STORE-SCP с указанным AETitle.

C-GET выполняет операции C-STORE на том же соединении, что и запрос, и не требует, чтобы сервер знал клиентский IP и порт, и работает проще через брандмауэры и трансляцию сетевых адресов, в которых входящие соединения C-STORE, необходимые для C-MOVE, могут не пройти.

Вышеуказанные методы обмена имеют все PACS-системы. Но эти традиционные методы не всегда удобны для практического использования при межплатформенном обмене. Поэтому также активно внедряются методы веб-доступа к объектам dicom (WADO). Идея состоит в том, чтобы предоставить удобный веб-интерфейс для доступа к изображениям, который может быть реализован разработчиками, минимально знакомыми со стандартом DICOM, и который использует такие удобные для использования механизмы, такие как http, JSON и медиа-типы ( как изображение / JPEG).

Семейство таких DicomWeb-сервисов включает:

WADO-RS для поиска файлов DICOM, метаданных в формах XML или JSON, объемных данных, отделенных от метаданных, и изображений потребительского формата;

STOW-RS для хранения (отправки) файлов DICOM или отдельных метаданных и объемных данных;

QIDO-RS для запроса коллекций (базы данных, реестры) объектов DICOM.

Суффикс «-RS» указывает на RESTful-характер этих сервисов.

Более ранние версии веб-сервисов, такие как WADO-URI и WADO-WS также ещё достаточно популярны. WADO-URI предоставляет простой доступ как к оригинальным изображениям dicom, так и к их отрендеренным на стороне сервера версиям.

Для того, чтобы обеспечить возможность своим клиентам «смотреть» снимки, МИС имеют (?) инструменты, использующие какие-либо из вышеуказанных сервисов, для их поиска и извлечения из PACS.

Т.о. теоретически мне понятно, как «взять» снимок с сервера.

Мне также понятно как модальность получает задачу и «отчитывается» о её выполнении. Но пока что я знаю считанное на пальцах одной руки количество МИС, которые могут такую задачу поставить. И, соответственно, я знаю, что реализованных на практике таких схем работы буквально единицы. То МИС есть, а PACS-а нет, то наоборот. Или есть, но не могут. Или могут, но не все 🙂

Но это ещё хорошо, когда модальность умеет читать WL, но не имеет такой возможности. Надеюсь в ближайшее время узнать больше систем, могущих их загрузить.

С другой стороны ситуация, когда модальность вообще не понимает, что такое WL, для меня одновременно и проще, и сложнее.

Проще в том плане, что отсутствие такой функции на модальности исключает необходимость иметь серверы WL и MPPS в составе МИС или PACS. Сложнее же тогда решить задачу передачи на неё данных пациента, чтобы обеспечить уникальность и постоянство ИД хотя бы в рамках одной МИС, не говоря уже о глобальных ИД.

Соответственно и МИС тогда должна иметь инструменты поиска исследований в PACS, используя только ИД пациента и, возможно какие-то другие фильтры типа предполагаемой даты или ещё чего-то.

А вот каким образом вводить ИД пациента нужно решать индивидуально для каждого конкретного случая. Мне представляются четыре возможных варианта «ввода»:

копирование данных из «окна» МИС в «окно» программы на модальности, если лаборантская станция позволяет одновременно запустить эти программы;

ручной ввод данных лаборантом из направления на бумаге или экрана рабочей станции, подключенной к МИС;

«автоматический» ввод данных с помощью сканера штрих-кода, если МИС позволяет напечатать такое направление на бумаге или экране;

самый трудозатратный — написание специальных программ для «согласования» баз данных МИС и модальности.

Первый вариант предполагаю лишь теоретически, на практике не встречал.

Ручной ввод, понятное дело, возможен почти везде. Но приводит к наибольшему количеству ошибок (особенно, когда нужно вводить длинные последовательности цифр) и неудобен для персонала.

Реализацию ввода ИД сканером штрих-кода видел в работе с программой АльфаПлюс компании "Телеоптик". Достаточно удобно, количество ошибок существенно меньше.

Программы «согласования» также есть. Есть пример работы МИС «Каштан» с программой АПВС. Костыль. Надежность низкая, т. к. требуется надежное сетевое соединение, база данных модальности забивается пустыми записями и куча всяких проблем.

После решения вопроса с единообразием ИД станет возможным поиск исследований на сервере и их запрос для отображения на клиентских станциях. Но, кроме собственно снимков, и даже в большей степени, чем снимки, клиентам нужен диагноз, который поставлен рентгенологом по исследованию.

По идее в составе МИС должна быть специализированная рабочая станция врача-рентгенолога, имеющая все необходимые инструменты для просмотра. В этом случае текст диагноза врач вносит непосредственно в базу данных МИС и просмотр его остальными клиентами системы не представляет проблемы.

Если такой специальной станции нет, то нужно использовать какие-то сторонние инструменты.

Я знаю пока только аж одну программу, которая «умеет» и смотреть снимки с сервера, и имеет встроенный редактор для их описания, и отправляет потом описания в виде DSR на сервер. Эта программа может использоваться там, где аппараты имеют полный dicom-функционал, но не имеют рабочих станций врача-рентгенолога. В этом случае МИС должна читать диагнозы из DSR, прилепленных к описанным исследованиям.

Там же, где аппаратура имеет свою локальную БД для описания, снова нужно искать способы передачи этих описаний либо путём ручного копирования из этой БД в БД МИС, либо путём установки дополнительных программ для автоматической «конвертации» текста из БД в DSR. Как указывалось выше, такие станции имеют достаточно удобные инструменты и врачи вряд ли откажутся от их использования даже при подключении к МИС. В этих локальных базах может быть многолетняя история, по которой можно наблюдать динамику состояния пациентов и поэтому туда будут «смотреть» ещё долго. Как правило эти рабочие станции имеют уже устаревшую аппаратную и программную платформу и могут не допускать возможности установить на них дополнительное ПО. В лучшем случае можно организовать просто отправку снимков на dicom-сервер, а уже потом решать вопрос об их просмотре и описании, которое можно будет передать либо через PACS, либо через МИС другим врачам.

Вот вкратце так о проблемах «подключения» рентгенотоделений к медицинским информационным системам.

(С) Александр Кузнецов, 05.05.2020

30.09.2017 Статьи

Обзор dicom-вьюверов, имеющих функцию чтения из PACS

Обзор подготовлен для предоставления заказчику выбора для различных вариантов конфигураций просмотровых станций врача-рентгенолога. Основными функциями, которые должен иметь вьювер врача-рентгенолога, по мнению заказчика являются:

  • подключение к удаленному серверу;
  • возможность загрузки для просмотра рентгеновских изображений (2D) из локальной папки и CD/DVD;
  • наличие удобных инструментов просмотра;
  • экспорт изображений на CD/DVD, в локальную папку, в т.ч. в графические форматы;
  • возможность Dicom-печати;
  • возможность печати на принтере;
  • корректное отображение кириллических символов в dicom-тегах.

Желательными, но не обязательными функциями являются: возможности просмотра 3D, экспорт снимков на удаленные dicom-серверы, национальная локализация интерфейса, мультиплатформенность.

Первоочередным требованием было наличие возможности подключения к dicom-серверу.

Естественно, всем также хочется максимального функционала за меньшие деньги.

В связи с такой постановкой вопроса для обзора были выбраны следующие продукты:

Условия тестирования.

Для тестирования использовался удаленный тестовый сервер dcm4chee, подключенный по VPN-соединению.

Для просмотра использовались как исследования из одного снимка в серии, так и серии изображений — томографических срезов. Изображения загружались с сервера, локальной (сетевой) папки, с CD/DVD.

Экспорт осуществлялся на другой сервер dcm4chee, в локальную (сетевую) папку, на CD/DVD (или образ).

Оценка удобства работы — моя, субъективная и предвзятая 🙂 , т. к. я изначально имею свои представления об удобствах.

По каждому критерию вьюверы расставлялись по местам с 1 по 10, а условные балы ставились наоборот с 10 до 1. По некоторым критериям баллы не ставились вообще, т. к. различий между продуктами нет, все одинаково.

1. Подключение к dicom-серверу.

Вьюверы в первую очередь и были отобраны по этому критерию. Поэтому все вышеперечисленные продукты имеют такую функцию.

Почти все вьюверы могут подключать несколько серверов, но не все могут запрашивать список исследований сразу с нескольких. RadiAnt умеет.

Снимок экрана 2017 09 30 14 11 47

Synedra не может подключить больше одного сервера. После запроса списка он выводится в такую таблицу, в которой нет возможности настроить вид и порядок столбцов. ФИО пациента оказывается не видным, приходится двигать полосу прокрутки.

synedra5

Multivox почему-то грузил все медленнее, чем другие. Даже не медленнее, а просто долго, очень долго. Особенно серии. В интерфейсе нет кнопки быстрого вызова окна запроса. Из локального хранилища есть, из папки есть, а из сервера нет

SanteDicom - обширное меню, не сразу найдешь, где настройки. Ход загрузка снимков показывается в таблице, не очень нагляден, непонятно, идет она или нет.

Dicompass почему-то при каждом запуске выводит предупреждение, что не может соединиться с сервером и предлагает загрузиться в standalone режиме. При этом после загрузки соединяется с сервером без проблем. Удобная форма для запроса списка исследований. В рабочем наборе снимков не отображаются эскизы, неудобно выбирать для переноса в окно просмотра, непонятно что.

Снимок экрана 2017 09 30 14 18 54

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

Снимок экрана 2017 09 30 14 15 49

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

В Weasis также можно настроить несколько вызывающих AetTitle и при обращении к каждому серверу выбирать, тот, который с ним работает. Тоже не мешало бы кнопку быстрого доступа к серверам вывести на панель инструментов из меню, а то приходится лезть в меню. Окно фильтра запроса не блещет изяществом. И выводимый список несколько неудобен, когда он длинный.

Osirix Lite и Horos легко настраиваются и подключаются, если знать, где настройки находятся. Для оторвавшегося от виндового рабочего стола юзера это испытание. Кнопки запроса сразу на панели инструментов, все просто. Так и должно быть.

Лидеры — Инобитек, Weasis RadiAnt. Первые два — за то, что можно на каждый сервер настраивать вызывающий AeTitle, третий — за возможность запроса сразу с нескольких серверов.

tab1

2. Импорт изображений

Synedra не открыл из сетевой папки ни dcm, ни DICOMDIR, непонятно вообще почему. Что-то бормотал про права 🙂 С локального диска открыл.

Multivox достаточно быстро сканирует папки на предмет dicom-файлов и выводит список для выбора для загрузки. Достаточно удобно. Кнопка открытия диалога выбора папки, правда, какая-то совсем мелкая. А для чтения диска нужно в меню заходить, нет «быстрой» кнопки. И при этом ему нужен именно натуральный диск. Т.е. папка c DICOMDIR не катит, хотя DICOMDIR читается тоже нормально, но через другой пункт меню. В общем все запутано.

У Ginkgo не очень удобный диалог импорта.

Снимок экрана 2017 09 30 14 34 00

RadiAnt вообще для локального просмотра просто класс. Ничего лишнего. Кнопку тыць, выбрал — готово, и быстро.

Osirix Lite и Horos — все открывают. Все классно и красиво. Но Osirix Lite постоянно предупреждает, что он не предназначен для вынесения клинических заключений. Заколебал просто-напросто.

Osirix Lite1

Остальные — как бы все без проблем, но каждый получил мою субъективную оценку.

tab2

3. Инструменты просмотра

RadiAnt не знает, что у мыши может быть три кнопки. Настроить только две можно. Интерфейс минималистский, но этим он мне и нравится. Несколько неудобны лишние клацания мышей для переназначения кнопок по инструментам. Зато нет громоздких меню с буквами 🙂 Лупы НЕТ! Моей любимой лупы нет.

Инобитек, где инверсия? Негатив/позитив? Нашел! Неужели нельзя сделать отдельную кнопочку? Рентгенологи очень часто ей пользуются. А здесь попробуй найти ее в выпадающем списке преднастроек раскрасок пункт «Уровень серого (инверсия)».

Multivox — интерфейс ЯД! «Панель управления» занимает треть экрана, уменьшая при этом изображения. Инструментов много. Меню огромное. Но все так далеко и не удобно, что не хочется и смотреть.

multivox5

Synedra — не Multivox, но недалеко ушел. Мне бы неудобно было работать с ним.

Ginkgo — инструменты только самые простые.

Weasis — мне нравится такая панель инструментов. Все, что часто используется есть, все под рукой.

Снимок экрана 2017 09 30 14 45 18

Osirix Lite и Horos — куча инструментов, основные на панели, удобно. Но меню все-таки перегружено кучей различных прибамбасов.

tab3

4. Экспорт изображений.

RadiAnt не пишет CD/DVD.

Weasis экспортирует куда угодно и как угодно. И в графику, и в dicom, и на удаленный сервер, и в образ CD/DVD, который потом можно прожечь и вьювер будет там тоже.

Инобитек - хороший набор экспортных функций имеет, в т.ч. и пересылку на удаленный сервер. И наглядное «ручное» формирование образа CD/DVD, как по мне, очень неплохая идея.

tab4

SanteDicom: куча экспортов, но записи на CD нет 🙁

В Synedra вообще с экспортом плохо. Все очень запутано и не очевидно.

Osirix Lite и Horos — все просто: кнопка «Send» и диалог выбора сервера для отправки. Или выбери из меню, куда что отправить. Диски тоже не проблема.

Horos1

Не умеют отправлять на удаленный сервер RadiAnt, Multivox и Synedra.

5. Dicom-печать

Она или есть, или ее нет. Есть, конечно нюансы. Но такую фичу имеют из представленных продуктов Инобитек и Weasis и «маковские» вьюверы. Преимущество Инобитеку — все-таки более понятный, чем импортный Horos.

tab5

6. Распечатка на принтере

Не умеют печатать на принтере RadiAnt, Multivox и Synedra. Остальным добавим по 1 баллу. Все таки печать на бумагу снимков может кому-то и нужна, но просто, чтобы какую-то картинку дать, типа снимок был. Не для диагностики точно.

7. Корректность отображения кириллических символов

RadiAnt отображает кириллицу, как стандартную, так и win-1251 правильно. Т.е. разработчик знает, что в нашей действительности в снимки пишется виндовая кодировка и пофиг все стандарты dicom 3.0. Тоже самое умеет и SanteDicom, хотя разработчики совсем не кириллические греки 🙂

Снимок экрана 2017 09 30 14 51 30

Все остальные вьюверы корректно отображают стандартную кириллицу. Единственная непонятка с Horos. Почему-то он выводит корректно кириллическое название области съемки, направление проекции, а ФИО не выводит вообще. Всем по 1 баллу, Horos-у — 0 🙂

8. 3D-просмотр

Смотрел чисто из интереса, т. к. заказа на это не было.

Какую красивую 3D-модель нарисовал RadiAnt из кучи каких-то невнятных слайсов!

Radian 3D

Умеют с 3D работать также Osirix с Horos-ом. Остальные так не умеют. Но эта опция исследовалась чисто для справки, есть/нет.

9. Локализация интерфейса.

У RadiAnt минимальное количество текста в меню, поэтому разработчику не трудно было его локализовать на кучу языков, в т.ч. и украинский. Но даже с таким минимальным количеством текста разработчик не доработал. «Почук», «Очичтити» - ну пародия же просто.

Есть украинский и у Weasis. В меню выбора языка есть. На самом деле «украинизирован» один пункт меню и пара кнопок. Остальное на английском.

У остальных украинского не нашел. У Ginkgo, SanteDicom и Horos нет и русского, что, конечно, у нашего медперсонала всегда вызывает недовольство. Им по 0, остальным по единичке 🙂

10. Мультиплатформенность.

Вопрос в общем-то условный конкурсный, т. к. одновременно на всех трех платформах вряд ли кто-то работает. А под каждую можно выбрать наиболее удачный именно для нее. Но тем не менее об этом нужно сказать.

Наиболее полно охватывают основные платформы Инобитек, Ginkgo и Weasis. Они работают под Windows, Linux и MacOS.

Исключительно под MacOS работают Osirix и Horos.

Synedra - Windows и MacOS.

Остальные — только Windows.

Итого: из 10 продуктов работают под Windows — 8, Linux — 3, MacOS — 5. Обидно за Linux. Именно на этой платформе я больше всего склонен работать.

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

Инсталляция всех программ почти не имела никаких проблем во всех системах. Были нюансы с Инобитеком под линуксом. Нужно поставить дополнительно пакеты, о чем в инструкции ничего не пишут, но поддержка оперативно ответила. Некоторые требуют Java. Некоторые еще чего-то, но моменты рабочие и танцев с бубном не требующие.

11. Цена

Когда дело доходит до оплаты начинается самое интересное. Люди, говорившие вам, что да, нам вот это нравится, нам только так, нам .. Потом начинают говорить, что нам и так сойдет, да и это лишнее, наверное. Давай-ка по минимуму посмотрим, но чтобы лучше всех было, а?

Ну так вот.

Бесплатными являются Ginkgo CADx, Weasis, Multivox, Synedra View Personal, Osirix Lite и Horos.

Ну как бесплатными? Распространяются они по своим лицензионным правилам, с которыми можно ознакомится. Которые могут предполагать, что продукт не может использоваться для коммерции, не предназначается для клинического использования и т. д. Хотя вот эта «метка» «Не для использования в клинике», или постоянные сообщения об этом говорят лишь о том, что продукт не сертифицирован американским или европейским центром сертификации для использования в клинической практике.

Это логично для бесплатных продуктов. За сертификацию нужно платить, а это деньги, немалые весьма. А Weasis, например, разрабатывается сообществом добровольцев как свободно распространяемый продукт. Кто его будет сертифицировать и выкладывать свои деньги?

Я подозреваю, что и большинство платных продуктов не имеют сертификатов FDA или TUV, просто не говорят об этом да и все.

Поэтому по вопросу всяких сертификатов каждый должен решать сам, как поступать.

Сертифицированный Osirix MD стоит 699 американских денег. За что? За то, что по большому счету делает то же самое, что и бесплатный Horos. Да, есть множество функций, которые там есть, а там нет. И возможно эти функции кому-то очень нужны. Ну тогда делать нечего, нужно платить. А если нужно просто посмотреть снимок, напечатать на пленке может быть или переслать кому-нибудь еще, то зачем платить такие деньги, если все остальное не будет использоваться никогда?

Согласен, если продукт имеет все, что нужно, не перегружен ненужным конкретному заказчику функционалом и стоит разумных денег, нужно платить. При этом я склонен, конечно, к отечественным производителям, им хотя бы позвонить можно и на понятном языке изложить свои проблемы и получить консультацию, поддержку и т. д. Ну а если нет отечественного, то хотя бы с понятным языком общения 🙂 🙂 🙂 Для каждого он, конечно, свой, «понятный» я имею ввиду.

Цены, приведенные в итоговой таблице, взяты на сайтах или запрошены у разработчиков (продавцов). Не ответили на этот раз только чехи с Dicompass. Крайняя цена, которую я знаю, позапрошлогодняя была 4500 их крон, что соответствовало почти 200 американским деньгам, поэтому она и указана.

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

 

ПОДВЕДЕМ ИТОГИ

Итак, расставив оценки, используя мою субъективную предвзятость, получаем следующую итоговую табличку.

tab itog

Еще раз подчеркиваю: это мое личное крайне субъективное и предвзятое мнение. Оно вам может нравиться, а может нет, от этого оно не поменяется. У Вас будет свое мнение и своя оценка. Я вообще хотел, чтобы победил Weasis 🙂 🙂 🙂

Но получилось так как получилось 🙂

Глядя на результат, сразу думаешь: ну и зачем мне теперь это? Я что, теперь должен всем рекомендовать вьювер воронежских разработчиков? Наверное нет. Каждый из продуктов чем-то неплох, и каждый может иметь свою область применения. Ну и от операционки зависит.

Лично я под винду бы выбрал из этого списка RadiAnt или Инобитек Lite. Они почти в одной ценовой категории. RadiAnt чуть дешевле, есть варианты его бесплатного использования, но и возможностей у него меньше. Или вообще бесплатный Weasis. Почему бы и нет. Некоторые просто предвзято к нему относятся, не знаю почему.

Под Линуксы — Weasis или Инобитек Lite. Если бесплатного функционала Weasis будет вам достаточно, то и не надо заморачиваться с платным продуктом.

Под Мак — Horos или Weasis. С другой стороны, если у вас есть Мак и вы готовы платить, то зачем платить Инобитеку за Про-версию те же деньги, которые можно заплатить за всеми признанный «супер-пуперным» Osirix MD? Ну разве, что Lite-версия все-таки не такая уж и дорогая. Но тогда бесплатный Horos по функционалу превосходит, имея, правда, в минусе отсутствие русского языка.

Вот такие вот мои выводы. Чувствуете, что у меня Weasis все-таки победил 🙂 🙂 🙂

(С) Alieksandr Kuznietsov, 30.09.2017

01.05.2016 Статьи

Краткий субъективный обзор Dicom-вьюверов

Краткий субъективный обзор dicom-вьюверов.
Для предупреждения вопросов, почему эти, почему не всё рассмотрено и т. д.:
потому что обзор мой сугубо субъективный, поверхностный и предвзятый. На что захотел, на то и посмотрел 🙂 Мне пока нужно смотреть только статические рентгеновские изображения, сохраненные в формате dicom. Кроме того, внимание уделено способности вьюверов отображать кириллические теги, а также руссификация интерфейса, т. к. не все наши медицинские работники могут читать меню в подлиннике 🙂

Поэтому, кому-то может пригодится, а кому-то это совсем не нужно даже начинать смотреть, не то что читать. Поехали. Смотреть будем без всякой системы сортировки.
1. И первый у меня (на обозрении, а не по моим симпатиям) Radiant 2.2.9 (http://www.radiantviewer.com/beta.php)
Первый плюс для меня в том, что изначально англоязычный интерфейс легко русифицируется скачиванием файлика по ссылке прямо из меню программы. Лицензионное соглашение, правда, все равно на английском. Но кто его читает? Я — нет.
Первая и главная неприятность — вьювер платный. 80 европейских денег. По-моему не стоит он столько, посмотрим. А был же вроде бы бесплатным когда-то, или я ошибаюсь? Локальные файлы грузит без проблем. Может читать сразу все файлы из каталога, в т.ч. ищет и в подкаталогах. Может читать СД/ДВД. Неплохо. Понимает кириллические теги как в стандартной кодировке, так и win1251, невзирая на то, что записано в 0008.0005.
А вот загрузиться ни из удаленного, ни из локального Пакса почему-то не получилось. Пробовал к настроенным и 100% рабочим dcm4chee и conquest. Возможно ограничение пробной версии? Грустно. Хотя список пациентов выводит, поиск работает. Здесь, правда, русский не понимает напрочь, т. е. По фамилии не найдешь никого. Но это от Пакса еще зависит. Из dcm4 хотя бы список пациентов выводит нормально, а из конквеста и в списке крокозябры.
Набор инструментов просмотра стандартный, не перегружен излишествами, достаточно неплохо работает. Есть экспорт в различные форматы.
В общем-то очень неплохо. Жаль, что чтение из Пакса не пошло. Не знаю, что сказать. Был бы бесплатный — однозначно хорошо, а так - средне 🙂

2. Multivox Dicom Viewer - http://www.multivox.ru/free_viewer.shtml

Совершенно бесплатно 🙂 Русский изначально. Интерфейс — яд! Студенты писали, не иначе.
А вот тут пожалуйста, тот же Пакс подключен с пол-тычка!
Регулирование яркости/контрастности — жесть, ползунками «Уровень» и «Ширина» 🙂 Хотя, соврал, мышкой тоже можно, не сразу дошло, что не левую,
а правую кнопку нажимать нужно 🙂 А вот увеличить/уменьшить — через меню «Преобразование геометрии».Очень неудобно.
Просто дайком файлы не читает, только дайкомдир. А файлы через изврат «Импорт из папки», но читает папку и предлагает отметить галками, что
загрузить на просмотр. Впрочем вроде бы и неплохо.

Теги кириллические понимает.
Экспорт во всякие графические форматы есть.
Куча всяческих непонятных измерений распределений и всякой чуши, которая врачам, думаю и на хрен не нужна.
Интерфейс неудобный, просто убивает все желание дальше с ним возиться. Если убрать «Панель управления», то еще как-то можно смотреть более спокойно.
В общем впечатления не очень. Единственное, что порадовало — чтение из Пакса.

Экспорта на СД нету.

3. Weasis portable https://sourceforge.net/projects/dcm4che/files/Weasis/
Подключения к удаленному хранилищу нет.
Кириллицу, не соответствующую стандарту (а win1251 такая и есть) не понимает.
Сделаю здесь отступление небольшое. Наши отечественные производители ПО для цифровой рентгенологии почему-то в большинстве своем пишут в дайкомы именно эту кодировку, хотя стандарт ее не поддерживает совершенно. Ее не понимают ни Паксы, ни вьюверы, которые считают, что кодировка должна быть стандартной и записываться в соответствующий тег. Но у нас в этот тег, что только не пишут иногда. А иногда и тег вообще не пишут.
Поэтому мне пришлось, чтобы Пакс понимал текстовые теги правильно, а вьювер отображал, написать специально программку для перекодирования тегов. Но, как мы видели выше, некоторые  «писатели» вьюверов знают об этой  «слабости» «писателей» дайкомов к виндовой кодировке и отображают ее правильно.
Интерфейс простой, мне понравился. Цветовая схема настраивается.
Русский язык также есть в настройках.
Локальные дайкомы читает без проблем. Инструменты стандартные, управлять легко, только привыкнуть переключаться между разными функциями кнопок мыши. Несколько «подтормаживает» изменение яркости/контрастности, не моментальное. И для существенного изменения нужно мышу  есколько раз гонять. Увеличение/уменьшение можно и колесиком производить. И вообще функции кнопок мыши и колесика легко настраиваются как вам
заблагорассудится. Класс!
Экспорты в разные форматы есть. Всяческие измерения, рисования и т. д. И т. п., много всего. Из особенного: есть дайком-печать, чего у предыдущих вьюверов не было. В общем мне понравилось. И БЕСПЛАТНО!

4. S ynedra Viewers Personal, http://www.synedra.com/en/downloads/download-purchase-viewer
Бесплатно. Есть и платные версии. Отличаются от бесплатной возможностью записи на СД, возможностью отправки снимков в Пакс и еще кучей наверное полезных вещей. Меня же больше интересуют простые базовые функции и бесплатно 🙂
Русский «искаропки».
С чтением из Паксов та же лажа, что и у Радианта, один в один. Не прочитал файлы с сетевого диска, только после переноса на локальный!
Кириллица распознается только стандартная для дайкома, виндовая отображается неправильно.

Вообще вьювер солидно смотрится, много всяких фич, часто не нужных.
Если бы Пакс подключился сразу, цены б ему не было. Будем разбираться...
Инструментами пользоваться достаточно удобно. Экспорт в jpeg есть. На СД — нет.
Еще из полезного — можно анонимизировать дайком. Было бы очень полезно в связке с возможностью отправки, но она только в платной (27 Е)
версии.
Если сравнивать с платным Радиантом, то я бы синедру выбрал :).

 

5. Sante Dicom Vuewer Free http://www.santesoft.com/downloads.html
Греческая разработка, неплохой сайт с множеством бесплатных утилит.
Но православные греки могли бы русское меню сделать. Так нет же — только английский, хорошо хоть не греческий. Кириллица распознается и виндовая, и стандартная.
Инструменты все есть, но управлять ими не очень удобно, как для меня. Неадекватный какой-то дерганный зум. Такая же регулировка яркости.
Повороты — из меню, «быстрых» кнопок нет. То же и для инверсии. Чтобы посмотреть теги, нужно выбрать файл в диалоге. Для текущего
изображения почему-то нет такой возможности.
Меню обширное, но разбираться с ним не было желания. Куча масок и фильтров для обработки, но с этим нужно долго и нудно разбираться, а нужно
ли?
Интерфейс вроде бы и симпатичный, но не очень удобный. Впрочем, кому-то может и понравится.

6. Inobitec Dicom Viewer 1.8.0 http://www.inobitec.com/download
Платный. Цена не указана, нужно связываться с разработчиком.

Ставил под убунтой и под виндой. Под убунтой сразу не пошло. Поддержка активная работает. Получилось.
Почти без проблем подключил локальный и удаленный серверы. На конквесте и на дцм4.
Кириллицу понимает только стандартную, виндовая не катит. В конквесте (под виндой) список пациентов выводится крокозябрами.
Инструменты почти все на месте, работают достаточно неплохо. Нет лупы почему-то. Иногда очень полезный инструмент. Не путать с зумом!
Интерфейс неплохо оформлен, ненавязчив. Три темы оформления, мне понравилась по умолчанию серая.
Есть функции печати, в т.ч. и дайком-печати.
Все неплохо. Но от платного инструмента хотелось бы ещё большего, например, отправки в Пакс 🙂

 

7. SonicDICOM Media Viewer https://sonicdicom.com/download/
Оригинальное решение. Вьювер работает в браузере. Рассчитан на работу со своим Паксом, который платный (там же скачать можно его триал) Инсталляции не требует. Распаковать и запустить. Можно открыть или папку с отдельными файлами или dicomdir. Запускается и в браузере выводит
список пациентов, чьи снимки находятся в папке. Кириллица стандартная отображается нормально, виндовая не понимается.
Выбраный снимок открывается в новой вкладке.
Интерфейс английский, но почти все интуитивно понятно, мне во всяком случае.
Никаких экспортов, печатей и т. д. Посмотреть, измерять и все. Но во многих случаях вполне достаточно.

 

8. Orpalis Dicom Viewer Free http://www.orpalis.com/labs/dicom-viewer/
Зря только ставил. Полный бред.
Во-первых, инструментов практически нет, кроме самых простых — яркость/зум Во-вторых, русские теги читает правильно, но виндовые, а те, которые,
наоборот, стандартные — нет.
Ну и глючит на каждом втором-третьем снимке. Я так понимаю, не может какие-то теги обработать.
Не советую вообще.

9. MicroDicom http://www.microdicom.com/downloads.html
Достаточно симпатичный вьювер. Портит его отсутствие русского интерфейса 🙂 Кириллицу понимает стандартную.
Читает локальные папки/файлы.
Инструменты стандартные все есть, кроме лупы.
Зум немного «дерганный», не плавный. А уровень яркости, наоборот, сильно плавный, устанешь мышей елозить по столу 🙂
Экспорты, измерения, печать на обычный принтер и т. д.
Сильно не впечатлил, но совсем неплохо.

10. Millensys Viewer Free http://www.millensys.com/downloads.html
Бесплатный.
Можно открывать снимки и смотреть. Ну и все. Инструменты стандартные есть, интерфейс простой, но английский весь. Кириллицы нет и близко нигде. Даже в тегах не отображается вообще ничего, просто игнорируются, даже закорючки не выводит.
Один файл. Никакой инсталляции. Просто глянуть. Постоянно работать — вряд ли.

11. Dicompass http://www.dicompass.cz/download/
Платный. Чехи хотят за него 4,5 тысячи своих крон, а это почти 190 американских долларов. Вот такие, блин, алчные.
Требует предварительной установки Java. И устанавливает ... 7-ю, хотя уже давно 8-я есть.
Интерфейс русский «искаропки», ну чехи.., что скажешь 😉
Читает из Пакса, правда, настройки соединения совсем не очевидны, но разобраться можно.
Кириллица стандартная понимается, виндовая нет. В тегах имеется в виду.
Лупы моей любимой нет. Все остальные инструменты есть, работают неплохо. Печать на принтер есть. На дайком тоже, но настройка опций опять же не
очень понятна.
Но я не вижу за что 200 баксов платить! Где правка тегов и сохранение в паксе? За такие деньги должно быть! Я так считаю 🙂

20.03.2016
(С) Александр Кузнецов
alexandr.v.kuznetsov1@gmail.com

 

01.05.2016 Статьи

Как просмотреть снимок с сервера dcm4chee версии 2.х

Инструкция
по работе с тестовым Dicom-сервером
Представляемый Dicom-сервер предназначен для хранения рентгеновских изображений, сохраненных в формате dicom, и их просмотра на любом компьютере, подключенном к сети интернет, с любой операционной системой с помощью загружаемого вместе с изображением вьювера.

Предполагается, что пользователь имеет свой аккаунт на сервере (логин/пароль). Предполагается также, что его аккаунт позволяет просматривать рентгеновские изображения, полученные хотя бы из одного источника.

Ввести свои логин и пароль


В появившемся окне можно задать критерии поиска изображения (по дате получения, по источнику, по ИД пациента и т. д.)

Нажать кнопку «Search». Будет выведен список рентгеновских изображений, соответствующий критериям поиска. Если критерии не вводились, то все.

Для просмотра выбранного изображения необходимо нажать на пиктограмму «глаз» с правой стороны экрана в соответствующей строке:

В случае, если на вашем компьютере не установлено приложение Java Web Start Launcher, Вы увидите следующий экран, который говорит что браузер не знает, каким приложением открыть загружаемый файл:

В этом случае необходимо установить нужное приложение. Заходим на сайт java.com и скачиваем установщик. Устанавливаем приложение и, возможно понадобится перезапуск браузера.

 

 

После перезапуска браузера снова заходим на веб-интерфейс сервера, авторизуемся, выбираем изображение и нажимаем на пиктограмму «глаз» 🙂

Теперь по нажатию на кнопку «Ок» загружаемый файл будет открыт в нужном нам приложении.
Далее необходимо подтвердить выполнение:

Начнется загрузка вьювера и снимков:

Если это первая загрузка вьювера, то интерфейс будет английским. Это легко исправить, зайдя в меню File-Preferences, где поменять язык интерфейса и тему оформления.

 

При последующих загрузках интерфейс будет русскоязычным:

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

(С) Kuznietsov Alieksandr , 2015
alexandr.v.kuznetsov1@gmail.com

Scroll to top