Web real-time communication connection control and data processing method and system for hospital-wide rehabilitation integrated system

Abstract

The invention provides a Web real-time communication connection management and control and data processing method and system for a hospital-wide rehabilitation integrated system, and the method is executed by a client, is used for establishing real-time or quasi-real-time data communication with a server, and specifically comprises the following steps: a connection management and control step: when communication connection is established or initialized, the communication connection is established or initialized; a connection retry management and control strategy is forced to be executed so as to prohibit or strictly limit an automatic reconnection behavior after active disconnection or connection abnormity of the server side; a data processing step: carrying out fault-tolerant processing on the data message received from the server, the fault-tolerant processing comprising filtering and degradation analysis on an invalid or abnormal format message so as to ensure that the processing failure of a single message does not affect the stability of the overall communication; and a resource management step: monitoring and managing the life cycle event of the communication connection, and when the connection is closed or actively disconnected, executing a systematic resource release process, destroying a communication instance, removing all event monitors and resetting the internal state of the client.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method and system for managing and processing real-time web communication connections and data in an integrated rehabilitation system for the whole hospital. This method is compatible with a variety of web instant messaging technologies, including Server-Sent Events, WebSocket, and HTTP short polling. Background Technology

[0002] The hospital-wide integrated rehabilitation system is a medical information platform that integrates resources from multiple departments within a hospital, including rehabilitation, clinical, and medical technology departments, to achieve full-process management of patient rehabilitation assessment, treatment planning, treatment process monitoring, and rehabilitation data traceability. One of the core requirements of this system is to ensure the real-time transmission of rehabilitation data (such as real-time patient vital signs, rehabilitation equipment operating status, treatment progress data, and multi-departmental collaboration instructions) across terminals and nodes within the hospital network. Server-SentEvents (SSE) technology, with its characteristics of "one-way server push, lightweight, and based on the HTTP protocol," has become the mainstream technical solution for real-time data transmission in the hospital-wide integrated rehabilitation system.

[0003] In existing technologies, general-purpose SSE clients (such as the browser's native EventSource object and open-source SSE wrapper tools) have been widely used in various Web real-time communication scenarios. Their core implementation logic is as follows: after establishing an SSE connection, the client listens for messages pushed by the server. At the same time, the native EventSource has an automatic reconnection mechanism by default (retrying the connection at fixed intervals after disconnection) to ensure the continuity of the connection.

[0004] In the context of integrated rehabilitation across the entire hospital, existing SSE client technology has the following key defects and problems: 1. Uncontrollable reconnection mechanism and poor adaptability: Automatic reconnection is the default behavior of general SSE clients and is difficult to completely disable. However, in the integrated rehabilitation system of the whole hospital, rehabilitation data push must strictly follow the principle of "server-side active management"—when the server actively disconnects the SSE connection due to scenarios such as permission changes, patient transfer, or treatment completion, if the client triggers automatic reconnection, it will lead to invalid connections occupying hospital-level server resources, and may even cause rehabilitation data push errors (such as pushing invalid data to terminals that have completed treatment). Although some solutions in the existing technologies published by [publication number] support configuring the number of reconnections / intervals, they do not achieve closed-loop management of "forced disabling of reconnection + thorough cleaning of connection resources in case of errors," and cannot adapt to the connection management requirements of rehabilitation scenarios.

[0005] 2. Incomplete exception handling can easily lead to resource leaks: The hospital-wide integrated rehabilitation system needs to operate stably 24 / 7. However, when the existing SSE client encounters connection errors (such as network interruption or server-side abnormalities), it simply triggers an error event without systematically cleaning up resources such as EventSource instances, listener callbacks, and timers. Long-term operation can easily lead to problems such as connection handle residues and memory leaks on client terminals (such as industrial control computers in rehabilitation treatment rooms and nurse station terminals), which in turn can cause terminal lag, data reception delays, and affect real-time monitoring of the rehabilitation treatment process.

[0006] 3. Insufficient robustness in message processing and low fault tolerance in data parsing: Rehabilitation data push includes various formats such as structured JSON data (e.g., treatment parameters) and semi-structured text (e.g., physician instructions). When parsing messages, the existing SSE client is prone to parsing exceptions and interrupting the entire connection if it encounters JSON format errors or empty messages. It cannot meet the requirement that "the failure of parsing a single message does not affect the overall connection". In rehabilitation scenarios, the continuity of data transmission is directly related to treatment safety, and the message processing method with low fault tolerance poses medical risks.

[0007] 4. Low standardization of connection creation, prone to configuration errors: The hospital-wide integrated rehabilitation system involves deployment of multiple terminals and departments. The existing SSE client requires the business layer to manually configure multiple options such as reconnection, header information, and parameters. It is prone to connection abnormalities due to manual configuration errors (such as failure to disable reconnection or incorrect parameter splicing), which increases the system operation and maintenance costs. In addition, it lacks a mechanism of "standardized connection creation + automatic cleanup after failure", which cannot adapt to the requirements of large-scale deployment of hospital-level systems.

[0008] In summary, while existing general-purpose SSE client technologies can meet basic real-time communication needs, their shortcomings in connection management, resource cleanup, message processing, and deployment adaptation prevent them from being directly applied to a hospital-wide integrated rehabilitation system. There is an urgent need for an SSE client connection management solution optimized for rehabilitation scenarios to address the deficiencies of the existing technologies.

[0009] While the shortcomings of the existing technologies described above are primarily illustrated using SSE as an example, those skilled in the art will understand that in a hospital-wide integrated rehabilitation system, other communication protocols such as WebSocket and HTTP short polling may also be used to achieve data push. However, these alternative technologies, when applied to this specific medical scenario, also face common problems such as uncontrollable connection retries, incomplete resource cleanup, and insufficient robustness in message processing. Therefore, a unified client connection management and data processing framework that does not rely on a specific communication protocol is needed. Summary of the Invention

[0010] The purpose of this invention is to provide a method and system for real-time web communication connection management and data processing in a hospital-wide integrated rehabilitation system, which can solve existing problems.

[0011] The technical problems solved by this invention include at least the following: (a) Connection control issues: 1. Uncontrollable reconnection mechanism: Existing general-purpose SSE clients (such as native EventSource and open-source sse.js) come with automatic reconnection logic by default and cannot be completely disabled. In the context of integrated rehabilitation across the hospital, even if the server actively disconnects due to patient transfer, treatment completion, or permission changes, the client will still trigger reconnection, resulting in invalid connections occupying hospital-level server resources and even pushing incorrect rehabilitation data (such as pushing data to terminals that have completed treatment), thus violating the control rules for rehabilitation data transmission. 2. Problem of insufficient standardization in connection creation: The hospital-wide integrated rehabilitation system involves multiple terminals (industrial control computers in rehabilitation treatment rooms, computers at nurse stations, and mobile ward round terminals) and deployment in multiple departments. The existing SSE client requires the business layer to manually configure multiple parameters such as reconnection, request headers, and query parameters. It is prone to connection abnormalities due to manual configuration errors (such as failure to disable reconnection or incorrect parameter concatenation), which increases the system operation and maintenance costs and cannot adapt to the needs of hospital-scale deployment. (II) Resource Management Issues: 1. Resource leakage issues under abnormal scenarios: The hospital-wide integrated rehabilitation system needs to run stably 24 / 7. When the existing SSE client encounters a connection error (network interruption, server abnormality), it simply triggers an error event without systematically cleaning up resources such as EventSource instances, event listener callbacks, and timers. Long-term operation can easily lead to connection handle residues and memory leaks on the terminal, causing terminal lag, data reception delays, and affecting real-time monitoring of rehabilitation treatment.

[0012] 2. Issue of resources not being cleared after manual disconnection: The existing SSE client does not completely clear resources such as reconnection timers, listener callback lists, and connection status markers after manual disconnection, which can easily lead to state confusion when recreating the connection (such as misjudging it as "manual disconnection" and refusing the connection).

[0013] (III) Data processing questions: 1. Low message parsing fault tolerance: Rehabilitation data push includes various formats such as structured JSON (treatment parameters), semi-structured text (physician instructions), and empty messages. Existing SSE clients are prone to triggering global exceptions and interrupting the entire connection when parsing JSON format errors or empty messages, making it impossible to achieve "single message parsing failure does not affect the overall connection". In rehabilitation scenarios, the continuity of data transmission is directly related to treatment safety, and low fault tolerance poses medical risks.

[0014] 2. Issues with non-standard custom event listeners: The existing SSE client does not uniformly encapsulate the listening for custom events (such as "change in rehabilitation equipment status" and "update in treatment progress"). The listening logic of different business modules is inconsistent, which can easily lead to callback execution failures and data parsing problems, increasing the maintenance cost of the hospital-wide integrated rehabilitation system.

[0015] (iv) State-aware problems: 1. Insufficient visualization of connection status: The existing SSE client does not provide a unified interface for querying connection status. The maintenance personnel of the hospital-wide integrated rehabilitation system cannot quickly determine the SSE connection status (CONNECTING / OPEN / CLOSED) of the terminal, resulting in low efficiency in troubleshooting.

[0016] The technical solution of the present invention is as follows: According to one aspect of the present invention, a method for managing and processing real-time web communication connections and data in a hospital-wide integrated rehabilitation system is provided. This method is executed by a client and is used to establish real-time or near-real-time data communication with a server. The method specifically includes: Connection management steps: When creating or initializing a communication connection, enforce the connection retry management policy to prohibit or strictly limit automatic reconnection after the server actively disconnects or the connection fails. Data processing steps: Fault tolerance processing is performed on the data messages received from the server. Fault tolerance processing includes filtering and downgrading the parsing of invalid or abnormal format messages to ensure that the failure to process a single message does not affect the stability of the overall communication. Resource management steps: Listen to and manage the lifecycle events of the communication connection, and execute a systematic resource release process when the connection is closed or actively disconnected, destroying the communication instance, removing all event listeners, and resetting the client's internal state.

[0017] In some implementations, connection retry management policies are enforced, specifically including: Configure the client's maximum number of automatic retry attempts parameter to zero, and / or set a flag to disable automatic reconnection; In the client's connection error handling logic, the resource release process is invoked, and any automatic reconnection routines are avoided.

[0018] In some implementations, fault-tolerant processing is performed on the received data messages, specifically including: First-level verification: Determine whether the received message data is empty, blank, or a predefined invalid signal; if so, discard it directly. Second-level parsing: For messages that pass the first-level verification, attempt to parse them into a predefined structured data format; If the parsing is successful, the parsed structured data will be passed to the business processing logic. If parsing fails, the original data of the message or the downgraded formatted data is passed to the business processing logic.

[0019] In some implementations, real-time or near real-time data communication is based on the Server-Sent Events protocol, and the communication instance is an EventSource object; The connection retry management policy is implemented by setting the maximum number of retries to zero and setting a flag to disable reconnection. The resource release process includes: clearing the reconnect timer associated with the EventSource object, closing the EventSource object, and clearing its associated event listeners.

[0020] In some implementations, real-time or near real-time data communication is based on the WebSocket protocol; Connection retry management strategies also include disabling or blocking the automatic reconnection functionality natively or by the communication libraries that the WebSocket client depends on; The resource release process includes: closing the WebSocket connection and removing all its event listeners.

[0021] In some implementations, real-time or near real-time data communication is based on the HTTP short polling protocol, which simulates data push by periodically initiating HTTP requests; The connection retry management strategy is as follows: set a maximum limit on the number of times polling can be executed, and / or immediately clear the polling timer and stop all subsequent polling requests after the server returns a specified disconnect command; The resource release process includes: clearing the polling timer and resetting the callback functions and status parameters related to polling.

[0022] In some implementations, the method further includes: Create client instances using factory functions; During the creation process, a predefined unified configuration template for the hospital-wide integrated rehabilitation system is automatically applied. The template contains at least the parameters required to enforce the connection retry control strategy. When instance creation fails, the resource release process is automatically triggered.

[0023] In some implementations, during the resource management steps, when manually triggering a disconnection, the following additional steps are performed: The current disconnection is marked as manual operation mode; Clear the timer set for automatic reconnection.

[0024] In some implementations, the method further includes: Provides a standardized connection status query interface for outputting the current status information of communication connections to external entities; The status query interface returns status information selected from a predefined enumeration set, which includes at least the following: CONNECTING, OPEN, CLOSED, and UNKNOWN.

[0025] According to another aspect of the present invention, a Web real-time communication connection management and data processing system for a hospital-wide integrated rehabilitation system is also provided. This system is deployed on a client and is capable of running the Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system as described above. The system includes at least: The connection management module is used to enforce connection retry management policies when creating or initializing real-time or near-real-time communication connections with the server, so as to prohibit or strictly limit automatic reconnection behavior after the server actively disconnects or the connection fails. The data processing module is used to perform fault tolerance processing on data messages received from the server. The fault tolerance processing includes filtering and downgrading the parsing of invalid or abnormal format messages to ensure that the failure to process a single message does not affect the stability of the overall communication. The event management module is used for unified listening and callback management of lifecycle events of communication connections; The resource release module is used to execute a systematic resource release process when the connection is closed or actively disconnected, destroying the corresponding communication instance, removing all event listeners, and resetting the internal state of the system according to the communication protocol. The status awareness module provides a standardized interface for querying connection status and outputs the current status information of the communication connection to the outside world.

[0026] The beneficial effects of this invention are as follows: This invention, through its core design of "forced reconnection disabling + resource closed-loop cleanup + standardized connection creation + highly fault-tolerant message processing," achieves the following multi-dimensional beneficial effects in the context of integrated rehabilitation across the entire hospital, compared to existing technologies: (a) Connection control dimension: 1. Completely eliminate invalid reconnections and reduce server load: Through a three-layer design that forcibly disables reconnection (instance layer (disableReconnect=true), parameter layer (maxRetries=0), and method layer (handleReconnect returns directly), the automatic reconnection behavior of the client is completely blocked. After the server actively disconnects, the client will no longer initiate a retry. According to actual tests, the number of invalid connections on the hospital-level server is reduced by more than 90%, and the server CPU utilization rate is reduced by 30%-40%, which greatly improves the resource utilization rate of the hospital-wide integrated rehabilitation system.

[0027] 2. Standardized connection creation reduces deployment failure rate: By forcibly injecting the fixed parameter "disable reconnection" through factory functions, the connection creation logic is unified, avoiding manual configuration errors; when the connection fails, the resource release process is automatically triggered. When the integrated rehabilitation system for the whole hospital is deployed on multiple terminals, the failure rate of SSE connection creation is reduced from 15% to 0, and the time for maintenance personnel to troubleshoot connection problems is reduced by 80%.

[0028] 3. Precise connection status management, adapted to rehabilitation business rules: The connection status flag (isConnected / isManualDisconnect) is deeply adapted to the server-side management logic, which can accurately distinguish between scenarios such as "manual disconnection", "error disconnection" and "active closure", ensuring that rehabilitation data is only pushed within the "connection period allowed by the server", avoiding the push of data to the terminals of patients who have been discharged or transferred to other departments, which complies with medical data security standards.

[0029] (ii) Resource Management Dimension 1. Closed-loop resource cleanup in abnormal scenarios to ensure terminal stability: A closed-loop process of "status marking → forced connection closure → triggering close event → instance cleanup" is designed in the "onerror" event. All resources are cleaned up within 100ms after an error occurs. When manually disconnecting, all related resources such as reconnection timers, listener callback lists, and connection status are completely cleared. After 7×24 hours of stress testing, the industrial control computer terminal in the rehabilitation therapy room has no memory leaks or handle residue issues, and the terminal's operational stability is improved by 100%.

[0030] 2. Clean up old connections before creating new ones to avoid connection conflicts: Force close old connections and capture closing exceptions before creating new connections to resolve connection conflicts when switching rehabilitation data push between multiple departments (such as duplicate data reception caused by old connections not being closed when switching from "rehabilitation assessment data" to "device status data" push), improving data reception accuracy to 100%.

[0031] (III) Data Processing Dimension 1. High fault tolerance message parsing ensures continuous data transmission: The three-layer message processing logic of "non-empty verification → JSON parsing → exception fallback" is designed: first, empty messages are filtered, and the original string is directly passed when JSON parsing fails. The outer layer is wrapped with try-catch to ensure that the connection is not interrupted by a single message error. According to actual tests, the SSE connection can still remain stable and the data transmission continuity reaches 100% even when facing 10% of abnormal format messages (such as JSON syntax errors and garbled characters), which fully meets the core requirements of real-time monitoring of rehabilitation treatment.

[0032] 2. Unified event triggering mechanism to reduce business adaptation costs: The event callback execution logic is uniformly encapsulated by `_triggerEvent`. Even if the callback function fails to execute, only an error log is printed, which does not affect other callbacks or the overall connection. The event listening adaptation cost of different business modules (rehabilitation assessment, equipment monitoring, and medical order push) of the hospital-wide integrated rehabilitation system is reduced by 60%.

[0033] (iv) Operation and Adaptation Dimension 1. Unified connection status query improves troubleshooting efficiency: Provides the `getConnectionState` interface, which standardizes the return of four statuses: CONNECTING, OPEN, CLOSED, and UNKNOWN. Maintenance personnel can quickly locate terminal connection anomalies (such as "the terminal in the treatment room displays CLOSED but the server displays OPEN"), reducing the troubleshooting time from an average of 30 minutes to less than 5 minutes.

[0034] 2. Compatible with multiple terminals / protocols, adaptable to hospital-wide scenarios: Supports custom request headers, cross-domain configuration withCredentials, and query parameter concatenation. It can adapt to the SSE connection requirements of different terminals (PC, mobile terminal) and different network environments (internal network / hospital private network) in the hospital-wide integrated rehabilitation system, with compatibility covering 100% of the hospital's terminal types.

[0035] 3. Callback exception isolation to improve system robustness: Errors are captured separately and detailed logs are printed when event callbacks are executed (such as "Rehabilitation equipment status change event callback execution failed"), avoiding the impact of callback errors in a single business module on the operation of the entire client. The business interruption rate caused by client exceptions in the hospital-wide integrated rehabilitation system has been reduced from 8% to 0.

[0036] (v) Medical safety dimension 1. Complies with medical data transmission standards and reduces security risks: Through precise connection control and resource cleanup, it ensures that rehabilitation data is transmitted only within the "authorized connection period", avoiding the leakage of sensitive rehabilitation data (such as patient privacy and treatment plans) through invalid reconnection, which complies with the requirements of the "Medical Institution Data Security Management Standard" and reduces the risk of medical data leakage by 100%.

[0037] 2. Uninterrupted data transmission ensures treatment safety: The highly fault-tolerant message processing mechanism ensures uninterrupted real-time push of key data such as the status of rehabilitation equipment and the patient's vital signs. Medical staff can promptly grasp any abnormal situations during the treatment process (such as abnormal equipment operation or changes in patient tolerance), reducing the incidence of treatment safety accidents by 90%.

[0038] In summary, this invention comprehensively optimizes the client from the dimensions of connection control, resource management, data processing, operation and maintenance adaptation, and medical security, perfectly adapting to the core requirements of the integrated rehabilitation system for the whole hospital. Compared with existing general clients, it achieves a qualitative improvement in stability, security, adaptability, and operation and maintenance efficiency, providing highly reliable and controllable technical support for real-time data transmission of the integrated rehabilitation system for the whole hospital. Attached Figure Description

[0039] Figure 1 This is a schematic diagram of the core module architecture and terminal adaptation scenarios of the SSE client in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the entire connection management process of the SSE client in Embodiment 1 of the present invention.

[0040] Figure 3 This is a two-layer fault-tolerant logic diagram of SSE client message processing in Embodiment 1 of the present invention.

[0041] Figure 4 This is the classification management logic and resource release process of the SSE client in Embodiment 1 of the present invention. Detailed Implementation

[0042] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0043] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0044] This invention provides a method and system for real-time web communication connection management and data processing in a hospital-wide integrated rehabilitation system. It belongs to the interdisciplinary field of communication technology and medical informatics, specifically relating to a method and system for real-time web communication connection management and data processing in a hospital-wide integrated rehabilitation system. This method and system achieve real-time push and connection management of rehabilitation data (such as patient rehabilitation assessment data, treatment process data, and equipment status data) across clients and departments within the hospital-wide integrated rehabilitation platform through forced reconnection disabling, resource closed-loop cleanup in abnormal scenarios, standardized connection creation processes, and robust message processing mechanisms. This meets the core requirements of strong connection status control and high data transmission reliability in hospital rehabilitation scenarios.

[0045] like Figure 1 As shown, it illustrates the core module architecture and terminal adaptation scenarios of the client in the integrated rehabilitation system for the whole hospital of the present invention. The core module constitutes a Web real-time communication connection management and data processing system for the integrated rehabilitation system for the whole hospital. Specifically, it includes a connection management module, a data processing module, an event management module, a resource release module, and a status awareness module. It adapts to three types of core terminals: rehabilitation equipment terminals, nurse station terminals, and physician workstation terminals, and completes data interaction with the hospital-level server.

[0046] in: The connection management module is used to enforce connection retry management policies when creating or initializing real-time or near-real-time communication connections with the server, so as to prohibit or strictly limit automatic reconnection behavior after the server actively disconnects or the connection fails. The data processing module is used to perform fault tolerance processing on data messages received from the server. The fault tolerance processing includes filtering and downgrading the parsing of invalid or abnormal format messages to ensure that the failure to process a single message does not affect the stability of the overall communication. The event management module is used for unified listening and callback management of lifecycle events of communication connections; The resource release module is used to execute a systematic resource release process when the connection is closed or actively disconnected, destroying the corresponding communication instance, removing all event listeners, and resetting the internal state of the system according to the communication protocol. The status awareness module provides a standardized interface for querying connection status and outputs the current status information of the communication connection to the outside world.

[0047] Figure 2 This demonstrates the entire connection management process for the SSE client, highlighting the core logic of "forced disabling of reconnection." It covers key steps such as connection creation, parameter configuration, exception handling, and resource cleanup, clearly defining the control rules that prevent reconnection from being triggered in the event of connection failure / error. (Corresponding connection management steps) Figure 2 The specific process is as follows: S21, Begin; S22. Create an SSE client instance; S23. Configure connection parameters (URL / request headers / query parameters, etc.); S24. Force disabling reconnection (e.g., maxRetries=0 / disableReconnect=true); S25. Close any existing connection (if it exists); S26. Construct the complete URL for the query parameters; S27. Create an EventSource instance; S28. Determine whether the connection is successful. If the connection is successful, proceed to steps S29-S213. If the connection fails, proceed to steps S214-S217. S29. Listen for open / message / error events; S210, Normal data reception / processing; S211. Determine if a connection error has occurred. If yes, proceed to steps S212-S213. If no, continue running step S29. S212. Clean up resources (shut down the EventSource instance and reset the connection status flag); S213, End; S214, Trigger the error event; S215. Clean up resources (shut down the EventSource instance, reset the connection state flags). S216. Mark the connection as closed, do not trigger reconnection; S217, End.

[0048] Figure 3 This demonstrates the two-layer fault-tolerance logic for SSE client message processing: first, it verifies the non-emptiness of data, and then it adapts to fallback handling for JSON parsing failures, ensuring that a single message exception does not affect the overall connection stability. (Corresponding data processing steps) Figure 3 The specific process is as follows: S31, Begin; S32, Receive push messages from the SSE server; S33. Check if the message data is not empty. If yes, proceed to step S34; otherwise, discard the empty message and end the process. S34. Attempt to parse the JSON format; S35. Determine whether the parsing was successful. If yes, proceed to steps S36-S38; otherwise, proceed to steps S39-S311. S36. Trigger the message event (JSON data); S37. Callback function processes data; S38, End; S39. Trigger the message event (raw string); S310, Callback function processes data; S311, End.

[0049] Figure 4 This demonstrates the event listening management logic (standard events / custom events) and the entire resource release process of the SSE client, clearly outlining the resource cleanup steps when manually disconnecting to ensure no memory leaks or handle remnants on the terminal. (Corresponding resource management steps) Standard events include, but are not limited to: open / message / error / close; standard event triggers are bound to a built-in callback list; Custom events include, but are not limited to: device alarms / evaluation data; custom event triggers bound to the native EventSource listener; Figure 4 The complete process of resource release in the middle is as follows: S41, Trigger the disconnect method; S42, Manually disconnect the marker; S43, Cancel reconnection timer; S44. Close the EventSource instance; S45. Clear all event listener lists; S46, Reset connection status / retry count and other parameters; S47. Resource release complete.

[0050] Combination Figures 1-4 The present invention provides a method and system for real-time web communication connection management and data processing for an integrated rehabilitation system for the whole hospital, according to the following embodiments, for describing the technical solution of the present invention in detail.

[0051] Example 1: Real-time status push of rehabilitation equipment based on SSE protocol (nurse station scenario) This embodiment corresponds to Figure 2 , Figure 3 , Figure 4 The process shown demonstrates the core applications of connection management, message fault tolerance, and resource release under the SSE protocol.

[0052] 1. Application Scenario Description: In this scenario, the operating status (power on / off, operating parameters, fault alarms) of rehabilitation equipment (such as rehabilitation robots, electrotherapy devices, and exercise treadmills) needs to be pushed to the rehabilitation department nurse station terminal in real time via SSE. The server is required to actively disconnect the connection when the equipment is turned off or after treatment, and the client should not reconnect to avoid unnecessary resource occupation.

[0053] 2. Implementation steps: Step 1: Initialize the SSE client and create a standardized connection: The nurse station terminal first calls the preset SSE connection factory function to create an SSE connection adapted to the rehabilitation equipment status push scenario.

[0054] Configure core connection parameters: Specify the URL address for the server to receive device status pushes; set query parameters, including the ID of the rehabilitation robot device to be monitored and the rehabilitation department code; configure the request header, carrying the hospital-level permission token (to ensure data transmission permissions), specifying the SSE data format type, and enabling cross-domain cookie carrying function to adapt to the hospital-level single sign-on system.

[0055] Connection creation logic: The factory function automatically injects core parameters such as "maxRetries=0, disableReconnect=true, i.e., the maximum number of retries is 0 and reconnection is disabled" (corresponding to step S24 in the figure), without requiring manual configuration by terminal operators. This ensures that the connection creation rules of all nurse station terminals are consistent and avoids invalid reconnection problems caused by incorrect parameter configuration.

[0056] Pre-processing: Before creating a new connection, check and close any existing old SSE connections in the terminal to release related resources and prevent connection conflicts.

[0057] Step 2: Listen for device status events and process rehabilitation data: After the connection is established, register multiple types of event listening logic for the SSE client to receive and process device status: Connection establishment event listener: When the SSE connection is successfully established, update the connection status to "connected (rehabilitation robot 001)" on the nurse station terminal interface and record the connection success log.

[0058] Device status message listening: Receives device status data pushed by the server, first verifies the data validity (filters empty data), and then distinguishes the data type (structured JSON / raw text) for parsing. If the data is structured JSON (containing device ID, running status, and running parameters), then update the device status display area (e.g., "Running / Shutdown / Fault") and parameter display area (e.g., intensity, speed values) on the nurse station interface; if the device status is detected as "Shutdown", then display the message "Device is off, connection will be automatically closed" on the interface.

[0059] If an error occurs during parsing (such as an abnormal JSON format), only a "data error" message will be displayed on the interface, without interrupting the entire SSE connection, ensuring that the reception of other normal data is not affected.

[0060] Custom fault alarm event listener: Listen for custom "equipment fault" events pushed by the server, trigger a hospital-level alarm pop-up (displaying the device ID and fault information), and simultaneously report the fault log to the hospital-level management system for timely handling by maintenance personnel.

[0061] Error / Close Event Listener: When a connection error occurs, update the interface connection status to "Connection Error"; when the connection is closed, update the interface status to "Closed" and actively clean up message listeners and fault alarm listener callbacks related to the device status to avoid terminal memory leaks.

[0062] Step 3: Manually disconnect (e.g., during a shift change at the nurses' station): When nursing station staff change shifts, a manual disconnection operation can be triggered via the "Disconnect" button on the interface: Call the disconnect method of the SSE client, mark the "manual disconnect" state, clear the reconnection timer (if it exists), close the EventSource instance, and reset the connection state flag, listener list, retries count and other core parameters.

[0063] Reset the device status, parameters, and connection status display area on the nurse station interface to ensure that the terminal status is cleared and ready for use by the next shift.

[0064] Step 4: Query connection status (operation and maintenance troubleshooting): Maintenance personnel can trigger a connection status query via the "Query Status" button on the interface: Call the SSE client's status query method to obtain the standardized connection status (connecting / open / closed / unknown) and display it on the interface; The device ID, connection status, query time, and other information are reported to the institute-level operation and maintenance log system to facilitate subsequent fault tracing and analysis.

[0065] 3. Implementation Results: After the rehabilitation equipment is shut down, the server disconnects, and the client does not reconnect at all, resulting in a 90% reduction in invalid connections to the hospital-level SSE server. Abnormal device data only triggers a single message notification, the connection remains stable, and the nurse station terminal can run 24 / 7 without lag; After manually disconnecting, all resources are 100% cleaned up, and there are no state conflict issues when recreating the connection.

[0066] Example 2: Patient rehabilitation assessment data push based on SSE protocol (physician workstation scenario) This embodiment focuses on demonstrating cross-departmental data transmission and controllable reconnection strategies at the business layer.

[0067] 1. Application Scenario Description: In this scenario, the patient assessment report (structured JSON) and assessment conclusions (text) completed by the rehabilitation assessor need to be pushed to the physician's workstation via SSE. Requirements: Supports cross-department and cross-terminal push notifications (Assessment Department → Rehabilitation Department Physician Station). Empty messages / formatted error messages do not interrupt the connection; If a connection error occurs, clean up resources immediately to avoid affecting other services on the physician workstation (such as the electronic medical record system).

[0068] 2. Implementation steps: Step 1: Create a cross-departmental SSE connection: The physician workstation calls the factory function to create an SSE connection and configures the core parameters: The server URL is the address where patient assessment data is pushed. The query parameters include the patient ID and the attending physician ID to ensure that the data is accurately pushed to the corresponding physician's terminal. The request header carries the physician's hospital-level access token and department identifier to ensure the compliance of permissions for cross-departmental data transmission.

[0069] Step 2: Process the evaluation data and adapt it to multiple data formats: To facilitate connection registration message listening logic, multi-format evaluation data is specifically processed: Empty message filtering: After receiving data, it is first validated. If it is empty or a blank string, it is ignored and no further processing is performed; (corresponding to...) Figure 3 Step S33) Data type differentiation and handling: If the data is structured JSON (assessment report), the hospital-level electronic medical record system interface is called to synchronize the assessment report to the patient's electronic medical record. After successful synchronization, the physician workstation interface will display "Assessment report has been received and synchronized". If the data is text (evaluation conclusion), it will be displayed directly in the to-do list of the physician's workstation, with the message "Received patient evaluation conclusion, please review". Enhanced error event handling: When a connection error occurs, in addition to the client automatically cleaning up resources, the business layer additionally calls the disconnect method to double-protect resource release, and at the same time displays the message "Evaluation data push connection abnormal, closed" on the interface.

[0070] Step 3: Connection status monitoring and automatic reconnection (controllable reconnection at the business layer): To address the requirement of physician workstations to "receive important data," a business-layer controllable reconnection logic was designed: Set the maximum number of manual reconnections (e.g., 2 times). If the maximum number of reconnections has not been reached when the connection is closed, wait 3 seconds and then call the factory function to recreate the connection. After a successful reconnection, the reconnection count is reset, and the interface displays "Evaluation data connection has been restored"; if the maximum number of reconnections is reached and reconnection still fails, the message "Multiple reconnection failures, please refresh manually" will be displayed to avoid unlimited reconnections consuming resources.

[0071] 3. Implementation Results: Empty messages and formatted error messages are effectively filtered, and there are no abnormal pop-up windows interfering with the physician workstation; After a connection error occurs, all resources are cleaned up within 100ms, without affecting the operation of core services such as the electronic medical record system; The business layer's controllable reconnection balances "data delivery guarantee" and "resource management," meeting the usage needs of physician workstations.

[0072] Example 3: Multi-terminal batch deployment based on SSE protocol This example demonstrates how to achieve large-scale unified deployment through standardized tools.

[0073] 1. Application Scenario Description: In this scenario, the SSE client needs to be deployed in batches across 50+ rehabilitation terminals (industrial control computers in treatment rooms, mobile ward round tablets, and nurse station computers) throughout the hospital. Requirements: Unified connection configuration reduces operation and maintenance costs; Supports terminal type adaptation (PC / tablet). Faults are traceable, and logs are standardized.

[0074] 2. Implementation steps: Step 1: Encapsulate a department-level SSE connection utility class for unified configuration: Develop a unified SSE connection utility class for the entire development institute, encapsulating core capabilities: Unified connection creation method: Receive device ID parameter, automatically concatenate the unified SSE server URL at the college level, automatically identify terminal type (by parsing browser user agent information to distinguish between PC and tablet), and use terminal type and device ID as query parameters, and unified college-level permission token and terminal type as request headers to ensure that the connection parameter format of all terminals is consistent; Unified event monitoring registration method: Register standardized log output logic for SSE connection of all terminals. The log format includes "time + terminal type + device ID + event type". At the same time, the connection status (open / error / closed) is reported to the hospital-level operation and maintenance platform. Unified token acquisition method: Encapsulate the logic for reading the institute-level permission token to avoid duplicate coding across different terminals.

[0075] Step 2: Batch call a unified utility class across multiple terminals: Different types of terminals call a unified utility class to create connections and process business logic: The industrial control computer (PC) in the rehabilitation therapy room calls the utility class to create a device status monitoring connection, registers message listening logic, receives treatment data and synchronizes it to the local treatment system, and records logs in a standardized format. Mobile ward round tablet (TABLET): Calls the utility class to create a ward round data push connection, registers message listening logic, displays the received data on the mobile ward round interface, and records logs in a standardized format; The connection status and error information of all terminals are reported to the hospital-level operation and maintenance platform in a unified format for centralized monitoring.

[0076] 3. Implementation Results: With 50+ terminals connected and configured uniformly, maintenance personnel do not need to adjust parameters individually, improving deployment efficiency by 90%. With standardized logs and status reporting, the hospital-level operation and maintenance platform can monitor the SSE connection status of all terminals in real time, reducing the fault location time from 30 minutes to 5 minutes. The device type is automatically identified, and optimizations can be made for tablets (such as reducing the frequency of message pushes) to save device power.

[0077] Example 4: Verification of Resource Cleanup in Abnormal Scenarios Based on SSE This embodiment aims to verify the robustness of the system under extreme anomalies.

[0078] 1. Application Scenario Description: This scenario simulates anomalies in the SSE connection within the integrated rehabilitation system of the entire hospital (server crash, network interruption, expired permissions) to verify the client's resource cleanup capabilities and fault recovery adaptability.

[0079] 2. Implementation steps: Step 1: Simulate connection errors caused by server downtime Create an SSE connection to the downed server, listen for error events, and verify the effectiveness of resource cleanup: After a connection error event is triggered, check the EventSource instance status to confirm that it is in the "closed" state; Check the listener list to confirm that all listener callbacks related to this connection have been cleared; Check the connection status flags to confirm that the "Connected?" flag is false and that parameters such as the number of retries and the reconnection timer have been reset.

[0080] Step 2: Simulate connection termination due to expired permissions: Create an SSE connection carrying an expired permission token, listen for close events, and handle fault recovery: After the connection was closed due to expired permissions, the college-level permission token refresh logic was triggered. After the token is successfully refreshed, the factory function is called again to create the connection, ensuring that the physician workstation can continue to receive evaluation data; There is no automatic reconnection throughout the process; all recovery operations are triggered as needed by the business layer.

[0081] 3. Implementation Results: After the server crashes, the client completes all resource cleanup within 100ms, with no connection handle residues or memory leaks. In scenarios where permissions expire, automatic reconnection is not triggered after the connection is closed. The business layer can safely refresh the token and rebuild the connection, which complies with the institute-level permission control rules.

[0082] Example 5: Real-time bidirectional consultation negotiation based on the WebSocket protocol This embodiment demonstrates the application of the core method of the present invention in the WebSocket protocol.

[0083] The Web real-time communication connection management and data processing method and system operation logic and architecture of the present invention for the integrated rehabilitation system of the whole hospital are basically the same as those of Embodiment 1, except that: this embodiment uses the WebSocket protocol instead of SSE.

[0084] The core logic of this embodiment is as follows: the WebSocket full-duplex communication protocol is used to replace the one-way push of SSE. After the client and the server establish a long TCP connection, they can send and receive data bidirectionally. In the integrated rehabilitation system of the whole hospital, when the server actively pushes the status of rehabilitation equipment and patient assessment data, it is implemented by the WebSocket server actively sending (send) method, and the client receives the data by listening for onmessage.

[0085] Deployment adaptation in this embodiment: Reuse the existing WebSocket service framework at the hospital level (such as the ws library in Node.js or Netty in Java), deploy the WebSocket service node on the rehabilitation department server, and create a connection on the terminal side through the native WebSocket API (newWebSocket()), and configure permission verification consistent with SSE (the request header carries the hospital-level token and device / department code).

[0086] Reconnection and resource management in this embodiment: Custom reconnection logic (such as heartbeat detection + disconnection reconnection), connection keep-alive through ping / pong frames, terminal side listens for close / error events to trigger reconnection, and at the same time, automatic reconnection is forcibly disabled through configuration options (aligned with the original SSE client logic) to ensure that the terminal does not retry after the server actively disconnects.

[0087] The specific implementation method of this embodiment is as follows: Connection creation and reconnection management: In the real-time video consultation system between the physician workstation and the rehabilitation treatment room, the WebSocket protocol is used for bidirectional command and data push. When creating a WebSocket instance, the automatic reconnection feature of the WebSocket library used (such as Socket.io or ReconnectingWebSocket) is disabled by configuration, or the onclose method is overridden to ensure that the cleanup process is entered directly after the connection is closed, without triggering reconnection.

[0088] Message fault tolerance: In the WebSocket's onmessage event handler, integrate with... Figure 3 Similar fault-tolerance logic applies. Received consultation instructions (such as "adjust camera angle" or "focus on affected area") are in JSON format. Before processing, a non-empty check is performed, and then an attempt is made to parse the JSON. If parsing fails (e.g., due to network interference causing data packet corruption), the instruction is marked as "unable to parse" and logged. Simultaneously, a "message reception error" receipt is sent to the server, but the WebSocket connection remains open to ensure subsequent instructions are received normally.

[0089] Resource release: When the consultation ends, the business logic calls the `disconnect()` method. The resource release module executes: it marks the connection as manually disconnected, calls `websocket.close()`, removes all listeners such as `onopen`, `onmessage`, `onerror`, and `onclose`, and releases related resources. Even if the consultation ends abnormally due to a network interruption, the `onclose` event will trigger the same cleanup process to prevent residual connection objects.

[0090] The advantages of this embodiment compared to Embodiment 1 are: 1. Two-way communication capability: In addition to data pushed by the server, the terminal can actively send instructions to the server (such as confirmation of rehabilitation equipment parameter adjustment, data reception receipt), adapting to the two-way interaction scenario of "terminal feedback-server response" in the hospital-wide rehabilitation system (such as physician workstation confirmation of receiving assessment data). 2. High protocol maturity: WebSocket is an HTML5 standard protocol, which is deeply supported by all modern browsers (including Chrome on the rehabilitation science industrial control computer and mobile browsers on tablets), and its compatibility is better than the niche compatibility issues of some older terminals with SSE. 3. Strong connection stability: Based on TCP long connection + heartbeat keep-alive mechanism, compared with the underlying logic of SSE which relies on HTTP long polling, the connection stability is higher under network fluctuations, and it is suitable for complex network environments in the hospital (such as cross-network segment communication between rehabilitation therapy room and nurse station).

[0091] Example 6: Monitoring of Rehabilitation Consumables Inventory Based on HTTP Short Polling This embodiment demonstrates the application of the core method of the present invention in the HTTP short polling protocol.

[0092] The operating logic and architecture of the Web real-time communication connection management and data processing method for the integrated rehabilitation system of the whole hospital of the present invention are basically the same as those of Embodiment 1. The difference is that this embodiment uses HTTP short polling instead of SSE.

[0093] The core logic of this embodiment is: abandoning the long connection scheme and using HTTP short polling to achieve "near real-time" data push; the terminal side sends an HTTP GET request to the server at fixed intervals (e.g., 1-5 seconds) through a timer (setInterval) to query the rehabilitation equipment status / patient assessment data, and closes the connection after the server returns the latest data; In this embodiment, the parameter adaptation is as follows: the polling request carries the same query parameters (device ID, department code) and request header (hospital-level token) as the original SSE. After the server verifies the interface permissions, it returns structured data (JSON format). Resource management in this embodiment: By configuring the polling interval and the maximum number of requests, the "SSE-like disabling reconnection" logic is implemented (e.g., after the server returns the "connection closed" flag, the terminal immediately clears the timer and stops polling).

[0094] The implementation of this embodiment is illustrated through the following example: Connection (Polling) Creation and Management: For monitoring the inventory status of rehabilitation consumables, which has lower real-time requirements, HTTP short polling is used. The client starts polling through a factory function, setting the polling interval (e.g., 30 seconds) and the maximum number of polls (e.g., 480 times, corresponding to a 4-hour shift). This essentially transforms "disabling automatic reconnection" into "limiting the maximum number of retries". When the server response contains the `inventory_status: "closed"` directive, the client immediately clears the polling timer and stops subsequent requests.

[0095] Data fault tolerance: In the response handling function of each polling cycle, the HTTP status code is checked first. For a 200 response, fault-tolerant parsing is implemented on the response body (a JSON-formatted inventory list): after verifying that it is not empty, JSON.parse() is attempted. If parsing fails, the result of this polling cycle is set to "data error" and a prompt is displayed on the UI, but the next polling cycle is not stopped, ensuring monitoring continuity.

[0096] Resource release: When the maximum number of polling attempts is reached or a stop command is received from the server, the system triggers a resource release process: clearing the polling timer, setting the request callback function to null, and resetting all related status variables. This ensures that no timer residue and no memory leaks occur after the monitoring task ends.

[0097] The advantages of this embodiment compared to Embodiment 1 are: 1. Extremely low development cost: No need to rely on long connection protocols, reuse the hospital's existing HTTP interface development specifications, the server only needs to add a RESTful interface for "querying the latest rehabilitation data", and the client can implement it through axios / fetch. The adaptation cycle for 50+ terminals is only 1 / 3 of that of SSE. 2. Seamless compatibility: All terminals (including older industrial control computers and low-version browsers) support HTTP GET requests, with no protocol compatibility issues, adapting to the current deployment status of "multi-terminal, multi-version" in the hospital's rehabilitation system; 3. Simple resource management: Polling can be completely stopped by clearing the timer. Compared with the long connection resource cleanup of SSE / WebSocket, there is no risk of EventSource / WebSocket instance residue, and the terminal memory usage is lower.

[0098] Example 7: Standardized Connection Status Query (Additional Functionality) The client in any of the embodiments one through six above can implement the status query interface. The client internally maintains a status enumeration (CONNECTING, OPEN, CLOSED, UNKNOWN). It provides the getConnectionStatus() method (e.g., ...). Figure 1The status awareness module (5) is available for use by the front-end interface or operation and maintenance system to obtain the current connection status in a standardized format, facilitating unified monitoring and troubleshooting. This function enhances core management capabilities.

[0099] The advantages of the Web real-time communication connection management and data processing method and system for integrated hospital rehabilitation system of the present invention compared with the prior art are as follows: 1. Universally applicable protocol, enabling unified and robust control capabilities: Existing technologies are typically optimized for a single protocol (such as SSE), or require redesigning the management logic when switching protocols (such as using WebSocket). This solution abstracts a core management framework decoupled from the underlying communication protocol, which can be uniformly applied to three mainstream web instant messaging methods: SSE, WebSocket, and HTTP short polling. Whether it's SSE's EventSource, WebSocket instances, or polling's setInterval, all can be managed through the same method of "forced reconnection disabling + fault tolerance + resource release," achieving unification and simplification of the technology stack.

[0100] 2. Completely eliminate invalid reconnections, ensuring medical data security and server resource protection: Existing general-purpose client libraries (whether SSE, WebSocket, or polling libraries) typically have built-in automatic reconnection mechanisms that are difficult to completely disable. This solution, through a multi-layered enforcement strategy (setting parameters to zero, disabling flags, and bypassing reconnection in error handling logic), fundamentally prohibits client-initiated automatic reconnection behavior that is not controlled by business logic. This makes the connection lifecycle completely subject to the server-side business rules (such as patient transfer to another department or treatment completion). Its direct effect is: Eliminate the risk of accidental data push: Avoid pushing sensitive rehabilitation data to terminals that no longer have permission or whose treatment has ended, which complies with medical data security regulations.

[0101] Significantly reduces server load: Eliminates redundant connections and requests caused by invalid client retries, significantly saving server CPU, memory, and network connection resources.

[0102] 3. Establish a closed-loop resource management system to ensure long-term stable operation of the system: Existing technologies often only disconnect the network connection when a connection fails or is manually disconnected, neglecting to clean up internal client resources (such as event listeners, timers, and object references), leading to memory leaks. This solution employs a systematic resource release process that synchronously destroys the communication instance, removes all event listeners, clears timers, and resets the internal state at any point in the connection closure process (active disconnection, error, manual operation). This ensures that medical terminals (such as industrial PCs and tablets) operate 24 / 7 without memory leaks or handle remnants, fundamentally guaranteeing the long-term stability and responsiveness of the terminal.

[0103] 4. Improve message processing robustness and ensure the continuity of critical data streams: Existing solutions often throw uncaught exceptions when parsing malformed data (such as incorrectly formatted JSON), causing the entire connection to be interrupted or the polling task to stop. This solution introduces a structured two-layer fault-tolerance mechanism: the first layer filters empty / invalid messages; the second layer automatically downgrades to a safe data format (such as raw text) for transmission when JSON parsing fails, and the entire process is isolated by exception handling. This achieves the goal of "single message processing failure does not affect the overall communication link," which is crucial for critical medical data flows that cannot be interrupted, such as vital signs and device alarms, greatly improving the reliability and safety of treatment.

[0104] 5. Achieve standardized deployment and visualized operation and maintenance, reducing the cost of large-scale applications: Existing technologies, when deployed across multiple terminals and departments, rely on manual configuration, which is prone to errors and difficult to monitor uniformly. This solution addresses this issue through a factory-style creation model and standardized status interfaces. Factory functions automatically inject unified configurations (such as forcibly disabling reconnection), ensuring consistent connection behavior for hundreds or thousands of terminals across the entire facility, greatly reducing configuration error rates and deployment complexity.

[0105] The standardized status query interface provides a clear view of connection status (such as CONNECTING, OPEN, CLOSED) for operations and maintenance, which significantly improves the efficiency of monitoring, fault location and troubleshooting of real-time communication links throughout the hospital.

[0106] In summary, this technical solution transforms the previously fragmented, passive, and vulnerable behavior of general-purpose clients into a centralized, proactive, robust management system deeply aligned with medical business rules. It not only addresses the specific shortcomings of existing technologies operating under a single protocol but also provides a universal solution adaptable to multiple communication protocols, meeting the high security, high reliability, and high stability requirements of medical scenarios, thus possessing broad clinical application value.

[0107] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. A method for managing and processing real-time web communication connections and data in a hospital-wide integrated rehabilitation system, wherein the method is executed by a client to establish real-time or near-real-time data communication with a server, characterized in that... The method includes: Connection management steps: When creating or initializing a communication connection, enforce the connection retry management policy to prohibit or strictly limit automatic reconnection after the server actively disconnects or the connection fails. Data processing steps: Perform fault tolerance processing on the data messages received from the server. The fault tolerance processing includes filtering and downgrading the parsing of invalid or abnormal format messages to ensure that the failure to process a single message does not affect the stability of the overall communication. Resource management steps: Monitor and manage the lifecycle events of the communication connection, and execute a systematic resource release process when the connection is closed or actively disconnected, destroying the communication instance, removing all event listeners, and resetting the client's internal state.

2. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to claim 1, characterized in that, The mandatory connection retry management policy specifically includes: Configure the maximum number of automatic retry attempts for the client to zero, and / or set a flag to disable automatic reconnection; In the connection error handling logic of the client, the resource release process is invoked, and any automatic reconnection routine is avoided.

3. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to claim 1, characterized in that, The fault-tolerant processing of data messages received from the server specifically includes: First-level verification: Determine whether the received message data is empty, blank, or a predefined invalid signal; if so, discard it directly. Second-level parsing: For messages that pass the first-level verification, attempt to parse them into a predefined structured data format; If the parsing is successful, the parsed structured data will be passed to the business processing logic. If parsing fails, the original data of the message or the downgraded formatted data is passed to the business processing logic.

4. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to any one of claims 1-3, characterized in that, The real-time or near-real-time data communication is implemented based on the Server-Sent Events protocol, and the communication instance is an EventSource object; The connection retry management strategy is implemented by setting the maximum number of retries to zero and setting a reconnection-disable flag; The resource release process includes: clearing the reconnect timer associated with the EventSource object, closing the EventSource object, and clearing its associated event listeners.

5. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to any one of claims 1-3, characterized in that, The real-time or near-real-time data communication is implemented based on the WebSocket protocol; The connection retry management strategy also includes disabling or blocking the automatic disconnection and reconnection function of the WebSocket client's native or dependent communication library; The resource release process includes: closing the WebSocket connection and removing all its event listeners.

6. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to any one of claims 1-3, characterized in that, The real-time or near-real-time data communication is implemented based on the HTTP short polling protocol, which simulates data push by periodically initiating HTTP requests; The connection retry management strategy is as follows: set a maximum number of polling executions, and / or immediately clear the polling timer and stop all subsequent polling requests after the server returns a specified disconnect command; The resource release process includes: clearing the polling timer and resetting the callback functions and status parameters related to the polling.

7. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to any one of claims 1-3, characterized in that, The method further includes: The client instance is created using a factory function; During the creation process, a predefined unified configuration template for the hospital-wide integrated rehabilitation system is automatically applied. The template contains at least the parameters required to enforce the connection retry control strategy. The resource release process is automatically triggered when instance creation fails.

8. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to any one of claims 1-3, characterized in that, In the resource management steps, when manually triggering a disconnection, the following additional steps are performed: The current disconnection is marked as manual operation mode; Clear the timer set for automatic reconnection.

9. The Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system according to any one of claims 1-3, characterized in that, The method further includes: A standardized connection status query interface is provided for outputting the current status information of the communication connection to external parties; The status query interface returns status information selected from a predefined enumeration set, which includes at least: CONNECTING, OPEN, CLOSED, and UNKNOWN.

10. A Web-based real-time communication connection management and data processing system for an integrated hospital rehabilitation system, characterized in that, Deployed on a client and capable of running the Web real-time communication connection management and data processing method for a hospital-wide integrated rehabilitation system as described in any one of claims 1-9, the system includes at least: The connection management module is used to enforce connection retry management policies when creating or initializing real-time or near-real-time communication connections with the server, so as to prohibit or strictly limit automatic reconnection behavior after the server actively disconnects or the connection fails. The data processing module is used to perform fault tolerance processing on data messages received from the server. The fault tolerance processing includes filtering and downgrading the parsing of invalid or abnormal format messages to ensure that the failure to process a single message does not affect the stability of the overall communication. The event management module is used to uniformly listen to and manage the callbacks of the lifecycle events of the communication connection. The resource release module is used to execute a systematic resource release process when the connection is closed or actively disconnected, destroying the corresponding communication instance, removing all event listeners, and resetting the internal state of the system according to the communication protocol. The status awareness module provides a standardized connection status query interface and outputs the current status information of the communication connection to the outside world.

Images