Вы просматриваете старую версию данной страницы. Смотрите текущую версию.

Сравнить с текущим просмотр истории страницы

« Предыдущий Версия 28 Следующий »


Паспорт

ЕПГУ



Метод (код)

Описание

Шаг

Описание

Базовый сценарий

1GetPatientInfo

Предоставление информации о наличии сведений о пациенте в МИС

ValidatePerson

Этап идентификации данных пациента

1. Пациент, с помощью ЕПГУ, вводит первичные данные для записи и КУ ФЭР отправляет запрос о доступности услуг пациенту в центральную базу РМИС.

Входные данные:

  • Patient_Data - данные пациента (номер полиса ОМС, серия полиса ОМС, СНИЛС, ФИО, дата рождения, пол)
  • Session_ID - идентификатор сессии
  • Pass_referral - признак необходимости возврата перечня направлений гражданина
  • Patient_Info_Kind - тип запрашиваемой информации о пациенте (ATTACHMENT – сведения о лечащих врачах, D_OBSERVATION – сведения о диспансерном наблюдении, REFERRAL – сведения о направлениях гражданина)


2. В центральной базе РМИС происходит попытка поиска данных о пациенте в системе при помощи получаемых обязательных параметров и идентификатора сессии.

  • Пациент должен быть прикреплен к какой-либо организации, поэтому перед записью требуется получить ответ от места прикрепления. Прикрепления проверяются по регистру сведений "тмб_ПрикрепленияПациентовКМО".
  • Если пациент не найден ни в одной из МИС, то возвращается ошибка PATIENT_NOT_FOUND с сообщением "Пациент не найден."
  • Если пациент найден, в ответе возвращаются выходные данные о нем
  • Если попытка поиска оказалась неудачной, то выдается исключение о внутренней ошибке системы INTERNAL_ERROR

Выходные данные:

  • Session_ID - идентификатор сессии
  • Patient_Id - идентификатор пациента в РМИС
  • Error - ошибка (PATIENT_NOT_FOUND - пациент не найден, INTERNAL_ERROR - внутренняя ошибка
1.1GetReferralInfo

Предоставление данных о направлении пациента по номеру направления

Referral

Этап выбора направления


2GetMOInfoExtended

Предоставление списка подразделений МО, в которые пациенту доступна запись к специалистам

MO

Этап получения списка медицинских организаций

3. КУ ФЭР отправляет запрос о доступных МО и их подразделений по прикреплению пациента в центральную базу РМИС.

Входные данные:

  • Session_ID - идентификатор сессии
  • Patient_Id - идентификатор пациента в РМИС
  • Service_Posts - список должностей
  • Booking_Type - тип планирования (один из {APPOINTMENT, DISPENSARY(ADVANCED), VACCINATION(COVID)}

4. Центральная база РМИС по идентификатору сессии определяет пациента.

  • При помощи идентификатора и РС ФедеральныеВебСервисыЗаписьНаПриемСессии запрашиваются данные о сессии по ее идентификатору, если сессия истекла в ответе возвращается ошибка SESSION_TIMED_OUT с сообщением "Истекло время ожидания в рамках сессии"
  • По указанным должностным кодам составляется список всех должностей
  • Если переданы должности и включена настройка "ИспользоватьПолучениеПодразделенийВМОПрикрепления", то центральная база обращается к подразделениям с фильтрацией по должностям, иначе отбор по должностям действовать не будет - поиск будет происходить по всем должностям

Далее, в зависимости от настройки организации "ИспользоватьПолучениеПодразделенийВМОПрикрепления" формируется список доступных подразделений (см.Примечание в п6. тмб_ПолучитьДоступныеЛПУРабочиеМестаСпециальности):

  • Если значение настройки = Нет, то список формируется в центральной базе (справочник "тмб_ОрганизацииУзлаОбменаСМИС"). Если передан список должностей, то производится сопоставление по табличной части «Должности подразделения» справочника «Организации узла обмена с МИС. Если для подразделения не указаны должности, то отбор по должности на подразделение не действует, т.е. выводится всегда. Если был передан параметр "Booking_Type", то дополнительно осуществляется подбор по меткам "Appointment, Dispensary, Vaccination" справочника "тмб_ОрганизацииУзлаОбменаСМИС"

  • Если значение настройки = Да и был передан список должностей, то запрос перенаправляется в МИСы прикреплений. В МИСе происходит поиск подразделений, в которых есть доступные слоты. Полученный список передается обратно в центр, где формируется общий ответ для КУ ФЭР. Отбор по должностям осуществляет по указанной должности врача (справочник "Сотрудники")

  • Если в служебной переменной количество доступных подразделение равно нулю, выводится ошибка NO_DATA_FOUND с сообщением "По запросу данных не найдено"

  • В случае если в МИС пациент не был найден, выдается исключение NO_DATA_FOUND с сообщением "По запросу данных не найдено"

  • При помощи функции тмб_ПолучитьДоступныеЛПУРабочиеМестаСпециальности общего модуля тмб_СервисЗаписьНаПрием отбираются по должностям и возвращаются только те подразделения, в которых присутствуют свободные слоты

  • Если подразделений не найдено, то также возвращается исключение NO_DATA_FOUND

  • В случае если попытка запроса оказалась неудачной, выдается исключение с ошибкой INTERNAL_ERROR и сообщением "Внутренняя ошибка системы"

Выходные данные:

  • Session_ID - идентификатор сессии NO_DATA_FOUND
  • MO_List - список МО
  • Error - ошибка (NO_DATA_FOUND - по запросу данных не найдено, INTERNAL_ERROR - внутренняя ошибка системы, SESSION_TIMED_OUT - истекло время ожидания в рамках сессии)
3GetServicePostSpecsInfo

Предоставление списка должностей медицинских специалистов, доступных пациенту в выбранном подразделении МО

ServiceOrSpecs

Этап получения списка должностей по медицинской организации

5. Пациент выбирает необходимое подразделение и КУ ФЭР отправляет запрос в центральную базу РМИС о доступных мед. специальностях.

Входные данные:

  • Session_ID - идентификатор сессии
  • MO_Id - идентификатор подразделения МО

6. В центральной базе создаются запросы для извлечения параметров операции SOAP в строковом виде по идентификаторам сессии и подразделения.

  • Центральная база РМИС, в зависимости от выбранного подразделения МО, перенаправляет запрос в периферийную базу.
  • Если узел обмена с МИС не был найден, то выдается ошибка NO_DATA_FOUND с сообщением "По запросу данных не найдено". Получаются данные сессии из РС ФедеральныеВебСервисыЗаписьНаПриемСессии по идентификатору
  • Если сессия не найдена, то выдается ошибка SESSION_TIMED_OUT с сообщением "Сессия не найдена"
  • Запрос перенаправляется в МИС, проверяется подразделение по указанному УИД, если оно не найдено возвращается ошибка по запросу данных
  • Если пациент или соглашение из РС ПолисыСтрахованияПациентов не были найдены, выдается ошибка NO_DATA_FOUND с сообщением "По запросу данных не найдено"
  • Отбираются рабочие места и специальности
  • Отбираются и заполняются специальности в зависимости от прикрепления, если таблица оказалась пустой, выводится соответствующая ошибка, иначе заполнение из выходных данных
  • В случае если попытка запроса оказалась неудачной, выдается исключение с ошибкой INTERNAL_ERROR и сообщением "Внутренняя ошибка системы"


Подключение к периферийной базе осуществляется под пользователем, под которым произведено подключение в центральной базе (WEBEMP_FWS_FER, WEBEMP_FWS_FER_OKAS, WEBEMP_FWS_FER_TM). Для успешной авторизации, необходимо чтобы в центральной базе в безопасном хранилище были записаны пароли от этих учетных записей.

Выходные данные:

  • Session_ID - идентификатор сессии
  • Service_Post_Specs - список должностей (специальностей) и медицинских услуг
  • Error - ошибка (NO_DATA_FOUND - по запросу данных не найдено, INTERNAL_ERROR - внутренняя ошибка системы, SESSION_TIMED_OUT - истекло время ожидания в рамках сессии)
4GetMOResourceInfo

Предоставление сведений о подразделении МО и медицинских специалистах (или кабинетах)

Resource

Этап получения списка медицинских ресурсов по медицинской должности

7. Пациент выбирает необходимую должность или медицинскую услугу и КУ ФЭР отправляет запрос списка доступных специалистов в центральную базу РМИС.

Входные данные:

  • Session_ID - идентификатор сессии
  • Service_Posts - информация о должности и услуге
  • MO_OID_List - перечень МО/СП МО
  • Start_Date_Range - дата начала периода предоставления информации о наличии/отсутствии свободных слотов
  • End_Date_Range - дата окончания периода предоставления информации о наличии/отсутствии свободных слотов
  1. В центральной базе РМИС в зависимости от выбранного подразделения МО, перенаправляет запрос в периферийную базу МО. Доступные специалисты (или кабинеты) определяются по доступным медицинским рабочим местам. В центральной базе создаются запросы для извлечения параметров операции SOAP в строковом виде по идентификаторам сессии и подразделения.
  • При помощи идентификатора и РС ФедеральныеВебСервисыЗаписьНаПриемСессии запрашиваются данные о сессии по ее идентификатору, если сессия истекла в ответе возвращается ошибка SESSION_TIMED_OUT с сообщением "Сессия не найдена"
  • Если OID MO заполнено, то используя Справочники.НаправившаяОрганизация.ПолучитьНаправившуюОрганизациюПоОИД формируется узел обмена с МИС из РС сшпАдресаНаправившихОрганизаций и идентификатор МО.
  • Если в данных сессии отсутствует узел обмена, то выдается ошибка NO_DATA_FOUND с сообщением "По запросу данных не найдено"
  • Запрос перенаправляется в МИС и получает данные сессии, если сессия ранее не была создана, то функция "GetMOResourceInfo" вызвана сразу после функции "GetPatientInfo", создается сессия по переданным параметрам
  • Если по указанным данным не удалось найти организацию или подразделения, то возвращается исключение NO_DATA_FOUND с сообщением "По запросу данных не найдено"
  • Если пациент или соглашение не были найдены, то аналогично возвращается NO_DATA_FOUND
  • Осуществляется получение доступных рабочих мест. Функция принимает на вход: дата приема, сотрудник, подразделение, адрес подразделения, рабочее место, специальность, НМУ. Полученная таблица сортируется по врачу и рабочему месту по колонкам с удалением всех дубликатов
  • Если рабочие места не найдены, то возвращается исключение NO_DATA_FOUND с сообщением "Данные не найдены"
  • Осуществляется получение доступных слотов. Функция принимает на вход необходимые даты и возвращает слоты в общем виде по тегам рабочего места, даты, идентификатора слота, а также кабинет
  • Если при получении данных ресурса равно нулю, то возвращается исключение NO_DATA_FOUND, иначе заполнение из выходных данных
  • В случае если попытка запроса оказалась неудачной, выдается исключение с ошибкой INTERNAL_ERROR и сообщением "Внутренняя ошибка системы"


Примечание

При этом также возвращаются рабочие места, у которых есть слоты Первичного приема, но они все заняты другими пациентами. В таком случае выводится тег, но вместо <Available_Dates> выводится блок <No_Schedule_Reason> с причиной "NO_AVAILABLE_SLOTS". Если есть хотя бы один свободный слот, то расписание выводится стандартным способом

Выходные данные:

  • Session_ID - идентификатор сессии
  • MO_Resource_List - информация о доступных МО/СП МО и ресурса
  • Error - ошибка (NO_DATA_FOUND - по запросу данных не найдено, INTERNAL_ERROR - внутренняя ошибка системы, SESSION_TIMED_OUT - истекло время ожидания в рамках сессии)
5GetScheduleInfo

Получение свободных слотов выбранного медицинского специалиста

Slot

Этап получения расписания по медицинскому ресурсу

9. Пациент выбирает специалиста (или кабинет) и КУ ФЭР отправляет запрос расписания приема выбранного специалиста (или кабинета)

Входные данные:

  • Session_ID - идентификатор сессии
  • Specialist_SNILS - СНИЛС специалиста
  • Room_OID - OID кабинета
  • Room_Id - идентифиатор кабинета в МИС
  • MO_OID - OID СП МО
  • Service_Post - информация о должности и услуге
  • Start_Date_Range - дата, с которой необходимо начать формировать расписание
  • End_Date_Range - дата, до которой необходимо формировать расписание
  • Start_Time_Range - время, с которого необходимо начать формировать расписание на день
  • End_Time_Range - время, до которого необходимо формировать расписание на день


6CreateAppointmentСоздание записи на приём к медицинскому специалисту с указанием даты и времени приёмаBookЭтап записи на получение услуги

ReferralAppointmentInformationПередача сведений о регистрации записи на прием к врачу по направлению



CancelAppointmentОтмена ранее созданной Пользователем записи на прием к врачу








  • Нет меток