Technological tasks

The Tech-tasks module is tasks related to the development, implementation and improvement of new technologies, products and processes. If you have development, implementation and other needs you can post information below.

Filter
771 tasks

Автоматизация и оптимизация внутренних процессов

Автоматизация управления и распределения экспертов, менторов и фрилансеров по входящим заявкам.

Customer

Alem School

Decision acceptance deadline

03.07.26 (inclusive)

Preferred systems

Intelligent control systems

Number of applications

1

Системы интерактивного онбординга для B2B AI-платформы

Цель: внедрение готового решения (ПО/инструмента) для создания интерактивного, бесшовного и быстрого онбординга внутри нашей AI-платформы. Описание: Сейчас ключевая задача — сократить Time-to-Value для новых пользователей. Нам нужно решение, которое позволит без привлечения жесткого хард-кода (желательно No-code/Low-code) развернуть внутри интерфейса интерактивные сценарии: пошаговые туры и интерактивные чек-листы. Система должна распознавать действия пользователя в реальном времени и вести его по воронке активации.

Customer

Gen2B жауапкершілігі шектеулі серіктестігі

Decision acceptance deadline

03.07.26 (inclusive)

Preferred systems

Neurotechnology and artificial Intelligence

Number of applications

1

на разработка UI-компонента календаря/расписания

Разработать UI-компонент календаря/расписания для отображения событий во временной сетке. Компонент должен использоваться во Vue-приложениях и позволять визуально показывать занятость по времени.

Customer

ТОО "Tekme"

Decision acceptance deadline

03.07.26 (inclusive)

Preferred systems

Intelligent control systems

Number of applications

1

Разработка AI-системы персонализированных рекомендаций видеоконтента для цифровой медиаплатформы.

Разработка AI-системы персонализированных рекомендаций видеоконтента для цифровой медиаплатформы. Решение должно обеспечивать анализ пользовательского поведения в режиме реального времени, учитывать историю просмотров, взаимодействие с контентом, жанровые предпочтения и автоматически формировать персонализированную ленту рекомендаций. Система должна использовать алгоритмы машинного обучения для постоянного самообучения на основе новых данных пользователей, а также обеспечивать возможность аналитики эффективности рекомендаций и влияния на пользовательскую активность. Основной целью проекта является повышение пользовательского удержания, увеличение вовлеченности аудитории и оптимизация процессов доставки контента за счет применения технологий искусственного интеллекта.

Customer

Azimut Tech

Decision acceptance deadline

26.06.26 (inclusive)

Preferred systems

Neurotechnology and artificial Intelligence

Number of applications

9

Ядро системы — Безопасность, Архитектура и Ролевая модель (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-запросов

Customer

ТОО DIGITAL CLINIC HUB

Decision acceptance deadline

26.06.26 (inclusive)

Preferred systems

Other technological solutions

Number of applications

5

Разработка фундаментального клинического модуля «Электронная Медицинская Карта (ЭМК) и цифровое рабочее место врача» с интеграцией управления этапами лечения (физиотерапия, КТ, ПРП-терапия) для облачной медицинской информационной системы Digital Clinic Hub (DCH).

Создать единое, интуитивно понятное цифровое рабочее пространство для медицинского персонала, которое полностью заменит бумажный документооборот . Главная задача ЭМК — обеспечить бесшовный клинический путь пациента от сбора анамнеза до прохождения многоэтапных курсов лечения, а также надежно связать медицинские назначения с работой Координаторов (Отдела заботы) и Кассы . Детальное описание функционала и технических решений: Архитектура карточки пациента: Разработка комплексного интерфейса на базе Vue.js 2 . Карточка будет включать паспортную часть (ИИН, ФИО, телефон, дата рождения) и систему вкладок: «История приемов», «План лечения», «Медиафайлы» и «Финансы» . В шапке карточки будет в реальном времени отображаться баланс пациента и наличие у него задолженностей перед клиникой . Динамические шаблоны осмотра и справочники: Внедрение конструктора протоколов осмотра для разных специализаций врачей. Врач сможет быстро заполнять жалобы, анамнез и объективный статус, а также добавлять текстовые медицинские комментарии к приему . Для стандартизации диагнозов будет интегрирован международный справочник МКБ-10. Управление многоэтапным лечением (Курсы процедур): Важнейшая часть ЭМК в рамках DCH. В карточке пациента будет реализован функционал сохранения и отслеживания сложных этапов лечения: курсов физиотерапии, КТ, ПРП-терапии и фитнес-реабилитации . Врач делает назначение, а интерфейс Отдела заботы мгновенно обновляется, позволяя координаторам добавлять процедуры по требуемому времени пациента . Безопасное хранение медиафайлов: Интеграция с защищенным облачным хранилищем для загрузки результатов анализов, УЗИ и тяжелых DICOM-изображений (КТ/МРТ) с жесткой привязкой к дате визита пациента и его ID. Ролевая модель (RBAC) в ЭМК: Врач: имеет изолированный доступ исключительно к медицинским картам своих пациентов. Может вносить комментарии и назначения . Координатор / Отдел заботы: видит назначения врача для проставления статуса покупки курса («Купил курс / Не купил») и управления сеткой загрузки процедурных кабинетов . КЦ-менеджер: видит только контактные данные для создания записей, но не имеет доступа к врачебной тайне (диагнозам) внутри карты пациента . Технологический стек: Бэкенд разрабатывается на Node.js с базой данных PostgreSQL . Для мгновенного сохранения черновиков осмотра (если у врача пропал интернет) будет использоваться кэширование, а для загрузки файлов — S3-совместимое хранилище.

Customer

ТОО DIGITAL CLINIC HUB

Decision acceptance deadline

26.06.26 (inclusive)

Preferred systems

Other technological solutions

Number of applications

3

Разработка фундаментального микросервиса «Ядро биллинга, архитектура баз данных и базовая оплата (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

Customer

ТОО DIGITAL CLINIC HUB

Decision acceptance deadline

26.06.26 (inclusive)

Preferred systems

Other technological solutions

Number of applications

4

Модуль автоматического распознавания речи (ASR) с поддержкой диоризации для спикеров

Создание модуля автоматического распознавания речи (ASR) с поддержкой диоризации для двух спикеров, обеспечивающего точное разделение реплик и корректную стенографию аудиозаписей на русском и казахском языках. Описание задачи: Разработать программный механизм, принимающий на вход аудиофайл и выполняющий следующие функции: 1. определение участков речи и автоматическое разделение на двух спикеров; 2. распознавание речи на русском и казахском языках; 3. формирование текстового файла с разметкой по говорящим и временными метками; 4. обеспечение точности диоризации не ниже 90% и точности распознавания не ниже 85%; 5. предоставление готового результата в формате, пригодном для последующего анализа и интеграции.

Customer

ТОО "Эвотек Центральная Азия"

Decision acceptance deadline

25.06.26 (inclusive)

Preferred systems

Neurotechnology and artificial Intelligence

Number of applications

7

Мультиагентная платформа интеллектуального анализа данных

Развитие и масштабирование пилотного решения ИИ-ассистента на базе мультиагентной ИИ-платформы для работы со структурированными данными компании. Решение должно обеспечить сотрудникам головной компании, распределительных центров и автотранспортных предприятий доступ к ИИ-ассистентам, которые позволяют анализировать операционные показатели, задавать вопросы на естественном языке, получать ответы на основе данных компании, формировать таблицы, графики, виджеты и персонализированные дашборды. В рамках проекта требуется доработать пилотное решение, подготовить его к промышленной эксплуатации, интегрировать с AD/LDAP, Trino, ClickHouse и LLM-моделями заказчика, обеспечить контейнерную поставку, мониторинг, документацию, обучение пользователей и техническое сопровождение.

Customer

Товарищество с ограниченной ответственностью СильверОпс

Decision acceptance deadline

24.06.26 (inclusive)

Preferred systems

Information processing and transformation

Number of applications

9

Скрипт переноса данных с СуБД Oracle 11.2.0.4 с системы семейства SPARK на Intel X64

В связи с переездом системы СуБД Oracle 11.2.0.4 с системы семейства SPARK на Intel X64. Необходимо подготовить PERL скрипт для переноса патриций и всей СУБД размером 20.54 Терабайт

Customer

VVT Group

Decision acceptance deadline

24.06.26 (inclusive)

Preferred systems

Intelligent control systems

Number of applications

3

Task type

Preferred systems

Field of application

Reset filters