[go: up one dir, main page]

CN109543863B - Medical task management method, server and storage medium - Google Patents

Medical task management method, server and storage medium Download PDF

Info

Publication number
CN109543863B
CN109543863B CN201811265505.5A CN201811265505A CN109543863B CN 109543863 B CN109543863 B CN 109543863B CN 201811265505 A CN201811265505 A CN 201811265505A CN 109543863 B CN109543863 B CN 109543863B
Authority
CN
China
Prior art keywords
doctor
diagnosis
recommended
target
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201811265505.5A
Other languages
Chinese (zh)
Other versions
CN109543863A (en
Inventor
郑毅
汪泓
张鑫宇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Ping An Medical Health Technology Service Co Ltd
Original Assignee
Shenzhen Ping An Medical Health Technology Service Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Ping An Medical Health Technology Service Co Ltd filed Critical Shenzhen Ping An Medical Health Technology Service Co Ltd
Priority to CN201811265505.5A priority Critical patent/CN109543863B/en
Publication of CN109543863A publication Critical patent/CN109543863A/en
Application granted granted Critical
Publication of CN109543863B publication Critical patent/CN109543863B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H80/00ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Business, Economics & Management (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Epidemiology (AREA)
  • Tourism & Hospitality (AREA)
  • Biomedical Technology (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Pathology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

The embodiment of the application discloses a medical task management method, a server and a computer readable storage medium, and relates to a data analysis technology for medical data, wherein the method comprises the following steps: receiving a diagnosis request from a user terminal; determining a target user according to a user label in the visit request, and determining a recommended doctor category according to the illness state description content in the visit request; acquiring a historical diagnosis record of a target user, and judging whether a historical doctor in the historical diagnosis record belongs to the recommended doctor category; if the information does not belong to the category, analyzing historical diagnosis records and illness state description contents according to analysis rules to determine diagnosis labels, and determining target recommended doctors from doctors of the recommended doctor category according to the corresponding relation between the diagnosis labels and the recommended doctors; the recommendation information containing the target recommended doctor is generated, and the recommendation information is sent to the user terminal, so that the target recommended doctor can be reserved for the user, more accurate and efficient reservation registration service can be realized, and the medical treatment process is integrated.

Description

Medical task management method, server and storage medium
Technical Field
The present application relates to the field of data processing technologies, and in particular, to a medical task management method, a server, and a storage medium.
Background
Along with the rapid development of modern medical science and technology, the treatment problem of a plurality of diseases is solved. In the current medical system, if a patient needs to visit a doctor, the patient needs to visit a hospital or a medical institution in person, and a doctor performs inquiry, clinical symptom examination and the like on the patient to make a diagnosis result, and along with the development of electronic information technology, the medical information technology is correspondingly developed. In some large-scale advanced hospitals or medical institutions, electronic medical records and online appointment registration are adopted, but at present, users can only select registration for treatment according to the watch and introduction of doctors, and the medical treatment process is still complicated.
Disclosure of Invention
The embodiment of the application provides a medical task management method, a server and a computer readable storage medium, which can realize more accurate and efficient appointment registration service, and integrate the medical process more conveniently.
In a first aspect, an embodiment of the present application provides a method for managing a medical task, where the method includes:
receiving a diagnosis request from a user terminal, wherein the diagnosis request comprises a user tag and illness state description content;
Determining a target user according to the user tag, and determining a recommended doctor category according to the illness state description content;
acquiring a history diagnosis record of the target user, and judging whether a history doctor in the history diagnosis record belongs to the recommended doctor category;
if the historic doctor belongs to the recommended doctor category, determining the historic doctor as a target recommended doctor;
If the history doctor does not belong to the recommended doctor category, analyzing the history diagnosis record and the illness state description content according to an analysis rule to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label as the target recommended doctor from doctors in the recommended doctor category according to the corresponding relation between the diagnosis label and the recommended doctor;
Generating recommendation information containing the target recommendation doctor, and sending the recommendation information to the user terminal;
When receiving a reservation request of the target recommended doctor from the user terminal, acquiring a reserved time table of the target recommended doctor, and sending the reserved time table to the user terminal;
And receiving reservation information from the user terminal, and generating reservation success information if reservation time in the reservation information is idle time in the reservation time table.
As one possible implementation, the historical diagnostic record includes an electronic medical record and/or an electronic prescription of the target user;
After the reservation success information is generated, the method further comprises:
and acquiring a user account of the target recommended doctor, and sending the electronic medical record and/or the electronic prescription to the user account.
As a possible implementation manner, the determining a recommended doctor category according to the condition description content includes:
and determining a visit department according to the condition keywords in the condition description content, and determining that the doctor belonging to the visit department is the recommended doctor category.
As a possible implementation manner, after the generating the reservation information, the method further includes:
Acquiring diagnosis data of the target user, identifying a target field in the diagnosis data to determine a diagnosis task, and generating task information of the diagnosis task, wherein the task information comprises basic information of staff of the diagnosis task;
And sending the task information to the user terminal.
As a possible implementation, the visit request includes a reservation request to a designated doctor, the method further comprising:
Judging whether the appointed doctor belongs to the recommended doctor category or not;
If the specific doctor is the one, determining that the specific doctor is matched with the disease description content, and executing the step of acquiring the appointment schedule of the specific doctor; and if the diagnosis label does not belong to the diagnosis label, determining that the designated doctor is not matched with the disease description content, and executing the step of analyzing the historical diagnosis record and the disease description content according to analysis rules to determine the diagnosis label.
In a second aspect, an embodiment of the present application provides a server, including: the system comprises a transmission module, a determination module, a judgment module, a recommendation module and a reservation module, wherein:
the transmission module is used for receiving a diagnosis request from the user terminal, wherein the diagnosis request comprises a user tag and illness state description content;
the determining module is used for determining a target user according to the user tag and determining a recommended doctor category according to the illness state description content;
The judging module is used for acquiring a historical diagnosis record of the target user and judging whether a historical doctor in the historical diagnosis record belongs to the recommended doctor category or not;
The recommending module is used for:
If the historic doctor belongs to the recommended doctor category, determining the historic doctor as a target recommended doctor; if the history doctor does not belong to the recommended doctor category, analyzing the history diagnosis record and the illness state description content according to an analysis rule to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label as the target recommended doctor from doctors in the recommended doctor category according to the corresponding relation between the diagnosis label and the recommended doctor;
The transmission module is further used for generating recommendation information containing the target recommendation doctor and sending the recommendation information to the user terminal; when receiving a reservation request of the target recommended doctor from the user terminal, acquiring a reserved time table of the target recommended doctor, and sending the reserved time table to the user terminal;
the reservation module is used for receiving reservation information from the user terminal, and generating reservation success information if reservation time in the reservation information is idle time in the reservation time table.
In a possible implementation manner, the determining module is specifically configured to determine, according to the condition keyword in the condition description, a diagnosis department, and determine that the doctor belonging to the diagnosis department is the recommended doctor category.
In one possible implementation, the server further includes:
The task module is used for acquiring the diagnosis data of the target user, identifying a target field in the diagnosis data to determine a diagnosis task, and generating task information of the diagnosis task, wherein the task information comprises basic information of staff of the diagnosis task;
The transmission module is also used for sending the task information to the user terminal.
In a third aspect, an embodiment of the present application further provides a server, including: a processor, an input device, an output device and a memory, the processor, the input device, the output device and the memory being interconnected, wherein the memory is adapted to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method according to the first aspect and any of its possible embodiments.
In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program comprising program instructions which, when executed by a processor, cause the processor to perform the method of the first aspect and any one of its possible embodiments.
According to the embodiment of the application, the diagnosis request comprises a user tag and illness state description content, a target user is determined according to the user tag, a recommended doctor category is determined according to the illness state description content, then a history diagnosis record of the target user is acquired, whether a history doctor in the history diagnosis record belongs to the recommended doctor category is judged, if the history doctor belongs to the recommended doctor category, the history doctor is determined to be the target recommended doctor, if the history doctor does not belong to the recommended doctor category, the history diagnosis record and the illness state description content are analyzed according to analysis rules to determine a diagnosis tag, then a recommended doctor corresponding to the diagnosis tag is determined to be the target recommended doctor from doctors in the recommended doctor category according to the correspondence between the diagnosis tag and the recommended doctor, recommendation information containing the target recommended doctor is generated, the recommendation information is transmitted to the user terminal, a reservation time table of the target recommended doctor is acquired when a reservation request of the target recommended doctor from the user terminal is received, the reservation time table is transmitted to the user terminal, and then reservation time table is received from the user terminal, if reservation time in the reservation time table is more effective, and the service can be realized more successfully.
Drawings
In order to more clearly illustrate the technical solution of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly described.
Fig. 1 is a schematic flow chart of a medical task management method according to an embodiment of the present application;
Fig. 2 is a flow chart of a method for managing medical tasks according to another embodiment of the present application;
fig. 3 is a schematic structural diagram of a server according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of another server according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the application. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments.
All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
The terms first, second and the like in the description and in the claims and in the above-described figures are used for distinguishing between different objects and not necessarily for describing a sequential or chronological order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus.
It is also to be understood that the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
It should be further understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
As used in this specification and the appended claims, the term "if" may be interpreted as "when..once" or "in response to a determination" or "in response to detection" depending on the context. Similarly, the phrase "if a determination" or "if a [ described condition or event ] is detected" may be interpreted in the context of meaning "upon determination" or "in response to determination" or "upon detection of a [ described condition or event ]" or "in response to detection of a [ described condition or event ]".
In order to better understand the embodiments of the present application, a method for applying the embodiments of the present application will be described below.
The user terminal mentioned in the embodiment of the present application is a device capable of communicating with a server, which is also referred to as a server, and is a device for providing a computing service, and may allow multiple user terminals to access. The User terminal may be a Mobile terminal, including various handheld devices, wearable devices, computing devices or other processing devices connected to a wireless modem, and various forms of User Equipment (UE), mobile Station (MS), etc.
The end user may connect to the server (end server) at any user terminal having a remote desktop connection. Such as: when an end user connects to a microsoft end server, the server will assign a separate session to the user, providing a desktop environment or a separate application environment for the end user to use. The user terminal (client) of the user, such as a computer, does not process the running application program, but simply transmits the click signals of the keyboard and the mouse to the server, and all the processing operations are completed by the server.
Referring to fig. 1, a schematic flow chart of a medical task management method according to an embodiment of the present application may be applied to a server, where the method may include:
101. A request for a visit from a user terminal is received, the request for a visit including a user tag and a condition description.
Among other things, the above-described user terminals include, but are not limited to, other portable devices such as mobile phones, laptop computers, or tablet computers having touch-sensitive surfaces (e.g., touch screen displays and/or touchpads). It should also be appreciated that in some embodiments, the device is not a portable communication device, but a desktop computer having a touch-sensitive surface (e.g., a touch screen display and/or a touch pad).
In the embodiment of the present application, the above-mentioned request for diagnosis may be a request sent by a user through a user terminal, where the request for diagnosis includes a user tag and a disease description content.
In particular, the above-mentioned user tag may be understood as identity information representing a user. For example, the user tag may be a combination of one or more of an identification number, a name, a gender, a telephone number, and/or a bank card number. It will be appreciated that the specific content of the user tag described above is not limiting in terms of embodiments of the present application.
Specifically, the above description of the condition is understood to be a description of the specific condition of the user. Specifically, the above-mentioned condition description may be that of gender, age, condition, medical history, condition description, diet, medication record, etc. and the condition. For example, the above-mentioned condition may be described in terms of "male or female, 71 years old, diabetes about 6/7 years old, blood sugar level in a controlled range, usual attention to diet, getting thinner and thinner, daily administration of metformin hydrochloride enteric-coated tablet and glimepiride tablet", etc. Or it should be understood that the embodiments of the application are not limited to the specific description of the above-mentioned disease states.
102. And determining a target user according to the user label, and determining a recommended doctor category according to the illness state description content.
In the embodiment of the present application, the server may determine the target user according to the user tag information carried by the diagnosis request. The target user refers to an owner applying for the diagnosis request, and can be understood as a user uploading the diagnosis request, the server can inquire whether the user exists in the server according to the user tag information, and if the user exists, the user is determined to be the target user; if the user does not exist, the server needs to store the user tag information of the user. It will be appreciated that in the embodiments of the present application, the specific implementation of how to determine the target user is not limited.
In the embodiment of the present application, the server may determine the recommended doctor category according to the condition description content carried by the doctor-seeing request. The recommended doctor category may be doctor of different diagnosis department, and may be doctor of different department such as surgery, ophthalmology, otorhinolaryngology, internal medicine, neurology, plastic surgery or pediatrics. Specifically, the server may establish different disease databases according to different diagnoses department, and when the server receives the disease description contents, find a diagnosis department doctor matching with the disease description contents by searching the disease database, and the diagnosis department doctor is the recommended doctor category. By implementing the application, the server can preliminarily determine the recommended doctor category for the user, and improves the appointment efficiency of the doctor. It will be appreciated that embodiments of the present application are not particularly limited to the specific implementation of the server determining recommended doctor categories described above.
103. And acquiring a history diagnosis record of the target user, and judging whether a history doctor in the history diagnosis record belongs to the recommended doctor category.
In the embodiment of the application, the server can acquire the historical diagnosis record of the target user. The history diagnostic record may include an electronic medical record and/or an electronic prescription of the target user. In particular, electronic medical records are digitized patient medical records that are stored, managed, transmitted, and reproduced by electronic devices (computers, health cards, etc.); the electronic prescription (Electronic prescription) is transmitted by means of a network, is programmed by adopting an information technology, fills in drug treatment information in a diagnosis and treatment activity, is prescribed, can be transmitted to a pharmacy through the network, is checked, allocated, checked and charged by a pharmacy professional technician, and is used as a medical electronic document for drug delivery and medical medication in the pharmacy.
Specifically, the electronic medical record and/or the electronic prescription can be shared by the user to the user terminal; or after passing identity authentication and/or user authorization, the user terminal of other medical institutions or medical service institutions connected with the user terminal network can automatically acquire the electronic medical record and/or electronic prescription of the user, and then the server can acquire the electronic medical record and/or electronic prescription of the user through the user terminal. It can be appreciated that the embodiment of the present application is not limited to a specific implementation manner in which the server obtains the electronic medical record and/or the electronic prescription.
The history diagnosis record may include history doctor information of the target user for diagnosis, so that the history doctor information may be obtained, a history doctor of the target user may be determined, and whether the history doctor belongs to the recommended doctor category may be determined. Specifically, the name or the doctor identifier (or the doctor number, etc.) of the historic doctor may be identified, the category to which the doctor belongs may be determined, and then whether the doctor belongs to the recommended doctor category may be determined, or a doctor list of the recommended doctor category may be obtained, and whether the historic doctor exists may be searched in the list, so as to determine whether the historic doctor belongs to the recommended doctor category.
If the history doctor belongs to the recommended doctor category, step 104 may be executed, and if the history doctor does not belong to the recommended doctor category, step 104 may not be executed, and step 105 may be executed.
104. And determining the historic doctor as a target recommending doctor.
If the historic doctor belongs to the recommended doctor category, that is, the requirement of the doctor for the target user is similar to the requirement of the historic doctor for the doctor, possibly because the doctor needs to visit in the same aspect, step 106 may be executed to recommend the doctor who has been consultated to the user to perform the treatment, and generally, the doctor who has been consultated to the doctor better knows the condition of the patient and can provide better treatment effect, so that the historic doctor can be determined as the target recommended doctor to recommend the doctor to the user, so that the user can preferentially select the doctor who has seen the doctor to visit the doctor.
105. And analyzing the historical diagnosis record and the illness state description content according to analysis rules to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label as the target recommended doctor from doctors in the class of recommended doctors according to the corresponding relation between the diagnosis label and the recommended doctor.
In the embodiment of the present application, the server may store the analysis rule, which is used for analyzing the history diagnosis record and the illness state description content, specifically, if the target user has the history diagnosis record, the server may further determine the illness state of the target user according to a more specialized electronic medical record and/or electronic prescription, a keyword library may be stored in the server, a diagnosis tag may be determined by identifying keywords of the history diagnosis record and the illness state description content, the analysis rule may include a mapping relationship between keywords and combinations thereof and the diagnosis tag, the server may obtain the history diagnosis record and the target keywords of the illness state description content, and may specifically search for which keywords of the history diagnosis record and the illness state description content are in the keyword library, and determine the diagnosis tag corresponding to the target keywords according to the mapping relationship between the keywords and combinations thereof and the diagnosis tag.
The diagnosis label can be in the form of diagnosis codes, can be used for reflecting the disease classification of target users, and can also be used for further determining target recommended doctors. The server may store the correspondence between the diagnostic tag and the recommended doctor, one diagnostic tag may correspond to one or more recommended doctors, and one recommended doctor may also correspond to one or more diagnostic tags. After the diagnosis tag is determined, a recommended doctor corresponding to the diagnosis tag may be determined as the target recommended doctor from among the doctors of the recommended doctor category according to the correspondence between the diagnosis tag and the recommended doctor. It will be appreciated that after determining the recommended doctor category, at least one target recommended doctor may be determined from the recommended doctor category by further analysis in the form of a diagnostic tag. The target recommended doctor can be understood as a professional doctor with the highest degree of relevance to the illness state described by the target user. For example, the history diagnosis record is a oncology patient, and a doctor with a higher level can be recommended to the patient preferentially through detailed patient data, history visit records and the like, for example, the selected doctor is more than the assistant doctor level, so that the matching degree between the patient and the visiting doctor is higher.
106. And generating recommendation information containing the target recommendation doctor, and transmitting the recommendation information to the user terminal.
In the embodiment of the present application, after determining the target recommended doctor, the server may generate recommendation information including the target recommended doctor, and send the recommendation information to the user terminal. The recommended information may include information such as name, gender, age, contact information, department, title, year of the doctor, and the field of indications and/or researches of the target recommended doctor. By implementing the embodiment of the application, the server can send the recommended information to the user terminal, so that a user can know the related information of the target recommended doctor through the recommended information, and actively contact and consult the target recommended doctor through the contact way provided by the recommended information, thereby not only improving the user experience of appointment registration of the user, but also enabling the user to know the related information of the target recommended doctor. It can be understood that the specific content of the recommendation information is not limited in the embodiment of the present application.
107. When receiving a reservation request from the user terminal for the target recommended doctor, acquiring a reservation-capable schedule of the target recommended doctor, and transmitting the reservation-capable schedule to the user terminal.
In the embodiment of the present application, it can be understood that, after a user receives a target recommended doctor recommended by the recommendation information, the user terminal generates a reservation request instruction for the target recommended doctor; if the user does not accept the target recommended doctor recommended by the recommendation information, the server will send a new target recommended doctor to the user terminal again until the user accepts the new target recommended doctor sent by the server, and then a reservation request instruction for the new target recommended doctor is generated. By implementing the embodiment of the application, the user can independently select the target recommended doctor, so that the satisfaction degree of the user in the appointment registering process is improved.
In the embodiment of the present application, when the server receives a reservation request from the user terminal for the target recommended doctor, the server acquires a reservation-capable schedule of the target recommended doctor and transmits the reservation-capable schedule to the user terminal. Wherein the appointment schedule may recommend a daily work schedule for the target for the doctor for approximately one month. For example, the appointment schedule may include information such as "King doctor, 9:00 am-11:00 am, 2018.8.24, idle". By implementing the embodiment of the application, the user can clearly know the recommended target recommended doctor's work schedule, so that the user can reasonably schedule the appointment time, and the appointment registering service efficiency is improved. It will be appreciated that the specific content and representation of the reservable schedule in the embodiments of the present application are not limited.
108. And receiving reservation information from the user terminal, and generating reservation success information if reservation time in the reservation information is idle time in the reservation-capable time table.
In the embodiment of the application, the server can receive the reservation information from the user terminal, and if the reservation time in the reservation information is the idle time in the reservation time table, the reservation is successful, and reservation success information is generated. The reservation information is generated by a user according to the reservation time table; the reservation success information can be information formed by combining one or more of characters, pictures, voice or video, and the like, optionally, after the reservation is successful, the contact information of the user can be obtained, the reservation success information is sent to the user, for example, a mobile phone number is obtained to send a short message, the reservation is informed to be successful, the visit time and notice are prompted, and the like. By implementing the embodiment of the application, the server can timely inform the user whether the reservation registration is successful or not, and unnecessary waiting time of the user can be avoided. It can be understood that the specific contents of the reservation information and the reservation success information are not limited in the embodiment of the present application.
In the embodiment of the present application, when receiving the reservation request of the user for the target recommended doctor, the method may further include: and transmitting reservation condition information of the user to the target recommended doctor, wherein the reservation condition information comprises illness state description content and historical diagnosis record of the user. If the doctor checks the reservation condition information and accepts the reservation, the reservation is successful, the doctor can not accept the reservation, the reason needs to be described to the user, and other proper doctors can be recommended to the user. When the user does not submit the illness state description but directly wants to reserve a doctor, the user can be matched with the doctor, the matching degree is displayed for the user to select whether the doctor needs to be reserved or not, and meanwhile, the doctor with the same type or better can be recommended to the user to carry out consultation. By implementing the embodiment of the application, the user and the doctor can freely select whether to establish the reservation task, so that the reservation registration service is more humanized.
According to the embodiment of the application, the doctor-seeing request comprises a user tag and illness state description content, a target user is determined according to the user tag, a recommended doctor category is determined according to the illness state description content, a historical diagnosis record of the target user is obtained, whether a historical doctor in the historical diagnosis record belongs to the recommended doctor category is judged, if the historical doctor belongs to the recommended doctor category, the historical doctor is determined to be the target recommended doctor, if the historical doctor does not belong to the recommended doctor category, the historical diagnosis record and the illness state description content are analyzed according to analysis rules to determine a diagnosis tag, then a recommended doctor corresponding to the diagnosis tag is determined to be the target recommended doctor from doctors in the recommended doctor category according to the corresponding relation between the diagnosis tag and the recommended doctor, recommendation information containing the target recommended doctor is generated, the recommendation information is sent to the user terminal, a reservation time table of the target recommended doctor can be obtained when the reservation request of the target recommended doctor from the user terminal is received, the reservation time table is sent to the user terminal, the reservation time table can be reserved in the reservation time table is received, and if the reservation time in the reservation time table is more effective can be generated, and the service can be more successful in an idle process.
Referring to fig. 2, which is a schematic flow chart of another method for managing medical tasks according to an embodiment of the present application, the embodiment shown in fig. 2 may be obtained based on the embodiment shown in fig. 1, and the method may include, as shown in fig. 2:
201. a request for a visit from a user terminal is received, the request for a visit including a user tag and a condition description.
The above step 201 may refer to the specific description in step 101 in the embodiment shown in fig. 1, and will not be described herein.
202. And determining a target user according to the user label, determining a doctor to visit department according to the disease keywords in the disease description content, and determining a doctor belonging to the doctor to visit department as a recommended doctor category.
The above determination of the target user may refer to the specific description in step 102 in the embodiment shown in fig. 1, and will not be described herein.
In the embodiment of the present application, the server may extract the condition keywords in the condition description content, determine the doctor to visit department according to the condition keywords, and finally determine the doctor belonging to the doctor to visit department as the recommended doctor category. The server may be preset with a keyword database and a correspondence between keywords and a combination mode thereof and a visit department, and after the condition keywords are obtained, a visit department corresponding to the condition keywords may be determined according to the correspondence between the keywords and the combination mode thereof and a visit department, so as to select a doctor of the visit department for recommending. The determination of the visit department described above may also be accomplished by artificial intelligence algorithm matching. By implementing the embodiment of the application, the server can initially determine the illness state of the user according to the illness state keywords, select doctor types and then make the later recommended appointment, so that appointment registering service is more accurate.
203. And acquiring a history diagnosis record of the target user, and judging whether a history doctor in the history diagnosis record belongs to the recommended doctor category or not, wherein the history diagnosis record comprises an electronic medical record and/or an electronic prescription of the target user.
The above step 203 may be described in detail with reference to step 103 in the embodiment shown in fig. 1, which is not described herein. If the history doctor belongs to the recommended doctor category, step 204 may be executed, and if the history doctor does not belong to the recommended doctor category, step 204 may not be executed, and step 205 may be executed.
204. And determining the historic doctor as a target recommending doctor.
205. And analyzing the historical diagnosis record and the illness state description content according to analysis rules to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label as the target recommended doctor from doctors in the class of recommended doctors according to the corresponding relation between the diagnosis label and the recommended doctor.
206. And generating recommendation information containing the target recommendation doctor, and transmitting the recommendation information to the user terminal.
The above steps 204 to 206 may be respectively described with reference to the embodiments 104 to 106 shown in fig. 1, and are not repeated here.
In an alternative embodiment, the above-mentioned visit request may include a reservation request for a designated doctor, that is, the server may obtain, from the visit request, information of the designated doctor that the user wants to reserve, and the server may perform the following steps:
judging whether the appointed doctor belongs to the recommended doctor category or not;
If the specific doctor is matched with the disease description content, a step of acquiring a reserved time table of the specific doctor can be executed; if not, the step of analyzing the historical diagnostic record and the condition descriptive content according to the analysis rules to determine a diagnostic tag may be performed to determine that the prescribed doctor does not match the condition descriptive content.
When the appointed doctor belongs to the category of the recommended doctor, the appointed doctor appointed by the user is matched with the illness state of the doctor in the present visit, namely the appointed doctor can be determined to be matched with the illness state descriptive content, and the appointment processing can be carried out; when the designated doctor does not belong to the category of the recommended doctor, the designated doctor is not matched with the doctor's illness state of the doctor, and the designated doctor is determined to be not matched with the illness state descriptive content, so that the designated doctor can not carry out the reservation processing for the user, but can execute the step 205 to re-recommend the doctor which is more matched with the illness state of the doctor to treat for the user, so that the patient can receive accurate treatment.
207. When receiving a reservation request from the user terminal for the target recommended doctor, acquiring a reservation-capable schedule of the target recommended doctor, and transmitting the reservation-capable schedule to the user terminal.
208. And receiving reservation information from the user terminal, and if the reservation time in the reservation information is idle time in the reservation-capable time table, generating reservation success information.
The above step 207 and step 208 may refer to the specific descriptions in the embodiment step 107 and step 108 shown in fig. 1, and are not repeated here.
209. And acquiring a user account of the target recommended doctor, and transmitting the electronic medical record and/or the electronic prescription to the user account.
In the embodiment of the present application, the user account may be understood as an account registered in an application program of a terminal device, and the server may obtain the user account of the target recommending doctor, and send the history diagnostic record to the terminal device that logs in the user account. It can be understood that the user account for obtaining the target recommending doctor may be authenticated and/or authenticated by the authorization of the target recommending doctor. After the reservation is successful, the historical electronic medical record and/or the electronic prescription of the target user can be provided for the reserved doctor, so that the doctor can know the illness state of the patient in time, and the treatment effect is improved.
210. And acquiring diagnosis data of the target user, identifying a target field in the diagnosis data to determine a diagnosis task, and generating task information of the diagnosis task, wherein the task information comprises basic information of staff of the diagnosis task.
Specifically, the server may obtain the diagnosis data of the target user, and perform comprehensive analysis on the diagnosis data of the user to determine a diagnosis task, so as to determine the diagnosis progress of the user (which is reflected as the diagnosis task). The diagnosis progress can be understood as a node or a sub-period in the whole diagnosis period, and the diagnosis task is a task performed in the current diagnosis progress. The server may identify a target field in the diagnostic data to determine the diagnostic task.
The above diagnosis data may be understood as information or data generated when a user looks at a doctor, may include an electronic medical record and/or an electronic prescription of the user, may be specifically a diagnosis result (as described in an electronic medical record or report), and may also be a disease description from the user or doctor. For example, the user needs to make a doctor visit, and in the case of not making a doctor visit yet, the patient's condition description can be input, or history doctor visit information such as history electronic medical records can be provided, and the server can automatically acquire data (such as the electronic medical records of the user can be required to pass identity authentication) of the user.
The server in the embodiment of the application can store the corresponding relation between the target field and the diagnosis task, and can determine the current diagnosis task by identifying the target field in the diagnosis data according to the corresponding relation between the target field and the diagnosis task. Specifically, the diagnosis progress may be determined through the target field, and then the diagnosis task may be further determined. The diagnosis progress may include at least one diagnosis task, the server may store diagnosis tasks corresponding to different diagnosis progress in advance, and the corresponding relationship between the diagnosis progress and the diagnosis task, the server may determine the corresponding diagnosis task after determining the diagnosis progress, where the diagnosis task includes various matters in the diagnosis progress, for example, the diagnosis task corresponding to the a disease may include a first diagnosis registration appointment, a first diagnosis post-examination item appointment, a report query before review, and the like, and for example, a treatment item corresponding to each chemotherapy stage of the cancer patient. The above-mentioned diagnosis schedule and diagnosis task can be stored in the form of table in the system, and can be modified (by means of which the staff can be required to obtain authority or make audit) and added or deleted.
Optionally, the user may determine the diagnosis progress and/or select a diagnosis task through manual operation, that is, the server may establish a medical management task of the user, and the user may select the current diagnosis progress by himself or herself, for example, the user may select stages such as initial diagnosis, review, waiting for operation, and post-operation repair, where the user may remotely select the diagnosis task through the user terminal, and after confirmation by the server, the diagnosis task corresponding to the diagnosis progress selected by the user may be obtained.
It should be noted that after the above-mentioned progress of the doctor is determined, the subtask management stage of the above-mentioned progress of the doctor may be entered for the doctor-seeing management task of the current user, that is, the diagnosis task focused on the progress of the doctor at this moment, the diagnosis tasks involved in other progress may be displayed simply or ignored, for example, some diagnosis tasks far away from the current progress of the doctor may not be focused any more, and no recommendation and reminding may be provided to the user, so that a more perfect doctor-seeing task management service may be provided to the user, and meanwhile, the current irrelevant data processing amount may be reduced.
Optionally, when a certain diagnosis task is in the execution stage, other diagnosis progress data can be performed in the background, for example, the next diagnosis task is obtained in advance for the user, and some relevant treatment suggestion information is recommended, notes about the illness state are pushed, and the like.
Specifically, the server may generate task information of the diagnosis task, where the task information may be understood as notification information that a user needs to obtain in the diagnosis task, and specifically, the task information may include basic information of staff of the diagnosis task, for example, a diagnosis task of a first diagnosis of a B-class disease, the task information may include a doctor, a contact manner, a time of a doctor, department, and the task information of a hospitalization stage may include a docking nurse, an attending doctor, a hospital bed number, and the like. In an embodiment of the present application, step 210 may be performed after step 208, or may be performed at other times.
211. And sending the task information to the user terminal.
After the task information of the diagnosis task is generated, the task information can be sent to a user terminal, so that comprehensive diagnosis service and task information can be provided for a user, relevant medical staff can be contacted conveniently, and diagnosis efficiency is improved.
According to the embodiment of the application, a diagnosis request from a user terminal is received, wherein the diagnosis request comprises a user tag and a illness state description content, a target user is determined according to the user tag, a diagnosis is determined according to an illness state keyword in the illness state description content department, a doctor belonging to the diagnosis department is determined to be a recommended doctor category, a history diagnosis record of the target user is obtained, whether a history doctor in the history diagnosis record belongs to the recommended doctor category is judged, and the history diagnosis record comprises an electronic medical record and/or an electronic prescription of the target user; if the history doctor is the target recommended doctor, if the history doctor is not the target recommended doctor, analyzing the history diagnosis record and the illness state description content according to analysis rules to determine a diagnosis label, determining that the recommended doctor corresponding to the diagnosis label is the target recommended doctor from doctors in the category of the recommended doctor according to the corresponding relation between the diagnosis label and the recommended doctor, generating recommendation information containing the target recommended doctor, sending the recommendation information to the user terminal, acquiring a appointment table of the target recommended doctor when a appointment request of the user terminal to the target recommended doctor is received, sending the appointment table to the user terminal, receiving appointment information from the user terminal, if appointment time in the appointment information is idle time in the appointment table, appointment success information can be generated, a user of the target recommended doctor can be obtained, the electronic medical record and/or the electronic prescription can be generated, diagnosis data of the target user can be obtained, the appointment data can be identified, the task can be generated, the task can be accurately scheduled by the user terminal, and the task can be executed by the user terminal.
Referring to fig. 3, fig. 3 is a schematic structural diagram of a server according to an embodiment of the application. As shown in fig. 3, the server includes a transmission module 310, a determination module 320, a judgment module 330, a recommendation module 340, and a reservation module 350, wherein:
the transmission module 310 is configured to receive a diagnosis request from a user terminal, where the diagnosis request includes a user tag and a disease description;
The determining module 320 is configured to determine a target user according to the user tag, and determine a recommended doctor category according to the condition description content;
The judging module 330 is configured to obtain a history diagnosis record of the target user, and judge whether a history doctor in the history diagnosis record belongs to the recommended doctor category;
the recommendation module 340 is configured to:
If the historic doctor belongs to the recommended doctor category, determining the historic doctor as a target recommended doctor; if the history doctor does not belong to the recommended doctor category, analyzing the history diagnosis record and the illness state description content according to an analysis rule to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label from doctors in the recommended doctor category as the target recommended doctor according to the corresponding relation between the diagnosis label and the recommended doctor;
The transmission module 310 is further configured to generate recommendation information including the target recommended doctor, and send the recommendation information to the user terminal; when receiving a reservation request from the user terminal for the target recommended doctor, acquiring a reservation-capable schedule of the target recommended doctor, and transmitting the reservation-capable schedule to the user terminal;
the reservation module 350 is configured to receive reservation information from the user terminal, and generate reservation success information if a reservation time in the reservation information is an idle time in the reservation-possible time table.
Optionally, the history diagnostic record includes an electronic medical record and/or an electronic prescription of the target user;
The transmission module 310 is further configured to obtain a user account of the target recommending doctor after the reservation success information is generated, and send the electronic medical record and/or the electronic prescription to the user account.
Optionally, the determining module 320 is specifically configured to determine the doctor to visit department according to the condition keyword in the condition description, and determine that the doctor belonging to the doctor to visit department is the recommended doctor category.
Optionally, the server further includes a task module 360, configured to obtain diagnostic data of the target user after generating the reservation information, identify a target field in the diagnostic data to determine a diagnostic task, and generate task information of the diagnostic task, where the task information includes basic information of a staff of the diagnostic task;
The transmission module 310 is further configured to send the task information to the user terminal.
Optionally, the visit request includes a reservation request for a designated doctor, and the determining module 330 is further configured to determine whether the designated doctor belongs to the recommended doctor category;
The determining module 320 is further configured to: if the designated doctor belongs to the recommended doctor category, determining that the designated doctor matches the condition description, the transmission module 310 may perform the step of acquiring a prescribable schedule of the designated doctor; if the designated doctor does not belong to the recommended doctor category, the recommendation module 340 may perform the step of analyzing the history diagnostic record and the condition descriptive contents according to the analysis rule to determine a diagnostic tag.
The server 300 in the embodiment of the present application may perform some or all of the method steps in the embodiment shown in fig. 1 and fig. 2, which are not described herein.
In the server 300 according to the embodiment of the present application, the server 300 may receive a diagnosis request from a user terminal, where the diagnosis request includes a user tag and a condition description content, determine a target user according to the user tag, determine a recommended doctor category according to the condition description content, obtain a history diagnosis record of the target user, determine whether a history doctor in the history diagnosis record belongs to the recommended doctor category, if the history doctor belongs to the recommended doctor category, determine the history doctor as a target recommended doctor, analyze the history diagnosis record and the condition description content according to an analysis rule to determine a diagnosis tag, determine a recommended doctor corresponding to the diagnosis tag as the target recommended doctor from doctors in the recommended doctor category according to a correspondence between the diagnosis tag and the recommended doctor, then generate recommendation information including the target recommended doctor, send the recommendation information to the user terminal, and if a reservation request for the target recommended doctor from the user terminal is received, obtain a reservation schedule of the target recommended doctor, send the reservation schedule to the user terminal, and if the reservation schedule is received from the user terminal, the reservation schedule is more successfully generated, and the reservation time can be more effectively integrated.
Referring to fig. 4, fig. 4 is a schematic structural diagram of another server according to an embodiment of the present application. As shown in fig. 4, the server 400 includes a processor 401 and a memory 402, wherein the server 400 may further include a bus 403, the processor 401 and the memory 402 may be connected to each other through the bus 403, and the bus 403 may be a peripheral component interconnect standard (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus or an extended industry standard architecture (Extended Industry Standard Architecture, EISA) bus, etc. The bus 403 may be classified into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 4, but not only one bus or one type of bus. The server 400 may further include an input/output device 404, where the input/output device 404 may include a display screen, such as a liquid crystal display screen. Memory 402 is used to store one or more programs that include instructions; the processor 401 is arranged to invoke instructions stored in the memory 402 to perform some or all of the method steps mentioned in the embodiments of fig. 1 and 2 above.
It should be appreciated that in embodiments of the present application, the Processor 401 may be a central processing unit (Central Processing Unit, CPU), which may also be other general purpose Processor, digital signal Processor (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), off-the-shelf Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The input device 402 may include a touch pad, a fingerprint sensor (for collecting fingerprint information of a user and direction information of a fingerprint), a microphone, etc., and the output device 403 may include a display (LCD, etc.), a speaker, etc.
The memory 404 may include read only memory and random access memory and provide instructions and data to the processor 401. A portion of memory 404 may also include non-volatile random access memory. For example, memory 404 may also store information of device type.
According to the server 400 of the embodiment of the application, the server 400 can receive a diagnosis request from a user terminal, wherein the diagnosis request comprises a user tag and illness state description content, a target user is determined according to the user tag, a recommended doctor category is determined according to the illness state description content, a historical diagnosis record of the target user is obtained, whether a historical doctor in the historical diagnosis record belongs to the recommended doctor category is judged, if the historical doctor belongs to the recommended doctor category, the historical doctor is determined to be the target recommended doctor, the historical diagnosis record and the illness state description content are analyzed according to analysis rules to determine a diagnosis tag, a recommended doctor corresponding to the diagnosis tag is determined to be the target recommended doctor according to the correspondence between the diagnosis tag and the recommended doctor, recommendation information containing the target recommended doctor is generated, the recommendation information is sent to the user terminal, a reservation schedule of the target recommended doctor is obtained when the reservation request of the target recommended doctor from the user terminal is received, the reservation schedule of the target recommended doctor is sent to the user terminal, the reservation schedule is sent to the user terminal, and the reservation information is received from the user terminal is more successfully received, and the reservation information can be generated in an idle time.
The embodiment of the application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program for electronic data exchange, and the computer program makes a computer execute part or all of the steps of any one of the medical task management methods described in the above method embodiments.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and for parts of one embodiment that are not described in detail, reference may be made to related descriptions of other embodiments.
In the several embodiments provided by the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, such as the division of the modules, merely a logical function division, and there may be additional manners of dividing actual implementations, such as multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or modules, which may be in electrical or other forms.
The modules described as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
The integrated modules, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer readable memory. Based on this understanding, the technical solution of the present invention may be embodied essentially or partly in the form of a software product, or all or part of the technical solution, which is stored in a memory, and includes several instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned memory includes: a U-disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a removable hard disk, a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Claims (8)

1. A medical task management method applied to a server, the method comprising:
receiving a diagnosis request from a user terminal, wherein the diagnosis request comprises a user tag and illness state description content;
Determining a target user according to the user tag, and determining a recommended doctor category according to the illness state description content;
acquiring a history diagnosis record of the target user, and judging whether a history doctor in the history diagnosis record belongs to the recommended doctor category;
if the historic doctor belongs to the recommended doctor category, determining the historic doctor as a target recommended doctor;
If the history doctor does not belong to the recommended doctor category, analyzing the history diagnosis record and the illness state description content according to an analysis rule to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label as the target recommended doctor from doctors in the recommended doctor category according to the corresponding relation between the diagnosis label and the recommended doctor;
Generating recommendation information containing the target recommendation doctor, and sending the recommendation information to the user terminal;
When receiving a reservation request of the target recommended doctor from the user terminal, acquiring a reserved time table of the target recommended doctor, and sending the reserved time table to the user terminal;
Receiving reservation information from the user terminal, and generating reservation success information if reservation time in the reservation information is idle time in the reservation time table;
Acquiring diagnosis data of the target user, identifying a target field in the diagnosis data to determine a diagnosis task, and generating task information of the diagnosis task, wherein the task information comprises basic information of staff of the diagnosis task; the diagnosis data is information or data generated when the target user visits, the diagnosis data is used for judging the diagnosis progress of the target user, the diagnosis progress refers to a node or a sub-period in a diagnosis period, and the diagnosis task is a task performed in the current diagnosis progress; the server stores the corresponding relation between the target field and the diagnosis task and the corresponding relation between the diagnosis progress and the diagnosis task; the progress of the visit includes at least one diagnostic task;
And sending the task information to the user terminal.
2. The method of claim 1, wherein the historical diagnostic record includes an electronic medical record and/or an electronic prescription of the target user;
After the reservation success information is generated, the method further comprises:
and acquiring a user account of the target recommended doctor, and sending the electronic medical record and/or the electronic prescription to the user account.
3. The method of claim 1 or 2, wherein said determining a recommended doctor category from said condition description comprises:
and determining a visit department according to the condition keywords in the condition description content, and determining that the doctor belonging to the visit department is the recommended doctor category.
4. The method of claim 1, wherein the visit request comprises a reservation request to a designated doctor, the method further comprising:
Judging whether the appointed doctor belongs to the recommended doctor category or not;
If the specific doctor is the one, determining that the specific doctor is matched with the disease description content, and executing the step of acquiring the appointment schedule of the specific doctor; and if the diagnosis label does not belong to the diagnosis label, determining that the designated doctor is not matched with the disease description content, and executing the step of analyzing the historical diagnosis record and the disease description content according to analysis rules to determine the diagnosis label.
5. A server, comprising: the system comprises a transmission module, a determination module, a judgment module, a recommendation module and a reservation module, wherein:
the transmission module is used for receiving a diagnosis request from the user terminal, wherein the diagnosis request comprises a user tag and illness state description content;
the determining module is used for determining a target user according to the user tag and determining a recommended doctor category according to the illness state description content;
The judging module is used for acquiring a historical diagnosis record of the target user and judging whether a historical doctor in the historical diagnosis record belongs to the recommended doctor category or not;
The recommending module is used for:
If the historic doctor belongs to the recommended doctor category, determining the historic doctor as a target recommended doctor; if the history doctor does not belong to the recommended doctor category, analyzing the history diagnosis record and the illness state description content according to an analysis rule to determine a diagnosis label, and determining a recommended doctor corresponding to the diagnosis label as the target recommended doctor from doctors in the recommended doctor category according to the corresponding relation between the diagnosis label and the recommended doctor;
The transmission module is further used for generating recommendation information containing the target recommendation doctor and sending the recommendation information to the user terminal; when receiving a reservation request of the target recommended doctor from the user terminal, acquiring a reserved time table of the target recommended doctor, and sending the reserved time table to the user terminal;
The reservation module is used for receiving reservation information from the user terminal, and generating reservation success information if reservation time in the reservation information is idle time in the reservation time table;
The task module is used for acquiring the diagnosis data of the target user, identifying a target field in the diagnosis data to determine a diagnosis task, and generating task information of the diagnosis task, wherein the task information comprises basic information of staff of the diagnosis task; the diagnosis data is information or data generated when the target user visits, the diagnosis data is used for judging the diagnosis progress of the target user, the diagnosis progress refers to a node or a sub-period in a diagnosis period, and the diagnosis task is a task performed in the current diagnosis progress; the server stores the corresponding relation between the target field and the diagnosis task and the corresponding relation between the diagnosis progress and the diagnosis task; the progress of the visit includes at least one diagnostic task;
The transmission module is also used for sending the task information to the user terminal.
6. The server according to claim 5, wherein the determining module is specifically configured to determine a doctor's doctor department based on the condition keyword in the condition description, and determine that a doctor belonging to the doctor's doctor department is the recommended doctor category.
7. A server comprising a processor, an input device, an output device and a memory, the processor, the input device, the output device and the memory being interconnected, wherein the memory is adapted to store a computer program comprising program instructions, the processor being configured to invoke the program instructions to perform the method of any of claims 1-4.
8. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program comprising program instructions which, when executed by a processor, cause the processor to perform the method of any of claims 1-4.
CN201811265505.5A 2018-10-27 2018-10-27 Medical task management method, server and storage medium Active CN109543863B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811265505.5A CN109543863B (en) 2018-10-27 2018-10-27 Medical task management method, server and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811265505.5A CN109543863B (en) 2018-10-27 2018-10-27 Medical task management method, server and storage medium

Publications (2)

Publication Number Publication Date
CN109543863A CN109543863A (en) 2019-03-29
CN109543863B true CN109543863B (en) 2024-06-18

Family

ID=65845220

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811265505.5A Active CN109543863B (en) 2018-10-27 2018-10-27 Medical task management method, server and storage medium

Country Status (1)

Country Link
CN (1) CN109543863B (en)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110021414A (en) * 2019-04-17 2019-07-16 方翔 The intelligent hospital registration system of internet medical services
CN110265128B (en) * 2019-06-27 2021-04-06 卫宁健康科技集团股份有限公司 Outpatient service number adding method and device, electronic equipment and readable storage medium
CN110442732A (en) * 2019-07-24 2019-11-12 万达信息股份有限公司 A kind of intelligent medical guide method, system and storage medium
CN110472028A (en) * 2019-07-25 2019-11-19 珠海九松科技有限公司 Medical problem based on artificial intelligence and big data answers system and method automatically
CN110619959A (en) * 2019-08-09 2019-12-27 贵阳叁玖互联网医疗有限公司 Intelligent triage method and system
CN110556185A (en) * 2019-09-11 2019-12-10 刘源 medical skin care classification matching method and system based on Internet platform
CN112568911B (en) * 2019-09-30 2024-09-13 深圳市理邦精密仪器股份有限公司 Electrocardiogram data classification method, equipment and device with storage function
CN111210042A (en) * 2020-01-03 2020-05-29 秒针信息技术有限公司 Reservation order dispatching method, device, equipment and storage medium
CN111475713A (en) * 2020-03-13 2020-07-31 京东方科技集团股份有限公司 Doctor information recommendation method, device, electronic device, system and storage medium
CN111415760B (en) * 2020-03-26 2023-10-13 潘佳亮 Doctor recommendation method, doctor recommendation system, computer equipment and storage medium
CN111612653A (en) * 2020-05-08 2020-09-01 快猪侠信息技术(杭州)有限公司 Terminal service system based on big data platform and service method thereof
CN112035611B (en) * 2020-08-28 2023-05-30 康键信息技术(深圳)有限公司 Target user recommendation method, device, computer equipment and storage medium
CN112133454A (en) * 2020-09-18 2020-12-25 泰康保险集团股份有限公司 Consultation service system, information display method and electronic equipment
CN112435745B (en) * 2020-12-18 2024-04-05 深圳赛安特技术服务有限公司 Method and device for recommending treatment strategy, electronic equipment and storage medium
CN112668743A (en) * 2020-12-28 2021-04-16 上海领健信息技术有限公司 Intelligent recommendation method and device for reserved time, storage medium and terminal
CN112614579A (en) * 2021-01-05 2021-04-06 北京融威众邦电子技术有限公司 Hospital appointment registration method and device and computer equipment
CN113764079A (en) * 2021-01-15 2021-12-07 北京京东拓先科技有限公司 Medical service method, system and storage medium
CN112951392B (en) * 2021-02-25 2023-10-03 挂号网(杭州)科技有限公司 Resource information pushing method and device, electronic equipment and storage medium
CN112837810A (en) * 2021-03-03 2021-05-25 湖南中医药大学 A comprehensive processing method for medical informationization of specialty of traditional Chinese medicine
CN113284617A (en) * 2021-03-08 2021-08-20 南京紫金山智慧城市研究院有限公司 Intelligent health management brain-based accurate intelligent health management system
CN112966181A (en) * 2021-03-08 2021-06-15 挂号网(杭州)科技有限公司 Service recommendation method and device, electronic equipment and storage medium
CN113241194B (en) * 2021-04-30 2022-09-09 上海市儿童医院 Intelligent medical question-answering method, system, terminal and storage medium
CN112992371B (en) * 2021-05-12 2021-09-07 四川大学华西医院 A disease risk monitoring system and method
CN113276133B (en) * 2021-06-10 2023-01-13 上海钛米机器人股份有限公司 Data processing method, device, equipment and storage medium
CN113793669A (en) * 2021-08-03 2021-12-14 浙江大学 Control method and device of drug scheme auditing device and readable storage medium
CN113744854A (en) * 2021-08-20 2021-12-03 海南视联大健康智慧医疗科技有限公司 Remote doctor recommendation method and device, terminal device and storage medium
CN113707335B (en) * 2021-09-06 2024-12-17 挂号网(杭州)科技有限公司 Method, device, electronic equipment and storage medium for determining target consultation user
CN113934346B (en) * 2021-09-16 2025-06-03 阿里健康科技(中国)有限公司 Treatment Method
CN114282880A (en) * 2021-11-09 2022-04-05 深圳市巨鼎医疗股份有限公司 Business handling guiding method and device and computer readable storage medium
CN114242224A (en) * 2021-12-28 2022-03-25 新瑞鹏宠物医疗集团有限公司 Doctor recommendation method and device, electronic equipment and storage medium
CN114255478A (en) * 2021-12-29 2022-03-29 新瑞鹏宠物医疗集团有限公司 Pet distribution method, device, storage medium and electronic device
CN115271133A (en) * 2022-06-14 2022-11-01 新瑞鹏宠物医疗集团有限公司 Information processing method and device, computer equipment and storage medium
CN114912645A (en) * 2022-06-15 2022-08-16 康键信息技术(深圳)有限公司 Information processing method and device, computer equipment and readable storage medium
CN115081658A (en) * 2022-06-21 2022-09-20 中国银行股份有限公司 A method and device for making an appointment for a banking business
CN115099444A (en) * 2022-06-30 2022-09-23 贵州精准健康数据有限公司 Hospital reservation background service system
CN118412122A (en) * 2023-02-09 2024-07-30 上海云药口腔医疗技术有限公司 Data processing system for determining tooth condition
CN116029399A (en) * 2023-02-27 2023-04-28 华序科技开发(深圳)有限公司 Online appointment diagnosis guiding method based on natural semantic recognition, electronic equipment and medium
CN116364233A (en) * 2023-03-06 2023-06-30 广东名阳信息科技有限公司 Prompting method and device after diagnosis
CN116884566A (en) * 2023-07-14 2023-10-13 盐城市食品药品监督检验中心 Medication risk monitoring and evaluating method and system
CN118172030B (en) * 2024-02-07 2024-10-01 广州易效能教育科技有限公司 Time management method and device

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102622498A (en) * 2011-01-27 2012-08-01 北京中医药大学 Traditional Chinese medicine information processing system and method based on comprehensive integration
CN106934244A (en) * 2017-03-20 2017-07-07 龚昕 A medical care cloud platform based on intelligent terminal

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107704571A (en) * 2017-09-29 2018-02-16 努比亚技术有限公司 Information intelligent recommends method, apparatus and computer-readable recording medium

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102622498A (en) * 2011-01-27 2012-08-01 北京中医药大学 Traditional Chinese medicine information processing system and method based on comprehensive integration
CN106934244A (en) * 2017-03-20 2017-07-07 龚昕 A medical care cloud platform based on intelligent terminal

Also Published As

Publication number Publication date
CN109543863A (en) 2019-03-29

Similar Documents

Publication Publication Date Title
CN109543863B (en) Medical task management method, server and storage medium
US11735294B2 (en) Client management tool system and method
US8301462B2 (en) Systems and methods for disease management algorithm integration
TWI444921B (en) Online system, method, and computer readable medium to facilitate providing health and wellness assistance
US9147041B2 (en) Clinical dashboard user interface system and method
US20210334462A1 (en) System and Method for Processing Negation Expressions in Natural Language Processing
US20210327582A1 (en) Method and system for improving the health of users through engagement, monitoring, analytics, and care management
US20040260577A1 (en) Electronic healthcare information and delivery management system with an integrated medical search architecture and capability
US20150106123A1 (en) Intelligent continuity of care information system and method
Hammond et al. Connecting information to improve health
US20150199488A1 (en) Systems and Methods for Interpreting Medical Information
US20110301976A1 (en) Medical history diagnosis system and method
CN111554365A (en) Chronic disease comprehensive service platform
US20160042146A1 (en) Recommending medical applications based on a physician's electronic medical records system
JP2004514982A (en) System and method for integrating disease management in a physician workflow
CA2884613A1 (en) Clinical dashboard user interface system and method
US20190311791A1 (en) System and method for patient-centric universal health recording and payment
KR20210153845A (en) An apparatus and a method for providing medical contents information services based on analyzing personalized health examination data
US20240331820A1 (en) Community based individualized health platforms
US20160042431A1 (en) Recommending medical applications based on a patient's electronic medical records system
CN112749321A (en) Data processing method, client, server, system and storage medium
EP3910648A1 (en) Client management tool system and method
US20190108897A1 (en) Apparatus and method for assisting medical consultation
WO2001035376A1 (en) Electronic healthcare information and delivery management system
WO2026025419A1 (en) Hospital support platforms

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right

Effective date of registration: 20220520

Address after: 518000 China Aviation Center 2901, No. 1018, Huafu Road, Huahang community, Huaqiang North Street, Futian District, Shenzhen, Guangdong Province

Applicant after: Shenzhen Ping An medical and Health Technology Service Co.,Ltd.

Address before: Room 12G, Block H, 666 Beijing East Road, Huangpu District, Shanghai 200000

Applicant before: PING AN MEDICAL AND HEALTHCARE MANAGEMENT Co.,Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant