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.
Разработка AI-системы персонализированных рекомендаций видеоконтента для цифровой медиаплатформы.
Разработка AI-системы персонализированных рекомендаций видеоконтента для цифровой медиаплатформы. Решение должно обеспечивать анализ пользовательского поведения в режиме реального времени, учитывать историю просмотров, взаимодействие с контентом, жанровые предпочтения и автоматически формировать персонализированную ленту рекомендаций. Система должна использовать алгоритмы машинного обучения для постоянного самообучения на основе новых данных пользователей, а также обеспечивать возможность аналитики эффективности рекомендаций и влияния на пользовательскую активность. Основной целью проекта является повышение пользовательского удержания, увеличение вовлеченности аудитории и оптимизация процессов доставки контента за счет применения технологий искусственного интеллекта.
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Neurotechnology and artificial IntelligenceNumber of applications
2
Ядро системы — Безопасность, Архитектура и Ролевая модель (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-запросов
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
3
Разработка фундаментального клинического модуля «Электронная Медицинская Карта (ЭМК) и цифровое рабочее место врача» с интеграцией управления этапами лечения (физиотерапия, КТ, ПРП-терапия) для облачной медицинской информационной системы Digital Clinic Hub (DCH).
Создать единое, интуитивно понятное цифровое рабочее пространство для медицинского персонала, которое полностью заменит бумажный документооборот . Главная задача ЭМК — обеспечить бесшовный клинический путь пациента от сбора анамнеза до прохождения многоэтапных курсов лечения, а также надежно связать медицинские назначения с работой Координаторов (Отдела заботы) и Кассы . Детальное описание функционала и технических решений: Архитектура карточки пациента: Разработка комплексного интерфейса на базе Vue.js 2 . Карточка будет включать паспортную часть (ИИН, ФИО, телефон, дата рождения) и систему вкладок: «История приемов», «План лечения», «Медиафайлы» и «Финансы» . В шапке карточки будет в реальном времени отображаться баланс пациента и наличие у него задолженностей перед клиникой . Динамические шаблоны осмотра и справочники: Внедрение конструктора протоколов осмотра для разных специализаций врачей. Врач сможет быстро заполнять жалобы, анамнез и объективный статус, а также добавлять текстовые медицинские комментарии к приему . Для стандартизации диагнозов будет интегрирован международный справочник МКБ-10. Управление многоэтапным лечением (Курсы процедур): Важнейшая часть ЭМК в рамках DCH. В карточке пациента будет реализован функционал сохранения и отслеживания сложных этапов лечения: курсов физиотерапии, КТ, ПРП-терапии и фитнес-реабилитации . Врач делает назначение, а интерфейс Отдела заботы мгновенно обновляется, позволяя координаторам добавлять процедуры по требуемому времени пациента . Безопасное хранение медиафайлов: Интеграция с защищенным облачным хранилищем для загрузки результатов анализов, УЗИ и тяжелых DICOM-изображений (КТ/МРТ) с жесткой привязкой к дате визита пациента и его ID. Ролевая модель (RBAC) в ЭМК: Врач: имеет изолированный доступ исключительно к медицинским картам своих пациентов. Может вносить комментарии и назначения . Координатор / Отдел заботы: видит назначения врача для проставления статуса покупки курса («Купил курс / Не купил») и управления сеткой загрузки процедурных кабинетов . КЦ-менеджер: видит только контактные данные для создания записей, но не имеет доступа к врачебной тайне (диагнозам) внутри карты пациента . Технологический стек: Бэкенд разрабатывается на Node.js с базой данных PostgreSQL . Для мгновенного сохранения черновиков осмотра (если у врача пропал интернет) будет использоваться кэширование, а для загрузки файлов — S3-совместимое хранилище.
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
2
Разработка фундаментального микросервиса «Ядро биллинга, архитектура баз данных и базовая оплата (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
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
2
Модуль автоматического распознавания речи (ASR) с поддержкой диоризации для спикеров
Создание модуля автоматического распознавания речи (ASR) с поддержкой диоризации для двух спикеров, обеспечивающего точное разделение реплик и корректную стенографию аудиозаписей на русском и казахском языках. Описание задачи: Разработать программный механизм, принимающий на вход аудиофайл и выполняющий следующие функции: 1. определение участков речи и автоматическое разделение на двух спикеров; 2. распознавание речи на русском и казахском языках; 3. формирование текстового файла с разметкой по говорящим и временными метками; 4. обеспечение точности диоризации не ниже 90% и точности распознавания не ниже 85%; 5. предоставление готового результата в формате, пригодном для последующего анализа и интеграции.
Decision acceptance deadline
25.06.26 (inclusive)
Preferred systems
Neurotechnology and artificial IntelligenceNumber of applications
4
Мультиагентная платформа интеллектуального анализа данных
Развитие и масштабирование пилотного решения ИИ-ассистента на базе мультиагентной ИИ-платформы для работы со структурированными данными компании. Решение должно обеспечить сотрудникам головной компании, распределительных центров и автотранспортных предприятий доступ к ИИ-ассистентам, которые позволяют анализировать операционные показатели, задавать вопросы на естественном языке, получать ответы на основе данных компании, формировать таблицы, графики, виджеты и персонализированные дашборды. В рамках проекта требуется доработать пилотное решение, подготовить его к промышленной эксплуатации, интегрировать с AD/LDAP, Trino, ClickHouse и LLM-моделями заказчика, обеспечить контейнерную поставку, мониторинг, документацию, обучение пользователей и техническое сопровождение.
Decision acceptance deadline
24.06.26 (inclusive)
Preferred systems
Information processing and transformationNumber of applications
7
Скрипт переноса данных с СуБД Oracle 11.2.0.4 с системы семейства SPARK на Intel X64
В связи с переездом системы СуБД Oracle 11.2.0.4 с системы семейства SPARK на Intel X64. Необходимо подготовить PERL скрипт для переноса патриций и всей СУБД размером 20.54 Терабайт
Decision acceptance deadline
24.06.26 (inclusive)
Preferred systems
Intelligent control systemsNumber of applications
2
Разработка микросервиса «Финансовая аналитика и BI-Дашборды (Analytics & Reports)» для агрегации транзакций, визуализации ключевых метрик (KPI) и автоматической генерации управленческой отчетности в модуле POS-терминала облачной медицинской информационной системы Digital Clinic Hub (DCH).
Создать мощный, интерактивный и абсолютно прозрачный аналитический инструмент для собственников бизнеса, главных врачей и финансовых директоров клиник. Главная задача этого блока — консолидировать финансовые потоки со всех кассовых смен и филиалов в режиме реального времени, предоставить наглядную визуализацию структуры выручки и автоматизировать выгрузку отчетов, не создавая при этом никаких задержек в работе основной кассы. Детальное описание функционала и технических решений: Изолированная архитектура баз данных (Read Replica): Это ключевое инженерное решение блока. Все тяжелые аналитические SQL-запросы (агрегации сумм за год, сложные выборки транзакций) маршрутизируются на отдельную реплику базы данных PostgreSQL . Это гарантирует, что формирование огромного отчета для руководства физически не сможет заблокировать транзакционные таблицы и не замедлит работу кассиров в холле клиники . Интерактивный Финансовый Дашборд: Разработка единого центра управления (сводного экрана) с использованием современных графических библиотек (Chart.js или ECharts) . Дашборд включает 5 ключевых KPI-карточек, расположенных в ряд: выручка за день, выручка за месяц, текущая сумма задолженностей пациентов, средний чек и количество отмененных счетов . Визуализация методов оплаты и транзакций: Под графиком динамики выручки по дням располагается круговая диаграмма с разбивкой поступающих средств (в процентах) по каналам оплаты: Наличные, Kaspi QR, Банковская карта, Kaspi Рассрочка . В нижней части экрана выводится интерактивная таблица последних транзакций с указанием суммы, кассира, пациента и статуса . Система генерации отчетов: Разработка специализированных REST API эндпоинтов (например, /analytics/revenue, /analytics/avg-receipt, /reports/daily, /reports/monthly) для гибкого запроса данных . Модуль предоставляет возможность в один клик выгружать сводные финансовые данные в форматах Excel и PDF . Технический норматив системы: экспорт массива данных объемом более 1000 строк в Excel должен выполняться всего за 5-10 секунд . Матрица прав доступа (RBAC): Доступ к финансовому дашборду, скрытой аналитике и экспорту отчетов имеет исключительно роль «Администратор (Admin)» . Для кассиров, координаторов, регистраторов и врачей эти эндпоинты заблокированы на уровне JWT-токена, что пресекает любую утечку коммерческой тайны линейному персоналу
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
4
Разработка микросервиса «Управление кассовыми сменами, инкассация и автоматическая генерация Z-отчетов (Shift Management)» в рамках финансового модуля POS-терминала облачной медицинской информационной системы Digital Clinic Hub (DCH)
Внедрить в клиниках систему жесткой цифровой, материальной и персональной ответственности кассиров. Главная задача данного блока — алгоритмически запретить любые несанкционированные финансовые операции «вне кассы», обеспечить строгий учет наличности с момента открытия до момента закрытия рабочего дня, а также полностью автоматизировать расчет итоговой выручки с генерацией фискальных Z-отчетов. Детальное описание функционала и технических решений: Механика открытия смены и JWT-валидация: Рабочий день кассира начинается с интерфейса «Карточка смены» . Кассир инициирует POST-запрос для открытия смены, где обязательно фиксирует остаток наличных в кассе на момент старта (opening_balance) . Сервер создает запись в таблице shifts, а главное — обновляет JWT-токен пользователя, вшивая в него shift_id . Это критический элемент безопасности: Middleware бэкенда блокирует любые транзакции (оплату, возврат), если в токене нет активного shift_id, возвращая ошибку 403 NO_ACTIVE_SHIFT . Защита от параллельных смен: Система на уровне базы данных проверяет открытые смены филиала. Если один кассир уже открыл смену, попытка второго кассира открыть параллельную кассу в этом же филиале блокируется сервером с ошибкой 409 SHIFT_ALREADY_OPEN . Промежуточная инкассация (Cash-out): Внедрение механизма безопасного изъятия наличных из кассы в течение дня (например, для передачи инкассаторам) без закрытия самой смены. Для этого используется эндпоинт POST /api/v2/shifts/:id/cash-out . Инкассация записывается в систему, влияет на расчетный финальный остаток наличных (closing_balance), но математически не искажает общую выручку клиники . Сверка наличности и расчет недостач: При нажатии «Закрыть смену» система подбивает итоги: кассир обязан вручную ввести фактическую сумму бумажных денег в кассе (cash_drawer_closing) . Сервер сравнивает введенную сумму с расчетной по формуле: closing_balance − (opening_balance + cash_in − cash_out). Любые расхождения (недостача или излишек) намертво фиксируются в поле discrepancy . Автоматическая генерация Z-отчетов: Сервер производит сложные SQL-агрегации (COUNT и SUM) всех транзакций за период смены с точной разбивкой по методам: Наличные, Kaspi, Карта, Возвраты и Чистая выручка . После математической сверки бэкенд использует библиотеку pdfkit (или puppeteer) для мгновенной генерации PDF-документа (Z-отчета) . Сгенерированный файл сохраняется в защищенное S3-совместимое объектное хранилище , а токен кассира аннулируется
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
1
Разработка микросервиса «Финтех-интеграция и безналичные платежи (Kaspi Ecosystem & Mixed Payments)» для автоматизации эквайринга, обработки QR-платежей, рассрочек и смешанных оплат в модуле POS-терминала облачной медицинской информационной системы Digital Clinic Hub (DCH).
Создать безопасный, высокоскоростной и полностью автоматизированный шлюз для приема безналичных оплат от пациентов. Главная задача данного блока — бесшовно интегрировать Kaspi Pay API в кассовый интерфейс DCH, исключить ручной ввод сумм на физических терминалах, автоматизировать получение статусов оплат (через Webhooks и Polling) и реализовать сложную механику «смешанной оплаты», гарантируя криптографическую защиту транзакций. Детальное описание функционала и технических решений: Глубокая интеграция с Kaspi Pay API (QR-платежи): Разработка механики динамической генерации QR-кодов. При выборе метода оплаты «Kaspi QR», бэкенд DCH делает запрос POST /api/v2/payments/kaspi/qr к внешнему API Kaspi, передавая точную сумму и уникальный invoice_id . В ответ сервер возвращает графический QR-код (base64 PNG) и payment_id, которые мгновенно отображаются на экране кассира . Таймаут ожидания оплаты по сгенерированному QR-коду составляет 15 минут . Двойная система отслеживания статуса (Polling + Webhooks): Для гарантированного подтверждения платежа внедряется отказоустойчивая связка. Клиентская часть (POS-экран) запускает поллинг: отправляет запросы GET /api/v2/payments/:payment_id/status каждые 3 секунды . Параллельно бэкенд DCH настраивает защищенный эндпоинт POST /api/v2/webhooks/kaspi для приема асинхронных уведомлений (Webhooks) от серверов Kaspi о смене статуса платежа . Криптографическая защита транзакций: Это критический элемент безопасности. Любой входящий webhook от Kaspi проходит обязательную верификацию. Система рассчитывает хэш HMAC-SHA256(body, kaspi_webhook_secret) и сверяет его с подписью из заголовка . Запросы без валидной подписи мгновенно отклоняются с ошибкой HTTP 401, что делает невозможным подмену статуса платежа злоумышленниками . При статусе PAID система атомарно обновляет транзакцию, меняет статус счета и публикует WebSocket-событие payment.completed для интерфейса . Механика Kaspi Рассрочки: Внедрение эндпоинта POST /api/v2/payments/kaspi/installment для интеграции возможности выбора периода рассрочки (3, 6 или 12 месяцев) прямо из POS-терминала DCH . Одобрение кредита банком происходит асинхронно, а статус в DCH обновляется через webhook . Смешанная оплата (Mixed Payments): Реализация сложной бизнес-логики для случаев, когда пациент хочет оплатить один счет разными способами (например, 30 000 тг наличными и 20 000 тг через Kaspi QR) . Интерфейс предоставляет два поля для ввода. Сервер создает две разные транзакции (с методами cash и kaspi_qr), привязанные к одному счету, и проводит жесткую математическую валидацию: SUM(transaction.amount) = invoice.total_amount (с точностью до 1 тенге) . Банковские карты и PCI DSS: DCH не хранит и не передает данные банковских карт, оставляя физическую обработку POS-терминалам (обеспечивая соответствие PCI DSS) . Кассир нажимает кнопку «Оплата прошла» после подтверждения на физическом банковском терминале, и DCH фиксирует этот метод в системе
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
2
