Doctor-patient calling method, device, equipment and medium

Abstract

The invention relates to the technical field of doctor-patient calling, and discloses a doctor-patient calling method and device, equipment and a medium, and the method comprises the steps: monitoring the communication state of a central server; wherein the central server is in communication connection with call initiating equipment and call receiving equipment in a doctor-patient area; under the condition that the communication state is normal, the central server receives a first call request triggered by the call initiating device and monitors the online state of the call receiving device; when the online state is offline, the central server triggers first call failure information and returns the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the standby signaling server; and under the condition that the communication state is abnormal, the call initiating device sends a second call request to the call receiving device through the standby signaling server. The method has the beneficial effects that the dependence of a single server is reduced, and the fault-tolerant capability and the stability are improved.

Description

Technical Field

[0001] The present application relates to the field of doctor-patient calling technology, and in particular to a doctor-patient calling method, device, equipment and medium. Background Art

[0002] Traditional bedside call systems use a centralized architecture, with the central server responsible for signaling exchange and forwarding audio and video calls. The patient-side device (such as the bedside extension) initiates a request for help, and the signal is forwarded to the medical-side device (such as the nurse station host) through the central server. The medical-side device answers the call and establishes a call with the patient based on the situation. Other display terminals (such as large TV screens and corridor screens) display patient call information in real time to help medical staff respond in a timely manner. The central server also monitors the status of the device to ensure the normal operation of the system.

[0003] However, the current disadvantage is that it is highly dependent on the central server and there is a risk of single point failure. If there is a problem with the server, the signaling transmission and emergency response of the entire system will be affected. Summary of the invention

[0004] The present application provides a doctor-patient calling method, device, equipment and medium, which solves the technical problem of high dependence on a central server and the risk of single point failure, and achieves the technical effect of reducing dependence on a single server and improving fault tolerance and stability.

[0005] In order to achieve the above objectives, the main technical solutions adopted in this application include: In a first aspect, an embodiment of the present application provides a doctor-patient calling method, the method comprising: Monitoring the communication status of a central server; wherein the central server is communicatively connected to a call initiating device and a call receiving device in a medical-patient area; When the communication state is normal, the central server receives a first call request triggered by the call initiating device, and monitors the online state of the call receiving device; When the online status is offline, the central server triggers the first call failure information and returns the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the standby signaling server; When the communication state is abnormal, the call initiating device sends the second call request to the call receiving device through the standby signaling server.

[0006] The present embodiment provides a method for doctor-patient calls, which ensures that call requests can be sent smoothly and responded to in a timely manner by real-time monitoring of the communication status of the central server and the online status of the device. When the call receiving device is offline, the central server can automatically trigger the call failure information to avoid long-term unresponsiveness and improve the user experience. At the same time, when the communication is abnormal, the call initiating device can automatically switch to the backup signaling server to continue to initiate the call request, thereby avoiding service interruption caused by the failure of the central server. This mechanism greatly improves high availability, fault tolerance and stability, effectively reduces the risk of single point failure, and ensures the reliable operation of doctor-patient calls under various abnormal circumstances. Overall, it enhances its ability to deal with emergencies, optimizes user experience, and improves service continuity and reliability.

[0007] Optionally, before monitoring the communication status of the central server, the method includes: The call initiating device and the call receiving device both create a TCP client through the Netty framework; The nurse station host in the medical area creates a TCP server through the Netty framework, and determines the nurse station host as the backup signaling server; The TCP client initiates a connection request to the TCP server to establish a long connection between the call initiating device and the call receiving device and the standby signaling server.

[0008] In this embodiment, the call initiating device and the call receiving device establish a long connection with the backup signaling server through the TCP client to ensure that data can be transmitted continuously and reliably. The Netty framework optimizes the establishment of connections and data transmission, and improves the throughput and response speed of the system. The setting of the backup signaling server enhances the fault tolerance of the system. Once the central server fails, the backup signaling server can take over the work to avoid communication interruption. The long connection mechanism reduces the delay caused by frequent connections and disconnections, improves communication efficiency, and supports real-time interaction between devices. Overall, this embodiment ensures stable operation in a high-concurrency environment through these technical measures, improves user experience, and avoids call delays or failures caused by connection problems.

[0009] Optionally, after monitoring the online status of the call receiving device, the method includes: When the online status is online, the central server sends the first call request to the call receiving device; The call receiving device receives the first call request and establishes real-time audio and video communication with the call initiating device through WebRTC technology.

[0010] In this embodiment, when the call receiving device is online, the central server will send the first call request to the call receiving device, thereby ensuring that the first call request can be accurately transmitted and arrive in time. After that, the call receiving device establishes real-time audio and video communication with the call initiating device through WebRTC technology, ensuring a high-quality, low-latency interactive experience. The use of WebRTC technology eliminates the dependence on the central server, allowing audio and video data to be transmitted through a point-to-point connection, thereby improving the real-time and stability of communication. The overall response efficiency and communication quality are improved, the risk of waiting and lost requests is reduced, ensuring that doctors and patients can enjoy smooth, clear real-time communication, and enhancing the user experience.

[0011] Optionally, before the call initiating device sends the second call request to the call receiving device through the standby signaling server, the method further includes: monitoring the online status of the call receiving device; When the online state is offline, the standby signaling server triggers second call failure information; In response to the call initiating device receiving the second call failure information, the call is terminated and prompt information is generated to remind the user of the call failure.

[0012] This embodiment ensures that it is possible to determine in real time whether the device is online or offline by monitoring the online status of the call receiving device. When it is detected that the call receiving device is offline, the backup signaling server is triggered to send a second call failure message to inform the call initiating device that the call cannot be connected. In response to this, the call initiating device will be triggered to end the call and generate a prompt message to remind the user that the call failed. Through this mechanism, call failure information can be fed back in time when the call receiving device is offline, avoiding the situation where the call initiating device waits for a long time without receiving a response, thereby improving the user experience. This process effectively ensures the transparency and accuracy of communication, ensuring that users can quickly learn the reasons for the call failure and take corresponding measures. In addition, triggering the backup signaling server to send failure information also ensures that clear feedback information can still be provided when the device cannot be accessed, thereby enhancing the stability of the entire call and user satisfaction.

[0013] Optionally, before the call initiating device sends the second call request to the call receiving device through the standby signaling server, the method further includes: monitoring the online status of the call receiving device; When the online state is online, the standby signaling server sends the second call request to the call receiving device; The call receiving device receives the second call request and establishes real-time audio and video communication with the call initiating device through WebRTC technology.

[0014] This embodiment monitors the online status of the call receiving device in real time. When the call receiving device is online, the backup signaling server will send a second call request to the device to ensure that the backup server can continue to transmit the call request when the central server fails, thereby improving reliability. In addition, the call receiving device establishes point-to-point real-time audio and video communication with the call initiating device through WebRTC technology, ensuring a low-latency, high-quality interactive experience, reducing transmission delays, and improving the smoothness and stability of communication. The call request transmission efficiency is optimized, the user experience is improved, and fault tolerance and availability are greatly enhanced.

[0015] Optionally, the call initiating device and the call receiving device include at least one of a bedside call terminal, a nurse station host, and a doctor on-duty extension.

[0016] Optionally, the method further comprises: The central server sends the first call request and the backup signaling server sends the second call request to the display end, and the call prompt is made through the display end; wherein, the display end includes at least one of a large interactive TV screen, a door split screen, and a corridor screen.

[0017] In this embodiment, the central server and the backup signaling server send the first call request and the second call request to the display terminal respectively, and make call prompts through the display terminal. The diversified configuration of the display terminal improves the visibility and coverage of the call prompt, ensuring that users can see the call information in time at different locations; secondly, it can adapt to the needs of different scenarios, such as the large interactive TV screen is suitable for public areas, the door split screen is suitable for entrances and exits, and the corridor screen can be used in corridors and other places; at the same time, through the collaborative work of multiple devices, fault tolerance is enhanced. Even if a display terminal fails, other display terminals can continue to provide call prompts, ensuring the reliable transmission of information; in addition, call prompts from multiple display terminals can also improve call response efficiency and reduce missed calls, thereby improving user experience, especially in large medical facilities, avoiding information omissions.

[0018] In a second aspect, an embodiment of the present application provides a doctor-patient calling device, the device comprising: A communication monitoring unit, used to monitor the communication status of the central server; wherein the central server is communicatively connected to the call initiating device and the call receiving device in the doctor-patient area; an online monitoring unit, configured to, when the communication state is normal, receive, by the central server, a first call request triggered by the call initiating device, and monitor an online state of the call receiving device; A backup service unit, configured to trigger, when the online state is offline, the first call failure information by the central server, and return the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the backup signaling server; The standby sending unit is used for, when the communication state is abnormal, the call initiating device to send the second call request to the call receiving device through the standby signaling server.

[0019] In a third aspect, an embodiment of the present application provides a computer device, including: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the above-mentioned doctor-patient calling method by executing the computer instructions.

[0020] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which computer instructions are stored, and the computer instructions are used to enable a computer to execute the above-mentioned doctor-patient calling method. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the specific implementation methods of the present application or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 A schematic diagram of a specific application example provided in an embodiment of the present application; Figure 2 A flowchart of a doctor-patient calling method provided in an embodiment of the present application; Figure 3 A flow chart before monitoring the communication status of a central server provided in an embodiment of the present application; Figure 4 A flow chart after monitoring the online status of a call receiving device provided in an embodiment of the present application; Figure 5 A flow chart provided in an embodiment of the present application before a call initiating device sends a second call request to a call receiving device through a standby signaling server; Figure 6 Another flow chart provided for an embodiment of the present application before a call initiating device sends a second call request to a call receiving device through a standby signaling server; Figure 7 A flowchart of another doctor-patient calling method provided in an embodiment of the present application; Figure 8 A block diagram of a doctor-patient calling device provided in an embodiment of the present application; Fig. 9 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0024] In traditional bedside call systems, a centralized architecture is usually adopted, in which the central server assumes the key functions of signaling exchange and audio and video call forwarding. The main components of the system include patient-side devices, medical-side devices, other call display terminals and central servers. Patient-side devices (such as bedside extensions) are responsible for initiating call requests to medical-side devices, or answering calls when receiving calls from medical-side devices, so that patients can initiate help at any time. Medical-side devices (such as nurse station host, doctor duty room extension) receive and process patient-side call requests, decide whether to answer and can actively initiate calls to communicate with patients. Other call display terminals (such as TV interactive large screens, door extensions, corridor screens, etc.) are mainly used to display relevant information about patient calls so that medical staff can respond in time. As the core of the entire system, the central server is responsible for receiving call requests from the patient and medical-side terminals, forwarding signaling messages to the target device, ensuring smooth signaling exchange, and monitoring system status and log records.

[0025] The system's workflow usually includes the following steps: the patient-side device initiates a call request, and the signaling message is forwarded to the relevant medical-side device through the central server; after receiving the request, the medical-side device decides whether to answer the call based on the situation; audio and video calls are established directly between the patient and medical ends, and the central server is mainly responsible for signaling coordination; other display ends display call information in real time so that medical staff can understand patient needs; the central server also continuously monitors the system status to ensure that the device connection is normal and handles any failures.

[0026] However, the system also has certain shortcomings, especially its over-reliance on the central server. Since the central server is a single point of failure in the system, any server failure or network problem may cause signaling transmission interruption, thus affecting the real-time nature of calls and emergency response, and causing delays in the allocation of medical resources.

[0027] In order to solve the above technical problems, according to an embodiment of the present application, a doctor-patient call method embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0028] Figure 1 A schematic diagram of a specific application example provided in the embodiment of the present application, such as Figure 1 As shown. A TCP server is created on the nurse station host using the Netty framework. This server is used to receive the connection request and subsequent call information from the call initiating device, and the nurse station host is determined as a backup signaling server. The call receiving device uses the Netty framework to create a TCP client and establish a long connection with the TCP server of the backup signaling server. When the call initiating device presses a physical button or clicks the touch screen, it initiates the first call request. The call initiating device first checks whether the communication with the central server is normal. If the connection is normal, the call initiating device sends the first call request to the central server, and the central server processes the first call request and checks whether the call receiving device is online. If the connection is abnormal, the call initiating device sends the second call request to the backup signaling server, and all subsequent operations are processed by the backup signaling server.

[0029] After the central server receives the first call request initiated by the call initiating device, it first verifies whether the call receiving device is online. If the call receiving device is online, the central server sends the first call request to the call receiving device. After the call receiving device receives the first call request, it establishes real-time audio and video communication with the call initiating device through WebRTC technology. If the call receiving device is offline, the central server triggers the first call failure information to the call initiating device. After the call initiating device receives the first call failure information, it re-processes the subsequent processing through the backup signaling server.

[0030] The call initiating device sends the second call request to the standby signaling server, and the standby signaling server checks whether the call receiving device is online. If the call receiving device is online, the standby signaling server sends the second call request to the call receiving device. After the call receiving device receives the second call request, it establishes real-time audio and video communication with the call initiating device through WebRTC technology. If the call receiving device is offline, the standby signaling server triggers the second call failure information to the call initiating device. After the call initiating device receives the second call failure information, it ends the call and generates a prompt message to remind the user that the call failed.

[0031] In this embodiment, a doctor-patient calling method is provided. Figure 2A flowchart of a doctor-patient calling method provided in an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps: Step S1, monitoring the communication status of the central server; wherein the central server is communicatively connected to the call initiating device and the call receiving device in the medical area.

[0032] The central server is responsible for receiving call requests from the patient or medical call initiator and forwarding the signaling message according to the requested call receiving device. In addition to signaling forwarding, the central server may also undertake the data forwarding function of audio and video calls. It must not only ensure the timely delivery of signaling, but also ensure the stability and efficiency of audio and video data flow. In the doctor-patient call system, any downtime of the central server will cause the collapse of the entire system, thereby affecting the life safety of the patient.

[0033] Specifically, the communication status of the central server needs to be monitored in real time, and the first call request to the central server can be triggered by the call initiating device to check the connection status with the central server to confirm the connectivity of the communication link.

[0034] In some preferred embodiments, the call initiating device and the call receiving device include at least one of a bedside call terminal, a nurse station host, and a doctor on-duty extension.

[0035] Specifically, the patient can initiate a call request to the nurse station host or the doctor's duty extension through the bedside call terminal, and can also receive a call request from the nurse station host or the doctor's duty extension; the nurse can initiate a call request to the bedside call terminal or the doctor's duty extension through the nurse station host, and can also receive a call request from the bedside call terminal or the doctor's duty extension; the doctor can initiate a call request to the bedside call terminal or the nurse station host through the doctor's duty extension, and can also receive a call request from the bedside call terminal or the nurse station host. That is, the bedside call terminal, the nurse station host, and the doctor's duty extension can be both call initiating devices and call receiving devices.

[0036] Step S3, when the communication status is normal, the central server receives the first call request triggered by the call initiating device, and monitors the online status of the call receiving device.

[0037] Specifically, if the communication status shows that the connection is normal, the call initiating device will send the first call information containing necessary information to the central server, which may include patient information, ward number, bed number, etc. The first call information is usually sent in a specific format, such as JSON or XML, to facilitate the central server to parse and process. The central server receives the first call information from the call initiating device. Based on the received information, the central server searches whether the corresponding call receiving device (such as the nurse station host or the doctor on duty extension) is online.

[0038] Step S5, when the online status is offline, the central server triggers the first call failure information and returns the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the backup signaling server.

[0039] Specifically, when the central server confirms that the call receiving device is offline, a first call failure message is generated. This first call failure message includes the reason for the call failure, such as "the receiving device is offline" or "network connection problem". The central server returns the first call failure message to the call initiating device. After the call initiating device receives the first call failure message, it triggers the process of the backup signaling server. The backup signaling server provides a backup communication path when the central server is unavailable. The call initiating device sends a second call request to the call receiving device through the backup signaling server. This second request contains the same information as the first request, and also includes an indication of using the backup signaling server for communication, indicating that this is a retry request.

[0040] Step S7: When the communication state is abnormal, the call initiating device sends a second call request to the call receiving device through the standby signaling server.

[0041] Specifically, if the communication state is detected to be abnormal, the call initiating device will automatically switch to the backup signaling server, and the call initiating device will send the second call request to the backup signaling server instead of the central server. In the second call request, the call initiating device needs to clearly indicate that the request is communicated through the backup signaling server.

[0042] The present embodiment provides a method for doctor-patient calls, which ensures that call requests can be sent smoothly and responded to in a timely manner by real-time monitoring of the communication status of the central server and the online status of the device. When the call receiving device is offline, the central server can automatically trigger the call failure information to avoid long-term unresponsiveness and improve the user experience. At the same time, when the communication is abnormal, the call initiating device can automatically switch to the backup signaling server to continue to initiate the call request, thereby avoiding service interruption caused by the failure of the central server. This mechanism greatly improves high availability, fault tolerance and stability, effectively reduces the risk of single point failure, and ensures the reliable operation of doctor-patient calls under various abnormal circumstances. Overall, it enhances its ability to deal with emergencies, optimizes user experience, and improves service continuity and reliability.

[0043] Figure 3 The flowchart provided in the embodiment of the present application before monitoring the communication status of the central server may include the following steps: Step S11: Both the call initiating device and the call receiving device create a TCP client through the Netty framework.

[0044] Step S13, the nurse station host in the medical area creates a TCP server through the Netty framework, and determines the nurse station host as a backup signaling server.

[0045] Step S15: The TCP client initiates a connection request to the TCP server to establish a long connection between the call initiating device and the call receiving device and the standby signaling server.

[0046] Specifically, both the call initiating device and the call receiving device create TCP clients through the Netty framework, which can initiate requests to connect to the TCP server. The nurse station host creates a TCP server through the Netty framework, enabling it to accept connection requests from TCP clients. The nurse station host is determined as a backup signaling server, which means that it will take on the task of signaling exchange when the central server is unavailable. The call initiating device and the call receiving device act as TCP clients and initiate connection requests to the nurse station host as a TCP server. After receiving the connection requests, the nurse station host processes these requests according to the configuration and establishes a connection. Once the connection is established, a long connection will be maintained between the TCP client and the TCP server for continuous communication. This long connection can be used to transmit data in real time, such as call requests, status updates, etc. At the same time, the long connection can reduce the delay in establishing a connection for each communication.

[0047] and Figure 2 Compared with the embodiment shown, in this embodiment, the call initiating device and the call receiving device establish a long connection with the backup signaling server through the TCP client to ensure that data can be transmitted continuously and reliably. The Netty framework optimizes the establishment of connections and data transmission, and improves the throughput and response speed of the system. The setting of the backup signaling server enhances the fault tolerance of the system. Once the central server fails, the backup signaling server can take over the work to avoid communication interruption. The long connection mechanism reduces the delay caused by frequent connections and disconnections, improves communication efficiency, and supports real-time interaction between devices. Overall, this embodiment ensures stable operation in a high-concurrency environment through these technical measures, improves user experience, and avoids call delays or failures caused by connection problems.

[0048] Figure 4 The flowchart provided in the embodiment of the present application after monitoring the online status of the call receiving device may include the following steps: Step S21: When the online status is online, the central server sends a first call request to the call receiving device.

[0049] Step S23: The call receiving device receives the first call request and establishes real-time audio and video communication with the call initiating device through WebRTC technology.

[0050] Specifically, the central server has confirmed that the call receiving device is online, and the central server sends the first call request to the call receiving device. The call receiving device (such as the nurse station host or the doctor's duty extension) receives the first call request sent by the central server. The call receiving device determines whether to accept the call based on the received first call request and prepares to establish communication with the call initiating device. Once the connection is established, the call receiving device uses WebRTC technology to establish real-time audio and video communication with the call initiating device. The application of WebRTC technology makes this process unnecessary to rely on traditional centralized video conferencing systems, reducing costs and increasing flexibility.

[0051] and Figure 2 Compared with the embodiment shown in the figure, in this embodiment, when the call receiving device is online, the central server will send the first call request to the call receiving device, thereby ensuring that the first call request can be accurately transmitted and arrive in time. After that, the call receiving device establishes real-time audio and video communication with the call initiating device through WebRTC technology, ensuring a high-quality, low-latency interactive experience. The use of WebRTC technology eliminates the dependence on the central server, allowing audio and video data to be transmitted through a point-to-point connection, thereby improving the real-time and stability of communication. The overall response efficiency and communication quality are improved, the risk of waiting and losing requests is reduced, ensuring that doctors and patients can enjoy smooth, clear real-time communication, and enhancing the user experience.

[0052] Figure 5 A flowchart provided in an embodiment of the present application before a call initiating device sends a second call request to a call receiving device through a standby signaling server may include the following steps: Step S711, monitoring the online status of the call receiving device.

[0053] Step S713: When the online state is offline, the standby signaling server triggers second call failure information.

[0054] Step S715: in response to the call initiating device receiving the second call failure information, the call is terminated and prompt information is generated to remind the user of the call failure.

[0055] Specifically, the online status of the call receiving device (such as the nurse station host or the doctor's duty extension) is checked regularly or monitored in real time. Usually, a heartbeat packet is sent and a status query request is made to determine whether the call receiving device is online. If the call receiving device is detected to be offline, the backup signaling server generates a second call failure message and feeds it back to the call initiating device. The second call failure message should include the cause of failure, timestamp, etc., so that the call initiating device can handle it correctly. The call initiating device receives the second call failure message from the backup signaling server. Generate a prompt message to remind the patient or medical staff of the call failure and end the current call.

[0056] and Figure 2 Compared with the embodiment shown, this embodiment ensures that it is possible to determine in real time whether the device is online or offline by monitoring the online status of the call receiving device. When it is detected that the call receiving device is in an offline state, the backup signaling server is triggered to send a second call failure message to inform the call initiating device that the call cannot be connected. In response to this, the call initiating device will be triggered to end the call and generate a prompt message to remind the user that the call failed. Through this mechanism, call failure information can be fed back in time when the call receiving device is offline, avoiding the situation where the call initiating device waits for a long time without receiving a response, thereby improving the user experience. This process effectively guarantees the transparency and accuracy of communication, ensuring that the user can quickly learn the reason for the call failure and take corresponding measures. In addition, triggering the backup signaling server to send failure information also ensures that clear feedback information can still be provided when the device cannot be accessed, thereby enhancing the stability of the entire call and user satisfaction.

[0057] Figure 6 Another flowchart provided in an embodiment of the present application before a call initiating device sends a second call request to a call receiving device through a standby signaling server may include the following steps: Step S721, monitoring the online status of the call receiving device.

[0058] Step S723: When the online state is online, the standby signaling server sends a second call request to the call receiving device.

[0059] Step S725: The call receiving device receives the second call request and establishes real-time audio and video communication with the call initiating device through WebRTC technology.

[0060] Specifically, the online status of the call receiving device (such as the nurse station host or the doctor's duty extension) is regularly checked or monitored in real time. Usually, the call receiving device is determined to be online by sending a heartbeat packet and querying the status request. If the call receiving device is detected to be online, the backup signaling server sends a second call request to the call receiving device. The call receiving device receives the second call request from the backup signaling server. The call receiving device determines whether to accept the call based on the received second call request and prepares to establish communication with the call initiating device. Once the connection is established, the call receiving device uses WebRTC technology to establish real-time audio and video communication with the call initiating device.

[0061] and Figure 2 Compared with the embodiment shown in the figure, this embodiment monitors the online status of the call receiving device in real time. When the call receiving device is online, the backup signaling server will send a second call request to the device to ensure that the backup server can continue to transmit the call request when the central server fails, thereby improving reliability. In addition, the call receiving device establishes point-to-point real-time audio and video communication with the call initiating device through WebRTC technology, ensuring a low-latency, high-quality interactive experience, reducing transmission delays, and improving the smoothness and stability of communication. The transmission efficiency of call requests is optimized, the user experience is improved, and fault tolerance and availability are greatly enhanced.

[0062] Figure 7 A flowchart of another doctor-patient calling method provided in an embodiment of the present application, the process may include the following steps: In step S9, the central server sends the first call request and the backup signaling server sends the second call request to the display end, and the call prompt is made through the display end; wherein the display end includes at least one of a large interactive TV screen, a door split screen, and a corridor screen.

[0063] Specifically, when the central server confirms that the call receiving device is online, the central server sends the first call request to the presentation terminal.

[0064] When the call receiving device is offline or the communication status of the central server is abnormal, the backup signaling server sends the second call request to the display end. The display end receives the call request from the central server or the backup signaling server. The display end displays the call prompt to the relevant personnel through the TV interactive large screen, the door split screen, the corridor screen and other devices, such as "Bed X in the ward requests help". The call information is further conveyed to the medical staff to improve the response speed and quality of medical services.

[0065] and Figure 2Compared with the embodiment shown, the central server and the backup signaling server of this embodiment send the first call request and the second call request to the display terminal respectively, and make call prompts through the display terminal. The diversified configuration of the display terminal improves the visibility and coverage of the call prompt, ensuring that users can see the call information in time at different locations; secondly, it can adapt to the needs of different scenarios, such as the large interactive TV screen is suitable for public areas, the door split screen is suitable for entrances and exits, and the corridor screen can be used in corridors and other places; at the same time, through the collaborative work of multiple devices, fault tolerance is enhanced. Even if a display terminal fails, other display terminals can continue to provide call prompts, ensuring the reliable transmission of information; in addition, call prompts from multiple display terminals can also improve call response efficiency and reduce missed calls, thereby improving user experience, especially in large medical facilities, avoiding information omissions.

[0066] Accordingly, please refer to Figure 8 A block diagram of a doctor-patient calling device provided in an embodiment of the present application, the terminal includes: The communication monitoring unit 101 is used to monitor the communication status of the central server; wherein the central server is communicatively connected to the call initiating device and the call receiving device in the medical area; The online monitoring unit 103 is used for, when the communication state is normal, the central server receives the first call request triggered by the call initiating device and monitors the online state of the call receiving device; The backup service unit 105 is used for triggering the first call failure information by the central server when the online state is offline, and returning the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the backup signaling server; The standby sending unit 107 is configured to, when the communication state is abnormal, enable the call initiating device to send a second call request to the call receiving device via the standby signaling server.

[0067] In some optional embodiments, before monitoring the communication status of the central server, the device includes: Both the call initiating device and the call receiving device create TCP clients through the Netty framework; The nurse station host in the medical and patient area creates a TCP server through the Netty framework, and determines the nurse station host as the backup signaling server; The TCP client initiates a connection request to the TCP server to establish a long connection between the call initiating device and the call receiving device and the standby signaling server.

[0068] In some optional implementations, after monitoring the online status of the call receiving device, the apparatus includes: When the online status is online, the central server sends the first call request to the call receiving device; The call receiving device receives the first call request and establishes real-time audio and video communication with the call initiating device through the WebRTC technology.

[0069] In some optional implementations, before the call initiating device sends the second call request to the call receiving device through the standby signaling server, the apparatus further includes: Monitor the online status of the call receiving device; When the online status is offline, the standby signaling server triggers a second call failure message; In response to the call initiating device receiving the second call failure information, the call is terminated and prompt information for reminding the user of the call failure is generated.

[0070] In some optional implementations, before the call initiating device sends the second call request to the call receiving device through the standby signaling server, the apparatus further includes: Monitor the online status of the call receiving device; When the online state is online, the standby signaling server sends a second call request to the call receiving device; The call receiving device receives the second call request and establishes real-time audio and video communication with the call initiating device through the WebRTC technology.

[0071] In some optional implementations, the call initiating device and the call receiving device include at least one of a bedside call terminal, a nurse station host, and a doctor on-duty extension.

[0072] In some optional embodiments, the device further comprises: The central server sends the first call request and the backup signaling server sends the second call request to the display end, and the call prompt is made through the display end; wherein the display end includes at least one of a large interactive TV screen, a door split screen, and a corridor screen.

[0073] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0074] In this embodiment, a doctor-patient call device is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0075] See also Fig. 9 , Fig. 9A schematic diagram of the structure of a computer device provided in an embodiment of the present application is shown in FIG. Fig. 9 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components are connected to each other using different buses for communication, and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig. 9 A processor 10 is taken as an example.

[0076] The processor 10 may be a central processing unit, a network processor or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic or any combination thereof.

[0077] The memory 20 stores instructions executable by at least one processor 10, so that the at least one processor 10 executes the method shown in the above embodiment.

[0078] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely arranged relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0079] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 20 may also include a combination of the above types of memory.

[0080] The computer device further comprises a communication interface 30 for the computer device to communicate with other devices or a communication network.

[0081] The embodiment of the present application also provides a computer-readable storage medium. The above method according to the embodiment of the present application can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0082] The systems, devices, and units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0083] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0084] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods and devices. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0085] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices and apparatuses according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of the processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0086] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0087] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0088] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0089] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0090] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

[0091] Although the embodiments of the present application have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present application, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A doctor-patient calling method, characterized in that: The method comprises: Monitoring the communication status of a central server; wherein the central server is communicatively connected to a call initiating device and a call receiving device in a medical-patient area; When the communication state is normal, the central server receives a first call request triggered by the call initiating device, and monitors the online state of the call receiving device; When the online status is offline, the central server triggers the first call failure information and returns the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the standby signaling server; When the communication state is abnormal, the call initiating device sends the second call request to the call receiving device through the standby signaling server.

2. The method according to claim 1, characterized in that Before monitoring the communication status of the central server, the method includes: The call initiating device and the call receiving device both create a TCP client through the Netty framework; The nurse station host in the medical area creates a TCP server through the Netty framework, and determines the nurse station host as the backup signaling server; The TCP client initiates a connection request to the TCP server to establish a long connection between the call initiating device and the call receiving device and the standby signaling server.

3. The method according to claim 1, characterized in that After monitoring the online status of the call receiving device, the method includes: When the online status is online, the central server sends the first call request to the call receiving device; The call receiving device receives the first call request and establishes real-time audio and video communication with the call initiating device through WebRTC technology.

4. The method according to claim 1, characterized in that: Before the call initiating device sends the second call request to the call receiving device through the standby signaling server, the method further includes: monitoring the online status of the call receiving device; When the online state is offline, the standby signaling server triggers second call failure information; In response to the call initiating device receiving the second call failure information, the call is terminated and prompt information is generated to remind the user of the call failure.

5. The method according to claim 1, characterized in that Before the call initiating device sends the second call request to the call receiving device through the standby signaling server, the method further includes: monitoring the online status of the call receiving device; When the online state is online, the standby signaling server sends the second call request to the call receiving device; The call receiving device receives the second call request and establishes real-time audio and video communication with the call initiating device through WebRTC technology.

6. The method according to claim 1, characterized in that The call initiating device and the call receiving device include at least one of a bedside call terminal, a nurse station host, and a doctor on-duty extension.

7. The method according to claim 1, characterized in that The method further comprises: The central server sends the first call request and the backup signaling server sends the second call request to the display end, and the call prompt is made through the display end; wherein, the display end includes at least one of a large interactive TV screen, a door split screen, and a corridor screen.

8. A doctor-patient calling device, characterized in that: The device comprises: A communication monitoring unit, used to monitor the communication status of the central server; wherein the central server is communicatively connected to the call initiating device and the call receiving device in the doctor-patient area; an online monitoring unit, configured to, when the communication state is normal, receive, by the central server, a first call request triggered by the call initiating device, and monitor an online state of the call receiving device; A backup service unit, configured to trigger, when the online state is offline, the first call failure information by the central server, and return the first call failure information to the call initiating device, so that the call initiating device sends a second call request to the call receiving device through the backup signaling server; The standby sending unit is used for, when the communication state is abnormal, the call initiating device to send the second call request to the call receiving device through the standby signaling server.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the doctor-patient calling method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the doctor-patient calling method according to any one of claims 1 to 7.

Images