Технологические задачи
Модуль Технологические задачи - это задачи, связанные с разработкой, внедрением и совершенствованием новых технологий, продуктов и процессов.
Если у вас есть потребность по разработке, внедрению и другие спросы вы можете разместить информацию ниже.
Скрипт переноса данных с СуБД 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
Интеллектуальная система контроля исполнения государственных контрактов и мониторинга качества выполненных работ
Создание цифровой платформы для объективного контроля выполнения работ и оказания услуг по государственным контрактам. Система должна обеспечивать: фото- и видеофиксацию выполненных работ; автоматическую геопривязку материалов; контроль сроков исполнения; анализ фактического выполнения работ с использованием технологий компьютерного зрения; мониторинг контрактов в режиме реального времени; выявление рисков неисполнения обязательств; формирование отчетности для заказчиков. Пример применения: Подрядчик выполнил ремонт дороги, установил освещение, провел благоустройство либо оказывает услуги по содержанию объектов. Через мобильное приложение загружаются материалы с координатами и временем съемки. Система автоматически подтверждает факт выполнения работ и выявляет возможные нарушения.
Прием решений до
22.06.26 (включительно)
Область задачи
бюджетный контроль, государственные закупки, мониторингКоличество заявок
13
Разработка финансового микросервиса «Касса, Биллинг и Финансовый учет» (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
Прием решений до
18.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
6
Разработка модуля «Отдел заботы и Управление многоэтапными процедурами» (Care Department & Treatment Course Management) для координации курсов лечения, отслеживания статусов конверсии, учета сеансов и распределения загрузки процедурных кабинетов в облачной медицинской информационной системе Digital Clinic Hub (DCH)
Создать специализированный цифровой инструмент для сотрудников «Отдела заботы» (Координаторов), который автоматизирует ведение пациента по сложным, многоэтапным курсам лечения (физиотерапия, КТ, ПРП-терапия и реабилитация). Главная задача модуля — связать медицинские назначения врачей с расписанием процедурных кабинетов и финансовым учетом, обеспечив максимальную конверсию пациентов из первичной консультации в покупку полного курса лечения. Детальное описание функционала и технических решений: Специализированный интерфейс Координатора: Разработка отдельного рабочего пространства, где пациенты распределены по вкладкам соответствующих курсов лечения (например, «Физио», «КТ», «ПРП», «FITNESS») . Координатор видит списки пациентов, которым врачи назначили процедуры, с отображением особенностей лечения . Учет и трекинг сеансов: Внедрение системы строгого контроля за прохождением курсов. В таблице Отдела заботы автоматически ведется точный математический учет: отображается общее количество назначенных сеансов, количество фактически пройденных процедур, а также количество пропущенных пациентом визитов . Модуль управления расписанием процедур: Сотрудники Отдела заботы получают возможность добавлять соответствующие процедуры пациентам, подбирая требуемое и удобное для пациента время . Для этого разрабатывается специальная сетка календаря (отличная от календаря врачей), ориентированная на загрузку конкретных аппаратов и кабинетов (например, график работы аппарата КТ или кабинета физиотерапии) . Модуль отметок посещений: Интеграция функционала, позволяющего врачу или координатору в один клик ставить отметку о факте успешного прохождения пациентом конкретной процедуры из курса . Управление статусами конверсии (Воронка): Координатор работает со своим физическим филиалом и отвечает за "дожим" пациента. Он наделен эксклюзивным правом проставлять в системе важнейшие конверсионные статусы: «Купил курс лечения» или «Не купил курс» . Гибкие финансовые права (RBAC): Для стимулирования продаж система (через проверку JWT-токена) наделяет Координатора частичными правами кассира. Координатор может самостоятельно создавать счета, принимать оплату (наличными, картой, Kaspi QR) и применять мотивирующую скидку до 10% . При этом координатору жестко запрещено оформлять финансовые возвраты, делать скидки более 10% или управлять закрытием кассовых смен
Прием решений до
18.06.26 (включительно)
Область задачи
Другие технологические решенияКоличество заявок
5
