Служба обеспечения готовности к хранению (модель push): как я получаю результат обратно в свой SCU?

Question

Я планировал внедрить службу службы хранения данных, чтобы проверить, были ли сохранены файлы, ранее отправленные в хранилище.

Моя архитектура очень проста и проста, мой SCU отправляет некоторые дополнительные изображения захвата в хранилище, и я хочу быть уверенным, что они безопасно сохранены, прежде чем удалять их.

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

То, что я понял, является

• мне нужно выдать N- ACTION запрос с идентификатором SOP-класса UID 1.2.840.10008.1.20.1 и добавьте к запросу идентификатор транзакции вместе со списком ссылочного идентификатора SOP-класса с ссылкой SOP Идентификатор экземпляра, где UID-идентификатор ссылочного SOP - это UID в вторичные изображения захвата я ранее посланные в хранилище и Реферировано SOP класса UID в моем случае это класс мыло идентификатор , представляющий Secondary Capture Image
• ждать моего ответа N-ACTION, чтобы увидеть, если запрос на N-ACTION успеха или не

• Получить ответ от хранения в виде N-EVENT-REPORT

  Но когда? Как хранилище вернет мне N-EVENT-REPORT вместе с результатами? Мой SCP AE реализует некоторые функции SCP ? Или мне нужно выпустить запрос N-EVENT для получения N-EVENT-REPORT?

Answer 1

Посмотрите на изображение ниже, скопированного из here:

Теперь о вашем вопросе, следующее объяснение предполагая такую ​​же ассоциацию будет использоваться для всей коммуникации. Для связи по нескольким ассоциациям см. Статью от Roni.

Но когда?

Сразу же. На том же соединении/ассоциации. При получении ответа NAction вы должны подождать, пока не будет настроен тайм-аут в вашем приложении. До истечения времени ожидания вы должны получить NEventReport.

Как хранилище вернет мне N-EVENT-REPORT вместе с результатами?

Когда вы получаете ответ NAction от SCP, это означает, что SCP говорит: «Хорошо, я понял, чего вы хотите.Теперь подождите, пока я извлечу ваши данные ... »Итак, вы ждете. Когда SCP готов со всеми данными (контрольный список), он просто отправляет его обратно в ту же ассоциацию через NEventReport. Вы анализируете отчет и делаете свой материал и отправить ответ SCP, говоря «Хорошо; Я закончил с тобой «и закрыть ассоциацию

ли мой SCP AE реализует некоторые функции УПП

Нет (в большинстве случаев),..? Вам не нужно осуществлять какие-либо SCP функции в обоих случаях (одна ассоциация/множественные ассоциации). Вы должны получить NEventReport в той же связи, что и упомянутая выше. DICOM работает в TCPIP. Концепция Client/Server в TCP ограничена только тем, кто устанавливает соединение и кто слушает подключения. соединение установлено, любой может считывать/записывать данные на гнездо.

В редких случаях S CP отправляет NEventReport, инициируя новую ассоциацию самостоятельно. В этом случае SCU необходимо реализовать функции SCP. Насколько мне известно, эта модель не используется. Трудно реализовать эту модель как для SCP, так и для SCU. Он также нуждается в нескольких конфигурациях, которые, как правило, избегают. Таким образом, это можно пренебречь. Я называю это редким, потому что я никогда (по крайней мере до сих пор) не сталкивался с такой реализацией. Но да; это действительный случай по уважительной причине.

Или мне нужно подать запрос N-EVENT на получение отчета N-EVENT-REPORT?

Нет; как сказано выше. См. this.

J.3.3 Уведомления
В DICOM ОПЗ, которые утверждают на соответствие настоящему SOP класса как SCP должен вызывать запрос N-EVENT-REPORT. DICOM AE, которые заявляют о соответствии этому SOP-классу в качестве SCU, должны получать запрос N-EVENT-REPORT.

Это говорит, SCU должен быть в состоянии процесса NEventReport. Это НЕ будет выдавать.

Answer 2

Возможны три различных последовательности событий. Я мог бы описать их здесь, но эта статья действительно отличная: Roni's DICOM blog

Мне нечего добавить к тому, что там написано.