Рабочий список передаёт на модальность сведения о запланированном этапе исследования. Его ценность определяется не наличием кнопки Worklist, а согласованностью идентификаторов и правильным поведением при изменениях и сбоях.
Пациент, направление и исследование
Patient ID, Accession Number и Study Instance UID выполняют разные роли. Их нельзя объединять в одно поле «номер». Пациент может иметь несколько направлений, направление — несколько этапов, а изображения должны быть связаны с правильным исследованием. При интеграции требуется согласовать, какие системы создают идентификаторы и как они сохраняются по всей цепочке.
DICOM Modality Worklist организован вокруг Scheduled Procedure Step. Стандарт описывает обмен данными для подготовки исследования и связывания изображений с информационной системой. Он не определяет всю внутреннюю организацию базы учреждения. Поэтому наличие поддержки стандарта не освобождает от проверки локальных сценариев и сопоставления полей. DICOM PS3.4: Modality Worklist.
| Идентификатор | Назначение | Частая ошибка |
|---|---|---|
| Patient ID | Идентификация пациента в заданном контексте | Считать уникальным между всеми организациями |
| Accession Number | Связь с заказом исследования | Подставлять случайный локальный номер |
| Study Instance UID | Уникальная идентификация DICOM-исследования | Использовать имя пациента вместо связи объектов |
| Scheduled Procedure Step ID | Идентификация запланированного этапа | Путать с любым номером процедуры |
| AE Title | Идентификация приложения в обмене | Считать идентификатором пациента |
Почему рабочий список не отменяет проверку личности
Автоматическая загрузка уменьшает ручной ввод, но оператор всё ещё может выбрать не ту строку. Поэтому проверка личности пациента и назначения остаётся частью клинического процесса. В интерфейсе должны быть доступны различающие сведения, а не только фамилия. Совпадение фамилий — нормальная ситуация, которую интеграция обязана выдерживать.
Для приёмочного теста используют искусственные записи с похожими именами, разными датами рождения и несколькими направлениями. Реальные персональные данные не нужны для проверки логики. Важно проверить не только успешный сценарий, но и отмену, перенос, исправление демографии и временную недоступность рабочего списка. IHE: принципы интеграционных профилей.
Разбор: список пуст, сеть работает
Учебная ситуация: устройство отвечает на сетевую проверку, но не получает назначений. Возможны ограничения по дате, модальности, станции или другой настройке запроса. Успешное соединение подтверждает лишь часть цепочки. Инженеру нужны параметры запроса и ответ сервера, полученные разрешёнными средствами диагностики, с защитой персональных данных.
Не следует сразу отключать фильтры на всех аппаратах. Сначала выбирают один известный тестовый заказ и проверяют, почему он не соответствует запросу. Так проще отличить неверный AE Title от даты или маршрутизации. После исправления проверяют, что устройство не стало показывать чужие назначения, которые раньше правильно исключались.
| Симптом | Проверяемая область | Контрольный результат |
|---|---|---|
| Пустой список | Фильтры и расписание | Известное назначение найдено |
| Лишние назначения | Маршрутизация станции | Показываются только нужные записи |
| Дубли пациентов | Идентификаторы и область их выдачи | Одна согласованная запись |
| Неверная кириллица | Кодировка и представление | Имя одинаково на всех этапах |
| Исследование не привязалось | Идентификаторы заказа и объектов | Результат доступен у нужного назначения |
Разбор: работа во время сбоя
Второй пример: рабочий список недоступен, исследование выполнено по утверждённой резервной процедуре. После восстановления сети возникает риск создания дубля. Заранее нужен процесс согласования локально полученных данных с правильным заказом. Простая повторная отправка не всегда решает идентификацию; она может только добавить ещё одну копию.
Резервная процедура должна определять допустимый временный идентификатор, ответственного за сверку и журнал изменений. Исправление должно оставлять прослеживаемую историю. Нельзя незаметно менять принадлежность изображения к пациенту без установленного процесса. Безопасность здесь состоит прежде всего в правильной идентификации и проверяемом восстановлении связи.
Приёмочный сценарий
| Тест | Что сделать на тестовых данных | Критерий завершения |
|---|---|---|
| Обычное назначение | Пройти от заказа до просмотра | Все идентификаторы согласованы |
| Похожие пациенты | Выбрать правильную запись | Доступны различающие сведения |
| Изменение заказа | Перенести или отменить | Список отражает состояние |
| Сбой связи | Использовать резервный маршрут | Восстановлена связь без скрытого дубля |
| Экспорт | Открыть данные в конечной системе | Пациент и исследование определены верно |
Приёмка Worklist заканчивается не появлением строки на аппарате, а правильной связью результата с пациентом и назначением. Такой подход делает интеграцию устойчивой к реальной работе отделения, где изменения и временные сбои неизбежны.
Пространство идентификаторов
Одинаковый Patient ID в двух организациях может относиться к разным людям. Поэтому контекст выдачи идентификатора имеет значение при объединении данных. Локально уникальный номер нельзя без проверки считать глобальным. При межсистемном обмене согласуют правила идентификации и поддерживаемые поля, а не полагаются на совпадение фамилии и номера.
Учебный тест может включать двух искусственных пациентов с одинаковым локальным номером из разных источников. Задача — убедиться, что система различает записи по согласованному контексту и не объединяет исследования автоматически. Такой тест безопаснее проводить до запуска, чем расследовать ошибочную принадлежность после появления реальных данных.
Исправление демографической информации также требует правил. Изменение имени пациента не должно создавать новую личность без необходимости, но и простое совпадение имени не должно объединять разные записи. Ответственность за такие изменения обычно выходит за пределы одного аппарата. Интеграционный документ должен определять, какая система является источником достоверных сведений и как изменения распространяются дальше.
Как писать заявку разработчику
Полезная заявка содержит тестовый идентификатор, ожидаемое поведение, фактическое поведение и участок цепочки, где возникает расхождение. Если сообщить только «Worklist не работает», разработчику придётся заново собирать весь контекст. При передаче журналов необходимо исключать ненужные персональные данные и использовать согласованный защищённый канал.
Исправление проверяют не только на исходном случае, но и на соседних сценариях: другая дата, несколько этапов, отменённый заказ и похожий пациент. Это не означает бесконечное тестирование; нужен заранее определённый набор, отражающий локальный рабочий процесс. Завершённой задачей считается восстановленная корректная связь данных, а не просто отсутствие сообщения об ошибке на экране.