Здесь:
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