А.В. Плотников, Д.А. Прилуцкий, С.В. Селищев.
Московский Институт Электронной Техники.
Одновременно c проникновением в медицину компьютерных технологий, стала ощущаться потребность в коммуникационных возможностях, которые позволяли бы:
Универсальные компьютерные сетевые технологии не обладают возможностями подключения различного медицинского оборудования. Поэтому его производители были вынуждены разрабатывать собственные коммуникационные интерфейсы. Однако, в связи с широким спектром используемого медицинского оборудования различных производителей, возникла необходимость в коммуникационных стандартах.
В настоящее время в мире используются различные медицинские коммуникационные стандарты: 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 для передачи изображений.
Для организации эффективной работы требуется больше, чем простое соединение оборудования через кабели. Необходимо комплексное решение по управлению всей диагностической информацией, начиная с ввода изображений и заканчивая архивацией. Стандарт DICOM позволяет решить задачи интеграции на основе открытой архитектуры. DICOM позволяет организовать не только пересылку данных по сети, но и автоматическую обработку данных. Он значительно уменьшает время подготовки и проведения исследований, управления изображениями и сопутствующей информацией. Для достижения наивысшей эффективности, он поддерживает все стадии диагностики, снижая себестоимость за счет:
На основе стандарта DICOM и типовых сетевых решений, как один из вариантов, рекомендуется 3–х уровневое интеграционное решение, изображенное на рис 1.
Первый уровень охватывает инфраструктуру отдельного отделения, например радиологического. Он связывает различное медицинское оборудование в единую систему. DICOM обеспечивает интеграцию как совместимого с ним оборудования, так и ранних моделей оборудования без коммуникационных возможностей с использованием DICOM–конверторов. Конвертор обеспечивает перевод команд и данных оборудования в формат стандарта, и наоборот. Он может реализовываться на базе универсального компьютера или специализированного микроконтроллера. Оборудование, совместимое со стандартом DICOM, просто подключается к сети. На этом уровне также располагаются различные станции диагностики и анализа. Целесообразно применения отдельного DICOM–сервера для принтера и дигитайзера (сканера).
Второй уровень управляет изображениями, охватывая несколько отделений. Администратор изображений выполняет работу по управлению подчиненными архивами. На данном уровне могут также подключаться различное оборудование и серверы.
Третий уровень служит для управления всей информацией, распределения времени использования оборудования, и т.д. Он обеспечивает выход в радиологическую информационную систему, а через нее и в госпитальную информационную систему.
Остановимся на следующих моментах интеграции – ввод, передача, визуализация и архивация.
Можно выделить следующие основные технологии для ввода изображений:
Для организации передачи данных во внутренней инфраструктуре отделения на основе локальной сети (LAN) предпочтительно использование Ehternet, или более высокоскоростные технологии (Fast Ehternet, ATM, FDDI). Применение в стандарте модели ISO/OSI и протокола TCP/IP обеспечивает подключение практически любых типов платформ: DOS/Windows, Unix, Mac, и т.д.
При соединении удаленных клиник и исследовательских центров через глобальные сети (WAN) ключевыми моментами являются скорость и стоимость. Всеобщее распространение Internet позволяет организовать передачу данных практически в любую точку планеты и добиться требуемого соотношения цена/скорость посредством выбора способа доступа (модем, коммутируемые линии, прямое подключение).
Для качественной визуализации необходим правильный выбор типа дисплейного устройства, позволяющего обеспечить требуемые качество изображения и функциональность при минимизации затрат:
В сетевой среде архив – это не просто долгосрочное хранение. Архивное решение должно иметь различные уровни хранения и статуса в терминах времени, емкости и стоимости:
В 1983 году ACR/NEMA сформировала объединенный комитет, поставив себе задачи обеспечения обмена цифровой информацией между медицинским оборудованием различных производителей, разработки принципов работы систем архивации изображений и взаимодействия с другими госпитальными системами.
Первая версия стандарта была опубликована в 1985 году [2]. Она определяла аппаратный интерфейс, минимальный набор команд, правила кодирования и передачи данных, и была применима только для среды с выделенным каналом – для операций в сетевом окружении требовался интерфейсный модуль. В 1988 году вышла версия 2.0 [3], которая уже включала командную поддержку дисплейных устройств, вводила новую иерархическую схему для идентификации изображений и дополняла элементы данных для более детального описания изображений.
Текущая версия 3.0 [5] и маршрутизируемом протоколе TCP/IP (Transmission Control Protocol/Internet Protocol) [6,7]. DICOM v3.0 определяет:
DICOM v3.0 имеет технологию для уникальной идентификации любой информации при сетевом взаимодействии, а также применяет сжатие изображений по стандарту JPEG [8]. Далее в статье описана третья версия стандарта.
Информационные объекты (IOD(s)) обеспечивают абстрактное описание логических групп данных для представления медицинской информации внутри приложения. Для каждого IOD специфицируются:
Предопределено множество необходимых типов объектов: пациент, визит, исследование, результаты, компьютерная радиография и томография, ядерный магнитный резонанс, ультразвук, стороннее изображение, параметры оборудования, отображение на дисплее или принтере и т.д. Модель взаимосвязи IODs показана на рис.2.
Для работы с IODs вводится набор сервисных SOP (Service-Object Pair) классов. Каждый класс предназначен для выполнения специализированных операций (таких как, хранение, поиск, передача, получение, согласование) над определенными IOD. В реальном приложении одна часть SOP–пары исполняет роль клиента, другая – сервера. Для каждого SOP класса определяется:
В стандарте SOP–классы подразделяются на нормализованные и смешанные. Нормализованные классы предназначены для выполнения операций над конкретным IOD, в то время как смешанные – над логически связанным набором разнотипных IODs.
Информация по сети передается в виде DICOM–сообщений (рис.3), которые состоят из последовательности команд и последовательности данных. Последовательность данных состоит из отдельных элементов, в которых передаются значения атрибутов IOD (имя пациента, возраст, название учреждения, тип изображения и т.п.). Каждый элемент данных имеет следующие поля:
DICOM ограничивает набор допустимых символов, используемых в сообщении, девятью таблицами кодировок стандарта ISO 8859. Предусмотрена вторая половина кодировок для латыни, кириллицы, арабского, греческого и иврита. Порядок следования байт в двоичных словах (обусловленный различными типами процессоров), а также наличие поля VR, зависит от типа установленного синтаксиса передачи:
Команды служат для спецификации выполняемых операций и установления соединения. Последовательность команд строится из командных элементов, определяемых протоколом элемента DIMSE, аналогично последовательности данных. Командные элементы не имеют поля типа (VR) и передаются в порядке увеличения номера тега, сначала идут младшие байты.
В стандарте зарегистрированы все элементы DICOM–сообщений и уникальные идентификаторы для синтаксиса передачи и SOP–классов. Для элементов определены теги, типы данных и список предопределенных значений (если необходим).
Сервис DIMSE обеспечивает пересылку сообщений между SOP-классами и определяет:
Стандарт вводит сервис верхнего уровня модели OSI для поддержки обмена DICOM–сообщениями между приложениями, позволяя устанавливать соединение, передавать сообщения и закрывать соединение. DICOM v3.0 может использовать следующие стеки протоколов (рис.4):
В стандарте определен коммуникационный протокол с выделенным соединением на основе семиуровневой модели ISO/OSI. Он выделяет 3 уровня, перекрывающие модель OSI: физический, канальный и сессии/транспорта/сети (STN) уровни. На физическом уровне данный протокол использует свой собственный 50–ти жильный кабель. Для него определены управляющие сигналы, прерывания, диаграммы состояния, временные параметры и нумерация контактов. На канальном уровне поддерживаются потоки данных, он также следит за статусом интерфейса и ошибками. На уровне STN поддерживаются виртуальные каналы и конвейеризация сообщений по интерфейсу. C введением в DICOM v3.0 поддержки модели OSI и протокола TCP/IP данный интерфейс утратил свою актуальность и используется для подключения DICOM–оборудования 1 и 2 версий стандарта.
После выхода третьей версии, в стандарт введены ряд дополнений, специфицирующих хранение информации на физических носителях, структуру файлов и управление ими:
Описан профиль и механизм работы приложения для хранения DICOM–информации на основе специализированных SOP-классов. Два приложения, имеющие одинаковый профиль и обеспечивающие взаимное дополнение сервиса, способны обмениваться частями DICOM–информации на физических носителях. Профиль приложения определяет:
DICOM поддерживает различные форматы физических носителей: дискеты 1.44М, магнитооптические диски емкостью 128М, 650М и 1.2G, а также 120мм записываемые оптические диски (CD–R). В качестве файловой системы используется FAT, совместимая с DOS версии 4.0 и выше.
Разработана технология поддержки стандарта 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.
Появившись как корпоративный, DICOM стал стандартом де-факто и встраивается в оборудование (КТ, ЯМР, УЗИ и т.д.) крупнейших производителей радиологического оборудования (PICKER, GE, Siemens, HP, Philips) и большинство систем архивации медицинских изображений. Он поддерживается национальными организациями по стандартам - CEN TC251 в Европе и JIRA в Японии.
Совершенно очевидно, что на сегодняшний день DICOM является хорошо проработанным стандартом, на который имеет смысл ориентироваться российским разработчикам. Начиная с создания простейших DICOM–конверторов, а также серверов архивации и печати, постепенно переходя к полноценным DICOM–решениям. Работы в этом направлении ведутся в Московском Государственном Институте Электронной Техники.