Подсистемы, обеспечивающие доступ граждан и организаций к информации и сервисам в рамках интерфейсов. Подсистема ведения фактов и параметров нетрудоспособности
Подсистема должна удовлетворять следующим требованиям:
Подсистема должна обеспечивать выдачу по запросу номера листа нетрудоспособности, для этого данная подсистема должна быть интегрирована с подсистемой генерации номеров листков нетрудоспособности (часть Пилотной подсистемы). Запрос номера должен инициироваться приложением, установленным в медицинской организации. Запрос, направляемый от медицинской организации на получение номера должен содержать все атрибуты организации, параметры факта нетрудоспособности, необходимые для открытия листка нетрудоспособности.
Выданный номер должен быть уникальным. Любой запрос к подсистеме генерации номеров должен содержать следующие атрибуты:
ОГРН медицинской организации.
Адрес медицинской организации, выдающей листок нетрудоспособности (по КЛАДР).
Дата и время запроса.
Внутренний идентификатор запроса подсистемы ведения данных о фактах и параметрах нетрудоспособности.
Должны быть реализованы сервисы, позволяющие:
сохранять все атрибуты вновь открытого в медицинской организации ЛН;
получать данные ЛН по ключу. При этом должно предусматриваться использование нескольких вариантов ключей для идентификации ЛН:
номер листа нетрудоспособности;
СНИЛС или фамилия и регистрационный номер страхователя в Фонде социального страхования РФ.
обновлять атрибуты ранее открытого ЛН.
Должен быть разработан регламент и стандарт обмена данными между информационными системами медицинских организаций и подсистемой ведения фактов и параметров нетрудоспособности. Данный регламент должен описывать, каким образом должно осуществляться взаимодействие Фонда и медицинских организаций при обмене данными о фактах и параметрах нетрудоспособности. Разработанный стандарт обмена данных должен содержать исчерпывающий перечень атрибутов, необходимых для реализации всех процессов, связанных с созданием и ведением листка нетрудоспособности. Также при разработке атрибутного состава, описывающего ЭЛН, необходимо предусмотреть возможность хранения номера бумажного листа нетрудоспособности, выданного в дополнение к электронному (применительно к переходному периоду)
Все процессы обмена данными между медицинскими организациями и подсистемой ведения фактов и параметров нетрудоспособности должны быть защищены при помощи электронной цифровой подписи.
Подсистема работы с ЭЦП.
Подсистема должна удовлетворять следующим требованиям:
Обеспечивать защищенное взаимодействие подсистемы ввода данных от страхователей с внешним контуром (сеть Интернет).
Обеспечивать идентификацию сторон взаимодействия.
Обеспечивать защищенное взаимодействие подсистемы ведения фактов и параметров нетрудоспособности с информационными системами медицинский организаций, расположенными во внешнем контуре (сеть Интернет).
Обеспечивать защиту от изменений (подделки) документа.
Обеспечивать контроль целостности передаваемой информации.
Подсистема ввода и контроля данных (подсистема Пилотного проекта).
Данная подсистема является частью Пилотной подсистемы. Подсистема ввода и контроля данных должна быть доработана в части добавления нового потока данных (данные о фактах и параметрах нетрудоспособности), соответственно, должны быть реализованы все процессы доведения указанных данных до подсистемы расчета и назначения выплат.
Подсистема должна удовлетворять следующим требованиям:
Должны быть созданы структуры хранения данных о фактах и параметрах нетрудоспособности, полученных из подсистемы ведения данных о фактах и параметрах нетрудоспособности.
Подсистема должна быть интегрирована с подсистемой ведения данных о фактах и параметрах нетрудоспособности с целью загрузки соответствующих данных в подсистему ввода и контроля данных. Загружаемые из подсистемы ведения данных о фактах и параметрах нетрудоспособности сведения должны характеризоваться набором статусов для дальнейшей обработки поступившей информации подсистемой ввода и контроля данных. Перечень статусов должен отражать основные состояния листка нетрудоспособности:
создан (открыт);
открыт, обновлен;
закрыт;
частично оплачен (или предъявлен к оплате), случай не закончен.
«оплачен/не оплачен»
Представленный перечень статусов является основным и предполагает наличие дополнительных статусов, характеризующих промежуточное состояние листка нетрудоспособности.
Помимо статуса факт нетрудоспособности должен содержать данные о дате изменения статуса, а также идентификатор стороны, инициировавшей изменение статуса.
Данные, загруженные в подсистему ввода и контроля, должны проходить форматно-логический контроль, аналогичный реализованному для данных в Пилотной подсистеме.
Подсистема ввода и контроля должна быть интегрирована с подсистемой ввода данных от страхователей в целях предоставления данных о нетрудоспособности застрахованных страхователям. Данные из подсистемы ввода и контроля должны быть загружены в подсистему ввода данных от страхователей сразу после закрытия листка нетрудоспособности в медицинской организации.
Должны быть разработаны регламенты и процессы забора данных из подсистемы ввода данных от страхователей. Данные необходимо выгружать после того, как информация о нетрудоспособности будет дополнена сведениями от страхователя для дальнейшей передачи полного пакета информации о нетрудоспособности в подсистему расчета и назначения выплаты. Информация, загруженная из подсистемы ввода данных от страхователей, должна проходить форматно-логический контроль. Необходимый перечень форматно-логических проверок для загружаемых данных представлен в приложении Таблица . Форматно-логический контроль.
В подсистеме ввода и контроля данных должен быть разработан набор интерфейсов для просмотра всей поступившей в подсистему информации. Должны быть разработаны интерфейсы для просмотра данных, поступивших от:
Медицинских организаций.
Страхователей.
Должен существовать набор процедур обновления статусов записей из подсистемы расчета и назначения выплат для дальнейшей трансляции данных в подсистему раскрытия информации. Функционал обновления статусов данных должен позволять получить основные статусы записей из подсистемы расчета и назначения выплат.
Подсистема ввода данных и контроля должна быть интегрирована с подсистемой раскрытия информации для возможности предоставления информации о пособиях в личный кабинет клиента Фонда.
Подсистема генерации номеров (подсистема Пилотного проекта).
Подсистема является частью Пилотного проекта и должна быть доработана в части реализации возможности:
Генерировать номер листка нетрудоспособности по запросу подсистемы ведения данных о фактах и параметрах нетрудоспособности.
Вести историю запросов на генерации номера.
Передавать созданный номер в справочник выданных номеров листов нетрудоспособности для дальнейшего его использования при проверке поступающих данных.
Иметь интерфейсы просмотра журналов обращений с возможностью просмотра части выданного номера. Для просмотра должна быть доступна только серийная часть номера – 9 знаков.
Подсистема расчета и назначения выплат (подсистема Пилотного проекта).
Подсистема должна удовлетворять следующим требованиям:
Должны быть реализованы сервисы, которые будут вызывать функционал расчета пособий. Данные сервисы должны быть разработаны таким образом, чтобы при вызове данного сервиса с набором атрибутов факта нетрудоспособности сервис возвращал сумму, которая должна быть начислена гражданину.
Набор сервисов должен реализовывать расчет всех пособий по нетрудоспособности и материнству, расчет и выплата которых реализована в Пилотной подсистеме.
Сервисы должны быть доступны для вызова из подсистемы раскрытия информации и подсистемы ввода и контроля данных.
Расчет любого пособия должен производиться не более чем за 30 секунд.
Подсистема ввода и загрузки сведений об услугах, оказанных инвалидам
С целью ведения сведений об услугах, оказанных инвалидам, Исполнитель должен разработать соответствующее автоматизированное рабочее место сотрудника Фонда. Указанный АРМ должен использоваться в части внесения данных при первичной регистрации обращения инвалида в региональные отделения ФСС РФ. Все компоненты данной подсистемы должны располагаться в центре обработке данных Фонда социального страхования РФ.
Ниже приведен перечень информации, подлежащей ведению в рамках подсистемы:
№
|
Атрибут
|
Поставщик
|
1
|
Адрес фактического проживания
|
ФСС РФ
|
2
|
Телефон
|
3
|
Адрес электронной почты
|
4
|
Дата постановки на учет в ФСС РФ
|
5
|
Место постановки на учет в ФСС РФ
|
6
|
Категория граждан, имеющая право на получение государственной социальной помощи в виде набора социальных услуг
|
7
|
Банковские реквизиты инвалида
|
В ходе разработки подсистемы необходимо реализовать форматно – логический контроль в части проверки корректности вводимых оператором данных. Также оператор должен иметь возможность внесения изменений в данные, полученные от различных источников, при помощи подсистемы загрузки данных, в том числе заполнения недостающей информации в ручном режиме.
Должны быть разработаны интерфейсы для ручного ввода данных об инвалидах. Данные интерфейсы должны быть опубликованы на портале Фонда (вывод интерфейса на портал фонда осуществляют специалисты Фонда). Интерфейсы должны обеспечивать функциональность по вводу всех необходимых данных, основные атрибуты, которые должны быть представлены в интерфейсах, представлены выше.
Интерфейсы должны быть эргономичными, поля форм должны быть максимально формализованы.
Также подсистема должна обеспечивать процесс загрузки данных от внешних источников, обеспечивать синхронизацию полученных данных.
В части сбора данных от местных органов исполнительной власти в рамках подсистемы должно быть предусмотрено взаимодействие со следующими источниками информации:
Органы медико–социальной экспертизы
В бюро МСЭ производится первичная регистрация граждан в качестве инвалидов. Потребителями данных от бюро МСЭ являются региональные органы ПФР и ФСС РФ. Бюро МСЭ предоставляет следующие данные об инвалидах:
-
1
|
Выписка из акта №
|
2
|
К справке серия
|
3
|
К справке №
|
4
|
Фамилия
|
5
|
Имя
|
6
|
Отчество
|
7
|
Адрес места жительства
|
8
|
Степень утраты профессиональной трудоспособности в процентах в связи с несчастным случаем/профессиональным заболеванием
|
9
|
Дата несчастного случая /профессионального заболевания
|
10
|
Срок установления степени утраты профессиональной трудоспособности с
|
11
|
Срок установления степени утраты профессиональной трудоспособности по
|
12
|
Дата очередного освидетельствования
|
13
|
Степень утраты профессиональной трудоспособности в процентах за пропущенный период
|
14
|
Степень утраты профессиональной трудоспособности за пропущенный период с
|
15
|
Степень утраты профессиональной трудоспособности за пропущенный период по
|
16
|
Акт №
|
17
|
Дата выдачи выписки
|
Необходимо расширить данный перечень, в части добавления дополнительной информации. Расширение перечня атрибутов должно быть отражено в разработанном формате и регламенте обмена данными с бюро МСЭ.
№
|
Атрибут
|
Поставщик
|
1
|
Персональные данные
|
ФИО
|
бюро МСЭ
|
Дата рождения
|
Пол
|
2
|
Паспортные данные
|
Серия
|
Номер
|
Доп. информация
|
3
|
Группа инвалидности
|
4
|
Причина инвалидности (инвалидизирующее заболевание)
|
6
|
Дата первичного установления инвалидности
|
7
|
Дата истечения срока инвалидности
|
8
|
Дата очередного освидетельствования
|
9
|
Реквизиты первичного акта бюро МСЭ
|
Дата
|
Номер
|
Код/наименование бюро
|
10
|
Реквизиты текущего акта бюро МСЭ
|
Дата
|
Номер
|
Код/наименование бюро
|
11
|
Тип программы реабилитации
|
ИПР/ПРП
|
12
|
Данные первичной ИПР/ПРП
|
№
|
Дата выдачи
|
Реквизиты бюро МСЭ
|
13
|
Данные текущей ИПР/ПРП
|
№
|
Дата выдачи
|
Реквизиты бюро МСЭ
|
14
|
Перечень ограничений основных категорий жизнедеятельности
|
15
|
Мероприятия медицинской реабилитации
|
16
|
Мероприятия профессиональной реабилитации
|
17
|
Мероприятия социальной реабилитации
|
18
|
Необходимость в обеспечении ТСР
|
19
|
Необходимость в обеспечении санаторно- курортным лечением
|
20
|
Необходимость в постороннем уходе
|
21
|
Возможность реабилитации
|
Региональные органы Пенсионного фонда РФ
-
№
|
Атрибут
|
Поставщик
|
1
|
СНИЛС
|
ПФР
|
2
|
Наличие отказа от государственных услуг полностью
|
|
Наличие отказа от государственной услуги по обеспечению лекарственными средствами
|
|
|
Наличие отказа от государственной услуги по обеспечению санаторно-курортным лечением
|
|
|
Наличие отказа от государственной услуги по обеспечению проездом к месту лечения
|
|
Органы ЗАГС
№
|
Атрибут
|
Поставщик
|
1
|
Дата окончательного исключения из списка инвалидов
|
ЗАГС
|
Перечень атрибутов должен быть уточнен Исполнителем и согласован с Заказчиком на этапе проектирования системы.
В рамках создания подсистемы загрузки данных (Пилотного проекта) необходимо разработать форматы обмена данными между данной подсистемой и поставщиками информации (региональными органами исполнительной власти), а также форматы обмена с потребителями информации данной подсистемы.
Подсистема ведения сведений об инвалидах
Подсистема ведения сведений об инвалидах должна обеспечивать централизованное хранение всех данных об инвалидах, полученных от органов исполнительной власти, а также информации, собираемой сотрудниками ФСС РФ в процессе взаимодействия с инвалидами, включая сведения о предоставленных ТСР и оказанных санаторно-курортных услугах.
Также подсистема ведения сведений об инвалидах предусматривает ведение следующих связанных ресурсов данных:
данные о выданных ТСР: предусматривается хранение документов и данных, отражающих факты взаимодействия конкретного органа исполнительной власти с инвалидами в рамках оказания им государственных услуг в части предоставления технических средств реабилитации;
данные санаторно – курортного лечения: предусматривается хранение документов и данных, отражающих факты взаимодействия конкретного органа исполнительной власти с инвалидами в рамках оказания им государственных услуг в части предоставления санаторно – курортного лечения;
данные о выданных компенсациях;
данные об оказанных услугах по проезду к месту лечения;
документы, полученные от инвалида;
данные о проведенных реабилитационных мероприятиях;
данные для регресса;
обращения инвалидов в ФСС РФ.
Подсистема интеграции данных для передачи ведений об инвалидах
Подсистема должна удовлетворять следующим требованиям:
Должна иметь набор веб сервисов для возможности интеграции с внешними источниками данных, перечень источников данных и состав данных представлен в пункте 6.2.1.
Также подсистема интеграции должна позволять организовывать обмен данными с внешними источниками посредством файлов (в случаях, когда взаимодействие по средствам веб сервисов организовать невозможно).
Весь обмен данными должен быть реализован через подсистему работы с ЭЦП для обеспечения необходимой достоверности и безопасности.
Подсистема управления контентом веб сайтов Фонда и его региональных отделений.
Данная подсистема должна обеспечивать как централизованное, так и локальное управление веб сайтами Фонда, заполнение их информацией и публикацию сервисов.
Состав информации и сервисов, размещаемых на сайтах Фонда и его региональных отделений, должен быть определен с учетом ключевых групп получателей услуг Фонда, их ожиданий, потребностей и типовых сценариев взаимодействия с сайтами Фонда, а также с учетом нормативных правовых актов, определяющих состав информации и сервисов, подлежащих размещению на сайтах органов государственной власти и внебюджетных фондов.
В частности, Подсистема должна позволять размещать информацию о структуре и полномочиях Фонда и его территориальных органов, о планах деятельности и результатах их выполнения, актуальную нормативную правовую информацию, сведения об оказываемых услугах и порядке их получения, о порядке приема обращений и иную социально значимую информацию. На сайтах также должны быть размещены сервисы, связанные с получением услуг Фонда. Полный состав информации и сервисов должны быть определены Исполнителем в рамках выполнения работ.
Подсистема должна позволять обновлять информацию в части следующего функционала:
Редактирование текстов и изображений;
Добавление разделов и страниц;
Просмотр произведенных изменений.
Подсистема должна позволять выполнять следующие действия с любыми элементами страницы:
Редактирование;
Удаление;
Перемещение (изменение порядка отображения);
Добавление однотипных элементов.
Централизованное управление, размещение информации и сервисов должно иметь приоритет выше локального.
|
