Price: 40000
Number of applications: 6
18.06.26 (inclusive)
Under discussion
Idea
ICT tasks
Medicine
Other technological solutions
Software/ IS
Financial processes in most private clinics remain one of the most vulnerable and poorly automated areas.: Manual and duplicate accounting: Clinics keep financial records in Excel, cash registers, or in third-party programs (for example, 1C) that have nothing to do with the medical schedule . Administrators have to manually transfer the data on the services provided from the patient's card to the cashier, which inevitably leads to typos, loss of positions in the receipt and lost profits . Debt blind spot: Due to the isolation of the cash register from the calendar, the coordinators and doctors do not see at the time of the visit that the patient has an old debt for previous appointments . As a result, the clinic lends to patients, losing significant funds. There is chaos in refunds and discounts: Making refunds often requires accounting and takes up to several days . Cashiers apply discounts uncontrollably, and when changing shifts, it is impossible to track which of the operators made a shortage at the checkout, since the shift is not linked to the user's digital profile . Opacity for guidance: Investors and chief medical officers do not have access to real-time analytics. There is no understanding of the distribution of revenue by payment methods (how much came through Kaspi and how much in cash), which makes financial planning and cash flow control difficult.
The launch of a billing microservice radically transforms the financial discipline of a medical institution: Zero accounting errors: Thanks to the automatic pull-up of services from the Calendar and the EHR directly into the POS terminal, errors during manual transfer and billing will decrease to 0% . A drastic increase in debt collection: Displaying the patient's balance in the cashier's interface and the EHRC header will allow administrators and coordinators to see debts in real time, which is projected to increase debt collection by 30% . Total personal responsibility: Mandatory opening of cash-locked shifts (opening_balance) and generation of personalized Z-reports at closing (closing_balance) will eliminate opportunities for financial manipulation and shortages among cashiers . Acceleration of operational processes: Automation of refunds (including through the Kaspi Refund API) will reduce the time for making a refund from 3 days to 15 minutes . By integrating with ChatApp, receipts will be issued instantly on WhatsApp, increasing patient loyalty . Absolute transparency for business: Management will have access to financial dashboards (which are accessed via the Read Replica database so as not to overload the cash registers), where KPIs for revenue, average receipt, and a breakdown of all payment methods will be displayed in real time.
Amina Agzamova
Purpose and description of task (project)
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.
Whatsapp
