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.
Мультиагентная платформа интеллектуального анализа данных
Развитие и масштабирование пилотного решения ИИ-ассистента на базе мультиагентной ИИ-платформы для работы со структурированными данными компании. Решение должно обеспечить сотрудникам головной компании, распределительных центров и автотранспортных предприятий доступ к ИИ-ассистентам, которые позволяют анализировать операционные показатели, задавать вопросы на естественном языке, получать ответы на основе данных компании, формировать таблицы, графики, виджеты и персонализированные дашборды. В рамках проекта требуется доработать пилотное решение, подготовить его к промышленной эксплуатации, интегрировать с AD/LDAP, Trino, ClickHouse и LLM-моделями заказчика, обеспечить контейнерную поставку, мониторинг, документацию, обучение пользователей и техническое сопровождение.
Decision acceptance deadline
24.06.26 (inclusive)
Preferred systems
Information processing and transformationNumber of applications
2
Скрипт переноса данных с СуБД 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
1
Разработка микросервиса «Финансовая аналитика и 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
1
Разработка микросервиса «Управление кассовыми сменами, инкассация и автоматическая генерация 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
1
Разработка и внедрение модуля «Интерактивный календарь записей пациентов 2.0» (Record Calendar System 2.0) — высоконагруженного ядра управления потоками пациентов, расписанием врачей и загрузкой филиалов для облачной медицинской информационной системы Digital Clinic Hub (DCH)
Создание отказоустойчивой, интуитивно понятной и автоматизированной системы маршрутизации пациентов, которая объединит работу колл-центра, регистратуры и медицинского персонала в едином цифровом пространстве реального времени. Главная задача модуля — обеспечить бесшовный процесс записи, исключить человеческий фактор при распределении времени врачей и предоставить управленческому составу сквозную аналитику по эффективности каждого сотрудника. Детальное описание функционала и технических решений: Визуализация и смарт-фильтрация: Интерактивная сетка расписания с тремя режимами отображения (по дням, неделям, месяцам) . Внедряется механизм мгновенной фильтрации слотов без перезагрузки страницы: по конкретному врачу, дате, физическому филиалу и городу . Цветовая и визуальная маркировка динамически меняется в зависимости от статуса записи: «Запланирован», «Забронировано», «Пришёл», «Не пришёл», «Отменён», «Купил курс / Не купил курс», «Промежуточный осмотр» . Механика 10-минутной брони (Smart-Hold): Для предотвращения двойных записей (race conditions) в условиях работы высоконагруженного колл-центра внедряется уникальная логика бронирования. При начале оформления пациента слот мгновенно блокируется для других операторов на 10 минут . По истечении этого времени, если запись не была подтверждена, система автоматически (без участия пользователя и без обновления страницы) снимает бронь, возвращая слот в свободную продажу . Динамическое расписание и перезапись (Drag-and-Drop): Если пациенту требуется визит в нестандартное время, отсутствующее в сетке врача, менеджер просто вводит это время, и система автоматически расширяет расписание, генерируя новое окно . Реализован механизм быстрого переноса (перезаписи) карточки пациента на другое время или к другому специалисту с помощью визуального интерфейса — старый слот при этом автоматически освобождается . Промежуточные осмотры: Внедрен механизм создания повторных/коротких визитов для пациентов, проходящих курс лечения, с помощью двойного клика . При этом требуется ввести минимум данных (только ФИО и телефон), а сама карточка визуально отличается от первичной консультации . Важнейшая бизнес-логика: промежуточные осмотры алгоритмически исключаются из расчета конверсии прихода для оценки реальной эффективности продаж колл-центра . Аналитика и Дашборды (BI): Администраторы получают доступ к сводным таблицам и графикам. Главная метрика — процент конверсии менеджеров колл-центра, который рассчитывается сервером по строгой формуле: Пришло / (Итого - Промежуточные осмотры) × 100% . Также реализована аналитика по причинам отмен (с долями от общего числа), конверсии конкретных врачей и филиалов с возможностью выгрузки отчетов в Excel
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
2
Создание локальной системы управления корпоративным магазином мерча
Разработка локальной веб-системы управления корпоративным магазином мерча (swag store) с функцией начисления и учета виртуальных баллов для сотрудников, с возможностью развертывания и полноценной работы системы на серверах компании без использования облачных сервисов, с возможностью обеспечения максимальной конфиденциальности данных и максимальной автоматизации процессов. Веб-приложение должно также позволять получать статистику по товарам, пользователям, распределению баллов, активности; быть удобным в использовании и доступным с любого устройства, подключенного к сети
Decision acceptance deadline
22.06.26 (inclusive)
Preferred systems
Web разработкаNumber of applications
6
Technical optimization of the software
Improve software performance, stability, and reliability. Comprehensive technical optimization of all layers of the information system — the database, the server business logic, the electronic medical records module and the integration layer with the government systems of the Republic of Kazakhstan - in order to speed up the system, reduce errors and ensure stable operation under high user load.
Decision acceptance deadline
22.06.26 (inclusive)
Preferred systems
Information processing and transformationNumber of applications
2
Интеллектуальная система контроля исполнения государственных контрактов и мониторинга качества выполненных работ
Создание цифровой платформы для объективного контроля выполнения работ и оказания услуг по государственным контрактам. Система должна обеспечивать: фото- и видеофиксацию выполненных работ; автоматическую геопривязку материалов; контроль сроков исполнения; анализ фактического выполнения работ с использованием технологий компьютерного зрения; мониторинг контрактов в режиме реального времени; выявление рисков неисполнения обязательств; формирование отчетности для заказчиков. Пример применения: Подрядчик выполнил ремонт дороги, установил освещение, провел благоустройство либо оказывает услуги по содержанию объектов. Через мобильное приложение загружаются материалы с координатами и временем съемки. Система автоматически подтверждает факт выполнения работ и выявляет возможные нарушения.
Decision acceptance deadline
22.06.26 (inclusive)
Preferred systems
бюджетный контроль, государственные закупки, мониторингNumber of applications
4
Разработка финансового микросервиса «Касса, Биллинг и Финансовый учет» (Billing Service & POS-терминал) для автоматизации платежей, управления кассовыми сменами, выставления счетов и сквозной финансовой аналитики в облачной медицинской информационной системе Digital Clinic Hub (DCH)
Создать отказоустойчивое, высокопроизводительное и идемпотентное платежное ядро, которое полностью устранит разрыв между медицинским приемом и финансовым учетом. Касса должна бесшовно интегрироваться с Интерактивным календарем и Электронной медицинской картой (ЭМК), обеспечивая моментальное выставление счетов, прозрачную обработку платежей (включая Kaspi QR и рассрочки) и автоматическое формирование фискальной и аналитической отчетности . Детальное описание функционала и технических решений: Интерфейс POS-терминала: Разработка единого рабочего экрана кассира (двухколоночный layout) на базе Vue.js 2, где весь флоу проведения оплаты умещается без необходимости скролла . Слева отображается состав счета (услуги, цены, скидки), справа — панель оплаты с интерактивным нумпадом 3×4 для быстрого ввода сумм и автоматического расчета сдачи клиентом по формуле Сдача = Принято − Итого . Методы оплаты и Смешанный биллинг: Поддержка множества методов оплаты: Наличные, банковские карты/POS, Kaspi QR и Kaspi Рассрочка . Реализуется сложная механика «Смешанной оплаты», позволяющая разбить один чек на части (например, часть оплатить наличными, а часть — через QR), при этом сервер создает две отдельные транзакции с валидацией совпадения сумм вплоть до тиына . Глубокая интеграция с Kaspi Pay API: При выборе Kaspi QR бэкенд DCH отправляет запрос к Kaspi Pay API, генерируя динамическую ссылку и QR-код . Интерфейс начинает поллинг (каждые 3 секунды в течение 15 минут) для проверки статуса . Дополнительно внедряется прием входящих Webhooks от Kaspi с обязательной верификацией криптографической подписи HMAC-SHA256 для защиты от подмены статуса . Строгое управление кассовыми сменами: Внедрение системы материальной ответственности. Кассир не может провести ни одной операции без открытой смены (наличие shift_id в JWT-токене проверяется Middleware) . При закрытии смены система автоматически подбивает баланс, сравнивает расчетную сумму с фактической наличностью в кассе, генерирует PDF Z-отчет (через pdfkit или puppeteer) и сохраняет его в S3-хранилище . Также доступна функция промежуточной инкассации . Жизненный цикл счета и контроль долгов: Система поддерживает статусы: draft, pending, partial, paid, debt, refunded, cancelled . Если пациент вносит лишь часть суммы, остаток автоматически фиксируется как долг, который сразу же подсвечивается координаторам и врачам в шапке ЭМК пациента . Модуль возвратов и скидок: Оформление возвратов доступно только из статуса paid и требует обязательного заполнения текстовой причины (минимум 10 символов) . Система скидок строго контролируется JWT-токеном: например, координатор может сделать скидку максимум до 10%, в то время как администратор не имеет ограничений . Интеграции и Уведомления: После успешной оплаты система автоматически генерирует фискальный/информационный чек в формате PDF и отправляет его пациенту на WhatsApp (через ChatApp) или Email . Если оплачивается курс лечения, DCH мгновенно отправляет Webhook в Bitrix24, переводя сделку на этап «Оплачено» (UF_PAYMENT_STATUS = 'paid') . Идемпотентность и безопасность БД: Все суммы в PostgreSQL хранятся в строгом финансовом типе NUMERIC(12,2) . Для исключения риска двойных списаний (например, если кассир дважды кликнул на кнопку при плохом интернете), API требует заголовок Idempotency-Key . Все кассовые действия тотально записываются в таблицу audit_log
Decision acceptance deadline
18.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
4
