WikiDer > Нейтральный архив поставщика

Vendor Neutral Archive

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

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

Определение

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

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

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

Существует общее согласие по следующим ключевым характеристикам:

Хранение DICOM изображения и связанные составные объекты (состояния презентации, ключевые объекты, структурированные отчеты)
Стандартный сетевой интерфейс DICOM для хранения, запроса и поиска
Административные обновления и исправления (изменение идентификатора пациента и объединение исследований)
Масштабируемость

Каждые из следующих признаков остаются спорными, в том смысле, что некоторые клиенты и поставщики утверждают, что некоторые или все имеют основополагающее значение для концепции, но другие не согласны:

Хранение объектов, не связанных напрямую с изображениями (например, запросов и отчетов, созданных человеком)
Хранение содержимого, не относящегося к DICOM (например, HL7 CDA документы)
Протоколы доступа, отличные от DICOM (например, IHE Cross-Enterprise Document Sharing (XDS и XDS-I)
Междоменная идентификация и разрешение кода (идентификатор пациента, номер доступа, коды процедур)
Динамическое преобразование тегов DICOM
Управление жизненным циклом информации
Исключение содержимого базы данных управления рабочим процессом
Независимость от выбора движка базы данных
Контрольный журнал доступа

История

Эволюция

Традиционно потребность в хранении медицинских изображений была наиболее распространена в отделениях радиологии и ядерной медицины и реализовывалась в форме специализированных и ведомственных (PACS), которые объединили функции управления изображениями и архивирования изображений в единый блок. единственное решение. Хотя все такие системы имеют стандартные интерфейсы (DICOM и ИГЕ) для приема и распространения изображений по сети и на физических носителях (например, компакт-дисках), обычно рабочий процесс и оптимальная производительность для отображения достигаются с помощью проприетарного программного обеспечения и протоколов. Кроме того, постоянное хранилище «внутри» проприетарной PACS может быть нестандартной формы, PACS может не обновлять хранимые файлы с последними исследованиями и демографическими обновлениями и аннотациями, хранящимися в базе данных, и может расширяться, злоупотреблять или зависеть от определенные стандартные и нестандартные (частные) атрибуты DICOM в сохраненных файлах.

Со временем во многих реализациях базовая инфраструктура хранения была «выделена» из традиционной (PACS) в аппаратное обеспечение и файловую систему (DAS, NAS, SAN) уровне, а вместо этого предоставляются не зависящими от домена компьютерное хранилище данных продавцы.

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

Осложняющим фактором является то, что предложения (PACS) находятся в постоянном изменении в отношении функций и качества обслуживания, и традиционно пользователи откажутся от одного поставщика и заменят свой продукт другим каждые 3-5 лет. Это вызывает необходимость «перенести» изображения и связанную с ними информацию в новую архитектуру без потери данных, что является нетривиальной задачей, несмотря на использование стандартных форматов для кодирования изображений. Концепция VNA теоретически обеспечивает большую стабильность (возможность повторного использования и менее частая миграция) на уровне архива, несмотря на быстрое развитие и изменения на более высоком уровне приложения (отображение и рабочий процесс). Конечно, переход от VNA одного производителя к другому тоже не является тривиальным, но, надеюсь, менее частым.^[1]

Альтернативным термином для VNA является «нейтральный архив PACS», который, возможно, лучше передает первоначальное намерение, но этот термин используется редко, и, к лучшему или к худшему, VNA стал модное слово выбора среди покупателей и продавцов.^[2]

Литература

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

С первых дней существования PACS предполагалось, что необходимо будет определить стандартные границы взаимодействия.^[3]. Стандарты ACR-NEMA, а затем и DICOM, возникли для удовлетворения не только потребности в стандартном формате файла, но и протоколов для хранения изображений от способов получения до архивов, а также для запроса и извлечения изображений из архива. Даже первый стандарт ACR-NEMA 1985 года^[4] определенные транзакции FIND и GET^[5]. То есть, с самого начала предусматривалось отделение рабочих станций и управления рабочими процессами от архивов. Первые демонстрации DICOM на RSNA, начавшиеся в 1992 году, использовали так называемый «центральный тестовый узел».^[6], который, возможно, был одним из первых независимых от поставщиков архивов на основе DICOM, хотя в то время этот ярлык не использовался. Домашние PACS или mini-PACS обычно описывали архив и рабочую станцию как отдельные объекты.^[7]. Многие, но не все, монолитные коммерческие PACS продолжали использовать проприетарные протоколы между своими интегрированными рабочими станциями и архивами, но всегда признавалась необходимость поддержки отдельных сторонних рабочих станций для специализированной работы, такой как обработка 3D и планирование лучевой терапии, и реализовано с использованием протокола DICOM.

В 1998 году Эриксон и Хангиандреу^[8] обсудили преимущества еще раз отделения архивных функций от традиционной монолитной PACS и использования предварительной выборки для заполнения «устройства хранения интерпретации». Они также описывают запросы и извлечение из нескольких архивов (таким образом, который теперь будет называться федеративным запросом) для обеспечения совместного использования изображений между предприятиями. В статье отмечены некоторые практические проблемы того времени, такие как относительная неэффективность выполнения запросов DICOM к таким многочисленным архивам и разделение тех ответов, которые имеют отношение к предварительной выборке, а также проблемы с идентификаторами пациентов. Тем не менее, возможность хранить изображения в системе, отдельной от рабочей станции, считалась важной возможностью. В конечном итоге Эриксон и его коллеги развили это в стартап-компанию TeraMedica.^[9] в 2000 году, который был приобретен Fuji Medical Systems в 2015 году.

В одной из многих записей блога^[10] По этому поводу Майкл Грей ссылается на раннее описание концепции разделения клиентских клинических приложений и внутренних хранилищ в статье Надима Дахера, аналитика рынка медицинской визуализации в Frost & Sullivan.^[11]

После ответа Майкла Грея давняя ветка форума тетушки Минни на PACS отклонилась, чтобы обсудить проблему нейтральных архивов среди более широкой аудитории.^[12]

Белая книга Уэйна ДеЖарнетта за 2009 год ^[13] - это ранняя попытка дать определение, основанное на необходимом наборе функций, и его компания также представила более позднюю интерпретацию.^[14]

Майкл Грей предлагает свои основные ингредиенты ВАЦ в своей записи в блоге 2009 года:^[15] со ссылкой на контрольный список атрибутов Acuo, самую последнюю форму которого можно найти в официальном документе Шеннон Верб об атрибутах «настоящего» ВАЦ.^[16]

Герман Остервейк дает более свежее описание от имени Teramedica в своем официальном документе:^[17] в котором он предлагает более подробное определение: «Нейтральный архив поставщика (VNA) - это медицинское устройство, которое обеспечивает масштабируемое изображение и информацию, а также управление жизненным циклом, чтобы изображения и связанную информацию можно было запрашивать, сохранять и извлекать таким образом, чтобы определены открытыми стандартами на уровне нескольких отделов, предприятий и регионов при сохранении конфиденциальности и безопасности пациентов. Характерной чертой VNA является то, что он обеспечивает ориентированный на пациента подход, который выходит за рамки обновлений и изменений различных компонентов просмотра, сбора данных и управления рабочим процессом, таких как они должны быть взаимозаменяемыми без необходимости переноса, преобразования или изменения форматов данных или интерфейса ВАЦ ».

Связь ВАЦ с хранением медицинских изображений в облако также туманен, но предлагает высокий потенциал для соответствие модному слову, а Майкл Грей дает некоторую ясность в своей статье, заказанной EMC.^[18]

Различные альтернативные модели развертывания^[19] и рамки^[20] были описаны, которые касаются вопросов стоимости, ценности и барьеров для входа.

С тех пор, как термин «VNA» стал использоваться в качестве маркетингового термина, он уже приобрел мифический статус.^[21]

Функции

Административные обновления и исправления

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

Существуют стандарты, которые охватывают некоторые варианты использования, такие как согласование информации о пациентах (PIR) IHE и управление изменениями объектов изображений (IOCM).

Междоменная идентификация и разрешение кода

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

Как правило, в пределах домена, такого как отдельное учреждение, идентификаторы пациентов и идентификаторы запросов, исследований и отчетов (например, по инвентарным номерам) присваиваются однозначно внутри этого домена, но не за его пределами. Большинство внутренних систем (и большинство PACS) не управляют существованием нескольких доменов идентификации, и если идентификаторы используются в доменах, возникают конфликты и неоднозначность. Таким образом, каждый идентификатор должен быть квалифицирован его «назначающим органом» при использовании (подход, принятый DICOM-основан ИГЕ Профиль Multiple Image Manager Archive (MIMA)) или принудительно преобразован в один «канонический» идентификатор, который охватывает область более крупного домена, включающего все интегрированные межорганизационные системы (подход, принятый IHE Обмен документами между предприятиями. При импорте внешних изображений в локальный архив этот вопрос также должен быть решен, обычно путем преобразования внешнего идентификатора во внутренний идентификатор и перекодирования информации (принуждение) в «заголовке» DICOM или других метаданных (например, способом, указанным в разделе «Рабочий процесс согласования импорта»).

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

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

Динамическое преобразование тегов

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

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

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

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

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

Динамическое преобразование тегов отличается от конкретных изменений атрибутов, связанных с междоменной идентификацией и разрешением кода (то, что DICOM в PS 3.4 называется «принуждением»), для которых существуют стандарты, определяющие, что изменять, когда и как и какие часто включают дополнительных участников, таких как Master Patient Index, хотя некоторые сторонники объединяют их вместе, а некоторые продукты реализуют их с использованием того же механизма.

Майкл Грей был одним из первых сторонников морфинга тегов и считает это важной функцией VNA.^[22] Описание вариантов использования преобразования тегов можно найти в официальном документе Уэйна Дежарнетта 2010 года.^[23]

Управление жизненным циклом информации

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

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

Тем не менее, потенциально полезной функцией VNA является поддержка локально настраиваемых критериев очистки (отбраковки) на основе правил, будь то прямая реализация правил или ответ на запросы IHE Imaging Object Change Management (IOCM) от отдельного механизма правил.

Не-DICOM контент

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

Однако в клинических условиях могут быть доступны другие типы документов и объемных объектов, которые было бы желательно хранить. Большинство PACS используют подход преобразования их в DICOM, в некоторых случаях используя объекты, предназначенные для «инкапсуляции» другого типа объекта. Классическим примером является отсканированный документ, хранящийся в виде файла PDF и инкапсулированный в объект PDF DICOM вместе с достаточными метаданными для его идентификации и управления им, как если бы это было изображение. VNA должны поддерживать этот тип инкапсулированных объектов DICOM, а «заголовок» DICOM предоставляет средства для получения метаданных для индексации для поддержки запросов и извлечения. Майкл Грей подробно раскрывает эту тему в своем официальном документе по этой теме.^[24]

Для других типов объектов, или когда нет доступного объекта инкапсуляции DICOM, или когда нет необходимости взаимодействовать с системами DICOM, при условии, что есть стандартные средства предоставления необходимых метаданных для индексации, например, с помощью HL7 версии 2 сообщений или служб реестра XDS, то теоретически VNA может хранить что угодно.

Конкретные типы содержимого, не относящегося к DICOM, такие как экземпляр документа HL7 CDA, содержащий, например, отчет о радиологии, могут быть сохранены либо как XDS, либо сначала инкапсулированы в объекте DICOM Encapsulated CDA и сохранены с использованием служб DICOM или его содержимого. а заголовок может быть преобразован в экземпляр структурированного отчета DICOM. Полнофункциональный VNA может иметь возможность транскодировать любой отдельный экземпляр в другую форму в зависимости от того, что требуется запрашивающей системе («преобразование объекта», если хотите).

Описание подхода Уэйна Дежарнетта к хранению объектов, отличных от DICOM, в его продукте описано в его техническом документе 2009 года.^[25]

Стандартизация интерфейса

Формат файла изображения на долговременном носителе

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

Реализации могут различаться по диапазону поддерживаемых схем сжатия, независимо от того, является ли обратимое (без потерь) сжатие обязательным для медицинских и юридических целей архивирования. Реализации также различаются по диапазону типов изображений, зависящих от модальности, которые они поддерживают; Хотя многие архивы в принципе поддерживают все информационные объекты изображения DICOM, некоторые крайние случаи, например, изображения патологий целого слайда и длинные видео, могут не поддерживаться. Общая особенность VNA состоит в том, чтобы попытаться сохранить все атрибуты в том виде, в каком они были изначально предоставлены, включая частные (проприетарные) атрибуты, будь то из способа сбора данных или добавленные другими промежуточными приложениями (такими как рабочие станции QC или PACS).

DICOM описывает множество различных «определений информационных объектов» и «классов SOP» для хранения изображений с конкретными метаданными, относящимися к конкретным модальностям и приложениям, и их список растет по мере развития технологий. Поскольку формат DICOM по своей сути является расширяемым, а все новые объекты основаны на общей кодировке и шаблоне, VNA должны иметь возможность хранить любой объект изображения DICOM, независимо от того, является ли класс SOP распознанным или новым. Это может быть достигнуто за счет использования изменяемой полем конфигурации для добавления новых классов SOP, или путем анализа содержимого «заголовка» объектов, или за счет простого подхода приема, сохранения и повторения всего, что передается через DICOM C- СОХРАНИТЬ операцию.

Протоколы передачи изображений

Обычный DICOM

Поддержка базового DICOM C-STORE, C-FIND, C-MOVE и предпочтительно C-GET является фундаментальной и не обсуждается. Как правило, поддерживаются базовые синтаксисы передачи без сжатия, включая неявный и явный обратный порядок байтов VR и менее распространенный синтаксис прямой передачи. Диапазон синтаксисов сжатой передачи обычно включает JPEG без потерь и обратимый и необратимый JPEG 2000, изредка JPEG-LS, и обычно JPEG с потерями для изображений, которые были предоставлены таким образом (особенно полноцветных фотографий. Поддержка сжатия движения (кроме многокадрового JPEG) менее распространена, но, возможно, более распространена в VNA, чем в PACS, особенно для хранения и срыгивания без просмотра.

ВАДО

Большинство согласятся, что важным интерфейсом VNA является оригинальная версия Веб-доступ к постоянным объектам DICOM (WADO), который позволяет извлекать отдельные изображения с HTTP URL-адрес в формате файла DICOM или предварительно преобразованный в пользовательский формат, например JPEG.

XDS-I.b

В МЫЛО Веб-сервис транзакции, основанные на IHE Cross Enterprise Document Sharing for Imaging, также обычно считаются предварительным условием для заявления о присвоении статуса VNA.

Объекты, связанные с изображениями

Состояния презентации

Преобразование оттенков серого или цветопередачи, применяемое к изображениям для отображения, следует сохранять как объект состояния представления DICOM. Эти объекты поддерживают полутоновые и полноцветные изображения, а также применение псевдоцвета. Справочная таблица для изображений в оттенках серого. Состояния презентации также могут записывать любое примененное масштабирование и панорамирование (выбор отображаемой области). ИГЕ использует их в профиле согласованного представления изображений (CPI)

Поскольку многие современные PACS также может сохранять аннотации к изображениям с использованием объектов состояния представления DICOM, ВАЦ должен поддерживать их, включая не только хранение и регургитацию, но также выбор и отображение в любом средстве просмотра, поставляемом как компонент ВАЦ.

Аннотации, области интересов и измерения

Предпочтительный формат для хранения аннотации, интересующие регионы, и измерения - это объект структурированного отчета DICOM (SR), который позволяет сохранять структуру, кодированную и семантическую информацию, а не просто ее представление. IHE называет их Доказательствами (ED). Объекты DICOM SR также могут быть созданы в контексте IHE, указывающего их в профиле простого изображения и числового отчета (SINR).

Поскольку многие методы сбора данных, системы CAD для маммографии и рабочие станции для количественного анализа изображений производят объекты SR, ВАЦ должен иметь возможность сохранять и воспроизводить их. В идеале любой компонент средства просмотра должен быть способен к общему (если не идеальному) отображению содержимого любого SR, включая отображение координат на ссылочных изображениях.

Для определенных доменов, например Лучевая терапия, более старый формат, DICOM RT Structure Set, который может кодировать трехмерные относительные координаты пациента. изоконтуры (только), и некоторые рабочие станции, не поддерживающие RT, также производят их вместо SR. ВАЦ тоже должен их поддерживать.

Ключевые изображения и выбор объекта

Общая концепция PACS заключается в том, что пользователь (например, оператор модальности или интерпретирующий радиолог) должен пометить некоторые изображения (или другие объекты) как «ключевые», т.е. представляющие особый интерес по какой-либо причине. Хотя устаревшая PACS может записывать это только как флаг во внутренней базе данных, современные PACS используют DICOM Объект выбора ключевого объекта (специализированная форма SR) для экспорта этой информации. Это использование описано в профиле IHE Key Image Note (KIN). ВАЦ должен поддерживать хранение и регургитацию объектов KOS, а также их выбор и отображение в любом средстве просмотра.

Отчеты о дозах облучения

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

Отчеты о процедурах

В радиологии и ядерной медицине практика диктовки и расшифровки (или использования распознавание речи) хорошо укоренился, и на выходе они обычно представляют собой неструктурированную или минимально структурированную прозу, закодированную как простой текст и распространяемую по факсу, сообщениями HL7 версии 2 или каким-либо столь же примитивным механизмом. Постоянная форма этих «документов» плохо стандартизирована, но многие клиенты ожидают, что ВАЦ сможет принимать их в любом предпочтительном локальном формате. Применяются те же принципы, что и для хранения любого содержимого, не относящегося к DICOM, включая использование сообщений HL7 версии 2 или XDS для предоставления метаданных вместо структурированного «заголовка», например, в случае отчетов, отображаемых в формате PDF, когда они не были инкапсулированы в объекты DICOM или CDA. Теперь, когда HL7 пообещал ослабить свою ранее закрытую политику IP, в том числе предложить CDA бесплатно для использования, возможно, что CDA станет предпочтительной формой кодирования, но VNA все равно должны будут принимать (и, возможно, перекодировать) отчеты во множестве форма из установленной базы. DICOM определяет шаблоны для кодирования отчетов, созданных человеком, как объекты структурированного отчета DICOM (SR), а IHE указывает их в профиле простого графического и числового отчета (SINR).

Объекты лучевой терапии

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

Объекты сырых данных

DICOM определяет объект Raw Data, который по сути является обычным заголовком составного экземпляра DICOM с информацией о пациенте, исследовании, серии и экземпляре, но без полезной нагрузки. Он был предназначен для хранения необработанные данные который нелегко представить как изображение или подобный изображению объект, такой как необработанные изображения, полученные с детекторов компьютерного томографа, или k-пространство данные со сканера МРТ, но могут использоваться для кодирования чего угодно. ВАЦ должен иметь возможность хранить и отрыгивать их, даже если он может не знать об их содержании, и только исходное устройство может их интерпретировать.

Объекты аудио, формы волны и спектроскопии

Хотя существует множество широко используемых потребительских форматов для кодирования звука, в них отсутствуют заголовок или метаданные, необходимые для идентификации пациента и встречи. VNA, который хочет поддерживать это, должен иметь средства предоставления такой информации, такие как отправка с помощью XDS. DICOM действительно определяет объект Basic Audio, и хотя он не поддерживает множество аудиокодеков, доступных в потребительском мире, некоторые PACS действительно создают их, поэтому VNA должен их поддерживать.

Временные осциллограммы (например, ЭКГ) могут храниться в формате DICOM или во множестве других форматов, и применяются те же принципы, что и для звука; то есть, если формат ориентирован на медицину, используйте метаданные заголовка для индексации во время приема, если нет, используйте XDS для его регистрации.

DICOM МР-спектроскопия объект определен, и поскольку некоторые модальности создают его, ВАЦ должен иметь возможность хранить и воспроизводить его экземпляры.

Частные объекты

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

Сценарии использования

Обслуживание изображений на сайте для нескольких PACS
Внедрение изображений в несколько PACS
Прямой просмотр изображений (локально или извне)
Высокая доступность
Непрерывность бизнеса и Аварийное восстановление

Спектр предложений от вендоров

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

Сторонние системы, разработанные независимо от PACS
Внешние архивные системы, изначально предназначенные для BC / DR
Продукты с центральным репозиторием, поддерживающие межорганизационный и внешний доступ
Традиционные PACS с улучшенным стандартным доступом к внутреннему архиву

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

Рынок

Размер глобального рынка VNA невелик по сравнению с рынком PACS, но предполагается, что он будет расти.^[26]

Обзор состояния рынка VNA на конец 2012 г. можно найти в этом резюме.^[27]

Navigation