Price: 0
Number of applications: 6
26.06.26 (inclusive)
Оплата
Idea
ICT tasks
Medicine
Other technological solutions
Software/ IS
Historically, financial accounting in most private medical centers in the CIS is the most vulnerable operational area, full of manual labor and errors related to the human factor. Manual data transfer and direct financial losses: Currently, clinic administrators keep records of payments in Excel spreadsheets or third-party cash register programs (for example, 1C), which are not physically connected to the medical calendar and the patients' EHR . The cashier has to manually retype the services from the paper doctor's appointment to the cashier. This regularly leads to forgotten positions in the receipt, typos in the amounts, and lost profits. Lack of a digital footprint and irresponsibility: In outdated POS systems, it is impossible to accurately track which of the registry operators accepted the payment or made an unauthorized discount, since accounts in the program are often shared across the entire branch . Network failures and duplicates (Race Conditions): If the Internet connection is unstable (which is often the case in clinics located on the ground floors), cashiers may press the "Pay" button several times. In older systems, this leads to the creation of duplicate accounts and distortion of daily revenue. Loss of bitcoins due to the database architecture: Programmers using incorrect data types (like float or double) to store money in old databases often leads to "magical" rounding errors when balancing over a long period
The development of a reliable financial core (Core & Cash) will solve the fundamental problems of medical administration and become a solid springboard for the implementation of complex banking integrations (Kaspi) and analytics in the next stages.: Reduction of accounting errors to 0%: Thanks to the automatic pull-up of services to the POS terminal from the directory and Calendar module, the human factor in billing will be completely eliminated . Absolute transaction security: The implementation of the idempotent query architecture will provide a 100% guarantee that double payment of one bill is physically impossible even in case of network failures . Crystal transparency and responsibility: Total Audit Log and tightly linking each transaction to an individual employee's JWT token and a specific active shift (shift_id) will eliminate opportunities for financial fraud by staff. Ultra-fast operation and queue-free service: The optimized architecture of the microservice will allow loading the cashier's POS screen in less than 1.5 seconds and making cash payments at speeds of up to 600 milliseconds (P95 target response), radically speeding up patient care in the clinic lobby.
Amina Agzamova
Purpose and description of task (project)
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.
Whatsapp
