Казначейство России Методологические подходы к созданию, ведению, изменению и применению классификаторов, реестров и иных информационных ресурсов и созданию. - презентация

1 Казначейство России Методологические подходы к созданию, ведению, изменению и применению классификаторов, реестров и иных информационных ресурсов и созданию единой информационной среды в сфере систематизации и кодирования информации Заместитель руководителя А.Т. Катамадзе г. Москва г.

2 Информационная среда До электронного правительства Текущая ситуация Будущее Потребность в локальном взаимодействии Потребность в обмене данными каждого со многими: > 300 ИР федерального уровня > видов данных > 2 млрд. реестровых записей Нарастание потребности в обмене данными всех со всеми, в т.ч. с базами данных 85 субъектов РФ, > 24 тыс. МО 2

3 Существующая проблема При выполнении гос. функций формируется множество реестров, регистров, кадастров и пр. Это привело к образованию баз данных с разрозненными сведениями об одних и тех же объектах и субъектах правоотношений. В итоге: Данные не достоверны - ошибки при многократном вводе Данные не актуальны - где-то обновлены, где-то нет в зависимости от заявителя Первичные документы проверяет каждый ФОИВ – избыточно, риски ошибок Данные без идентификаторов - усложняет обмен Интеграция друг с другом всех ресурсов – дорого, не масштабируемо Задача: обеспечить обмен актуальными данными между всеми инф. ресурсами на постоянной основе. Нужны новые подходы! 3

4 План мероприятий по формированию методологии систематизации и кодирования информации… утвержденный поручением А.В. Дворковича от 31 июля 2014 г. АД-П (далее – План мероприятий) Концепция методологии систематизации и кодирования информации, а также совершенствования и актуализации общероссийских классификаторов, реестров и справочников (далее – Концепция методологии), утвержденная распоряжением Правительства Российской Федерации от 10 мая 2014 г. 793-р. Постановление Правительства Российской Федерации «О порядке создания, ведения, изменения и применения отдельных информационных ресурсов» (далее – Постановление) (пункт 1.1 Плана мероприятий). Концепция создания единой информационной среды (далее - Концепция) в сфере систематизации и кодирования информации (пункт 1.2 Плана мероприятий). Концепция методологии утверждена Правительством РФ Разработан проект Концепции создания единой информационной среды Разработан проект постановления Правительства Российской Федерации 4 План мероприятий по реализации постановления Правительства Российской Федерации «О порядке создания, ведения, изменения и применения отдельных информационных ресурсов» Разработан План мероприятий к проекту Постановления Новые подходы – в ключевых НПА Конкретные правовые и технологические решения в постановлении!

5 Постановление 928 «О БГИР» - единственный документ. Однако в нормативной правовой базе: Отсутствуют критерии определения источника италонных данных Отсутствуют требования к созданию и ведению ресурсов для обеспечения обмена данными Реестр паспортов БГИР не позволил унифицировать источники данных и их форматы Автоматизация процесса обмена данными между ресурсами предусматривается «каждый» с «каждым», что существенно усложняет обмен Не обеспечен обмен актуальными данными одновременно между всеми ресурсами на постоянной основе Регулирование и реализация в настоящее время Нужны новые правовые и технологические решения! 5

6 Ключевые положения проекта постановления В проекте постановления о порядке создания, ведения, изменения и применения отдельных информационных ресурсов установлены единые требования: Виды ресурсов Правило определения источников данных (где италон) Правила создания и ведения ресурсов Новая технология обмена данными между ресурсами Далее - о каждом! 6

7 Понятия и виды информационных ресурсов Информационный ресурс – «информация, содержащаяся в ГИС, а также иные имеющиеся в распоряжении гос. органов сведения и документы. Информация, содержащаяся в ГИС, является официальной» (п. 9 статьи 14 Закона 149-ФЗ «Об информации…»). Определены два вида ресурсов: Базовые и производные ресурсы – включают данные о конкретных объектах учета (ООО «Ромашка», «Петров П.С.»). Участвуют в обмене данными. Базовые ресурсы – содержат италонные данные. Производные ресурсы – не содержат италонные данные. Классификаторы - группируют объекты по общему признаку/типу («товары», «ОПФ» и пр.) Применяются для структурирования данных в базовых и производных ресурсах. Общероссийские классификаторы – являются обязательными для использования в базовых и производных ресурсах. Ведомственные справочники – для локальных задач. 7

8 Определение источников данных (где италон) 8 Предложены универсальные критерии определения италонных данных. Эталонные данные должны отвечать следующим требованиям: Формирование осуществляется ФОИВ в соответствии с его полномочиями впервые Изменение правового статуса объекта учета влечет необходимость соответствующих изменений данных При формировании проверяются все необходимые первичные документы Дублирующиеся данные вносятся только с использованием италонных данных. Требовать от заявителя первичные документы в целях их формирования запрещено – новое правило

9 Новые требования к ресурсам: Должен быть сформирован в виде ГИС (база данных) Должен применять идентификатор своих италонных данных Должен включать идентификаторы италонных данных других ресурсов Должен применять классификаторы Включение дублирующихся данных с использованием италонных должно осуществляться на постоянной основе и автоматизировано Новая технология - Реестр видов данных, Система Ключевые требования к информационным ресурсам 9

10 Два пути реализации 10 Разработать единые форматы данных и внедрить их во все ресурсы. Обмен самими данными между ресурсами сохранить по принципу «каждый с каждым», не связывая данные ресурсов Связать данные по ID и осуществлять обмен через единую систему. Затем перейти к унификации форматов там, где есть обмен данными I II

11 зап. ИР-италон ID ИР-италона Наим-ие итал. данного База СНИЛС (ПФР) Реестр паспортов (ФМС) ЕГРЮЛ (ФНС) Реестр лицензий в области связи 1 ЗАГС свид-ва о рождении ФИО рожд. ФИО за страх. ФИО гражданина ФИО ген. директора ФИО ген. дир. лиценз. 2 пол рожд. пол за страх. пол гражданина 3 дата рождения дата рожд. за страх. дата рожд. гражданина дата рожд. ген. директора 4 место рождения место рожд. за страх. место рожд. гражданина 5 Реестр паспортов (ФМС) паспорта дата выдачи паспорта дата выдачи паспорта ген. дир. 6 выдавший орган 7 код подразделения 8 ЕГРЮЛ (ФНС) ИННнаим. ю. л. наим. ю.л.- лиценз. 9 ГАР (ФНС) ГАРадрес адрес ф.л.адрес ю.л. адрес ю.л.- лиценз. Реестр видов данных – необходим для I, II подходов 11 Вывод: РВД – вспомогательный инструмент для корректного формирования мета-данных. Вместе с тем, для обмена данными о конкретных объектах нужны дополнительные технологии 1. Формируют перечень данных, которые содержатся в ИР для включения в заявку, 2. Подают через Систему заявку в РВД. Отв. ОИВ ЗАГСПФРФМСФНС Оператор РВД Наборы видов данных используются: - при утверждении НПА об ИР, - для ведения самого ИР. 1. Определяет совместно с ОИВ виды данных (италонные, дублирующиеся, источники, форматы и пр.), 2. Распределяет данные в РВД. Включает описание форматов италонных данных, в т.ч. справочников, 3. Обеспечивает доступ ОИВ к РВД в целях формирования НПА и создания (ведения ИР). Наборы видов данных Дублирующиеся данные Эталонные данные

12 Обмен данными: текущая ситуация – запрос-ответ > 300 ИР ИР- италоны СНИЛС ИР- потребители ИНН, СНИЛС СНИЛС, ИНН, кадастр. СНИЛС, паспорта кадастр. СНИЛС, паспорта, лицензии ИНН ИНН, кадастр. СНИЛС >145 млн. лицензии > 100 тыс. ЗАГС ПФР ФМС ФНС Росреестр СНИЛС, записи ЗАГС > 200 млн. Россвязь потребность > 50 % данных ИР-Э > 57 видов данных – 1 ИР, > 7,5 млн. записей – 1 ИР паспорта > 120 млн. > 4 млрд. запросов в 1 г. (ФОИВ) кадастр. > 120 млн. ИНН ю.л. > 8 млн. Нужны новые подходы к организации обмена данными! 12 Запрос-ответ не позволяет организовать обмен актуальными данными, так как: в ресурсах нет италонных ID, поэтому актуализация италонных данных зависит от заявителя обмен данными каждого со многими не позволяет унифицировать форматы в условиях разной потребности в данных взаимодействие ресурсов «каждый с каждым» не позволяет управлять подпиской на обновления Вывод: данные не достоверны без обращения заявителя – начисление пенсий и льгот умершим каждый проверяет первичные документы – избыточная функция ресурсы-италоны перегружены большим числом повторяющихся запросов нет возможности унифицировать справочники интеграция всех ресурсов со всеми по отдельности – дорого, не масштабируемо

13 Обмен данными: вариант I – запрос-ответ к обновлений ИР-италоны СНИЛС >5 млн. ИНН, СНИЛС >2 тыс. СНИЛС, ИНН, кадастр. СНИЛС, паспорта >14 млн. кадастр. >700 тыс. СНИЛС, паспорта, лицензии ИНН >1 млн. ИНН, кадастр. СНИЛС >145 млн. лицензии > 100 тыс. ЗАГС ПФР ФМС ФНС Росреестр СНИЛС, записи ЗАГС > 200 млн. Россвязь паспорта > 120 млн. кадастр. > 120 млн. ИНН ю.л. > 8 млн обновлений обновлений обновлений обновлений обновлений обновлений ID-ID Каждая измененная реестровая запись порождает столько же разных выгрузок, сколько ИР-потребителей Ресурс-потребитель ежедневно сверяет все свои записи по ID с Целесообразен переход к единой технологии для соблюдения общих правил! 13 Запрос-ответ к обновлений предполагает, что: ресурсы-италоны должны обеспечить хранилище для ежедневных выгрузок обновлений ресурсы-италоны должны генерировать множество отчетов-выгрузок по каждой записи в зависимости от потребителя ресурсы-потребители должны ежедневно сверять все записи с выгрузками обновлений, так как нет единого хранилища связей ID де-факто ресурсы будут иметь разные форматы по схожим сущностям, так как нет единой системы обмена данными необходимо обеспечить включение италонных ID в ресурсы Вывод: реализация возможна, но требует значительных доработок ресурсов-участников обмена и высокой организации владельцев ресурсов при обмене актуальными данными нет возможности администрировать всех в части реализации подхода

14 Обмен данными: вариант II - единая система ИР-италоны СНИЛС ИНН, СНИЛС СНИЛС, ИНН, кадастр. СНИЛС, паспорта кадастр. СНИЛС, паспорта, лицензии ИНН ИНН, кадастр. СНИЛС >145 млн. лицензии > 100 тыс. ЗАГС ПФР ФМС ФНС Росреестр СНИЛС, записи ЗАГС > 200 млн. Россвязь паспорта > 120 млн. кадастр. > 120 млн. ИНН ю.л. > 8 млн. обновлений обновлений обновлений обновлений обновлений обновлений Единая система Сводная обновлений Пакеты обновлений Нет потребности РВД ID-ID НСИ ИР- потребители Подход направлен на оптимизацию сбора, обработки информации и обеспечение актуальности данных в ресурсах! 14 Обмен данными через единую систему предполагает: хранение ежедневных обновлений в одной системе, а не каждым ресурсом генерацию отчетов-выгрузок по записям в зависимости от потребности через единую модель данных, а не каждым хранение связей ID, что позволяет очищать отчеты от необновленных данных – не нужно всем ежедневно сверять все записи переход на унифицированные форматы, там где имеет место обмен данными упрощение процесса включения италонных ID в ресурсы. Возможно обогащение данных Вывод: единая система разгрузит ОИВ от непрофильной деятельности (сервисы выгрузок, обновлений, отчеты потребителям и пр.) и позволит сосредоточить работу над улучшением качества италонных данных уполномоченному органу необходимо создать систему и обеспечить взаимодействие с ней участников обмена

15 Базовый для I и II вариантов: по мере обновления данных включать италонные ID в ресурсы ресурсы - италоны СНИЛС ресурсы - потребители ИНН, СНИЛС СНИЛС, паспорта кадастр. ИНН СНИЛС >145 млн. ПФР ФМС ФНС Росреестр паспорта > 120 млн. кадастр. > 120 млн. ИНН ю.л. > 8 млн. Подходы к включению италонных идентификаторов в информационные ресурсы СНИЛС ПаспортИНН СНИЛС ИНН Заявители кадастр. Дополнительный для II варианта: «обогащение данных» за счет доступа ко всем ресурсам СНИЛС ИР1ИР2 СНИЛС ИНН кадастр СНИЛС – нужен! ИР3 Установлено соответствие СНИЛС-ИНН СНИЛС кадастр ! 15

16 Акт. книга (ЗАГС) св-ва о рожд. ФИОпол дата рожд. место рожд. ФИО родит. … Реестр застр. лиц (ПФР) СНИЛС св-ва о рожд. ФИО застр. пол застр. дата рожд застр. место рожд застр. Сумма начис. страх. взн. … Паспорта пасп.СНИЛС ФИО пол гражд. дата рожд гражд. место рожд гражд. Сумма начис. страх. взн. дата выдачи пасп. отм. о детях … ЕГРЮЛ (ФНС) ИНН ю.л. пасп ФИО ген. дир. дата рожд ген. дир. дата выдачи пасп. ген. дир. … Реестр лицензий в обл. связи лиценз. ИНН ю.л. ФИО ген. дир. вид лиценз. деят. … Для чего необходимо хранить связи идентификаторов в единой системе 16 Вывод: обмен данными основан на иерархии связей ID, а не одной связи ID без хранения в системе иерархии связей ID, каждый ресурс должен запрашивать обновлений по всей цепочке, что существенно усложняет обмен хранение иерархии связей ID в системе также позволяет одновременно обновлять данные всех потребителей непосредственно из ресурсов-италонов Идентификатор каждого последующего ресурса определяет новый правовой статус

17 ID 1 A1A1 ID 2 A2A2 B2B2 C2C2 Актуализация данных через единую систему 17 ID ABC ID 1 A1A1 B1B1 C1C1 ID 2 A2A2 B2B2 C2C2 ID 3 A3A3 B3B3 C3C3 Ресурс-италон ЕГРЮЛ Ресурс-италон ЕГРП обновлений AA - B-B CC- X-- Y-Y ZZ- РВД ID ACZ ID 7 ID 1 ID 4 A1A1 CZ4Z4 ID 8 ID 2 ID 6 A2A2 C2C2 Z6Z6 РФИ (ресурс-потребитель) СИСТЕМА ID XYZ ID 4 X4X4 Y4Y4 Z4Z4 ID 5 X5X5 Y5Y5 Z5Z5 ID 6 X6X6 Y6Y6 Z6Z ID 4 X4X4 Y4Y4 Z4Z4 ID 6 X6X6 Y6Y6 Z6Z6 ID 1 A1A1 B1B1 C1C1 ID 2 A2A2 B2B2 C2C2 IDABC ID 1 #A1#A1 #B1#B1 #C1#C1 ID 2 #A2#A2 #B2#B2 #C2#C2 ID 3 #A3#A3 #B3#B3 #C3#C3 ID 2 XYZ ID 4 #X4#X4 #Y4#Y4 #Z4#Z4 ID 5 #X5#X5 #Y5#Y5 #Z5#Z5 ID 6 #X6#X6 #Y6#Y6 #Z6#Z6 ID 1 #A1#A1 #B1#B1 #C1#C1 ID 2 #A2#A2 #B2#B2 #C2#C2 обновлений 1 ID 4 #X4#X4 #Y4#Y4 #Z4#Z4 ID 6 #X6#X6 #Y6#Y6 #Z6#Z6 ID 4 Z4Z4 ID 6 Z6Z6 ID BY ID 9 ID 2 ID 5 B2B2 Y ID 1 ID 7 - ID 2 ID 8 ID 9 ID 3 -- ID 4 ID 7 - ID 5 -ID 9 ID 6 ID 8 - Связи ID Обновление данных в ресурсе-италоне ID 8 ID 2 A2A2 C2C2 ID 9 ID 2 B2B2 2 Иной ресурс-потребитель 4 4 ID ABC ID 1 A1A1 B1B1 C1C1 ID 2 A2A2 B2B2 C2C2 ID 3 A3A3 B3B3 C3C3 Хэш-копии ресурсов Вид данных Данные Наим. ю.л. Адрес ю.л. ФИО ген. дир. ID XYZ ID 4 X4X4 Y4Y4 Z4Z4 ID 5 X5X5 Y5Y5 Z5Z5 ID 6 X6X6 Y6Y6 Z6Z6 ID 7 ID 1 A1A1 4 ID 7 ID 4 Z 4 ID ACZ ID 7 ID 1 ID 4 A1A1 CZ4Z4 ID 8 ID 2 ID 6 A2A2 C2C2 Z6Z6 ID ACZ ID 7 ID 1 ID 4 A1A1 C Z4Z4 ID 8 ID 2 ID 6 A2A2 C2C2 Z6Z6 ID ACZ ID 7 ID 1 ID 4 A1A1 C Z4Z4 ID 8 ID 2 ID 6 A2A2 C2C2 Z6Z6 ID BY ID 9 ID 2 ID 5 B2B2 Y ID 8 ID 6 Z6Z6 ID ACZ ID 7 ID 1 ID 4 A1A1 C Z4Z4 ID 8 ID 2 ID 6 A2A2 C2C2 Z6Z6 IDABC ID 1 #A1#A1 #B1#B1 #C1#C1 ID 2 #A2#A2 #B2#B2 #C2#C2 ID 3 #A3#A3 #B3#B3 #C3#C3 ID 7 ID 8 ID 2 XYZ ID 4 #X4#X4 #Y4#Y4 #Z4#Z4 ID 5 #X5#X5 #Y5#Y5 #Z5#Z5 ID 6 #X6#X6 #Y6#Y6 #Z6#Z6 НСИ Выгрузка обновлений Хэширование обновлений Сравнение с хэш-копиями ресурсов Очистка данных Определение соответствующих реестровых записей и видов данных потребителей Формирование пакета обновлений Выгрузка обновлений потребителю Ресурс-потребитель Аналогичным образом Определение соответствующих реестровых записей и видов данных потребителей. + Формирование пакетов обновлений По аналогии

18 Резюме 18 Разработать единые форматы данных и внедрить их во все ресурсы. Обмен самими данными между ресурсами сохранить по принципу «каждый с каждым», не связывая данные ресурсов I вариант – от единых форматов к самостоятельному обмену данными II вариант – от организованного обмена данными к унификации востребованных форматов Результат: общие неизменные форматы и структура данных Результат: единая система обмена актуальными данными Связать данные по ID и осуществлять обмен через единую систему. Затем перейти к унификации форматов там, где есть обмен данными

19 Спасибо за внимание! 19