Что такое программа диком

В этой статье описываются основные понятия DICOM и службы DICOM.

DICOM

DICOM (Digital Imaging and Communications in Medicine) — это международный стандарт для передачи, хранения, извлечения, печати, обработки и отображения медицинской информации, а также является основным стандартом медицинской визуализации, принятым в сфере здравоохранения.

Служба DICOM

Служба DICOM — это управляемая служба в службах azure Health Data Services , которая прием и сохранение объектов DICOM с несколькими тысячами изображений в секунду. Он упрощает обмен данными изображений и их передачу с любыми системами или приложениями с поддержкой DICOMweb™ с помощью стандартных API DICOMweb, таких как Store (STOW-RS),Search (QIDO-RS) и Retrieve (WADO-RS). Он поддерживается управляемым предложением «платформа как услуга» (PaaS) в облаке с полным соответствием PHI , что позволяет отправлять данные PHI в службу DICOM и обмениваться ими через безопасные сети.

• Соответствие ТРЕБОВАНИЯМ PHI. Защитите PHI с помощью непревзойденной аналитики безопасности. Ваши данные изолированы в уникальной базе данных для каждого экземпляра API и защищены с помощью отработки отказа в нескольких регионах. Служба DICOM реализует многоуровневую, глубокую защиту и расширенную защиту от угроз для ваших данных.
• Расширенные теги запросов. Кроме того, индексируйте исследования DICOM, ряды и экземпляры как для стандартных, так и для частных тегов DICOM, расширяя список тегов, которые уже указаны в инструкции о соответствии DICOM.
• Канал изменений: доступ к упорядоченным, гарантированным, неизменяемым журналам только для чтения всех изменений, происходящих в службе DICOM. Клиентские приложения могут считывать эти журналы в любое время независимо, параллельно и в собственном темпе.
• DICOMcast. С помощью DICOMcast служба DICOM может внедрять метаданные DICOM в службу FHIR или сервер FHIR в качестве ресурса исследования изображений, что позволяет создать единый источник истины как для клинических данных, так и для метаданных изображений. Эта функция доступна как функция с открытым кодом, которая может размещаться в Azure самостоятельно. Дополнительные сведения о развертывании DICOMcast.
• Доступность по регионам. Служба DICOM имеет широкий спектр доступности во многих регионах с защитой от отработки отказа в нескольких регионах и постоянно расширяется.
• Масштабируемость. Служба DICOM изначально разработана для поддержки различных уровней рабочей нагрузки в больнице, стране или регионе и глобальном масштабе без ущерба для характеристик производительности с помощью функций автомасштабирования.
• Доступ на основе ролей: вы управляете данными. Управление доступом на основе ролей (RBAC) позволяет управлять хранением данных и доступом к ним. Обеспечивая повышенную безопасность и снижая административную нагрузку, вы определяете, кто имеет доступ к создаваемым наборам данных, на основе определений ролей, созданных для вашей среды.

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

Как работать с DICOM

Radiant DICOM viewer для 3D. Знакомлюсь с программой.

Приложения для службы DICOM

Для эффективного лечения пациентов, исследования новых методов лечения, диагностики решений или предоставления эффективного обзора истории здоровья одного пациента организации должны интегрировать данные из нескольких источников. Одной из наиболее важных интеграций является между клиническими данными и данными визуализации. Служба DICOM позволяет безопасно сохранять данные образов в облаке Майкрософт и размещать их вместе с данными EHR и Интернета вещей в одной подписке Azure.

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

• Резервное копирование изображений: научно-исследовательские учреждения, клиники, центры визуализации, ветеринарные клиники, учреждения патологии, розничные торговцы, любая команда или организация могут использовать службу DICOM для резервного копирования своих изображений с неограниченным хранением и доступом. Кроме того, нет необходимости деидифицировать данные PHI, так как наша служба проверяется на соответствие требованиям PHI.
• Обмен изображениями и совместная работа. Мгновенное предоставление общего доступа к изображениям, набору изображений в хранилище или всей библиотеке образов с соответствующими данными EHR или без нее.
• Аварийное восстановление. Высокий уровень доступности является характеристикой устойчивости службы DICOM. Высокий уровень доступности реализуется на месте (в том же регионе, что и основная служба), разрабатывая его как функцию основной системы.
• Создание когорт для исследований: Часто через запросы для пациентов, которые соответствуют данным как в клинических, так и в системах визуализации, таких как эта (что вызвало усилия по интеграции данных FHIR™ и DICOM): «Дайте мне все лекарства, предписанные со всеми документами КТ и связанные с ними отчеты радиологии для любого пациента старше 45 лет, который имел диагноз остеосаркомы в течение последних двух лет».
• Поиск результатов для аналогичных пациентов, чтобы понять варианты и планировать лечение: при предъявлении диагноза пациента врач может определить результаты и планы лечения для прошлых пациентов с аналогичным диагнозом, даже если они включают данные визуализации.
• Обеспечение продольного обзора пациента во время диагностики: радиологи, особенно телерадиологи, часто не имеют полного доступа к истории болезни пациента и связанным исследованиям изображений. Благодаря интеграции FHIR™ эти данные можно легко предоставить даже радиологам за пределами локальной сети организации.
• Закрытие цикла обратной связи с телерадиологами: в идеале радиолог имеет доступ к клиническим данным больницы, чтобы закрыть цикл обратной связи после выполнения рекомендации. Однако для телерадиологов это часто не так. Вместо этого они часто не могут закрыть цикл обратной связи после выполнения диагностики, так как у них нет доступа к данным пациентов после первоначального чтения. При отсутствии (или ограниченном) доступе к клиническим результатам или результатам они не могут получить обратную связь, необходимую для улучшения своих навыков. Как выразился один телерадиолог: «Возьмем паратиреоид, например. Мы делаем больше, чем любая другая клиника в стране или регионе, и все же я должен умолял и умолял хирургов сказать мне, что они на самом деле нашли. Из более чем 500 исследований, которые я делаю каждый месяц, я получаю прямую обратную связь только о трех или четырех». Благодаря интеграции с FHIR™ организация может легко создать инструмент, который будет предоставлять прямую обратную связь телерадиологам, помогая им оттачивать свои навыки и делать лучшие рекомендации в будущем.
• Закрытие цикла обратной связи для моделей ИИ/МАШИНного обучения: модели машинного обучения лучше всего подходят, когда для улучшения моделей можно использовать реальные отзывы. Однако сторонние поставщики моделей машинного обучения редко получают отзывы, необходимые для улучшения своих моделей с течением времени. Например, один isV выразился так: «Мы используем сочетание машинных моделей и человеческих экспертов, чтобы рекомендовать план лечения для хирургии сердца. Тем не менее, мы лишь редко получаем отзывы от врачей о том, насколько точным был наш план. Например, мы часто рекомендуем размер стентов. Мы хотели бы получить отзыв о том, был ли наш прогноз правильным, но единственный раз, когда мы слышим от клиентов, это когда есть серьезная проблема с нашими рекомендациями». Как и в случае с отзывами телерадиологов, интеграция с FHIR™ позволяет организациям создать механизм предоставления обратной связи для конвейера переобучения модели.

Развертывание службы DICOM в Azure

Службе DICOM требуется подписка Azure для настройки и запуска необходимых компонентов. Эти компоненты по умолчанию создаются в существующей или новой группе ресурсов Azure для упрощения управления. Кроме того, требуется учетная запись Azure Active Directory. Для каждого экземпляра службы DICOM мы создаем сочетание изолированного и мультитенантного ресурса.

Сервер DICOM

Сервер медицинской визуализации для DICOM (далее называется сервером DICOM) — это открытый код сервер DICOM, который легко развертывается в Azure. Он обеспечивает связь на основе стандартов с любыми системами с поддержкой DICOMweb™ и внедряет метаданные DICOM на сервер FHIR, чтобы создать целостное представление данных пациентов. См. раздел Сервер DICOM.

Сводка

В этой концептуальной статье представлен обзор DICOM и службы DICOM.

Дальнейшие действия

Чтобы приступить к работе со службой DICOM, см. раздел

Дополнительные сведения об использовании API-интерфейсов DICOMweb™ Standard со службой DICOM см. в статье.

FHIR® является зарегистрированным товарным знаком HL7 и используется с разрешения HL7.

Источник: learn.microsoft.com

Что такое программа диком

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

В настоящее время в мире используются различные медицинские коммуникационные стандарты: HL7, IEEE/Medix, X12, ASTM, NCPDP и другие [1]. Они охватывают широких круг задач, от интерфейса с лабораторным оборудованием до обмена информацией между отдельными клиниками.

Для обеспечения взаимной совместимости этих стандартов при комитете HISPP (Health Informatics Standards Planning Panel) ANSI был создан подкомитет MSDS (Message Standards Developers Subcommittee). Область медицинской коммуникации была разделена на функциональные задачи, каждой из которых стала заниматься своя рабочая группа, представляющая комитеты по соответствующим стандартам: модель данных – IEEE/Medix, межорганизационный обмен – X12N, внутриорганизационная администрация и заключения – HL7, клинические результаты – ASTM, фармакология – NCPDP, изображения – ACR/NEMA (American College of Radiology / National Electrical Manufactures Association). Для минимального изменения существующих стандартов предполагается на основе общей модели данных специфицировать области, в которых предпочтительно использовать тот или иной стандарт. Так стандарт HL7 предполагается использовать для обеспечения интерактивного обмена данными в госпитальной инфраструктуре, X12 – для работы с медицинской информацией по коммутируемым линиям. В настоящее время ASTM и HL7 уже имеют общий формат для клинических данных, а X12N разрабатывает формат включения сообщений HL7 для внедрения детальных клинических данных в формат X12.

Для передачи изображений наиболее широко используется стандарт DICOM (Digital Imaging and Communications in Medicine), разработанный Американской коллегией радиологии и Национальной ассоциацией производителей электроники (ACR/NEMA). Кроме того, другие коммуникационные стандарты (HL7, X12) используют формат стандарта DICOM для передачи изображений.

1. Возможности стандарта DICOM

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

На основе стандарта DICOM и типовых сетевых решений, как один из вариантов, рекомендуется 3–х уровневое интеграционное решение, изображенное на рис 1.

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

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

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

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

Остановимся на следующих моментах интеграции – ввод, передача, визуализация и архивация.

1.1. Ввод

• непосредственная оцифровка изображения (компьютерное радиографическое оборудование);
• реконструкция изображения по отсчетам (КТ, ЯМР, УЗИ оборудование);
• оцифровка аналогового видеосигнала с выхода медицинского оборудования.

1.2. Передача

Для организации передачи данных во внутренней инфраструктуре отделения на основе локальной сети (LAN) предпочтительно использование Ehternet, или более высокоскоростные технологии (Fast Ehternet, ATM, FDDI). Применение в стандарте модели ISO/OSI и протокола TCP/IP обеспечивает подключение практически любых типов платформ: DOS/Windows, Unix, Mac, и т.д.

При соединении удаленных клиник и исследовательских центров через глобальные сети (WAN) ключевыми моментами являются скорость и стоимость. Всеобщее распространение Internet позволяет организовать передачу данных практически в любую точку планеты и добиться требуемого соотношения цена/скорость посредством выбора способа доступа (модем, коммутируемые линии, прямое подключение).

1.3. Визуализация.

• для первичной диагностики необходимо применение дисплеев с наиболее высоким разрешением (более 1600х1200), здесь оправдано применение рабочих станций с 8–12 битным цветом и диагональю монитора не менее 17–21”.
• в палатах интенсивной терапии и отделении неотложной помощи – недорогие рабочие станции с разрешением монитора не менее 1024х768.
• при анализе изображений совместно с КТ и ЯМР–системами требуются мощные графические станции, обеспечивающие 3–х мерную визуализацию, видео и постобработку изображений.
• для простого просмотра изображений допустимо применение простых терминалов, на базе недорогих ПК.

1.4. Архивация.

• На первом уровне целесообразен краткосрочный (порядка недели) архив на базе RAID (Redundant Array of Inexpensive Disks), обеспечивающий быстрый доступ к хранимым данным;
• На втором уровне – кластерный архив. Один кластер может удовлетворять несколько месяцев потребности в хранении для малых групп, а множество кластеров – всего отделения;
• И третьим уровнем располагается долгосрочный архив. Например, на основе технологии записываемых оптических дисков или магнитооптики, которые имеют сроки хранения до 30–50 лет.

2. Стандарт DICOM версии 3.0

2.1 История создания.

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

Первая версия стандарта была опубликована в 1985 году [2]. Она определяла аппаратный интерфейс, минимальный набор команд, правила кодирования и передачи данных, и была применима только для среды с выделенным каналом – для операций в сетевом окружении требовался интерфейсный модуль. В 1988 году вышла версия 2.0 [3], которая уже включала командную поддержку дисплейных устройств, вводила новую иерархическую схему для идентификации изображений и дополняла элементы данных для более детального описания изображений.

2.2 Содержание стандарта.

• информационные объекты;
• концепцию сервисных классов для работы c информационными объектами;
• структуру сообщений, форматы команд и данных, сервис передачи сообщений DIMSE (DICOM Message Service Element);
• взаимодействие с моделью OSI и используемые протоколы;
• интерфейс с медицинским оборудованием.

DICOM v3.0 имеет технологию для уникальной идентификации любой информации при сетевом взаимодействии, а также применяет сжатие изображений по стандарту JPEG [8]. Далее в статье описана третья версия стандарта.

2.2.1 Информационные объекты.

• семантика описания;
• информация, включаемая в IOD;
• атрибуты для описания характеристик.

Предопределено множество необходимых типов объектов: пациент, визит, исследование, результаты, компьютерная радиография и томография, ядерный магнитный резонанс, ультразвук, стороннее изображение, параметры оборудования, отображение на дисплее или принтере и т.д. Модель взаимосвязи IODs показана на рис.2.

2.2.2 Сервисные классы.

• семантика описания его состояния;
• взаимоотношение с IODs;
• группа операций сервиса DIMSE;
• поддерживаемые SOP классы.

В стандарте SOP–классы подразделяются на нормализованные и смешанные. Нормализованные классы предназначены для выполнения операций над конкретным IOD, в то время как смешанные – над логически связанным набором разнотипных IODs.

2.2.3 Структура сообщений, форматы команд и данных, сервис передачи сообщений DIMSE (DICOM Message Service Element).

• Тег – уникальный идентификатор элемента, состоящий из пары 16-битных слов, определяющих номер группы и номер элемента. Пользователь может вводить свои собственные теги, передавая их для согласования соответствующему сервису.
• Поле типа данных (VR) – 2-х символьная строка, содержащая аббревиатуру типа данных. Наряду с классическими типами (целыми, вещественными, строковыми и текстовыми), вводятся специфические типы для времени, возраста, имени, уникальных идентификаторов и т.д. Определенный тип элементов может содержать в своем поле данных другие элементы. Поле типа является необязательным, и при его отсутствии тип данных определяется по тегу.
• Поле длины – в зависимости от типа 16– или 32–битное беззнаковое слово, содержащее число байт в поле данных;
• Поле данных – передаваемые атрибуты IOD.

1. элементы передаются без поля типа данных (тип данных определяется по тегу), в словах (тег, длина, данные двоичного типа) сначала передаются младшие байты;
2. присутствует поле типа данных, сначала передаются младшие байты;
3. присутствует поле типа данных, сначала передаются старшие байты.

Команды служат для спецификации выполняемых операций и установления соединения. Последовательность команд строится из командных элементов, определяемых протоколом элемента DIMSE, аналогично последовательности данных. Командные элементы не имеют поля типа (VR) и передаются в порядке увеличения номера тега, сначала идут младшие байты.

В стандарте зарегистрированы все элементы DICOM–сообщений и уникальные идентификаторы для синтаксиса передачи и SOP–классов. Для элементов определены теги, типы данных и список предопределенных значений (если необходим).

• процедуры и правила кодирования сообщений;
• сервисные примитивы (запроса, ответа, отображения, подтверждения);
• поддержку коммуникаций между пользователями (как в синхронном, так и в асинхронном режиме);
• сервисы согласования и исполнения (сохранение, перемещение и поиск информации).

2.2.4 Взаимодействие с моделью OSI и используемые протоколы.

• стек протоколов удовлетворяющий спецификации ISO/OSI;
• протокол верхнего уровня для TCP/IP, обеспечивающий необходимый сервис и функции стека OSI;
• стек протокола с выделенным соединением, для совместимости с предыдущими версиями стандарта.

2.2.5. Интерфейс с медицинским оборудованием.

В стандарте определен коммуникационный протокол с выделенным соединением на основе семиуровневой модели ISO/OSI. Он выделяет 3 уровня, перекрывающие модель OSI: физический, канальный и сессии/транспорта/сети (STN) уровни. На физическом уровне данный протокол использует свой собственный 50–ти жильный кабель.

Для него определены управляющие сигналы, прерывания, диаграммы состояния, временные параметры и нумерация контактов. На канальном уровне поддерживаются потоки данных, он также следит за статусом интерфейса и ошибками. На уровне STN поддерживаются виртуальные каналы и конвейеризация сообщений по интерфейсу. C введением в DICOM v3.0 поддержки модели OSI и протокола TCP/IP данный интерфейс утратил свою актуальность и используется для подключения DICOM–оборудования 1 и 2 версий стандарта.

2.3 Дополнения к стандарту.

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

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

DICOM поддерживает различные форматы физических носителей: дискеты 1.44М, магнитооптические диски емкостью 128М, 650М и 1.2G, а также 120мм записываемые оптические диски (CD–R). В качестве файловой системы используется FAT, совместимая с DOS версии 4.0 и выше.

3. Результаты

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

Основные свойства ООП – инкапсуляция, наследование и полиморфизм, обеспечивают большую структурированность и абстрактность, чем традиционное программирование, и хорошо вписываются в стандарт DICOM. Вся входящая и выходящая информация представляется в виде потоков, что обеспечивает должный уровень абстрагирования от способа получения информации (из сети, с локального диска или оборудования).

Минимальной единицей информации в стандарте являются элементы данных, которые реализуют различные типы данных DICOM – текстовые, строковые, двоичные и др. Они реализованы полиморфно и происходят от одного предка, который “умеет” только читать и записывать данные в поток, а также проверять правильность своих данных. Из этих минимальных объектов строятся более крупные – IODs. Они также реализованы полиморфно, т.е. являются наследниками от абстрактного IOD, который уже “умеет” высокоуровнево читать и записывать данные в поток, отображать и вводить данные, и т.д. Наследование позволяет легко расширять функциональность стандартных объектов DICOM и вводить собственные специфичные классы объектов.

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

На основе принципов ООП выполнен “словарь” данных (специфицированный в части 6 – Data Dictionry стандарта), являющийся неотъемлемой частью любого ПО для работы с DICOM и позволяющий обеспечить кодирование / декодирование содержимого файлов или сообщений в формате стандарта. Словарь имеет следующие методы – поиск по заданному тегу названия, типа данных, числа возможных значений, предопределенных значений для DICOM–элемента, он также поддерживает добавление новых элементов.

В соответствии с требованиями стандарта реализован DICOM–сервис верхнего уровня для протокола TCP/IP на основе стека РС/ТСР 3.0 для DOS фирмы FTP Software. Ведется перенос данного сервиса на базе спецификации WinSocket в среду Windows.

Создано ПО (для среды DOS) редактирования и просмотра файлов в формате DICOM c простым графическим интерфейсом, работающее как в реальном, так и в защищенном (DPMI) режиме. Частично данное ПО реализовано и для Windows.

Для обеспечения независимости от конкретной платформы ведется работа по переносу технологии работы с DICOM–информацией на язык Java.

4. Выводы.

Появившись как корпоративный, DICOM стал стандартом де-факто и встраивается в оборудование (КТ, ЯМР, УЗИ и т.д.) крупнейших производителей радиологического оборудования (PICKER, GE, Siemens, HP, Philips) и большинство систем архивации медицинских изображений. Он поддерживается национальными организациями по стандартам — CEN TC251 в Европе и JIRA в Японии.

Совершенно очевидно, что на сегодняшний день DICOM является хорошо проработанным стандартом, на который имеет смысл ориентироваться российским разработчикам. Начиная с создания простейших DICOM–конверторов, а также серверов архивации и печати, постепенно переходя к полноценным DICOM–решениям. Работы в этом направлении ведутся в Московском Государственном Институте Электронной Техники.

5. Литература:

[1] Jeffrey S.Blair. The Biomedical Engineering handbook, 1995,стр. 2650-2659.
[2] American College of Radiology, National Electrical Manufacturers Association, «ACR-NEMA Digital Imaging and Communications Standard», NEMA Standards Publication No. 300-1985, Washington, DC, 1985.
[3] American College of Radiology, National Electrical Manufacturers Association, «ACR-NEMA Digital Imaging and Communications Standard: Version 2.0», NEMA Standards Publication No. 300-1988, Washington, DC, 1988.
[4] American College of Radiology, National Electrical Manufacturers Association, «Digital Imaging and Communications in Medicine (DICOM): Version 3.0», Draft Standard, ACR-NEMA Committee, Working Group VI, Washington, DC, 1993.
[5] ISO 7498, Information Processing Systems, OSI, Basic Reference Model.
[6] RFC 791, Internet Protocol, DAPRA Internet Protocol Specification.
[7] RFC 793, Transmission Control Protocol, DAPRA Internet Protocol Specification.
[8] ISO/IS 10918-1(2), JPEG Standart for digital compression and encoding of continuous-tone still image.

Источник: mks.ru

postDICOM — Free DICOM Viewer

postDICOM — это облачный DICOM Viewer и программа просмотра клинических документов.

postDICOM.com — это облачный DICOM и программа просмотра клинических документов. Вы можете загружать файлы DICOM и клинические документы, используя веб-браузеры. Более того, вы можете отправлять файлы DICOM с ваших устройств обработки изображений и PACS viewer / client, используя протокол DICOM C-STORE.

Файлы DICOM и клинические документы хранятся на наших серверах и передаются в ваш браузер с помощью нашего сложного средства просмотра HTML5 DICOM с минимальными размерами. Вы можете загружать и просматривать файлы DICOM с настольных ПК (Windows XP, 7, 8, 8.1, 10, MacOS и Linux), планшетов (Windows, IOS и Android) и смартфонов (IOS и Android) где угодно и когда угодно. Мы предоставляем бесплатное медицинское хранилище объемом 50 ГБ, и вы можете использовать нашу систему в качестве облачной онлайн-бесплатной программы просмотра DICOM.

Источник: progsoft.net