A multi-source patient diagnosis and treatment data backend intelligent management method

Abstract

This application belongs to the field of medical data management technology and discloses an intelligent backend management method for multi-source patient diagnosis and treatment data. Through a unified interface architecture and data management mechanism, it achieves cross-module fusion, authorized access, and intelligent analysis of patient-related data, solving the problems of data fragmentation, low security, and insufficient analysis in existing systems. This application, through modular backend design and a multi-dimensional data indexing strategy, realizes unified processing and collaborative control of multi-source information such as user management, patient management, scale management, video management, treatment management, report configuration, log tracking, and data statistics.

Description

Technical Field

[0001] This application relates to the field of medical data management technology, specifically to an intelligent backend management method for multi-source patient diagnosis and treatment data, which is particularly suitable for a comprehensive medical management system that integrates patient basic information, scale data, video data, treatment data, report data and equipment authorization information. Background Technology

[0002] With the continuous advancement of medical informatization, especially the rapid development in areas such as digital healthcare, telemedicine, and intelligent rehabilitation, medical institutions and treatment facilities are constantly generating large amounts of heterogeneous data. This data includes, but is not limited to, patient basic information, medical records, scale assessment data, video therapy data, equipment stimulation data, treatment process monitoring data, and final treatment reports. However, the wide range of data sources, complex structures, and frequent updates have led to the following problems: 1. Severe data silos: Patients' medical data are usually scattered across multiple systems and platforms, with different data sources using different formats and storage structures, making it difficult for backend systems to achieve unified data management, querying, and analysis.

[0003] 2. Lack of a unified access and control mechanism: In existing medical management systems, modules such as patient information, treatment tasks, scale data, and video data are usually relatively independent with incompatible interfaces, making it difficult to achieve data sharing and collaborative work between different systems. These issues also make the integration of third-party systems extremely complex.

[0004] 3. Poor data security and traceability: The lack of a unified identity authentication and access control mechanism between different modules makes it difficult to effectively guarantee the security of data access and operations. Furthermore, the absence of a log tracking system makes it difficult to trace the operation and modification of sensitive data, posing a high security risk.

[0005] 4. Insufficient intelligent analysis and visualization capabilities: Existing systems mostly remain at the level of data storage and display, lacking intelligent analysis and decision support for multi-source diagnosis and treatment data, making it difficult to achieve comprehensive optimization of the patient's diagnosis and treatment process.

[0006] To address the aforementioned issues, there is an urgent need for an intelligent backend management method for multi-source patient diagnosis and treatment data that can achieve comprehensive intelligent management from patient information collection to treatment task management, report generation, and data analysis, while ensuring data security, traceability, and efficient system collaboration. Summary of the Invention

[0007] The purpose of this application is to address the problems of existing technologies and provide a method for intelligent backend management of multi-source patient diagnosis and treatment data.

[0008] To address the technical problem, the technical solution of this application is: a method for intelligent backend management of multi-source patient diagnosis and treatment data, comprising the following steps: Step 1: Login and Token Authentication Processing; After submitting the username and password through the login interface and performing basic format validation, the data is sent to the backend authentication module. The backend authentication module calls `crud.user.authenticate` to verify the password, then uses `security.create_access_token` to generate a JWT token, which is returned in the response body. Simultaneously, the login information is recorded in the logging module, forming the basis for security auditing. Meanwhile, the frontend uses the Axios request interceptor to automatically append `Authorization: Bearer` to the header of all subsequent HTTP requests. <token>This enables continuous authentication of the session; Step 2: Unified API access, security verification and token management; all API requests are processed uniformly through the Axios request interceptor and backend API routing, and each backend business route uses Depends for permission verification; communication is encrypted with TLS throughout and uses the JWT seamless refresh mechanism. Step 3: Dynamic permission loading and front-end data management; Based on role permissions, the authorization module is dynamically loaded. At the same time, the front-end uses encapsulated composite functions to manage table data in a unified manner and provides a unified dictionary management interface. Step 4: Patient core information and full lifecycle management; responsible for the full lifecycle management of patient master data, adding / editing patients is implemented through the recordDetail.vue pop-up, and providing interfaces for viewing patient details and quick search by treatment number; Step 5: Multi-source diagnostic and treatment data fusion and access; including scale data management and access, image data management and access, and treatment plan management and access; Step 6: Treatment task execution and hardware interaction; create treatment tasks through the interface, trigger treatment tasks through the interface, and start an independent thread in the backend to control the hardware device to execute treatment; at the same time, the interface obtains the channel status of all activated devices in real time for visualization on the front-end interface; Step 7: License authorization and usage control; provide an interface to provide real-time statistics on the total number of licenses, remaining usage times, and usage times for the entire system; Step 8: Intelligent report generation and template configuration; manage the various configurations required for the report template through the interface. After treatment is completed, the interface automatically aggregates patient data to form the structured data required for the report; Step 9: Role and Fine-grained Permission Management; Implement CRUD operations for roles through the interface, and the interface also returns the complete menu-button tree structure of the system. The many-to-many relationship between users and roles is maintained through the CRUD.User_Role service to achieve dynamic allocation of user permissions; Step 10: Operation Log Tracking and Security Auditing; Automatically record logs during critical business operations using crud.log.create, supporting multi-dimensional conditional retrieval and pagination, and the interface supports viewing the original JSON snapshot details of a single log entry; Step 11: Data statistical analysis and visualization; the interface provides real-time statistics and returns key indicators, and the interface provides monthly statistics on the number of patients. Step 12: File Upload and Resource Management; The interface supports uploading various file types, and uploaded file records include name, path, type, and status information. Step 13: User account management; including adding, deleting, modifying, and querying user information, maintaining personal information, and integrating permissions; Step 14: System operation, maintenance and monitoring; including health status monitoring, scheduled tasks and anomaly isolation and recovery.

[0009] Preferably, step 1 specifically comprises: Step 1.1: Submit your account and password through the front-end login interface. After the front-end performs basic format verification, it sends the credentials to the back-end authentication module's interface through a TLS / HTTPS encrypted channel. Step 1.2: The backend authentication module calls crud.user.authenticate to verify the password. After successful verification, it uses security.create_access_token to generate a JWT token. The JWT token contains the user ID, role, device fingerprint and validity period information. Step 1.3: After successful verification, the JWT token is returned in the response body, and the login information is recorded in the log module to form the basis for security auditing; Step 1.4: The frontend uses the Axios request interceptor to automatically append Authorization: Bearer header to all subsequent HTTP requests. <token>This enables continuous authentication of the session.

[0010] Preferably, step 2 specifically comprises: Step 2.1: All API requests are processed uniformly by the Axios request interceptor and the backend API route. Each business route in the backend uses Depends dependency injection for permission verification to ensure interface-level security. Step 2.2: The entire communication process uses TLS encryption. If a request fails, the front end notifies the user through the Quasar Notify component. Step 2.3: Use the JWT seamless refresh mechanism. When the response interceptor detects that the token is about to expire, it automatically calls the refresh interface to update the token and resends the original request to ensure user experience.

[0011] Preferably, step 3 specifically comprises: Step 3.1: After the user logs in, the authorization module is dynamically loaded according to their role permissions. The front end obtains the list of menus and buttons that the user can access by calling the / get-user-menu interface, so as to achieve fine-grained control over the interface rendering. Step 3.2: The front end uses the encapsulated useTableData composite function to manage table data in a unified manner. This function integrates the call to the backend pagination query interface, condition filtering, sorting and loading status control to ensure that the data interaction logic of each module is consistent and efficient. Step 3.3: Provide a unified dictionary management interface: / get-dict-all retrieves the system dictionary configuration; / get-user-dict retrieves the mapping relationship between user IDs and names for use by the front-end dropdown selection component.

[0012] Preferably, step 4 specifically includes: Step 4.1: Supports CRUD operations, conditional filtering, soft deletion, and archiving. The core interface is / api / v1 / patient / patients. Step 4.2: Adding / editing patients is achieved through the recordDetail.vue pop-up. Before the form is submitted, the required fields and format are validated. When submitted, the POST or PUT interface is called, and the backend crud.patient.create / update performs the operation, ensuring the uniqueness of the treatment number. Step 4.3: After the deletion operation is confirmed twice, the DELETE interface is called. The backend crud.patient.delete performs soft deletion and cascades the NII file record and treatment record associated with the soft deletion, while recording the operation log. Step 4.4: Provide an interface for viewing patient details and a quick search interface by treatment number.

[0013] Preferably, step 5 specifically comprises: Step 5.1: Scale data management; Scale library management: Scales can be added, edited, deleted, and list-queried via the / api / v1 / scale / scales interface, and the association management of scale items and answers is supported; Patient scale assessment: The assessment results of each patient are recorded through the / api / v1 / patient / scale_tests interface, which supports multi-condition query. The details interface can obtain the specific answers and score analysis of the assessment. Step 5.2: Image data management; Associate NII model files for patients through the / api / v1 / patient / nii / save interface, using a "delete first, add later" strategy to ensure that patients are only associated with the latest valid model files at present; Step 5.3: Treatment Plan (Strategy) Management: Treatment plan management: CRUD operations on treatment strategies are implemented through the / api / v1 / ploy / ploys interface. Administrators create validated treatment plans for clinical selection. For details on the solution, please refer to the ` / api / v1 / ploy / {ploy_id}` interface to view the complete parameter configuration of the strategy.

[0014] Preferably, step 6 specifically includes: Step 6.1: Task creation and patient binding; create treatment tasks through the / api / v1 / task / patient interface, automatically determine whether the patient exists, bind the patient with the selected treatment strategy and indication, and generate a record of tasks to be executed; Step 6.2: Task execution control; Task startup: The treatment task is triggered by the / api / v1 / task / start interface, and the backend starts an independent thread through thread.threadTiTreat.start_ti_treat to control the hardware device to perform the treatment; Task stopped: The / api / v1 / task / stop interface securely terminates a running treatment task; Real-time parameter adjustment: The / api / v1 / task / tuning interface supports dynamic adjustment of key parameters during treatment; Step 6.3: Hardware status monitoring; The / api / v1 / upload / channels interface obtains the channel status of all activated devices in real time for visualization on the front-end interface; Step 6.4: Task List and Classification; The / api / v1 / task / tasks interface retrieves a list of treatment tasks to be executed based on department classification.

[0015] Preferably, step 7 specifically comprises: Step 7.1: Authorization verification; Before creating critical business nodes, the system forcibly calls crud.recharge.get_multi_recharges to count the global remaining counts and performs license authorization verification; Step 7.2: Authorization Statistics; Provide the / api / v1 / license / statis interface to provide real-time statistics on the total number of licenses, remaining usage times, and usage times for the entire system, and display the data on the management dashboard; Step 7.3: Authorization record management; New authorization feature: The / api / v1 / license / interface now supports license authorization codes. The backend parses the authorization codes using sys_utils.identify_license and stores them in the database. Record Query: The / api / v1 / license / licenses interface queries all authorization records and displays the creator's name.

[0016] Preferably, step 8 specifically includes: Step 8.1: Report Configuration Management; Manage the various configurations required for report templates through the / api / v1 / report / config interface; Step 8.2: Report data generation; After treatment is completed, the / api / v1 / task / report interface automatically aggregates the patient's basic information, treatment plan parameters, and treatment duration data to form the structured data required for the report; Step 8.3: Report Printing; The / api / v1 / task / report / print interface generates the final report, which supports print output; Step 9 specifically involves: Step 9.1: Role Management; Implement the creation, deletion, modification, and querying of roles through the / api / v1 / role / roles interface. When creating a role, it is necessary to associate it with the menu permission list. Step 9.2: Permission tree management; the / api / v1 / role / menu / tree interface returns the complete menu-button tree structure of the system, which is used for rendering the front-end permission configuration interface; Step 9.3: User-Role Association; In the user management module, the many-to-many relationship between users and roles is maintained through the crud.user_role service to achieve dynamic allocation of user permissions; Step 10 specifically involves: Step 10.1: Full operation logging; Automatically log critical business operations using crud.log.create, covering module, operator, action, result, IP address, and timestamp; Step 10.2: Multi-dimensional log query; Provides the / api / v1 / log / logs interface, supporting combined retrieval and pagination by username, operation type, time range, and operation result, facilitating security auditing and issue backtracking; Step 10.3: View log details; the / api / v1 / log / {log_id} interface supports viewing the original JSON snapshot details of a single log entry; Preferably, step 11 specifically includes: Step 11.1: Core Data Overview; The / api / v1 / static / quantity interface provides real-time statistics and returns core metrics, which include: total number of patients, total number of treatments, total number of scales, and total number of treatment plans. Step 11.2: Trend Analysis; The / api / v1 / static / enquiry interface calculates the number of patients per month and generates trend data for front-end chart display; Step 11.3: Multi-dimensional statistics; the system design supports data distribution analysis by disease symptoms, patient age, and gender. Step 12 specifically involves: Step 12.1: General file upload; The / api / v1 / upload / file / upload interface supports uploading images, videos, and document files, automatically identifies file types, saves them to the specified path, and records metadata in the database; Step 12.2: File Management; Uploaded file records include name, path, type, and status information for reference by other modules; Step 13 specifically involves: Step 13.1: User creation, deletion, modification, and query; Implement complete user lifecycle management through the / api / v1 / user / users interface, and support searching for users by conditions; Step 13.2: Personal Information Maintenance; Regular users can view and modify their personal information through the / api / v1 / user / me and / api / v1 / user / me interfaces; Step 13.3: Permission Integration; When creating or updating a user, the user's role association is updated synchronously through the crud.user_role service to ensure that permissions take effect immediately; Step 14 specifically involves: Step 14.1: Health status monitoring; indirectly monitor the system health by checking the response status of each service interface and the database connection status; Step 14.2: Scheduled Tasks; The design supports data backup, log archiving, cache refresh, and license expiration monitoring via background scheduled tasks; Step 14.3: Anomaly Isolation and Recovery; Critical services are designed with anomaly handling mechanisms to prevent local failures from causing overall system unavailability.

[0017] Compared with the prior art, the advantages of this application are: (1) This application integrates multi-source data: Through a unified data model and interface architecture, it can integrate and manage patient data (such as scales, videos, treatments, reports, etc.) from different data sources, effectively eliminating data silos and realizing unified storage, querying and analysis of multi-source data; (2) This application adopts a unified calling architecture: all functional modules are accessed through a unified backend interface, which supports cross-system collaborative work and can easily achieve integration with third-party systems, thereby improving the openness and compatibility of the system; (3) This application has data security and traceability: the token-based authentication and access control mechanism, combined with the log tracking system, ensures that every data operation can be traced, which greatly improves data security and reduces the risk of sensitive data leakage; (4) This application adopts automated and intelligent management: the system can automatically perform tasks (such as treatment task initiation, report generation, data cleaning, etc.), reduce manual intervention, and provide support for medical decision-making through intelligent analysis, thereby further improving work efficiency and decision-making accuracy; (5) This application has scalability and maintainability: it adopts a modular architecture design, supports flexible expansion and functional upgrade of the system, facilitates the integration of new diagnostic and treatment modules or external data interfaces in the future, and has low system maintenance costs and convenient upgrades; (6) The intelligent management method for multi-source patient diagnosis and treatment data provided in this application can effectively solve the problems of fragmented multi-source data, poor security and insufficient analysis capabilities in existing medical data management, and is of great significance for improving the management efficiency, security and intelligent analysis capabilities of medical data. Attached Figure Description

[0018] Figure 1 This is a flowchart of a backend intelligent management method for multi-source patient diagnosis and treatment data according to this application; Figure 2 and Figure 3 All of these are interfaces of the treatment management module in this application; Figure 4 and Figure 5 All of these are user management module interfaces for this application. Detailed Implementation

[0019] The present application is described in detail below with reference to the accompanying drawings and specific embodiments, but the present application is not limited to these embodiments. The present application covers any alternatives, modifications, equivalent methods, and solutions made within the spirit and scope of the present application. To provide the public with a thorough understanding of the present application, specific details are described in detail in the following embodiments, but those skilled in the art will fully understand the present application even without these detailed descriptions.

[0020] This application's system adopts a front-end and back-end separation architecture. The back-end is built on the FastAPI framework to provide RESTful API services, while the front-end uses Vue3 and Quasar frameworks to implement dynamic interfaces. Through component-based encapsulation, a unified API security policy, and a multi-layered data management mechanism, the system achieves centralized and intelligent management of patient information, multi-source diagnostic and treatment data, license authorization, treatment plans, operation logs, and role permissions. This application includes the following core steps: Step 1: User login and token authentication processing; 1.1 Users submit their account and password through the front-end login interface. After the front-end performs basic format verification, it sends the credentials to the back-end authentication interface ( / login / access-token) through a TLS / HTTPS encrypted channel.

[0021] 1.2 The backend authentication module calls `crud.user.authenticate` to verify the password (using salted hash comparison). After successful verification, a JWT token is generated using `security.create_access_token`. The token payload contains information such as user ID, role, device fingerprint, and validity period.

[0022] 1.3 The system has a login protection mechanism. After successful authentication, JWT is returned in the response body, and the IP address, device information, and other information of this login are recorded in the log module (crud.log) to form the basis for security auditing.

[0023] 1.4 The frontend uses the Axios request interceptor to automatically append Authorization: Bearer header to all subsequent HTTP requests. <token>This enables continuous authentication of the session.

[0024] Step 2: Unify API access, security verification, and token management; 2.1 All API requests are processed uniformly by the front-end interceptor and the back-end API router (APIRouter). Each back-end business route (such as / api / v1 / patient / , / api / v1 / license / ) uses dependency injection (Depends(deps.get_current_active_user / superuser)) for permission verification to ensure interface-level security.

[0025] 2.2 All communication uses TLS encryption. In case of request errors, the frontend notifies the user via the Quasar Notify component.

[0026] 2.3 The system implements a seamless JWT refresh mechanism. When the response interceptor detects that the token is about to expire, it can automatically call the refresh interface to update the token and resend the original request, ensuring a good user experience.

[0027] Step 3: Dynamic permission loading and front-end data management layer; 3.1 After a user logs in, the system dynamically loads the authorization module based on their role permissions. The front end obtains the list of menus (records) and buttons that the user can access by calling the / get-user-menu interface, thus enabling fine-grained control over the interface rendering.

[0028] 3.2 The front-end uses the encapsulated useTableData composite function to uniformly manage table data. This function integrates calls to the back-end pagination query interface, condition filtering, sorting, and loading status control to ensure consistent and efficient data interaction logic among modules.

[0029] 3.3 The system provides a unified dictionary management interface: / get-dict-all retrieves the system dictionary configuration; / get-user-dict retrieves the mapping relationship between user IDs and names, which can be used by front-end dropdown selection and other components.

[0030] Step 4: Patient core information and full-cycle management; 4.1 This module is responsible for the full lifecycle management of patient master data, supporting CRUD operations, conditional filtering, and soft deletion and archiving. The core interface is / api / v1 / patient / patients.

[0031] 4.2 Adding / editing patients is achieved through the recordDetail.vue pop-up. Required fields and format validation are performed before form submission. Upon submission, a POST or PUT interface is called, and the backend `crud.patient.create / update` performs the operation, ensuring the uniqueness of the patient's registration number (record_number).

[0032] 4.3 After secondary confirmation, the DELETE interface is called for deletion. The backend crud.patient.delete performs a soft deletion and cascades the associated NII file records and treatment records, while also logging the operation.

[0033] 4.4 Provide an interface for viewing patient details ( / api / v1 / patient / {patient_id}) and a quick search interface by treatment number ( / api / v1 / patient / patients / {record_number}).

[0034] Step 5: Integration and access of multi-source diagnostic and treatment data; 5.1 Scale Data Management: Scale library management: Scales can be added, edited, deleted, and their lists searched via the ` / api / v1 / scale / scales` interface. It supports the association management of scale items and answers (` / api / v1 / scale / {scale_id}`).

[0035] Patient scale assessment: The assessment results for each patient are recorded through the / api / v1 / patient / scale_tests interface, supporting multi-condition queries. The details interface provides the specific answers and score analysis for each assessment.

[0036] 5.2 Image Data Management: Patients are associated with NII model files via the / api / v1 / patient / nii / save interface. The system employs a "delete first, add later" strategy to ensure that patients are currently associated only with the latest valid model file.

[0037] 5.3 Treatment plan (strategy) management: Treatment plan management: CRUD operations for treatment strategies are implemented through the / api / v1 / ploy / ploys interface. Administrators can create validated treatment plans for clinical selection.

[0038] For details on the solution, please refer to the ` / api / v1 / ploy / {ploy_id}` interface to view the complete parameter configuration of the strategy.

[0039] Step 6: Execution of diagnostic and treatment tasks and interaction with hardware; 6.1 Task Creation and Patient Binding: Treatment tasks are created via the / api / v1 / task / patient interface. The system automatically determines if the patient exists (or creates a new one if the patient does not exist), and binds the patient with the selected treatment strategy and indication, generating a record of tasks to be executed.

[0040] 6.2 Task Execution Control: Task Startup: The treatment task is triggered by the / api / v1 / task / start interface. The backend starts an independent thread through thread.threadTiTreat.start_ti_treat to control the hardware device to perform the treatment.

[0041] Task stopped: The / api / v1 / task / stop interface securely terminates a running treatment task.

[0042] Real-time parameter adjustment: The / api / v1 / task / tuning interface supports dynamic adjustment of key parameters such as current during treatment.

[0043] 6.3 Hardware Status Monitoring: The / api / v1 / upload / channels interface obtains the channel status of all active devices in real time, which is then displayed visually on the front-end interface.

[0044] 6.4 Task List and Classification: The / api / v1 / task / tasks interface retrieves a list of treatment tasks to be executed based on the department (outpatient / inpatient).

[0045] Step 7: License Authorization and Usage Control; 7.1 Authorization Verification: Before creating critical business nodes such as treatment tasks, the system forcibly calls crud.recharge.get_multi_recharges to count the global remaining counts (remain) and performs license authorization verification.

[0046] 7.2 Authorization Statistics: Provides the / api / v1 / license / statis interface to provide real-time statistics on the total number of licenses, remaining usage times, and usage times for the entire system. The data is displayed on the management dashboard.

[0047] 7.3 Authorization Record Management: New authorization: Add a License authorization code to the / api / v1 / license / interface (requires super administrator privileges). The backend will parse the authorization code and store it in the database using sys_utils.identify_license.

[0048] Record Query: The / api / v1 / license / licenses interface queries all authorization records and displays the creator's name.

[0049] Step 8: Intelligent report generation and template configuration; 8.1 Report Configuration Management: Manage various configurations required for report templates through the / api / v1 / report / config interface, such as hospital name, department list, indication list ( / api / v1 / task / symptoms), etc.

[0050] 8.2 Report Data Generation: After treatment is completed, the / api / v1 / task / report interface automatically aggregates patient basic information, treatment plan parameters, treatment duration and other data to form the structured data required for the report.

[0051] 8.3 Report Printing: The / api / v1 / task / report / print interface generates the final report and supports print output.

[0052] Step 9: Role and Fine-grained Permission Management; 9.1 Role Management: Roles can be added, deleted, modified, and queried through the ` / api / v1 / role / roles` interface. A menu permission list (menu_ids) must be associated when creating a role.

[0053] 9.2 Permission Tree Management: The / api / v1 / role / menu / tree interface returns the complete menu-button tree structure of the system, which is used for rendering the front-end permission configuration interface.

[0054] 9.3 User-Role Association: In the user management module, the many-to-many relationship between users and roles is maintained through the crud.user_role service, enabling dynamic allocation of user permissions.

[0055] Step 10: Operation log tracking and security audit; 10.1 Full Operation Log: The system automatically logs critical business operations (CRUD operations, login, task start / stop, etc.) using CRUD.Log.Create, covering the module, operator, action, result, IP address, and timestamp.

[0056] 10.2 Multi-dimensional log query: Provides the / api / v1 / log / logs interface, which supports multi-dimensional conditional search and pagination by username, operation type, time range, operation result, etc., to facilitate security auditing and problem backtracking.

[0057] 10.3 Viewing Log Details: The / api / v1 / log / {log_id} interface supports viewing the original JSON snapshot details of a single log entry.

[0058] Step 11: Data statistical analysis and visualization; 11.1 Core Data Overview: The / api / v1 / static / quantity interface provides real-time statistics and returns the system's core metrics: total number of patients, total number of treatments, total number of scales, and total number of treatment plans.

[0059] 11.2 Trend Analysis: The / api / v1 / static / enquiry interface calculates the number of patients per month and generates trend data for front-end chart display.

[0060] 11.3 Multi-dimensional statistics: The system design supports data distribution analysis by disease symptoms, patient age, gender, and other dimensions (interface to be improved).

[0061] Step 12: File Upload and Resource Management; 12.1 General File Upload: The / api / v1 / upload / file / upload interface supports uploading various file types, including images, videos, and documents. The system automatically identifies the file type, saves it to the specified path, and records metadata in the database.

[0062] 12.2 File Management: Uploaded file records contain information such as name, path, type, and status, which can be referenced by other modules (such as patient NII file association).

[0063] Step 13: User Account Management; 13.1 User CRUD Operations: The complete lifecycle management of system users is achieved through the / api / v1 / user / users interface (administrator privileges required). User searches based on specific criteria are supported.

[0064] 13.2 Personal Information Maintenance: Regular users can view and modify their personal information (such as name, phone number, password) through the / api / v1 / user / me and / api / v1 / user / me(PUT) interfaces.

[0065] 13.3 Permission Integration: When creating or updating a user, the user's role association is updated synchronously through the crud.user_role service to ensure that permissions take effect immediately.

[0066] Step 14: System operation, maintenance, and monitoring; 14.1 Health Status Monitoring: The health of the system is indirectly monitored by the response status of each service interface and the database connection status.

[0067] 14.2 Scheduled Tasks: The system design supports the execution of maintenance operations such as data backup, log archiving, cache refresh, and license validity monitoring through background scheduled tasks (the specific implementation is not shown in the provided code).

[0068] 14.3 Anomaly Isolation and Recovery: Critical services (such as hardware communication threads) are designed with anomaly handling mechanisms to prevent local failures from causing the entire system to become unavailable.

[0069] Example 1 like Figure 2 and Figure 3 As shown, Figure 2 Corresponding to step 4, core patient information and full-cycle management. Figure 3 This corresponds to the diagnostic and treatment task execution and hardware interaction in step 6; it is used to realize collaborative control and data interaction between the front-end system, the back-end management system, and the lower-level treatment device. Through unified back-end control logic, it manages the entire process of patient treatment task creation, execution, dynamic adjustment, termination, and treatment result generation. Specifically, when stimulation therapy is required for a patient, the back-end management system receives patient information and treatment task parameters submitted by the front-end system, and performs matching and verification in the patient database based on the patient's diagnosis number. If the patient information already exists, the system directly generates a treatment task record based on the patient identifier and stores it in the treatment task database. If the patient information does not exist, the system first adds the patient's basic information and then automatically creates the associated treatment task record, thereby achieving linkage between patient management and treatment management. After the treatment task is created, when the back-end management system receives the treatment start command, it sends the corresponding stimulation parameters and control commands to the lower-level device through the communication interface, causing the lower-level device to start executing the stimulation therapy. Simultaneously, it updates the treatment task status to the execution status and records the task start time and related operation logs. During treatment, if any abnormal situation occurs or medical personnel need to interrupt treatment, the backend management system, upon receiving a stop request, sends a stop stimulation command to the lower-level machine and synchronously updates the status information of the corresponding treatment task in the database, ensuring the safety and controllability of the treatment process. If adjustments to stimulation parameters are needed during treatment, the backend management system can receive current adjustment parameters from the frontend. After completing safety verification, it sends the new stimulation current parameters to the lower-level machine in real time, enabling dynamic fine-tuning of the stimulation current during treatment. Related parameter changes are recorded in the treatment log to ensure the integrity and traceability of treatment data. After the treatment task is completed, the backend management system automatically integrates patient basic information, treatment parameters, treatment duration, and equipment feedback data based on the treatment task identifier, and generates a corresponding treatment report according to a preset report template. The generated treatment report is stored in the report database for subsequent querying, printing, or statistical analysis. Furthermore, during the treatment task configuration phase, the system provides an indication information retrieval function, which returns the types of indications currently supported by the system and their associated parameters to the frontend, assisting medical personnel in configuring standardized treatment plans. Through the above implementation methods, this application realizes closed-loop management of treatment tasks from creation, execution, dynamic adjustment to result generation, improves the automation level, security and data traceability of the stimulation treatment process, and is suitable for intelligent medical management systems with multiple devices, multiple patients and multiple treatment scenarios.

[0070] Example 2 like Figure 4 and Figure 5 As shown, Figure 4 Corresponding to step 2, unified API access, security verification, and token management. Figure 5 Corresponding to step 13, the user account management method for multi-source patient diagnosis and treatment data backend intelligent management includes a user management module interface. This module is used to realize unified management of system users, role and permission binding, and autonomous management of logged-in user information. This user management module provides external consumers with full lifecycle user management capabilities through standardized interfaces and works in conjunction with the system's identity authentication and permission control mechanisms. Specifically, the backend management system provides a user addition function. When a request to add a user is received, the system allows the corresponding role identifier to be directly passed into the interface parameters while creating the user's basic information, thereby completing the binding of roles and permissions during the user creation stage, avoiding subsequent repetitive configuration, and improving user management efficiency. When a user already exists, the system supports obtaining the basic information of a specified user through a user query interface, and after modifying the required fields on the front end, uniformly updating the user data through a user update interface to ensure the consistency of user information. Simultaneously, the user management module supports batch query functions for user lists. The backend management system can return user data for the corresponding page number according to pagination parameters and supports fuzzy matching combinations of queries based on multiple conditions such as username, account, and role to meet the retrieval needs of administrators in large-scale user scenarios. For precise queries of individual user information, the system allows retrieval of detailed user information, including basic data and associated role and permission information, through the user's unique identifier. Regarding user deletion management, the backend management system supports both individual deletion based on a single user identifier and batch deletion by inputting multiple user identifiers, thereby improving the efficiency of user cleanup and permission revocation. To ensure system security and availability, user deletion can be performed logically, retaining necessary historical operation records. Furthermore, to enhance user self-service capabilities, the user management module also provides login user information reading and updating functions. After completing identity authentication and obtaining a valid access token, logged-in users can directly obtain their basic information and permission data by calling the corresponding interface without inputting a user identifier; simultaneously, logged-in users can also modify their personal information through the update interface, and the system updates the user data and writes it to the audit log after completing permission verification. Through the above implementation methods, the user management module of this application realizes unified interface control for user creation, maintenance, query, deletion, and self-management. Combined with the role and permission mechanism, it effectively ensures the system's security, scalability, and ease of use, and is suitable for multi-role, multi-level medical management system application scenarios.

[0071] The preferred embodiments of this application have been described in detail above. However, this application is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of this application.

[0072] Many other changes and modifications can be made without departing from the concept and scope of this application. It should be understood that this application is not limited to the specific embodiments, and the scope of this application is defined by the appended claims.< / token> < / token> < / token>

Claims

1. A method for intelligent backend management of multi-source patient diagnosis and treatment data, characterized in that, Includes the following steps: Step 1: Login and Token authentication processing; After submitting their username and password on the login page and undergoing basic format validation, the data is sent to the backend authentication module. The backend authentication module calls `crud.user.authenticate` to verify the password, then uses `security.create_access_token` to generate a JWT token, which is returned in the response body. Simultaneously, the login information is logged to the log module, forming the basis for security auditing. Meanwhile, the frontend uses an Axios request interceptor to automatically append `Authorization: Bearer` to the header of all subsequent HTTP requests. <token> This enables continuous authentication of the session;< / token> Step 2: Unified API access, security verification and token management; all API requests are processed uniformly through the Axios request interceptor and backend API routing, and each backend business route uses Depends for permission verification; communication is encrypted with TLS throughout and uses the JWT seamless refresh mechanism. Step 3: Dynamic permission loading and front-end data management; Based on role permissions, the authorization module is dynamically loaded. At the same time, the front-end uses encapsulated composite functions to manage table data in a unified manner and provides a unified dictionary management interface. Step 4: Patient core information and full lifecycle management; responsible for the full lifecycle management of patient master data, adding / editing patients is implemented through the recordDetail.vue pop-up, and providing interfaces for viewing patient details and quick search by treatment number; Step 5: Multi-source diagnostic and treatment data fusion and access; including scale data management and access, image data management and access, and treatment plan management and access; Step 6: Treatment task execution and hardware interaction; create treatment tasks through the interface, trigger treatment tasks through the interface, and start an independent thread in the backend to control the hardware device to execute treatment; at the same time, the interface obtains the channel status of all activated devices in real time for visualization on the front-end interface; Step 7: License authorization and usage control; provide an interface to provide real-time statistics on the total number of licenses, remaining usage times, and usage times for the entire system; Step 8: Intelligent report generation and template configuration; manage the various configurations required for the report template through the interface. After treatment is completed, the interface automatically aggregates patient data to form the structured data required for the report; Step 9: Role and Fine-grained Permission Management; Implement CRUD operations for roles through the interface, and the interface also returns the complete menu-button tree structure of the system. The many-to-many relationship between users and roles is maintained through the CRUD.User_Role service to achieve dynamic allocation of user permissions; Step 10: Operation Log Tracking and Security Auditing; Automatically record logs during critical business operations using crud.log.create, supporting multi-dimensional conditional retrieval and pagination, and the interface supports viewing the original JSON snapshot details of a single log entry; Step 11: Data statistical analysis and visualization; the interface provides real-time statistics and returns key indicators, and the interface provides monthly statistics on the number of patients. Step 12: File Upload and Resource Management; The interface supports uploading various file types, and uploaded file records include name, path, type, and status information. Step 13: User account management; including adding, deleting, modifying, and querying user information, maintaining personal information, and integrating permissions; Step 14: System operation, maintenance, and monitoring; This includes health status monitoring, scheduled tasks, and anomaly isolation and recovery.

2. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 1 specifically involves: Step 1.1: Submit your account and password through the front-end login interface. After the front-end performs basic format verification, it sends the credentials to the back-end authentication module's interface through a TLS / HTTPS encrypted channel. Step 1.2: The backend authentication module calls crud.user.authenticate to verify the password. After successful verification, it uses security.create_access_token to generate a JWT token. The JWT token contains the user ID, role, device fingerprint and validity period information. Step 1.3: After successful verification, the JWT token is returned in the response body, and the login information is recorded in the log module to form the basis for security auditing; Step 1.4: The frontend uses the Axios request interceptor to automatically append Authorization: Bearer header to all subsequent HTTP requests. <token> This enables continuous authentication of the session.< / token> 3. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 2 specifically involves: Step 2.1: All API requests are processed uniformly by the Axios request interceptor and the backend API route. Each business route in the backend uses Depends dependency injection for permission verification to ensure interface-level security. Step 2.2: The entire communication process uses TLS encryption. If a request fails, the front end notifies the user through the Quasar Notify component. Step 2.3: Use the JWT seamless refresh mechanism. When the response interceptor detects that the token is about to expire, it automatically calls the refresh interface to update the token and resends the original request to ensure user experience.

4. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 3 specifically involves: Step 3.1: After the user logs in, the authorization module is dynamically loaded according to their role permissions. The front end obtains the list of menus and buttons that the user can access by calling the / get-user-menu interface, so as to achieve fine-grained control over the interface rendering. Step 3.2: The front end uses the encapsulated useTableData composite function to manage table data in a unified manner. This function integrates the call to the backend pagination query interface, condition filtering, sorting and loading status control to ensure that the data interaction logic of each module is consistent and efficient. Step 3.3: Provide a unified dictionary management interface: / get-dict-all retrieves the system dictionary configuration; / get-user-dict retrieves the mapping relationship between user IDs and names for use by the front-end dropdown selection component.

5. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 4 specifically involves: Step 4.1: Supports CRUD operations, conditional filtering, soft deletion, and archiving. The core interface is / api / v1 / patient / patients. Step 4.2: Adding / editing patients is achieved through the recordDetail.vue pop-up. Before the form is submitted, the required fields and format are validated. When submitted, the POST or PUT interface is called, and the backend crud.patient.create / update performs the operation, ensuring the uniqueness of the treatment number. Step 4.3: After the deletion operation is confirmed twice, the DELETE interface is called. The backend crud.patient.delete performs soft deletion and cascades the NII file record and treatment record associated with the soft deletion, while recording the operation log. Step 4.4: Provide an interface for viewing patient details and a quick search interface by treatment number.

6. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 5 specifically involves: Step 5.1: Scale data management; Scale library management: Scales can be added, edited, deleted, and list-queried via the / api / v1 / scale / scales interface, and the association management of scale items and answers is supported; Patient scale assessment: The assessment results of each patient are recorded through the / api / v1 / patient / scale_tests interface, which supports multi-condition query. The details interface can obtain the specific answers and score analysis of the assessment. Step 5.2: Image data management; Associate NII model files for patients through the / api / v1 / patient / nii / save interface, using a "delete first, add later" strategy to ensure that patients are only associated with the latest valid model files at present; Step 5.3: Treatment Plan (Strategy) Management: Treatment plan management: CRUD operations on treatment strategies are implemented through the / api / v1 / ploy / ploys interface. Administrators create validated treatment plans for clinical selection. For details on the solution, please refer to the ` / api / v1 / ploy / {ploy_id}` interface to view the complete parameter configuration of the strategy.

7. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 6 specifically involves: Step 6.1: Task creation and patient binding; create treatment tasks through the / api / v1 / task / patient interface, automatically determine whether the patient exists, bind the patient with the selected treatment strategy and indication, and generate a record of tasks to be executed; Step 6.2: Task execution control; Task startup: The treatment task is triggered by the / api / v1 / task / start interface, and the backend starts an independent thread through thread.threadTiTreat.start_ti_treat to control the hardware device to perform the treatment; Task stopped: The / api / v1 / task / stop interface securely terminates a running treatment task; Real-time parameter adjustment: The / api / v1 / task / tuning interface supports dynamic adjustment of key parameters during treatment; Step 6.3: Hardware status monitoring; The / api / v1 / upload / channels interface retrieves the channel status of all activated devices in real time, which is then displayed visually on the front-end interface. Step 6.4: Task List and Classification; The / api / v1 / task / tasks interface retrieves a list of treatment tasks to be executed based on department classification.

8. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 7 specifically involves: Step 7.1: Authorization verification; Before creating critical business nodes, the system forcibly calls crud.recharge.get_multi_recharges to count the global remaining counts and performs license authorization verification; Step 7.2: Authorization Statistics; Provides the / api / v1 / license / statis interface to provide real-time statistics on the total number of licenses, remaining usage times, and usage times for the entire system, with the data displayed on the management dashboard; Step 7.3: Authorization record management; New authorization feature: The / api / v1 / license / interface now supports license authorization codes. The backend parses the authorization codes using sys_utils.identify_license and stores them in the database. Record Query: The / api / v1 / license / licenses interface queries all authorization records and displays the creator's name.

9. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 8 specifically involves: Step 8.1: Report Configuration Management; Manage the various configurations required for report templates through the / api / v1 / report / config interface; Step 8.2: Report data generation; After treatment is completed, the / api / v1 / task / report interface automatically aggregates the patient's basic information, treatment plan parameters, and treatment duration data to form the structured data required for the report; Step 8.3: Print the report; The ` / api / v1 / task / report / print` interface generates the final report and supports print output. Step 9 specifically involves: Step 9.1: Role Management; Implement the creation, deletion, modification, and querying of roles through the / api / v1 / role / roles interface. When creating a role, it is necessary to associate it with the menu permission list. Step 9.2: Permission tree management; The / api / v1 / role / menu / tree interface returns the complete menu-button tree structure of the system, which is used for rendering the front-end permission configuration interface. Step 9.3: User-Role Association; In the user management module, the many-to-many relationship between users and roles is maintained through the crud.user_role service, enabling dynamic allocation of user permissions; Step 10 specifically involves: Step 10.1: Full operation logging; Automatically log critical business operations using crud.log.create, covering module, operator, action, result, IP address, and timestamp; Step 10.2: Multi-dimensional log query; Provides the / api / v1 / log / logs interface, supporting combined retrieval and pagination by username, operation type, time range, and operation result, facilitating security auditing and issue backtracking; Step 10.3: View log details; The / api / v1 / log / {log_id} interface supports viewing the raw JSON snapshot details of a single log entry.

10. The intelligent backend management method for multi-source patient diagnosis and treatment data according to claim 1, characterized in that, Step 11 specifically involves: Step 11.1: Core Data Overview; The / api / v1 / static / quantity interface provides real-time statistics and returns core metrics, which include: total number of patients, total number of treatments, total number of scales, and total number of treatment plans. Step 11.2: Trend Analysis; / The api / v1 / static / enquiry interface calculates the number of patients per month and generates trend data for front-end chart display. Step 11.3: Multi-dimensional statistics; the system design supports data distribution analysis by disease symptoms, patient age, and gender. Step 12 specifically involves: Step 12.1: General file upload; The / api / v1 / upload / file / upload interface supports uploading images, videos, and document files, automatically identifies file types, saves them to the specified path, and records metadata in the database; Step 12.2: File Management; Uploaded file records include name, path, type, and status information for reference by other modules; Step 13 specifically involves: Step 13.1: User creation, deletion, modification, and query; Implement complete user lifecycle management through the / api / v1 / user / users interface, and support searching for users by conditions; Step 13.2: Personal Information Maintenance; Regular users can view and modify their personal information through the / api / v1 / user / me and / api / v1 / user / me interfaces; Step 13.3: Permission Integration; When creating or updating a user, the user's role association is updated synchronously through the crud.user_role service to ensure that permissions take effect immediately; Step 14 specifically involves: Step 14.1: Health status monitoring; indirectly monitor the system health by checking the response status of each service interface and the database connection status; Step 14.2: Scheduled Tasks; The design supports data backup, log archiving, cache refresh, and license expiration monitoring via background scheduled tasks; Step 14.3: Anomaly Isolation and Recovery; Critical services are designed with anomaly handling mechanisms to prevent local failures from causing overall system unavailability.

Images