Интеграция с российскими LMS и ЭИОС вузов

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Обучающий видеопродукт в России приходится интегрировать с тремя типами систем. Первый – электронная информационно-образовательная среда (ЭИОС) вуза или колледжа, которую организация обязана иметь по ч. 3 ст. 16 закона «Об образовании». Второй – облачные LMS и платформы онлайн-школ вроде iSpring Learn, GetCourse и Teachbase. Третий – государственные и национальные площадки: ГИС «Современная цифровая образовательная среда» и «Открытое образование». Технически способы интеграции те же, что и во всём мире: запуск инструмента по стандарту LTI 1.3 там, где платформа его поддерживает, единый вход (SSO) плюс API платформы там, где LTI нет, и пакет SCORM как общий знаменатель для упакованного контента. Российский рынок добавляет три условия, которых нет ни в одной спецификации: персональные данные студентов хранятся только в базах на территории России (ч. 5 ст. 18 152-ФЗ), для идентификации на аттестациях ПП 1678 предусматривает ЕСИА и ЕБС (п. 14–18), а для государственных вузов ПО фактически должно быть в реестре российского ПО (п. 21 ПП 1678). Дорогие ошибки – считать, что LTI есть в каждой LMS, писать отдельную интеграцию под каждый вуз и узнавать про реестр и локализацию данных только на этапе закупки.

Почему это важно

«А он встроится в нашу ЭИОС?» – первый вопрос вуза, колледжа или учебного центра ДПО к любому видеопродукту; онлайн-школа спрашивает то же самое про GetCourse или Teachbase. Статья написана для основателя EdTech-компании, продакт-менеджера или L&D-директора, которому нужно решить, как интегрироваться с каждой системой, объяснить задачу инженерам и заложить бюджет, не начиная новый проект под каждого клиента. Правильно выбранный способ интеграции даёт одну реализацию для всех вузов на Moodle и тонкие адаптеры для остальных. Неправильный – пачку разовых интеграций, которые к тому же нельзя продать государственному вузу, потому что продукта нет в реестре или данные студентов хранятся не там. Утверждения о стандартах здесь опираются на спецификации 1EdTech и ADL, о регулировании – на тексты 273-ФЗ, 152-ФЗ и ПП 1678.

Три типа систем: с кем вы интегрируетесь

Прежде чем выбирать технологию, разберитесь, с какой системой имеете дело: на российском рынке их три класса, и у каждого своя логика.

ЭИОС вуза или колледжа. Электронная информационно-образовательная среда – совокупность систем, через которые организация ведёт электронное обучение: курсы, задания, оценки, связь с преподавателем. Создать её организация обязана по ч. 3 ст. 16 273-ФЗ. Ядро ЭИОС чаще всего – Moodle, стандарт де-факто в российских вузах; часть крупных университетов строит собственные системы, например НИУ ВШЭ работает в своей SmartLMS. Для интегратора это значит, что в одном вузе вас встретит знакомый Moodle, а в другом – самописная система, в которой есть ровно то, что сделала ИТ-служба вуза.

Облачные LMS и платформы онлайн-школ. Учебные центры, организации ДПО и онлайн-школы работают в готовых сервисах: iSpring Learn (входит в реестр российского ПО, серверы в РФ), Teachbase, GetCourse. GetCourse, по данным Smart Ranking, вошёл в топ-10 российских EdTech-компаний по выручке 2025 года с 6,6 млрд ₽. Это SaaS: свой код внутри не запустить, работать придётся через то, что открыл вендор, – стандарты контента, API, встраивание.

Государственные и национальные площадки. ГИС «Современная цифровая образовательная среда» (СЦОС, портал online.edu.ru Минобрнауки) собирает каталог онлайн-курсов разных платформ; результаты курса засчитывает сама образовательная организация. Вузы и организации ДПО вправе использовать СЦОС (п. 10 ПП 1678). «Открытое образование» (openedu.ru) – национальная платформа открытого образования, курсы которой вузы могут перезачитывать. У школ и колледжей свободы меньше: для общеобразовательных программ и СПО использование государственных ГИС и мессенджера MAX обязательно (ч. 3.1 ст. 16 273-ФЗ, п. 9 ПП 1678). Поэтому дальше речь пойдёт о вузах, ДПО и учебных центрах.

Нажмите, чтобы увеличить

Два способа, которые работают везде, где поддерживаются

В мире интеграция сводится к двум способам, и российский рынок не исключение.

Первый – Learning Tools Interoperability, или LTI: образовательный стандарт 1EdTech, по которому внешний инструмент безопасно запускается внутри любой LMS без копирования контента. Ваш видеоинструмент остаётся на ваших серверах, а LMS открывает его по подписанному запросу. Второй – API платформы: веб-интерфейс (чаще всего REST – стандартный способ, которым одно веб-приложение запрашивает данные у другого по HTTPS), через который внешняя система читает и записывает данные LMS: пользователей, курсы, зачисления, оценки.

Правило, которое экономит больше всего денег, здесь то же, что везде. LTI – стандарт, поэтому один совместимый инструмент из одного кода запускается в каждой LMS, которая его поддерживает. API у каждой платформы свой, и каждый приходится реализовывать отдельно. Начинайте с LTI, а к API обращайтесь только за тем, чего LTI не даёт.

Российская поправка одна, но важная: LTI заявлен не везде. В Moodle LTI 1.3 встроен, поэтому вся «мудловская» часть рынка доступна сразу. У облачных LMS и собственных ЭИОС поддержку LTI нужно проверять по документации вендора или уточнять у ИТ-службы вуза и заранее закладывать запасной путь на случай, если её нет. Этот запасной путь – третий способ, о нём ниже.

LTI 1.3: путь по умолчанию там, где он есть

Для видеопродукта, в том числе интерактивного, запуск – правильный выбор по умолчанию, а ориентироваться нужно на LTI 1.3 с набором сервисов LTI Advantage. (Подробнее о стандарте – в объяснении LTI.)

LTI 1.3 – не вход по логину и паролю. Когда студент нажимает на ваш инструмент в курсе, LMS начинает обмен по OpenID Connect (стандартный способ, которым одна система подтверждает личность пользователя перед другой) и передаёт инструменту подписанный JSON Web Token, или JWT – небольшое криптографически подписанное сообщение о том, кто этот студент, из какого он курса и какая у него роль. Единый вход – следствие подписанного запуска, а не его механизм. Основную работу делают три сервиса LTI Advantage: Deep Linking позволяет преподавателю выбрать конкретное видео для встраивания, Names and Role Provisioning Services (NRPS) – получить список учащихся курса, а Assignment and Grade Services (AGS) – записать оценки обратно в журнал LMS.

Настройка везде устроена одинаково. Инструмент сообщает платформе свои адреса входа и запуска и публичные ключи (набор JWKS); платформа выдаёт ему client ID, идентификатор развёртывания (deployment ID) и свои адреса. Дальше всё решает конфигурация, а не код: подключение следующего вуза на Moodle – это регистрация инструмента администратором, а не новая разработка. Пошаговая настройка в Moodle описана в статье «Интеграция с Moodle», здесь повторять её не будем.

Нажмите, чтобы увеличить

Когда LTI нет: SSO, API платформы и встраивание

Если LMS не поддерживает LTI, его возможности приходится собирать из трёх частей, и каждую нужно сделать так же аккуратно, как в самом стандарте.

Вход. Студент не должен заводить второй пароль. Подключайтесь к провайдеру идентификации вуза или учебного центра по OpenID Connect или SAML 2.0 – стандартам единого входа, которые поддерживают большинство корпоративных каталогов и open-source-решения вроде Keycloak. Связывайте учётные записи по стабильному идентификатору из системы вуза, а не по email: почта меняется, идентификатор – нет. И учтите российское правило авторизации: с 01.12.2023 российские сайты должны авторизовать пользователей из РФ только по российскому номеру телефона, через ЕСИА, ЕБС или информационную систему российского юрлица (406-ФЗ). Вход через систему вуза или через Госуслуги этому правилу отвечает, а вход только через зарубежные сервисы – нет.

Встраивание. Без LTI инструмент обычно открывается во фрейме или по ссылке с коротким подписанным токеном: вы с платформой договариваетесь о ключе, а токен содержит идентификатор пользователя и курса, роль и срок действия. Фактически это «самодельный LTI», и защищать его нужно так же: проверка подписи, срок действия в минутах, одноразовое значение (nonce) против повторного использования ссылки.

Данные. Список учащихся, зачисления и результаты передаются через API платформы. У GetCourse, например, есть публичный API: он принимает пользователей, группы и заказы и отдаёт выгрузки для анализа, но доступен на платных тарифах и с ограничением частоты запросов. Набор методов у каждого вендора свой и меняется, поэтому сверяйтесь с документацией вендора, а не со сторонними статьями. С собственной ЭИОС API согласуют с ИТ-службой вуза; иногда единственный вариант – обмен файлами по расписанию. Это допустимое крайнее средство, если выгрузка идемпотентна (повторная загрузка того же файла ничего не ломает) и сверяется по контрольным суммам.

Упакованный контент: SCORM как общий знаменатель

Второй способ попасть в LMS – передать ей самодостаточный пакет, который она хранит, воспроизводит и отслеживает сама. Это нужно, когда контент должен работать внутри системы организации, не завися от ваших серверов.

Коротко о форматах. SCORM – давний стандарт, который упаковывает курс в zip-архив, чтобы любая совместимая LMS могла его воспроизвести и отследить. Он записывает фиксированную модель данных – завершение, балл, время, – а не каждое действие (см. объяснение SCORM). xAPI (Experience API) записывает обучение утверждениями «субъект–глагол–объект» вроде «Мария завершила модуль 3» и может фиксировать посекундную работу с видео, если проектировать утверждения по xAPI Video Profile. Если вы ещё выбираете формат, посмотрите сравнение SCORM, xAPI, cmi5 и LTI: там для каждого стандарта указана его задача.

В России картина простая. SCORM – общий знаменатель: в Moodle SCORM 1.2 встроен, iSpring Learn поддерживает SCORM. А вот xAPI и cmi5 российские LMS почти нигде публично не заявляют: в Moodle они подключаются плагинами, у остальных поддержку нужно проверять у вендора. Отсюда практичная схема для видео: подробные события плеера отправляйте xAPI-утверждениями в собственное хранилище учебных записей (Learning Record Store, LRS) на серверах в России, а в LMS передавайте только итог – завершение и балл через SCORM или AGS. Так глубина аналитики не зависит от возможностей LMS конкретного клиента.

И ещё одна деталь: SCORM-пакет не обязан содержать само видео. Пакет может лишь запускать ваш плеер, а видеофайлы остаются на вашем хостинге. Так вы сохраняете контроль над контентом и обновляете его без повторной загрузки пакета.

Код внутри LMS: где это возможно

Четвёртый путь – написать код, который работает внутри LMS и меняет её экраны. На российском рынке ситуация такая.

Moodle это позволяет: плагин на PHP – штатный способ расширения, он разобран в статье о Moodle. Но и там это тяжёлый путь: плагин нужно сопровождать на каждом релизе и в каждой сборке, которую поддерживает вуз.

Облачные LMS – iSpring Learn, GetCourse, Teachbase – этого не позволяют. Это SaaS, и расширять их можно только снаружи: через стандарты контента, API, встраивание.

Собственная ЭИОС вуза технически позволяет, если пустит ИТ-служба. Но тогда вы становитесь соразработчиком чужой внутренней системы и зависите от её релизов, доступа и согласований со службой безопасности. Беритесь за это, только если договор прямо предусматривает сопровождение.

Требования ЭИОС, которых нет в спецификациях

Стандарты отвечают на вопрос «как подключиться». Российское регулирование добавляет вопрос «на каких условиях», и для вуза он часто важнее.

Данные студентов – только в России. С 01.07.2025 сбор, запись и хранение персональных данных граждан РФ с использованием баз данных за пределами России не допускаются (ч. 5 ст. 18 152-ФЗ). Это касается всего, что вы получаете через LTI, SSO и API: списков учащихся, оценок, логов, xAPI-утверждений в LRS, резервных копий. Вуз здесь – оператор персональных данных, а вы – лицо, обрабатывающее их по поручению, поэтому нужен договор-поручение с перечнем данных, действий, целей и требований к защите (ч. 3 ст. 6 152-ФЗ). ПП 1678 отдельно напоминает, что обработка ПДн в ЭО и ДОТ идёт по 152-ФЗ (п. 22).

Идентификация на аттестациях. Для аттестаций в ВО, СПО и ДПО организация может идентифицировать учащихся через ЕСИА и Единую биометрическую систему (ЕБС) – сама или через сервис прокторинга, который вправе получить из ЕСИА ФИО и СНИЛС (п. 14–16, 18 ПП 1678). Подключение к инфраструктуре идёт по ПП 1382, для ЕБС нужно согласие учащегося. Собственное распознавание лица в обход ЕБС – зона риска: частные компании с 01.06.2023 не вправе хранить исходные биометрические образцы (572-ФЗ). Подробно – в статье о подтверждении личности на экзаменах.

Локальный акт. Порядок прокторинга и средства связи – ВКС, сообщения, обмен файлами – организация закрепляет в локальном акте и публикует на своём сайте (п. 20 ПП 1678). Если ваш инструмент участвует в обучении или аттестации, вуз опишет его в этом акте, поэтому подготовьте готовое описание того, что инструмент делает и какие данные обрабатывает.

Реестр российского ПО. Системы управления обучением, ПО в составе ДОТ, идентификации в составе прокторинга, ВКС и обмена сообщениями «должны создаваться и использоваться в соответствии с законодательством РФ и (или) должны включаться в единый реестр российских программ» (п. 21 ПП 1678). Из-за «и (или)» строгость нормы зависит от толкования, но государственные заказчики применяют её жёстко. У реестра есть и коммерческая сторона: передача прав на ПО из реестра, в том числе по модели удалённого доступа, освобождена от НДС (пп. 26 п. 2 ст. 149 НК РФ).

Нажмите, чтобы увеличить

Пример: шесть клиентов

Допустим, вы продаёте инструмент для оценивания на основе интерактивного видео. Клиенты: три вуза с ЭИОС на Moodle, один вуз с собственной ЭИОС (вход по OpenID Connect, оценки через API) и два учебных центра на облачных LMS без LTI. Везде нужны оценки в журнале.

Сначала путь «по проекту на клиента»:

По проекту на клиента = 3 плагина Moodle (PHP) под разные версии и сборки
                      + 1 интеграция с собственной ЭИОС
                      + 2 интеграции с API облачных LMS
                      = 6 кодовых баз, 6 циклов релизов

Теперь путь «сначала стандарт». Вы один раз реализуете LTI 1.3 с сервисами Advantage – один поток запуска, одну проверку JWT, один клиент передачи оценок AGS – и рядом один слой SSO с адаптерами:

LTI 1.3 + AGS                 = 1 реализация                    ≈ 4–6 инж.-недель
3 вуза на Moodle              = регистрация и тестовый запуск    ≈ 1–2 часа на вуз
SSO (OIDC / SAML 2.0)         = 1 слой для всех без LTI          ≈ 2–3 инж.-недели
Адаптер к API платформы       = 3 адаптера (ЭИОС + 2 LMS)        ≈ 1–2 инж.-недели каждый
xAPI из плеера → ваш LRS в РФ = одинаково для всех клиентов

Одна реализация LTI закрывает всю «мудловскую» часть рынка, а седьмой клиент на Moodle – это настройка, а не код. Адаптеры остаются только там, где LTI нет, и каждый из них тонкий: вход идёт через общий слой SSO, подробная аналитика – через общий LRS, а адаптер лишь доставляет оценку в API конкретной платформы. Для любого видеопродукта, рассчитанного больше чем на один вуз, в этой разнице и состоит весь выбор.

Какой способ интеграции когда использовать

Способы интеграции отвечают на разные вопросы. Определите, что интеграция действительно должна делать, и возьмите самый лёгкий способ, который с этим справится.

Запускайте через LTI 1.3 везде, где он есть, – это выбор по умолчанию для видеоинструмента на вашем хостинге. Где его нет, собирайте замену из SSO, подписанного встраивания и API платформы. Пакет SCORM используйте, когда организации нужно, чтобы контент жил внутри LMS, а подробный трекинг видео держите в своём LRS. Код внутри LMS пишите только в Moodle и только когда без этого не обойтись.

Нажмите, чтобы увеличить

Частые ошибки

Несколько ошибок повторяются из проекта в проект, и каждую дёшево предотвратить заранее.

Первая – считать, что LTI есть везде. В Moodle он встроен, в облачных LMS и собственных ЭИОС его может не быть. Проверьте поддержку LTI 1.3 до подписания договора и заложите запасной путь через SSO и API. И не делайте интеграцию на LTI 1.1: подпись общим секретом – именно та модель, на смену которой пришёл LTI 1.3.

Вторая – писать отдельную интеграцию под каждый вуз на Moodle. Если ЭИОС построена на Moodle, плагин под каждого клиента не нужен: один LTI 1.3-инструмент подключается регистрацией. Плагин оправдан, только когда нужно менять экраны самого Moodle.

Третья – держать данные студентов за рубежом. Зарубежный LRS, облачная аналитика или резервное копирование за границей нарушают ч. 5 ст. 18 152-ФЗ, и это уже самостоятельное правонарушение. Если же такие данные утекут, юрлицу грозит от 3 до 15 млн ₽ в зависимости от числа записей, за повторную утечку – 1–3% выручки, но не меньше 20 млн ₽ и не больше 500 млн ₽ (ст. 13.11 КоАП).

Четвёртая – узнать про реестр ПО на этапе закупки. Государственный вуз попросит подтвердить соответствие п. 21 ПП 1678, и без записи в реестре сделка может остановиться. Планируйте включение в реестр как часть дорожной карты продукта, а не как реакцию на тендер.

Пятая – делать собственное распознавание лица на экзаменах. Легальный путь биометрической идентификации – ЕСИА и ЕБС по ПП 1678; хранить исходные образцы лица частная компания не вправе. Если нужна идентификация, интегрируйтесь с ЕСИА или с сервисом прокторинга, который это уже умеет, – например, ProctorEdu или Examus.

Шестая – считать, что «просмотрено 100%» равно «завершено». Завершение – это то, что сообщает активность: статус в SCORM, xAPI-утверждение или балл через AGS. Определите критерий завершения осознанно: шкала прогресса в плеере сама по себе оценку не ставит.

Разрабатывать или покупать: где здесь интеграция с российскими LMS

Интеграцию с ЭИОС и российскими LMS редко можно просто купить, но и раздувать её в большую разработку не нужно: задача в том, чтобы выбрать минимальный набор способов интеграции и переиспользовать его. Дороже всего обходится работа «по проекту на клиента»: плагин под один вуз, самописный обмен под другой, когда один LTI 1.3-инструмент и один слой SSO обслужили бы почти всех.

Если вы делаете видеоинструмент, в том числе интерактивный, объём работ ограничен: LTI 1.3 с нужными сервисами Advantage, слой SSO на OpenID Connect и SAML 2.0, тонкие адаптеры к API платформ без LTI и собственный LRS в России для подробного трекинга. Open-source-библиотеки LTI есть для большинства языков и избавляют от рутины. Параллельно идёт юридическая работа: договор-поручение по 152-ФЗ, описание инструмента для локального акта вуза, план включения в реестр. Если же у вас своя ЭИОС и вы решаете, расширять её или заказать разработку, это более широкий выбор, он разобран в статье «Построить, купить или расширить существующую LMS». О корпоративных системах обучения – в статье «Интеграция с корпоративными LMS и HR-системами». Чтобы с первого раза выбрать способ интеграции, скачайте рабочий лист по интеграции с российскими LMS и ЭИОС.

Где здесь Фора Софт

Фора Софт с 2005 года разрабатывает ПО для видеообучения, стриминга, видеоконференций и интерактивных плееров; за это время выпущено более 250 проектов. В интеграциях с ЭИОС и LMS мы чаще всего помогаем командам с решением, которому посвящена статья: один LTI 1.3-инструмент для всех систем, где есть LTI (он читает список учащихся через NRPS и записывает оценки через AGS), и общий слой SSO с тонкими адаптерами для остальных – вместо отдельной интеграции под каждый вуз. Обычно мы делаем инструмент интерактивного видео, который открывается внутри курса, передаёт посекундные данные о вовлечённости по xAPI Video Profile в LRS, развёрнутый в России, и обращается к API платформ только там, где LTI нет. Запуск и передачу оценок мы проверяем в реальной ЭИОС клиента, а не только в тестовом Moodle.

Главные выводы

• В России три типа систем: ЭИОС вуза, облачные LMS и государственные площадки.
• Один LTI 1.3-инструмент обслуживает все ЭИОС на Moodle; подключение – настройка, а не код.
• Где LTI нет, собирайте замену из SSO, подписанного встраивания и API платформы.
• SCORM – общий знаменатель; подробный трекинг видео держите в своём LRS в России.
• Данные студентов – только в РФ, по договору-поручению с вузом.
• ЕСИА и ЕБС для аттестаций и реестр российского ПО планируйте до первой продажи.

Что почитать дальше

• LTI: запуск инструментов внутри любой LMS
• Интеграция с Moodle
• Интеграция с корпоративными LMS и HR-системами