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.
Automation and optimization of internal processes
Automate the management and distribution of experts, mentors, and freelancers for incoming applications.
Decision acceptance deadline
03.07.26 (inclusive)
Preferred systems
Intelligent control systemsNumber of applications
18
Interactive onboarding systems for the B2B AI platform
The goal: to implement a ready-made solution (software/tool) for creating interactive, seamless and fast onboarding inside our AI platform. Description: The key task now is to reduce the Time-to-Value for new users. We need a solution that allows us to deploy interactive scenarios inside the interface without using hard hard code (preferably No-code/Low-code): step-by-step tours and interactive checklists. The system must recognize user actions in real time and guide them through the activation funnel.
Decision acceptance deadline
03.07.26 (inclusive)
Preferred systems
Neurotechnology and artificial IntelligenceNumber of applications
8
to develop a calendar/schedule UI component
Develop a calendar/schedule UI component for displaying events in a time grid. The component should be used in Vue applications and allow you to visually show time occupancy.
Decision acceptance deadline
03.07.26 (inclusive)
Preferred systems
Intelligent control systemsNumber of applications
11
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
