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 "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
An intelligent system for monitoring the execution of government contracts and monitoring the quality of work performed
Creation of a digital platform for objective monitoring of the performance of works and the provision of services under government contracts. The system should provide: photo and video recording of completed works; automatic geolocation of materials; control of deadlines; analysis of the actual performance of work using computer vision technologies; real-time contract monitoring; identification of risks of default; reporting for customers. Application example: The contractor has repaired the road, installed lighting, carried out landscaping or provides services for the maintenance of facilities. Materials with coordinates and shooting time are uploaded via the mobile application. The system automatically confirms that the work has been completed and identifies possible violations.
Decision acceptance deadline
22.06.26 (inclusive)
Preferred systems
бюджетный контроль, государственные закупки, мониторингNumber of applications
13
Development of the financial microservice "Cash Register, Billing and Financial Accounting" (Billing Service & POS terminal) for payment automation, cash shift management, billing and end-to-end financial analytics in the cloud-based medical information system Digital Clinic Hub (DCH)
Create a fault-tolerant, high-performance, and idempotent payment core that completely bridges the gap between medical admission and financial accounting. The cash register should seamlessly integrate with an Interactive Calendar and Electronic Medical Record (EHR), providing instant billing, transparent payment processing (including Kaspi QR and installments) and automatic generation of fiscal and analytical reports . Detailed description of the functionality and technical solutions: POS terminal interface: Development of a single cashier's desktop (two-column layout) based on Vue.js 2, where the entire payment flow fits without the need for scrolling . The composition of the invoice (services, prices, discounts) is displayed on the left, and the payment panel with an interactive 3×4 numpad is displayed on the right for quick entry of amounts and automatic calculation of the customer's change using the Change formula = Accepted − Total. Payment Methods and Mixed Billing: Support for multiple payment methods: Cash, Bank Cards/POS, Kaspi QR and Kaspi Installment . A complex "Mixed Payment" mechanism is implemented, which allows you to split one check into parts (for example, to pay in cash and part via QR), while the server creates two separate transactions with validation of matching amounts up to the amount. Deep integration with Kaspi Pay API: When you select Kaspi QR, the DCH backend sends a request to the Kaspi Pay API, generating a dynamic link and a QR code . The interface starts polling (every 3 seconds for 15 minutes) to check the status . Additionally, incoming Webhooks from Kaspi are being accepted with mandatory verification of the HMAC-SHA256 cryptographic signature to protect against status substitution . Strict management of cash shifts: Implementation of a financial responsibility system. The cashier cannot perform any operations without an open shift (the presence of shift_id in the JWT token is checked by Middleware) . When the shift is closed, the system automatically adjusts the balance, compares the estimated amount with the actual cash in the cash register, generates a PDF Z-report (via pdfkit or puppeteer) and saves it to S3 storage . An intermediate collection function is also available . Account lifecycle and debt control: The system supports the following statuses: draft, pending, partial, paid, owed, refunded, cancelled . If the patient pays only a part of the amount, the balance is automatically recorded as a debt, which is immediately highlighted to the coordinators and doctors in the patient's EHR header . The refunds and discounts module: Making refunds is only available from the paid status and requires you to fill in a text reason (at least 10 characters) . The discount system is strictly controlled by the JWT token: for example, the coordinator can make a discount of up to 10%, while the administrator has no restrictions . Integration and Notifications: After successful payment, the system automatically generates a fiscal/information receipt in PDF format and sends it to the patient via WhatsApp (via ChatApp) or Email . If the treatment is paid for, DCH instantly sends a Webhook to Bitrix24, transferring the transaction to the "Paid" stage (UF_PAYMENT_STATUS = 'paid') . DATABASE idempotence and security: All amounts in PostgreSQL are stored in the strict NUMERIC financial type(12.2) . To eliminate the risk of double charges (for example, if the cashier double-clicked on the button when the Internet was bad), the API requires the Idempotency-Key header. All cash transactions are recorded in the audit_log table.
Decision acceptance deadline
18.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
6
Development of the module "Department of care and Management of multi-stage procedures" (Care Department & Treatment Course Management) to coordinate treatment courses, track conversion statuses, record sessions, and distribute downloads of treatment rooms in the Digital Clinic Hub (DCH) cloud medical information system
To create a specialized digital tool for the staff of the "Department of Care" (Coordinators), which automates the management of patients through complex, multi-stage treatment courses (physiotherapy, CT, PREP therapy and rehabilitation). The main objective of the module is to link doctors' medical appointments with the schedule of treatment rooms and financial accounting, ensuring maximum conversion of patients from the initial consultation to the purchase of a full course of treatment. """""" Detailed description of functionality and technical solutions: ""Specialized Coordinator interface: Development of a separate workspace, where patients are divided into tabs of the appropriate treatment courses (for example, "Physio", "CT", "PRP", "FITNESS") . The coordinator sees lists of patients to whom doctors have prescribed procedures, with a display of treatment features . Recording and tracking sessions: Implementation of a strict monitoring system for the completion of courses. The Care Department's table automatically keeps accurate mathematical records: the total number of sessions scheduled, the number of procedures actually performed, and the number of visits missed by the patient are displayed . Procedure schedule management module: The staff of the Care Department have the opportunity to add appropriate procedures to patients, choosing the time required and convenient for the patient. . For this purpose, a special calendar grid is being developed (different from the doctors' calendar), focused on the workload of specific devices and rooms (for example, the schedule of the CT machine or the physiotherapy room) . Visit marking module: Integration of functionality that allows a doctor or coordinator to mark the fact of a patient's successful completion of a specific procedure from the course in one click . Conversion status management (Funnel): The coordinator works with his physical branch and is responsible for the patient's "follow-up". "He" is given the exclusive right to put down the most important conversion statuses in the system: "Bought a course of treatment" or "Did not buy a course ." Flexible Financial Rights (RBAC): To stimulate sales, the system grants the Coordinator partial cashier rights (through verification of the JWT token). The coordinator can independently create invoices, accept payments (in cash, by card, Kaspi QR) and apply a motivating discount of up to 10% . At the same time, the coordinator is strictly prohibited from making financial refunds, making discounts of more than 10%, or managing the closure of cash shifts.
Decision acceptance deadline
18.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
5
Development of an internal module "CRM system, Sales Funnels and End-to-end Integration" (CRM & Patient Journey Funnels) for patient lifecycle management, call center automation and deep two-way synchronization with Bitrix24 within the Digital Clinic Hub (DCH) cloud medical information system
Create a seamless lead management system (potential patients) that will combine the clinic's marketing efforts with the actual medical admission and cash register. The main objective of the module is to digitize the patient's Journey from the first click on an advertisement to the successful completion of the treatment plan, eliminate the loss of leads due to the human factor, and automate the task of setting operators to "wait" or return the patient. Detailed description of the functionality and technical solutions: Visual Kanban Boards (Funnels): Development of interactive sales funnels divided by branches . """"""""""The patient's card visually moves through the stages (stages of the transaction): "New treatment", ""Hired", "Made an appointment", "Came to the initial appointment", "Assigned course", "Bought course / Successfully completed", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal", "Refusal / He didn't come." The drag-and-drop mechanism for manual movement is supported, as well as automatic stage change based on system triggers. Deep two-way synchronization with Bitrix24: The module acts as an integration core between DCH and external CRM. Any change in DCH should be instantly reflected in Bitrix24 via Webhooks . If the CC operator selects a non-standard time in the DCH calendar, a new window is automatically created in Bitrix24 . Upon successful payment in the "Checkout" module, DCH sends a PATCH request to the Bitrix24 API to update the transaction stage and the UF_PAYMENT_STATUS = 'paid' field. The opposite direction also works: when an entry is created in the iDoctor aggregator application or in Bitrix24, it is automatically converted into a patient card and occupies a slot in the DCH calendar grid . Trigger automation and task setting: The system automatically responds to statuses from the Interactive Calendar. """" For example, if the Registrar sets the status "Not received," the CRM module automatically transfers the patient's card to the "Missed" stage and generates an urgent Task for the call center manager with a deadline - "Contact the patient to transfer the record." If the parish Department sets the status to "Canceled" , the system requires you to specify the reason and sets the task for quality control. Omnichannel and Communication (ChatApp): Integration with ChatApp, WhatsApp Business API and Facebook Messenger services to aggregate all correspondence with the patient directly in his card inside the CRM . Automatic sending of reminders 24 and 2 hours before the appointment to minimize the no-show rate . Analysis of the reasons for failures (Lost Reasons): A required field when transferring a card to the "Failure" stage or when canceling an entry . """" The data is aggregated into a special dashboard of the administrator, showing the churn funnel (for example, "Expensive", "Inconvenient time", "Chose competitors").
Decision acceptance deadline
18.06.26 (inclusive)
Preferred systems
Other technological solutionsNumber of applications
7
