На сегодняшний день этот вопрос становится всё более актуальным, т. к. внедряемые МИС либо предлагают хранение рентгеновских исследований в своих облачных хранилищах по заоблачным ценам, либо вообще ничего не предлагают. И почти никто не горит желанием использовать уже имеющиеся в отделениях PACS-серверы по одной простой причине — просто «не умеют» работать с ними.Проблемы, конечно, есть. Самая большая проблема, на мой взгляд, в большом количестве рентгеновской аппаратуры, которая в лучшем случае может «сделать» снимок в формате «примерно» соответствующем dicom. Таких аппаратов огромное количество. Столько же, а может и больше, аппаратов, которые вообще просто пленочные и про «цифру» только «мечтают». В данном случае мы пока их вообще не рассматриваем.
Вернёмся к «как-бы» цифровым аппаратам. Они производят снимки «почти» dicom. И хранят их, а также информацию о них, как правило, на лаборантских рабочих станциях, используя при этом какие-либо СУБД типа InterBase, Firebird или MS Access. Описание этих снимков производится на врачебных рабочих станциях с использованием специально именно для них разработанного ПО, т. к. универсальные dicom-вьюверы такие снимки не читают без дополнительной обработки. Передавать самостоятельно исследования в PACS такие системы также не умеют. Для этого обычно можно использовать программу DicomAutoExport . Но зато в таких системах имеются удобные для врачей инструменты описания снимков, ведения истории исследований, печати снимков на пленку, печати описаний на бумаге.
В последнее время всё больше внедряется цифровых аппаратов, которые имеют все необходимые функции для полноценной работы с PACS и МИС. Но функции эти не используются, т. к. нет либо PACS, либо МИС, либо и того, и другого. В итоге хороший цифровой аппарат при отсутствии информационных систем используется даже более примитивно, чем рассмотренные выше аппараты. Зачастую такие системы вообще не имеют врачебных рабочих станций, т. к. предполагается, что все описания будут совершаться рентгенологом на рабочей станции, подключенной к МИС. Но МИС то нет, соответственно «писать» не на чем. И описывают врачи снимки просто, глядя на экран в лучшем случае своего, а не лаборантского, компьютера, используя какой-нибудь самостоятельно установленный dicom-вьювер и чернильную ручку с бумагой. Да, аппарат цифровой, а результаты на выходе получаются «аналоговые».
Но прогресс всё же идёт и многие рентгенотделения имеют сейчас PACS, которые используются в основном для резервного хранения рентгеновских исследований и предоставления доступа к ним врачам-специалистам посредством подключаемых вьюверов. При этом передача диагнозов, поставленных рентгенологами, опять же осуществляется «вручную», «аналоговым» способом, т. к. в большинстве случаев у рентгенологов нет инструментов для создания dsr-файлов и передачи их на сервер.
Поиск исследований в PACS осуществляется либо по ИД, либо по дате, т. к. поиск по ФИО часто некорректен из-за недостаточно полной поддержки кириллических шрифтов. Но ИД одного и того же пациента на каждом аппарате даже в пределах одного отделения разный, т. к. присваивается или вручную по какому-то установленному правилу, или автоматически программой, производящей снимки. Не говоря уже о других модальностях типа УЗИ, ЭКГ и т.д.
С внедрением МИС вопрос единообразия ИД теоретически должен решиться. Осталось решить его практически. И здесь не всё так просто оказывается, как со стороны МИС, так и со стороны отделений.
Теоретически схема взаимодействия МИС и отделения должна выглядеть так (поправьте, если я чего-то упускаю или неправильно понимаю):
Здесь:
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
