SIP (Session Initiation Protocol) talkback event semantic arrangement and multi-terminal consistency presentation method and system

Abstract

The invention discloses an SIP (Session Initiation Protocol) talkback event semantic arrangement and multi-terminal consistency presentation method and system, and the method comprises the following steps: S1, initialization: a client completes SIP registration and WebSocket connection, and loads built-in semantic mapping and throttling parameters; s2, collecting and normalizing: unifying the original events generated by the four ends into a standard event object, and attaching a minimum context; through the design of event normalization, built-in semantic mapping, WebSocket real-time synchronization, time window de-duplication and abnormal cooling, off-line reissuing, manual queue state triggering, operation trace leaving and the like, on the premise that a rear end and an intercom base are not transformed, multi-terminal information collaborative and consistent presentation is achieved, time sequence drift and understanding deviation are eliminated, the coupling and transformation cost is reduced, and the system performance is improved. The display stability under the weak network is optimized, audit tracing is perfected, and finally the doctor-seeing order, the communication efficiency and the patient experience are improved.

Description

Technical Field

[0001] This invention relates to the field of smart clinic technology, and in particular to a method and system for semantic orchestration of SIP intercom events and consistent presentation across multiple terminals. Background Technology

[0002] In hospital outpatient, pharmacy, medical technology, and triage services, queuing and calling systems are responsible for maintaining queue entries and status, while SIP intercom systems handle voice communication between medical staff and triage equipment. Current IT practices often involve separate construction and loose integration. With increasing patient volume and the number of devices, traditional solutions are gradually revealing their shortcomings in efficiency, accuracy, and real-time monitoring, making it difficult to meet hospitals' actual needs for safe, orderly patient care and continuous communication. The specific deficiencies of traditional solutions are as follows: (1) Information silos: Calling and intercom often come from different manufacturers or subsystems, and the models, interfaces and terminology are not consistent. Communication events such as "ringing / connecting / hanging up / busy line / no answer" that occur on the intercom side are difficult for the calling side to understand and utilize in a timely and equivalent manner. At the same time, the business status of the calling side such as "calling / processing / completed / passed" is not presented in a consistent manner to the communication side. This fragmentation leads to asynchronous prompts from various terminals (doctor's end, triage desk, caller and large screen), affecting patient diversion and on-site order. (2) Lack of "event-level" real-time presentation capability: Traditional integrations mostly remain at the level of "page refresh or polling", and the instantaneous nature and contextual semantics of intercom events cannot be visualized with low latency and uniformity on multiple terminals; (3) Inconsistent semantics of communication events: For the same "missed / busy / cancelled" status codes, different terminals and different implementation branches may output inconsistent status codes and prompts; the wording, icons and levels of the same event are also inconsistent on different pages, which causes medical staff and patients to have inconsistent understanding of the on-site status, increasing the cost of explanation and the burden of secondary communication. (4) Insufficient adaptation to weak network environment: The hospital's intranet or wireless coverage is not always stable. Some terminals may experience temporary offline, jitter, late messages, etc. Traditional solutions lack the design for degradation and compensation in weak network scenarios (such as local perceptible prompts during offline periods and status resending after reconnection), resulting in asynchronous display of multiple terminals, lost prompts or frequent changes, and poor user experience. (5) High coupling and high transformation cost: In pursuit of "automation", some practices attempt to write communication events directly back to the backend queue system, but this usually brings strong coupling, cross-system consistency and process compliance risks; once business rules or communication stack are upgraded, the transformation scope is wide, the testing cost is high, and the stability is difficult to guarantee; most hospitals therefore revert to "weak integration", and the problem cannot be solved for a long time. (6) The complexity of multiple terminals is difficult to manage: In real-world scenarios, multiple devices such as Windows doctor terminal, Windows nurse terminal triage station, Android call number device, Android triage station, call number screen / large screen coexist. The UI form, network conditions and interaction rhythm are different. Traditional solutions lack a consistent arrangement and presentation mechanism for multiple terminals. The handling of terminal differences is scattered in their respective codes, making maintenance difficult and behavior inconsistent. (7) Insufficient audit and process traceability: There is a lack of structured and reviewable link records between the occurrence and prompt presentation of intercom events and the manual operations of medical staff (such as "call again / next person / passed number / completed"). When disputes occur on site or experience problems need to be reviewed, we often have to rely on scattered logs or manual recollection, which makes it difficult to form an effective improvement loop. In summary, this application proposes a method and system for SIP intercom event semantic orchestration and multi-terminal consistent presentation. Summary of the Invention

[0003] Based on the technical problems existing in the background technology, this invention proposes a method and system for SIP intercom event semantic orchestration and multi-terminal consistent presentation.

[0004] The SIP intercom event semantic orchestration and multi-terminal consistent presentation method proposed in this invention includes the following steps: S1: Initialization: The client completes SIP registration and WebSocket connection, and loads built-in semantic mapping and throttling parameters; S2: Acquisition and Normalization: Unify the raw events generated by the four terminals into standard event objects, with a minimal context; S3: Semantic Orchestration: Generate prompt semantics based on built-in semantic mapping; deduplicate equivalent events within a 2-5 second time window; apply a 10-30 second cooldown to high-frequency anomaly prompts; S4: Synchronous presentation: The "prompt semantics + queue status" are synchronized to the server via WebSocket, and the subscription terminals are refreshed uniformly through the five terminals. Terminals that are offline for a short time can resend the message after reconnection or poll as needed. S5: Manual Operation and Audit: Medical staff can change the queue status and report the record by pressing a button. The system retains the necessary time and source information for quality control and review.

[0005] Preferably, in S2, the four terminals include a Windows doctor terminal, a Windows nurse terminal triage station, an Android queuing system, and an Android triage station.

[0006] Preferably, in S2, the minimum context includes a window / seat identifier, a peer identifier, and a timestamp.

[0007] Preferably, in S4, the five-terminal display subscription terminal includes a Windows doctor terminal, a Windows nurse terminal triage desk, an Android caller, an Android triage desk, and a large caller screen.

[0008] This invention also proposes a SIP intercom event semantic orchestration and multi-terminal consistent presentation system, including an event acquisition and normalization module, a semantic orchestration module, a synchronization and consistent presentation module, and a user interface and operation module; The event acquisition and normalization module is used to access four-terminal intercom events and unify them into a fixed set, which includes RINGING, CONNECTED, TERMINATED, CANCELED, TIMEOUT, and BUSY. The semantic orchestration module uses built-in code mapping to convert standard events into prompt semantics, and performs time window deduplication and cooling to stabilize the visual experience; The synchronization and consistent presentation module is synchronized to the server via WebSocket and refreshed by the doctor's / nurse's / Android / queue screen subscription client; The user interface and operation module are used to provide an intercom window and manual buttons for "Next / Recall / Missed Number / Follow-up Visit / Complete", and to record and report operation data.

[0009] Preferably, the operating logic of the event acquisition and normalization module is as follows: (1) It is compatible with both outbound and incoming call paths and can access the original intercom events of four terminals: Windows doctor terminal, Windows nurse terminal triage station, Android caller, and Android triage station. (2) The outbound caller performs an "invite-reply" handshake through SIPMESSAGE. The caller sends / special / talk / invite, the called party replies / special / talk / invite / back, and the caller waits for 30 seconds with TaskCompletionSource. (3) If no reply is received or the call is not entered during the waiting period, it is determined that the ringing timeout has occurred. CancelCall() is called and / special / talk / end is sent to end the process; the incoming caller supports INVITE to formally establish the chain, and at the same time, the MESSAGE invitation branch sent by the other end is parsed and / invite / back is replied. (4) Process the incoming call MESSAGE body with HtmlDecode+XmlDocument.LoadXml, then convert it to JSON via SerializeXmlNode, and parse the params.call_info field to get the description. If it is empty, fall back to the FromURI. (5) Use custom callId / cid to distinguish sessions, and use SipState to drive UI scene switching. When an invitation with a different cid is received during a call, send / special / talk / end to discard the subsequent session; (6) Unify all raw events into a fixed standard set: RINGING, CONNECTED, TERMINATED, CANCELED, TIMEOUT, BUSY, with a minimum context including window / seat identifier, peer identifier, and timestamp, and output the normalized events.

[0010] Preferably, the operating logic of the semantic orchestration module is as follows: (1) Normalized events output by the input event acquisition and normalization module: (2) Read the built-in semantic mapping rules and convert the normalized standard events into unified and readable prompt semantics; (3) Activate the time window deduplication mechanism. Within 2-5 seconds, prompts with the same semantics are only retained once to avoid flashing on multiple devices; (4) Set a 10-30 second cooling period for the high-frequency abnormal prompts of "busy line / no answer" to reduce noise; (5) Generate the final prompt semantics to ensure that different terminals express the same event in a completely consistent manner.

[0011] Preferably, the operating logic of the synchronization and consistent presentation module is as follows: (1) The client collects the "final prompt semantics + queue status triggered manually by medical staff" and synchronizes it to the server via WebSocket; (2) The server broadcasts the synchronized data to all subscribed terminals according to the department / window dimension; (3) The call number screen / large screen only displays the prompt semantics and queue status, and does not display the intercom window; the other four terminals refresh the corresponding prompt information synchronously; (4) Detect the terminal network status. If the terminal is offline for a short time, the server will resend incremental data according to the timestamp after reconnection, or the terminal will retrieve the data through periodic polling to ensure that the final display of multiple terminals is consistent.

[0012] Preferably, the operating logic of the user interface and operation module is as follows: (1) Display the intercom window on the four-terminal intercom device and provide "answer / reject / cancel / end" communication operation buttons; (2) Provide queue operation buttons for "Next / Recall / Missed Number / Follow-up Visit / Completed", which can be manually triggered by medical staff to change the queue status; (3) Record all manual operation behaviors, report operation records through existing interfaces, and do not write back to the backend queue system throughout the process; (4) Synchronize the queue status triggered by manual operation to the synchronization module and push it to the server along with the prompt semantics. At the same time, the subscription end refreshes the data in a unified manner to realize the linkage presentation of operation and status.

[0013] Compared with existing technologies, the beneficial effects of this invention are: 1. By using "event normalization + WebSocket synchronization", communication events such as "ringing / connection / busy line" on the intercom side and business statuses such as "calling / processing / passed number" on the queuing side are integrated and synchronized to all terminals such as the doctor's end, triage desk, queuing device, and large screen. This avoids the fragmented scenario of "no one answers the intercom but the large screen still shows the window", ensuring patient triage and on-site order, breaking down information silos, and realizing multi-terminal information collaboration. 2. WebSocket is used to synchronize "prompt semantics + queue status" in real time, and offline reconnection and resending and polling fallback mechanisms are used to ensure that after an intercom event (such as "busy line" or "cancelled") occurs, multiple terminals refresh with low latency, eliminate erroneous guidance, improve the timeliness of on-site status perception, and solve the problem that traditional "page refresh / polling" cannot capture the instantaneous nature of intercom events and cause time sequence drift. 3. By using "standard event set (RINGING / CONNECTED, etc.) + built-in semantic mapping", communication events are converted into unified and readable prompts such as "calling in progress / no answer / call ended", eliminating the misunderstanding of status between medical staff and patients, reducing the burden of explanation and secondary communication, and solving the problem of inconsistent status codes, prompt text and icons for the same event (such as "missed call") on different terminals in traditional solutions; 4. By designing a "short-term offline local keep-alive + incremental resending after reconnection" mechanism, and suppressing flickering and frequent jumps through a "2-5 second deduplication time window + 10-30 second abnormal cooling", even if the hospital's intranet fluctuates, it can still ensure consistent display across multiple terminals, improve the user experience, and solve the problems of terminal offline, message loss, and display jumps under weak network conditions in traditional solutions. 5. By focusing the complexity on the client-side semantic governance and synchronization layer, deployment can be carried out by upgrading only the client without modifying the backend queuing system and intercom base; and the queue status is triggered by a manual button by medical staff, avoiding cross-system compliance risks, with fast deployment, low testing costs, and easy rollback, solving the hospital's "weak integration" dilemma. 6. By constructing a unified orchestration mechanism of "four-terminal intercom (doctor / nurse / Android caller / Android triage station) + five-terminal display (including large screen)," the terminal difference processing is integrated into the client module, replacing the scattered code logic, reducing maintenance costs, ensuring the consistency of behavior of different terminal forms, and solving the problem of scattered and difficult maintenance of multi-terminal (Windows / Android devices, large screen) difference processing in traditional solutions. 7. By storing structured records such as timestamps and source identifiers (excluding sensitive data) for "medical staff manual operations (redial / next person / missed number)" and "event synchronization process", it is convenient for in-hospital quality control, dispute tracing and experience problem review, forming a closed loop of "problem discovery-tracing-improvement", which helps continuous optimization and solves the problem of traditional solutions lacking structured records of intercom events and manual operations and making it difficult to review disputes; This invention achieves multi-terminal information collaboration and consistent presentation without modifying the backend and intercom base, through designs such as event normalization, built-in semantic mapping, WebSocket real-time synchronization, time window deduplication and anomaly cooling, offline resending, manual triggering of queue status and operation logging. It eliminates time drift and misunderstanding, reduces coupling and modification costs, optimizes display stability under weak network conditions, improves audit traceability, and ultimately enhances medical order, communication efficiency and patient experience. Attached Figure Description

[0014] Figure 1 The flowchart shows the SIP intercom event semantic orchestration and multi-terminal consistent presentation method proposed in this invention. Figure 2 This is a block diagram of the SIP intercom event semantic orchestration and multi-terminal consistent presentation system proposed in this invention; Figure 3 This is a flowchart illustrating the operational logic of the event acquisition and normalization module in the SIP intercom event semantic orchestration and multi-terminal consistent presentation system proposed in this invention. Figure 4 This is a flowchart illustrating the operational logic of the semantic orchestration module in the SIP intercom event semantic orchestration and multi-terminal consistent presentation system proposed in this invention. Figure 5 This is a flowchart illustrating the operational logic of the synchronization and consistency presentation module in the SIP intercom event semantic orchestration and multi-terminal consistent presentation system proposed in this invention. Figure 6 This is a flowchart illustrating the operational logic of the user interface and operation modules in the SIP intercom event semantic orchestration and multi-terminal consistent presentation system proposed in this invention. Detailed Implementation

[0015] The present invention will be further explained below with reference to specific embodiments.

[0016] Example Reference Figure 1-6 This embodiment proposes a method for SIP intercom event semantic orchestration and multi-terminal consistent presentation, including the following steps: S1: Initialization: The client completes SIP registration and WebSocket connection, and loads built-in semantic mapping and throttling parameters; S2: Collection and Normalization: Unify the raw events generated by the four terminals into standard event objects with a minimum context. The four terminals include the Windows doctor terminal, the Windows nurse terminal triage desk, the Android caller, and the Android triage desk. The minimum context includes the window / seat identifier, the peer identifier, and the timestamp. S3: Semantic Orchestration: Generate prompt semantics based on built-in semantic mapping; deduplicate equivalent events within a 2-5 second time window; apply a 10-30 second cooldown to high-frequency anomaly prompts; S4: Synchronous presentation: The "prompt semantics + queue status" are synchronized to the server via WebSocket and refreshed uniformly through the five terminal display subscription terminals. Terminals that are offline for a short time can resend the message after reconnection or poll as needed. The five terminal display subscription terminals include the Windows doctor terminal, the Windows nurse terminal triage desk, the Android call number device, the Android triage desk, and the call number screen. S5: Manual Operation and Audit: Medical staff can change the queue status and report the record by pressing a button. The system retains the necessary time and source information for quality control and review.

[0017] This embodiment also proposes a SIP intercom event semantic orchestration and multi-terminal consistent presentation system, including an event acquisition and normalization module, a semantic orchestration module, a synchronization and consistent presentation module, and a user interface and operation module. The event acquisition and normalization module is used to access four-terminal intercom events and unify them into a fixed set, which includes RINGING, CONNECTED, TERMINATED, CANCELED, TIMEOUT, and BUSY. The operation logic of the event acquisition and normalization module is as follows: (1) It is compatible with both outbound and incoming call paths and can access the original intercom events of four terminals: Windows doctor terminal, Windows nurse terminal triage station, Android caller, and Android triage station. (2) The outbound caller performs an "invite-reply" handshake through SIPMESSAGE. The caller sends / special / talk / invite, the called party replies / special / talk / invite / back, and the caller waits for 30 seconds with TaskCompletionSource. (3) If no reply is received or the call is not entered during the waiting period, it is determined that the ringing timeout has occurred. CancelCall() is called and / special / talk / end is sent to end the process; the incoming caller supports INVITE to formally establish the chain, and at the same time, the MESSAGE invitation branch sent by the other end is parsed and / invite / back is replied. (4) Process the incoming call MESSAGE body with HtmlDecode+XmlDocument.LoadXml, then convert it to JSON via SerializeXmlNode, and parse the params.call_info field to get the description. If it is empty, fall back to the FromURI. (5) Use custom callId / cid to distinguish sessions, and use SipState to drive UI scene switching. When an invitation with a different cid is received during a call, send / special / talk / end to discard the subsequent session; (6) Unify all raw events into a fixed set of standards: RINGING, CONNECTED, TERMINATED, CANCELED, TIMEOUT, BUSY, and attach a minimum context of window / seat identifier, peer identifier, and timestamp, and output the normalized events; The semantic orchestration module uses built-in code mapping to convert standard events into prompt semantics, and performs time window deduplication and cooling to stabilize the visual experience; The semantic orchestration module operates as follows: (1) Normalized events output by the input event acquisition and normalization module: (2) Read the built-in semantic mapping rules and convert the normalized standard events into unified and readable prompt semantics; (3) Activate the time window deduplication mechanism. Within 2-5 seconds, prompts with the same semantics are only retained once to avoid flashing on multiple devices; (4) Set a 10-30 second cooling period for the high-frequency abnormal prompts of "busy line / no answer" to reduce noise; (5) Generate the final prompt semantics to ensure that the description of the same event is completely consistent across different terminals; The synchronization and consistent presentation module is synchronized to the server via WebSocket and refreshed by the doctor's / nurse's / Android / queue screen subscription client; The operating logic of the synchronization and consistent presentation module is as follows: (1) The client collects the "final prompt semantics + queue status triggered manually by medical staff" and synchronizes it to the server via WebSocket; (2) The server broadcasts the synchronized data to all subscribed terminals according to the department / window dimension; (3) The call number screen / large screen only displays the prompt semantics and queue status, and does not display the intercom window; the other four terminals refresh the corresponding prompt information synchronously; (4) Detect the terminal network status. If the terminal is offline for a short time, the server will resend incremental data according to the timestamp after reconnection, or the terminal will retrieve the data through periodic polling to ensure that the final display of multiple terminals is consistent. The user interface and operation module provide an intercom window and manual buttons for "Next / Recall / Missed Number / Follow-up Visit / Complete", and record and report operation data. The operating logic of the user interface and operation modules is as follows: (1) Display the intercom window on the four-terminal intercom device and provide "answer / reject / cancel / end" communication operation buttons; (2) Provide queue operation buttons for "Next / Recall / Missed Number / Follow-up Visit / Completed", which can be manually triggered by medical staff to change the queue status; (3) Record all manual operation behaviors, report operation records through existing interfaces, and do not write back to the backend queue system throughout the process; (4) Synchronize the queue status triggered by manual operation to the synchronization module and push it to the server along with the prompt semantics. At the same time, the subscription end refreshes the data in a unified manner to realize the linkage presentation of operation and status. This embodiment achieves multi-terminal information collaboration and consistent presentation without modifying the backend and intercom base, through designs such as event normalization, built-in semantic mapping, WebSocket real-time synchronization, time window deduplication and anomaly cooling, offline resending, manual triggering of queue status and operation logging. It eliminates time drift and misunderstanding, reduces coupling and modification costs, optimizes display stability under weak network conditions, improves audit traceability, and ultimately enhances the order of medical treatment, communication efficiency and patient experience.

[0018] The above are merely preferred embodiments of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for semantic orchestration of SIP intercom events and consistent presentation across multiple terminals, characterized in that, Includes the following steps: S1: Initialization: The client completes SIP registration and WebSocket connection, and loads built-in semantic mapping and throttling parameters; S2: Acquisition and Normalization: Unify the raw events generated by the four terminals into standard event objects, with a minimal context; S3: Semantic Orchestration: Generate prompt semantics based on built-in semantic mapping; deduplicate equivalent events within a 2-5 second time window; apply a 10-30 second cooldown to high-frequency anomaly prompts; S4: Synchronous presentation: The "prompt semantics + queue status" are synchronized to the server via WebSocket, and the subscription terminals are refreshed uniformly through the five terminals. Terminals that are offline for a short time can resend the message after reconnection or poll as needed. S5: Manual Operation and Audit: Medical staff can change the queue status and report the record by pressing a button. The system retains the necessary time and source information for quality control and review.

2. The SIP intercom event semantic orchestration and multi-terminal consistent presentation method according to claim 1, characterized in that, In S2, the four terminals include a Windows doctor terminal, a Windows nurse terminal triage station, an Android queuing system, and an Android triage station.

3. The SIP intercom event semantic orchestration and multi-terminal consistent presentation method according to claim 1, characterized in that, In S2, the minimum context includes the window / seat identifier, the peer identifier, and the timestamp.

4. The SIP intercom event semantic orchestration and multi-terminal consistent presentation method according to claim 1, characterized in that, In S4, the five-terminal display subscription terminal includes a Windows doctor terminal, a Windows nurse terminal triage desk, an Android caller, an Android triage desk, and a large caller screen.

5. A SIP intercom event semantic orchestration and multi-terminal consistent presentation system, used to implement the method described in any one of claims 1-4, characterized in that, It includes an event acquisition and normalization module, a semantic orchestration module, a synchronization and consistent presentation module, and a user interface and operation module; The event acquisition and normalization module is used to access four-terminal intercom events and unify them into a fixed set, which includes RINGING, CONNECTED, TERMINATED, CANCELED, TIMEOUT, and BUSY. The semantic orchestration module uses built-in code mapping to convert standard events into prompt semantics, and performs time window deduplication and cooling to stabilize the visual experience; The synchronization and consistent presentation module is synchronized to the server via WebSocket and refreshed by the doctor's / nurse's / Android / queue screen subscription client; The user interface and operation module are used to provide an intercom window and manual buttons for "Next / Recall / Missed Number / Follow-up Visit / Complete", and to record and report operation data.

6. The SIP intercom event semantic orchestration and multi-terminal consistent presentation system according to claim 5, characterized in that, The operation logic of the event acquisition and normalization module is as follows: (1) It is compatible with both outbound and incoming call paths and can access the original intercom events of four terminals: Windows doctor terminal, Windows nurse terminal triage station, Android caller, and Android triage station. (2) The outbound caller performs an "invite-reply" handshake through SIPMESSAGE. The caller sends / special / talk / invite, the called party replies / special / talk / invite / back, and the caller waits for 30 seconds with TaskCompletionSource. (3) If no reply is received or the call is not entered during the waiting period, it is determined that the ringing timeout has occurred. CancelCall() is called and / special / talk / end is sent to end the process; the incoming caller supports INVITE to formally establish the chain, and at the same time, the MESSAGE invitation branch sent by the other end is parsed and / invite / back is replied. (4) Process the incoming call MESSAGE body with HtmlDecode+XmlDocument.LoadXml, then convert it to JSON via SerializeXmlNode, and parse the params.call_info field to get the description. If it is empty, fall back to the FromURI. (5) Use custom callId / cid to distinguish sessions, and use SipState to drive UI scene switching. When an invitation with a different cid is received during a call, send / special / talk / end to discard the subsequent session; (6) Unify all raw events into a fixed standard set: RINGING, CONNECTED, TERMINATED, CANCELED, TIMEOUT, BUSY, with a minimum context including window / seat identifier, peer identifier, and timestamp, and output the normalized events.

7. The SIP intercom event semantic orchestration and multi-terminal consistent presentation system according to claim 5, characterized in that, The operating logic of the semantic orchestration module is as follows: (1) Normalized events output by the input event acquisition and normalization module: (2) Read the built-in semantic mapping rules and convert the normalized standard events into unified and readable prompt semantics; (3) Activate the time window deduplication mechanism. Within 2-5 seconds, prompts with the same semantics are only retained once to avoid flashing on multiple devices; (4) Set a 10-30 second cooling period for the "busy line / no answer" high-frequency abnormal prompts to reduce noise; (5) Generate the final prompt semantics to ensure that different terminals express the same event in a completely consistent manner.

8. The SIP intercom event semantic orchestration and multi-terminal consistent presentation system according to claim 5, characterized in that, The operating logic of the synchronization and consistent presentation module is as follows: (1) The client collects the "final prompt semantics + queue status triggered manually by medical staff" and synchronizes it to the server via WebSocket; (2) The server broadcasts the synchronized data to all subscribed terminals according to the department / window dimension; (3) The call number screen / large screen only displays the prompt semantics and queue status, and does not display the intercom window; the other four terminals refresh the corresponding prompt information synchronously; (4) Detect the terminal network status. If the terminal is offline for a short time, the server will resend incremental data according to the timestamp after reconnection, or the terminal will retrieve the data through periodic polling to ensure that the final display of multiple terminals is consistent.

9. The SIP intercom event semantic orchestration and multi-terminal consistent presentation system according to claim 5, characterized in that, The operating logic of the user interface and operation module is as follows: (1) Display the intercom window on the four-terminal intercom device and provide "answer / reject / cancel / end" communication operation buttons; (2) Provide queue operation buttons for "Next / Recall / Missed Number / Follow-up Visit / Completed", which can be manually triggered by medical staff to change the queue status; (3) Record all manual operation behaviors, report operation records through existing interfaces, and do not write back to the backend queue system throughout the process; (4) Synchronize the queue status triggered by manual operation to the synchronization module and push it to the server along with the prompt semantics. At the same time, the subscription end refreshes the data in a unified manner to realize the linkage presentation of operation and status.

Images