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.
Development of an AI system for personalized recommendations of video content for a digital media platform.
Development of an AI system for personalized recommendations of video content for a digital media platform. The solution should provide real-time analysis of user behavior, take into account browsing history, interaction with content, genre preferences, and automatically generate a personalized recommendation feed. The system should use machine learning algorithms for continuous self-learning based on new user data, as well as provide the ability to analyze the effectiveness of recommendations and the impact on user activity. The main goal of the project is to increase user retention, increase audience engagement, and optimize content delivery processes through the use of artificial intelligence technologies.
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Neurotechnology and artificial IntelligenceNumber of applications
15
The core of the system is Security, Architecture and Role Model (RBAC) Product: Digital Clinic Hub (DCH) Cloud—based Medical Information System
The creation of an absolutely secure, fault—tolerant and scalable cloud platform (SaaS) core, which will become the technological foundation for all subsequent functional modules of the system (Calendar, Cash Register, EMC, etc.). The main task of this block is to ensure an unprecedented level of isolation of medical and financial data between different client clinics, as well as to introduce an insurmountable system of separation of rights access for employees within each clinic Detailed description of functionality and technical solutions: Multi-tenant microservice architecture: The core of the system is designed on the basis of Node.js and PostgreSQL. Each clinic (or a separate branch of a network clinic) receives a separate database (logical or physical separation at the schema level), which guarantees complete isolation of customer data and support for the franchise structure. Authentication and Authorization System (JWT): A mechanism for stateless authentication using JSON Web Tokens (JWT) is being implemented. Every action in the system is validated through Middleware based on the payload of the token. Critical data is hardwired in the token: role (user role), branch_id (branch ID to limit visibility), sub (user ID), shift_id (ID of the active cash shift) and max_discount_pct (acceptable discount percentage). Access Rights Matrix (RBAC): The core implements strict access control for 6 main roles, where rights are checked directly at the API endpoint level: Admin: Full access to all branches, directories, hidden analytics and cancelled records. Can apply any discounts and delete documents. Call Center Manager: Access to the schedule of all branches for creating, editing, transferring records and making a 10-minute reservation. Access to finance is completely closed. (The "Parish Department" may additionally cancel entries with an indication of the reason). Registrar: Strictly limited to its physical branch. "He" can only change the patient's attendance status ("He came" / "He did not come"). Doctor: Isolated access only to his records. He can add medical comments, but is not allowed to edit schedules or finances. "Coordinator" Manages the financial statuses of treatment courses ("Bought course" / "Did not buy"), has the right to create invoices and apply a discount (for example, strictly up to 10%), but cannot make refunds or manage cash shifts. Cashier: He has access to the POS terminal of his branch, can open/close shifts, make payments, make Z-reports and make refunds. Total audit and logging (Audit Log): Development of a logging module that tightly records all critical operations in the system (creation, cancellation of records, acceptance of payments, refunds) in the audit_log service table. ""The system records the user_id, time, type of action, and the status of the data "before" and "after" the changes were made. Idempotence and protection: To eliminate the risk of double write-offs or duplicate entries with an unstable Internet, the core implements support for the Idempotency-Key header for all POST requests.
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
7
Development of the fundamental clinical module "Electronic Medical Record (EHR) and digital workplace of the doctor" with integration of management of stages of treatment (physiotherapy, CT, PREP therapy) for the cloud medical information system Digital Clinic Hub (DCH).
To create a single, intuitive digital workspace for medical personnel, which will completely replace paper document management. The main task of the EMC is to ensure a seamless clinical path of the patient from the collection of medical history to the completion of multi—stage treatment courses, as well as to reliably link medical appointments with the work of the Coordinators (Department of Care) and the Cash Register. Detailed description of the functionality and technical solutions: Architecture of the patient card: Development of a comprehensive interface based on Vue.js 2 . """""" The card will include a passport part (IIN, full name, phone number, date of birth) and a system of tabs: "Admission history", "Treatment plan", "Media files" and "Finance". The card header will display the patient's balance and whether he has debts to the clinic in real time. Dynamic examination templates and reference books: Implementation of the examination protocol designer for different medical specialties. The doctor will be able to quickly fill in complaints, medical history and objective status, as well as add text medical comments to the appointment. The international ICD-10 handbook will be integrated to standardize diagnoses. Multi-stage Treatment Management (Procedure Courses): An essential part of the DCH EHR. The patient's card will have the functionality to save and track complex stages of treatment: courses of physiotherapy, CT, PREP therapy and fitness rehabilitation. The doctor makes an appointment, and the interface of the Care Department is instantly updated, allowing the coordinators to add procedures according to the patient's required time. Secure storage of media files: Integration with secure cloud storage for uploading test results, ultrasound and heavy DICOM images (CT/MRI) with strict reference to the date of the patient's visit and his ID. The Role Model (RBAC) in EMC: Doctor: has isolated access exclusively to the medical records of his patients. Can make comments and assignments . Coordinator / Department of Care: sees the doctor's appointment to indicate the purchase status of the course ("Bought a course / Not bought") and management of the loading grid of treatment rooms . CC manager: sees only contact information for creating records, but does not have access to medical secrets (diagnoses) inside the patient's card. Technology stack: The backend is being developed on Node.js with the PostgreSQL database . Caching will be used to instantly save examination drafts (if the doctor has lost the Internet), and S3—compatible storage will be used to download files.
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
7
Development of the fundamental microservice "Billing Core, Database Architecture and Basic Payment (Core & Cash)" for the POS terminal module of the Digital Clinic Hub (DCH) cloud medical information system.
To lay a fault-tolerant, scalable and high-performance foundation for the entire financial contour of the clinic. The main task of this block is to design a reliable database architecture (invoices, transactions, check positions), implement strict validation of access rights through JWT tokens at the API gateway level, and implement the basic but most critical cash payment process with automatic settlement of the deposit to the client and protection against double payments. Detailed description of the functionality and technical solutions: Database architecture and financial data types: Designing key tables in PostgreSQL: invoices, invoice_items, and transactions . The fundamental technical requirement is that all amounts (prices, discounts, totals, delivery) must be stored in the database exclusively in the strict NUMERIC(12.2) financial format (categorically prohibiting the use of the float data type), and all critical calculations must take place on the backend side to eliminate errors on the client . Services Database: Development and integration of the services table (a call via the endpoint GET /api/v2/services?search=) to automatically add items (medical services or goods) to the invoice . Each item in the receipt will be rigidly linked to the directory, including its default value and VAT rate (vat_pct) . RBAC and Transaction Protection (JWT Middleware): Every cash transaction (creating an invoice, applying a discount, making a payment) must pass through a strict security filter. Middleware verifies the cashier's JWT token by validating the required fields: role (rights level), branch_id (limiting account visibility only to its branch), sub (employee ID) and max_discount_pct (acceptable personal discount limit) . The most important thing is that the server checks for shift_id. If the user does not have an open cash shift, the operation is blocked with the HTTP 403 NO_ACTIVE_SHIFT status . Cash Flow: Development of an algorithm for accepting cash without external banking integration . The server accepts the amount_paid parameter (how much the patient gave). If the accepted amount is less than the total amount of the invoice, the API automatically rejects the transaction with the error 422 INSUFFICIENT_AMOUNT . The change is calculated on the client reactively (change = amount_paid - total) . Upon successful execution, the account status is atomically transferred by the server to the paid (or partial) status, after which the WebSocket payment.completed event is sent to the client for instant updating of the POS terminal interface . Idempotence and Audit (Audit Log): Implementation of a protection mechanism against network failures and double clicks. The critical Endpoint POST /api/v2/invoices/:id/pay requires mandatory transmission of the Idempotency-Key header. With a duplicate request, the server will return the original cached response without creating a double transaction . At the same time, any actions are rigidly logged into the global audit_log table, which stores who performed the operation, what the action was, and the JSON status of the receipt before and after.
Decision acceptance deadline
26.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
6
Automatic Speech Recognition (ASR) module with support for diorization for speakers
Creation of an automatic speech recognition (ASR) module with diorization support for two speakers, ensuring accurate separation of phrases and correct shorthand of audio recordings in Russian and Kazakh. Task description: To develop a software mechanism that accepts an audio file as input and performs the following functions: 1. definition of speech sections and automatic separation into two speakers; 2. Speech recognition in Russian and Kazakh languages; 3. formation of a text file with speaker markup and timestamps; 4. Ensuring diorization accuracy of at least 90% and recognition accuracy of at least 85%; 5. Providing the finished result in a format suitable for subsequent analysis and integration.
Decision acceptance deadline
25.06.26 (inclusive)
Preferred systems
Neurotechnology and artificial IntelligenceNumber of applications
9
Multi-agent data mining platform
Development and scaling of a pilot AI assistant solution based on a multi-agent AI platform for working with structured company data. The solution should provide employees of the parent company, distribution centers and trucking companies with access to AI assistants that allow them to analyze operational indicators, ask questions in natural language, receive answers based on company data, create tables, graphs, widgets and personalized dashboards. The project requires finalizing the pilot solution, preparing it for commercial operation, integrating it with AD/LDAP, Trino, ClickHouse and LLM models of the customer, providing container delivery, monitoring, documentation, user training and technical support.
Decision acceptance deadline
24.06.26 (inclusive)
Preferred systems
Information processing and transformationNumber of applications
11
Script for transferring data from Oracle 11.2.0.4 DBMS from SPARK family system to Intel X64
Due to the relocation of the Oracle 11.2.0.4 DBMS system from the SPARK family system to Intel X64, it is necessary to prepare a PERL script for migrating the patricia and the entire 20.54 Terabyte DBMS.
Decision acceptance deadline
24.06.26 (inclusive)
Preferred systems
Intelligent control systemsNumber of applications
5
Development of the "Financial Analytics and BI Dashboards (Analytics & Reports)" microservice for transaction aggregation, visualization of key metrics (KPIs) and automatic generation of management reports in the POS terminal module of the Digital Clinic Hub (DCH) cloud medical information system.
Create a powerful, interactive and completely transparent analytical tool for business owners, chief medical officers and financial directors of clinics. The main task of this block is to consolidate financial flows from all cash shifts and branches in real time, provide visual visualization of the revenue structure and automate the uploading of reports, without creating any delays in the operation of the main cash register. Detailed description of functionality and technical solutions: Isolated database architecture (Read Replica): This is a key engineering decision of the unit. All heavy analytical SQL queries (aggregations of annual amounts, complex transaction samples) are routed to a separate replica of the PostgreSQL database . This ensures that the formation of a huge report for management will not physically be able to block the transaction tables and will not slow down the work of the cashiers in the lobby of the clinic . Interactive Financial Dashboard: Development of a single control center (summary screen) using modern graphics libraries (Chart.js or ECharts) . The dashboard includes 5 key KPIs arranged in a row: revenue per day, revenue per month, the current amount owed by patients, the average receipt, and the number of canceled bills . Visualization of payment methods and transactions: Under the graph of revenue dynamics by day, there is a pie chart with a breakdown of incoming funds (as a percentage) by payment channels: Cash, Kaspi QR, Bank Card, Kaspi Installment Plan. An interactive table of recent transactions is displayed at the bottom of the screen, indicating the amount, cashier, patient, and status . Report generation system: Development of specialized REST API endpoints (for example, /analytics/revenue, /analytics/avg-receipt, /reports/daily, /reports/monthly) for flexible data query . The module provides the ability to download consolidated financial data in Excel and PDF formats in one click . The technical standard of the system: exporting a data array of more than 1000 rows to Excel should be performed in just 5-10 seconds . Access Rights Matrix (RBAC): The "Admin" role only has access to the financial dashboard, hidden analytics, and report export . For cashiers, coordinators, registrars, and doctors, these endpoints are blocked at the JWT token level, which prevents any leakage of trade secrets to line staff.
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
7
Development of the microservice "Cash shift management, collection and automatic generation of Z-reports (Shift Management)" as part of the financial module of the POS terminal of the Digital Clinic Hub (DCH) cloud medical information system
To introduce a system of strict digital, financial and personal responsibility of cashiers in clinics. The main task of this block is to algorithmically prohibit any unauthorized financial transactions "outside the cash register", ensure strict cash accounting from the moment of opening to the moment of closing the working day, and fully automate the calculation of total revenue with the generation of fiscal Z-reports. Detailed description of the functionality and technical solutions: Shift opening mechanics and JWT validation: The cashier's working day begins with the "Shift Card" interface . The cashier initiates a POST request to open the shift, where he must record the remaining cash in the cash register at the time of start (opening_balance) . The server creates an entry in the shifts table, and most importantly, updates the user's JWT token by sewing shift_id into it. . This is a critical security element: The Middleware of the backend blocks any transactions (payment, refund) if there is no active shift_id in the token, returning the error 403 NO_ACTIVE_SHIFT . Protection against parallel shifts: The system checks the open shifts of the branch at the database level. If one cashier has already opened a shift, the second cashier's attempt to open a parallel cashier in the same branch is blocked by the server with error 409 SHIFT_ALREADY_OPEN . Cash-out: The introduction of a mechanism for safely withdrawing cash from the cash register during the day (for example, for transfer to cash collectors) without closing the shift itself. The POST /api/v2/shifts/:id/cash-out endpoint is used for this . Collection is recorded in the system, affects the estimated final cash balance (closing_balance), but does not mathematically distort the total revenue of the clinic . Cash reconciliation and shortage calculation: When you click "Close shift", the system summarizes the results: the cashier must manually enter the actual amount of paper money in the cash register (cash_drawer_closing) . The server compares the entered amount with the calculated amount using the formula: closing_balance − (opening_balance + cash_in − cash_out). Any discrepancies (shortfall or excess) are firmly fixed in the discretion field . Automatic generation of Z-reports: The server performs complex SQL aggregations (COUNT and SUM) of all transactions during the shift period with an accurate breakdown by methods: Cash, Kaspi, Card, Refunds and Net Revenue . After mathematical reconciliation, the backend uses the pdfkit library (or puppeteer) to instantly generate a PDF document (Z-report) . The generated file is saved to a secure S3-compatible object storage , and the cashier's token is revoked.
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
3
Development of the microservice "Fintech integration and cashless payments (Kaspi Ecosystem & Mixed Payments)" for automating acquiring, processing QR payments, installments and mixed payments in the POS terminal module of the Digital Clinic Hub (DCH) cloud medical information system.
Create a secure, high-speed and fully automated gateway for accepting non-cash payments from patients. The main task of this block is to seamlessly integrate the Kaspi Pay API into the DCH cash register interface, eliminate manual entry of amounts at physical terminals, automate receipt of payment statuses (via Webhooks and Polling) and implement complex "mixed payment" mechanics, guaranteeing cryptographic transaction protection. Detailed description of the functionality and technical solutions: Deep integration with Kaspi Pay API (QR payments): Development of dynamic QR code generation mechanics. When choosing the "Kaspi QR" payment method, the DCH backend makes a POST/api/v2/payments/kaspi/qr request to the external Kaspi API, transmitting the exact amount and a unique invoice_id . In response, the server returns a graphical QR code (base64 PNG) and payment_id, which are instantly displayed on the cashier's screen . The waiting time for payment using the generated QR code is 15 minutes . A dual status tracking system (Polling + Webhooks): A fail-safe bundle is being implemented to ensure payment confirmation. The client part (POS screen) starts polling: it sends GET/api/v2/payments/:payment_id/status requests every 3 seconds . In parallel, the DCH backend configures a secure endpoint POST /api/v2/webhooks/kaspi to receive asynchronous notifications (Webhooks) from Kaspi servers about a change in payment status . Cryptographic transaction Protection: This is a critical security element. Any incoming webhook from Kaspi is subject to mandatory verification. The system calculates the HMAC-SHA256 hash(body, kaspi_webhook_secret) and checks it against the signature from the header . Requests without a valid signature are instantly rejected with an HTTP 401 error, which makes it impossible for attackers to substitute the payment status . With the PAID status, the system atomically updates the transaction, changes the account status, and publishes the WebSocket event payment.completed for the interface . Mechanics of Kaspi Installments: Implementation of the POST /api/v2/payments/kaspi/installation endpoint to integrate the option of choosing the installment period (3, 6 or 12 months) directly from the DCH POS terminal . The bank approves the loan asynchronously, and the status in DCH is updated via a webhook . Mixed Payments: Implementation of complex business logic for cases when the patient wants to pay one bill in different ways (for example, 30,000 tenge in cash and 20,000 tenge via Kaspi QR) . The interface provides two input fields. The server creates two different transactions (using the cash and kaspi_qr methods) linked to the same account, and performs strict mathematical validation: SUM(transaction.amount) = invoice.total_amount (accurate to 1 tenge) . Bank Cards and PCI DSS: DCH does not store or transfer bank card data, leaving the physical processing to POS terminals (ensuring PCI DSS compliance) . The cashier clicks the "Payment completed" button after confirmation at the physical bank terminal, and DCH records this method in the system.
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
5
