Технологические задачи
Модуль Технологические задачи - это задачи, связанные с разработкой, внедрением и совершенствованием новых технологий, продуктов и процессов.
Если у вас есть потребность по разработке, внедрению и другие спросы вы можете разместить информацию ниже.
Автоматизация и оптимизация внутренних процессов
Автоматизация управления и распределения экспертов, менторов и фрилансеров по входящим заявкам.
Прием решений до
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
Модуль автоматического распознавания речи (ASR) с поддержкой диоризации для спикеров
Создание модуля автоматического распознавания речи (ASR) с поддержкой диоризации для двух спикеров, обеспечивающего точное разделение реплик и корректную стенографию аудиозаписей на русском и казахском языках. Описание задачи: Разработать программный механизм, принимающий на вход аудиофайл и выполняющий следующие функции: 1. определение участков речи и автоматическое разделение на двух спикеров; 2. распознавание речи на русском и казахском языках; 3. формирование текстового файла с разметкой по говорящим и временными метками; 4. обеспечение точности диоризации не ниже 90% и точности распознавания не ниже 85%; 5. предоставление готового результата в формате, пригодном для последующего анализа и интеграции.
Прием решений до
25.06.26 (включительно)
Область задачи
Нейротехнологии и искусственный интеллектКоличество заявок
9
Мультиагентная платформа интеллектуального анализа данных
Развитие и масштабирование пилотного решения ИИ-ассистента на базе мультиагентной ИИ-платформы для работы со структурированными данными компании. Решение должно обеспечить сотрудникам головной компании, распределительных центров и автотранспортных предприятий доступ к ИИ-ассистентам, которые позволяют анализировать операционные показатели, задавать вопросы на естественном языке, получать ответы на основе данных компании, формировать таблицы, графики, виджеты и персонализированные дашборды. В рамках проекта требуется доработать пилотное решение, подготовить его к промышленной эксплуатации, интегрировать с AD/LDAP, Trino, ClickHouse и LLM-моделями заказчика, обеспечить контейнерную поставку, мониторинг, документацию, обучение пользователей и техническое сопровождение.
Прием решений до
24.06.26 (включительно)
Область задачи
Обработка и преобразование информацииКоличество заявок
11
Скрипт переноса данных с СуБД Oracle 11.2.0.4 с системы семейства SPARK на Intel X64
В связи с переездом системы СуБД Oracle 11.2.0.4 с системы семейства SPARK на Intel X64. Необходимо подготовить PERL скрипт для переноса патриций и всей СУБД размером 20.54 Терабайт
Прием решений до
24.06.26 (включительно)
Область задачи
Интеллектуальные системы управленияКоличество заявок
5
