Общее описание

Подсистема обмена данными инструментальных исследований (ОДИИ) обеспечивает возможность обмена данными инструментальных исследований между медицинскими организациями Санкт-Петербурга.

Подсистема «ОДИИ» обеспечивает:

  1. Централизованный учет данных пациентов, врачей, диагностического оборудования и PACS-серверов (ЦАМИ);
  2. Хранение данных по бизнес-процессам проведения инструментального исследования, включая данные направления, данные результатов —  медицинских изображений, полученные при выполнении исследования, и протоколы исследований;
  3. Единую идентификацию проведенных инструментальных исследований;
  4. Доступ к просмотру информации о выполненных исследованиях из всех информационных систем, подключенных к ГИС «РЕГИЗ».

Информационное взаимодействие

Подсистема «ОДИИ» поддерживает бизнес-процесс проведения инструментального исследования, состоящий из трех этапов информационного взаимодействия:

  1. Назначение на инструментальное исследование
  2. Выполнение исследования
  3. Формирование результата исследования

Информационное взаимодействие осуществляется с помощью обмена данных между следующими информационными системами ГИС «РЕГИЗ»:

  1. Информационная система направляющей медицинской организации (МО)
    1. Учет пациентов
    2. Учет направляющих врачей
    3. Учет случаев обслуживания
    4. Формирование заявок (направление)
  2. Информационная система целевой медицинской организации (МО)
    1. Учет врачей, утвердивших результат
    2. Учет информации об устройствах (диагностических аппаратов)
    3. Формирование результатов исследования
    4. Локальный worklist
      1. Учет заданий для оборудования
  3. Подсистема «Управление очередями пациентов» (УО)
    1. Учет направлений и активных профилей МО
  4. Подсистема «ОДИИ»
    1. учет заявок на исследование
    2. учет результатов
    3. учет пациентов, которым назначено исследование
    4. учет направляющих врачей, врачей исполнителей
    5. учет информации об устройствах (диагностических аппаратов)
    6. учет информации о PACS-серверах
  5. Глобальный worklist
    1. Учет заданий для модальности
    2. Учет сообщений о статусе готовности
  6. ЦАМИ
    1. Учет данных PACS-серверов
    2. Учет изображений и протоколов исследований
  7. Портал врача
    1. Просмотр данных исследований

Запуск обмена данными

Для запуска подсистемы «ОДИИ» в медицинской организации (МО) необходимо выполнить следующее:

  1. Информационная система МО должна быть интегрирована с подсистемой «ОДИИ» РЕГИЗ в соответствии с Регламентом (см. раздел интеграционные профили) для обмена данными результатов исследований;
  2. Информационная система МО должна быть интегрирована с подсистемой «УО» для обмена данными направлений и активными профилями МО;
  3. Диагностическое оборудование целевой МО должно быть интегрировано с ЦАМИ и глобальным worklist, при отсутствии работающего локального worklist;
  4. Рабочие места врачей должны быть оборудованы компьютерами с установленной и интегрированной с РЕГИЗ информационной системой.

Тестовая площадка

Тестовый стенд ОДИИ развернут.

http://r78-rc.zdrav.netrika.ru/imaging/exlab/api

Всё желающие подключиться могут отправлять запросы на адрес технической поддержки Нетрики zdrav-support@netrika.ru для получения доступа.

«ЧаВо»

  1. Как получить доступ к тестовой среде ОДИИ (если это где-то описано, то дайте, пожалуйста, ссылку - документов много уже теряемся в них)?

Ссылка на тестовую площадку http://r78-rc.zdrav.netrika.ru/imaging/exlab/api

  1. Если мы делаем интеграцию МИС, в которой, в том числе, оформляются заключения на диагностические исследования и при этом направления есть только внутренние (то есть на КТ, МРТ Рентген нет внешних направлений, они формируются только внутри учреждения), то

2.1. нужно ли реализовывать полный сценарий взаимодейтсвия: заявка - результат на заявку?
2.2. правильно ли я понял, что при послыке заявки в ОДИИ именно в ОДИИ формируется accession number? Или мы его можем сформировать на нашей стороне для прямой интеграции с PACS сервером, использующимся в учреждении?

  1. Внутренние направления: 
    2.1 Для данного сценария достаточно прислать в ОДИИ результат без заявки.
    2.2 В проекте Санкт-Петербурга все заявки (направления) должны регистрироваться в сервисе Управления Очередями (не ОДИИ). Сервис управления очередями будет генерировать уникальный идентификатор направления, который сервис ОДИИ будет использовать в качестве accession number.
    Таким образом: Если заявка приходит через сервис УО, то в качестве accession number используете уникальный идентификатор направления УО.
    Если заявка не регистрируется в сервисе УО, и вы проходите сценарий внутреннего направления, то можете использовать свой собственный accession number.

  2. В заявке мы должны передавать данные о предполагаемом времени (occurancetimming) и аппарате (performer(device)), а если на момент заявки это не известно? Почему эти параметры являются обязательными?

Все верно, необязательные данные для заявки. Высылаю вам актуальную версию ОИП. Еще раз отмечу, что заявки все должны регистрироваться через сервис УО. После подтверждения заявки целевой МО, целевая МО должна прислать в сервис ОДИИ запрос POST Schedule, в которой передает данные об устройстве и расписании, которых нет в сервисе УО.

  1. Передача результатов раздел ImagingStudy:

4.1. Возможна передача двух вариантов индетификаторов, тогда как в заявке вроде только ACSN? Я что-то неправильно понял?

Если можно использовать какой-то свой идентификатор, то как его передавать в заявке? или заявке всегда присваивается на стороне ОДИИ ACSN, а результат можно передать, используя свой идентификатор?

4.2. Endpoint:

4.2.1. Если PACS не поддерживает формат обмена, тот, что ожидает ОДИИ, то как быть?

4.2.2. Какой url нужно укзывать,в защищенной сети?

4.2.3. Какие форматы могут быть указаны payloadType?

4.2.4. в описании параметр назван address, но в примере  "url": "https://pacs.hospital.org/wado-rs"

Как правильно? Надо указывать полный путь к исследованию во viewer?

Можно ли на первом этапе обойтись без передачи этого раздела?

  1. По ImagingStudy
    4.1. ImagingStudy.identifier должен всегда содержать два идентификатора: accession number и studyUID, см. примеры. + в данном ресурсе можно передавать другие идентификаторы исследования Series Instance UID и SOP Instance UID.
    О каких своих идентификаторах идет речь? Если вы имеете в виду accession, то в Bundle результата по заявке он должен совпадать с accession заявки (см. описание параметра ImagingStudy.identifier.value). В Bundle результата без заявки такой проверки нет, можно передавать свой.
    4.2. Endpoint
    4.2.1 Параметр ImagingStudy.endpoint необязательный. Можно не передавать.
    4.2.2 Адрес, по которому можно получить исследование.
    4.2.3 В ОИП указан OID справочника, по которому в НСИ можно посмотреть список типов соединения 2.16.840.1.113883.4.642.1.1140
    4.2.4. Нет, полный путь до исследования не надо указывать. Ссылку на исследования должен  сформировать  сам клиент по данным изображения (accession number/studyUID/instance UID и адреса). Как писала выше данный ресурс является необязательным в результате.
Закрыть меню