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 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
Development and implementation of the "Interactive Patient Record Calendar 2.0" module (Record Calendar System 2.0), a highly loaded core for managing patient flows, doctors' schedules, and branch downloads for the Digital Clinic Hub (DCH) cloud medical information system
Creation of a fault-tolerant, intuitive and automated patient routing system that will combine the work of the call center, registry and medical staff in a single real-time digital space. The main objective of the module is to ensure a seamless recording process, eliminate the human factor in allocating doctors' time, and provide management with end—to-end analytics on the effectiveness of each employee. Detailed description of the functionality and technical solutions: Visualization and smart filtering: Interactive schedule grid with three display modes (by day, week, month). A mechanism is being implemented for instant filtering of slots without reloading the page: by a specific doctor, date, physical branch and city. """"""""""" The color and visual markings change dynamically depending on the status of the record: "Scheduled", "Booked", "Arrived", "Did not arrive", "Canceled", "Bought course / I did not buy the course", "Intermediate inspection". Mechanics of 10-minute armor (Smart-Hold): A unique booking logic is being implemented to prevent double entries (race conditions) in a highly loaded call center. When the patient registration begins, the slot is instantly blocked for other operators for 10 minutes. After this time, if the entry has not been confirmed, the system automatically (without user participation and without updating the page) cancels the reservation, returning the slot to free sale. Dynamic schedule and rewrite (Drag-and-Drop): If a patient needs a visit at a non-standard time that is not on the doctor's schedule, the manager simply enters this time, and the system automatically expands the schedule, generating a new window. The mechanism of fast transfer (rewriting) is implemented patient cards for another time or to another specialist using the visual interface — the old slot is automatically released . Interim checkups: A mechanism has been introduced to create repeat/short visits for patients undergoing treatment using a double click. At the same time, you need to enter a minimum of data (only your full name and phone number), and the card itself is visually different from the initial consultation. The most important business logic: intermediate inspections are algorithmically excluded from the calculation of the arrival conversion to assess the actual sales effectiveness of the call center. Analytics and Dashboards (BI): Administrators get access to pivot tables and graphs. The main metric is the conversion rate of call center managers, which is calculated by the server using a strict formula: Received / (Total - Interim inspections) × 100%. Analytics for cancellation reasons (with fractions of the total number), conversions of specific doctors and branches with the ability to upload reports to Excel are also implemented.
Decision acceptance deadline
23.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
5
Creation of a local management system for a corporate merch store
Development of a local web-based management system for a corporate merch store (swag store) with the function of accruing and accounting virtual points for employees, with the ability to deploy and fully operate the system on company servers without using cloud services, with the ability to ensure maximum data confidentiality and maximum automation of processes. The web application should also allow you to get statistics on products, users, points distribution, activity; it should be easy to use and accessible from any device connected to the network.
Decision acceptance deadline
22.06.26 (inclusive)
Preferred systems
Web разработкаNumber of applications
12
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
7
