Intelligent management method and system for traditional Chinese medicine decoction service based on knowledge graph

Abstract

The application relates to the field of traditional Chinese medicine pharmacy management, and provides a traditional Chinese medicine decoction service intelligent management method and system based on a knowledge graph, which comprises the following steps: constructing a traditional Chinese medicine decoction knowledge graph; performing identity recognition on a current processing object, searching for a target patient entity in the traditional Chinese medicine decoction knowledge graph based on the identity recognition result, and obtaining a to-be-processed prescription set associated with the target patient entity; isolating and grouping the to-be-processed prescription set based on incompatible relationships between the to-be-processed prescriptions, generating a prescription group entity; establishing a dispensing serial number lease node for the prescription group entity, assigning a target dispensing serial number to the prescription group entity when the dispensing serial number lease node meets an effectiveness condition, and establishing an association relationship among the target dispensing serial number, a decoction task and a decoction device; and pushing a dispensing voucher, a prescription label and a decoction label to a user terminal and / or a decoction device based on the association relationship. The application can improve the safety, standardization and process control efficiency of traditional Chinese medicine pharmacy decoction service.

Description

Technical Field

[0001] This application relates to the field of traditional Chinese medicine pharmacy management, and more specifically to a knowledge graph-based intelligent management method and system for traditional Chinese medicine decoction services. Background Technology

[0002] In existing technologies, traditional Chinese medicine decoction services often rely on manual record-keeping and simple spreadsheet management. In the traditional decoction process, patient information identification mainly depends on manual entry or simple card swiping, and prescription processing lacks intelligent merging and verification mechanisms, leading to low efficiency and a high risk of errors. Furthermore, existing management systems typically only have basic data storage functions, lacking the ability to visualize and trace the entire decoction process (from order acceptance, dispensing, decoction to delivery), and cannot effectively support batch management, workload statistics, and real-time monitoring of abnormal situations.

[0003] However, due to the lack of unified data standards and intelligent business logic processing mechanisms, existing technologies rely heavily on manual processes for prescription entry, information verification, voucher filling, and number allocation. This results in cumbersome and time-consuming processes, hindering efficiency and making it difficult to cope with peak-hour workloads, leading to long patient wait times. Furthermore, manual information entry during prescription processing is prone to errors such as incorrect patient identification, prescription information entry discrepancies, duplicate medication numbers, and mixed prescriptions, directly impacting the quality of decoction services and potentially posing medication safety risks. Moreover, when patients or administrators check the decoction progress, cross-stage manual verification is often required, resulting in low information transparency and negatively impacting service experience and management efficiency. Summary of the Invention

[0004] This application provides a knowledge graph-based intelligent management method and system for traditional Chinese medicine decoction services, which can solve the technical problems of low decoction efficiency, easy error in manual information entry, and low transparency of the decoction process in the prior art.

[0005] In a first aspect, embodiments of this application provide an intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs, the method comprising: Collect multi-source business events related to traditional Chinese medicine decoction services and construct a knowledge graph of traditional Chinese medicine decoction services; The current processing object is identified, and the target patient entity is retrieved in the Chinese herbal medicine decoction knowledge graph based on the identification result to obtain the set of prescriptions to be processed associated with the target patient entity. Based on the incompatibility between the prescriptions to be processed, the set of prescriptions to be processed is isolated and grouped to generate prescription group entities; A medication collection sequence number lease node is established for the prescription group entity. When the medication collection sequence number lease node meets the validity condition, a target medication collection sequence number is assigned to the prescription group entity, and the association relationship between the target medication collection sequence number, the decoction task, and the decoction equipment is established. Based on the association, a decoction control instruction corresponding to the prescription group entity is generated, and the medication voucher, prescription label, and decoction label corresponding to the decoction control instruction are pushed to the corresponding user terminal and / or decoction device.

[0006] Secondly, embodiments of this application provide a knowledge graph-based intelligent management system for traditional Chinese medicine decoction services, which has the function of implementing the knowledge graph-based intelligent management method for traditional Chinese medicine decoction services provided in the first aspect above. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, and the modules can be software and / or hardware.

[0007] In one embodiment, the knowledge graph-based intelligent management system for traditional Chinese medicine decoction services is used to execute the knowledge graph-based intelligent management method for traditional Chinese medicine decoction services provided in the first aspect; the system includes: The input / output unit is configured to collect multi-source business events related to traditional Chinese medicine decoction services and construct a knowledge graph of traditional Chinese medicine decoction services. The processing unit is configured to identify the current processing object and, based on the identification result, retrieve the target patient entity from the traditional Chinese medicine decoction knowledge graph to obtain a set of prescriptions to be processed associated with the target patient entity; based on the incompatibility relationships between the prescriptions to be processed, isolate and group the set of prescriptions to be processed to generate prescription group entities; establish a dispensing sequence number lease node for the prescription group entity; when the dispensing sequence number lease node meets the validity condition, assign a target dispensing sequence number to the prescription group entity and establish an association relationship between the target dispensing sequence number, the decoction task, and the decoction device; and generate a decoction control instruction corresponding to the prescription group entity based on the association relationship. The input / output module is also configured to push the medication voucher, prescription label, and decoction label corresponding to the decoction control command to the corresponding user terminal and / or decoction device.

[0008] Compared to existing technologies, this application embodiment collects multi-source business events related to traditional Chinese medicine (TCM) decoction services and constructs a TCM decoction knowledge graph. It then performs unified association modeling of patients, prescriptions, prescription groups, medication collection numbers, decoction tasks, and decoction equipment. Through target patient entity retrieval, acquisition of the set of prescriptions to be processed, isolation and grouping of incompatible prescription relationships, allocation of medication collection number leases, and generation of decoction control instructions, it achieves collaborative processing of key objects and nodes in the decoction process. This effectively reduces problems such as incorrect patient identity matching, mixed prescription groups, duplicate medication collection numbers, and low equipment collaboration efficiency. Since this application embodiment uses a knowledge graph for unified association processing, rather than the manual registration, manual verification, and decentralized management of existing technologies, it can improve data consistency and task execution accuracy in the TCM decoction process. Therefore, this application embodiment, by uniformly managing the object relationships and processing constraints in the TCM decoction business, can achieve automation and intelligence in the decoction process. Because knowledge graphs support multi-source data fusion, dynamic relationship retrieval, and constraint collaborative analysis, they can not only automatically identify, match, and allocate key links in the decoction process, but also enhance data consistency and process collaboration between different business nodes, thereby further improving the safety, standardization, and process control efficiency of the decoction service in Chinese pharmacies. Attached Figure Description

[0009] Figure 1 This is a schematic diagram illustrating a scenario of the intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs, as described in this application. Figure 2 This is a flowchart illustrating the intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs, as described in this application. Figures 3 to 6 This is a schematic diagram illustrating the principle of the intelligent management method for traditional Chinese medicine decoction service based on knowledge graphs, as described in this application embodiment. Figure 7 This is a schematic diagram of the structure of the intelligent management system for traditional Chinese medicine decoction service based on knowledge graph, which is an embodiment of this application. Detailed Implementation

[0010] This application provides a knowledge graph-based intelligent management method and system for traditional Chinese medicine (TCM) decoction services. It can be applied to a smart TCM pharmacy scenario where patient information, prescription information, decoction task information, and equipment information are uniformly managed, correlated, and collaboratively controlled. The decoction service management system may include a knowledge graph processing device and a business execution device, which can be deployed integratedly or separately.

[0011] The knowledge graph processing device is at least used to collect multi-source business events related to the traditional Chinese medicine decoction service, construct a knowledge graph for traditional Chinese medicine decoction, and perform target patient entity retrieval, acquisition of the set of prescriptions to be processed, prescription isolation and grouping, allocation of dispensing serial numbers, and generation of decoction control instructions based on the knowledge graph. The business execution device is used to receive and execute the decoction control instructions, output dispensing vouchers, prescription tags, and decoction tags, and feed back the execution results to the knowledge graph processing device.

[0012] The knowledge graph processing device can be an application for collecting multi-source business events, constructing a knowledge graph of traditional Chinese medicine decoction, and performing graph reasoning processing, or a server or terminal device with the application installed. The business execution device can be an identity recognition terminal, a user terminal, a label printing terminal, a barcode scanning terminal, a dispensing terminal, a decoction equipment, or a terminal device with corresponding business control programs deployed.

[0013] In existing technologies, traditional Chinese medicine decoction services are mostly processed through manual registration, manual verification, and simple information system assistance. Typically, staff obtain patient information by swiping cards, manually entering data, or querying ledgers, and then manually screen, group, number, and assign prescriptions. This approach stems from the fact that existing systems usually only have basic data recording capabilities and lack the ability to uniformly express and automatically analyze the complex relationships between patients, prescriptions, tasks, equipment, and status.

[0014] However, existing technologies have at least the following problems: First, patient identity information and prescription information are scattered and lack unified data standards, resulting in inaccurate patient identity matching and low prescription retrieval efficiency; second, the incompatibilities between different prescriptions, conflicts in decoction processes, and differences in patient scenarios mainly rely on manual experience judgment, which easily leads to prescription mixing and medication risks; third, medication vouchers, prescription labels, and decoction labels mostly use manual numbering or simple incremental numbering methods, which makes it difficult to avoid numbering conflicts and task mismatches in concurrent processing scenarios; fourth, there is a lack of a unified scheduling and control mechanism between the decoction task and the equipment, making it difficult to achieve automated processing of label output, task allocation, and equipment collaboration.

[0015] Compared to existing technologies, this application's embodiments collect multi-source business events related to traditional Chinese medicine decoction services and construct a knowledge graph for traditional Chinese medicine decoction services. This allows for unified association modeling of patients, prescriptions, prescription groups, medication collection numbers, decoction tasks, and decoction equipment. Furthermore, by retrieving target patient entities and sets of prescriptions to be processed based on identity recognition results, isolating and grouping prescriptions based on incompatible relationships between them, establishing medication collection number lease nodes for prescription group entities, and generating corresponding decoction control instructions, the problems of inaccurate patient identity matching, mixed prescription groups, duplicate medication collection numbers, and low collaborative efficiency of decoction tasks in existing technologies are solved.

[0016] In some implementations, the knowledge graph processing apparatus and the business execution apparatus are deployed separately. (See also...) Figure 1 The intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs provided in this application can be based on... Figure 1 The diagram illustrates a decoction service management system. This system may include a server 01, a terminal device 02, and a decoction device 03.

[0017] The server 01 can be a knowledge graph processing device, which can deploy a multi-source business event processing program, a knowledge graph construction program, a target patient entity retrieval program, a prescription incompatibility analysis program, a medication dispensing number lease allocation program, and a decoction control instruction generation program.

[0018] The terminal device 02 can be a business execution device, which can deploy an identity recognition program, a prescription processing program, a user interaction program, a label display program, or a QR code confirmation program. The terminal device 02 can receive the identity recognition data corresponding to the currently processed object and send the identity recognition data or the corresponding standardized data to the server 01.

[0019] The decoction-making device 03 can be a label printing device, a decoction machine, a dispensing terminal, or other devices related to the execution of the decoction-making task. It is used to receive the decoction-making control instructions generated by the server 01, and output the medicine collection voucher, prescription label and decoction label according to the decoction-making control instructions, and / or execute the corresponding decoction-making processing task.

[0020] In one example, terminal device 02 sends received identity verification data, prescription data, and operation events to server 01. Server 01 constructs or updates a knowledge graph of traditional Chinese medicine decoction services based on this data, retrieves target patient entities from the knowledge graph, and obtains a set of prescriptions to be processed. Subsequently, server 01 isolates and groups the set of prescriptions to be processed based on the incompatibility relationships between them, generating prescription group entities. For each prescription group entity, server 01 establishes a medication collection number lease node, assigning a target medication collection number to the prescription group entity when the validity condition is met. Afterward, server 01 generates a decoction control instruction corresponding to the prescription group entity and sends this instruction to terminal device 02 and / or decoction device 03. Terminal device 02 and / or decoction device 03 can output corresponding medication collection vouchers, prescription labels, and decoction labels based on the decoction control instruction. The execution results are fed back to server 01 for subsequent business recording, task progress tracking, and status updates.

[0021] It should be noted that the computing devices involved in the embodiments of this application can be servers and / or terminal devices. The servers involved in the embodiments of this application can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, security services, and big data and artificial intelligence platform services. The terminal devices involved in the embodiments of this application can be devices that provide data interaction capabilities to users or staff. They can be handheld devices with wireless connectivity, or dispensing terminals, barcode scanning terminals, label printing terminals, tablet devices, workstations, mobile phones, personal digital assistants, portable computers, vehicle terminals, or other devices with data processing and network communication capabilities. The terminal devices can exchange business data, status data, and control commands with the server to realize identity recognition, task interaction, label output, and status feedback in the traditional Chinese medicine decoction service.

[0022] Reference Figure 2 , Figure 2 This is a flowchart illustrating a knowledge graph-based intelligent management method for traditional Chinese medicine decoction services, provided in an embodiment of this application. The method can be executed by a knowledge graph-based intelligent management system for traditional Chinese medicine decoction services. The method includes the following steps: Step 101: Collect multi-source business events related to the traditional Chinese medicine decoction service and construct a knowledge graph of traditional Chinese medicine decoction services.

[0023] In this embodiment of the application, the multi-source business events related to the traditional Chinese medicine decoction service include at least identity recognition events, prescription receipt events, prescription change events, printing events, dispensing events, decoction events, delivery events, receipt signing events, deletion events, photo recording events, and device feedback events.

[0024] For example, the identity recognition event can be a card reading event or identity verification event generated when a patient uses a social security card, health card, ID card, or electronic medical insurance voucher to read information. The prescription receiving event can be a receiving event generated when the system receives prescription information submitted by the hospital information system, the pharmacy workstation, or the manual input terminal. The prescription change event can be an update event generated when a doctor withdraws, changes, or supplements a prescription, or when staff modify prescription attributes. The printing event can be an event generated, issued, successfully printed, failed to print, or reprinted event for a medication receipt, prescription label, or decoction label. The medication dispensing event can be an event generated when a prescription enters the medication dispensing state, medication dispensing begins, medication dispensing is completed, or medication dispensing is verified; the decoction event can be an event generated when a prescription enters the decoction gestation state, decoction begins, decoction is completed, special process processing is performed, or decoction is verified. The delivery event can be an event generated when medicines are packaged, shipped, being delivered, or arriving at a designated location. The signature event can be an event generated when a patient signs for receipt, the ward signs for receipt, or a person on behalf of the recipient confirms receipt. The deletion event can be an event generated when staff perform deletion or voiding operations on abnormal records, incorrect label records, or invalid task records. The photo-taking event can be an event generated when taking photos of valuable medicinal materials, special medicinal materials, packaged medicines, or abnormal prescriptions for evidence preservation. The device feedback event can be a result feedback event returned by a card reader, printer, barcode scanner, dispensing terminal, or decoction equipment after performing the corresponding business action.

[0025] In this embodiment of the application, the identity recognition event originates from at least one of the following: social security card, health card, ID card, and medical insurance electronic voucher reading terminal.

[0026] For example, when a patient swipes their social security card at a decoction service window using a terminal, an identity recognition event is generated, containing the card type, card number identifier, reading time, terminal number, and reading result. When a patient completes identity verification using an ID card reader, an identity recognition event is generated, containing the document type, document number, name, verification time, and verification status. When a patient scans their medical insurance electronic voucher for authentication, an identity recognition event is generated, containing the voucher identifier, authentication time, authentication terminal, and authentication result. These identity recognition events from different sources provide a unified data foundation for subsequent identity document entity matching and target patient entity retrieval.

[0027] In this embodiment of the application, the device feedback event includes at least one of the following: printing success feedback, printing failure feedback, QR code confirmation feedback, or terminal confirmation feedback.

[0028] For example, when a printing device successfully outputs a medication receipt, prescription label, or decoction label, a successful printing feedback event can be generated. This event may include a printing task identifier, device number, output time, and output result. When the printing device experiences a paper jam, paper shortage, offline status, or communication abnormality, a printing failure feedback event can be generated. This event may include the reason for failure, failure time, and abnormal device identifier. When staff or patients scan and confirm the medication receipt, prescription label, or medicine package using a barcode scanner, a barcode confirmation feedback event can be generated. This event may include the scanned object identifier, scanning time, scanning terminal, and confirmation result. When staff complete task confirmation, status switching, or abnormal reporting through a dispensing terminal, decoction terminal, or management terminal, a terminal confirmation feedback event can be generated. This event may include a task identifier, terminal number, operator identifier, confirmation time, and confirmation result. By collecting and writing back these device feedback events, dynamic updates of event nodes, device nodes, and status nodes in the traditional Chinese medicine decoction knowledge graph can be supported.

[0029] In this embodiment of the application, the knowledge graph of traditional Chinese medicine decoction includes the relationships between patient entities, prescription entities, prescription group entities, medicine collection sequence number entities, batch entities, task entities, device entities, status entities, and abnormal entities.

[0030] As an optional embodiment, step 101 involves collecting multi-source business events related to the traditional Chinese medicine decoction service and constructing a knowledge graph of traditional Chinese medicine decoction services. This includes: collecting multi-source business events related to the traditional Chinese medicine decoction service; performing field mapping, timestamp unification, event type normalization, outlier filtering, and duplicate event elimination on the multi-source business events to generate a standardized event flow; extracting patient entities, prescription entities, prescription group entities, medication collection sequence number entities, batch entities, task entities, equipment entities, status entities, and abnormal entities based on the standardized event flow, establishing the association relationships between each entity, and constructing the knowledge graph of traditional Chinese medicine decoction services.

[0031] In the above embodiments, firstly, multi-source business events related to the traditional Chinese medicine decoction service are collected.

[0032] In this embodiment, at least one of the following can be used to collect business data throughout the entire process of traditional Chinese medicine decoction service, in order to form multi-source business events: server, management terminal, identity recognition terminal, printing terminal, dispensing terminal, decoction equipment, barcode scanning terminal, delivery terminal or hospital information system interface.

[0033] The multi-source business events may include identity recognition events, prescription receipt events, prescription change events, printing events, dispensing events, decoction events, delivery events, receipt signing events, deletion events, photo recording events, and device feedback events.

[0034] Among them, the identity recognition event can be generated by social security card reading terminal, health card reading terminal, ID card recognition terminal, medical insurance electronic voucher scanning terminal or manual entry terminal, and is used to record information such as the voucher type, voucher identifier, recognition time, recognition terminal and recognition result corresponding to the patient's identity recognition process.

[0035] Prescription receipt events can be generated by the hospital information system interface, outpatient workstation, inpatient workstation, or herbal medicine shop order receiving terminal, and are used to record the prescription number, patient identifier, doctor identifier, prescription time, medicinal materials composition, number of doses, decoction requirements, and delivery information.

[0036] Prescription change events can be generated by the doctor's terminal, the review terminal, or the management terminal, and are used to record changes such as prescription cancellation, prescription modification, addition or subtraction of medicinal materials, adjustment of decoction method, or adjustment of delivery method.

[0037] Printing events can be generated by medication receipt printing terminals, prescription label printing terminals, or decoction label printing terminals, and are used to record the printing task number, printing object type, printing device number, printing time, and printing result.

[0038] Dispensing events can be generated by dispensing terminals or dispensing workstations to record information such as prescriptions entering the dispensing state, dispensing starting, dispensing completion, and dispensing verification.

[0039] Decoction events can be generated by the decoction machine, decoction control terminal, or manual confirmation terminal. They are used to record information such as the prescription entering the decoction state, the start of decoction, the pre-decoction process, the post-decoction process, the completion of decoction, and the decoction verification process.

[0040] Delivery events and receipt events can be generated by delivery terminals, ward terminals, or patient receipt terminals to record information such as outbound, delivery in progress, arrival, and receipt confirmation.

[0041] Deletion events can be generated by the management terminal to record the deleted object, the reason for deletion, the time of deletion, and the person who performed the deletion.

[0042] Photo recording events can be generated by a camera terminal or mobile terminal and are used to record the image file identifier, shooting time, shooting equipment and shooting object corresponding to valuable medicinal materials, special medicinal materials, abnormal prescriptions or packaging results.

[0043] Device feedback events can be generated by printing devices, barcode scanners, decoction equipment, dispensing terminals, or user terminals. These events are used to record execution result information such as successful printing feedback, printing failure feedback, barcode confirmation feedback, task confirmation feedback, and device anomaly feedback.

[0044] In some implementations, the system can continuously collect the above-mentioned multi-source business events through methods such as interface polling, message subscription, device active reporting, database log collection, or manual operation triggering, and write the collected raw business events into the raw event cache, message queue, or raw event database for subsequent standardized processing.

[0045] Furthermore, in the above embodiments, the multi-source business events are subjected to field mapping, timestamp unification, event type normalization, outlier filtering, and duplicate event elimination to generate a standardized event stream.

[0046] In this embodiment, the event preprocessing module can perform standardized processing on the collected raw business events.

[0047] Field mapping refers to mapping field names in the original event to a unified field when the data formats output from different source terminals, different business systems, or different device manufacturers are inconsistent. For example, Patient ID, Patient Number, and Patient Identifier can be uniformly mapped to the Patient Identifier field; Prescription Number, Prescription_id, and RecipeNo can be uniformly mapped to the Prescription Number field; and Device_Sn, Terminal Number, and Machine_Code can be uniformly mapped to the Device Identifier field.

[0048] Timestamp unification refers to converting the local time, server time, millisecond timestamps, or character timestamps used in different systems into a preset time standard format to facilitate time sequence analysis and status tracking of events.

[0049] Event type normalization refers to mapping different event names describing the same business action across different terminals or systems to a unified event type. For example, print_ok, printing completed, and label output can be uniformly normalized into a print success event, and scan passed, verification successful, and confirmation completed can be uniformly normalized into a confirmation feedback event.

[0050] Outlier filtering refers to removing invalid events that are severely missing fields, have obviously abnormal times, have illegal device identifiers, have object numbers that do not meet preset coding rules, or have state transitions that do not conform to basic process constraints.

[0051] Duplicate event elimination refers to the process of merging or deduplicating events that are repeatedly reported, retransmitted over the network, or manually clicked repeatedly by the same terminal, and that construct an event fingerprint based on the patient identifier, prescription number, event type, device identifier, and time window.

[0052] In some implementations, after preprocessing, each business event can be uniformly represented as a structured event record, which includes at least event number, event type, event time, patient identifier, prescription number, device identifier, operator identifier, event status, and event payload information.

[0053] Based on multiple structured event records, arranged according to time sequence, object identifier, or task identifier, a standardized event flow can be generated. This standardized event flow can reflect the entire business trajectory of a patient from identification, prescription receipt, medication dispensing, decoction preparation, delivery, to receipt confirmation.

[0054] Finally, in the above embodiments, based on the standardized event flow, patient entities, prescription entities, prescription group entities, medication dispensing sequence number entities, batch entities, task entities, device entities, status entities, and abnormal entities are extracted, and the relationships between each entity are established to construct the knowledge graph of traditional Chinese medicine decoction.

[0055] In this embodiment, entity extraction, relation extraction, and graph writing processing can be performed on the standardized event flow. Entity extraction can include: extracting patient entities and identity credential-related attributes from identity recognition events; extracting prescription entities and their medicinal composition, dosage, decoction requirements, and efficacy attributes from prescription receipt events and prescription change events; extracting prescription group entities from prescription isolation and grouping results; extracting drug dispensing sequence number entities from numbering and allocation results; extracting batch entities from batch scheduling results; extracting task entities from business processes such as dispensing, decoction, and delivery; extracting equipment entities from equipment information such as printing equipment, decoction machines, barcode scanning terminals, and management terminals; extracting status entities from flow nodes such as pending dispensing, dispensing, pending decoction, decoction being processed, delivered, and completed; and extracting abnormal entities from records such as printing failure, status conflict, label mismatch, equipment offline, and batch delay.

[0056] For example, the relationship extraction may include: establishing a correspondence between patient entities and identity credentials; establishing an association between patient entities and prescription entities; establishing an attribution relationship between prescription entities and prescription group entities; establishing an allocation relationship between prescription group entities and medication collection number entities; establishing an attribution relationship between medication collection number entities and batch entities; establishing an execution relationship between task entities and device entities; establishing a state change relationship between task entities and state entities; and establishing abnormal association relationships between abnormal entities and patient entities, prescription entities, task entities, device entities, or state entities.

[0057] In some implementations, each entity can be represented as a graph node, the semantic relationships between entities can be represented as graph edges, and the event occurrence time, event source, risk level, processing result, etc. can be written into the graph database as node attributes or edge attributes, thereby forming the knowledge graph of traditional Chinese medicine decoction.

[0058] For example, a graph relationship can be established such as Patient Entity A - Associated with Prescription Entity B, Prescription Entity B - Belongs to Prescription Group Entity C, Prescription Group Entity C - Assigned to Dispensing Sequence Number Entity D, Task Entity E - Used to Equipment Entity F, and Abnormal Entity G - Associated with Status Entity H.

[0059] By using the knowledge graph of traditional Chinese medicine decoction, object information, task information, device information, and status information that were originally scattered across different devices, terminals, and business processes can be uniformly linked, providing a graph-based data foundation for subsequent target patient entity retrieval, acquisition of prescription sets to be processed, prescription incompatibility analysis, prescription isolation and grouping, allocation of dispensing serial numbers, and generation of decoction control instructions.

[0060] It should be noted that the execution order of the above steps is not strictly limited. In some implementations, historical business data can be standardized offline and the graph can be initialized and constructed first, followed by real-time collection and incremental writing of new business events. Alternatively, a process of simultaneous collection, standardization, and graph updating can be performed on real-time events to achieve dynamic modeling and continuous maintenance of the entire process of traditional Chinese medicine decoction services.

[0061] Step 102: Identify the current processing object and, based on the identification result, retrieve the target patient entity in the Chinese herbal medicine decoction knowledge graph to obtain the set of prescriptions to be processed associated with the target patient entity.

[0062] This can be understood as the current processing object referring to the target business object to be identified, retrieved, or processed by the system under the current business node of the traditional Chinese medicine decoction service. The current processing object can be the patient themselves, patient identification credentials, decoction service requests, candidate prescription records, or other business data objects associated with the patient. In step 102, the current processing object can mainly be understood as the patient's identity object to be identified or the decoction service request triggered by that identity object. By identifying the current processing object, the corresponding identity credential entity is matched in the traditional Chinese medicine decoction knowledge graph, and the associated target patient entity and the set of prescriptions to be processed are further retrieved.

[0063] Figure 3 The interface primarily showcases the patient order acceptance and prescription processing interface. This interface allows for reading patient prescription information after card swiping, card reading, or input of identity information, and displays a set of candidate prescriptions associated with the current patient. The interface displays information such as prescription number, name, number of prescriptions, card number, ID card information, and entry date. Staff can use this interface to verify candidate prescriptions and further select processing methods such as "prepared by proxy" or "prepared by the patient." Figure 3 The specific implementation effect of step 102 is shown.

[0064] As an optional embodiment, in step 102, the current processing object is identified, and the target patient entity is retrieved from the traditional Chinese medicine decoction knowledge graph based on the identification result to obtain the set of prescriptions to be processed associated with the target patient entity, including: Collect the identity recognition data corresponding to the current processing object; match the corresponding identity credential entity in the traditional Chinese medicine decoction knowledge graph based on the identity recognition data; retrieve the associated target patient entity based on the identity credential entity, and retrieve the candidate prescription set associated with the target patient entity; perform validity screening on the candidate prescription set to obtain the prescription set to be processed.

[0065] Specifically, firstly, the identity verification data corresponding to the currently processed object is collected. This identity verification data includes at least one of the following: social security card information, health card information, ID card information, electronic medical insurance voucher information, or manually entered identity information.

[0066] In this step, identity verification data corresponding to the currently processed object is collected through an identity verification terminal, a manual data entry terminal, or a hospital information system interface. The identity verification data includes at least one of the following: social security card information, health card information, ID card information, electronic medical insurance voucher information, or manually entered identity information. It may include voucher type, voucher identifier, name, ID number, visit identifier, verification time, terminal identifier, and verification result. For identity verification data from different sources, further field mapping and format unification processing can be performed to generate standardized identity input data for subsequent identity credential entity matching. In cases of recognition failure, missing information, or data conflicts, a re-identification, manual confirmation, or supplementary data entry process can be triggered, thereby improving the accuracy and stability of subsequent target patient entity retrieval.

[0067] In some implementations, the identity verification data includes at least one of the following: social security card information, health card information, ID card information, electronic medical insurance voucher information, or manually entered identity information. For example, when a patient uses a social security card reader at a decoction window for identity verification, the corresponding card type, card number identifier, name, gender, date of birth, reading time, reader identifier, and reading result can be collected. When a patient uses an ID card reader for identity verification, the document type, document number, name, document validity period, recognition time, recognition device identifier, and recognition status can be collected. When a patient uses an electronic medical insurance voucher scanning terminal for authentication, the voucher identifier, authentication time, authentication terminal, authentication result, and the user identity identifier corresponding to the voucher can be collected. When staff enter patient information through a manual input terminal, the patient's name, contact number, document number, medical card number, outpatient number, inpatient number, or other information that can be used for identity verification can be collected.

[0068] In other embodiments, the acquisition method of the identity recognition data may include at least one of the following: active device reading, terminal scanning, interface call acquisition, and manual data entry. For identity recognition data from different sources, further format unification and field standardization processing can be performed. For example, card numbers, ID numbers, medical insurance voucher identifiers, patient names, and medical visit identifiers from different sources can be mapped to unified data fields for subsequent unified matching within the traditional Chinese medicine decoction knowledge graph. In cases of missing information, recognition failure, or field anomalies, the corresponding abnormal status can be recorded, triggering a re-identification, manual confirmation, or supplementary data entry process.

[0069] In some implementations, to improve the accuracy and completeness of identity verification data collection, the system can jointly collect and cross-validate multiple identity verification data sources corresponding to the same currently processed object. For example, it can simultaneously collect the patient's electronic medical insurance voucher information and manually entered name and ID number information, and perform consistency comparisons on the data from different sources. When there are conflicts between multiple data sources, the system can select the data with higher credibility as the input data for subsequent identity credential entity matching according to preset priority rules. Through the above methods, the deviation of identity information caused by a single identification source can be reduced, and the accuracy of subsequent target patient entity retrieval can be improved.

[0070] By collecting the identity recognition data corresponding to the current processing object, the system can unify and structure the patient identity information that was originally scattered across different recognition terminals, different business entry points and different information sources, laying the data foundation for matching the corresponding identity credential entity in the traditional Chinese medicine decoction knowledge graph based on the identity recognition data.

[0071] In the optional embodiment described in step 102, further optionally, the identity verification data is matched with the corresponding identity credential entity in the traditional Chinese medicine decoction knowledge graph. Specifically, firstly, the collected identity verification data is parsed to extract identity feature fields, which include at least one or more of the following: credential type, credential identifier, name, ID number, medical card number, medical insurance credential identifier, date of birth, gender, and contact number. Then, the identity feature fields are compared with the pre-stored identity credential entity attributes in the traditional Chinese medicine decoction knowledge graph to determine a set of candidate identity credential entities that match the identity verification data.

[0072] In some implementations, precise matching can be prioritized based on highly unique identity identifiers. For example, when the identity recognition data includes social security card numbers, ID card numbers, electronic medical insurance voucher identifiers, or health card numbers, these identifiers can be used as the primary matching key to search for identity credential entities with the same identifier attribute in the traditional Chinese medicine decoction knowledge graph. When a unique match is found, the corresponding identity credential entity can be directly identified as the target identity credential entity.

[0073] In other implementations, when the identity recognition data lacks a unique identifier, the unique identifier reading fails, or multiple candidate identity credential entities exist, joint matching can be performed based on multiple identity feature fields. Specifically, similarity calculations or consistency comparisons can be performed on fields such as name, gender, date of birth, contact number, medical card number, outpatient number, and inpatient number. Combined with the existing associations between identity credential entities and patient entities / treatment entities, a matching score is calculated for each candidate identity credential entity. Subsequently, the candidate identity credential entities are sorted from highest to lowest matching score, and the identity credential entity whose matching score meets a preset threshold is selected as the matching result.

[0074] In some implementations, to improve matching accuracy, the system can also utilize the relational constraint information in the traditional Chinese medicine decoction knowledge graph to perform secondary verification of identity credential entities. For example, if a candidate identity credential entity has already been associated with a specific patient entity, historical prescription entity, or medical record entity, the system can further determine whether the time, department, hospital, or business entry point corresponding to the current identity recognition data is consistent with the associated relationship. If consistent, the matching priority of the candidate identity credential entity is increased. If inconsistent, its matching priority is decreased or it is removed.

[0075] In other implementations, when the matching scores of multiple candidate identity credential entities are close, or when there is a conflict in identity information, the system can temporarily retain multiple candidate identity credential entities and generate a pending confirmation mark to trigger a manual review, secondary identification, or supplementary entry process; after receiving the manual confirmation result or supplementary identity information, the candidate identity credential entities are updated and filtered to determine the final matching identity credential entity.

[0076] In this way, identity recognition data from different identification terminals, different credential types, and different input methods can be uniformly matched with the identity credential entities in the traditional Chinese medicine decoction knowledge graph, thereby providing an accurate graph entry point for subsequent retrieval of associated target patient entities based on the identity credential entities.

[0077] In the optional embodiment of step 102, further optionally, retrieving the associated target patient entity based on the identity credential entity and retrieving the candidate prescription set associated with the target patient entity can be implemented as follows: retrieving the associated candidate patient entity set in the traditional Chinese medicine decoction knowledge graph based on the identity credential entity, and extracting the historical prescription information, prescription time information, and consultation time information corresponding to each candidate patient entity; constructing a triplet relationship chain containing patient, prescription, and time based on the historical prescription information, prescription time information, and consultation time information corresponding to each candidate patient entity, and using a temporal knowledge graph reasoning model to retrieve the historical prescription information of each candidate patient entity. The drug behavior pattern is analyzed over time to obtain the behavior matching degree corresponding to each candidate patient entity; TCM constitution tags are extracted from the historical prescriptions associated with each candidate patient entity, and the semantic similarity of the constitution tags between the current processing object and each candidate patient entity is calculated based on the composition, properties and / or efficacy information of the medicinal materials in the prescription corresponding to the current processing object to obtain the constitution matching degree corresponding to each candidate patient entity; based on the behavior matching degree and the constitution matching degree, the target patient entity corresponding to the current processing object is determined; based on the association relationship between the target patient entity and the prescription entity, the set of candidate prescriptions associated with the target patient entity is retrieved.

[0078] In the optional embodiment described in step 102, further optionally, retrieving the associated target patient entity based on the identity credential entity and retrieving the candidate prescription set associated with the target patient entity can be implemented as follows: First, based on the identity credential entity, retrieve the set of candidate patient entities that are associated with it in the traditional Chinese medicine decoction knowledge graph. The association may include the real-name binding relationship between the identity credential entity and the patient entity, the historical medical visit association relationship, the historical prescription ownership relationship, or the historical decoction service association relationship. For each candidate patient entity, further extract its associated historical prescription information, prescription time information, and medical visit time information in the traditional Chinese medicine decoction knowledge graph as basic data for subsequent patient identification and reasoning.

[0079] In some implementations, a triplet relationship chain containing patient, prescription, and time can be constructed based on the historical prescription information, prescription time information, and consultation time information corresponding to each candidate patient entity. For example, the historical record corresponding to a candidate patient entity can be represented as a relationship structure of "patient entity A - associated - prescription entity B - corresponding prescription time - time entity C", or as a temporal relationship structure of "patient entity A - consultation behavior occurs in time entity C - prescription entity B is generated". Based on the above triplet relationship chain, a temporal knowledge graph reasoning model can be used to perform temporal association analysis on the historical medication collection behavior patterns of each candidate patient entity within a preset time window. The temporal association analysis can consider temporal characteristics such as the patient's historical prescription cycle, medication collection frequency, medication collection time distribution, follow-up visit interval, department changes, and prescription change trends, thereby outputting the behavior matching degree corresponding to each candidate patient entity. For example, if a candidate patient entity has repeatedly had traditional Chinese medicine decoction collection at a fixed time every week within the past thirty days, and the time of the current identity recognition is highly consistent with the historical behavior pattern, then the behavior matching degree corresponding to the candidate patient entity can be improved.

[0080] In other implementations, TCM constitution tags can be extracted from historical prescriptions associated with each candidate patient entity to further improve the accuracy of target patient entity retrieval. Specifically, TCM constitution tags associated with candidate patient entities can be extracted based on the composition, properties, efficacy, indications, or past treatment directions of medicinal materials in historical prescriptions, such as Qi deficiency, Yang deficiency, Yin deficiency, phlegm-dampness, or damp-heat constitution. Simultaneously, a constitution feature representation of the current processing object can be generated based on the composition, properties, and / or efficacy information of medicinal materials in the prescription corresponding to the current processing object. Subsequently, semantic similarity calculation can be used to calculate the similarity between the constitution feature representation of the current processing object and the constitution tags corresponding to each candidate patient entity to obtain the constitution matching degree for each candidate patient entity. For example, when the current prescription contains Qi-tonifying herbs such as Astragalus membranaceus, Codonopsis pilosula, and Atractylodes macrocephala, and the prescription as a whole embodies the effects of tonifying the middle energizer and benefiting Qi, strengthening the spleen and lungs, it can be determined that the constitution feature of the current processing object is more inclined towards Qi deficiency, thus improving the constitution matching degree of candidate patient entities that match the Qi deficiency constitution tag.

[0081] In some implementations, a comprehensive score can be calculated for each candidate patient entity based on the behavioral matching degree and the physical fitness matching degree, and the target patient entity corresponding to the current processing object can be determined from the scores. The comprehensive score can be obtained using a weighted fusion method, where the weights of the behavioral matching degree and the physical fitness matching degree can be dynamically adjusted according to the business scenario, data completeness, or historical recognition accuracy. For example, when the identity credential information is relatively complete but the historical prescription data is relatively scarce, the weight of the behavioral matching degree in the comprehensive score can be appropriately increased. When the historical behavioral patterns among candidate patient entities are relatively similar, the weight of the physical fitness matching degree in the comprehensive score can be appropriately increased. Finally, the candidate patient entity with the highest comprehensive score that meets the preset threshold condition can be determined as the target patient entity. If no candidate patient entity meets the preset threshold condition, a manual confirmation process or a supplementary information entry process can be triggered.

[0082] After identifying the target patient entity, a set of candidate prescriptions associated with the target patient entity can be retrieved based on the association between the target patient entity and the prescription entity. Specifically, the search can be performed along the relationship path of "target patient entity - association - prescription entity" in the traditional Chinese medicine decoction knowledge graph, and prescriptions associated with the target patient entity can be filtered by combining prescription status, prescription time, receipt time, consultation time, and historical processing records to obtain a set of candidate prescriptions. The prescriptions in the set of candidate prescriptions can be prescriptions that have been received but not processed, prescriptions that are waiting to be dispensed, prescriptions that are waiting to be grouped, or other prescription records that meet preset conditions. In this way, starting from the identity credential entity, the screening of candidate patient entities, the identification of target patient entities, and the retrieval of candidate prescription sets can be completed step by step in the knowledge graph, thereby providing support for subsequent prescription validity screening and determination of the set of prescriptions to be processed.

[0083] For example, in a specific application scenario, a patient initially verifies their identity at a window using their ID card. For subsequent follow-up visits, they use their electronic medical insurance voucher for authentication. After receiving the identity verification data corresponding to the electronic medical insurance voucher, the system first searches the knowledge graph for multiple candidate patient entities associated with that voucher, and extracts the historical prescription information and appointment time information for each candidate patient entity over the past month. If one candidate patient entity has consistently had traditional Chinese medicine decoctions prepared and picked up on Wednesday mornings for the past few weeks, and the current authentication time is also within the same timeframe, and the composition and efficacy characteristics of the medicinal materials in their historical prescriptions are highly similar to the physical characteristics corresponding to the current prescription, then this candidate patient entity can be identified as the target patient entity. Further, the system retrieves the set of candidate prescriptions associated with this target patient entity for subsequent filtering to obtain the set of prescriptions to be processed.

[0084] The validity screening provided in this application includes at least one or more of the following: prescription status verification, prescription time verification, patient identity consistency verification, and duplicate processing verification.

[0085] For example, prescription status verification can be used to determine whether a candidate prescription is currently in a pending, dispensing, grouping, or other preset pending status, and to exclude prescriptions that have been completed, cancelled, invalidated, or closed. Prescription time verification can be used to determine whether the prescription's opening time, receiving time, or consultation time falls within a preset time window, to exclude prescriptions that are too old, expired, or do not match the current business hours. Patient identity consistency verification can be used to determine whether the patient identity information associated with the candidate prescription matches the identity feature information corresponding to the target patient entity, to reduce the risk of mismatch between patients with the same name, patients sharing contact information, or patients with multiple credentials. Duplicate processing verification can be used to determine whether a candidate prescription has already been grouped, numbered, printed, dispensed, decocted, or signed for, thereby avoiding the same prescription being processed, numbered, or repeatedly entered into the decoction process.

[0086] Figure 4 The main interface shown is the prescription details viewing interface. This interface pops up or expands after a candidate prescription is selected, displaying detailed information such as the patient's basic information, prescription amount, number of doses, and the names, specifications, and dosages of each medicinal material in the prescription. Through this interface, staff can review the current prescription content, providing a basis for manual confirmation for subsequent prescription validity screening, prescription incompatibility analysis, and prescription grouping. Figure 4 An example of the implementation effect of retrieving the candidate prescription set and verifying the candidate prescriptions in step 102 is shown.

[0087] In the above optional embodiment of step 102, it is further optional to perform validity screening on the candidate prescription set to obtain a prescription set to be processed, which can be implemented as follows: First, a state chain verification is performed on the candidate prescription set. Specifically, based on the association between prescription entities, state entities, and event entities in the traditional Chinese medicine decoction knowledge graph, the state transition chain corresponding to each candidate prescription can be extracted. Candidate prescriptions in the pending state are then filtered out according to a preset set of pending states, and prescriptions that have been completed, canceled, invalidated, or closed are removed. Unlike judging solely based on a single state field, this embodiment can further combine the historical event nodes associated with the prescription to verify the consistency of the state. For example, when the current state field of a candidate prescription shows "pending," but its associated event chain already contains a decoction completion event or a receipt confirmation event, the candidate prescription can be identified as an abnormal state prescription and removed, thereby improving the accuracy of the state verification.

[0088] After filtering out candidate prescriptions in a preset pending state, a prescription time verification based on time constraints can be further performed. Specifically, the prescription time, receipt time, consultation time, and most recent status update time corresponding to each candidate prescription can be obtained, and the prescription time sequence characteristics can be constructed by combining them with the current business time. Subsequently, an adaptive time window filtering method can be adopted to dynamically set the effective time range according to different business scenarios. For example, a shorter time window can be used for outpatient prescriptions prepared on the same day. A relatively longer time window can be used for inpatient continuous treatment prescriptions or prescriptions prepared by appointment. Candidate prescriptions within the time window can be retained, while candidate prescriptions that exceed the preset time limit, are significantly delayed, or have abnormal time logic can be removed. Furthermore, in some embodiments, the time window can be personalized according to the historical follow-up visit cycle and historical medication collection time distribution corresponding to the target patient entity to improve the matching degree between candidate prescription time filtering and real business scenarios.

[0089] After time verification is completed, patient identity consistency verification can be further performed. Specifically, patient identity information associated with candidate prescriptions can be extracted, including identity features such as name, ID number, medical card number, medical insurance voucher identifier, contact number, gender, and date of birth, and the identity features corresponding to the target patient entity can also be extracted. Subsequently, an identity verification method based on graph neighborhood consistency scoring can be used to perform multi-dimensional comparison between the patient identity information associated with the candidate prescription and the identity features corresponding to the target patient entity. The graph neighborhood consistency scoring can comprehensively consider the following factors: the degree of matching between the patient node associated with the candidate prescription and the target patient entity in terms of identity attributes, the degree of overlap in historical prescriptions and medical records, behavioral consistency in the time dimension, and the stability of association in terms of family relationship, contact information, or business entry point. Candidate prescriptions with consistency scores meeting a preset threshold are retained. Candidate prescriptions with consistency scores below the preset threshold are eliminated or marked for manual review. This method can avoid the problem of erroneous association caused by simple matching based on a single name or a single ID field.

[0090] After identity consistency verification, duplicate processing verification can be further performed. Specifically, a prescription event fingerprint corresponding to each candidate prescription can be generated based on the prescription number, visit number, prescription group identifier, medication collection sequence number, status record, and historical processing record. The prescription event fingerprint can be generated by combining the unique prescription identifier, key state node sequence, associated task identifier, and key time segment, and is used to uniquely represent the processing trajectory of the candidate prescription in the decoction process. Subsequently, the prescription event fingerprints of each candidate prescription can be compared based on the event nodes and status nodes in the traditional Chinese medicine decoction knowledge graph. When multiple candidate prescriptions are detected to have the same or highly similar event fingerprints, it can be determined that the corresponding candidate prescription has the risk of duplicate recording, duplicate reception, or duplicate processing, and its state transition chain can be used to determine whether it belongs to a processed prescription, a historical prescription, or a redundant prescription caused by network retransmission. For candidate prescriptions identified as duplicate prescriptions or processed prescriptions, deduplication and removal processing can be performed.

[0091] After completing state chain verification, timing constraint verification, identity consistency verification, and duplicate processing verification, the candidate prescriptions retained after screening can be determined as the set of prescriptions to be processed. Each candidate prescription in the set of prescriptions to be processed can meet the conditions of being in a preset pending state, being within a valid time window, having an identity consistent with the target patient entity, and not being processed repeatedly, thereby providing accurate and reliable input data for subsequent isolation and grouping based on the incompatibility relationship between prescriptions to be processed.

[0092] In a specific application scenario, after receiving multiple candidate prescriptions associated with a target patient entity, the state transition chains of each candidate prescription can be extracted from the knowledge graph. If a candidate prescription is marked as pending processing but a confirmation event has already occurred in its event chain, it is identified as having an abnormal state and is removed. Subsequently, time window filtering is performed on the remaining candidate prescriptions to remove historical prescriptions whose prescription time exceeds a preset time limit. Then, a graph neighborhood consistency score is performed on the remaining candidate prescriptions. If the ID number of the patient corresponding to a candidate prescription does not match the target patient entity and its historical medical path does not match, it is removed. Finally, prescription records that were repeatedly received due to network retransmission are identified based on the prescription event fingerprint and deduplicated. The candidate prescriptions retained after the above filtering can be determined as the set of prescriptions to be processed.

[0093] Step 103: Based on the incompatibility between the prescriptions to be processed, the set of prescriptions to be processed is isolated and grouped to generate prescription group entities.

[0094] As an optional embodiment, in step 103, the prescription set to be processed is isolated and grouped based on the incompatibility relationship between the prescriptions to be processed to generate a prescription group entity, including: constructing a prescription incompatibility relationship graph based on the incompatibility relationship between the prescriptions to be processed; and isolating and grouping the prescription set to be processed according to the prescription incompatibility relationship graph to generate a prescription group entity.

[0095] In this embodiment, the incompatibility relationship between prescriptions to be processed refers to the constraint relationship that may lead to compatibility risks, process conflicts, identity confusion risks, or task execution conflicts when two or more prescriptions are processed in the same group, on the same equipment, or in the same process. Isolation and grouping refers to the system grouping the set of prescriptions to be processed based on the aforementioned incompatibility relationship, isolating prescriptions with incompatible relationships into different groups, and grouping prescriptions without incompatible relationships into the same group. A prescription group entity is a graph entity generated based on the isolation and grouping results, used to represent a set of prescriptions that can jointly enter the subsequent numbering allocation, task generation, and equipment scheduling processes. Through the above processing, the set of prescriptions to be processed can be transformed into multiple prescription group entities with clear boundaries, well-defined relationships, and ease of unified processing.

[0096] Further optionally, in step 103, constructing a prescription incompatibility graph based on the incompatibility relationships between the prescriptions to be processed includes: extracting key feature information corresponding to each prescription to be processed; performing association reasoning on any two prescriptions to be processed based on the association relationships between medicinal material entities, patient entities, prescription entities, and process entities in the traditional Chinese medicine decoction knowledge graph to determine whether there is an incompatibility relationship between the two prescriptions to be processed; when there is an incompatibility relationship between any two prescriptions to be processed, establishing incompatible edges between the graph nodes corresponding to the two prescriptions to be processed, and determining the edge weights of the incompatible edges according to the type, risk level, and scenario association degree of the incompatibility relationship; and constructing a prescription incompatibility graph using each prescription to be processed as a graph node and the incompatible edges as graph edges.

[0097] The key feature information includes at least one or more of the following: prescription drug composition, drug properties, drug incompatibilities, drug user labels, decoction process requirements, prescription efficacy, patient relationship, delivery address, and medication time.

[0098] The incompatibility relationships include at least one of the following: incompatible drug combinations, conflicting drug properties, conflicting populations, conflicting decoction processes, antagonistic effects, conflicting medication use in home settings, and conflicting medication administration times.

[0099] Specifically, in this embodiment, the key feature information is first extracted for each prescription in the set of prescriptions to be processed. This key feature information can originate from the attribute and relationship information of medicinal material entities, patient entities, process entities, and task entities associated with the prescription in the traditional Chinese medicine decoction knowledge graph. For example, information such as medicinal material name, medicinal property category, incompatibilities, toxicity level, and special processing requirements can be extracted from the medicinal material entities associated with the prescription entity. Information such as gender, age, pregnancy / partum status, underlying disease tags, and family relationship tags can be extracted from the patient entity. Information such as pre-decoction, post-decoction, separate decoction, melting, wrapped decoction, decoction time, heat type, and temperature requirements can be extracted from the process entity. Information such as delivery address, delivery method, and medication time period can also be extracted from delivery-related entities. By uniformly extracting and structurally representing the above information, the system can provide basic data for determining incompatibility relationships between subsequent prescriptions to be processed.

[0100] After extracting the key feature information corresponding to each prescription to be processed, the association relationships between medicinal material entities, patient entities, prescription entities, and process entities in the traditional Chinese medicine decoction knowledge graph can be used to perform association reasoning on any two prescriptions to be processed to determine whether there is an incompatible relationship between them. Specifically, the key feature information corresponding to the first and second prescriptions to be processed can be obtained sequentially by combining prescriptions in pairs, and the preset incompatibility rules can be verified item by item.

[0101] In some implementations, if there is an incompatibility relationship between the medicinal materials corresponding to the first and second prescriptions to be processed, then it can be determined that there is an incompatibility relationship between the two prescriptions. For example, if the first prescription to be processed contains Pinellia ternata and the second prescription to be processed contains Aconitum carmichaelii or Aconitum napellus, the risk of cross-prescription compatibility between the two prescriptions can be identified based on the incompatibility relationship edges of medicinal materials pre-established in the knowledge graph, and marked as incompatible.

[0102] In some implementations, if the overall medicinal properties of the first prescription to be processed and the second prescription to be processed conflict significantly, it can be determined that there is a conflict of medicinal properties between the two prescriptions. For example, if the first prescription to be processed is generally cold and purgative, while the second prescription to be processed is generally hot and tonifying, and both need to be taken within a similar time period or processed in the same decoction batch, then a conflict of medicinal properties between the two prescriptions can be determined based on the comparison of medicinal property categories and efficacy tendencies.

[0103] In some implementations, if the population tags or identity relationships of the patients corresponding to the first and second prescriptions trigger preset contraindication rules, the system can determine that there is a population contraindication conflict or a family-based medication conflict between the two prescriptions. For example, if the patient corresponding to the first prescription is a pregnant woman, and the second prescription contains medications contraindicated during pregnancy, and the patients corresponding to the two prescriptions have a family member relationship, the same delivery address, or overlapping medication environments, the system can identify a potential medication confusion risk between the two prescriptions based on the family relationship edge between the patient entities and the contraindication tags of the medication entities, thereby determining that there is an incompatibility relationship.

[0104] In some implementations, if the decoction process requirements corresponding to the first prescription to be processed and the second prescription to be processed conflict with each other, it can be determined that there is a decoction process conflict between the two prescriptions. For example, the first prescription to be processed requires a certain herb to be decocted for 60 minutes first, while the second prescription requires some herbs to be added 5 minutes later or decocted separately. If the differences in the decoction time, heat control, order of adding herbs, or temperature curves between the two exceed a preset threshold, it can be determined that the two prescriptions to be processed cannot be processed together under the same standard decoction process, thereby establishing a process conflict relationship.

[0105] In other implementations, it can also be determined whether there is an antagonistic relationship or an overlapping / conflicting relationship between the first and second prescriptions to be processed. For example, when the core efficacy of the first prescription is to relieve exterior syndromes and dispel cold, and the core efficacy of the second prescription is to astringe the lungs and stop sweating, and both are scheduled to be taken by the same patient, in the same family setting, or at the same time, the risk of antagonistic efficacy between the two can be identified based on the semantic relationship of efficacy and the relationship of medication time in the knowledge graph. As another example, when two prescriptions need to be taken at overlapping times, and the prescriptions contain known interacting herbs or herbs that should be used with caution in special populations, an overlapping / conflicting relationship in medication time can be determined.

[0106] When an incompatibility relationship is determined between any two prescriptions to be processed, an incompatible edge can be established between the graph nodes corresponding to the two prescriptions. The edge weight of the incompatible edge is determined based on the type of incompatibility relationship, risk level, and scenario relevance. The type of incompatibility relationship can be used to differentiate risks from different sources, such as drug incompatibilities, drug property conflicts, decoction process conflicts, population contraindications, and family-based medication conflicts. The risk level reflects the degree of impact of the incompatibility relationship on the safety and correctness of the decoction process. The scenario relevance reflects the probability of the incompatibility relationship occurring in actual business scenarios, such as whether the prescriptions belong to the same household, the same delivery address, the same medication time period, or the same equipment used for processing.

[0107] In some implementations, incompatibilities with higher safety risks can be assigned larger edge weights. For example, incompatibilities arising from conflicts between 18 incompatible herbs, 19 antagonistic herbs, toxic medicinal materials, or medicinal materials contraindicated during pregnancy can be assigned high weights. Incompatibilities with significant process differences but which can be mitigated through special treatments can be assigned medium weights. Potentially risky relationships that may only be triggered under specific family scenarios or overlapping medication times can be assigned low weights. By introducing edge weights, the system can quantify incompatibilities of different types and intensities, providing a basis for conflict resolution and grouping optimization during subsequent isolation and grouping processes.

[0108] After determining the incompatibility relationships and assigning edge weights to all prescriptions to be processed, each prescription to be processed can be treated as a graph node, and the incompatible edges established between the prescriptions to be processed can be treated as graph edges, thus constructing a prescription incompatibility graph. This prescription incompatibility graph reflects the conflict distribution and constraint structure within the set of prescriptions to be processed. It can identify at the graph structure level which prescriptions must be isolated from each other and which prescriptions can be further evaluated and processed jointly, thereby providing a graph structure foundation for subsequently isolating and grouping the set of prescriptions to be processed based on the prescription incompatibility graph and generating prescription group entities.

[0109] Further optionally, in step 103, isolating and grouping the set of prescriptions to be processed according to the prescription incompatibility graph to generate prescription group entities includes: performing graph segmentation on the set of prescriptions to be processed according to the edge weights of each incompatible edge in the prescription incompatibility graph to obtain at least one candidate prescription subset; dividing the prescriptions to be processed corresponding to incompatible edges with edge weights greater than or equal to a strong conflict threshold into different candidate prescription subsets; grouping and merging the prescriptions to be processed with edge weights less than the strong conflict threshold and process compatibility meeting preset conditions according to the principle of minimizing the sum of conflict edge weights; when there are still low conflict edges with weights less than the strong conflict threshold in the candidate prescription subset, resolving conflicts in the candidate prescription subset according to safety priority, timeliness priority, and resource priority to obtain target prescription groups; assigning a unique group identifier to each target prescription group, and establishing the association between the target prescription group and the corresponding patient entity, prescription entity, decoction priority label, and equipment adaptation parameters to generate the prescription group entity.

[0110] Specifically, in this embodiment, after obtaining the prescription incompatibility graph, graph segmentation is performed on the set of prescriptions to be processed based on the edge weights of the incompatible edges in the graph to obtain at least one subset of candidate prescriptions. The goal of the graph segmentation is to isolate prescriptions with strong incompatibilities from each other, while ensuring medication safety and the feasibility of decoction, and to group prescriptions without significant conflicts and capable of joint processing into the same subset of candidate prescriptions as much as possible, thereby balancing the safety of prescription grouping with the efficiency of subsequent equipment utilization.

[0111] In some implementations, the incompatible edges in the prescription incompatibility graph can be traversed first, and incompatible edges with weights greater than or equal to a preset strong conflict threshold can be identified. For such incompatible edges, the corresponding prescriptions to be processed can be forcibly divided into different subsets of candidate prescriptions. The strong conflict threshold can be used to characterize unacceptable high-risk conflict levels, such as conflicts involving the Eighteen Incompatibilities, Nineteen Antagonisms, contraindicated medicinal materials during pregnancy, toxic medicinal material conflicts, or significant process conflicts that cannot be handled by a unified decoction process. In this case, instead of attempting to perform joint grouping on the corresponding prescriptions, hard isolation is directly performed to prevent high-risk prescriptions from entering the same subsequent processing flow.

[0112] After initial isolation of strongly conflicting prescriptions, compatibility analysis can be further performed on prescriptions with edge weights less than the strong conflict threshold. Specifically, the process compatibility between different prescriptions can be calculated by combining the process entity information corresponding to each prescription. The process compatibility can be calculated based on parameters such as decoction time, heat type, temperature requirements, order of adding medicine, requirement of decocting before adding medicine, whether to decoct separately, whether to wrap and decoct, and special processing methods. When the incompatible edge weights between two or more prescriptions are low and the corresponding process compatibility meets the preset conditions, the prescription can be regarded as a candidate for merging, and the grouping and merging can be performed according to the principle of minimizing the sum of conflict edge weights. That is, prescriptions with lower overall conflict levels and smaller differences in process execution are preferentially grouped into the same subset of candidate prescriptions to reduce the number of subsequent groups and improve the joint processing capability.

[0113] In some implementations, the graph segmentation process can be achieved through iterative optimization. First, the set of prescriptions to be processed is initially segmented based on strongly conflicting edges to form several candidate prescription subsets. Then, the sum of the weights of conflicting edges within each candidate prescription subset and the process compatibility between prescriptions are calculated. Next, the candidate prescription subsets are gradually optimized by moving nodes, exchanging nodes, or splitting subsets, so that the degree of conflict within each candidate prescription subset is continuously reduced and the process compatibility within each candidate prescription subset is continuously improved. When the sum of the weights of conflicting edges no longer decreases significantly or the process compatibility reaches a preset requirement, the current grouping result is determined as the candidate grouping result.

[0114] When low-conflict edges with edge weights less than the strong conflict threshold still exist in the candidate prescription subset, the candidate prescription subset can be further conflict-resolved according to safety priority, timeliness priority, and resource priority to obtain the target prescription group. Specifically, the safety priority can be used to prioritize the safety of prescriptions containing toxic, expensive, pregnancy-contraindicated, or high-risk interacting drugs. When such prescriptions exist in the candidate prescription subset, they can be prioritized to be grouped independently or assigned to a lower-risk target prescription group. The timeliness priority can be used to prioritize the processing efficiency of emergency prescriptions, expedited prescriptions, prescriptions with short appointment times, or prescriptions with urgent delivery times. When low-conflict edges involve prescriptions with high timeliness requirements, their grouping range can be narrowed or they can be grouped separately. The resource priority can be used to improve the comprehensive utilization rate of decoction equipment, printing terminals, and dispensing resources while meeting safety and timeliness constraints. Prescription combinations with high process compatibility and low equipment switching costs can be prioritized, and the remaining prescriptions can be dynamically split or redistributed.

[0115] In some implementations, if a subset of candidate prescriptions is found to have low-conflict edges, but the corresponding conflicts can be mitigated through device adaptation capabilities, the grouping results can be further optimized by combining device adaptation parameters. For example, for prescriptions with slight differences in decoction processes that can be coordinated through segmented temperature control, staged drug addition, independent post-addition, or additional processing channels, these prescriptions can be retained in the same target prescription group when it is confirmed that the target decoction equipment has the corresponding execution capabilities. Corresponding device adaptation parameters can then be generated for subsequent decoction control command generation and equipment scheduling.

[0116] After conflict resolution, the processing results can be identified as target prescription groups, and each target prescription group can be assigned a unique group identifier. Subsequently, the association between the target prescription group and its corresponding patient entity, prescription entity, decoction priority label, and equipment adaptation parameters can be established to generate the prescription group entity. The patient entity and prescription entity represent the business scope of the target prescription group. The decoction priority label represents the priority processing order of the target prescription group in subsequent numbering, task generation, and equipment scheduling. The equipment adaptation parameters represent the equipment type, decoction parameters, label output requirements, and special execution strategies that match the target prescription group.

[0117] For example, in a specific application scenario, after constructing a prescription incompatibility graph for multiple prescriptions to be processed, if a high-weighted incompatibility conflict edge is detected between two prescriptions, these two prescriptions are forcibly assigned to different candidate prescription subsets. For several other prescriptions with similar processes, low conflict edge weights, and that meet the conditions for joint decoction, they can be merged into the same candidate prescription subset. If a low-conflict edge still exists in this candidate prescription subset, and one of the prescriptions is relevant to an emergency scenario, then this emergency prescription can be grouped separately according to its timeliness priority, ultimately resulting in multiple target prescription groups. Each of these target prescription groups is then assigned a unique group identifier and associated with corresponding patient entities, prescription entities, decoction priority tags, and equipment adaptation parameters to generate prescription group entities for subsequent use in assigning medication collection numbers, generating decoction tasks, and scheduling equipment.

[0118] The above method enables the isolation and grouping of prescription sets to be processed based on the prescription incompatibility graph, taking into account safety, timeliness and resource utilization. This reduces the risks of prescription mixing, decoction process conflicts and medication safety, while improving the rationality of prescription grouping and the efficiency of subsequent decoction processes.

[0119] Step 104: Establish a drug collection sequence number lease node for the prescription group entity. When the drug collection sequence number lease node meets the validity conditions, assign a target drug collection sequence number to the prescription group entity and establish the association between the target drug collection sequence number, the decoction task, and the decoction device.

[0120] In this embodiment, the medication dispensing number lease node can be understood as a graph node in the knowledge graph used to temporarily represent the allocation and occupancy status of a candidate medication dispensing number in the current business scenario. The medication dispensing number lease node is not equivalent to the final effective medication dispensing number itself, but rather an intermediate control node used to constrain and manage the application, occupancy, timeout, and confirmation process of the candidate medication dispensing number before its formal confirmation. By introducing the medication dispensing number lease node, the system can perform orderly allocation and conflict control of medication dispensing number resources in scenarios involving concurrent applications from multiple terminals, parallel processing of multiple prescription groups, or collaborative execution by multiple devices.

[0121] The target medication collection number can be understood as an official identification number selected from the set of candidate medication collection numbers, meeting preset validity conditions, and ultimately assigned to the target prescription group entity. The target medication collection number can be used to identify the decoction service object corresponding to the current prescription group, and can be further used in subsequent processing steps such as medication collection voucher generation, prescription label generation, decoction label generation, task tracking, and patient medication collection verification.

[0122] The relationship between the target medication pickup number, the decoction task, and the decoction device can be understood as a semantic connection between different business objects in a knowledge graph. In step 104, the relationship can include at least the allocation relationship between the target medication pickup number and the prescription group entity, the task binding relationship between the target medication pickup number and the decoction task entity, and the device execution relationship between the target medication pickup number and the decoction device entity. By establishing the above relationships, the number allocation result can be uniformly bound to the subsequent task execution object and device execution object, so that subsequent tag push, task scheduling, and device control can revolve around the same target medication pickup number.

[0123] As an optional embodiment, in step 104, establishing a medication collection number lease node for the prescription group entity, and allocating a target medication collection number to the prescription group entity when the medication collection number lease node meets the validity condition, includes: generating a candidate medication collection number set based on the hospital identifier, business date, prescription group type, device identifier, and historical medication collection number allocation records corresponding to the prescription group entity; establishing a corresponding medication collection number lease node for each candidate medication collection number in the traditional Chinese medicine decoction knowledge graph, wherein the medication collection number lease node includes a serial number identifier, an application terminal identifier, an application time, and an expiration date. One or more of the following: time, occupancy status, and confirmation status; based on the association between the drug retrieval number lease node and the prescription group entity, the decoction task entity, and the decoction equipment entity, determine whether each candidate drug retrieval number meets the validity conditions; determine the target drug retrieval number from the candidate drug retrieval numbers that meet the validity conditions, and establish an association between the target drug retrieval number and the prescription group entity, the decoction task entity, and the decoction equipment entity; update the drug retrieval number lease node corresponding to the target drug retrieval number to the occupied status, and update the drug retrieval number lease node to the confirmed status after receiving confirmation feedback.

[0124] The validity conditions include at least one of the following: the corresponding medication collection number is not occupied, the corresponding lease node has not expired, the corresponding decoction equipment is available, and the corresponding prescription group entity is not associated with other confirmed medication collection numbers.

[0125] Specifically, in this embodiment, a candidate set of dispensing serial numbers can first be generated based on the hospital identifier, business date, prescription group type, device identifier, and historical dispensing serial number allocation record corresponding to the prescription group entity. The hospital identifier can be used to distinguish different medical institutions, pharmacies, or business areas. The business date can be used to distinguish the scope of serial number usage under different dates. The prescription group type can be used to distinguish different business types such as outpatient decoction, inpatient decoction, expedited decoction, or special medicinal material processing; the device identifier can be used to identify the printing terminal, decoction equipment, or workstation that is preferentially matched to the current prescription group. The historical dispensing serial number allocation record can be used to avoid generating duplicate numbers that have already been used or confirmed. Based on the above parameters, multiple candidate dispensing serial numbers can be generated according to preset numbering rules for subsequent screening.

[0126] After generating a set of candidate drug dispensing serial numbers, a corresponding drug dispensing serial number lease node can be established in the traditional Chinese medicine decoction knowledge graph for each candidate drug dispensing serial number. The drug dispensing serial number lease node can include at least one or more of the following: serial number identifier, application terminal identifier, application time, expiration time, occupancy status, and confirmation status. The serial number identifier represents the candidate drug dispensing serial number corresponding to the lease node. The application terminal identifier represents the terminal or workstation that initiated the application for the candidate drug dispensing serial number. The application time and expiration time limit the effective occupancy time window of the candidate drug dispensing serial number in the current application process. The occupancy status indicates whether the candidate drug dispensing serial number is currently temporarily occupied by a prescription group entity. The confirmation status indicates whether the candidate drug dispensing serial number has been formally confirmed and transformed into a final effective target drug dispensing serial number.

[0127] In some implementations, the validity of each candidate medication retrieval number can be determined based on the association between the medication retrieval number lease node and the prescription group entity, the decoction task entity, and the decoction equipment entity. Specifically, it can be first determined whether the lease node corresponding to the candidate medication retrieval number is in an unoccupied state to exclude candidate medication retrieval numbers that have been occupied by other prescription group entities; then it can be determined whether the corresponding lease node has expired to exclude invalid candidate medication retrieval numbers whose applications have expired but have not been confirmed; next, it can be determined whether the decoction equipment entity associated with the candidate medication retrieval number is currently in an available state to exclude candidate medication retrieval numbers that are offline, faulty, have task congestion, or do not support the current prescription group type; finally, it can be determined whether the current prescription group entity has been associated with other confirmed medication retrieval numbers to avoid the same prescription group being repeatedly assigned multiple official numbers. Through the above determinations, candidate medication retrieval numbers that meet the validity conditions can be filtered from the candidate medication retrieval number set.

[0128] In some implementations, for multiple candidate dispensing numbers that meet the validity criteria, a target dispensing number can be further determined according to a preset priority strategy. For example, candidate dispensing numbers with better sequential numbering can be prioritized to improve the convenience of window calling and patient identification; candidate dispensing numbers that better match the current device queue, task batch, or tag output order can also be prioritized to improve subsequent execution efficiency; or the target dispensing number most suitable for the current prescription group entity can be determined by combining historical business habits, hospital numbering rules, or number segment allocation rules of different terminals.

[0129] After determining the target dispensing number from the candidate dispensing numbers that meet the validity criteria, the target dispensing number can be associated with the prescription group entity, the decoction task entity, and the decoction equipment entity. Specifically, a relationship of "prescription group entity - allocation - target dispensing number" can be established to represent the official dispensing number corresponding to the prescription group entity; a relationship of "target dispensing number - binding - decoction task entity" can be established to represent the subsequent task flow of dispensing, decoction, and delivery driven by the target dispensing number; and a relationship of "target dispensing number - association - decoction equipment entity" can be established to represent the equipment object corresponding to the target dispensing number in the subsequent tag output, task issuance, and equipment execution processes. Through the above relationship binding, all subsequent task processing around the number can be built on the same graph main line.

[0130] After establishing the aforementioned association, the lease node corresponding to the target medication pickup number can be updated to an occupied state, and upon receiving confirmation feedback, the lease node can be updated to a confirmed state. The confirmation feedback can include at least one of the following: successful tag generation feedback, successful medication pickup voucher output feedback, business terminal confirmation feedback, or manual confirmation feedback. Once the lease node is updated to a confirmed state, it indicates that the target medication pickup number has officially taken effect and can no longer be repeatedly occupied or reallocated by other prescription group entities. If no confirmation feedback is received within a preset time window, the lease node can be reset to a reclaimable state, or the corresponding candidate medication pickup number can be added back to the candidate medication pickup number set for reallocation.

[0131] For example, in a specific application scenario, a set of candidate medication collection numbers A001, A002, and A003 is generated for a certain prescription group entity, and corresponding medication collection number lease nodes are established for each. It is detected that the lease node corresponding to A001 is already occupied by another prescription group entity; the lease node corresponding to A002 is not occupied, but its associated printing device is offline; while the lease node corresponding to A003 is not occupied, has not expired, and its associated device is available. Furthermore, the current prescription group entity is not associated with any other confirmed medication collection numbers. Therefore, the system can identify A003 as the target medication collection number and establish an association between it and the current prescription group entity, the decoction task entity, and the target decoction device entity. Subsequently, after the medication collection voucher and label are successfully generated and confirmation feedback is received, the lease node corresponding to A003 is updated from occupied to confirmed.

[0132] Optionally, in step 104, the association between the target medication dispensing number, the decoction task, and the decoction device is established. Specifically, a candidate medication dispensing number set can first be generated based on the hospital identifier, business date, prescription group type, device identifier, and historical medication dispensing number allocation records corresponding to the prescription group entity, and a corresponding medication dispensing number lease node can be established for each candidate medication dispensing number. Subsequently, based on the association between the medication dispensing number lease node and the prescription group entity, the decoction task entity, and the decoction device entity, it is determined whether each candidate medication dispensing number meets the validity conditions. Then, the target medication dispensing number is determined from the candidate medication dispensing numbers that meet the validity conditions, and an association is established between the target medication dispensing number and the prescription group entity, the decoction task entity, and the decoction device entity. Finally, the medication dispensing number lease node corresponding to the target medication dispensing number is updated to an occupied state, and updated to a confirmed state after receiving confirmation feedback.

[0133] Furthermore, a corresponding decoction task entity can be generated based on the target medicine collection serial number, and a target decoction device entity can be matched with the decoction task entity, thereby establishing a unified association between the target medicine collection serial number, the decoction task, and the decoction device.

[0134] Step 105: Generate a decoction control instruction corresponding to the prescription group entity based on the association relationship, and push the medication voucher, prescription label and decoction label corresponding to the decoction control instruction to the corresponding user terminal and / or decoction device.

[0135] Specifically, in step 105, a decoction control instruction corresponding to the prescription group entity is generated based on the aforementioned association. This decoction control instruction can be understood as structured control data used to drive subsequent label generation, voucher output, task issuance, and equipment execution. It may include at least one or more of the following: prescription group identifier, target medication dispensing number, patient identifier, prescription details, decoction task type, decoction equipment identifier, label type, output terminal identifier, priority information, and process execution parameters. By generating this decoction control instruction, the association results between prescription group entities, target medication dispensing numbers, task entities, and equipment entities in the knowledge graph can be converted into control information that can be directly executed by terminal devices and decoction equipment.

[0136] In some implementations, different types of decoction control instructions can be generated based on the business attributes and task attributes corresponding to the prescription group entity. For example, when the current processing stage corresponds to the output of medication information, a medication voucher control instruction can be generated to drive the printing terminal or user terminal to output the medication voucher. When the current processing stage corresponds to the generation of a label, prescription label control instructions and decoction label control instructions can be generated to drive the label printing terminal, dispensing terminal, or decoction equipment to output the corresponding label. When the current processing stage corresponds to the execution of decoction, a task execution control instruction containing the decoction sequence, process parameters, equipment target, and task identifier can also be generated to drive the corresponding decoction equipment into a preset processing state.

[0137] In some implementations, the medication pickup voucher may include at least one or more of the following: target medication pickup number, patient name, prescription group identifier, number of prescription doses, medication pickup prompt information, window information, generation time, and verification identifier. The prescription label may include at least one or more of the following: prescription number, patient identifier, medicinal material summary information, decoction requirements, label type, and corresponding QR code information. The decoction label may include at least one or more of the following: target medication pickup number, prescription group identifier, decoction task identifier, decoction process requirements, equipment identifier, priority label, and verification code. The field content and display format of the medication pickup voucher, prescription label, and decoction label can be adapted to the usage scenarios of different output objects.

[0138] In some implementations, the push target can be determined based on the aforementioned association. Specifically, if the medication pickup voucher is used for patient medication pickup prompts or window queuing, the corresponding medication pickup voucher can be pushed to the user terminal, queuing terminal, window display terminal, or receipt printing terminal. If the prescription label is used for medication identification, prescription verification, or packaging material identification, the corresponding prescription label can be pushed to the dispensing terminal, label printing terminal, or management terminal. If the decoction label is used for equipment identification, decoction execution, or task tracking, the corresponding decoction label can be pushed to the decoction equipment, decoction control terminal, or printing module connected to the decoction equipment. By targeting different label objects and different terminal objects, it can be ensured that subsequent business nodes receive control information that matches their task responsibilities.

[0139] In some implementations, after generating the decoction control command, the command can be encoded and encapsulated to form an output message suitable for different terminal or device protocols. For example, according to the communication protocol and data format requirements of the user terminal, printing terminal, label printer, or decoction equipment, the decoction control command can be sorted by fields, converted in format, have a checksum appended, and encapsulated for transmission. Then, it can be sent to the corresponding user terminal and / or decoction equipment through interface calls, message queue push, network transmission, or serial communication.

[0140] In some implementations, when the corresponding user terminal and / or decoction equipment receives the decoction control command, it can generate and output the corresponding medication collection voucher, prescription label, and decoction label according to the command. For example, a printing terminal can output a paper medication collection voucher based on the target medication collection number, patient name, and verification identifier in the control command. A label printing terminal can output a prescription label based on the prescription details, label type, and QR code information in the control command. The decoction equipment or its supporting terminal can generate a decoction label based on the decoction task identifier, process parameters, and equipment identifier in the control command, and prepare for subsequent decoction tasks.

[0141] In some implementations, to ensure the consistency between the decoction control command and the associations in the knowledge graph, a consistency check can be performed on the control command before pushing it. The consistency check may include: verifying whether the target medication dispensing sequence number uniquely corresponds to the current prescription group entity, verifying whether the associated decoction task entity is in a sendable state, verifying whether the associated decoction device entity is in a receiveable state, and verifying whether the current tag content is consistent with the latest data in the prescription group entity and the task entity. If the consistency check passes, the push is executed. If the consistency check fails, the control command can be regenerated, the target device switched, or an error message process triggered.

[0142] For example, in a specific application scenario, after assigning a target medication collection number to a prescription group entity, a medication collection voucher control instruction containing the patient's name, medication collection number, prescription group identifier, and QR code identifier can be generated based on the association between the target medication collection number and the decoction task entity and decoction equipment entity, and then pushed to the window printing terminal. Simultaneously, a prescription label control instruction containing the prescription number, herbal medicine summary, decoction requirements, and label identifier is generated and pushed to the label printing terminal. Further, a decoction label control instruction containing the target medication collection number, decoction task identifier, decoction parameters, and equipment identifier is generated and pushed to the corresponding decoction equipment. Subsequently, the window printing terminal, label printing terminal, and decoction equipment output the corresponding medication collection voucher, prescription label, and decoction label respectively based on the received control instructions to support subsequent patient medication collection, dispensing verification, and decoction execution.

[0143] The above methods can transform the relationships between target medicine collection numbers, decoction tasks, and decoction equipment established in the knowledge graph into decoction control instructions for specific terminals and equipment, and drive the generation and push of medicine collection vouchers, prescription labels, and decoction labels, thereby achieving unified coordination between information output, task issuance, and equipment execution in the traditional Chinese medicine decoction service process.

[0144] Specifically, after establishing the association between the target medication pickup number, the decoction task, and the decoction device, a decoction control instruction corresponding to the prescription group entity can be generated based on the association. The decoction control instruction includes at least one or more of the following: prescription group identifier, target medication pickup number, task identifier, device identifier, and tag output information. Subsequently, the push target is determined according to different output objects, and the medication pickup voucher, prescription tag, and decoction tag corresponding to the decoction control instruction are pushed to the corresponding user terminal and / or decoction device, respectively, to drive subsequent medication pickup prompts, prescription verification, and decoction task execution.

[0145] As an optional embodiment, after pushing the dispensing voucher, prescription label, and decoction label corresponding to the decoction control command to the corresponding decoction device in step 105, the method further includes: obtaining the device execution feedback data corresponding to the decoction control command, and writing the device execution feedback data into the traditional Chinese medicine decoction knowledge graph to update the event nodes, device nodes, and status nodes associated with the current processing object; performing a state transition determination on the current processing object based on the updated association node relationship, and migrating the current processing object from the current status node to the corresponding next status node when the determination meets the preset transition conditions; generating an abnormal entity associated with the current processing object when an execution anomaly, state conflict, or label mismatch is detected, and establishing the association relationship between the abnormal entity and the corresponding event node, device node, and status node; performing anomaly localization based on the relationship between the abnormal entity and the associated nodes to output the anomaly type, anomaly source, and anomaly propagation path.

[0146] The device execution feedback data includes at least one or more of the following: tag output result, voucher output result, decoction task start result, decoction task completion result, QR code confirmation result, or terminal confirmation result.

[0147] Specifically, in this embodiment, after the medication receipt, prescription label, and decoction label corresponding to the decoction control command are pushed to the corresponding decoction equipment, the device execution feedback data corresponding to the decoction control command can be obtained through at least one of the following: label printing terminal, medication receipt output terminal, barcode scanning terminal, decoction equipment, dispensing terminal, management terminal, or user terminal. The device execution feedback data is used to characterize the execution status, execution result, and abnormal information of the decoction control command during actual execution, and may include at least one or more of the following: label output result, receipt output result, decoction task start result, decoction task completion result, barcode confirmation result, or terminal confirmation result. For example, a label output result can be generated when the printing terminal successfully outputs the prescription label or decoction label. A receipt output result can be generated when the medication receipt is printed. A decoction task start result can be generated when the decoction equipment starts executing the corresponding decoction task. A decoction task completion result can be generated when the decoction equipment completes the preset decoction process. A barcode confirmation result can be generated when staff or patients scan and verify the label, receipt, or medicine package using a barcode scanning terminal. When staff perform task confirmation, status confirmation, or manual review through the business terminal, a terminal confirmation result can be generated. The feedback data from various devices may also include one or more of the following: feedback object identifier, feedback time, device identifier, operator identifier, feedback status, exception code, and remarks.

[0148] After obtaining the device execution feedback data, it can be written into the traditional Chinese medicine decoction knowledge graph to update the event nodes, device nodes, and status nodes associated with the currently processed object. The currently processed object can be a prescription group entity, a dispensing sequence number entity, a decoction task entity, or other objects corresponding to the current business node. Specifically, based on the data type of feedback, corresponding event nodes can be added or updated in the knowledge graph, such as tag output event nodes, voucher output event nodes, decoction start event nodes, decoction completion event nodes, QR code confirmation event nodes, or terminal confirmation event nodes. Simultaneously, the current status, most recent feedback time, execution result, availability flag, and anomaly flag of the corresponding device node are updated. Furthermore, the status nodes associated with the currently processed object are updated to keep the object status, device status, and event chain in the knowledge graph synchronized with the actual business execution. By continuously writing the device execution feedback data back to the knowledge graph, a dynamic business closed loop around the currently processed object can be formed, providing real-time basis for subsequent state transition judgment and anomaly analysis.

[0149] In some implementations, a state transition determination can be performed on the currently processed object based on the updated associated node relationships. When a preset transition condition is met, the currently processed object is transitioned from the current state node to the corresponding next state node. The preset transition condition may include at least one or more of the following: a preceding event node corresponding to the currently processed object has been generated; an associated device node returns a successful feedback; a legitimate transition path exists between the current state node and the target state node; and no abnormal entity blocks the transition. For example, when a label output result is detected as successful and the scan confirmation result is passed, the current processed object can be determined to meet the condition for transitioning from the "pending printing" state to the "printed" state. When a decoction task initiation result is detected as successful, the current processed object can be determined to meet the condition for transitioning from the "pending decoction" state to the "decoction in progress" state. When a decoction task completion result is detected as successful and the terminal verification result is passed, the current processed object can be determined to meet the condition for transitioning from the "decoction in progress" state to the "pending delivery" or "completed" state.

[0150] Furthermore, a state transition rule table or state machine model can be maintained in advance, and the legality of the transition can be verified based on the relationship between event nodes, device nodes, and state nodes, thereby avoiding state transition errors caused by misjudgment due to a single feedback.

[0151] When execution anomalies, state conflicts, or label mismatches are detected during feedback writing and state transition determination, an anomaly entity associated with the currently processed object can be generated, and the association between the anomaly entity and the corresponding event node, device node, and state node can be established. Execution anomalies can include printing failure, output timeout, device offline, device malfunction, decoction task startup failure, decoction task interruption, barcode scanning failure, or terminal confirmation failure. State conflicts can include inconsistencies between the current state and the feedback event, multiple mutually exclusive states corresponding to the same object simultaneously, and state transition order not conforming to preset process rules. Label mismatches can include inconsistencies between the prescription label and the target medication dispensing number, inconsistencies between the decoction label and the task identifier, and inconsistencies between the medication dispensing voucher and the patient identifier. An "triggered by..." relationship can be established between the anomaly entity and the event node that triggered the anomaly, an "occurred on..." relationship can be established with the device node where the anomaly occurred, and an "blocked..." state transition or "conflicted with..." state relationship can be established with the affected state node, thereby forming a complete anomaly context chain.

[0152] In some implementations, anomaly localization can also be performed based on the relationship between the abnormal entity and associated nodes to output the anomaly type, source, and propagation path. Specifically, starting from the abnormal entity, backtracking can be performed along event relationships, device relationships, and state relationships in the knowledge graph to identify the initiating event that triggered the anomaly, the corresponding device, the upstream task object, and the affected state node. For example, when a scan confirmation failure is detected for a decoction label, backtracking can be performed along the relationship path of "scan confirmation event node - label output event node - target dispensing sequence number entity - prescription group entity" to determine whether the anomaly is caused by an error in the label content, an error in the label push object, or an error in the scanning device. When a state conflict of an object is detected, analysis can also be performed along the state transition chain and the most recent event chain to determine whether it is caused by a missing preceding event, a device feedback delay, or an error in the manual confirmation sequence. Finally, the anomaly type, source, and propagation path can be output, and the anomaly localization results can be provided to the management terminal or relevant business terminals to facilitate timely intervention and correction by staff.

[0153] This embodiment enables closed-loop control of the entire decoction service process after the decoction control command is executed, including feedback writing, status progression, anomaly modeling, and anomaly tracing, thereby improving the transparency, accuracy, and traceability of the traditional Chinese medicine decoction service process.

[0154] Figure 5 The main interface shown is the decoction task details management interface. This interface can be used to display detailed information for each decoction task or prescription record, such as patient information, order status, prescription number, doctor information, diagnosis information, and corresponding operation buttons. Staff can perform operations such as packing, placing in baskets, printing, and viewing details on this interface, or process prescription tasks. Figure 5 This illustrates an implementation method for unified management of prescriptions, tasks, labels, and processing status in the embodiments of this application, and can also be used to illustrate the tracking and operation management of task details in the decoction process.

[0155] Figure 6 The main interface shown is the batch management interface for decoction processing. This interface displays the batch number, batch generation time, completion status, decoction status, and corresponding operation entry points for multiple decoction processing batches. Staff can view, filter, and process batch tasks using this interface. Figure 6 This illustrates the implementation of batch scheduling and batch management based on prescription group entities and task entities in the embodiments of this application. It can also be used to illustrate the batch processing effect after unified management of prescription groups, drug dispensing serial numbers, tasks and equipment relationships through knowledge graphs.

[0156] In this embodiment, by collecting multi-source business events related to the traditional Chinese medicine (TCM) decoction service and constructing a TCM decoction knowledge graph, patients, prescriptions, prescription groups, medication collection numbers, decoction tasks, and decoction equipment are uniformly associated and modeled. Furthermore, by identifying the current processing object to retrieve the target patient entity and the set of prescriptions to be processed, isolating and grouping prescriptions based on incompatible relationships, establishing medication collection number lease nodes for prescription group entities and assigning target medication collection numbers, and generating corresponding decoction control instructions based on the aforementioned associations and pushing medication collection vouchers, prescription tags, and decoction tags, collaborative processing of patient identification, prescription grouping, number allocation, and task issuance in the TCM decoction process can be achieved. This results in a decoction service with clear object relationships, accurate task associations, and an automatically advancing process, thereby reducing the risk of business errors caused by incorrect patient identity matching, mixed prescription groups, and duplicate medication collection numbers. It also reduces the operational burden of manual verification, manual numbering, and manual task issuance, improving the processing efficiency, execution accuracy, and process standardization of the TCM decoction service.

[0157] The above describes a knowledge graph-based intelligent management method for traditional Chinese medicine decoction services. The following describes the knowledge graph-based intelligent management system for traditional Chinese medicine decoction services that implements the above method.

[0158] See Figure 7 ,like Figure 7 The diagram shows a structural schematic of a knowledge graph-based intelligent management system for traditional Chinese medicine decoction services. The knowledge graph-based intelligent management system for traditional Chinese medicine decoction services in this embodiment can achieve the above-mentioned... Figure 2 The steps of the knowledge graph-based intelligent management method for traditional Chinese medicine decoction services are executed in the corresponding embodiments. The functions implemented by the knowledge graph-based intelligent management system for traditional Chinese medicine decoction services can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, and the modules can be software and / or hardware. The knowledge graph-based intelligent management system for traditional Chinese medicine decoction services may include an input / output module 701 and a processing module 702. The functional implementation of the processing module 702 and the input / output module 701 can be found in [reference needed]. Figure 2 The operations performed in the corresponding embodiments will not be described in detail here. For example, the processing module 702 can be used to control the sending, receiving, and acquiring operations of the input / output module 701.

[0159] The input / output module 701 is configured to collect multi-source business events related to the traditional Chinese medicine decoction service and construct a knowledge graph of traditional Chinese medicine decoction. The processing module 702 is configured to identify the current processing object and, based on the identification result, retrieve the target patient entity in the traditional Chinese medicine decoction knowledge graph to obtain the set of prescriptions to be processed associated with the target patient entity; based on the incompatibility relationship between the prescriptions to be processed, isolate and group the set of prescriptions to be processed to generate prescription group entities; establish a dispensing sequence number lease node for the prescription group entity; when the dispensing sequence number lease node meets the validity condition, assign a target dispensing sequence number to the prescription group entity and establish an association relationship between the target dispensing sequence number, the decoction task, and the decoction device; and generate a decoction control instruction corresponding to the prescription group entity based on the association relationship. The input / output module 701 is also configured to push the medication voucher, prescription label and decoction label corresponding to the decoction control command to the corresponding user terminal and / or decoction device.

[0160] In this embodiment, by unifying the management of multi-source business objects and their processing constraints in the traditional Chinese medicine decoction service, the automation level and collaborative processing capability of the decoction process can be improved. Since this embodiment can achieve correlation analysis and control of business object relationships, task execution status, and device processing relationships based on knowledge graphs, the knowledge graph-based intelligent management system for traditional Chinese medicine decoction services obtained in this embodiment can achieve ideal process control and intelligent collaboration effects, effectively improving the processing efficiency, execution accuracy, business standardization, and medication safety of the traditional Chinese medicine decoction service.

[0161] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0162] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0163] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.

[0164] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0165] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0166] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0167] The computer program product includes one or more computer instructions. When the computer program is loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0168] The technical solutions provided in the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.

Claims

1. A knowledge graph-based intelligent management method for traditional Chinese medicine decoction services, characterized in that, The method includes: Collect multi-source business events related to traditional Chinese medicine decoction services and construct a knowledge graph of traditional Chinese medicine decoction services; The current processing object is identified, and the target patient entity is retrieved in the Chinese herbal medicine decoction knowledge graph based on the identification result to obtain the set of prescriptions to be processed associated with the target patient entity. Based on the incompatibility between the prescriptions to be processed, the set of prescriptions to be processed is isolated and grouped to generate prescription group entities; A medication collection sequence number lease node is established for the prescription group entity. When the medication collection sequence number lease node meets the validity condition, a target medication collection sequence number is assigned to the prescription group entity, and the association relationship between the target medication collection sequence number, the decoction task, and the decoction equipment is established. Based on the association, a decoction control instruction corresponding to the prescription group entity is generated, and the medication voucher, prescription label, and decoction label corresponding to the decoction control instruction are pushed to the corresponding user terminal and / or decoction device.

2. The intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs according to claim 1, characterized in that, The collection of multi-source business events related to traditional Chinese medicine decoction services will be used to construct a knowledge graph for traditional Chinese medicine decoction services, including: Collect multi-source business events related to traditional Chinese medicine decoction services; The multi-source business events are mapped to fields, unified with timestamps, normalized with event types, filtered for outliers, and eliminated for duplicate events to generate a standardized event stream. Based on the standardized event flow, extract patient entities, prescription entities, prescription group entities, medication dispensing sequence number entities, batch entities, task entities, equipment entities, status entities, and abnormal entities, establish the association relationships between each entity, and construct the knowledge graph of traditional Chinese medicine decoction.

3. The intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs according to claim 1, characterized in that, The step of identifying the current processing object and retrieving the target patient entity from the traditional Chinese medicine decoction knowledge graph based on the identification result to obtain the set of prescriptions to be processed associated with the target patient entity includes: Collect the identity recognition data corresponding to the currently processed object. The identity recognition data includes at least one of the following: social security card information, health card information, ID card information, electronic medical insurance voucher information, or manually entered identity information. Based on the identity recognition data, the corresponding identity credential entity is matched in the knowledge graph of traditional Chinese medicine decoction services; Based on the identity credential entity, retrieve the associated target patient entity and retrieve the set of candidate prescriptions associated with the target patient entity; The candidate prescription set is subjected to validity screening to obtain the prescription set to be processed.

4. The intelligent management method for traditional Chinese medicine decoction service based on knowledge graph as described in claim 3, characterized in that, The step of retrieving the target patient entity associated with the identity credential entity and retrieving the candidate prescription set associated with the target patient entity includes: Based on the identity credential entity, the associated set of candidate patient entities is retrieved in the knowledge graph of traditional Chinese medicine decoction, and the historical prescription information, prescription time information and consultation time information corresponding to each candidate patient entity are extracted. Based on the historical prescription information, prescription time information, and consultation time information corresponding to each candidate patient entity, a triplet relationship chain containing patient, prescription, and time is constructed. Then, a temporal association analysis is performed on the historical medication behavior pattern of each candidate patient entity using a temporal knowledge graph reasoning model to obtain the behavior matching degree corresponding to each candidate patient entity. TCM constitution tags are extracted from the historical prescriptions associated with each candidate patient entity. Based on the composition, properties and / or efficacy information of the medicinal materials in the prescription corresponding to the current processing object, the semantic similarity of the constitution tags between the current processing object and each candidate patient entity is calculated to obtain the constitution matching degree corresponding to each candidate patient entity. Based on the behavioral matching degree and the physical condition matching degree, the target patient entity corresponding to the current processing object is determined; Based on the association between the target patient entity and the prescription entity, a set of candidate prescriptions associated with the target patient entity is retrieved.

5. The intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs according to claim 1, characterized in that, The step of isolating and grouping the set of prescriptions to be processed based on the incompatibility relationships between them to generate prescription group entities includes: Construct a prescription incompatibility graph based on the incompatibility relationships between the prescriptions to be processed; The prescription set to be processed is isolated and grouped according to the prescription incompatibility graph to generate prescription group entities.

6. The intelligent management method for traditional Chinese medicine decoction service based on knowledge graph as described in claim 5, characterized in that, The construction of a prescription incompatibility graph based on the incompatibility relationships between prescriptions to be processed includes: Extract key feature information corresponding to each prescription to be processed; Based on the association relationships between the medicinal material entities, patient entities, prescription entities, and process entities in the knowledge graph of traditional Chinese medicine decoction, association reasoning is performed on any two prescriptions to be processed to determine whether there is an incompatible relationship between any two prescriptions to be processed. When there is an incompatible relationship between any two prescriptions to be processed, an incompatible edge is established between the graph nodes corresponding to the two prescriptions to be processed, and the edge weight of the incompatible edge is determined according to the type of incompatible relationship, risk level and scenario correlation. Using each prescription to be processed as a graph node and the incompatible edges as graph edges, a prescription incompatibility graph is constructed.

7. The intelligent management method for traditional Chinese medicine decoction service based on knowledge graph as described in claim 5, characterized in that, The step of isolating and grouping the set of prescriptions to be processed according to the prescription incompatibility graph to generate prescription group entities includes: Based on the edge weights of each incompatible edge in the prescription incompatibility graph, graph segmentation is performed on the prescription set to be processed to obtain at least one candidate prescription subset. The prescriptions to be processed corresponding to incompatible edges whose edge weights are greater than or equal to the strong conflict threshold are divided into different subsets of candidate prescriptions. For prescriptions to be processed that have edge weights less than the strong conflict threshold and whose process compatibility meets the preset conditions, they are grouped and merged according to the principle of minimizing the sum of conflict edge weights. When there are still low-conflict edges with weights less than the strong conflict threshold in the candidate prescription subset, conflict resolution is performed on the candidate prescription subset according to security priority, timeliness priority and resource priority to obtain the target prescription group; A unique group identifier is assigned to each target prescription group, and the association between the target prescription group and the corresponding patient entity, prescription entity, decoction priority label and device adaptation parameters is established to generate the prescription group entity.

8. The intelligent management method for traditional Chinese medicine decoction service based on knowledge graph as described in claim 1, characterized in that, The step of establishing a medication collection sequence number lease node for the prescription group entity, and assigning a target medication collection sequence number to the prescription group entity when the medication collection sequence number lease node meets the validity condition, includes: Based on the hospital identifier, business date, prescription group type, device identifier, and historical medication collection number allocation record corresponding to the prescription group entity, a candidate medication collection number set is generated; For each candidate medicine collection number, a corresponding medicine collection number lease node is established in the knowledge graph of traditional Chinese medicine decoction. The medicine collection number lease node includes one or more of the following: serial number identifier, application terminal identifier, application time, expiration time, occupancy status, and confirmation status. Based on the association between the drug dispensing sequence number lease node and the prescription group entity, the decoction task entity, and the decoction equipment entity, it is determined whether each candidate drug dispensing sequence number meets the validity conditions. Determine the target drug collection number from the candidate drug collection numbers that meet the validity conditions, and establish an association relationship between the target drug collection number and the prescription group entity, the decoction task entity, and the decoction equipment entity. The medication collection sequence number lease node corresponding to the target medication collection sequence number is updated to an occupied state, and after receiving confirmation feedback, the medication collection sequence number lease node is updated to a confirmed state.

9. The intelligent management method for traditional Chinese medicine decoction service based on knowledge graph as described in claim 1, characterized in that, After sending the dispensing voucher, prescription label, and decoction label corresponding to the decoction control command to the corresponding decoction device, the process further includes: Obtain the device execution feedback data corresponding to the decoction control command, and write the device execution feedback data into the traditional Chinese medicine decoction knowledge graph to update the event nodes, device nodes and status nodes associated with the current processing object; Based on the updated associated node relationships, a state transition determination is performed on the currently processed object, and when the determination meets the preset transition conditions, the currently processed object is transitioned from the current state node to the corresponding next state node; When an execution anomaly, state conflict, or label mismatch is detected, an anomaly entity associated with the currently processed object is generated, and the association between the anomaly entity and the corresponding event node, device node, and state node is established. Anomaly localization is performed based on the relationship between the abnormal entity and its associated nodes to output the anomaly type, anomaly source, and anomaly propagation path.

10. A knowledge graph-based intelligent management system for traditional Chinese medicine decoction services, characterized in that, The system is used to execute the intelligent management method for traditional Chinese medicine decoction services based on knowledge graphs as described in any one of claims 1 to 9; the system includes: The input / output unit is configured to collect multi-source business events related to traditional Chinese medicine decoction services and construct a knowledge graph of traditional Chinese medicine decoction services. The processing unit is configured to identify the current processing object and, based on the identification result, retrieve the target patient entity from the traditional Chinese medicine decoction knowledge graph to obtain a set of prescriptions to be processed associated with the target patient entity; based on the incompatibility relationships between the prescriptions to be processed, isolate and group the set of prescriptions to be processed to generate prescription group entities; establish a dispensing sequence number lease node for the prescription group entity; when the dispensing sequence number lease node meets the validity condition, assign a target dispensing sequence number to the prescription group entity and establish an association relationship between the target dispensing sequence number, the decoction task, and the decoction device; and generate a decoction control instruction corresponding to the prescription group entity based on the association relationship. The input / output module is also configured to push the medication voucher, prescription label, and decoction label corresponding to the decoction control command to the corresponding user terminal and / or decoction device.

Images