Метка: 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.02.2022 Программа Dicom AutoExport

Dicom AutoExport 1.9.3

Как всегда, поводом для разработки новой версии стал опыт применения программы, как собственный, так и пользователей.

Программа Dicom AutoExport предназначена для:

  • обработки рентгеновских изображений в формате dicom (расширения файлов .dcm, .dic или без расширения), которые были созданы программами получения рентгеновских снимков*, с целью устранения ошибок совместимости примененных кириллических кодировок (в основном win1251) со стандартом Dicom 3.0;
  • добавления/удаления/редактирования «на лету» элементов (dicom-тегов);
  • сохранения обработанного файла в заданной папке экспорта;
  • отправки обработанных изображений на стандартный dicom-сервер, возможна отправка и исходных файлов без обработки, если они соответствуют стандарту.

Все перечисленные операции выполняются автоматически в фоновом режиме.

*Примечание. Возможна обработка не только рентгеновских изображений, но и других файлов, имеющих формат dicom, например, результаты исследований УЗИ, ЭКГ, ангиографии, томографии, маммографии и т.п.
При запуске Программа сворачивает свое окно в область задач или область уведомлений ("трей") и “наблюдает” за заданной папкой. При появлении в ней нового dicom-файла снимка, последний копируется в рабочую папку Программы и обрабатывается. При успешности обработки снимок отправляется на заданный dicom-сервер.

Что нового в версии 1.9.3?

Добавлена опция фильтрации файлов в папке импорта по имени файла (или фрагменту имени). Причина? Столкнулся лично с рентгеновским аппаратом китайского производства типа Titan 2000 и как-то там ещё дальше. Работает в качестве флюрика. Снимки неплохие, достаточно надежен, судя по отзывам персонала. При организации экспорта на сервер выяснилось, что программа аппарата сохраняет в папку снимков сразу три dicom-файла, два из которых потом удаляются, а третий переименовывается. Причем отфильтровать ни по расширению, ни по размеру нельзя. Пришлось на ходу дописывать опцию, чтобы игнорировать эти временные файлы по имени.

Так появилась версия 1.9.2, но до публикации её дело не дошло. Было установлено лишь несколько экземпляров. Пришлось внести ещё некоторые изменения и опции, которые и вошли уже в представленную 1.9.3.

Добавлена опция конвертации кодировки отдельно для элементов Code String. Причина в том, что на эти элементы не распространяется установка типа кодировки в элементе (0008,0005). Подробнее здесь: Кодировка dicom-элементов типа Code String

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

Добавлена возможность просмотреть историю полученных и отправленных файлов.

Подчищены некоторые процедуры и функции по мелочам.  Изменил логирование.

Всё описал в инструкции, которую можно скачать по ссылке ниже.

Ссылка для скачивания программы инсталляции: Dicom AutoExport setup v.1.9.3

Для обновления с версий 1.9.x (для тех, у кого уже установлена программа): Update to ver. 1.9.3

Скачать  инструкцию: Manual DicomAutoExport v.1.9.3

Manual_DicomAutoExport_v.1.9.3-2
02.11.2021 Reference materials, Разработка

Типы данных в DICOM

Представление значения (VR) элемента данных описывает тип данных и формат значений этого элемента данных. PS3.6 перечисляет VR каждого элемента данных по тегу элемента данных.

Значения с VR, состоящими из строк символов, за исключением случая пользовательского интерфейса VR, должны быть дополнены символами ПРОБЕЛА (20H, в наборе символов по умолчанию), когда это необходимо для достижения четной длины. Значения с VR пользовательского интерфейса должны быть дополнены одним конечным символом NULL (00H), когда это необходимо для достижения четной длины. Значения с VR, равным OB, должны быть дополнены одним конечным значением NULL-байта (00H), когда это необходимо для достижения четной длины.

Все новые VR, определенные в будущих версиях DICOM, должны иметь ту же структуру элементов данных, как определено в разделе 7.1.2, с зарезервированными байтами после VR и 32-битным целым числом без знака (т. е. в соответствии с форматом для VR, например OB или UT), и может разрешать или не разрешать неопределенную длину.

В таблице 6.2-1 длины представлений значений, для которых набор символов может быть расширен или заменен, явно указаны в символах, а не в байтах. Это связано с тем, что сопоставление символа с количеством байтов, используемых для кодирования этого символа, может зависеть от используемого набора символов.

Тип Описание Набор символов Длина
AE

Application Entity

 Строка символов, идентифицирующая объект приложения, причем начальные и конечные пробелы (20H) не имеют значения. Значение, состоящее исключительно из пробелов, не должно использоваться. Набор символов по умолчанию, за исключением кода символа 5CH (обратная косая черта «\» в ISO-IR 6) и всех управляющих символов. максимум 16 байт
AS

Age String

 Строка символов одного из следующих форматов — nnnD, nnnW, nnnM, nnnY;  где nnn должно содержать количество дней для D, недель для W, месяцев для M или лет для Y.

Пример: «018M» будет обозначать возраст 18 месяцев.

 "0"-"9", "D", "W", "M", "Y"

 

 4 байта фиксировано
CS

Code String

 Строка символов, идентифицирующая контролируемую концепцию.  Ведущие или конечные пробелы (20H) не имеют значения.

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

 Символы верхнего регистра, «0»–«9», символ ПРОБЕЛ и подчеркивание «_» из набора символов по умолчанию.

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 максимум 16 байт

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
DA

Date

 Строка символов формата ГГГГММДД;  где ГГГГ содержит год, ММ содержит месяц, а ДД содержит день, интерпретируемый как дата григорианской календарной системы.
Пример:
«19930822» будет означать 22 августа 1993 года.ПримечаниеСтандарт ACR-NEMA 300 (предшественник DICOM) поддерживал строку символов формата ГГГГ.ММ.ДД для этого VR.  Использование этого формата не соответствует требованиям.
См. также DT VR в этой таблице.
Даты до 1582 года, например, используемые для датирования исторических или археологических предметов, интерпретируются как предварительные даты по григорианскому календарю, если не указано иное.В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧЕК, представляющая пустое значение ключа.		 «0»–«9» из репертуара персонажей по умолчанию.

В контексте запроса с сопоставлением диапазона (см. PS3.4) допускается использование символа «-», а для заполнения допускается завершающий символ ПРОБЕЛ.

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ..

 8 байт фиксировано

В контексте запроса с сопоставлением диапазона (см. PS3.4) длина составляет максимум 18 байт.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
DS

Decimal String

 Строка символов, представляющая либо число с фиксированной запятой, либо число с плавающей запятой.  Номер с фиксированной точкой должен содержать только символы 0–9 с необязательным начальным «+» или «-» и необязательным «.»  для обозначения десятичной точки.  Число с плавающей запятой должно передаваться, как определено в ANSI X3.9, с буквой «E» или «e», обозначающей начало показателя степени.  Десятичные строки могут быть дополнены пробелами в начале или в конце.  Встроенные пробелы не допускаются.

Примечание
Элементы данных с несколькими значениями, использующие этот VR, могут быть неправильно закодированы, если используется синтаксис передачи Explicit-VR и VL этого элемента данных превышает 65534 байта.
 "0"-"9", "+", "-", "Е", "е", "."  и символ ПРОБЕЛ из набора символов по умолчанию.

 

 максимум 16 байт

 
DT

Date Time

 Объединенная строка символов даты и времени в формате:

YYYYMMDDHHMMSS.FFFFFF&ZZXX

Компоненты этой строки (слева направо): ГГГГ = год, ММ = месяц, ДД = день, ЧЧ = час (диапазон «00» – «23»), ММ = минуты (диапазон «00» – «59»). ), СС = Секунда (диапазон «00» – «60»).

FFFFFF = Дробная секунда содержит дробную часть секунды размером до 1 миллионной секунды (диапазон «000000» — «999999»).

&ZZXX — необязательный суффикс для смещения от всемирного координированного времени (UTC), где & = «+» или «-», а ZZ = часы и XX = минуты смещения.

Год, месяц и день интерпретируются как дата системы григорианского календаря.

Используется 24-часовой формат времени.  Полночь должна обозначаться только цифрой «0000», поскольку «2400» нарушает часовой диапазон.

Компонент дробной секунды, если он присутствует, должен содержать от 1 до 6 цифр.  Если дробная секунда не указана, предыдущий "."  не должны быть включены.  Суффикс смещения, если он присутствует, должен содержать 4 цифры.  Строка может быть дополнена завершающими символами ПРОБЕЛ.  Ведущие и встроенные пробелы не допускаются.

Компонент, который опущен в строке, называется нулевым компонентом.  Завершающие нулевые компоненты Date Time указывают на то, что значение не соответствует точности этих компонентов.  Компонент YYYY не должен быть нулевым.  Неконечные нулевые компоненты запрещены.  Необязательный суффикс не считается компонентом.

Значение даты и времени без необязательного суффикса интерпретируется как находящееся в местном часовом поясе приложения, создающего элемент данных, если явно не указано в параметре «Смещение часового пояса от UTC» (0008,0201).

Смещения UTC рассчитываются как «местное время минус UTC».  Смещение значения даты и времени в формате UTC должно быть +0000.

В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧОК, представляющая пустое значение ключа.

Примечание

Диапазон смещения составляет от -1200 до +1400.  Смещение восточного стандартного времени США составляет -0500.  Смещение стандартного времени Японии составляет +0900.
Использование -0000 в качестве смещения для указания местного времени в RFC 2822 не допускается.
Значение даты и времени 195308 означает август 1953 года, а не конкретный день.  Значение даты и времени 19530827111300,0 означает 27 августа 1953 года, 11:13 утра с точностью до 1/10 секунды.
Второй компонент может иметь значение 60 только для дополнительной секунды.
Смещение может быть включено независимо от нулевых компонентов;  например, 2007-0500 является допустимым значением.

 "0"-"9", "+", "-", "." и символ ПРОБЕЛ из набора символов по умолчанию.

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 максимум 26 байт

В контексте запроса с сопоставлением диапазона (см. PS3.4) длина составляет максимум 54 байта.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
IS

Integer String

 Строка символов, представляющая целое число по основанию 10 (десятичное), должна содержать только символы 0–9 с необязательным начальным знаком «+» или «-».  Оно может быть дополнено начальными и/или конечными пробелами.  Встроенные пробелы не допускаются.

Представленное целое число n должно находиться в диапазоне:

-231<= n <= (231-1).

 «0»-»9», «+», «-» и символ ПРОБЕЛ из набора символов по умолчанию. максимум 12 байт
LO

Long String

 Строка символов, которая может быть дополнена начальными и/или конечными пробелами.  Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями в многозначных элементах данных.  В строке не должно быть управляющих символов, за исключением ESC. Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022]. Максимум 64 символа (см. примечание в разделе 6.2)
LT

Long Text

 Строка символов, которая может содержать один или несколько абзацев.  Он может содержать набор графических символов и управляющие символы, CR, LF, FF и ESC.  Он может быть дополнен конечными пробелами, которые можно игнорировать, но ведущие пробелы считаются значимыми.  Элементы данных с этим VR не должны быть многозначными, поэтому можно использовать код символа 5CH (обратная косая черта "\" в ISO-IR 6). Набор символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]). Максимум 10240 символов (см. примечание в разделе 6.2).
PN

Person Name

 Строка символов, закодированная с использованием пятикомпонентного соглашения.  Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями в многозначных элементах данных.  Строка может быть дополнена конечными пробелами.  Для использования человеком пять компонентов в порядке их появления: фамилия, имя, отчество, префикс имени, суффикс имени.

Примечание
HL7 запрещает ведущие пробелы внутри компонента;  DICOM допускает начальные и конечные пробелы и считает их незначительными.

Любой из пяти компонентов может быть пустой строкой.  Разделителем компонентов должен быть символ «^» (5EH).  Разделителей компонентов должно быть не более четырех, т. е. их не должно быть после последнего компонента, если присутствуют все компоненты.  Разделители необходимы для внутренних нулевых компонентов.  Завершающие нулевые компоненты и их разделители могут быть опущены.  В каждом компоненте разрешено несколько записей, которые кодируются как естественные текстовые строки в формате, предпочитаемом указанным лицом.

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

Эта группа из пяти компонентов называется группой компонентов «Имя человека».

Для написания названий идеографическими и фонетическими знаками допускается использовать до 3 групп компонентов (см. Приложение H, Приложение I и Приложение J).  Разделителем групп компонентов должен быть символ равенства "=" (3DH).  Разделителей групп компонентов должно быть не более двух, т. е. их не должно быть после последней группы компонентов, если присутствуют все группы компонентов.  Три группы компонентов в порядке их появления: алфавитное представление, идеографическое представление и фонетическое представление.

Любая группа компонентов может отсутствовать, включая первую группу компонентов.  В этом случае имя человека может начинаться с одного или нескольких разделителей "=".  Разделители необходимы для внутренних нулевых групп компонентов.  Завершающие нулевые группы компонентов и их разделители могут быть опущены.

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

Примеры и примечания см. в разделе 6.2.1.1.

 Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022].

 

 Максимум 64 символа на группу компонентов

 
SH

Short String

 Строка символов, которая может быть дополнена начальными и/или конечными пробелами.  Код символа 05CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями для многозначных элементов данных.  В строке не должно быть управляющих символов, кроме ESC. Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022]. максимум 16 символов
SQ

Sequence of Items

 Значение — это последовательность из нуля или более элементов, как определено в разделе 7.5. not applicable (see Section 7.5) not applicable (see Section 7.5)
ST

Short Text

 Строка символов, которая может содержать один или несколько абзацев.  Он может содержать набор графических символов и управляющие символы, CR, LF, FF и ESC.  Он может быть дополнен конечными пробелами, которые можно игнорировать, но ведущие пробелы считаются значимыми.  Элементы данных с этим VR не должны быть многозначными, поэтому можно использовать код символа 5CH (обратная косая черта "\" в ISO-IR 6). Набор символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]). максимум 1024 символа

 
TM

Time

 Строка символов формата HHMMSS.FFFFFF;  где HH содержит часы (диапазон «00» — «23»), MM содержит минуты (диапазон «00» — «59»), SS содержит секунды (диапазон «00» — «60»), а FFFFFF содержит дробную часть секунда, равная 1 миллионной секунды (диапазон «000000» — «999999»).  Используется 24-часовой формат времени.  Полночь должна обозначаться только цифрой «0000», поскольку «2400» нарушает часовой диапазон.  Строка может быть дополнена конечными пробелами.  Ведущие и встроенные пробелы не допускаются.

Один или несколько компонентов MM, SS или FFFFFF могут быть неопределенными, если каждый компонент справа от неуказанного компонента также не указан, что указывает на то, что значение не соответствует точности этих неуказанных компонентов.

Компонент FFFFFF, если он присутствует, должен содержать от 1 до 6 цифр.  Если FFFFFF не указано, предыдущий "."  не должны быть включены.

Примеры:

«070907.0705» представляет собой время 7 часов 9 минут 7,0705 секунды.
«1010» представляет собой время 10 часов 10 минут.
«021» — недопустимое значение.Примечание
Стандарт ACR-NEMA 300 (предшественник DICOM) поддерживал строку символов формата HH:MM:SS.frac для этого VR.  Использование этого формата не соответствует требованиям.
См. также DT VR в этой таблице.
Компонент SS может иметь значение 60 только для дополнительной секунды.
В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧЕК, представляющая пустое значение ключа.

 "0–9, «.» и символ ПРОБЕЛ из набора символов по умолчанию.

В контексте запроса с сопоставлением диапазона (см. PS3.4) допускается использование символа «-».

В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 максимум 14 байт

В контексте запроса с сопоставлением диапазона (см. PS3.4) длина составляет максимум 28 байт.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
UC

Unlimited Characters

 Строка символов, которая может иметь неограниченную длину и может быть дополнена конечными пробелами.  Код символа 5CH (обратная косая черта "\" в ISO-IR 6) не должен присутствовать, поскольку он используется в качестве разделителя между значениями в многозначных элементах данных.  В строке не должно быть управляющих символов, за исключением ESC. Набор символов по умолчанию и/или как определено (0008,0005), за исключением кода символа 5CH (обратная косая черта "\" в ISO-IR 6) и всех управляющих символов, кроме ESC, когда они используются для escape-последовательностей [ISO/IEC 2022]. 232-2 bytes maximum

 
UI

Unique Identifier (UID)

 Строка символов, содержащая UID, который используется для уникальной идентификации широкого спектра элементов.  UID представляет собой серию числовых компонентов, разделенных точкой "."  . Если поле значения, содержащее один или несколько UID, имеет длину нечетного числа байтов, поле значения должно быть дополнено одним конечным нулевым символом (00H), чтобы гарантировать, что поле значения имеет длину четное количество байтов.  Полную спецификацию и примеры см. в разделе 9 и приложении B. "0"-"9", "."  набора символов по умолчанию максимум 64 байта

 
UR

Universal Resource Identifier or Universal Resource Locator (URI/URL)

 Строка символов, идентифицирующая URI или URL-адрес, как определено в [RFC3986].  Ведущие пробелы не допускаются.  Конечные пробелы игнорируются.  Элементы данных с этим VR не должны быть многозначными.

В качестве альтернативы, в контексте запроса с сопоставлением пустого значения (см. PS3.4), строка из двух символов КАВЫЧОК, представляющая пустое значение ключа.

Примечание
Допускаются как абсолютные, так и относительные URI.  Если URI является относительным, то он относится к базовому URI объекта, в котором он содержится, или к базовому URI в другом атрибуте, как указано в определении информационного объекта.
 Подмножество набора символов по умолчанию, необходимое для URI, как определено в разделе 2 IETF RFC3986, плюс символ пробела (20H), разрешенный только в качестве завершающего дополнения.

Примечание
Символ обратной косой черты (5CH) входит в число запрещенных в URI.
В контексте запроса с пустым сопоставлением значений (см. PS3.4) допускается использование символа КАВЫЧКИ.

 232-2 bytes maximum.

В контексте запроса с совпадением пустых значений (см. PS3.4) длина фиксирована в 2 байта.
UT

Unlimited Text

 Строка символов, которая может содержать один или несколько абзацев.  Он может содержать набор графических символов и управляющие символы, CR, LF, FF и ESC.  Он может быть дополнен конечными пробелами, которые можно игнорировать, но ведущие пробелы считаются значимыми.  Элементы данных с этим VR не должны быть многозначными, поэтому можно использовать код символа 5CH (обратная косая черта "\" в ISO-IR 6). Репертуар символов по умолчанию и/или как определено в (0008,0005), исключая управляющие символы, кроме TAB, LF, FF, CR (и ESC при использовании для escape-последовательностей [ISO/IEC 2022]). 232-2 bytes maximum

See Note 2

Набор данных dicom-файла (Data Set) представляет собой экземпляр информационного объекта реального мира. Набор данных состоит из элементов данных. Элементы данных содержат закодированные значения атрибутов этого объекта. Конкретное содержание и семантика этих атрибутов указаны в определениях информационных объектов (см. PS3.3).

Пиксельные данные, наложения и кривые - это элементы данных, интерпретация которых зависит от других связанных элементов.

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

Определены два типа элементов данных:

Стандартные элементы данных имеют четный номер группы, который не равен (0000, eeee), (0002, eeee), (0004, eeee) или (0006, eeee).

Элементы личных данных имеют нечетный номер группы, который не равен (0001, eeee), (0003, eeee), (0005, eeee), (0007, eeee) или (FFFF, eeee).

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

Неявные и явные элементы данных VR не должны сосуществовать в наборе данных и вложенных в него наборах данных (см. Раздел 7.5). Использует ли набор данных явный или неявный VR, помимо прочих характеристик, определяется согласованным синтаксисом передачи (см. Раздел 10 и Приложение А). VR не содержатся в элементах данных, когда используется синтаксис передачи по умолчанию DICOM (неявный синтаксис передачи с прямым порядком байтов DICOM).

Уникальные идентификаторы (UID) предоставляют возможность уникальной идентификации широкого спектра элементов. Они гарантируют уникальность в нескольких
страны, сайты, продавцы и оборудование. Различные классы объектов, экземпляры объектов и информационные объекты можно отличить друг от друга в рамках дискурса DICOM независимо от любого семантического контекста.

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

Схема идентификации UID основана на Идентификации объекта OSI (числовая форма) в соответствии со стандартом [ISO / IEC 8824]. Все уникальные идентификаторы, используемые в контексте стандарта DICOM, являются зарегистрированными значениями, как определено в [ISO / МЭК 9834-1] для обеспечения глобальной уникальности. Использование таких UID определено в различных частях стандарта DICOM.

Каждый UID состоит из двух частей: <org root> и <suffix>
Часть <org root> UID однозначно идентифицирует организацию (т.е. производителя, исследовательскую организацию, NEMA и т. д.) и состоит из ряда числовых компонентов, как определено в [ИСО / МЭК 8824]. Часть <суффикса> UID также состоит из ряда числовых компонентов и должна быть уникальной в рамках <корневого каталога org>. Это означает, что организация, указанная в <org root>, несет ответственность за гарантию уникальности <суффикса> путем предоставления политик регистрации. Эти политики должны гарантировать уникальность <суффикса> для всех идентификаторов UID, созданных этой организацией. В отличие от <org root>, который может быть общим для UID в организации, <суффикс> должен принимать разные уникальные значения между разными UID, которые идентифицируют разные объекты.

Правила кодирования DICOM UID определены следующим образом:
Каждый компонент UID является номером и должен состоять из одной или нескольких цифр. Первая цифра каждого компонента не должна быть нулевой, если компонент не является одной цифрой.
Регистрирующие органы могут распространять компоненты с незначительными начальными нулями. При кодировании начальные нули должны игнорироваться (то есть «00029» будет кодироваться как «29»).
Каждое числовое значение компонента должно быть закодировано с использованием символов 0-9 Базового набора G0 Международной справочной версии ISO 646: 1990 (набор символов DICOM по умолчанию).
Компоненты должны быть разделены знаком "." (2EH).
Если заканчивается на нечетной границе байта, за исключением случаев, когда используется для согласования сети (см. PS3.8), один завершающий NULL (00H), как символ заполнения, должен следовать за последним компонентом, чтобы выровнять UID по четной границе байта,
UID не должен превышать 64 символов.
"1.2.840.xxxxx.3.152.235.2.12.187636473"
\___________/ \______________________/
root                  .            Suffix

В этом примере корень:
1 идентифицирует ISO
2 идентифицирует тело члена ANSI
840 код страны конкретного органа-члена (США для ANSI)
xxxxx Идентифицирует конкретную организацию. (Назначается ANSI)

В этом примере первые два компонента суффикса относятся к идентификации устройства:
3 определенный производителем тип устройства
152 Серийный номер, определенный производителем
Остальные четыре компонента суффикса относятся к идентификации изображения:
235 номер исследования
2 номер серии
12 номер изображения
187636473 Кодированная дата и время получения изображения

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

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

Примечание
1. Например, в США ANSI назначает за плату идентификаторы организации для любой запрашивающей организации. Такой идентификатор может использоваться идентифицированной организацией в качестве корня, к которому он может добавить суффикс, состоящий из одного или нескольких компонентов. Указанная организация принимает на себя ответственность за правильную регистрацию этих суффиксов для обеспечения уникальности
2. Ниже приведены два типичных примера получения UID <org root>. Эти примеры не предназначены для иллюстрации всех возможных методов получения UID <org root>, см. [ИСО / МЭК 8824] и [ИСО / МЭК 9834-1] для получения полной спецификации.
Идентификаторы организации можно получить в различных органах-членах ISO (например, IBN в Бельгии, ANSI в США, AFNOR во Франции, BSI в Великобритании, DIN в Германии, COSIRA в Канаде). В первом примере показан случай <org root>, выданный органом-членом ISO (в данном примере ANSI в США).
<Org root> состоит из идентификатора ISO, идентификатора ветви тела участника, кода страны и идентификатора организации. Обратите внимание, что не требуется, чтобы реализация, использующая выданный ANSI <org root>, была сделана или находилась в США.
<Org root> состоит из следующих компонентов: 1.2.840.xxxxx
1 обозначает ISO
2 обозначает ветвь тела члена ISO
840 идентифицирует код страны конкретного органа-члена ISO (США для ANSI)
xxxxx идентифицирует конкретную организацию, зарегистрированную органом-членом ISO ANSI.
Во втором примере показан случай <org root>, выданный ISO (делегирован BSI) международной организации.
Он состоит из идентификатора ISO, идентификатора ветви международной организации и международного обозначения кода. Значение <org root> назначается международным органом регистрации, который может использоваться многими различными UID, определенными одной и той же международной организацией. <Org root> состоит из следующих компонентов:
1.3.yyyy

1 обозначает ISO
3 обозначает филиал международной организации
yyyy идентифицирует конкретную организацию, зарегистрированную международным регистрационным органом по обозначению кода (см.ISO 6523).
Примерные компоненты <суффикса> для уникальной идентификации изображения могут включать:
системный идентификатор
исследование, серия и номера изображений
изучение, серия и изображение даты и времени.

ISO 3166-1:

Украина — 804
Россия — 643
Великобритания — 826
Набор символов по умолчанию для символьных строк в DICOM - это базовый набор G0 международной справочной версии ISO 646: 1990 (ISO IR-6). Кроме того, поддерживаются управляющие символы LF, FF, CR, TAB и ESC. Эти управляющие символы являются подмножеством набора C0, определенного в ISO 646: 1990 и ISO 6429: 1990.
Байтовая кодировка набора символов по умолчанию показана в таблице E-1. Эта таблица может использоваться для получения как байтовых значений столбца / строки ISO, так и шестнадцатеричных значений для закодированных представлений

J.5 Представление значения имени человека на других языках с использованием Unicode

Имена людей на многих языках могут быть написаны локальным (не латинским) шрифтом, а также транслитерацией к латинскому шрифту (романизация). Информационные системы здравоохранения в этих средах могут поддерживать один или оба формата имен. Локальные сценарии могут быть закодированы с использованием Unicode в UTF-8.
Для целей обмена в DICOM существует три типичных использования групп компонентов имен, использующих Unicode в UTF-8:
1. Имена в латинском алфавите могут быть закодированы в первой (алфавитной) группе компонентов, а имена в локальном шрифте (алфавит, абугида или слоговый) в третьей (фонетической) группе компонентов (см. Таблицу 6.2-1). Вторая (идеографическая) группа компонентов является нулевой. Это предпочтительное использование для межфирменного или международного общения.
2. Если локальный сценарий исторически имеет однобайтовый набор символов, определенный для конкретного набора символов (0008 0005), т. Е. Кириллицы, арабского, греческого, иврита, тайского и различных версий латиницы, может использоваться только группа компонентов первого имени использоваться. Кодирование может быть в Unicode в UTF-8, как описано в этом Приложении, в качестве эквивалента для использования этого определенного однобайтового набора символов в группе компонентов первого имени (см. Примечание 1).
3. Имена в локальном скрипте могут быть закодированы в первой группе компонентов, а имена в латинском алфавите в третьей группе компонентов, оба кодируются в Unicode в UTF-8.
Примечание
1. Предыдущее издание DICOM требовало, чтобы группа компонентов имени использовала однобайтовый набор символов (см. PS3.5-2008). Юникод в UTF-8 теперь может использоваться в этой группе компонентов просто как кодировка другого набора символов, но с тем же самым прикладным использованием этой группы компонентов.
2. Информационные системы здравоохранения будут использовать конкретные сценарии в одной, двух или трех группах компонентов «Личное имя» в соответствии с местной политикой. Соответствующие прикладные программы DICOM, которые получают атрибуты имени, должны принимать несколько групп компонентов имени. Прикладная сущность, которая настраивается таким образом, чтобы разрешить использование локального сценария для имен в первой или третьей группе компонентов и сценария транслитерации в другой, будет поддерживать все эти типичные представления.
3. Транслитерация (из местного алфавита) может быть нелатинским шрифтом, например кириллицей. Применяются те же принципы, и имя с кириллицей может быть закодировано в первой группе компонентов, а локальный скрипт (который на самом деле может быть производным от латиницы) в третьей группе компонентов.

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

Scroll to top