Автор: Пользователь скрыл имя, 12 Января 2014 в 13:47, дипломная работа
Часто из вида упускается вклад DICOM и PACS на фактического пациента. DICOM обеспечивает весь рабочий процесс с момента, когда пациент входит в радиологическое отделение, собирая важные данные и изображения с цифровых модальностей и доставляя их за считанные минуты рентгенологам в самой точной для диагностики форме. Сравнение предыдущих исследований с новыми не требуют огромных усилий с DICOM, что приводит к более точной диагностики и лучшему лечению. Нет пленок, которые можно потерять, перепутать, просрочить, а отсюда и меньше повторных исследований. Все это позволяет ускорить и значительно улучшить современное здравоохранение. Важность DICOM, как неотъемлемой части IT–инфраструктуры, будет расти. Количество существующих и доступных DICOM и PACS приложений просто ошеломляет. Выбор PACS с каждым годом становится все сложнее, а понимание DICOM все важнее.
Таблица 1.1.4 Основные типы DICOM (VR)
Каждый элемент является одной частью типизированных данных с предварительно четко определенным смыслом. Существуют тысячи DICOM элементов, от самых простых атрибутов типа имени пациента и даты рождения к самым эзотерическим, таким как описание 3D поверхностей.
В некотором смысле определения объектов в DICOM похожи объектно-ориентированное программирование. Благодаря подробному описанию определения объекта (Information Object Definition) DICOM позволяет обмениваться виртуальными объектами между приложениями, не зная заранее ничего о приложении с которым оно будет взаимодействовать. Сохраненный на жестком диске объект DICOM и есть DICOM файл. Файлы образовались как часть стандарта, а не наоборот. На рисунке 1.2.1 показан DICOM файл, открытый в блокноте. Самый простой способ его распознать: должен содержать DICM с 129 по 132 байт.
Рисунок 1.2.1 DICOM файл, открытый в блокноте
На рисунке 1.2.2 изображена модель данных в самой упрощенной форме
Рисунок 1.2.2 Упрощенная модель данных DICOM
Модель данных определяет информационные структуры (Information Entities); пациент, исследование, серия, экземпляр. Существуют и другие структуры, такие как визит, оборудование, процедура и множество других. Модель данных DICOM, которая сделана из IE считается нормализованной. Однако классы объектов DICOM это композиты, сделанные из модулей различных структур. Интеграция достигается приложениями, которые обмениваются составными объектами. Каждое приложение отвечает за свою собственную внутреннюю нормализованную базу данных, которая является частной для него и которая не должна заинтересовать любое другое приложение, а также выходить за рамки стандарта. То, как необходимо разрабатывать DICOM приложение полностью дело разработчика. Единственное, что имеет значение – интерфейсы. Приложение должно уметь «общаться» надлежащим стандартом образом. В сетевом протоколе DICOM есть различие между нормализованными и композитными операциями, и есть протокол N и C с различными командами для каждого из них.
Классы DICOM статической модели данных называются SOP классами, и они определяются с помощью описания информации об объекте (Information Object Definition). IOD’ы представляют собой набор модулей, а модули представляют собой набор элементов из одной информационной структуры, которые вместе представляют собой нечто.
Все объекты DICOM должны содержать общий модуль SOP и модули из четырех основных IE: пациент, исследование, серия, экземпляр. Например, все экземпляры DICOM, которые являются изображениями, должны включать в себя модуль изображений. Так как объект DICOM должен быть частью серии, все объекты должны включать общий модуль серии, а так как серии должны быть частью исследования, каждый объект должен включать общий модуль исследования и потому что каждое исследование проводится на некоторых пациентов, все объекты должны иметь модуль пациента.
DICOM широко использует уникальные идентификаторы. Почти каждая сущность в модели данных DICOM имеет уникальный идентификатор. Каждый SOP класс DICOM имеет уникальный идентификатор. Объект DICOM является экземпляром такого класса и называется SOP экземпляром, и он тоже имеет свой UID. DICOM определяет механизм для того, чтобы убедиться, что UID’ы являются глобально уникальными. Каждое DICOM приложение должно получить Root UID, который используется в качестве префикса для UID’ов, которые оно создает. Каждый объект в модели данных DICOM также имеет UID, за исключением пациента. Пациенты определяются с помощью сочетания имени и документов. Исследования, серии, все имеют UID. Архивы DICOM (PACS) должны использовать UID, с целью индексировать свои базы данных для того чтобы другие приложения могли делать поиск (запросы) и ссылаться на объекты, используя UID, а архив мог реагировать быстро.
Сетевой протокол DICOM удерживает любые медицинские системы вместе. Хоть и большинство считают, что DICOM это просто формат изображений, на самом деле это более широкий стандарт, который контролирует все аспекты работы госпиталя и выходит далеко за рамки простого формата.
Для связи DICOM использует TCP/IP протокол, так как он вмещает все программные и аппаратные вариации и обеспечивает наиболее фундаментальную функциональность, необходимую для сети: отправка и прием информации (в виде последовательности байт) с одного порта или IP-адреса на другой. DICOM лишь добавляет к нему свой собственный язык (прикладной уровень).
Каждое DICOM - совместимое устройство (Application Entity), находящееся в сети, обладает сетевой картой и своим IP-адресом, который необходим для связи другим устройствам с ним. В дополнение к этим стандартным требованиям DICOM назначает каждому устройству собственные имена, называемые Application Entity Title (AET). AET кодируются специальным типом VR – AE, который не может быть длиннее 16 байт.
Таким образом, для настройки устройства в сети DICOM необходимо назначить три вещи:
Связь для обмена информации между двумя Application Entity называется ассоциацией. Во время ассоциации определяется контекст приложения, который имеет UID и во время начала этой ассоциации этот UID передается к партнеру. Сравнивая UID контекста приложения, партнер может решить, способен ли он обрабатывать этот запрос на ассоциацию. От этого будет зависеть его выбор, либо принять создание ассоциации или отклонить его.
AE DICOM’а передают друг другу сервисные сообщения, запрашивая или предоставляя информацию. Вот почему все служебные команды известны в DICOM как DIMSE. DIMSE протокол устанавливает правила «общения» в сети DICOM, является костяком сети DICOM. Каждая служба DIMSE обычно имеет часть «запрос» и часть «ответ». Запросы направляются клиентом (SCU), а ответы предоставляются сервером (SCP). DIMSE связанные с составными данными называются «DIMSE-C», а DIMSE, связанные с нормированными данными называются «DIMSE-N».
Рассмотрим команды протокола:
Modality Worklist (MWL) – одна из самых важных служб DICOM. Она действительно ускоряет и автоматизирует модальности. Служба загружает списки запланированных процедур на модальность, таким образом, когда пациент приходит на нее, о нем уже все известно. SOP класс UID этой службы является "1.2.840.10008.5.1.4.31".
Весьма простая по принципу служба, которая действительно ускоряет работу больницы. MWL просто отправляет списки назначения на заданную модальность. Чаще всего эти списки хранятся в информационной системе радиологии (Radiology Information System), где пациенты уже зарегистрированы для проведения каких либо исследований. RIS не относится к стандарту DICOM, она использует вместо этого стандарт HL7, а поэтому требуется некоторое средство перевода на язык DICOM. Обычно сервер MWL обладает такими возможностями. На рисунке 1.4.1 показана схема работы MWL.
Рисунок 1.4.1 Схема работы MWL
Рассмотрим принцип работы:
Storage Commitment (SCM) является службой DICOM, которая позволяет проверить, действительно ли файлы, которые были ранее отправлены в PACS с помощью DICOM Storage Service были сохранены успешно. SOP класс UID этой службы является "1.2.840.10008.1.20.1".
Принцип работы SCM весьма прост. Все, что нужно сделать, это отправить список экземпляров и получить обратно ответ, какие экземпляры находятся в PACS, а какие нет. На рисунке 1.5.1 изображен общий принцип работы SCM.
Рисунок 1.5.1 Принцип работы SCM
Слева показан SCM запрос. Он отсылает DIMSE команду N-ACTION с набором данных, которая состоит из:
Все что делает SCP далее, это отвечает, что он получил данные и начинает их обработку. На правой стороне рисунка показано, что посылается в ответ после того, как запрос был получен и обработан. Результаты отсылаются с DIMSE командой N-EVENT-REPORT, которая содержит:
Если список неподтвержденных экземпляров не пуст, то результат считается неудачным. В противном случае – удачным. Команда N-EVENT-REPORT имеет ID события, который равен 1, если SCM удачен и все экземпляры подтвердились и 2, если какие-то экземпляры не удалось подтвердить.
Получение результата SCM иногда может быть немного сложным. Иногда SCP не отвечает сразу и иногда ему нужно некоторое время для обработки запроса, постановки в очередь для пакетной обработки, проверки базы данных, составления ответа, постановки в очередь для отправки и так далее. Вместо того чтобы просто получить данные и отправить ответ, DICOM позволяет SCP свободу решать, когда и как ответить. SCP может отослать ответ N-EVENT-REPORT тремя способами:
Третья опция была добавлена для решения проблем с мобильными модальностями, которые очень часто включаются и выключаются в сеть, что может привести к проблеме, когда он может выйти из сети, когда PACS не сможет установить ассоциацию для отправки результата.
Первая проблема DICOM заключается в том, что хоть он и направлен на создание совместимости между приложениями, устройствами и модальностями, но из-за сложности стандарта не все производители понимают его одинаково и выполняют каждый пункт.
Вторая проблема заключается в том, что стандарт весьма динамичен и постоянно обновляется и изменяется, а также к нему добавляются новые пункты и службы. Сравнительно недавним добавлением было сразу две службы: сопровождение листов назначений (Modality Worklist) и подтверждение хранения изображения (Storage Commitment). Отсюда следует, что и приложения должны постоянно обновляться и поддерживаться.
Существует два подхода для расширения и поддержки функциональности DICOM приложений:
Первый подход: использование готовых бесплатных библиотек и проектов с открытым исходным кодом. В число таких библиотек входят DCMTK, DVTk, Fellow Oak DICOM, DICOM4Che и другие. У этого подхода есть большие достоинства. Например, из-за открытого исходного кода, над ними работают большое количество людей, а значит риск неисправленных ошибок меньше. Однако у этого подхода так же есть и существенные недостатки. Во-первых, проект получается более динамичным, а значит менее контролируемым и структурированным. Во-вторых, разобраться в чужом коде не всегда бывает легче, чем написать свой. В-третьих, в библиотеках что-то может быть лишним, что-то сделано не так, как нужно нам, а что-то может и вовсе отсутствовать. Например, в работе для тестирования использовались сразу два пакета, так как нужен был разный набор служб.
Второй подход: развитие или аккреция собственного кода. Этим подходом пользуются все крупнейшие производители медицинского оборудования, разрабатывая собственные DICOM-модули. Этот подход решает проблему с контролируемостью, а так же пониманием кода. Свой код будет гораздо легче поддерживать и сопровождать.