Consultation sheet processing method and device

Abstract

The disclosure provides an inquiry sheet processing method and device, and relates to the technical field of Internet medical treatment. The method comprises the following steps: receiving an inquiry sheet of a patient; determining a target doctor group matched with the inquiry sheet according to inquiry information of the inquiry sheet and service information of doctors; pushing the inquiry sheet to a personal pool of one or more target doctors in the target doctor group; and assigning the inquiry sheet to a target doctor who sends a first order request to the inquiry sheet for treatment, wherein the first order request is the first valid order request received. A personal pool is established for each doctor, the personal pool serves a certain doctor, the frequency of being pulled and refreshed for display is reduced, and each refresh involves inquiry sheets in the personal pool, so that the refresh efficiency is improved. For a certain doctor, all the inquiry sheets cached in the personal pool are suitable for the doctor to treat and match the service information of the doctor, so that the inquiry sheet jamming problem in the inquiry sheet processing method based on the department pool is avoided, and the treatment efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of internet medical technology, and in particular to a method and apparatus for processing medical consultation forms. Background Technology

[0002] Internet hospitals refer to medical services that utilize internet technology to provide users with consultation, intelligent medication inquiry, follow-up, and disease management services online.

[0003] In the dispatch system of the Internet hospital, consultation orders are placed into the corresponding department pool. Each doctor in that department can retrieve and refresh all consultation orders in the department pool through their own doctor client, find the consultation orders that they can provide services for, and accept the consultations. Consultation orders that have been accepted will be removed from the department pool. Summary of the Invention

[0004] Research revealed that the department pool serves all doctors in that department, and is retrieved and refreshed frequently. Each refresh involves all consultation requests in the pool, resulting in low refresh efficiency. Furthermore, for a particular doctor in that department, not all consultation requests in the pool are suitable for their practice. When unsuitable consultation requests accumulate significantly in the pool, it will block the display of suitable consultation requests, thus affecting the efficiency of seeing patients.

[0005] In this embodiment, a personal pool is established for each doctor. The personal pool serves a specific doctor, reducing the frequency of retrieval and refresh display. Each refresh involves the consultation orders in the personal pool, improving refresh efficiency. Furthermore, for a specific doctor, the consultation orders cached in the personal pool are all suitable for their service information and are appropriate for their patients. This avoids the consultation order congestion problem in consultation order processing methods based on department pools, which helps to improve the efficiency of patient reception.

[0006] This disclosure provides a method for processing medical records, including:

[0007] Receive patient consultation forms;

[0008] Based on the consultation information and the doctor's service information in the consultation form, determine the target doctor group that matches the consultation form;

[0009] The consultation form is pushed to the personal pool of one or more target doctors in the target doctor group;

[0010] The consultation form is assigned to the target doctor who issued the first order acceptance request to receive the consultation. The first order acceptance request is the first valid order acceptance request received.

[0011] In some embodiments, the method further includes: generating a token for the consultation form; pushing the consultation form and its token together to the personal pools of one or more target doctors in the target doctor group; when a target doctor retrieves a consultation form from its personal pool, verifying the token of each consultation form in the personal pool, and outputting a valid consultation form whose token has been successfully verified.

[0012] In some embodiments, assigning the consultation form to the target doctor who issued the first request to receive the consultation form includes:

[0013] Receive one or more order acceptance requests from one or more target doctors in response to the consultation form;

[0014] According to the order in which the order requests are received, the tokens of the corresponding medical consultation forms in the personal pool of the target doctor are verified in turn based on the tokens of the stored medical consultation forms.

[0015] If token verification fails, continue to verify the next order request. If token verification succeeds, the corresponding order request becomes the first order request. The consultation form is assigned to the target doctor who issued the first order request to receive the consultation form, and the stored token of the consultation form is updated.

[0016] The order request following the first order request is treated as the second order request. Based on the new token of the consultation form, the token of the consultation form in the personal pool of the target doctor who issued the second order request is verified. If the token verification fails, the target doctor who issued the second order request is rejected from accepting the consultation form.

[0017] In some embodiments, if the consultation form is not received within a preset time, a new target doctor group matching the consultation form is determined, and the token of the generated consultation form is updated; the consultation form and its new token are pushed together to the personal pools of one or more target doctors in the new target doctor group; when a target doctor retrieves a consultation form from its personal pool, the token of each consultation form in the personal pool is verified, and a valid consultation form with successfully verified token is output.

[0018] In some embodiments, the number of target doctors in the new target doctor group is greater than the number of target doctors in the target doctor group.

[0019] In some embodiments, the consultation information on the consultation form includes at least one of the following: consultation form type and the department requiring consultation.

[0020] In some embodiments, the doctor's service information includes at least one of the following: the services the doctor can provide, the doctor's current workload, and the doctor's activity level.

[0021] In some embodiments, the method further includes: managing individual pools of each target doctor, using department identifiers and doctor identifiers as keys, consultation number as a field, and consultation-related information items as values, wherein the consultation-related information items are extensible.

[0022] In some embodiments, the method further includes: supplementing the valid consultation form with preset information after successful token verification, and then outputting the valid consultation form with successful token verification.

[0023] In some embodiments, the dispatch service receives a patient's consultation order and sends it to the corresponding workflow orchestration service. The workflow orchestration service assigns doctor nodes and push nodes to the consultation order. The doctor node determines the target doctor group that matches the consultation order based on the consultation information and the doctor's service information. The push node pushes the consultation order to the personal pools of one or more target doctors in the target doctor group. Each target doctor's personal pool is maintained by a doctor personal pool service, and the doctor personal pool manager service manages the personal pools of each target doctor. The order status management service assigns the consultation order to the target doctor who issued the first order acceptance request to receive the consultation order. The first order acceptance request is the first valid order acceptance request received.

[0024] This disclosure provides some embodiments of a medical record processing device, including:

[0025] The dispatch service is configured to receive patient consultation requests.

[0026] The workflow orchestration service is configured to assign doctor nodes and push nodes to consultation forms;

[0027] The doctor node is configured to determine the target doctor group that matches the consultation form based on the consultation information and the doctor's service information.

[0028] The push node is configured to push the consultation form to one or more personal pools of target doctors in the target doctor group, and each personal pool of target doctors is maintained by a doctor personal pool service;

[0029] The Doctor Individual Pool Manager service is configured to manage individual pools for each target doctor.

[0030] The order status management service is configured to assign the consultation order to the target doctor who issued the first order acceptance request to receive the consultation order. The first order acceptance request is the first valid order acceptance request received.

[0031] This disclosure provides embodiments of a medical record processing apparatus, including: a memory; and a processor coupled to the memory, the processor being configured to execute the medical record processing methods of various embodiments based on instructions stored in the memory.

[0032] Some embodiments of this disclosure provide a non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the consultation form processing method of each embodiment. Attached Figure Description

[0033] The accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. This disclosure can be more clearly understood from the following detailed description with reference to the accompanying drawings.

[0034] Obviously, the accompanying drawings described below are merely some embodiments of this disclosure. Those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0035] Figure 1 A flowchart illustrating a consultation form processing method according to some embodiments of this disclosure is shown.

[0036] Figure 2A This diagram illustrates the information storage of a personal pool according to some embodiments of the present disclosure.

[0037] Figure 2B The diagram illustrates the management of various individual pools according to some embodiments of this disclosure.

[0038] Figure 3A This illustration shows a flowchart of some embodiments of the present disclosure of pushing the consultation form to a personal pool of one or more target doctors in the target doctor group.

[0039] Figure 3B This illustration shows a flowchart of a target doctor retrieving consultation orders from their personal pool and verifying tokens, according to some embodiments of this disclosure.

[0040] Figure 3C This illustration shows a flowchart of a process in which a consultation form is assigned to a target doctor who issued a first request for consultation, according to some embodiments of this disclosure.

[0041] Figure 4 The diagram illustrates the re-distribution of consultation forms and token updates according to some embodiments of this disclosure.

[0042] Figure 5 A schematic diagram of the structure of a medical record processing device according to some embodiments of the present disclosure is shown.

[0043] Figure 6 A schematic diagram of the structure of a medical record processing device according to other embodiments of this disclosure is shown. Detailed Implementation

[0044] The technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0045] Figure 1 A flowchart illustrating a consultation form processing method according to some embodiments of this disclosure is shown.

[0046] like Figure 1 As shown, the consultation form processing method of this embodiment includes the following steps 110-160, wherein steps 140 and 160 can be selected to be executed as needed.

[0047] In step 110, in response to the patient's consultation request sent through the Internet Hospital, the patient's consultation request is received.

[0048] Patients can send consultation requests through the internet hospital's application or website, thus enabling online consultations based on network technology.

[0049] A consultation form may include, but is not limited to, the patient's basic information, health-related data, and the content of the consultation.

[0050] In step 120, based on the consultation information and the doctor's service information on the consultation form, a target doctor group matching the consultation form is determined.

[0051] The consultation information on the consultation form includes, but is not limited to, at least one of the following: consultation form type and the department requiring consultation. The consultation form type should reflect the main content of the patient's consultation request.

[0052] This includes, but is not limited to, at least one of the following: the services a doctor can provide, the doctor's current workload, and the doctor's activity level. The doctor's current workload can be determined, for example, based on the number of consultation forms assigned to the doctor. The doctor's activity level can be determined, for example, based on the number of patients the doctor has seen.

[0053] A target doctor group may include one or more target doctors. The number of target doctors in a target doctor group can be set as needed.

[0054] In some embodiments, if the content of the consultation request matches the services that a doctor can provide, the consultation request is considered a match for that doctor, and that doctor can be selected as the target doctor matching the consultation request.

[0055] In other embodiments, in addition to ensuring that the content of the consultation request matches the services that the doctor can provide, the doctor's current busyness or activity level can also be taken into account. For example, doctors whose busyness is below a certain value and / or whose activity level is above a certain value are selected as the target doctors that match the consultation request.

[0056] With a sufficient number of online doctors available at internet hospitals, it's usually possible to match a patient's consultation request with a suitable doctor. If a suitable doctor isn't found initially, the matching requirements can be lowered, and a new doctor can be matched. This maximizes the chances of meeting the user's need for real-time consultations.

[0057] In step 130, the consultation form is pushed to the personal pool of one or more target doctors in the target doctor group.

[0058] By performing the matching calculation between consultation forms and doctors in advance, and then sending the matched consultation forms to the doctors' personal pool, the reading speed of consultation forms can be improved, which is conducive to improving the efficiency of receiving patients.

[0059] In some embodiments, such as Figure 3A As shown, step 130 includes steps 131-132. In step 131, a token for the consultation form is generated and stored. For example, the token can be generated based on JSON Web Token (JWT) technology. In step 132, the consultation form and its token are pushed together to the personal pools of one or more target doctors in the target doctor group. Thus, the token is used to distinguish between valid and invalid consultation forms.

[0060] Each target doctor has their own personal pool, which stores information from consultation forms that match the target doctor's service capabilities, ensuring that the personal pool serves only the target doctor. For example... Figure 2A As shown, in the target doctor's personal pool, the corresponding department identifier and doctor identifier are used as keys, the consultation number as a field, and the consultation-related information items as values. Thus, information storage in the personal pool is achieved based on Redis's hash technology. The consultation-related information items are expandable. These items include, but are not limited to, the consultation number, token, and time.

[0061] It also allows for the management of individual pools of target doctors, such as... Figure 2B As shown, each target doctor's department identifier and doctor identifier are used as keys, the consultation order number as a field, and the consultation order-related information items as values. Thus, personal pool management is achieved based on Redis's hash technology. The consultation order-related information items are extensible. These items include, but are not limited to, the consultation order number, token, and time.

[0062] After step 132, step 140 can also be performed.

[0063] In step 140, when the target doctor retrieves consultation orders from their personal pool, the token of each consultation order in the personal pool is verified, and a valid consultation order with successfully verified tokens is output. This achieves read-time repair.

[0064] If the consultation form's token has not been updated, the token for that consultation form in the personal pool will be successfully verified; if the consultation form's token has been updated, the new token for that consultation form in the personal pool will be successfully verified, and the old token for that consultation form in the personal pool will fail to be verified. Specifically, the token for a consultation form will be updated when it is reassigned after not being treated within a certain period of time; or, when a consultation form is treated first, the token for that consultation form will be updated.

[0065] For example, when a consultation form is reassigned, the form's token is updated. The consultation form and its new token are then distributed to the doctor's personal pool. The previously issued consultation form and its old token do not need to be deleted from the personal pool. However, when the doctor retrieves and refreshes their personal pool, invalid consultation forms whose old tokens failed verification are removed. This achieves read-time repair and allows doctors to manage their own personal pools.

[0066] In some embodiments, preset information can be added to valid consultation forms that have successfully verified the token before the form is output, making the information in the consultation form more comprehensive. The supplementary preset information may include, but is not limited to, service requests, commission, and timeliness.

[0067] In some embodiments, step 140 includes steps 141-147. For example... Figure 3B As shown, in step 141, the target doctor retrieves consultation orders from their personal pool through the doctor client. In step 142, the tokens of the consultation orders in the personal pool are verified based on the stored tokens. In step 143, if the token verification is successful, the consultation order is added to the output list as a valid consultation order. In step 144, if the token verification fails, the consultation order is added to the removal list as an invalid consultation order. In step 145, the consultation orders in the removal list are deleted from the personal pool. In step 146, as needed, preset information is added to the valid consultation orders with successful token verification. In step 147, the valid consultation orders with successful token verification in the output list are output.

[0068] Step 150 may also be performed after step 130 or step 132.

[0069] In step 150, the consultation form is assigned to the target doctor who issued the first order acceptance request to receive the consultation form. The first order acceptance request is the first valid order acceptance request received, that is, the consultation form is received by the target doctor in the target doctor group who is the first to grab the consultation form.

[0070] A consultation request may be distributed to multiple pools of target doctors. The doctor who is the first to receive the consultation request will then handle the case, which helps the consultation request be processed more quickly.

[0071] In some embodiments, such as Figure 3C As shown, step 150 includes steps 151-154. In step 151, one or more order acceptance requests from one or more target doctors regarding the consultation form are received; in step 152, according to the order in which the order acceptance requests are received, the tokens of the consultation forms in the personal pools of the corresponding target doctors are verified sequentially based on the stored tokens of the consultation forms; in step 153a, if the token verification fails, the verification of the next order acceptance request continues; in step 153b, if the token verification succeeds, the corresponding order acceptance request is designated as the first order acceptance request, and the consultation form is assigned to the target doctor who issued the first order acceptance request to receive the consultation, and the stored tokens of the consultation form are updated; in step 154, the order acceptance request following the first order acceptance request is designated as the second order acceptance request, and the tokens of the consultation forms in the personal pools of the target doctor who issued the second order acceptance request are verified based on the new tokens of the consultation forms. If the token verification fails, the consultation request from the target doctor who issued the second order acceptance request is rejected.

[0072] In other words, in response to a target doctor's attempt to claim the consultation form, it is determined whether the claim was initiated first. For example, if the consultation form status is "claimed," it means it was not the first claim; if the consultation form status is "not claimed," it means it was the first claim. If it was the first claim, the tokens of the consultation forms in the personal pool are verified based on the stored tokens of the consultation form. If the token verification is successful, the consultation form status is marked as "claimed," the first target doctor to claim it is recorded, and the consultation form is allowed to be treated by the target doctor who initiated the claim. The token of the consultation form is also updated. If it was not the first claim, due to the token update, the tokens of the consultation forms in the personal pool are verified based on the new token of the consultation form. If the token verification fails, the consultation form is refused treatment by the target doctor who was not the first to claim it.

[0073] In step 160, if the consultation form is not received within a preset time (e.g., 2 minutes), a redistribution operation is triggered. This involves re-identifying the target doctor group that matches the consultation form, updating the token of the consultation form, and pushing the consultation form and its new token together to the personal pools of one or more target doctors in the new target doctor group. Then, steps 140 and 150 can be executed.

[0074] Specifically, based on the consultation information and doctor's service information in the consultation form, a new target doctor group can be determined to match the consultation form. In some embodiments, compared to the initial matching, the matching requirements between the consultation form and the doctor can be appropriately relaxed. For example, the requirements regarding the doctor's current workload or activity level can be relaxed to find more matching target doctors and ensure that the consultation form is treated as soon as possible. The number of target doctors in the new target doctor group reassigned to the consultation form can be set to be greater than the number of target doctors in the original target doctor group, thereby ensuring that the consultation form is treated as quickly as possible.

[0075] The new target doctor group may have duplicate doctors as the original target doctor group. The personal pool of the duplicate doctor will temporarily contain the previously issued consultation order and the reissued consultation order, but the tokens of the two consultation orders are different. Through token verification in step 140, the previously issued consultation order is invalidated during read repair.

[0076] For example, such as Figure 4 As shown, consultation form 211001 is first pushed to doctor A (personalPrefix_A) and doctor B (personalPrefix_B), with the token ABC. If consultation form 211001 is not treated within 2 minutes, it is pushed to doctor B and doctor C (personalPrefix_C) a second time with the new token ABX. Due to the token inconsistency, consultation form 211001 in doctor A's personal pool will fail token verification. During read repair, the invalid consultation form 211001 will be deleted.

[0077] In this embodiment, a personal pool is established for each doctor. The personal pool serves a specific doctor, reducing the frequency of retrieval and refresh display. Each refresh involves the consultation orders in the personal pool, improving refresh efficiency. Furthermore, for a specific doctor, the consultation orders cached in the personal pool are all suitable for their service information and are appropriate for their patients. This avoids the consultation order congestion problem in consultation order processing methods based on department pools, which helps to improve the efficiency of patient reception.

[0078] Figure 5 A schematic diagram of the structure of a medical record processing device according to some embodiments of the present disclosure is shown.

[0079] like Figure 5 As shown, the consultation order processing device 500 in this embodiment includes: order dispatch service 510, process orchestration service 520, doctor node 530, push node 540, doctor personal pool manager service 550, several doctor personal pool services 560, and order status management service 570.

[0080] The dispatch service 510 receives patient consultation orders and sends them to the corresponding workflow orchestration service 520. The workflow orchestration service 520 assigns doctor nodes 530 and push nodes 540 to the consultation orders. The doctor node 530 determines the target doctor group matching the consultation order based on the consultation information and the doctor's service information. The push node 540 can optionally generate a token and push the consultation order and its token (optionally) to the personal pools of one or more target doctors in the target doctor group. Each target doctor's personal pool corresponds to a doctor personal pool service 560, which is maintained by the doctor personal pool service 560. The doctor personal pool manager service 550 is a service class that manages the personal pools of each target doctor. It can implement personal pool management based on Redis hash technology, and associates the pushed doctors and consultation orders for storage. The associated storage format is as follows: Figure 2B As shown, the department identifier and doctor identifier are used as keys, the consultation number as a field, and consultation-related information items as values. The consultation-related information items are expandable. The doctor's personal pool service 560 can retrieve its own consultation information from the doctor's personal pool manager service 550.

[0081] A personal pool is established for each doctor, serving a specific doctor. The frequency of being pulled and refreshed is reduced, and each refresh involves the consultation orders in the personal pool, improving refresh efficiency. Furthermore, for a given doctor, the consultation orders cached in the personal pool are all suitable for their service information and are appropriate for their patients. This avoids the consultation order congestion problem that occurs in consultation order processing methods based on department pools, which helps to improve the efficiency of patient reception.

[0082] The order status management service 570 can assign the consultation order to the target doctor who issued the first order acceptance request to receive the consultation order. The first order acceptance request is the first valid order acceptance request received, that is, the consultation order is received by the target doctor in the target doctor group who is the first to grab the consultation order. Specifically, the system receives one or more order acceptance requests from one or more target doctors regarding the consultation form; following the order of receipt of the order acceptance requests, the system verifies the tokens of the consultation forms in the personal pool of the corresponding target doctors according to the stored tokens of the consultation forms; if the token verification fails, the system continues to verify the next order acceptance request; if the token verification succeeds, the corresponding order acceptance request is designated as the first order acceptance request, and the consultation form is assigned to the target doctor who issued the first order acceptance request to receive the consultation, and the stored token of the consultation form is updated; the order acceptance request following the first order acceptance request is designated as the second order acceptance request, and the system verifies the tokens of the consultation forms in the personal pool of the target doctor who issued the second order acceptance request according to the new token of the consultation form; if the token verification fails, the system rejects the consultation request from the target doctor who issued the second order acceptance request. In other words, in response to a target doctor's attempt to claim the consultation form, it is determined whether the claim was initiated first. For example, if the consultation form status is "claimed," it means it was not the first claim; if the consultation form status is "not claimed," it means it was the first claim. If it was the first claim, the tokens of the consultation forms in the personal pool are verified based on the stored tokens of the consultation form. If the token verification is successful, the consultation form status is marked as "claimed," the first target doctor to claim it is recorded, and the consultation form is allowed to be treated by the target doctor who initiated the claim. The token of the consultation form is also updated. If it was not the first claim, due to the token update, the tokens of the consultation forms in the personal pool are verified based on the new token of the consultation form. If the token verification fails, the consultation form is refused treatment by the target doctor who was not the first to claim it.

[0083] If the consultation form is not received within a preset time, the doctor node 530 re-determines the target doctor group that matches the consultation form, and the push node 540 updates the token of the consultation form (optionally, this is done if token verification is available), and pushes the consultation form and its new token (optionally) together to the personal pool of one or more target doctors in the new target doctor group.

[0084] In this system, doctor node 530 can re-determine the target doctor group to match the consultation form based on the consultation information and the doctor's service information. In some embodiments, the re-matching of doctor node 530 can appropriately relax the matching requirements between the consultation form and the doctor compared to the initial matching. For example, it can relax the requirements on the doctor's current workload or activity level, thereby finding more matching target doctors and enabling the consultation form to be treated as soon as possible. The number of target doctors in the new target doctor group reassigned to the consultation form can be set to be greater than the number of target doctors in the previously assigned target doctor group, thus enabling the consultation form to be treated as quickly as possible.

[0085] When a target doctor retrieves consultation orders from their personal pool, the doctor's personal pool service 560 verifies the token of each consultation order in the pool and outputs a valid consultation order if the token verification is successful. This achieves read-time repair.

[0086] Figure 6 A schematic diagram of the structure of a medical record processing device according to other embodiments of this disclosure is shown.

[0087] like Figure 6 As shown, the consultation form processing device 600 of this embodiment includes: a memory 610 and a processor 620 coupled to the memory 610. The processor 620 is configured to execute the consultation form processing method of any of the foregoing embodiments based on instructions stored in the memory 610.

[0088] The memory 610 may include, for example, system memory, fixed non-volatile storage media, etc. The system memory may store, for example, the operating system, application programs, boot loader, and other programs.

[0089] The processor 620 can be implemented using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates, or transistors, or other discrete hardware components.

[0090] Device 600 may also include input / output interfaces 630, network interfaces 640, and storage interfaces 650. These interfaces 630, 640, and 650, as well as the memory 610 and processor 620, can be connected, for example, via a bus 660. The input / output interface 630 provides a connection interface for input / output devices such as displays, mice, keyboards, and touchscreens. The network interface 640 provides a connection interface for various networked devices. The storage interface 650 provides a connection interface for external storage devices such as SD cards and USB flash drives. The bus 660 can use any bus architecture from a variety of bus structures. For example, bus architectures include, but are not limited to, Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, and Peripheral Component Interconnect (PCI) buses.

[0091] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more non-transitory computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer program code.

[0092] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0093] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0094] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0095] The above description is only a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

Claims

1. A method for processing medical records, characterized in that, include: Receive patient consultation forms; Based on the consultation information and the doctor's service information in the consultation form, determine the target doctor group that matches the consultation form; Generate and store a token for the consultation form, wherein the stored token for the consultation form is updated when the consultation form is first received or when it is not received within the time limit. The consultation form and its token are pushed to the personal pool of one or more target doctors in the target doctor group. The personal pool includes the consultation form and its token. Receive one or more order acceptance requests from one or more target doctors in response to the consultation form; According to the order in which the order requests are received, the tokens of the corresponding medical consultation forms in the personal pool of the target doctor are verified in turn based on the tokens of the stored medical consultation forms. If token verification fails, the verification of the next order request continues. If token verification succeeds, the corresponding order request is the first order request. The consultation form is assigned to the target doctor who issued the first order request to receive the consultation, and the stored token of the consultation form is updated. The first order request is the first valid order request received.

2. The method according to claim 1, characterized in that, Also includes: The order request following the first order request is treated as the second order request. Based on the new token of the stored consultation form, the token of the consultation form in the personal pool of the target doctor who issued the second order request is verified. If the token verification fails, the consultation request of the target doctor who issued the second order request is rejected.

3. The method according to claim 1, characterized in that, Also includes: If the consultation form is not received within a preset time, a new target doctor group matching the consultation form is determined, and the stored token of the consultation form is updated. The consultation form and its new token are pushed together to the personal pool of one or more target doctors in the new target doctor group; When the target doctor retrieves consultation orders from their personal pool, the tokens of each consultation order in the personal pool are verified based on the stored consultation order tokens, and a valid consultation order with successfully verified tokens is output.

4. The method according to claim 3, characterized in that, The number of target doctors in the new target doctor group is greater than the number of target doctors in the target doctor group.

5. The method according to claim 1, characterized in that, The consultation information on the consultation form includes at least one of the following: consultation form type and the department that needs to be consulted. The doctor's service information includes at least one of the following: the services the doctor can provide, the doctor's current workload, and the doctor's activity level.

6. The method according to claim 1, characterized in that, Also includes: Manage the individual pools of each target doctor, using department and doctor identifiers as keys, consultation number as field, and consultation-related information items as values. The consultation-related information items are expandable.

7. The method according to claim 1, characterized in that, Also includes: Supplement the preset information for valid medical consultations that have been successfully verified by the token, and then output the valid medical consultations that have been successfully verified by the token.

8. The method according to claim 1, characterized in that, include: The dispatch service receives patient consultation forms and sends them to the corresponding workflow orchestration service. The workflow orchestration service assigns doctor nodes and push nodes to consultation forms; The doctor node determines the target doctor group that matches the consultation form based on the consultation information and the doctor's service information. The push node pushes the consultation form to the personal pools of one or more target doctors in the target doctor group. Each target doctor's personal pool is maintained by a doctor personal pool service, and the doctor personal pool manager service manages the personal pools of each target doctor. The order status management service assigns the consultation order to the target doctor who issued the first order acceptance request to receive the consultation order. The first order acceptance request is the first valid order acceptance request received.

9. A medical record processing device, comprising: Memory; And a processor coupled to the memory, the processor being configured to execute the medical record processing method of any one of claims 1-8 based on instructions stored in the memory.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the medical record processing method according to any one of claims 1-8.

Images