Технологические задачи
Модуль Технологические задачи - это задачи, связанные с разработкой, внедрением и совершенствованием новых технологий, продуктов и процессов.
Если у вас есть потребность по разработке, внедрению и другие спросы вы можете разместить информацию ниже.
Разработка прототипа корпоративного ИИ-помощника для безопасной работы с внутренней базой знаний компании.
Исследование возможностей и создание прототипа (Proof of Concept) локального корпоративного ИИ-ассистента на базе Open-Source языковых моделей (LLM) с архитектурой RAG, способного оперативно и безопасно осуществлять контекстный поиск и анализ информации по внутренним регламентам и документам компании без передачи данных во внешние облачные сервисы. Описание задачи: В рамках выполнения технологической задачи предлагается решить проблему безопасного и быстрого поиска информации внутри корпоративных баз данных. Современные публичные ИИ-решения (ChatGPT, Claude и др.) не могут быть использованы в контуре компании из-за строгих требований информационной безопасности и условий NDA. Задача заключается в том, чтобы развернуть и адаптировать открытую языковую модель (например, Llama 3, Mistral или аналоги) полностью на локальных мощностях. Проект включает в себя: Создание модуля для загрузки и индексации текстовых документов (PDF, DOCX, TXT); Настройку векторной базы данных для точного извлечения контекста (RAG); Разработку удобного веб-интерфейса (чат-бота), который будет отвечать на вопросы сотрудников на казахском и русском языках, обязательно ссылаясь на конкретные пункты и страницы документов-первоисточников. Результатом задачи должен стать работоспособный прототип, упакованный в Docker-контейнер, для демонстрации внутренней технической команде.
Прием решений до
10.07.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
14
Разработка цифровой платформы управления посещаемостью и контроля доступа на массовые мероприятия
Цель проекта — создание единой цифровой платформы для автоматизации процессов контроля доступа посетителей на концерты, спортивные мероприятия, фестивали, театральные представления и другие массовые события. Система должна обеспечивать онлайн-проверку билетов, управление потоками посетителей, мониторинг загруженности входных групп в режиме реального времени и предоставление организаторам аналитических данных о посещаемости мероприятий.
Прием решений до
10.07.26 (включительно)
Область задачи
ITКоличество заявок
8
Интерактивная шахматная дуэль для учеников ABCHESS
Разработать интерактивный образовательный веб-модуль для проведения соревновательных шахматных занятий. Модуль должен позволять нескольким ученикам одновременно решать шахматные задания на одном экране в игровом формате. Основная цель проекта — повысить вовлечённость детей в процесс обучения за счёт элементов соревнования, визуального прогресса и мгновенной обратной связи. Проект рассматривается как отдельный образовательный инструмент, который в дальнейшем может быть интегрирован с существующими онлайн-платформами и внутренними базами учебных материалов.
Прием решений до
07.07.26 (включительно)
Область задачи
Обработка и преобразование информацииКоличество заявок
18
Автоматизация и оптимизация внутренних процессов
Автоматизация управления и распределения экспертов, менторов и фрилансеров по входящим заявкам.
Прием решений до
03.07.26 (включительно)
Область задачи
Интеллектуальные системы управленияКоличество заявок
18
Системы интерактивного онбординга для B2B AI-платформы
Цель: внедрение готового решения (ПО/инструмента) для создания интерактивного, бесшовного и быстрого онбординга внутри нашей AI-платформы. Описание: Сейчас ключевая задача — сократить Time-to-Value для новых пользователей. Нам нужно решение, которое позволит без привлечения жесткого хард-кода (желательно No-code/Low-code) развернуть внутри интерфейса интерактивные сценарии: пошаговые туры и интерактивные чек-листы. Система должна распознавать действия пользователя в реальном времени и вести его по воронке активации.
Прием решений до
03.07.26 (включительно)
Область задачи
Нейротехнологии и искусственный интеллектКоличество заявок
8
на разработка UI-компонента календаря/расписания
Разработать UI-компонент календаря/расписания для отображения событий во временной сетке. Компонент должен использоваться во Vue-приложениях и позволять визуально показывать занятость по времени.
Прием решений до
03.07.26 (включительно)
Область задачи
Интеллектуальные системы управленияКоличество заявок
11
Разработка AI-системы персонализированных рекомендаций видеоконтента для цифровой медиаплатформы.
Разработка AI-системы персонализированных рекомендаций видеоконтента для цифровой медиаплатформы. Решение должно обеспечивать анализ пользовательского поведения в режиме реального времени, учитывать историю просмотров, взаимодействие с контентом, жанровые предпочтения и автоматически формировать персонализированную ленту рекомендаций. Система должна использовать алгоритмы машинного обучения для постоянного самообучения на основе новых данных пользователей, а также обеспечивать возможность аналитики эффективности рекомендаций и влияния на пользовательскую активность. Основной целью проекта является повышение пользовательского удержания, увеличение вовлеченности аудитории и оптимизация процессов доставки контента за счет применения технологий искусственного интеллекта.
Прием решений до
26.06.26 (включительно)
Область задачи
Нейротехнологии и искусственный интеллектКоличество заявок
15
Ядро системы — Безопасность, Архитектура и Ролевая модель (RBAC) Продукт: Облачная медицинская информационная система Digital Clinic Hub (DCH)
Создание абсолютно защищенного, отказоустойчивого и масштабируемого ядра облачной платформы (SaaS), которое станет технологическим фундаментом для всех последующих функциональных модулей системы (Календарь, Касса, ЭМК и др.). Главная задача этого блока — обеспечить беспрецедентный уровень изоляции медицинских и финансовых данных между разными клиниками-клиентами, а также внедрить непреодолимую систему разграничения прав доступа для сотрудников внутри каждой клиники Детальное описание функционала и технических решений: Мульти-тенантная микросервисная архитектура: Ядро системы проектируется на базе Node.js и PostgreSQL. Каждая клиника (или отдельный филиал сетевой клиники) получает обособленную базу данных (логическое или физическое разделение на уровне схем), что гарантирует полную изоляцию данных клиентов и поддержку франшизной структуры. Система аутентификации и авторизации (JWT): Внедряется механизм stateless-аутентификации с использованием JSON Web Tokens (JWT). Каждое действие в системе проходит проверку через Middleware на основе полезной нагрузки (payload) токена. В токене жестко зашиты критические данные: role (роль пользователя), branch_id (идентификатор филиала для ограничения видимости), sub (ID пользователя), shift_id (ID активной кассовой смены) и max_discount_pct (допустимый процент скидки). Матрица прав доступа (RBAC): Ядро реализует строгий контроль доступа по 6 основным ролям, где права проверяются прямо на уровне эндпоинтов API: Администратор (Admin): Полный доступ ко всем филиалам, справочникам, скрытой аналитике и отмененным записям. Может применять любые скидки и удалять документы. Менеджер Колл-центра (КЦ): Доступ к расписанию всех филиалов для создания, редактирования, переноса записей и постановки 10-минутной брони. Доступ к финансам полностью закрыт. (Подроль "Отдел прихода" дополнительно может отменять записи с указанием причины). Регистратор: Строго ограничен своим физическим филиалом. Может только менять статус явки пациента («Пришёл» / «Не пришёл»). Врач: Изолированный доступ только к своим записям. Может добавлять медицинские комментарии, но лишен прав на редактирование расписания или финансов. Координатор: Управляет финансовыми статусами курсов лечения («Купил курс» / «Не купил»), имеет право создавать счета и применять скидку (например, строго до 10%), но не может оформлять возвраты или управлять кассовыми сменами. Кассир: Имеет доступ к POS-терминалу своего филиала, может открывать/закрывать смены, проводить оплату, делать Z-отчеты и оформлять возвраты. Тотальный аудит и логирование (Audit Log): Разработка модуля журналирования, который намертво фиксирует все критические операции в системе (создание, отмена записей, прием оплат, возвраты) в служебную таблицу audit_log. Система записывает user_id, время, тип действия, а также состояние данных "до" (before) и "после" (after) внесения изменений. Идемпотентность и защита: Для исключения риска двойных списаний или дублирования записей при нестабильном интернете, ядро внедряет поддержку заголовка Idempotency-Key для всех POST-запросов
Прием решений до
26.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
7
Разработка фундаментального клинического модуля «Электронная Медицинская Карта (ЭМК) и цифровое рабочее место врача» с интеграцией управления этапами лечения (физиотерапия, КТ, ПРП-терапия) для облачной медицинской информационной системы Digital Clinic Hub (DCH).
Создать единое, интуитивно понятное цифровое рабочее пространство для медицинского персонала, которое полностью заменит бумажный документооборот . Главная задача ЭМК — обеспечить бесшовный клинический путь пациента от сбора анамнеза до прохождения многоэтапных курсов лечения, а также надежно связать медицинские назначения с работой Координаторов (Отдела заботы) и Кассы . Детальное описание функционала и технических решений: Архитектура карточки пациента: Разработка комплексного интерфейса на базе Vue.js 2 . Карточка будет включать паспортную часть (ИИН, ФИО, телефон, дата рождения) и систему вкладок: «История приемов», «План лечения», «Медиафайлы» и «Финансы» . В шапке карточки будет в реальном времени отображаться баланс пациента и наличие у него задолженностей перед клиникой . Динамические шаблоны осмотра и справочники: Внедрение конструктора протоколов осмотра для разных специализаций врачей. Врач сможет быстро заполнять жалобы, анамнез и объективный статус, а также добавлять текстовые медицинские комментарии к приему . Для стандартизации диагнозов будет интегрирован международный справочник МКБ-10. Управление многоэтапным лечением (Курсы процедур): Важнейшая часть ЭМК в рамках DCH. В карточке пациента будет реализован функционал сохранения и отслеживания сложных этапов лечения: курсов физиотерапии, КТ, ПРП-терапии и фитнес-реабилитации . Врач делает назначение, а интерфейс Отдела заботы мгновенно обновляется, позволяя координаторам добавлять процедуры по требуемому времени пациента . Безопасное хранение медиафайлов: Интеграция с защищенным облачным хранилищем для загрузки результатов анализов, УЗИ и тяжелых DICOM-изображений (КТ/МРТ) с жесткой привязкой к дате визита пациента и его ID. Ролевая модель (RBAC) в ЭМК: Врач: имеет изолированный доступ исключительно к медицинским картам своих пациентов. Может вносить комментарии и назначения . Координатор / Отдел заботы: видит назначения врача для проставления статуса покупки курса («Купил курс / Не купил») и управления сеткой загрузки процедурных кабинетов . КЦ-менеджер: видит только контактные данные для создания записей, но не имеет доступа к врачебной тайне (диагнозам) внутри карты пациента . Технологический стек: Бэкенд разрабатывается на Node.js с базой данных PostgreSQL . Для мгновенного сохранения черновиков осмотра (если у врача пропал интернет) будет использоваться кэширование, а для загрузки файлов — S3-совместимое хранилище.
Прием решений до
26.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
7
Разработка фундаментального микросервиса «Ядро биллинга, архитектура баз данных и базовая оплата (Core & Cash)» для модуля POS-терминала облачной медицинской информационной системы Digital Clinic Hub (DCH).
Заложить отказоустойчивый, масштабируемый и высокопроизводительный фундамент для всего финансового контура клиники. Главная задача этого блока — спроектировать надежную архитектуру базы данных (счета, транзакции, позиции чеков), внедрить строгую валидацию прав доступа через JWT-токены на уровне API-шлюза и реализовать базовый, но самый критичный процесс оплаты наличными средствами с автоматическим расчетом сдачи клиенту и защитой от двойного проведения платежей. Детальное описание функционала и технических решений: Архитектура БД и финансовые типы данных: Проектирование ключевых таблиц в PostgreSQL: invoices (счета), invoice_items (позиции счета) и transactions (транзакции) . Фундаментальное техническое требование — все суммы (цены, скидки, итоги, сдача) должны храниться в базе данных исключительно в строгом финансовом формате NUMERIC(12,2) (категорический запрет на использование плавающего типа данных float), а все критические вычисления должны происходить на стороне бэкенда для исключения погрешностей на клиенте . Справочник услуг (Services Database): Разработка и интеграция таблицы services (вызов через эндпоинт GET /api/v2/services?search=) для автоматизированного добавления позиций (медицинских услуг или товаров) в счет . Каждая позиция в чеке будет жестко привязана к справочнику, включая ее стоимость по умолчанию и ставку НДС (vat_pct) . RBAC и защита операций (JWT Middleware): Каждая кассовая операция (создание счета, применение скидки, проведение платежа) должна проходить через жесткий фильтр безопасности. Middleware проверяет JWT-токен кассира, валидируя обязательные поля: role (уровень прав), branch_id (ограничение видимости счетов только своим филиалом), sub (ID сотрудника) и max_discount_pct (допустимый предел персональной скидки) . Самое важное: сервер проверяет наличие shift_id — если у пользователя нет открытой кассовой смены, операция блокируется со статусом HTTP 403 NO_ACTIVE_SHIFT . Флоу оплаты наличными (Cash Flow): Разработка алгоритма приема наличности без внешней банковской интеграции . Сервер принимает параметр amount_paid (сколько дал пациент). Если принятая сумма меньше итоговой суммы счета (total), API автоматически отклоняет транзакцию с ошибкой 422 INSUFFICIENT_AMOUNT . Сдача рассчитывается на клиенте реактивно (change = amount_paid - total) . При успешном проведении, статус счета атомарно переводится сервером в статус paid (или partial), после чего клиенту отправляется WebSocket событие payment.completed для мгновенного обновления интерфейса POS-терминала . Идемпотентность и Аудит (Audit Log): Внедрение механизма защиты от сетевых сбоев и двойных кликов. Критический Endpoint POST /api/v2/invoices/:id/pay требует обязательной передачи заголовка Idempotency-Key . При дублированном запросе сервер вернет закешированный оригинальный ответ без создания двойной транзакции . Одновременно с этим, любые действия жестко логируются в глобальную таблицу audit_log, где сохраняется кто сделал операцию, какое было действие и JSON-состояние чека before и after
Прием решений до
26.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
6
