Технологические задачи
Модуль Технологические задачи - это задачи, связанные с разработкой, внедрением и совершенствованием новых технологий, продуктов и процессов.
Если у вас есть потребность по разработке, внедрению и другие спросы вы можете разместить информацию ниже.
Разработка фундаментального микросервиса «Ядро биллинга, архитектура баз данных и базовая оплата (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
Разработка микросервиса «Финансовая аналитика и 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-токена, что пресекает любую утечку коммерческой тайны линейному персоналу
Прием решений до
23.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
7
Разработка микросервиса «Управление кассовыми сменами, инкассация и автоматическая генерация 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-совместимое объектное хранилище , а токен кассира аннулируется
Прием решений до
23.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
3
Разработка микросервиса «Финтех-интеграция и безналичные платежи (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 фиксирует этот метод в системе
Прием решений до
23.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
5
Разработка и внедрение модуля «Интерактивный календарь записей пациентов 2.0» (Record Calendar System 2.0) — высоконагруженного ядра управления потоками пациентов, расписанием врачей и загрузкой филиалов для облачной медицинской информационной системы Digital Clinic Hub (DCH)
Создание отказоустойчивой, интуитивно понятной и автоматизированной системы маршрутизации пациентов, которая объединит работу колл-центра, регистратуры и медицинского персонала в едином цифровом пространстве реального времени. Главная задача модуля — обеспечить бесшовный процесс записи, исключить человеческий фактор при распределении времени врачей и предоставить управленческому составу сквозную аналитику по эффективности каждого сотрудника. Детальное описание функционала и технических решений: Визуализация и смарт-фильтрация: Интерактивная сетка расписания с тремя режимами отображения (по дням, неделям, месяцам) . Внедряется механизм мгновенной фильтрации слотов без перезагрузки страницы: по конкретному врачу, дате, физическому филиалу и городу . Цветовая и визуальная маркировка динамически меняется в зависимости от статуса записи: «Запланирован», «Забронировано», «Пришёл», «Не пришёл», «Отменён», «Купил курс / Не купил курс», «Промежуточный осмотр» . Механика 10-минутной брони (Smart-Hold): Для предотвращения двойных записей (race conditions) в условиях работы высоконагруженного колл-центра внедряется уникальная логика бронирования. При начале оформления пациента слот мгновенно блокируется для других операторов на 10 минут . По истечении этого времени, если запись не была подтверждена, система автоматически (без участия пользователя и без обновления страницы) снимает бронь, возвращая слот в свободную продажу . Динамическое расписание и перезапись (Drag-and-Drop): Если пациенту требуется визит в нестандартное время, отсутствующее в сетке врача, менеджер просто вводит это время, и система автоматически расширяет расписание, генерируя новое окно . Реализован механизм быстрого переноса (перезаписи) карточки пациента на другое время или к другому специалисту с помощью визуального интерфейса — старый слот при этом автоматически освобождается . Промежуточные осмотры: Внедрен механизм создания повторных/коротких визитов для пациентов, проходящих курс лечения, с помощью двойного клика . При этом требуется ввести минимум данных (только ФИО и телефон), а сама карточка визуально отличается от первичной консультации . Важнейшая бизнес-логика: промежуточные осмотры алгоритмически исключаются из расчета конверсии прихода для оценки реальной эффективности продаж колл-центра . Аналитика и Дашборды (BI): Администраторы получают доступ к сводным таблицам и графикам. Главная метрика — процент конверсии менеджеров колл-центра, который рассчитывается сервером по строгой формуле: Пришло / (Итого - Промежуточные осмотры) × 100% . Также реализована аналитика по причинам отмен (с долями от общего числа), конверсии конкретных врачей и филиалов с возможностью выгрузки отчетов в Excel
Прием решений до
23.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
5
Создание локальной системы управления корпоративным магазином мерча
Разработка локальной веб-системы управления корпоративным магазином мерча (swag store) с функцией начисления и учета виртуальных баллов для сотрудников, с возможностью развертывания и полноценной работы системы на серверах компании без использования облачных сервисов, с возможностью обеспечения максимальной конфиденциальности данных и максимальной автоматизации процессов. Веб-приложение должно также позволять получать статистику по товарам, пользователям, распределению баллов, активности; быть удобным в использовании и доступным с любого устройства, подключенного к сети
Прием решений до
22.06.26 (включительно)
Область задачи
Web разработкаКоличество заявок
12
Техническая оптимизация программного обеспечения
Повышение производительности, стабильности и надёжности программного обеспечения. Комплексная техническая оптимизация всех слоёв информационной системы — базы данных, серверной бизнес-логики, модуля электронных медицинских карт и интеграционного слоя с государственными системами Республики Казахстан — с целью ускорения работы системы, снижения количества ошибок и обеспечения стабильной работы при высокой пользовательской нагрузке.
Прием решений до
22.06.26 (включительно)
Область задачи
Обработка и преобразование информацииКоличество заявок
7
