Server, display device, and reception method

Abstract

The application provides a server, a display device and a reception method. The server is configured to: receive a user terminal inquiry request, the inquiry request comprising a user identity of a user and a user type; if the user type is a first type, send a first reception command comprising the user identity to a first terminal, so that the first terminal and the user terminal establish a first video reception process; if the user type is a second type, send a triage command comprising the user identity to a second service unit, so that the second service unit feeds back target department information after establishing an inquiry process with the user terminal; and send a second reception command to a second terminal according to the received target department information and the user identity, so that the second terminal and the user terminal establish a second video reception process, wherein the second type represents that the user is not bound to any doctor. The application improves the inquiry experience of user inquiry.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a server, a display device, and a reception method. Background Technology

[0002] Internet-based healthcare is the application of the internet in the medical industry. Leveraging the convenience of the internet, it allows people to consult doctors from the comfort of their homes, removing geographical limitations and making life more convenient. In related technologies, when a user consults online, the server randomly recommends a currently online doctor. However, this means the doctor might be different each time. For users who need frequent consultations, such as those requiring continuous monitoring of a disease at fixed intervals, frequently changing doctors is detrimental to the user experience. Summary of the Invention

[0003] To address the technical issue of poor user experience during medical visits, this application provides a server, a display device, and a method for receiving patients.

[0004] Firstly, this application provides a server configured to:

[0005] Receive a consultation request from a user terminal, the consultation request including the user's user identity identifier and user type;

[0006] If the user type is the first type, a first consultation command containing the user's identity identifier is sent to the first terminal to establish a first video consultation process between the first terminal and the user terminal, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship;

[0007] If the user type is the second type, a triage command containing the user's identity identifier is sent to the second business unit so that the second business unit can provide the target department information after establishing a consultation process with the user terminal; and a second reception command is sent to the second terminal based on the received target department information and the user's identity identifier so that the second terminal and the user terminal can establish a second video reception process, wherein the second type indicates that the user has not bound any doctor;

[0008] Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

[0009] Secondly, this application provides a display device, which includes:

[0010] monitor;

[0011] The controller, which is communicatively connected to the display, is configured to:

[0012] After entering the consultation application, the system queries the account module of the server for the rights and interests information of logged-in users, including user type;

[0013] If the user type is the first type, when the trigger instruction of the patient control in the consultation application is received, a first consultation request including the user type is sent to the server, so that the server controls the first terminal to establish a first video consultation process with the display device, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship;

[0014] If the user type is the second type, when a trigger instruction is received from the patient control in the consultation application, a second consultation request including the user type but excluding the causal parameter is sent to the server according to the trigger instruction not including the causal parameter. This allows the server to control the second business unit to obtain target department information after establishing a consultation process with the display device, and to control the second terminal to establish a second video consultation process with the display device according to the received target department information. The second type indicates that the user is not bound to any doctor.

[0015] Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

[0016] Thirdly, this application provides a method for receiving patients, the method comprising:

[0017] Receive a consultation request from a user terminal, the consultation request including the user's user identity identifier and user type;

[0018] If the user type is the first type, a first consultation command containing the user's identity identifier is sent to the first terminal to establish a first video consultation process between the first terminal and the user terminal, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship;

[0019] If the user type is the second type, a triage command containing the user's identity identifier is sent to the second business unit so that the second business unit can provide the target department information after establishing a consultation process with the user terminal; and a second reception command is sent to the second terminal based on the received target department information and the user's identity identifier so that the second terminal and the user terminal can establish a second video reception process, wherein the second type indicates that the user has not bound any doctor;

[0020] Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

[0021] The beneficial effects of the server, display device, and reception method provided in this application include:

[0022] The server in this embodiment divides doctors into two groups. For users of the first type, they can be bound to doctors in the first group. The server controls these doctors to see the users of the first type, increasing the probability that a user will see their bound doctor multiple times, thus solving the problem of different doctors for each consultation. For users of the second type, no doctor is bound to them. The server selects a doctor from the second group based on the user's desired department, thereby meeting the user's medical needs. This embodiment satisfies the medical needs of different types of users and improves the consultation experience. Attached Figure Description

[0023] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 The diagram illustrates an operational scenario between a display device and a control unit.

[0025] Figure 2 The diagram above illustrates a flowchart of a consultation method.

[0026] Figure 3 The diagram above illustrates a flowchart of the patient reception method.

[0027] Figure 4 The diagram above illustrates a flowchart of the patient reception method.

[0028] Figure 5The diagram above illustrates the timeline of the patient reception process.

[0029] Figure 6 The image above shows a schematic diagram of the online consultation homepage.

[0030] Figure 7 The diagram above illustrates a patient selection interface.

[0031] Figure 8 The diagram above illustrates a video call interface.

[0032] Figure 9 The diagram above illustrates the timeline of the patient reception process.

[0033] Figure 10 An exemplary diagram of the patient selection interface is shown;

[0034] Figure 11 The diagram above illustrates a waiting interface for medical treatment.

[0035] Figure 12 The diagram above illustrates the timeline of the patient reception process.

[0036] Figure 13 The diagram above illustrates a patient selection interface.

[0037] Figure 14 The diagram above illustrates the department selection interface.

[0038] Figure 15 The diagram above illustrates a waiting interface for medical appointments. Detailed Implementation

[0039] To make the objectives and implementation methods of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the exemplary embodiments described are only some embodiments of this application, and not all embodiments.

[0040] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0041] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms are interchangeable where appropriate.

[0042] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0043] The display device provided in this application can have various implementation forms, such as a television, a smart television, a laser projection device, a monitor, an electronic bulletin board, an electronic table, etc. Figure 1 This is one specific embodiment of the display device of this application.

[0044] Figure 1 This is a schematic diagram illustrating the operational scenario between the display device and the control unit according to the embodiment. Figure 1 As shown, the user can operate the display device 200 through the smart device 300 or the control device 100.

[0045] In some embodiments, the control device 100 may be a remote control. Communication between the remote control and the display device includes infrared protocol communication, Bluetooth protocol communication, and other short-range communication methods, controlling the display device 200 wirelessly or via wired means. Users can control the display device 200 by inputting user commands through buttons on the remote control, voice input, control panel input, etc.

[0046] In some embodiments, a smart device 300 (such as a mobile terminal, tablet computer, computer, laptop computer, etc.) may also be used to control the display device 200. For example, an application running on the smart device may be used to control the display device 200.

[0047] In some embodiments, the display device may receive instructions not through the aforementioned smart devices or control devices, but through touch or gestures.

[0048] In some embodiments, the display device 200 can also be controlled in ways other than the control device 100 and the smart device 300. For example, it can be controlled by directly receiving the user's voice commands through a module configured inside the display device 200 for acquiring voice commands, or it can be controlled by receiving the user's voice commands through a voice control device set outside the display device 200.

[0049] In some embodiments, the display device 200 also communicates with the server 400. The display device 200 may communicate via a local area network (LAN), wireless local area network (WLAN), and other networks. The server 400 may provide various content and interactive features to the display device 200. The server 400 may be a cluster or multiple clusters, and may include one or more types of servers.

[0050] In some embodiments, the application layer of the display device may include a health consultation application, which allows users to consult with doctors and enjoy the convenience of internet healthcare from home.

[0051] It should be noted that in the embodiments of this application, "user" refers to the person who needs to be consulted, not the doctor.

[0052] In some embodiments, the display device may be equipped with a camera component to enable users to conduct video consultations with doctors in health consultation applications.

[0053] In some embodiments, users consult doctors online via text. When this method is applied to display devices such as smart TVs, the user's input efficiency is low because users usually input through a remote control on the smart TV. This results in the inability to communicate with doctors in a timely, comprehensive, and accurate manner, leading to a poor consultation experience for the user.

[0054] To address the technical issue of poor user experience when seeking medical advice on smart TVs, this application proposes a consultation method for servers used in health consultation applications. This method, by enabling video calling, allows users to conduct video consultations on their smart TVs, thereby improving the timeliness, comprehensiveness, and accuracy of the consultation. Furthermore, the server provided in this application distributes different consultation interfaces to the display device for different types of users, allowing different user experiences to access different levels of consultation services, thus meeting diverse consultation needs.

[0055] In some embodiments, a health consultation application is called "Xiaoju Health," which can provide video consultations and different consultation methods for different types of users.

[0056] In some embodiments, "Xiaoju Health" users can be divided into three categories: the first category is Super VIP users, the second category is ordinary VIP users, and the third category is users who have not activated VIP.

[0057] In some embodiments, a Super VIP user refers to a user who has activated the Super Member benefits of "Xiaoju Health". These Super Member benefits include family doctor consultations; Super VIPs can sign up with a family doctor. Family doctors are general practitioners who only see Super VIP users. Super Member benefits also include the number of consultations and the consultation validity period. Super VIP users can consult with a family doctor when the number of consultations is greater than zero and within the validity period. In some embodiments, after a user purchases Super Member benefits, "Xiaoju Health" may display a family doctor selection interface for the user to choose a family doctor, or "Xiaoju Health" may randomly assign a family doctor to the user, who can change the doctor if dissatisfied. After a user selects a family doctor, "Xiaoju Health's" server can bind the user's identity identifier with the family doctor's identity identifier.

[0058] In some embodiments, a Super VIP user can be linked to two or more family doctors.

[0059] In some embodiments, a regular VIP user is someone who has activated the regular membership benefits of "Xiaoju Health." These benefits include consultations with specialist doctors. A specialist doctor is a physician in a specific department, also known as a general practitioner, and only sees regular VIP users. Regular VIP users can consult with specialist doctors from multiple different departments. In some embodiments, users who have not activated VIP include those who have not purchased either the "Xiaoju Health" Super Membership or the regular Membership benefits. If such users seek a consultation, "Xiaoju Health" may prompt them to purchase either Super Membership or the regular Membership benefits. Users can then seek a consultation after purchasing either Super Membership or the regular Membership benefits.

[0060] For ease of description, user types can also be divided into Type 1, Type 2, and Type 3. Type 1 corresponds to Super VIP, Type 2 to Regular VIP, and Type 3 to Non-VIP. Family doctors can be collectively referred to as First Doctors, and specialist doctors can be collectively referred to as Second Doctors.

[0061] In some embodiments, to facilitate the management of information for family doctors and specialists, the server sets a first group identifier and a second group identifier. The identity identifier of a family doctor is associated with the first group identifier, and the identity identifier of a specialist doctor is associated with the second group identifier, thereby achieving grouped management of doctor information. The group corresponding to the first group identifier is called the first group, and the group corresponding to the second group identifier is called the second group. Each doctor's information within a group may include the device information for logging into the server and their current status. For a family doctor, the doctor's information also includes the user identity identifier bound to that doctor. The device used by the family doctor to log into the server can be collectively referred to as the first terminal, the device used by the specialist doctor to log into the server can be collectively referred to as the second terminal, and the device used by the user to log into the server through "Xiaoju Health" can be referred to as the user terminal.

[0062] In some embodiments, regular VIP users can be further divided into two categories: those who know the cause of their illness and those who do not. It should be noted that the same user may fall into different categories in two consultations. For example, in one consultation, a user may know their illness is a cold, while in another, the user may feel unwell but not know the cause. Of course, even if a user knows the cause of their illness, the server can be controlled to treat them as if they didn't know the cause, to avoid inaccurate diagnosis and poor consultation results.

[0063] Taking the "Xiaoju Health" application as an example, in order to realize online consultation, the server may include a rights and benefits module, a medical guide module, a doctor scheduling module, a video call module, an account module, and a consultation module.

[0064] In some embodiments, the rights module stores rights information for various types of users. This rights information may include the user's name, user type, remaining consultation count, and rights validity period for each account's patient. User types may include Super VIP, Regular VIP, and Non-VIP. Each piece of rights information corresponds to a user ID (Identity document). In some embodiments, a user may create only one patient under an account. In this case, the user identity document corresponds to one patient, and the user name in the account's rights information is either the name entered by the user when creating the patient or a nickname randomly generated by the module.

[0065] In some embodiments, a user can create multiple patients under one account. In this case, the user identifier corresponds to multiple patients. For ease of management, the account's benefits information is divided into multiple sub-information entries, each corresponding to a patient. These sub-information entries include the patient's user name, user type, remaining consultation attempts, and benefit validity period. Each patient's user type, remaining consultation attempts, and benefit validity period are identical. For example, if the account has 10 remaining consultation attempts after recharging, then each patient's benefits information will show 10 remaining consultation attempts. If one patient uses one consultation attempt, then each patient's benefits information will show 9 remaining consultation attempts.

[0066] In some embodiments, the account module stores the user identifier of each user's account and the user identifier of each doctor's account, and can provide login functionality for each user's account and the doctor's account.

[0067] In some embodiments, the patient guidance module is used to automatically match departments based on the patient's condition description information from the display device, or the patient guide can manually match departments based on the condition description information. The patient guide is a doctor specifically assigned to match departments for users; they can also be called a health manager or health administrator. For ease of description, the patient guide can also be referred to as a third-party doctor, and the device used by the patient guide to log in to the server can be called a third-party terminal.

[0068] In some embodiments, the doctor scheduling module is used to match a doctor in the corresponding department for the user based on a doctor scheduling request sent by the display device or a doctor scheduling request sent by the patient guidance module.

[0069] In some embodiments, the video call module is used to establish a communication connection between the display device of the user login account module and the display device of the doctor login account module, so as to enable video calls between the user and the doctor.

[0070] In some embodiments, the consultation module is used to implement functions such as doctor consultation and consultation record management.

[0071] Both Super VIP users and regular VIP users can log in to the consultation application on their respective display devices, and then make the display devices interact with the server to realize video consultation.

[0072] In some embodiments, a diagnostic method performed on a display device may be referred to Figure 2 It includes the following steps:

[0073] Step S101: After entering the consultation application, query the server for the rights and interests information of the logged-in users, including the user type.

[0074] In some embodiments, the rights and benefits information may include user type, consultation validity period, and number of consultations.

[0075] In some embodiments, the patient control can be set on the homepage of the consultation application or on the trigger interface of the consultation control. The trigger interface is the patient selection interface, where users can click on a patient control to conduct a consultation. This makes it easier for the server to associate the consultation record with the patient when storing the consultation record of this consultation.

[0076] Step S102: If the user type is the second type, upon receiving the trigger instruction from the patient control in the consultation application, a second consultation request including the user type but excluding the causal parameter is sent to the server according to the trigger instruction not containing the causal parameter. This allows the server to control the second business unit to establish a consultation process with the display device, receive the ailment description information input by the user, and send the ailment description information to the server. This allows the server to obtain the target department information fed back by the second business unit based on the ailment description information, and allows the server to control the second terminal and the display device to establish a second video consultation process.

[0077] In some embodiments, if a user of the second type logs into the consultation application, the consultation application can display a cause option in the patient control. If the user selects the cause option, the triggering instruction of the patient control will include the cause parameter after the patient is triggered. If the user does not select the cause option, the triggering instruction of the patient control will not include the cause parameter after the patient is triggered.

[0078] In some embodiments, the second business unit of the server is a medical guidance desk module, and the first business unit is a doctor scheduling module.

[0079] In some embodiments, a user can provide a description of their condition to the second business unit via a display device. The second business unit can intelligently calculate the target department that the user needs to access based on preset algorithm rules. Alternatively, the patient guide can log in to the server and analyze the description of the condition on the second business unit to obtain the target department.

[0080] Step S103: If the user type is the second type, when the trigger instruction of the patient control in the consultation application is received, if the trigger instruction contains etiology parameters, a department selection interface containing multiple department controls is displayed. After receiving the trigger instruction of one of the department controls, the target department information is obtained according to the trigger instruction of the department control, and the target department information is sent to the server so that the server controls the second terminal and the user terminal to establish a second video consultation process.

[0081] In some embodiments, the interface data of the department selection interface may be stored in the local data of the consultation application on the display device, or it may be obtained by the display device sending a request for the interface data to the server after receiving a trigger instruction from the patient's control.

[0082] Regardless of whether the target department information is obtained by the display device based on the department control triggered by the user, or by the second business unit, after obtaining the target department information, the server can assign a doctor in the corresponding department to receive the user.

[0083] Additionally, for the first type of user, the patient selection interface displayed on the display device does not include a cause of illness option in the patient control. A user can click on a patient control, and the display device generates a first consultation request containing the user's identity and user type. This consultation request is then sent to the server, enabling the server to control a first terminal to establish a first video consultation process with the display device.

[0084] In some embodiments, a patient reception method executed on the server may be referred to Figure 3 It includes the following steps:

[0085] Step S201: Receive a consultation request from the user terminal, the consultation request including the user's user identity and user type.

[0086] In some embodiments, after receiving a consultation request from a user terminal, the server will verify the user's identity and the user's rights data (time, number of times, etc.) stored in the data. If the user has no remaining times or no remaining time, the server will send a reminder message to the user.

[0087] Step S202: If the user type is the first type, send a first consultation command containing the user's identity identifier to the first terminal so that the first terminal and the user terminal establish a first video consultation process, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship.

[0088] For the first type of user consultation, the server allocates a first terminal from the terminal group corresponding to the first group identifier to establish a first video consultation process with the user terminal, so that the family doctor of the first terminal can receive the user. Specifically, when allocating the first terminal, the server prioritizes allocating the first terminal of the family doctor bound to the user's identity identifier. If the current status of the first terminals of all family doctors bound to the user's identity identifier is offline, then the server allocates a first terminal of an unbound but online family doctor to the user.

[0089] In some embodiments, when the server controls the communication connection between the user terminal and the first terminal, it first adds the user's consultation task to the task list of the first terminal. When the user's consultation task is at the top of the task list, the user terminal then establishes a communication connection with the first terminal. Similarly, when the server controls the communication connection between the user terminal and the second terminal, it first adds the user's consultation task to the task list of the second terminal. When the user's consultation task is at the top of the task list, the user terminal then establishes a communication connection with the second terminal. The consultation task may include a session identifier, which is associated with the user's identity identifier and represents a single consultation process for a user. This session identifier can be generated and returned to the consultation application by the server after the user logs in once. The consultation application can carry this session identifier when sending data to the server subsequently, allowing the server to manage the user's consultation matters based on the session identifier, such as assigning a doctor.

[0090] Step S203: If the user type is the second type, send a triage command containing the user's identity identifier to the second business unit so that the second business unit can provide the target department information after establishing a consultation process with the user terminal; and send a second reception command to the second terminal based on the received target department information and the user's identity identifier so that the second terminal and the user terminal can establish a second video reception process, wherein the second type indicates that the user has not bound any doctor.

[0091] Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

[0092] To further describe the reception process for the second type of user, Figure 4 A flowchart illustrating a patient reception method according to some embodiments is shown. See also: Figure 4 The method includes the following steps:

[0093] Step S301: Receive a consultation request from a user terminal, wherein the consultation request includes a user identity identifier.

[0094] In some embodiments, after a second type of user clicks the patient control on the user terminal, the user terminal sends a consultation request to the server. The consultation request includes the user's identity identifier, user type, and session identifier.

[0095] Step S302: If the consultation request does not contain etiology parameters, send a triage command containing the user's identity identifier to the second business unit so that the second business unit can provide the target department information after establishing a consultation process with the user terminal; and send a second reception command to the second terminal corresponding to the target department information according to the received target department information and the user's identity identifier so that the second terminal and the user terminal can establish a second video reception process, wherein the second type indicates that the user has not bound any doctor.

[0096] In some embodiments, after receiving a consultation request from a user terminal, the server will confirm whether the consultation request contains the etiology parameter. If there is no etiology parameter, a first triage command is sent to the second business unit. After the second business unit completes the triage of the user terminal and obtains the target department information, the server can obtain a doctor from the second group that corresponds to the target department information, and establish a second video consultation process between the second terminal of the doctor who logged into the server and the user terminal.

[0097] Step S303: If the consultation request includes the etiology parameters, feed back the department selection interface data including multiple department controls to the user terminal, receive the target department information sent by the user terminal, wherein the target department information is obtained by the user terminal according to the department control triggered by the user, and send the second consultation command to the second terminal corresponding to the target department information so that the second terminal and the user terminal establish a second video consultation process.

[0098] In some embodiments, upon receiving a consultation request from a user terminal, the server confirms whether the consultation request contains the etiology parameter. If the etiology parameter is present, a second triage command containing the user's identity and the etiology parameter is sent to the second service unit. This causes the second service unit to send a department selection interface containing multiple department controls to the user terminal after establishing a consultation process with the user terminal, allowing the user to select a target department. After obtaining the target department information, the server can retrieve a doctor from the second group corresponding to the target department information and establish a second video consultation process between the doctor's second terminal (logged into the server) and the user terminal.

[0099] In some embodiments, when the server controls the communication connection between the user terminal and the second terminal, it first adds the user's consultation task to the task list of the second terminal. When the user's consultation task is at the top of the task list, the communication connection between the user terminal and the second terminal is established. Before the consultation task corresponding to the user's identity is at the top of the task list of the second terminal, the server sends consultation waiting interface data to the user terminal, which includes the target department information.

[0100] In some embodiments, for Super VIP users and regular VIP users with a known diagnosis, one method of receiving patients is for the doctor scheduling module to process the doctor scheduling request of the display device. For regular VIP users with an unknown diagnosis, another method of receiving patients is for the medical guidance desk to generate a doctor scheduling request and then send it to the doctor scheduling module for processing.

[0101] The server's diagnostic process will be further described below, using the user's consultation process as an example.

[0102] In some embodiments, if a VIP user, such as user A, clicks "Xiaoju Health" on the display device, a timeline diagram of the consultation process can be seen. Figure 5 .

[0103] like Figure 5 As shown, to enable video consultations for Super VIP users, the server can be configured with functional modules such as a rights module, a doctor scheduling module, a consultation module, a video call module, and an account module. These modules can be set on one or more hardware devices, and this application does not make any specific limitations on this.

[0104] In some embodiments, Super VIP users can access [the app] by clicking "Xiaoju Health" on the display device. Figure 6 The homepage for online consultation shown.

[0105] See Figure 6 This is a schematic diagram of the user interface of a consultation homepage according to some embodiments. Figure 6 As shown, the homepage for online consultation can display the consultation process, consultation rights control 501, video consultation control 502, and consultation record control 503.

[0106] In some embodiments, the consultation process displayed on the consultation homepage may include the following steps: clicking on video consultation, selecting a patient, health manager consultation / triage, doctor consultation, and ending the consultation.

[0107] In some embodiments, users can view historical consultation records by clicking the consultation record control 503.

[0108] In some embodiments, if the user is a Super VIP user, then as follows Figure 6As shown, the consultation privileges control 501 can display a member identifier, which can be "VVIP" indicating that the user is a Super VIP user. If the user is a regular VIP user, the consultation privileges control 501 can display "VIP" indicating that the user is a regular VIP user. If the user is a non-VIP user, the consultation privileges control 501 may not display "VIP". For example, one Super VIP user is user A, one regular VIP user is user B, and another regular VIP user is user C.

[0109] In some embodiments, whether a user is a Super VIP or a regular VIP, the consultation privilege control 501 can display the remaining consultation attempts, the consultation validity period, and an "Instant Renewal" button. Within the consultation validity period, if the number of consultation attempts is not zero, the user can click the video consultation control 502 to start a consultation. If the number of consultation attempts is zero, clicking the video consultation control 502 will display a recharge prompt for available consultation attempts. The user can click the "Instant Renewal" button in the consultation privilege control 501 to recharge consultation attempts.

[0110] In some embodiments, if a user's number of consultations is zero or the validity period has expired, the video consultation control is grayed out. The grayed-out video consultation control executes a different process upon receiving an operation compared to the ungrayed version. In some embodiments, the grayed-out consultation control can receive focus, and upon receiving a confirmation operation, a membership benefits purchase prompt will pop up. This prompt can respond to the user's first operation (exit prompt) or to the user's second operation (entering the membership benefits purchase interface).

[0111] In some embodiments, to facilitate user consultations and doctor appointments, "Xiaoju Health" has two interfaces: one for user interaction and one for doctor interaction. Figure 6 The interface shown is the homepage for online consultations after the user logs in.

[0112] In some embodiments, user A's registered family doctor is Doctor A, and Doctor A's corresponding consultation device is the first terminal. A specialist doctor is Doctor B, and Doctor B's corresponding consultation device is the second terminal. Compared to Doctor B, Doctor A has a smaller maximum consultation capacity, while Doctor B has no maximum consultation capacity. This means that users of Doctor A may have relatively shorter waiting times, while users of Doctor B may have relatively longer waiting times. For example, Doctor A's maximum consultation capacity is 10 people, and Doctor B's maximum is 50 people. During peak consultation periods, Doctor A may have 5 patients, and Doctor B's maximum is 20 people. User A is Doctor A's 5th patient and needs to wait for 4 people to consult before consulting Doctor A. User B is Doctor A's 20th patient and needs to wait for 19 people to consult before consulting Doctor B. Therefore, user A's waiting time is relatively shorter.

[0113] In some embodiments, Doctor A can log in on the first terminal by entering an account and password. Figure 5 The account module can verify the account and password. If the verification is successful, a login result indicating successful login is generated. If the verification fails, a login result indicating failed login is generated. After generating the login result, the login result is returned to the first terminal.

[0114] In some embodiments, the account module may be configured with an online identifier for each doctor. The online identifier is used to indicate the doctor's current status. If a family doctor successfully logs in to the account module, the account module sets the family doctor's current status identifier to online. If a family doctor fails to log in, the account module sets the family doctor's current status identifier to offline.

[0115] In some embodiments, the first terminal may display the doctor's consultation interface upon successful login. For example, this consultation interface may display the user currently requiring consultation, the consultation control, and the remaining number of users requiring consultation. The consultation control is configured to send a consultation request to the consultation module upon triggering, enabling the consultation module to control the user currently requiring consultation to establish a video connection with the first terminal, thus enabling a video call between the doctor and the user.

[0116] In some embodiments, after doctor A successfully logs in, the first terminal can automatically enter the consultation module to display the consultation homepage.

[0117] In some embodiments, the doctor scheduling module does not assign patients to doctor A before doctor A logs in successfully; the doctor scheduling module assigns patients to doctor A only after doctor A logs in successfully.

[0118] In some embodiments, user A can access the "Xiaoju Health" consultation application by clicking "Xiaoju Health" on the user terminal.

[0119] In some embodiments, after a user terminal launches a medical consultation application, if the user has previously logged into the application, the application or an account and password management application on the display device can store the user's previous login username and password. Upon launching the application again, the application can request login from the account module using this username and password, thus eliminating the need for manual login by the user. The account module verifies the username and password sent by the user terminal. If verification is successful, a login result indicating successful login is generated; if verification fails, a login result indicating failed login is generated. After generating the login result, the module returns the login result to the user terminal.

[0120] In some embodiments, after receiving a login result, the user terminal can detect the application's login status. The consultation application can be configured such that if the user is already logged in, the application stores the user's login information on the user terminal; if the user is not logged in, the application does not store login information on the user terminal. The login information, including the user ID, can be extracted from the login result returned by the account module. Therefore, the consultation application can determine whether a user is logged in by detecting login information. If login information is detected, the user's login status is determined to be logged in; if no login information is detected, the user's login status is determined to be not logged in.

[0121] In some embodiments, the online medical consultation application can be configured to set login parameters on the user's terminal. If the user is already logged into the application, the value of the login parameter is the user ID; if the user is not logged into the application, the value of the login parameter is empty. Therefore, the online medical consultation application can determine whether the user is logged in by detecting the login parameter. If the login parameter value is not empty, the user is considered logged in; if the login parameter value is empty, the user is considered not logged in.

[0122] In some embodiments, after the consultation application on the user terminal detects that the login status is logged in, it can send a rights request to the rights module to query the user's rights information, wherein the rights request may include the user ID.

[0123] In some embodiments, after receiving a rights request, the rights module can extract the user ID from the request, query the rights information for that user ID, and return the rights information to the user terminal. The rights information may include the user's name, user type, remaining consultation attempts, and rights validity period. The user type may include Super VIP and Regular.

[0124] In some embodiments, after receiving the benefits information, if the user type in the benefits information is Super VIP, the user A who has logged in can be identified as a Super VIP user, and the benefits information can be displayed accordingly. Figure 6 The interface shown. Among them, in Figure 6 In the interface shown, apart from the content displayed by the consultation rights control 501, which is generated based on the rights information, the other content can be generated based on the data parsed from the installation package when the consultation application is installed on the display device.

[0125] In some embodiments, Figure 6 As shown on the homepage of the online consultation, user A can click the video consultation control 502 to start a video consultation.

[0126] In some embodiments, if user A has not created a patient in the online consultation application, after clicking the video consultation control, the display device will not find the patient's data in the local application data. Instead, it will generate and display a patient creation interface. In this interface, the user can create at least one patient. The information a user needs to input to create a patient includes the patient's name, gender, age, etc. After creation, the display device can save the information of each patient in the local application data and upload it to the account module. In some embodiments, the display device may not store patient information locally. When the display device logs into the online consultation application, the login result returned by the account module includes the information of all patients.

[0127] In some embodiments, after user A clicks the video consultation control, the display device can obtain information about all patients, and then generate and display information based on this information. Figure 7 The patient selection interface shown can include multiple patient controls 504, each of which can display information about a patient. Users can switch between the currently selected patient controls to select a patient for treatment.

[0128] In some embodiments, after user A selects a patient, for example, patient 3, and the user terminal's consultation application determines that user A is a Super VIP user, it can send a first consultation request to the server's consultation interface. This first consultation request is processed by the consultation module. The consultation module can generate a consultation task based on the first consultation request and send the consultation task to the doctor scheduling module for processing.

[0129] In some embodiments, the doctor scheduling module can query the ID of the family doctor bound to the user ID of user A. If the bound family doctor ID is found to be the ID of doctor A, the module can then query the account module to see if doctor A is online. If online, user A's consultation task can be added to doctor A's task list.

[0130] In some embodiments, when user A's consultation task is first in the task list, the doctor scheduling module may send a consultation access request to the consultation module, wherein the consultation access request may include the user ID.

[0131] In some embodiments, after receiving a consultation access request, the consultation module may send a first consultation command to the first terminal.

[0132] In some embodiments, after receiving the first consultation command, the first terminal can update the consultation interface to display user A's name and consultation controls. If the doctor agrees to begin seeing the user, they can click the consultation controls on the consultation interface. After receiving the trigger instruction from the consultation controls, the first terminal can send a consultation request to the consultation module and decrement the number of remaining users requiring consultation by one.

[0133] In some embodiments, after receiving a consultation request from the first terminal, the consultation module can return an access result to the doctor scheduling module. The access result may indicate that user A has been connected, thereby enabling the doctor scheduling module to adjust the doctor's task list based on the access result. The adjustment includes: moving the order of consultation tasks for users after user A forward by one position, and reducing the number of remaining users to be consulted by one.

[0134] In some embodiments, after receiving a consultation request from the first terminal, the consultation module can send a video call request to the video call module. This video call request may include the user ID of user A and the ID of doctor A. Upon receiving the video call request, the video call module can query the account module for the currently logged-in devices of user A and doctor A based on these two IDs, obtaining the communication addresses (e.g., IP addresses) of the user terminal and the first terminal. Then, it dials the first terminal and the user terminal respectively to obtain the audio and video collected by the user terminal and the first terminal, transmitting the audio and video collected by the user terminal to the first terminal in real time, thereby establishing video connections with both the user terminal and the first terminal, enabling a video call between user A and doctor A.

[0135] See Figure 8 This is a schematic diagram of a video call interface provided in an embodiment of this application. Figure 8 As shown, the video call interface can display doctor information control 505, photo upload control 506, end consultation control 507, close camera control 508, and user window control 509.

[0136] In some embodiments, the doctor information control 505 displays descriptive information about the doctor in a call window in a layer below the control, allowing the user to know the doctor's name and other information.

[0137] In some embodiments, after the photo upload control is selected, options such as local image and camera capture can be displayed at the top of the current interface to allow users to enter photos through different methods. The method of determining which photo to enter can refer to relevant technologies. After the user selects the photo to be entered, the user terminal uploads the photo to the video call room, and the doctor's terminal retrieves the photo from the video call room for viewing.

[0138] In some embodiments, after a user uploads a photo, a prompt message appears on the doctor's terminal interface asking them to view the photo. After the doctor confirms the viewing, a new overlay is created above the current interface to display the photo, while the video call continues. This facilitates the doctor's consultation. In some embodiments, the newly created layer can have an exit control or preset exit software logic. Upon receiving the doctor's action to exit the control or upon receiving the preset action, the overlay is deactivated, restoring the original foreground display.

[0139] In some embodiments, after a user clicks the "End Consultation" control 507, the user terminal can send an "End Consultation" request to the consultation module. This request includes user A's user ID. Upon receiving the "End Consultation" request, the consultation module sends an "End Consultation" message to the doctor scheduling module, which then adjusts doctor A's task list based on this message.

[0140] In the above embodiment, the consultation module controls the video call module to start a video call based on the consultation request from the first terminal.

[0141] In some embodiments, the consultation module may send a consultation notification to the first terminal, which may include the communication address of the device currently logged into by user A. Based on the consultation notification, the first terminal may directly initiate a video call request to the user terminal through the video call module.

[0142] Depend on Figure 5 It is evident that by assigning a family doctor with a smaller number of patients to Super VIP users, the waiting time for Super VIP users to see a doctor is shorter compared to that of regular VIP users.

[0143] In some embodiments, if a regular VIP user, such as user B, clicks "Xiaoju Health" on a display device, the display device will show the consultation homepage and the method for the user to conduct a consultation. (See also: [link to relevant documentation]). Figure 9 This is a timeline diagram of a patient reception process.

[0144] like Figure 9 As shown, to enable video consultations, the server can be configured with functional modules such as a rights module, a patient guidance module, a doctor scheduling module, a consultation module, a video call module, and an account module. These modules can be set on one or more hardware devices, and this application does not make any specific limitations on them.

[0145] In some embodiments, a regular VIP user, such as user B, can access the consultation homepage after clicking "Xiaoju Health" on the display device.

[0146] In some embodiments, a doctor who provides consultation services to ordinary VIP users is Doctor B, for example, Doctor B is a doctor in the pediatrics department.

[0147] In some embodiments, on the homepage of the online consultation, user B can click the video consultation control to start a video consultation.

[0148] In some embodiments, after user B clicks the video consultation control, the display device can generate a message based on whether the user type is a regular VIP. Figure 10 The patient selection interface is shown below. Figure 10 As shown, each patient control can display a "Confirmed Condition" option, which corresponds to a cause parameter. If the user knows the department to consult regarding the patient's condition, they can check this option; if the user does not know the department to consult regarding the patient's condition, they can leave this option unchecked.

[0149] In some embodiments, user B in Figure 10 If the "Confirmed Condition" option is not selected, after confirming the selected patient, the display device can detect the user's identity category, i.e., user type. If the detected user type is "ordinary," it further detects the etiology parameters. An empty etiology parameter indicates that the user has not selected the "Confirmed Condition" option; a non-empty etiology parameter indicates that the user has selected the "Confirmed Condition" option. Since user B has not selected the "Confirmed Condition" option, the display device can detect that the etiology parameters are empty. At this time, the display device can send a second consultation request to the server's consultation interface. This second consultation request includes the user ID but does not include the etiology parameters. After receiving this second consultation request, the consultation module sends a first triage command to the triage module. This first triage command may include the user ID but does not include the etiology parameters.

[0150] In some embodiments, after receiving a first triage command, the triage module can establish a first consultation process with the user terminal if the first triage command does not contain etiology parameters. After the first consultation process is established, the user can input a description of the illness on the user terminal, and the user terminal sends the description of the illness to the triage module. The triage staff can manually determine the target department information or the triage module can intelligently determine the target department information. The triage module returns the target department information to the consultation module, and the consultation module sends a consultation task to the doctor scheduling module based on the target department information. The consultation task may contain a session identifier.

[0151] In some embodiments, after receiving the consultation task, the doctor scheduling module can query the current status identifier of the doctors in the target department to determine whether the doctors in the target department are online, thereby selecting a doctor in the target department with fewer remaining patients to see, such as Doctor B. The module adds user B's consultation task to Doctor B's task list, generates waiting screen data, and returns the waiting screen data to the user terminal, enabling the user terminal to generate... Figure 11 The patient waiting interface shown. Figure 11As shown, the waiting list interface displays the number of people waiting to be seen before user B.

[0152] In some embodiments, the waiting interface may also display the estimated waiting time for user B, which can be calculated from the average consultation time of a single user. The average consultation time of a single user can be obtained by the doctor scheduling module based on the update time of the queue order in the previous task list.

[0153] In some embodiments, when user B is ranked first in the task list, doctor B will see user B. The process and interface for seeing user B can be found in the description of the process for seeing user A, and will not be repeated here.

[0154] In some embodiments, if a regular VIP user, such as user C, clicks "Xiaoju Health" on a display device, the display device will show the consultation homepage and the method for the user to conduct a consultation. (See also: [link to relevant documentation]). Figure 12 This is a timeline diagram of a patient reception process.

[0155] like Figure 12 As shown, to enable video consultations, the server can be configured with functional modules such as a rights module, a patient guidance module, a doctor scheduling module, a consultation module, a video call module, and an account module. These modules can be set on one or more hardware devices, and this application does not make any specific limitations on them.

[0156] In some embodiments, a regular VIP user, such as user C, can access the consultation homepage after clicking "Xiaoju Health" on the display device.

[0157] In some embodiments, a doctor who provides consultation services to ordinary VIP users is Doctor B, for example, Doctor B is a doctor in the ophthalmology department.

[0158] In some embodiments, the display device that Doctor B enters for consultation may be a second terminal.

[0159] In some embodiments, the interface for Doctor B to access the consultation module and receive patients can be found in the description of Doctor A, and will not be repeated here.

[0160] In some embodiments, user C can access the "Xiaoju Health" consultation application by clicking "Xiaoju Health" on the user terminal.

[0161] In some embodiments, on the homepage of the online consultation, user C can click the video consultation control to start a video consultation.

[0162] In some embodiments, after user C clicks the video consultation control, the display device can generate a message based on whether the user type is a regular VIP. Figure 13 The patient selection interface is shown below. Figure 13As shown, each patient control can display a "Confirmed Condition" option, which corresponds to a cause parameter. If the user knows the department to consult regarding the patient's condition, they can check this option; if the user does not know the department to consult regarding the patient's condition, they can leave this option unchecked.

[0163] In some embodiments, user C in Figure 13 After selecting the "Confirmed Condition" option and confirming the selected patient, the display device can detect the user's identity category, i.e., user type. If the detected user type is "ordinary," it further detects the etiology parameters. An empty etiology parameter indicates that the user has not selected the "Confirmed Condition" option, while a non-empty etiology parameter indicates that the user has selected the "Confirmed Condition" option. Since user C has selected the "Confirmed Condition" option, the display device can detect that the etiology parameters are not empty. At this time, the display device can send a third consultation request to the consultation module. This consultation request contains the etiology parameters and the user's identity identifier. Based on the etiology parameters contained in the consultation request, the consultation module sends a second triage command to the guidance desk module. The guidance desk module establishes a second consultation process with the user terminal based on the etiology parameters contained in the triage command, and then sends department selection interface data containing multiple department controls to the user terminal through this process, causing the user terminal to display... Figure 14 The department selection interface shown.

[0164] See Figure 14 On the department selection interface, user C can select a department as the target department for this consultation. Figure 14 In the example, user C selected ophthalmology as the target department.

[0165] In some embodiments, after receiving the target department selected by the user, the user terminal may send the target department information to the medical guidance module.

[0166] In some embodiments, after receiving the target department information, the guidance desk module can send the target department information to the consultation module. The consultation module then sends a consultation task to the doctor scheduling module based on the target department information. Upon receiving the consultation task, the doctor scheduling module can query the current status of doctors in the target department to determine if the doctors in that department are online. This allows it to select a doctor in that department with fewer remaining patients to see, such as Doctor B. The consultation task for user C is added to Doctor B's task list, and a waiting list interface is generated. This waiting list interface data is then returned to the user terminal, enabling the user terminal to generate... Figure 15 The patient waiting interface shown. Figure 15 As shown, the waiting screen displays the number of people waiting for treatment before user B, as well as the doctor corresponding to the user's task list.

[0167] In some embodiments, the waiting interface may also display the estimated waiting time for user C, which can be calculated from the average consultation time of a single user. The average consultation time of a single user can be obtained by the doctor scheduling module based on the update time of the queue order in the previous task list.

[0168] In some embodiments, when user C is ranked first in the task list, doctor B will see user C. The process and interface for seeing user C can be found in the description of the process for seeing user A, and will not be repeated here.

[0169] In summary, for regular VIP users, if they are unsure which department they need, the system needs to interact with them through the patient guidance module to determine the appropriate department. If the user already knows the department, they can directly select it. Compared to Super VIP users, regular VIP users are assigned doctors with a higher patient capacity, so their waiting time may be relatively longer. In some embodiments, the distinction between family doctors and general practitioners may not be made, meaning the doctor assigned to a Super VIP user by the doctor dispatch module may be the same as the doctor assigned to a regular VIP user. In this case, Super VIP users enjoy priority access. When a Super VIP user's display device initiates a doctor dispatch request, the doctor dispatch module, after determining a doctor for the Super VIP user, sets the Super VIP user's information to the first or Nth position in that doctor's task list, or prioritizes the Super VIP user's consultation, allowing them to skip the queue.

[0170] As can be seen from the above embodiments, in this embodiment, the server divides doctors into two groups. For users of the first type, they can be bound to doctors in the first group. The server controls the doctors in the first group to see users of the first type, thereby increasing the probability that users will see their bound doctor multiple times, solving the problem of different doctors for each consultation. For users of the second type, no doctor is bound to them. The server selects a doctor from the second group to see the user based on the target department they need to visit, thus meeting the user's consultation needs. This embodiment meets the consultation needs of different types of users and improves the consultation experience. A consultation limit can be set for doctors in the first group. This application embodiment displays a department selection interface based on the trigger command of the patient control containing etiology parameters, allowing the user to select a department to consult. Conversely, if the trigger command of the patient control does not contain etiology parameters, a triage interface is displayed, allowing the user to input a description of their condition to determine the appropriate department. This allows users to directly select the appropriate department when they know which department they should consult, and to input a description of their condition into the display device for server analysis to determine the correct department when they are unsure. This enables the server to quickly assign a suitable doctor to the user, improving consultation efficiency.

[0171] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0172] For ease of explanation, the above description has been provided in conjunction with specific embodiments. However, the above exemplary discussion is not intended to be exhaustive or to limit the embodiments to the specific forms disclosed above. Various modifications and variations can be obtained based on the above teachings. The selection and description of the above embodiments are for the purpose of better explaining the principles and practical applications, thereby enabling those skilled in the art to better utilize the described embodiments and various different variations of embodiments suitable for specific use considerations.

Claims

1. A server, characterized in that, The server is configured as follows: Receive a consultation request from a user terminal, the consultation request including the user's user identity identifier and user type; If the user type is the first type, a first consultation command containing the user's identity identifier is sent to the first terminal to enable the first terminal and the user terminal to establish a first video consultation process, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship; If the user type is the second type, a triage command containing the user's identity identifier is sent to the second business unit so that after the second business unit establishes a consultation process with the user terminal, it can provide the target department information based on the information fed back by the user terminal; and a second reception command is sent to the second terminal according to the received target department information and the user's identity identifier so that the second terminal and the user terminal can establish a second video reception process, wherein the second type indicates that the user has not bound any doctor; Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

2. The server according to claim 1, characterized in that, The consultation request corresponding to the first type further includes a first session identifier, and sending a first consultation command containing the user identity identifier to the first terminal, including: Add the consultation task corresponding to the user's identity identifier to the task list of the first terminal; When the consultation task is at the top of the task list of the first terminal, a first consultation command containing the user's identity identifier is sent to the first terminal.

3. The server according to claim 2, characterized in that, Add the consultation task corresponding to the user to the task list of the first terminal, including: Obtain the current status of all first terminals of the doctor bound in the terminal group corresponding to the first group identifier, wherein the first group identifier is used to represent the first group; If at least one of the first terminals of the bound doctor is currently online, the consultation task corresponding to the user is added to the task list of any first terminal that is currently online. If all of the first terminals of the bound doctor are currently offline, the consultation task corresponding to the user will be randomly added to the task list of the first terminal of a doctor in the first group whose user identity is not bound and who is online.

4. The server according to claim 1, characterized in that, Sending a triage command containing the user's identity identifier to the second business unit, so that the second business unit can provide the target department information after establishing a consultation process with the user terminal, including: If the consultation request does not contain etiology parameters, a first triage command containing the user's identity identifier and not containing etiology parameters is sent to the second business unit, so that after the second business unit establishes a consultation process with the user terminal, it can provide feedback on the target department information based on the user's input description of the illness. If the consultation request includes etiology parameters, a second triage command containing the user's identity and etiology parameters is sent to the second business unit. This allows the second business unit to send department selection interface data containing multiple department controls to the user terminal after establishing a consultation process with the user terminal. The second business unit then feeds back the target department information obtained by the user terminal based on the department controls triggered by the user. The triage command includes the first triage command and the second triage command.

5. The server according to claim 1, characterized in that, The server also stores the user's medical treatment rights information, including the number of consultations and the validity period of each consultation. The server is further configured to: Upon receiving the consultation request, query the number of consultations and the validity period of the consultation for the user's identity identifier; If the number of consultations for the user's identity is not zero and the current time is within the consultation validity period, the consultation request will be processed according to the user type.

6. The server according to claim 1, characterized in that, The server is also configured to: If the user type is the first type, at the end of the consultation, if the doctor on the first terminal is not bound to the user, a prompt message is sent to the user terminal asking whether the user is bound to the doctor on the first terminal. If a confirmation message corresponding to the prompt message is received, the doctor on the first terminal is bound to the user.

7. A display device, characterized in that, include: monitor; The controller, which is communicatively connected to the display, is configured to: After entering the consultation application, the system queries the account module of the server for the rights and interests information of logged-in users, including user type; If the user type is the first type, when the trigger instruction of the patient control in the consultation application is received, a first consultation request including the user type is sent to the server, so that the server controls the first terminal to establish a first video consultation process with the display device, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship; If the user type is the second type, when the trigger instruction of the patient control in the consultation application is received, a second consultation request including the user type is sent to the server, so that the server controls the second business unit to feed back the target department information based on the information fed back by the display device after establishing a consultation process with the display device, and controls the second terminal to establish a second video consultation process with the display device according to the received target department information. The second type indicates that the user has not bound any doctor. Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

8. The display device according to claim 7, characterized in that, Also includes: A camera component, communicatively connected to the controller, is used to capture images of the user.

9. A method for receiving patients, characterized in that, The methods for receiving patients include: Receive a consultation request from a user terminal, the consultation request including the user's user identity identifier and user type; If the user type is the first type, a first consultation command containing the user's identity identifier is sent to the first terminal to enable the first terminal and the user terminal to establish a first video consultation process, wherein the first type indicates that the user and at least one doctor in the first group have a binding relationship; If the user type is the second type, a triage command containing the user's identity identifier is sent to the second business unit so that after the second business unit establishes a consultation process with the user terminal, it can provide the target department information based on the information fed back by the user terminal; and a second reception command is sent to the second terminal according to the received target department information and the user's identity identifier so that the second terminal and the user terminal can establish a second video reception process, wherein the second type indicates that the user has not bound any doctor; Wherein, the first terminal refers to the terminal corresponding to the doctor in the first group, the second business unit refers to the business unit that determines the target department information based on the condition entered by the user during the consultation process, the second terminal refers to the terminal corresponding to the doctor in the second group, and the doctor in the second group is the doctor who only sees the second type of user.

10. The patient reception method according to claim 9, characterized in that, Sending a triage command containing the user's identity identifier to the second business unit, so that the second business unit can provide the target department information after establishing a consultation process with the user terminal, including: If the consultation request does not contain etiology parameters, a first triage command containing the user's identity identifier and not containing etiology parameters is sent to the second business unit, so that after the second business unit establishes a consultation process with the user terminal, it can provide feedback on the target department information based on the user's input description of the illness. If the consultation request includes etiology parameters, a second triage command containing the user's identity and etiology parameters is sent to the second business unit. This allows the second business unit to send department selection interface data containing multiple department controls to the user terminal after establishing a consultation process with the user terminal. The second business unit then feeds back the target department information obtained by the user terminal based on the department controls triggered by the user. The triage command includes the first triage command and the second triage command.

Images