Multi-protocol cooperative control method and device for medical care talkback and medium

Abstract

The invention discloses a multi-protocol cooperative control method and device for medical care talkback and a medium. The method comprises the following steps: acquiring an event notification reported by an initiating terminal when a key event or a state change event occurs; if an event corresponding to the event notification conforms to a preset system rule and a target device corresponding to the event notification exists and is online, sending a call request protocol to the target device, so that the target device establishes a session initial protocol communication link with the initiating terminal based on the call request protocol; wherein the session initiation protocol communication link is used for performing audio data transmission between the initiating terminal and the target device. According to the multi-protocol cooperative control method and device for medical care talkback and the medium provided by the invention, a unified communication link is constructed by being compatible with multiple types of initiating terminals such as a sickbed extension set, a ward extension set and preset extension equipment and adopting a session initiation protocol, so that a protocol barrier between different equipment is broken; the problems of difficulty in equipment adaptation and high response delay of a medical intercom system can be solved.

Description

Technical Field

[0001] This invention relates to the field of walkie-talkie technology, and in particular to a multi-protocol collaborative control method, device and medium for medical and nursing intercom. Background Technology

[0002] With the continuous deepening of hospital informatization, medical staff intercom systems have been widely deployed in various ward scenarios, covering key areas such as beds, wards, and nurse stations. The core functions include call linkage between patients and medical staff, real-time voice intercom, equipment status reporting, emergency assistance, and nursing notification push notifications. These systems provide immediate support for rapid communication between doctors and patients and efficient ward scheduling, becoming a key infrastructure for hospital informatization operation and maintenance and collaborative medical services. Existing medical staff intercom systems have software architectures that are tied to specific hardware. Communication often uses TCP or proprietary protocols, and events such as calls, button presses, and system notifications are handled by different modules. Some are built on Android or general-purpose systems, establishing a SIP session first, followed by audio acquisition, echo cancellation, and UDP transmission to achieve basic functions such as calls, voice intercom, and status reporting between patients in beds and nurse stations.

[0003] However, the existing medical intercom system's software architecture is tightly coupled with specific hardware, making it unusable across devices. Furthermore, its communication methods are limited to TCP or proprietary protocols, and it lacks a unified processing model for various call, button press, and system notification events. This not only increases the system's maintenance and upgrade costs but also directly causes difficulties in device adaptation. Devices built on Android or general systems are prone to status reporting delays in high-concurrency scenarios due to their lengthy event reporting paths. Additionally, the intercom mechanism uses a process of establishing a SIP session before processing audio acquisition, echo cancellation, and UDP transmission, resulting in poor compatibility between different terminals and further exacerbating issues such as high response latency and unstable call quality. Summary of the Invention

[0004] This invention provides a multi-protocol collaborative control method, device, and medium for medical intercom systems to solve the problems of difficult equipment adaptation and high response delay in medical intercom systems.

[0005] To achieve the above objectives, this application provides a multi-protocol collaborative control method for medical intercom, applicable to a central server, comprising: Receive event notifications reported by the initiating terminal when a key event or state change event occurs; wherein, the initiating terminal is a bedside extension, a ward extension, or a preset extended device; If the event notification corresponds to an event that conforms to a preset system rule, and the target device corresponding to the event notification exists and is online, then a call request protocol is sent to the target device so that the target device can establish a session initiation protocol communication link with the initiating terminal based on the call request protocol; wherein, the session initiation protocol communication link is used to transmit audio data between the initiating terminal and the target device based on a preset intercom mechanism.

[0006] At the device adaptation level, this invention adopts the Session Initiation Protocol (SIP) as a unified communication standard, covering diverse terminals such as bedside extensions, ward extensions, and pre-set extended devices. It abandons the fragmented development model of traditional systems where different types of devices require dedicated adaptation interfaces, achieving protocol-level compatibility for multi-device access. This significantly reduces the adaptation threshold for cross-vendor and cross-model devices, avoiding access failures or functional abnormalities caused by inconsistent interfaces. Simultaneously, through event notification and pre-set system rule matching verification, it can flexibly accommodate event reporting mechanisms of different devices, improving adaptation flexibility. At the response latency optimization level, after receiving an event notification, it prioritizes system rule matching and pre-verification of the target device's online status, filtering invalid requests in advance, avoiding resource waste, and ensuring priority processing of valid requests. Subsequently, a direct communication link is quickly established based on the SIP, eliminating the intermediate link of multi-node forwarding in traditional systems. Furthermore, by controlling audio data transmission, it ensures the interactive coordination between the initiating terminal and the target device, shortening the entire process time from event triggering to intercom initiation, effectively reducing response latency and solving the latency pain point in real-time intercom scenarios.

[0007] Compared to existing technologies, this invention breaks down protocol barriers between different devices by being compatible with multiple types of initiating terminals, such as bedside extensions, ward extensions, and pre-set extended devices, and by using a session initiation protocol to build a unified communication link. This eliminates the redundant steps of multi-node forwarding in traditional systems and reduces the time consumed from event triggering to intercom startup. Therefore, it can solve the problems of difficult device adaptation and high response latency in medical intercom systems.

[0008] As a preferred embodiment, if the event corresponding to the event notification conforms to preset system rules, and the target device corresponding to the event notification exists and is online, then a call request protocol is sent to the target device, specifically as follows: The initiating terminal permissions and event type in the event notification are compared and verified with the preset system rules to obtain the event compliance verification result; Based on the target device identifier in the event notification, the device online status list is queried to obtain a determination result that the target device exists and is online; wherein, the device online status list is updated by device status data reported in real time by several terminals; If both the verification result and the determination result are passed, the initiating terminal information, the target device identifier, and the event type in the event notification are packaged based on the User Datagram Protocol (UDP) to generate the call request protocol, and the call request protocol is sent to the target device.

[0009] This preferred solution accurately filters compliant events by comparing and verifying the initiating terminal's permissions and event type with preset system rules, preventing unauthorized calls or invalid operations from interfering with system order and ensuring the security and standardization of the medical intercom system. By querying the target device status based on a real-time updated list of online device statuses, invalid scenarios such as offline or non-existent devices can be eliminated in advance, reducing the transmission of useless call requests and lowering system resource consumption. The use of the User Datagram Protocol (UDP) to package key information and generate a call request protocol balances high data transmission efficiency and lightweight design, ensuring that call requests are quickly delivered to the target device. This meets the core requirement of timely response in medical settings and improves the timeliness of doctor-patient communication.

[0010] As a preferred embodiment, the target device establishes a session initiation protocol communication link with the initiating terminal based on the call request protocol, specifically as follows: The target device is controlled to receive the call request protocol and extract the initiating terminal communication address and event type. Combined with the extracted data and the area parameters and permission parameters of the target device when it goes online, the legitimacy of the connection corresponding to the call request protocol is verified. If the verification is successful, the target device is controlled to initiate a Session Initiation Protocol (SIP) connection request containing media negotiation parameters to the initiating terminal based on the initiating terminal's communication address, and a User Datagram Protocol (UDP) heartbeat is initiated to detect the link connectivity status between the target device and the initiating terminal. When the link connectivity is established, after the initiating terminal responds to the Session Initiation Protocol (SIP) connection request, the initiating terminal and the target device are controlled to interact and confirm media parameters through SIP signaling. After the interaction and confirmation of SIP signaling are completed, the SIP communication link is established.

[0011] This preferred solution combines the target device's own region and permission parameters to verify the legitimacy of the call request, further strengthening the system's security defenses, preventing unauthorized connections, and ensuring the privacy and integrity of medical communication data. Activating the User Datagram Protocol (UDP) heartbeat detection link connectivity status can confirm the availability of the communication link in advance, avoiding time losses caused by subsequent session establishment failures and improving the success rate of session establishment. Confirming media parameters through initial session protocol signaling interaction before establishing the communication link ensures media compatibility between the initiating terminal and the target device, avoiding audio transmission anomalies caused by parameter mismatches, ensuring smooth communication, and providing technical support for clear communication between medical staff and between doctors and patients.

[0012] As a preferred embodiment, after the target device and the initiating terminal establish a session initiation protocol communication link, the method further includes: Switch the User Datagram Protocol heartbeat to the Session Initiation Protocol heartbeat.

[0013] This preferred solution switches the User Datagram Protocol (UDP) heartbeat to the Session Initialization Protocol (SIP) heartbeat after the Session Initialization Protocol (SIP) communication link is established, achieving precise matching between the heartbeat detection mechanism and the communication link type. Compared to the common UDP heartbeat, the SIP heartbeat is more suited to the characteristics of the current communication link, enabling more accurate and real-time monitoring of link connectivity and timely detection of anomalies such as link interruptions and stuttering. This switch improves the accuracy and reliability of link status monitoring, reduces false positives or false negatives, ensures continuous and stable communication during the intercom process, avoids communication interruptions caused by untimely detection of link anomalies, and ensures the continuity of medical communication.

[0014] As a preferred embodiment, the event notification is reported in parallel using Message Queuing Telemetry Transport Protocol and User Datagram Protocol. The event notifications reported via the message queue telemetry transmission protocol are used by the central server to update the bed status and generate operation logs, while the event notifications reported via the user datagram protocol are used to synchronize call requests and terminal status data in multi-terminal scenarios.

[0015] This preferred solution employs a parallel reporting approach using both Message Queuing Telemetry (MQT) and User Datagram Protocol (UDP) for event notifications, achieving a division of labor and efficient complementarity in data transmission. The MQT focuses on updating bed status and generating operation logs, without consuming resources for transmitting call-related data, ensuring the integrity of status records and log retention. The UDP, on the other hand, focuses on synchronizing call requests and terminal status data in multi-terminal scenarios, leveraging its high transmission efficiency and low latency to ensure timely information synchronization in multi-device collaborative scenarios. This parallel operation improves system data processing efficiency and ensures the reliability of different types of data transmission, guaranteeing that medical staff can monitor bed status in real time while call requests are not delayed.

[0016] As a preferred embodiment, the audio data is acquired and played through an audio hardware adapter component during transmission, and the echo is eliminated in real time through an echo cancellation component.

[0017] This preferred solution achieves compatibility with different types of audio acquisition and playback devices by applying audio hardware adaptation components, improving the versatility of medical intercom terminals. It can adapt to the hardware differences of different terminals such as bedside units and ward units, reducing equipment adaptation costs. The echo cancellation component eliminates echoes in real time, effectively solving the problem of echo interference caused by audio feedback during intercom communication and significantly improving the clarity of audio communication. In medical settings, clear audio transmission is crucial for accurately conveying diagnostic and treatment information and nursing instructions. This design avoids information mishearing and misjudgment caused by echoes, ensuring the accuracy of doctor-patient communication and medical staff collaboration, and improving the quality of medical services.

[0018] As a preferred embodiment, the button events include signal interruptions and level changes caused by physical buttons and touch buttons, and the state change events include changes in the terminal's internal communication state, intercom state, and the device's own state.

[0019] This preferred solution clearly defines the specific types of button events and state change events, enabling the system to identify events more accurately and comprehensively, avoiding omissions or erroneous responses due to ambiguous event definitions. It clearly defines signal changes triggered by physical buttons and touch buttons, as well as changes in terminal communication, intercom, and its own state, allowing the system to develop differentiated processing strategies for different event types, improving the relevance and efficiency of event response. Comprehensive coverage of key event scenarios during terminal operation ensures the system can promptly capture abnormal terminal states and user operation needs, providing accurate event evidence for subsequent compliance verification, call establishment, and other processes, guaranteeing the stability and comprehensiveness of the medical intercom system's operation.

[0020] This application also provides a multi-protocol collaborative control device for medical intercom, suitable for a central server, including a notification module and a session module; The notification module is used to obtain event notifications reported by the initiating terminal when a key event or state change event occurs; wherein the initiating terminal is a bedside extension, a ward extension, or a preset extended device; The session module is configured to send a call request protocol to the target device if the event corresponding to the event notification conforms to a preset system rule and the target device corresponding to the event notification exists and is online, so that the target device establishes a session initialization protocol communication link with the initiating terminal based on the call request protocol; wherein, the session initialization protocol communication link is used to transmit audio data between the initiating terminal and the target device based on a preset intercom mechanism.

[0021] This application also provides a storage medium storing a computer program, which is called and executed by a computer to implement the multi-protocol collaborative control method for medical intercom as described above.

[0022] This application also provides a computer program product, including a computer program or instructions, which, when executed by a communication device, implements the multi-protocol collaborative control method for medical intercom as described above. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a multi-protocol collaborative control method for medical intercom provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a multi-protocol collaborative control device for medical intercom provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] In the description of this application, unless otherwise stated, "a number" means two or more.

[0026] The multi-protocol collaborative control method for medical intercom provided in this application aims to solve problems such as difficulty in device adaptation, single communication method, chaotic event processing logic, high status reporting delay, unstable intercom quality, and lack of automatic device type adaptation method in existing medical intercom systems.

[0027] Example 1: Please see Figure 1The embodiments of this application provide a multi-protocol collaborative control method for medical intercom, applicable to a central server, including S1~S4, and the specific implementation steps are as follows: S1. Obtain the event notification reported by the initiating terminal when a key event or state change event occurs; wherein, the initiating terminal is a bedside extension, a ward extension, or a preset extended device.

[0028] Step S1 in this embodiment includes S1.1 to S1.3, specifically as follows: S1.1. Clarify the equipment system involved in the medical intercom system, including two major categories: core terminal equipment and related equipment; among them, the "core terminal equipment" is the core execution subject of this invention, and its core attribute is the initiating terminal of the event and undertakes the core operation. At the same time, it can be used as the target device in multi-terminal scenarios. For example, when the bedside extension calls, the ward extension at the nurse station can be used as the target device to receive the call. Its unified software architecture and built-in modules are designed to support the initiating terminal function. The core terminal equipment is specifically divided into three categories: bedside extensions, ward extensions, and pre-installed expansion devices. Bedside extensions are designed for individual patients and are used for patients to call medical staff, receive nursing notifications, and communicate with the nurses' station. Ward extensions are designed for the entire ward, such as at the ward entrance or next to the nurses' station, and can receive calls from patients in the ward, broadcast notifications, and communicate with patients. Pre-installed expansion devices have reserved expansion capabilities and can be other types of terminals such as corridor extensions or doctor's office extensions. They can be adapted by simply modifying the configuration file without rewriting the software. The core terminal equipment adopts a completely unified software architecture, requiring no modification to the core program. Device type determination is achieved solely through configuration files, adapting to bedside extensions, ward extensions, and various extended devices. It incorporates five core functional modules that collaboratively support operation across all scenarios: ① Network communication module: used to execute three communication methods: MQTT (Message Queuing Telemetry Transport), HTTP (Hypertext Transfer Protocol), and UDP (User Datagram Protocol).

[0029] ② Intercom module: Based on libosip (Open SIP Stack Library), a SIP (Session Initiation Protocol) session is established. In conjunction with ALSA (Advanced Linux Sound Architecture) and AECM (Acoustic Echo Cancellation Module), audio acquisition, playback and echo cancellation are completed.

[0030] ③ Event Processing Module: This module includes an event receiving unit, an event judgment unit, and an event execution unit. It should be noted that the terminal of this invention, based on the event processing module, employs a unified event mechanism to handle various events, ensuring standardized and efficient processes. The event receiving unit is triggered from two sources: local events triggered by local button presses and server-sent events received via MQTT. Upon receiving an event, the event judgment unit immediately identifies and classifies its attributes, determining whether it belongs to a call, nursing, broadcast, or device control type, providing a basis for subsequent differentiated processing. Subsequently, the corresponding processing logic of the event execution unit is invoked, such as UI interface updates, sending status reports via MQTT / UDP, and initiating SIP link establishment. After the processing logic is executed, multi-channel result feedback is triggered, including sending processing status back to the central server via MQTT, synchronizing results with associated terminals via UDP, and displaying interface prompts on the local terminal, such as call success pop-ups and operation failure alarms. The entire event flow follows a closed-loop logic of "event reception → type judgment → action execution → result feedback → (optional) UI update," ensuring that each step of the operation is traceable and perceptible.

[0031] ④ Status reporting module: Used to report key events, device status, call status, etc. via MQTT and UDP.

[0032] ⑤ Graphical Interface Module: Based on LVGL (LittlevGL, a small visualization graphics library), it realizes component-based UI rendering with low performance consumption.

[0033] "Associated devices" are the collaborative objects of the initiating terminal, including the central server and target devices: The central server is responsible for receiving configuration parameters and status data reported by the terminal, issuing regional parameters, permission configurations, event notifications, and generating operation logs, and is the data hub of the entire system; the target device is the communication peer device in a multi-terminal scenario. For example, when a bedside extension calls, the ward extension at the nurse station is the target device; when a ward extension broadcasts, all bedside extensions in the ward are the target devices.

[0034] S1.2 Before the terminals involved in the equipment system are officially put into use, initial configuration must be completed. The specific process is as follows: After the terminal is powered on, an MQTT connection is established first based on the network communication module. If the connection is successful, local configuration parameters containing device ID, device type, room and bed information are sent to the central server. After receiving the server confirmation information, the login process is executed via HTTP to synchronously obtain area parameters, permission parameters and function configuration. Based on the server configuration, the UI interface settings are completed based on the graphical interface module, and the initial deployment of each functional module and intercom module is implemented to lay a solid foundation for the subsequent operation of terminal event processing, intercom communication and other functions. The "UI interface" refers to a low-performance, component-based interface implemented using LVGL, which can adapt to different equipment types such as bedside extensions and ward extensions. It can provide medical staff and patients with an intuitive operation entry and information display window, and support the operation of subsequent terminal functions such as event processing and intercom communication. Specifically, it includes displaying device status, event feedback, operation options, etc., to facilitate users to perform relevant operations and view information.

[0035] S1.3 The initiating terminal obtains key events or state change events through the event receiving unit; among them, "key events" include signal interruptions and level changes caused by physical keys and touch keys, and "state change events" include changes in functional modules such as the terminal's internal communication status, intercom status, and device status.

[0036] After a button press or state change event, the event judgment unit immediately identifies and classifies the event attributes to determine whether it belongs to the type of call, nursing, broadcast, or equipment control. The event notification containing the event type is then reported to the central server via MQTT and UDP in parallel, providing a basis for the central server to determine whether to start the intercom mechanism and select the communication method. Among them, the event notifications reported via MQTT are used by the central server to update the bed status and generate operation logs, while the event notifications reported via UDP are used to synchronize call requests and terminal status data in multi-terminal scenarios. Furthermore, the core data corresponding to "event type" is divided into four categories, and each category corresponds to a clear processing logic: ① Call event (call event): Requires the establishment of intercom communication, corresponding to the subsequent SIP link establishment and audio transmission process; ② Nursing events: No real-time intercom is required; only information synchronization is needed, which is accomplished via MQTT and UDP broadcast. ③ Broadcast events: Batch notifications to terminals in a specific area, such as a ward extension pushing a notification to the bedside extensions in the ward area; ④ Device control events: These involve the management and control of the terminal's own functional modules, such as device initialization, module start-up and shutdown, etc.

[0037] In this embodiment S1.3, the parallel reporting of event notifications using both the Message Queuing Telemetry Transport Protocol (MQTP) and the User Datagram Protocol (UDP) achieves a division of labor and efficient complementarity in data transmission. The MQTP focuses on updating bed status and generating operation logs, without consuming transmission resources for call-related data, ensuring the integrity of status records and log retention. The UDP, on the other hand, focuses on synchronizing call requests and terminal status data in multi-terminal scenarios, leveraging its high transmission efficiency and low latency to ensure timely information synchronization in multi-device collaborative scenarios. This parallel operation improves the efficiency of system data processing and ensures the reliability of different types of data transmission, ensuring that medical staff can monitor bed status in real time while call requests are not delayed. Furthermore, this embodiment clearly defines the specific types of button events and state change events, enabling the system to identify events more accurately and comprehensively, avoiding omissions or erroneous responses due to ambiguous event definitions. Clearly defining signal changes triggered by physical buttons and touch buttons, as well as changes in terminal communication, intercom, and its own state, allows the system to develop differentiated processing strategies for different event types, improving the relevance and efficiency of event response. Comprehensive coverage of key event scenarios during terminal operation ensures the system can promptly capture abnormal terminal states and user operation needs, providing accurate event evidence for subsequent compliance verification, call establishment, and other processes, guaranteeing the stability and comprehensiveness of the medical intercom system's operation.

[0038] S2. If the event notification corresponds to a pre-defined system rule, and the target device corresponding to the event notification exists and is online, a call request protocol is sent to the target device so that the target device can establish a session initiation protocol communication link with the initiating terminal based on the call request protocol; wherein, the session initiation protocol communication link is used to transmit audio data between the initiating terminal and the target device based on a pre-defined intercom mechanism.

[0039] Step S2 in this embodiment includes S2.1 to S2.3, specifically as follows: S2.1 After receiving the event notification, the central server compares and verifies the initiating terminal's permissions and event type with the preset system rules to obtain the event compliance verification result. The "preset system rules" are compliance verification standards pre-configured in the central server, centered around the matching relationship between initiating terminal permissions and event types. These rules determine whether the initiating terminal has the permission to initiate the corresponding event and specifically include terminal permission rules, event validity rules, and cross-regional or permission constraint rules: terminal permission rules clarify the event type restrictions that different types of terminals can initiate; event validity rules define the valid event types supported by the system; and cross-regional or permission constraint rules constrain the permission matching requirements between the initiating terminal and the target device.

[0040] Based on the target device identifier in the event notification, the device online status list is queried to obtain the determination result that the target device exists and is online; the “device online status list” is updated by device status data reported in real time by several terminals based on the status reporting module. If both the verification and judgment results are passed, the initiating terminal information, target device identifier, and event type in the event notification are lightweightly packaged based on UDP to generate a call request protocol, which is then sent to the target device. After the other end replies, the local device will store the other end's device information to facilitate subsequent communication.

[0041] In this embodiment, S2.1 compares and verifies the initiating terminal's permissions and event type with preset system rules to accurately filter compliant events, avoiding interference with system order from unauthorized calls or invalid operations, and ensuring the security and standardization of the medical intercom system's operation. By querying the target device's status based on a real-time updated list of online device statuses, invalid scenarios such as offline or non-existent devices can be eliminated in advance, reducing the transmission of useless call requests and lowering system resource consumption. The use of the User Datagram Protocol (UDP) to package key information and generate a call request protocol balances high data transmission efficiency and lightweight design, ensuring that call requests are quickly delivered to the target device, meeting the core requirement of timely response in medical scenarios and improving the timeliness of doctor-patient communication.

[0042] S2.2 After the target device receives the call request protocol, control the target device to extract the initiating terminal communication address and event type from the call request protocol, and combine the extracted data with the area parameters and permission parameters when the target device went online to verify the legality of the connection corresponding to the call request protocol. If the verification is successful, the target device initiates a session initiation protocol connection request containing media negotiation parameters to the initiating terminal based on the initiating terminal's communication address, and starts a UDP heartbeat to detect the link connectivity status between the target device and the initiating terminal. Among them, the "media negotiation parameters" are the core set of parameters carried by the target device when initiating a SIP connection request to the initiating terminal. They are used to agree on the unified rules for audio interaction between the two parties and ensure audio adaptation and compatibility during the intercom. Specifically, they include audio encoding and decoding formats, sampling rate, bit depth, audio transmission protocol and corresponding port, and also associate echo cancellation related adaptation configurations. Its core function is to keep the initiating terminal and the target device consistent in the audio acquisition, transmission, playback and echo processing stages, and ensure the audio quality and stability of the medical intercom.

[0043] When the link is connected, after the initiating terminal responds to the Session Initiation Protocol (SIP) connection request, the initiating terminal and the target device control each other to confirm media parameters via SIP signaling. After completing the interaction and confirmation of SIP signaling, a SIP communication link, namely the SIP communication link, is established. The "SIP signaling" is the control information transmitted between the initiating terminal and the target device during the establishment of the SIP communication link. Its core function is to interact and confirm media negotiation parameters, such as audio encoding format, sampling rate, transmission protocol, and port. Simultaneously, it facilitates the exchange of connection establishment commands, ensuring that both parties reach agreement on audio acquisition, transmission, playback, and echo processing, providing communication control support for subsequent stable medical intercom.

[0044] After the SIP communication link is successfully established, the UDP heartbeat is switched to the SIP heartbeat to continuously maintain the SIP communication link connectivity between the target device and the initiating terminal, and to coordinate with the subsequent intercom module to carry out full-process audio interaction.

[0045] In this embodiment, S2.2 verifies the legitimacy of the call request by combining the target device's own region and permission parameters, further strengthening the system's security defenses, preventing unauthorized connections, and ensuring the privacy and integrity of medical communication data. Activating the User Datagram Protocol (UDP) heartbeat detection link connectivity status can confirm the availability of the communication link in advance, avoiding time losses caused by subsequent session establishment failures and improving the success rate of session establishment. Confirming media parameters through initial session protocol signaling interaction before establishing the communication link ensures media compatibility between the initiating terminal and the target device, avoiding audio transmission anomalies caused by parameter mismatches, ensuring smooth intercom communication, and providing technical support for clear communication between medical staff and between doctors and patients. Furthermore, after the Session Initiation Protocol (SIP) communication link is established, the User Datagram Protocol (UDP) heartbeat is switched to the SIP heartbeat, achieving precise matching between the heartbeat detection mechanism and the communication link type. Compared to the general UDP heartbeat, the SIP heartbeat is more suited to the characteristics of the current communication link, enabling more accurate and real-time monitoring of link connectivity and timely detection of anomalies such as link interruptions and stuttering. This switch improves the accuracy and reliability of link status monitoring, reduces false positives or false negatives, ensures the continuous stability of the intercom process, avoids communication interruptions caused by untimely detection of link anomalies, and ensures the continuity of medical staff communication.

[0046] S2.3. The intercom mechanism is initiated based on the SIP communication link. The specific process is as follows: Based on the SIP communication link, the event execution unit calls the core logic of the intercom module, using libosip as technical support to ensure the stable continuation of the SIP session, and coordinates the entire audio interaction process between the initiating terminal and the target device; simultaneously, the ALSA (Audio Hardware Adapter) audio acquisition and playback function is started, and AECM (Echo Cancellation Component) technology is used to eliminate call echo in real time. At the same time, the UDP transmission process of audio data is fully controlled to ensure efficient data transmission; if the target device is detected to be offline, a constraint mechanism is automatically triggered to restrict related devices in the area from initiating invalid intercom requests, thus avoiding resource waste.

[0047] This embodiment, S2.3, achieves compatibility with different types of audio acquisition and playback devices by applying an audio hardware adaptation component. This improves the versatility of the medical intercom terminal, allowing it to adapt to the hardware differences of different terminals such as bedside extensions and ward extensions, thus reducing equipment adaptation costs. The echo cancellation component eliminates echoes in real time, effectively solving the problem of echo interference caused by audio feedback during intercom communication and significantly improving the clarity of audio communication. In medical settings, clear audio transmission is crucial for accurately conveying diagnostic and treatment information and nursing instructions. This design avoids information mishearing and misjudgment caused by echoes, ensuring the accuracy of doctor-patient communication and medical staff collaboration, and improving the quality of medical services.

[0048] It should be noted that the medical intercom terminal and its control method provided by this invention achieve a completely decoupled design by means of a unified software structure, configuration files to distinguish device types, LVGL component-based UI automatic loading and layout adaptation, unified core thread interface registration, and event-driven architecture. It is applicable to various medical intercom terminals, including current bedside extensions, ward extensions, and other types of terminals that can be expanded in the future, such as corridor extensions and doctor's office extensions. It can quickly adapt to the device requirements of different hardware models without rewriting the core program.

[0049] Overall, this embodiment has the following beneficial effects: At the device adaptation level, this invention adopts the Session Initiation Protocol (SIP) as a unified communication standard, covering diverse terminals such as bedside extensions, ward extensions, and pre-set extended devices. It abandons the fragmented development model of traditional systems where different types of devices require dedicated adaptation interfaces, achieving protocol-level compatibility for multi-device access. This significantly reduces the adaptation threshold for cross-vendor and cross-model devices, avoiding access failures or functional abnormalities caused by inconsistent interfaces. Simultaneously, through event notification and pre-set system rule matching verification, it can flexibly accommodate event reporting mechanisms of different devices, improving adaptation flexibility. At the response latency optimization level, after receiving an event notification, it prioritizes system rule matching and pre-verification of the target device's online status, filtering invalid requests in advance, avoiding resource waste, and ensuring priority processing of valid requests. Subsequently, it quickly establishes a direct communication link based on the SIP, eliminating the intermediate link of multi-node forwarding in traditional systems. Furthermore, by controlling audio data transmission, it ensures the interactive coordination between the initiating terminal and the target device, shortening the entire process time from event triggering to intercom initiation, effectively reducing response latency and solving the latency pain point in real-time intercom scenarios. In summary, this invention not only achieves automatic multi-terminal adaptation through configuration files, decoupling software and hardware and significantly reducing software adaptation costs, but also allows for rapid deployment of new devices without rewriting programs, requiring only configuration modifications, resulting in highly scalable systems. Furthermore, it employs a multi-protocol collaborative communication mechanism using MQTT, HTTP, UDP, and SIP, significantly improving communication efficiency and stability in real-time medical scenarios. Simultaneously, relying on the low-latency mechanism of parallel reporting via MQTT and UDP, it enables near real-time responses to nursing care, calls, and other events. A unified event processing flow enables centralized management of various events, making the logic clearer and reducing management costs. Stable audio processing is achieved using ALSA and AECM technologies, ensuring intercom quality and enhancing multi-device compatibility. In addition, the LVGL-based component-based UI mechanism supports adaptation to different screen sizes and low-performance chips, enabling flexible UI updates and significant performance optimization, comprehensively addressing many pain points of existing technologies.

[0050] Example 2: Please see Figure 2 The embodiments of this application provide a multi-protocol collaborative control device for medical intercom, which is suitable for a central server and includes a notification module 10 and a session module 20; The notification module 10 is used to obtain event notifications reported by the initiating terminal when a key event or state change event occurs; wherein the initiating terminal is a bedside extension, a ward extension, or a preset extended device. The session module 20 is used to send a call request protocol to the target device if the event corresponding to the event notification conforms to the preset system rules and the target device corresponding to the event notification exists and is online, so that the target device can establish a session initialization protocol communication link with the initiating terminal based on the call request protocol; wherein, the session initialization protocol communication link is used to transmit audio data between the initiating terminal and the target device based on a preset intercom mechanism.

[0051] It should be noted that the technical concept of this second embodiment is completely consistent with that of the first embodiment. The two maintain a high degree of synergy at the technical logic level. The specific technical details can be referred to the relevant description of the first embodiment, which will not be repeated here.

[0052] Example 3: This application provides a computer-readable storage medium, which includes a stored computer program, wherein the computer program controls the device where the computer-readable storage medium is located to execute the aforementioned multi-protocol collaborative control method for medical intercom when it is running. The multi-protocol collaborative control method for medical intercom, when implemented as a software functional unit and used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0053] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0054] The above are preferred embodiments of the present invention. It should be noted that, for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A multi-protocol collaborative control method for medical staff intercom, characterized in that, Applicable to central servers, including: Receive event notifications reported by the initiating terminal when a key event or state change event occurs; wherein, the initiating terminal is a bedside extension, a ward extension, or a preset extended device; If the event notification corresponds to an event that conforms to a preset system rule, and the target device corresponding to the event notification exists and is online, then a call request protocol is sent to the target device so that the target device can establish a session initiation protocol communication link with the initiating terminal based on the call request protocol; wherein, the session initiation protocol communication link is used to transmit audio data between the initiating terminal and the target device based on a preset intercom mechanism.

2. The multi-protocol collaborative control method for medical intercom as described in claim 1, characterized in that, If the event corresponding to the event notification conforms to preset system rules, and the target device corresponding to the event notification exists and is online, then a call request protocol is sent to the target device, specifically: The initiating terminal permissions and event type in the event notification are compared and verified with the preset system rules to obtain the event compliance verification result; Based on the target device identifier in the event notification, the device online status list is queried to obtain a determination result that the target device exists and is online; wherein, the device online status list is updated by device status data reported in real time by several terminals; If both the verification result and the determination result are passed, the initiating terminal information, the target device identifier, and the event type in the event notification are packaged based on the User Datagram Protocol (UDP) to generate the call request protocol, and the call request protocol is sent to the target device.

3. The multi-protocol collaborative control method for medical intercom as described in claim 1, characterized in that, Specifically, the target device establishes a session initiation protocol communication link with the initiating terminal based on the call request protocol, which involves: The target device is controlled to receive the call request protocol and extract the initiating terminal communication address and event type. Combined with the extracted data and the area parameters and permission parameters of the target device when it goes online, the legitimacy of the connection corresponding to the call request protocol is verified. If the verification is successful, the target device is controlled to initiate a Session Initiation Protocol (SIP) connection request containing media negotiation parameters to the initiating terminal based on the initiating terminal's communication address, and a User Datagram Protocol (UDP) heartbeat is initiated to detect the link connectivity status between the target device and the initiating terminal. When the link connectivity is established, after the initiating terminal responds to the Session Initiation Protocol (SIP) connection request, the initiating terminal and the target device are controlled to interact and confirm media parameters through SIP signaling. After the interaction and confirmation of SIP signaling are completed, the SIP communication link is established.

4. The multi-protocol collaborative control method for medical intercom as described in claim 3, characterized in that, After the target device and the initiating terminal establish a session initiation protocol communication link, the method further includes: Switch the User Datagram Protocol heartbeat to the Session Initiation Protocol heartbeat.

5. The multi-protocol collaborative control method for medical intercom as described in claim 1, characterized in that, The event notification is reported in parallel using Message Queuing Telemetry Transport Protocol and User Datagram Protocol. The event notifications reported via the message queue telemetry transmission protocol are used by the central server to update the bed status and generate operation logs, while the event notifications reported via the user datagram protocol are used to synchronize call requests and terminal status data in multi-terminal scenarios.

6. The multi-protocol collaborative control method for medical intercom as described in claim 1, characterized in that, During transmission, the audio data is acquired and played through an audio hardware adapter component, and echo is eliminated in real time through an echo cancellation component.

7. The multi-protocol collaborative control method for medical intercom as described in claim 1, characterized in that, The button events include signal interruptions and level changes caused by physical buttons and touch buttons, and the state change events include changes in the terminal's internal communication state, intercom state, and device state.

8. A multi-protocol collaborative control device for medical intercom, characterized in that, Suitable for central servers, including notification and session modules; The notification module is used to obtain event notifications reported by the initiating terminal when a key event or state change event occurs; wherein the initiating terminal is a bedside extension, a ward extension, or a preset extended device; The session module is configured to send a call request protocol to the target device if the event corresponding to the event notification conforms to a preset system rule and the target device corresponding to the event notification exists and is online, so that the target device establishes a session initialization protocol communication link with the initiating terminal based on the call request protocol; wherein, the session initialization protocol communication link is used to transmit audio data between the initiating terminal and the target device based on a preset intercom mechanism.

9. A storage medium, characterized in that, The storage medium stores a computer program, which is called and executed by a computer to implement a multi-protocol collaborative control method for medical intercom as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the communication device, they implement a multi-protocol collaborative control method for medical intercom as described in any one of claims 1 to 7.

Images