Decision acceptance deadline

26.06.26 (inclusive)

Form of award

Оплата

Product status

Idea

Task type

ICT tasks

Сфера применения

Medicine

Область задачи

Other technological solutions

Type of product

Software/ IS

Problem description

Today, more than 40% of administrative and clinical processes in private medical centers in Kazakhstan and the CIS are performed manually, using paper media, Excel spreadsheets or disparate non-specialized systems. This creates enormous problems in the field of information security and personnel management: The threat of data leakage: In monolithic systems without a multidimensional architecture, there is a huge risk that patient data from one clinic (including IIN, contact numbers and sensitive diagnoses) may become available to employees of another clinic, which is a direct violation of the legislation of the Republic of Kazakhstan on personal data protection. data. Internal fraud and rights chaos: Clinics often lack strict separation of digital rights. Call center operators may accidentally or intentionally delete patient records, cashiers may make unauthorized discounts or refunds "past the checkout", and doctors may view the financial statements of the entire clinic. Lack of a digital footprint: When an incident occurs (for example, a patient complains that his record was canceled without warning, or a shortage is found at the checkout), management cannot find the culprit, since the old systems do not keep detailed logs of who exactly changed the status of the document, from which device and at what second. Scaling difficulties: Current local clinic solutions do not allow for the rapid opening of new branches or the launch of medical franchises due to the fact that databases cannot be seamlessly shared and synchronized.

Expected effect

The implementation of this fundamental block will provide DCH with the status of an Enterprise solution and bring the following results: Absolute security and data isolation: A multi-client (franchise) architecture with filtering at the Middleware level guarantees 100% protection of medical secrets and commercial information (clinic revenue) from cross-access. This will be the main argument when selling DCH to large medical networks. Zero tolerance to fraud: Strict role allocation (RBAC), in which the buttons for prohibited actions are visually blocked by the interface (disabled with tooltip), and the backend returns an HTTP 403 error, will completely eliminate human error and financial fraud on the part of the staff. Transparency of management: Continuous Audit Log will provide management with the opportunity to investigate any incident in a couple of clicks, increasing the personal responsibility of clinic staff (each cash shift and cancellation of an appointment will be "signed" with a digital footprint of a specific person). Ready for international scaling: The created core will allow the system to withstand an SLA of 99.5% and provide the technical base for future international information security certifications (ISO, HL7) and successful expansion into the markets of Central Asia (Uzbekistan, Kyrgyzstan) by 2028-2029.

Full name of responsible person

Agzamova Amina

Purpose and description of task (project)

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.

Note