Intelligent Medical Process Management Method, System and Cloud Platform Based on Cloud Computing

Abstract

The present application discloses a smart medical process management method, system and cloud platform based on cloud computing, which relates to the field of medical informatization management. The method includes: receiving a return application instruction for high-value consumables, and obtaining the UDI code and a list of return details; verifying the list of return details according to the UDI code, and if the verification is passed, determining whether the current service corresponding to the return application instruction starts a business process; if it starts, creating a process instance based on the cloud platform; generating a high-value return processing process based on the process instance, and determining the process processing order based on the high-value return processing process; determining a first process node and a last process node among n process nodes according to the process processing order; starting from the front-end interface corresponding to the first process node, executing a loop step according to the process processing order until jumping to the front-end interface corresponding to the last process node; receiving an end signal of the front-end interface corresponding to the last process node, and jumping to a preset front-end interface. The present application can effectively improve the user experience.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of medical informatization management, and particularly to a smart medical process management method, system and cloud platform based on cloud computing. Background Art

[0002] In modern medical systems, the management of high-value consumables has always been a complex and important issue. High-value consumables generally refer to those medical supplies with relatively high unit prices, low usage frequencies, but crucial for medical quality and patient safety, such as artificial joints, cardiac stents, etc. These consumables not only directly affect medical costs and hospital benefits, but also are closely related to the treatment effects and satisfaction of patients. With the continuous progress of medical technology and the increasing demand for medical services, the usage volume of high-value consumables is also constantly growing, which brings huge challenges to hospital inventory management, cost control and quality assurance.

[0003] In this context, the return processing of high-value consumables has become an indispensable part of the daily operations of medical institutions. Returns may occur in various situations, such as product quality problems, expiration, damaged packaging, order errors, etc. Effective return management can not only reduce the economic losses of hospitals, but also improve the resource utilization efficiency and ensure that patients receive the best medical services. However, since high-value consumables usually involve multiple departments and systems, such as budget management, cost management, inventory management, etc., the return processing flow often becomes complex and cumbersome.

[0004] In traditional medical systems, the return processing of high-value consumables usually involves multiple independent systems and departments. These systems include but are not limited to: budget management system, cost management system, high-value consumable management system, financial system, supply chain management system, etc. Each system has its specific functions and data structures, and there is often a lack of effective integration and information sharing mechanisms between these systems.

[0005] Currently, the return process of high-value consumables is as follows: medical staff or inventory managers submit a return application in the high-value consumable management system, including product information, return reasons, etc.; relevant department heads review the return application in the system to confirm the rationality and necessity of the return; the budget management system needs to adjust the budgets of relevant departments or projects according to the return situation; the cost management system needs to recalculate the costs of relevant medical services or projects; the high-value consumable management system needs to update the inventory information, re-warehouse the returned products or mark them as pending return status. In this process, operators need to frequently switch between different systems and manually input or transfer data. Due to the lack of unified process management, the sequence and dependency relationships between each step may not be clear, resulting in operators may encounter obstacles in a certain step and need to return to the previous steps to reprocess.

[0006] In summary, in the high-value return processing flow of the existing medical system, each system may need to be accessed multiple times. Sometimes, when entering a process, it will be reminded that the previous process needs to be processed first before the current process can be processed. Or, due to the need to manually input or update data in multiple systems, it is easy to cause data inconsistency or errors, resulting in the need to enter the system multiple times for verification and correction. Therefore, the existing high-value return processing flow seriously reduces the work efficiency of operators and affects their usage experience. Summary of the Invention

[0007] An embodiment of the present application provides a cloud computing-based intelligent medical process management method, system, and cloud platform for effectively improving the work efficiency of operators and their usage experience of the medical system.

[0008] To achieve the above object, the embodiments of the present application adopt the following technical solutions:

[0009] In a first aspect, a cloud computing-based intelligent medical process management method is provided, which is applied to an electronic device deployed with a cloud platform. The method includes:

[0010] In response to receiving a return application instruction for high-value consumables, obtain the UDI code of the high-value consumables and a return detail list according to the return application instruction;

[0011] Verify the return detail list according to the UDI code, and determine whether the current service corresponding to the return application instruction starts a business process when the verification is passed;

[0012] When the current service starts a business process, create a process instance based on the cloud platform, and the process instance is used to integrate medical subsystems;

[0013] Based on the process instance, generate a high-value return processing process, and determine the process processing order based on the high-value return processing process. The high-value return processing process includes n process nodes, and each process node corresponds to a front-end interface, where n is an integer greater than 1;

[0014] Determine the first process node and the last process node among the n process nodes according to the process processing order;

[0015] Start from the front-end interface corresponding to the first process node, execute a loop step according to the process processing order until jumping to the front-end interface corresponding to the last process node;

[0016] In response to receiving an end signal from the front-end interface corresponding to the last process node, jump to a preset front-end interface.

[0017] In a possible implementation manner of the first aspect, the verifying the return detail list according to the UDI code includes:

[0018] Parse the UDI code to obtain the product identifier and the production identifier;

[0019] Match the product information according to the product identifier and the production identifier in a preset high-value consumable database;

[0020] Compare the product information with the return details list, and when the product information corresponds to the return details list, determine that the return details list passes the verification.

[0021] In another possible implementation of the first aspect, the cloud platform includes a microservice module. Determining whether the current service corresponding to the return application instruction starts a business process includes:

[0022] Extract the key features of the product information and store the key features in a preset structured data structure;

[0023] Traverse the structured data structure to determine whether there are features that conform to the business process code format;

[0024] If there are features that conform to the business process code format, determine that there is a business process code in the key features;

[0025] Use the business process code as a key to call the microservice module to query the corresponding business port in the cache of the electronic device. The microservice module is used to process the mapping between the key and the business port;

[0026] Send a heartbeat request to the business port. When a response signal returned by the business port is received, determine that the current service corresponding to the return application instruction starts a business process.

[0027] In another possible implementation of the first aspect, the cloud platform further includes a business process engine. When the current service starts a business process, creating a process instance based on the cloud platform includes:

[0028] When the current service starts a business process, use the microservice module to encapsulate each medical subsystem into an independent microservice;

[0029] Based on all the microservices, use a preset business logic to determine all business process nodes and the data flow between the business process nodes;

[0030] Define multiple process files according to all the business process nodes and the data flow;

[0031] Process all the process files using the business process engine to obtain multiple business rules and logical relationships, and generate a dynamic process instance based on all the business rules and all the logical relationships to achieve the integration of all the medical subsystems, where the medical subsystems include a budget management system, a cost management system, and a high-value consumables management system.

[0032] In another possible implementation manner of the first aspect, based on all the microservices, using a preset business logic to determine all business process nodes and the data flow directions between the business process nodes, including:

[0033] Combine and orchestrate all the microservices using a preset business logic combination to determine all business process nodes;

[0034] Map each business process node to the corresponding microservice, and define the input data and output data of each business process node according to the business logic;

[0035] Based on the input data and the output data of each business process node, determine the data flow directions between the business process nodes.

[0036] In another possible implementation manner of the first aspect, the combining and orchestrating all the microservices using a preset business logic combination to determine all business process nodes includes:

[0037] Analyze the business logic to obtain business steps and decision points;

[0038] Determine the call sequence and dependency relationship between all the microservices according to the business steps;

[0039] Combine and orchestrate all the microservices according to the call sequence and the dependency relationship between all the microservices, and determine all the business process nodes according to the decision points.

[0040] In another possible implementation manner of the first aspect, generating a high-value return processing process based on the process instance includes:

[0041] Determine the target business rules and target logical relationships in the process instance according to the business process code;

[0042] Decompose the target business rules according to the target logical relationships to obtain n process nodes, where each process node corresponds to a front-end interface;

[0043] Convert each process node into an executable sub-process instance through the business process engine;

[0044] For each of the sub - process instances, create an associated interface component in the corresponding front - end interface;

[0045] Combine all the interface components through the target logical relationship to obtain a high - value return processing process.

[0046] Determining the process processing order based on the high - value return processing process includes:

[0047] According to the target logical relationship of the high - value return processing process, use a preset topological sorting algorithm to determine the process processing order.

[0048] In another possible implementation manner of the first aspect, the loop step includes:

[0049] Starting from the first process node, use Vue.js to load the interface component of the current active node, where the current active node is the process node currently operated by the user;

[0050] In response to the loading signal of the interface component, communicate with the interface component through WebSocket;

[0051] In response to the change signal of the interface component, determine the next interface component according to the process processing order, and load the next interface component to jump to the front - end interface corresponding to the next interface component. Wherein, if the front - end interface corresponding to the next interface component is the front - end interface corresponding to the final process node, end the loop step.

[0052] In a second aspect, the present application provides a cloud - based intelligent medical process management method system, including:

[0053] A first electronic device, on which a cloud platform is deployed, and the cloud platform is used to execute the above - mentioned cloud - based intelligent medical process management method;

[0054] n second electronic devices, all n second electronic devices are connected to the first electronic device, and each second electronic device is deployed with a medical subsystem, where n is an integer greater than 1.

[0055] In a third aspect, the present application provides a cloud platform, which is deployed in the first electronic device and is used to execute the operation steps of the above - mentioned cloud - based intelligent medical process management method.

[0056] Through the above technical solutions, first, a unified process instance is created through the cloud platform, integrating the budget management system, cost management system, and high-value consumable management system, breaking the information silos among medical subsystems and solving the problem of frequently switching between different systems in traditional processes. Second, by verifying the return details list through UDI codes, the accuracy and consistency of data are ensured, reducing the situation of repeatedly entering the system for checking and correction due to data errors. The high-value return processing process includes n process nodes, each corresponding to a front-end interface, greatly simplifying the operation process and making the entire return processing process clearer. By determining the process processing sequence and clarifying the first process node and the final process node, the problem of unclear sequence and dependency relationship of each step in the traditional process is solved, avoiding the situation where operators need to return to previous steps to reprocess when encountering obstacles in a certain step. Starting from the first process node, the loop steps are executed in the preset order until the final process node. This process-based processing method greatly improves the coherence and efficiency of operations. In summary, this technical solution not only improves the operation efficiency, reduces the risk of operation errors, but also greatly reduces the delay in return processing, thereby enhancing the hospital's operation efficiency and economic benefits. At the same time, due to smoother operations, unnecessary repeated operations and system switches are reduced, also reducing the work pressure and fatigue of employees and improving job satisfaction. Therefore, by introducing the intelligent medical process management method based on cloud computing, multiple problems existing in the high-value consumable return processing process of existing medical subsystems can be effectively solved, significantly improving the overall operation efficiency and user experience.

[0057] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific implementation part. Brief Description of the Drawings

[0058] Figure 1 It is a flowchart of an intelligent medical process management method based on cloud computing provided by an embodiment of the present application;

[0059] Figure 2 It is an architecture diagram of a cloud platform provided by an embodiment of the present application;

[0060] Figure 3 It is a structural diagram of an intelligent medical process management system based on cloud computing provided by an embodiment of the present application. Detailed Description of the Embodiments

[0061] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of this application. It should be understood that the specific implementation manners described herein are only used to illustrate and explain the embodiments of this application, and are not used to limit the embodiments of this application. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this application.

[0062] It should be noted that if there are directional indications (such as up, down, left, right, front, back,...) involved in the embodiments of this application, the directional indications are only used to explain the relative positional relationship and movement conditions between components in a specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indications will also change accordingly.

[0063] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of this application, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions between various embodiments can be combined with each other, but it must be based on the ability of those of ordinary skill in the art to implement. When the combination of technical solutions results in contradictions or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the protection scope required by this application.

[0064] Figure 1 A flowchart of a smart medical process management method based on cloud computing according to an embodiment of this application is schematically shown. As Figure 1 shown, an embodiment of this application provides a smart medical process management method based on cloud computing, which is applied to an electronic device. The electronic device is deployed with a cloud platform, and the method may include the following steps.

[0065] S110. In response to receiving a return application instruction for high-value consumables, obtain the UDI code of the high-value consumables and the return detail list according to the return application instruction;

[0066] S120. Verify the return detail list according to the UDI code, and determine whether the current service corresponding to the return application instruction starts a business process when the verification passes;

[0067] S130. When the current service starts a business process, create a process instance based on the cloud platform. The process instance is used to integrate medical subsystems, and the medical subsystems include a budget management system, a cost management system, and a high-value consumable management system;

[0068] S140. Generate a high-value return processing flow based on the process instance, and determine the process execution order based on the high-value return processing flow. The high-value return processing flow includes n process nodes, and each process node corresponds to a front-end interface, where n is an integer greater than 1;

[0069] S150. Determine the first process node and the last process node among the n process nodes according to the process execution order;

[0070] S160. Start from the front-end interface corresponding to the first process node, execute the loop step according to the process execution order, and jump to the front-end interface corresponding to the last process node;

[0071] S170. In response to receiving the end signal of the front-end interface corresponding to the last process node, jump to the preset front-end interface.

[0072] In this embodiment, the electronic device may be a tablet computer, desktop, laptop, handheld computer, wearable device, notebook computer, ultra-mobile personal computer (UMPC), netbook, or other devices with a processor. Of course, the electronic device may also be a server. The specific form of the electronic device in the embodiments of the present application is not particularly limited.

[0073] In response to receiving the return application instruction for high-value consumables, obtain the UDI code of the high-value consumables and the return detail list according to the return application instruction. In this embodiment, the return application instruction input by the user can be received through the user interface of the electronic device, and the instruction contains the basic information of the return, such as the return reason, return quantity, etc. After receiving the instruction, automatically parse the instruction content to extract the unique device identifier (UDI code) of the high-value consumables and the return detail list. The UDI code is an internationally common unique identifier for medical devices, including a product identifier and a production identifier, which can uniquely identify each medical device. The return detail list contains the detailed information of the returned items, such as item name, specification, quantity, batch number, etc. In specific implementation, first access the high-value consumables management database, and query and match the corresponding high-value consumables records according to the information in the UDI code and the return detail list. The user can fill in the return information through the return application form interface and submit it. The background program receives the form data, parses the UDI code and the return details, and then compares them with the records in the database.

[0074] Verify the return details list according to the UDI code, and determine whether the current business corresponding to the return application instruction starts the business process in the case of successful verification, so as to use the UDI code as the unique identifier to comprehensively verify the return details list. The verification process includes checking the validity of the UDI code, comparing whether the information in the UDI code is consistent with the information in the return details, and verifying whether the return quantity exceeds the original purchase quantity. In this embodiment, first call the UDI code parsing module to decompose the UDI code into a product identifier and a production identifier, and then match it with the records in the high-value consumables database. At the same time, check each item of information in the return details list to ensure that it conforms to the product information corresponding to the UDI code. After successful verification, it can be determined whether the current business corresponding to the return application instruction starts the business process. In specific implementation, the UDI code can be parsed first, and then each item of information in the return details list can be compared one by one. If any inconsistency is found, it will be immediately marked and the user will be prompted to make corrections. For the case of successful verification, the pre-set business rule library can be queried, and according to the characteristics of the current return application, it can be decided whether to start a specific business process to ensure the accuracy and consistency of the return information and prevent return processing problems caused by information errors. At the same time, by intelligently judging whether to start the business process, corresponding processing methods can be adopted for different types of return applications, improving the flexibility and efficiency of return processing.

[0075] In the case that the current business starts the business process, create a process instance based on the cloud platform. The process instance is used to integrate medical subsystems, and the medical subsystems include a budget management system, a cost management system, and a high-value consumables management system. The cloud platform can be used to build a dynamic process instance. This process instance, as an intermediate layer, integrates the originally independent budget management system, cost management system, and high-value consumables management system. The creation process of the process instance first involves the definition and encapsulation of the interfaces of each subsystem to ensure that data can be smoothly transmitted between different systems. Then, according to the predefined business logic, determine the process nodes and data flow directions. Each process node corresponds to a specific business operation, such as budget inspection, cost accounting, inventory update, etc. The distributed computing and storage capabilities of the cloud platform enable the process instance to efficiently process a large number of concurrent requests and achieve real-time data synchronization. In specific implementation, a microservices architecture can be adopted to encapsulate each subsystem as an independent service and manage and call them through an API gateway. The process instance can be implemented using a workflow engine, which can define process files and manage process instances to achieve seamless integration of multiple medical subsystems, enabling various operations involved in the high-value consumables return processing to be completed on a unified platform. This not only improves the consistency and real-time nature of data, but also effectively simplifies the operation process, reducing the time loss and potential errors caused by system switching. At the same time, the implementation method based on the cloud platform can easily handle the growth of business volume and the addition of new functions.

[0076] Based on the process instance, a high-value return processing process is generated, and the process processing sequence is determined based on the high-value return processing process. The high-value return processing process includes n process nodes, and each process node corresponds to a front-end interface, where n is an integer greater than 1. In this embodiment, the abstract process instance can be transformed into a specific and operable high-value return processing process. Specifically, first, a high-value return processing process including multiple process nodes can be dynamically generated according to the business rules and logical relationships defined in the process instance. Each process node represents a specific step or decision point in the high-value return processing process, such as return application review, inventory verification, financial processing, etc. The connection relationship between process nodes determines the processing sequence of the process, including logical relationships such as sequential execution, parallel execution, or conditional branching. Specifically, a unique identifier can be assigned to each process node and associated with the corresponding front-end interface. The front-end interface is the window for users to interact with the system, and the implementation method can use a workflow engine to manage the generation and execution of the process. For example, BPMN (Business Process Model and Notation) can be used to define the process, and then it can be converted into an executable process instance through the workflow engine. For the front-end interface, a component-based development method can be adopted to create an independent interface component for each process node, and these interface components can be dynamically combined and displayed according to the needs of the process. The determination of the process processing sequence can be achieved through a topological sorting algorithm to ensure that subsequent nodes are executed only after all preconditions are met. Finally, a structured and visual high-value return processing process is generated, making the complex return processing process clear and controllable. The front-end interface corresponding to each process node provides an intuitive operation entry, and the operator can clearly understand the current process stage and the operations that need to be performed. It not only standardizes the return processing process, reduces human errors, but also improves the transparency and traceability of the entire process, which is beneficial for subsequent auditing and optimization.

[0077] Determine the first process node and the last process node among n process nodes according to the process handling sequence. In this embodiment, based on the generated high-value return processing process, by analyzing the structure of the flowchart and the connection relationship between nodes, identify and determine the starting point (the first process node) and the ending point (the last process node) of the entire process. The first process node is the entry point of the high-value return processing process, which can be the submission or preliminary review of the return application. The last process node represents the final state of the entire processing process, which can be the completion of the return, the refund arrival, or the filing of relevant documents, etc. The process of determining these two key nodes involves the path analysis algorithm in graph theory. Specifically, a directed graph can be constructed, where each process node is a vertex in the graph, and the connection relationship between nodes is a directed edge. Then, through the depth-first search or breadth-first search algorithm, find the vertex without incoming edges as the first process node and the vertex without outgoing edges as the last process node. By clearly defining the first and last nodes, the life cycle of the process instance can be better managed, such as when to create a new process instance and when to end and file the completed process. This method improves the accuracy and efficiency of process management and also provides a basis for process optimization and analysis.

[0078] Starting from the front - end interface corresponding to the first process node, execute loop steps according to the process handling sequence until jumping to the front - end interface corresponding to the final process node. Based on the previously determined process handling sequence, each process node can be activated one by one and the corresponding front - end interface can be displayed along a predetermined path. This process is dynamic and interactive, and can determine the next process node to be activated according to the user's operations and inputs. The execution of each process node involves background processing such as data verification, business rule checking, database operations, etc., and at the same time, the user needs to provide necessary information or make decisions through the front - end interface. In specific implementation, the state of the current active node can be maintained, and the next node to be activated can be determined according to the conditions and rules in the process definition. This process can continue until the final process node is reached. A state machine model can be used to manage the execution of the process. Each process node can be regarded as a state, and the transition between nodes corresponds to the change of state. The observer pattern or publish - subscribe pattern can be used to handle communication between nodes and state changes. The switching of the front - end interface can be implemented through single - page application (SPA) technology, such as using the Vue.js framework to dynamically load the corresponding interface components according to the current active node. In the background, technologies such as WebSocket are used to communicate with the front - end in real - time to ensure data synchronization and process coherence, thus providing users with a smooth and intuitive return processing experience. Users can clearly see the current process stage and complete all necessary operations through a unified interface. The system can automatically guide users through each step of the operation, reducing the possibility of operation errors and omissions. At the same time, it also improves the transparency and controllability of the entire processing process. Managers can understand the processing progress and status of any return application at any time. In addition, since the entire process is systematic and standardized, it is also convenient for subsequent data analysis and process optimization.

[0079] In response to receiving the end signal of the front-end interface corresponding to the final process node, it jumps to the preset front-end interface. After the entire high-value return processing flow is completed, a clear end mechanism and subsequent operation guidelines are required. When the user completes the last step of operation on the front-end interface corresponding to the final process node and triggers the end signal, this signal will be captured, and then a series of end operations will be executed. The end operations can include the final confirmation and submission of data, the update of relevant system statuses, the generation of processing reports, etc. After completing the above operations, the user interface can be automatically jumped to a pre-defined front-end interface, which can be a summary page showing the results and key information of the entire return processing, or the main page of the cloud platform to guide the user to start new operations. In specific implementation, an event listening mechanism can be used on the front-end to listen for specific operations of the user on the final process node interface (such as clicking the "Complete" button). When this operation is detected, the front-end will send an end signal to the background. After receiving the signal, the background will trigger an end processing flow, execute the necessary data processing and status updates. After completion, the background will send a jump instruction to the front-end, including the URL or routing information of the target page. After receiving this instruction, the front-end will use routing navigation or page redirection to guide the user to the preset front-end interface.

[0080] In this embodiment, first, a unified process instance is created through the cloud platform, realizing the integration of the budget management system, the cost management system, and the high-value consumables management system, breaking the information silos between systems, and solving the problem of frequently switching between different systems in the traditional process. Second, by verifying the return detail list through the UDI code, the accuracy and consistency of the data are ensured, and the situation of repeatedly entering the system for checking and correction due to data errors is reduced. The high-value return processing flow contains n process nodes, and each node corresponds to a front-end interface, greatly simplifying the operation process and making the entire return processing process clearer. By determining the process processing order and clarifying the first process node and the final process node, the problem of unclear order and dependency relationship of each step in the traditional process is solved, and the situation that the operator needs to return to the previous step to reprocess when encountering obstacles in a certain step is avoided. Starting from the first process node, the loop steps are executed in the preset order until the final process node. This process-based processing method greatly improves the coherence and efficiency of the operation. In summary, this technical solution not only improves the operation efficiency, reduces the risk of operation errors, but also greatly reduces the return processing delay, thus enhancing the hospital's operation efficiency and economic benefits. At the same time, due to the smoother operation, unnecessary repeated operations and system switches are reduced, and the work pressure and fatigue of employees are also reduced, improving job satisfaction. Therefore, by introducing the intelligent medical process management method based on cloud computing, multiple problems existing in the high-value consumables return processing flow of the existing medical subsystems can be effectively solved, and the overall operation efficiency and user experience are significantly improved.

[0081] In one implementation of this embodiment, verifying the return details list according to the UDI code includes the following steps:

[0082] S210. Analyze the UDI code to obtain the product identifier and the production identifier;

[0083] S220. Match the product information in the preset high-value consumables database according to the product identifier and the production identifier;

[0084] S230. Compare the product information with the return details list, and when the product information corresponds to the return details list, determine that the return details list passes the verification.

[0085] The UDI code, fully known as the Unique Device Identification code, is a complex string containing the product identifier and the production identifier. The parsing process first needs to identify the encoding format of the UDI code. Common standards include GS1, HIBCC, and ICCBBA, etc. Taking the GS1 standard as an example, the UDI code usually consists of an Application Identifier (AI) and a data field. The product identifier part contains the Global Trade Item Number (GTIN), while the production identifier part contains information such as batch number, serial number, and production date. When parsing, first split the UDI code into multiple data segments through specific delimiters (such as parentheses or special characters). Then, according to the predefined data structure template, identify the meaning of each data segment. For example, in the UDI code of "(01)47964367965424(17)220531(10)A213B4", the 14 digits after "(01)" are the GTIN, that is, the product identifier; the 6 digits after "(17)" are the expiration date, and the alphanumeric combination after "(10)" is the batch number, which together constitute the production identifier.

[0086] Match according to the product identifier and production identifier obtained by parsing in a preset high-value consumables database. In this embodiment, there is a preset database for storing high-value consumables information. This database has a hybrid architecture of a relational database (such as MySQL) combined with a non-relational database (such as MongoDB) to balance query efficiency and data flexibility. During the query process, first use the product identifier (such as GTIN) as the primary key to perform an exact match in the database. If a corresponding record is found, further use the information in the production identifier (such as batch number, production date) for secondary screening. A fuzzy matching algorithm can be used because the formats of production identifiers may have slight differences. For example, for the batch number "A213B4", variants such as "a213b4", "A-213-B4" need to be considered. In actual operation, SQL statements combined with regular expressions can be used for querying. If no matching record is found in the main database, the historical database or external data sources can be queried. Finally, the product information obtained by matching should include detailed information such as the complete product name, specification, manufacturer, approval number, etc., providing comprehensive reference data for the subsequent verification of return details.

[0087] Compare the product information with the return details list. First, it is necessary to define the key fields for comparison, including product name, specification model, production batch number, production date, expiration date, etc. The comparison process adopts a field-by-field matching method. In this embodiment, the consistency of data formats also needs to be considered. For example, there may be synonyms or abbreviations for the product name, and a word vector model can be used to calculate the similarity. For numerical fields, such as specifications, standardize the units before comparison. In addition, this embodiment also needs to check the quantity information to ensure that the return quantity does not exceed the original purchase quantity. If all key information can correspond and the quantity is reasonable, it is confirmed that the verification of the return details list passes.

[0088] This embodiment uses the UDI code to verify the return details list, which can effectively improve the inventory management efficiency of medical institutions. Through accurate product identification and information matching, problem batches can be quickly located, which helps with quality traceability and risk management.

[0089] In one implementation manner of this embodiment, the cloud platform includes a microservice module. Determining whether the current service corresponding to the return application instruction enables the business process includes the following steps:

[0090] S310. Extract the key features of the product information and store the key features in a preset structured data structure;

[0091] S320. Traverse the structured data structure to determine whether there are features that conform to the business process code format;

[0092] S330. If there is a feature that conforms to the business process code format, it is determined that there is a business process code among the key features;

[0093] S340. Use the business process code as the key and call the microservice module to query the corresponding business port in the cache of the electronic device. The microservice module is used to process the mapping between the key and the business port;

[0094] S350. Send a heartbeat request to the business port. When the response signal returned by the business port is received, it is determined that the current business corresponding to the return application instruction starts the business process.

[0095] First, extract the key features of the product information and store them in a preset structured data structure. The key features may include core information such as the unique identifier of the product (such as UDI code or internal code), product name, specification model, production batch number, production date, expiration date, manufacturer, etc. Feature extraction can use natural language processing (NLP) techniques, such as named entity recognition (NER), to identify and extract these features from unstructured text. After extraction, the above features are stored in a preset structured data structure. The structured data structure refers to a data structure that can effectively organize and quickly retrieve data, such as a hash table, B-tree, or relational database table. Structured storage not only facilitates subsequent data processing and retrieval but also ensures data consistency and integrity.

[0096] Traverse the structured data structure to determine whether there is a feature that conforms to the business process code format. Specifically, the business process code is a string with a specific format used to identify and trigger a specific business process. For example, if the business process code is "BF-RTN-001", where "BF" represents the business process, "RTN" represents the return process, and "001" is the specific number of the process. The traversal process first defines a regular expression to match the format. Then, each field stored in the structured data structure is traversed and matched. If a string that conforms to the format is found in any field, it is marked as finding the business process code, thus effectively extracting the key business process information from the complex product information and providing necessary guidance for subsequent process processing.

[0097] When a feature that conforms to the business process code format is found during the traversal of the structured data structure, it is determined that there is a business process code among the key features.

[0098] Using the business flow code as the key, call the microservice module to query the corresponding business port in the cache of the electronic device. Specifically, the business flow code is used as the key to find the corresponding business port. A "business port" generally refers to the network address and port number of a microservice instance that provides specific business services. The microservice module is the service registry, responsible for maintaining the mapping relationship between the key (business flow code) and the business port. The mapping relationship is stored in the cache of the electronic device to improve the query efficiency. The cache can be implemented using an in-memory database (such as Redis) or a distributed cache system. The query process is as follows: First, the microservice module receives a query request containing the business flow code; then, it looks up the business port information corresponding to the code in the cache; if found, it returns the port information; if not found, it queries the backend database or triggers the service discovery mechanism. Ultimately, it can decouple the business process from the specific service instance, improving the flexibility and scalability of the system.

[0099] Sending a heartbeat request to the business port and confirming the response is a service availability verification process to ensure that the found business port is active and can handle requests normally. The heartbeat request is a lightweight POST request sent to a specific URL path of the business port. This request does not contain specific business data and is only used to check whether the service is online and for the response. When sending the heartbeat request, an appropriate timeout needs to be set, usually between 100 - 500 milliseconds, to balance the response speed and the impact of network fluctuations. If a response is received within the timeout period, the response content needs to be parsed. If the status in the response is "UP" or a similar normal status indication, it can be confirmed that the business port is active and the current business has started the business flow. If no response is received, or the response status is abnormal, error handling needs to be performed, which can be retried, and after a preset number of retries, report that the service is unavailable to the upper layer. Specifically, if three consecutive heartbeat requests fail, mark the service instance as unavailable and temporarily remove it from the available list.

[0100] This embodiment realizes the precise positioning and verification from the original data to the specific service instance, significantly improving the automation level and processing efficiency, and can quickly and accurately route the return application instruction to the correct business processing flow. At the same time, through the microservice architecture and heartbeat detection, the scalability and reliability are enhanced. It not only simplifies the management of complex business processes but also provides a basis for dynamic service scheduling and load balancing, making the high-value return processing flow more flexible, efficient, and stable.

[0101] In one implementation of this embodiment, the cloud platform further includes a business flow engine. When the current business starts the business flow, a process instance is created based on the cloud platform, including the following steps:

[0102] S410. When the business process is enabled for the current business, each medical subsystem is encapsulated as an independent microservice using a microservice module;

[0103] S420. Based on all microservices, using a preset business logic, determine all business process nodes and the data flow between business process nodes;

[0104] S430. Define multiple process files according to all business process nodes and data flows;

[0105] S440. Use a business process engine to process all process files, obtain multiple business rules and logical relationships, and generate dynamic process instances based on all business rules and all logical relationships to achieve the integration of all medical subsystems, where the medical subsystems include a budget management system, a cost management system, and a high-value consumables management system.

[0106] When the business process is enabled for the current business, each medical subsystem is encapsulated as an independent microservice using a microservice module to transform the originally monolithic or tightly coupled medical subsystems into loosely coupled and independently deployable microservices. First, perform functional analysis and boundary division on each medical subsystem (budget management system, cost management system, high-value consumables management system). Specifically, the core functions and external interfaces of each system can be identified. For example, the budget management system includes function modules such as budget formulation, budget adjustment, and budget execution tracking. Next, determine microservice interfaces for each identified function module, and then refactor the existing code to encapsulate each function module into an independent service container, such as a Docker container. The code that originally directly accessed the database can be changed to operate through a unified data access layer, and configuration such as database connection information can be extracted into environment variables or configuration files. In addition, message queues can be used to implement asynchronous communication. Finally, implement basic functions such as health checks, logging, and monitoring for each microservice to ensure its manageability and observability in a distributed environment. Ultimately, the originally tightly coupled system becomes more modular and extensible, and each microservice can be developed, tested, and deployed independently, greatly improving flexibility and maintainability.

[0107] Based on all microservices, using the preset business logic, determine all business process nodes and the data flow between business process nodes, so as to transform the abstract business requirements into specific and executable process definitions. First, all key nodes can be identified according to the entire business process. Taking the high-value medical device return process as an example, the nodes involved may include: submission of return application, budget impact assessment, cost accounting, inventory update, financial processing, etc. Each node corresponds to the invocation of one or more microservices. Next, define the logical relationships and data flows between the nodes. For example, after the return application is submitted, it is necessary to trigger both the budget impact assessment and cost accounting simultaneously, and these two nodes may execute in parallel; while the inventory update must be carried out after the cost accounting is completed, which is a serial relationship. The definition of the data flow includes determining the input and output data of each node. For instance, the output of the return application node (such as return product information, quantity, amount) will be used as the input of the budget assessment and cost accounting nodes. In actual implementation, business process modeling tools (such as BPMN 2.0) can be used to visualize these nodes and relationships. Finally, convert these definitions into a format that can be understood and executed by the business flow engine, usually a configuration file in XML or JSON format.

[0108] Defining multiple process files according to all business process nodes and data flows is a process of transforming abstract processes into specific executable files, so as to convert the business process nodes and data flows determined in S420 into a standardized file format that can be parsed and executed by the business flow engine. Usually, the executable files are in XML or JSON format and follow a specific business process definition language (such as BPEL, XPDL or a custom DSL). First, create an independent process file for each major business process. For example, there may be a main process file describing the entire return process, and multiple sub-process files respectively describing specific links such as budget assessment and cost accounting. When creating these files, it is necessary to define the basic information of the process, such as metadata like process ID, version number, creation time, etc. Next, each business process node needs to be converted into specific elements in the process file. Taking the XML format as an example, a node is defined as: id="submitRefundRequest", name="Submit Return Application", serviceTask implementation="refundService.submitRequest", outgoing>flow1.

[0109] Among them, the id and name attributes are used to uniquely identify and describe nodes. The serviceTask element specifies the microservice call corresponding to this node, and the outgoing element defines the data flow direction. Then, the connections between nodes and data transfer need to be defined. This is achieved in the following way: id="flow1", sourceRef="submitRefundRequest", targetRef="budgetAssessment". This means that data flows from the "Submit Refund Request" node to the "Budget Assessment" node.

[0110] Finally, the business process engine processes all process files to obtain multiple business rules and logical relationships, and generates dynamic process instances based on all business rules and logical relationships. Specifically, first, the business process engine loads and parses all process files defined in S430. The parsing process includes verifying the syntax correctness of the files, checking the integrity of nodes and connections, and parsing the attributes and configurations of various elements. During the parsing process, the engine constructs a process model in memory, which reflects the structure and attributes of the process.

[0111] Next, the engine needs to extract business rules and logical relationships from the parsed process model. Business rules include conditional branches, data validation rules, permission checks, etc. For example, a business rule extracted by the engine can be: when the budget is sufficient (greater than or equal to the refund amount), the process enters the refund approval link. Logical relationships describe the execution order and dependencies between nodes, including serial, parallel, conditional branches, etc.

[0112] After extracting the rules and relationships, the engine needs to convert these abstract definitions into executable code or instructions. A memory data structure containing all business rules and relationships can be constructed. Finally, based on business rules and logical relationships, the engine creates a dynamic process instance. This instance is a runtime representation of the process definition, containing information such as the current state of the process, executed nodes, and nodes to be executed. During the instantiation process, the engine needs to initialize process variables, set the initial state, and prepare to execute the first node. This embodiment can transform the static process definition into an executable and dynamic process instance, realizing the integration of the medical subsystem. In this way, different subsystems (such as budget management, cost management, high-value consumable management) can work together under a unified process framework, improving the flexibility and efficiency of the overall system.

[0113] In this embodiment, by encapsulating the medical subsystem as a microservice, a high degree of modularity and scalability is achieved. Based on the business process nodes and data flow directions designed in the microservice architecture, a clear structure and logical framework are provided for complex medical business processes. Transforming the business process nodes and data flow directions into standardized process files not only improves the readability and maintainability of process definitions but also provides a unified interface for integration between different systems. Finally, through the processing and instantiation of these files by the business flow engine, dynamic and flexible process execution is realized. This greatly improves the adaptability and response speed of the system, enabling it to quickly respond to complex demand changes in the medical industry while ensuring efficient collaboration between different subsystems, providing a comprehensive and efficient business process management solution for medical institutions.

[0114] In one implementation of this embodiment, based on all microservices, using a preset business logic, determine all business process nodes and the data flow directions between the business process nodes, including the following steps:

[0115] S510. Combine and orchestrate all microservices using a preset business logic to determine all business process nodes;

[0116] S520. Map each business process node to the corresponding microservice and define the input data and output data of each business process node according to the business logic;

[0117] S530. Based on the input data and output data of each business process node, determine the data flow directions between the business process nodes.

[0118] In this embodiment, first, combine and orchestrate all microservices using a preset business logic to determine all business process nodes. Specifically, the preset business logic can be deeply analyzed, and the business logic can be determined through business requirement documents. Taking the medical device procurement process as an example, the preset business logic may include multiple links such as requirement submission, budget review, supplier selection, contract signing, and payment processing. Next, match these business logics with the encapsulated microservices. For example, the budget review link corresponds to the microservice of the budget management system.

[0119] During the process of combining and orchestrating microservices, the dependency relationships, execution order, and parallel possibilities between microservices need to be considered. For example, the budget review must be carried out after the requirement submission, while the supplier qualification review may be carried out in parallel with the budget review. In actual operation, workflow modeling tools (such as the BPMN 2.0 editor) can be used to visually orchestrate the process and create a preliminary flowchart.

[0120] Determining business process nodes is the result of the orchestration process. Each node represents an independent business step, usually corresponding to the invocation of one or more microservices. For example, the "Budget Review" node includes multiple microservice invocations such as querying budget information, calculating available budget, and updating budget status. When defining a node, it is necessary to clarify the responsibilities, execution conditions, and completion criteria of each node.

[0121] After that, each business process node is mapped to the corresponding microservice, and the input data and output data of each business process node are defined according to the business logic to establish a clear association between the business process node and the specific microservice implementation, and define how data flows between nodes. First, analyze the functional requirements of each business process node to determine the microservices they need to invoke. For example, the "Budget Review" node needs to invoke microservices of the budget management system to check the available budget, update the budget status, etc. This mapping process may be one-to-one (one node corresponds to one microservice) or one-to-many (one node needs to invoke multiple microservices). This application does not limit this.

[0122] In actual operation, a mapping table or configuration file can be created to record in detail the correspondence between each node and the microservice. For example:

[0123] Node Name: Budget Review

[0124] Corresponding Microservice:

[0125] Service Name: BudgetCheckService

[0126] Method: checkBudget

[0127] Service Name: BudgetUpdateService

[0128] Method: updateBudgetStatus

[0129] Next, define the input data and output data for each node. The input data is the information required for the node to execute, coming from the output of the upstream node or external input. The output data is the result generated after the node executes, which will be passed to the downstream node or used as the final output of the process. For example, the input data of the "Budget Review" node includes: purchase application ID, requested amount, department number; the output data includes: review result (approved / rejected), available budget amount, review comments.

[0130] Finally, based on the input and output data of each business process node, determine the data flow between business process nodes to establish a complete, end-to-end data flow diagram for describing the transfer of data throughout the business process. First, match the output of each node with the input of other nodes. An initial data flow diagram can be created, connecting the nodes with arrows and annotating the data items transferred on the arrows. Flowchart tools (such as Visio or Draw.io) can be used for drawing.

[0131] In actual operation, a data flow matrix can be used to detail the data transfer between nodes. The rows of the matrix represent data providers (source nodes), the columns represent data consumers (target nodes), and the transferred data items are filled in the cross cells.

[0132] In this embodiment, by adopting a preset business logic combination and orchestrating microservices, clear business process nodes are determined, providing a structured framework for the entire process. Mapping each node to a specific microservice and defining its input and output data not only realizes the close combination of business logic and technical implementation but also provides a clear interface definition for data flow. Finally, by determining the data flow between nodes, the entire process is connected into a whole, ensuring the smooth transfer and correct conversion of data throughout the business process. It greatly improves the flexibility and maintainability of the system, enabling complex medical business processes to be implemented in a modular and scalable manner. At the same time, it provides a solid foundation for system integration, exception handling, and process optimization, capable of quickly responding to changes in business requirements and improving overall operational efficiency.

[0133] In one implementation of this embodiment, all microservices are combined and orchestrated using a preset business logic combination to determine all business process nodes, including the following steps:

[0134] S610. Analyze the business logic to obtain business steps and decision points;

[0135] S620. Determine the call order and dependency relationship between all microservices according to the business steps;

[0136] S630. Combine and orchestrate all microservices according to the call order and dependency relationship between all microservices, and determine all business process nodes according to the decision points.

[0137] In this embodiment, first, the business logic is parsed and transformed into clear and executable business steps and decision points. In specific implementation, the key business steps and decision points can be identified by detailing the main process and alternative processes of each use case. For example, the "budget review" use case includes the following steps: 1. Receive a procurement application; 2. Check the department budget; 3. Decision point: Is the budget sufficient?; 4. If sufficient, approve the application; 5. If not sufficient, reject the application or initiate a budget adjustment process.

[0138] A decision point is a place in the process where different execution paths need to be selected based on specific conditions. Each decision point has clear conditions and corresponding actions.

[0139] The parsing results can be organized into a structured document. It includes: a detailed list of steps, with clear input, processing logic, and output for each step; a list of decision points, including the conditions and possible outcomes of each decision point; a list of business rules and constraints; and a glossary of key terms to ensure that all relevant parties have a consistent understanding of important concepts.

[0140] Based on the business steps, determine the call order and dependencies between all microservices. Specifically, in this embodiment, there is a pre-set service catalog or API document that details the functions, interfaces, and data models of each microservice. Map each business step to one or more microservices. When determining the call order, it can be achieved through the logical order of the business process and data dependencies. For example, budget review must be carried out after the return application is submitted because it requires the data of the return application as input. Determining dependencies not only involves the direct call order but also includes data dependencies and state dependencies. For example: Data dependency: The budget management service depends on the return amount data provided by the return application service.

[0141] Finally, combine and orchestrate all microservices according to the call order and dependencies between all microservices, and determine all business process nodes based on the decision points.

[0142] Specifically, first use a workflow engine to build a complete process orchestration model. During the orchestration process, each business step needs to be converted into a task or activity in the process. Each task needs to be associated with the corresponding microservice. This can be achieved by specifying service calls in the process definition. For example, the "budget review" task may call the checkBudget method of the budget management service.

[0143] Decision points are represented as gateways in the process. BPMN provides various types of gateways, such as Exclusive Gateway, Parallel Gateway, and Inclusive Gateway, etc. For example, after budget review, an Exclusive Gateway can be used to decide whether to continue the process or return it for modification according to the review results.

[0144] In this embodiment, by parsing the business logic, clear business steps and decision points are obtained, providing a structured foundation for the entire process. Subsequently, by determining the call sequence and dependency relationship between microservices, the abstract business logic is transformed into a specific technical implementation path. Finally, by combining and orchestrating microservices and integrating decision points, a complete and executable business process is created. This not only ensures a close correspondence between the technical implementation and business requirements but also improves the flexibility and maintainability of the system.

[0145] In one implementation of this embodiment, based on the process instance, a high-value return processing process is generated, including the following steps:

[0146] S710. Determine the target business rules and target logical relationships in the process instance according to the business flow code;

[0147] S720. Decompose the target business rules according to the target logical relationships to obtain n process nodes, where each process node corresponds to a front-end interface;

[0148] S730. Convert each process node into an executable sub-process instance through the business flow engine;

[0149] S740. For each sub-process instance, create an associated interface component in the corresponding front-end interface;

[0150] S750. Combine all interface components through the target logical relationships to obtain the high-value return processing process.

[0151] First, determine the target business rules and target logical relationships in the process instance according to the business flow code to extract the key business rules and their logical relationships from the existing process instance, laying a foundation for the subsequent generation of the high-value return processing process. In this embodiment, a custom parser can be used to implement it. For example, using JAXB (Java Architecture for XML Binding) can parse the XML-formatted business flow code into Java objects for further processing and analysis. After parsing, a structured data model containing all nodes, conditions, and variables can be obtained.

[0152] Next, the target business rules can be extracted from this data model. For example, a business rule might be "Returns of high-value goods (worth over 1000 yuan) must undergo quality inspection." This rule is reflected in the transition condition from the "Return Application" to the "Quality Inspection" node.

[0153] During the process of extracting business rules, decision tables or decision trees can be used to organize and represent these rules. For example, a decision table can be created, listing different return situations (such as the value of the goods, the reason for return, the purchase time, etc.) and the corresponding processing procedures. At the same time, the target logical relationships need to be identified. The target logical relationships are mainly reflected in the connections and conditional judgments between nodes. For example, there is a "dependency" relationship between "Return Reason Verification" and "Quality Inspection", that is, quality inspection can only be carried out after verifying the return reason. The logical relationships can be represented graphically, such as flowcharts or state transition diagrams.

[0154] Decompose the target business rules according to the target logical relationships to obtain n process nodes, where each process node corresponds to a front-end interface, so as to split the target business rules into a series of independent but interrelated process nodes, and each node can be visually presented and operated on the front-end interface.

[0155] First of all, for the target business rules, the decomposition based on the target logical relationships needs to follow the following splitting principles, which include but are not limited to: independence of functions, integrity of data, convenience of user interaction, etc. For example, in the high-value return processing flow, the business rule of "Return Application" needs to be split into multiple process nodes: input of return information, selection of return reason, upload of return vouchers, confirmation of return address.

[0156] Each process node has clear inputs, processing logics, and outputs. For example, the input of the "Return Reason Selection" node is a predefined list of return reasons, the processing logic is that the user selects one or more reasons, and the output is the selected return reason.

[0157] In actual operations, flowcharts or state diagrams can be used to visualize these process nodes and their relationships. For example, use BPMN (Business Process Model and Notation) tools to create detailed flowcharts, where each node is represented as a task or activity, and the lines between the nodes represent logical relationships.

[0158] For example, for the "Return Reason Selection" node, the front-end interface may include: a multi-selection list showing all possible return reasons; a text box allowing the user to enter other reasons; "Confirm" and "Return" buttons; a progress indicator showing the current position in the entire process.

[0159] Convert each process node into an executable sub - process instance through a business process engine, so as to transform the above - mentioned process nodes into software entities that can actually run and be managed. The business process engine can interpret process definitions, coordinate the execution of tasks, manage process states, and handle exceptions. The business process engine can be Activiti.

[0160] Convert the definition of each process node into a format that the engine can understand, such as an XML file. Next, the corresponding business logic needs to be implemented for each process node. For example, for the "Return Reason Selection" node, the following functions can be implemented: load optional return reasons from a database or configuration file; verify the user's selection; update the status of the return application according to the selected reason; determine the next node to execute.

[0161] The above - mentioned business logic can be implemented by writing Java classes or scripts and associating them with the process definition.

[0162] Create relevant interface components for each sub - process instance. The functional requirements and data interaction requirements of each sub - process instance can be analyzed, and the corresponding interface components can be designed and implemented according to the above requirements. During specific implementation, a component - based development method can be adopted, encapsulating the interface elements corresponding to each sub - process into independent components. These components may include common user interface elements such as forms, buttons, lists, and dialog boxes. In actual operation, Vue can be used to build these components. Each component can run independently and can interact with the backend service for data.

[0163] Finally, combine all the created interface components according to the target logical relationship to finally form a complete high - value return processing process interface. During the implementation process, first, the logical sequence of the entire high - value return processing process needs to be sorted out. It includes multiple links such as return application, review, logistics arrangement, and refund processing. According to the sequence and interdependence of these links, determine the placement position and display order of each interface component. During the combination process, the coherence and intuitiveness of user operations need to be considered. For example, a step navigation bar can be used to display the progress of the entire process, so that users can clearly know which stage they are in and which steps still need to be completed. At the same time, pay attention to data transfer and state synchronization between components. For example, after the return application is approved, the subsequent logistics arrangement component should be able to automatically obtain and display relevant order information.

[0164] To implement complex logical relationships, introduce a state management tool (such as Vuex) to uniformly manage the states and data flows of each component. This can ensure that in complex business scenarios, each component can maintain data consistency and real - time performance.

[0165] This embodiment constructs a high-value return processing flow interface that is functionally complete and user-friendly. This interface can not only accurately reflect complex business logics, but each sub-process has its own dedicated interface component, which can operate independently and cooperate closely through carefully designed logical relationships. The final interface can adapt to different usage scenarios and user requirements. Through the state management and data synchronization mechanisms, the consistency and real-time nature of data throughout the process are ensured, effectively enhancing the user experience and improving the efficiency and accuracy of return processing.

[0166] In one implementation of this embodiment, based on the high-value return processing flow, the process processing sequence is determined, including the following steps:

[0167] S810. According to the target logical relationship of the high-value return processing flow, use a preset topological sorting algorithm to determine the process processing sequence.

[0168] This embodiment can convert the high-value return processing flow into a directed acyclic graph (DAG) according to the target logical relationship of the high-value return processing flow, and then obtain a reasonable processing sequence through the topological sorting algorithm.

[0169] First, each process node (such as return application, review, logistics arrangement, refund processing, etc.) in the high-value return processing flow needs to be regarded as a vertex in the graph. The dependencies between these nodes are represented as directed edges. For example, if the refund processing must be carried out after the return application has been reviewed and approved, then there will be a directed edge from the "review" node to the "refund processing" node.

[0170] After constructing the complete directed graph, next, apply the topological sorting algorithm. The topological sorting algorithm in this embodiment is the Kahn algorithm, and its basic steps are as follows: 1. Find all vertices with an in-degree of 0 in the graph and add them to a queue. These vertices represent the process nodes that can start processing immediately. 2. When the queue is not empty, take out a vertex from the queue and add it to the sorting result. 3. For the taken-out vertex, subtract 1 from the in-degree of all its adjacent vertices. If the in-degree of a certain adjacent vertex becomes 0, add it to the queue. 4. Repeat steps 2 and 3 until the queue is empty. 5. If there are still vertices in the graph that have not been visited finally, it means that there is a cycle in the graph, that is, there is a circular dependency in the business process. In this case, special processing or an error needs to be reported.

[0171] This embodiment uses a topological sorting algorithm to determine the processing order of the high-value return processing flow, providing a clear roadmap for the execution of the entire process. It can not only accurately reflect complex business logics and dependencies but also automatically identify and resolve potential circular dependency problems. By transforming the business process into a directed acyclic graph and applying the topological sorting algorithm, a logical and efficient processing order can be obtained, which can adapt to complex and changeable business scenarios, support parallel processing and dynamic adjustment, thus effectively improving the efficiency and flexibility of return processing while enhancing the user experience.

[0172] In one implementation of this embodiment, the loop steps include:

[0173] S910. Starting from the first process node, use Vue.js to load the interface component of the current active node, where the current active node is the process node currently operated by the user;

[0174] S920. In response to the loading signal of the interface component, communicate with the interface component via WebSocket;

[0175] S930. In response to the change signal of the interface component, determine the next interface component according to the process processing order and load the next interface component to jump to the front-end interface corresponding to the next interface component. If the front-end interface corresponding to the next interface component is the front-end interface corresponding to the last process node, the loop steps end.

[0176] Vue.js is a JavaScript front-end framework that adopts a component-based development approach and is suitable for building complex single-page applications (SPAs). In this step, it is first necessary to determine the first process node, which is usually the entry point of the entire high-value return processing flow, such as the return application page.

[0177] The process of using Vue.js to load components first includes dynamic component loading. Vue.js provides the component element, and with the is attribute, it can achieve the dynamic rendering of components. In addition, Vue.js supports asynchronous components, and the corresponding component code is loaded only when needed. This can be achieved through Vue's defineAsyncComponent function, which accepts a factory function that returns a Promise as a parameter. In actual implementation, a component mapping table can be created to map the name of each process node to the corresponding component. Then, according to the name of the current active node, the corresponding component can be obtained from this mapping table and rendered using Vue's dynamic component function.

[0178] In response to the loading signal of the interface component, communicate with the interface component via WebSocket. WebSocket is a protocol for full-duplex communication over a single TCP connection. It provides a way to establish a persistent connection between the client and the server and is suitable for real-time interaction scenarios. In the high-value return processing flow, using WebSocket can achieve real-time data exchange between the server and the client. When the interface component finishes loading, it sends a loading signal, which triggers the establishment process of the WebSocket connection.

[0179] In this embodiment, the establishment of the WebSocket connection includes the following steps: 1. The client (browser) initiates a WebSocket connection request. 2. When the server receives the request and supports WebSocket, it performs a handshake. 3. After the handshake is successful, the WebSocket connection is established, and at this time, two-way communication can be carried out.

[0180] In a Vue.js application, the WebSocket connection can be initialized in the mounted lifecycle hook of the component. Once the WebSocket connection is established, messages can be sent and received through it. For example, a message indicating that the component has been loaded can be sent. After the server receives this message, corresponding processing can be done, such as updating the process status, preparing relevant data, etc.

[0181] The real-time communication implemented through WebSocket can greatly improve the response speed and user experience of the high-value return processing flow. For example, when an administrator approves a return application, the electronic device can immediately push a notification to the user via WebSocket, and the user interface can update the status in real time without refreshing the page.

[0182] In response to the change signal of the interface component, determine and load the next interface component according to the process handling sequence. When the user completes an operation on the current interface and triggers the change signal, the next interface component to be displayed can be determined according to the predefined process handling sequence, and then loaded and jumped to.

[0183] The change signal is usually triggered by the user's operations, such as submitting a form, clicking the confirmation button, etc. After the change signal is triggered, the parent component or a dedicated process control component will capture this event, and then determine the next component according to the process handling sequence. The process handling sequence obtained by the topological sorting algorithm before can be used.

[0184] For example, a flowchart object can be maintained. Then, based on the current component name, the next component can be determined. After determining the next component, the dynamic component feature of Vue.js can be used to load it. This can be achieved by updating a reactive variable. In this way, the dynamic flow of the high-value return processing process can be realized, making the entire processing process smoother and more efficient. Users can complete all necessary steps in the predefined process sequence, and at the same time, the system can flexibly handle various possible situations.

[0185] In this embodiment, by implementing loop steps, the high-value return processing process achieves a high degree of dynamicity and interactivity. Starting from the first process node, corresponding interface components can be dynamically loaded according to user operations and the predefined process sequence, and real-time communication is maintained through WebSocket. This not only improves the user experience but also greatly enhances the flexibility and response speed of the system. Users can smoothly complete the entire return processing process, while the system can update the status in real time, push important notifications, and dynamically adjust the process according to the actual situation.

[0186] In summary, Figure 2 shows an architecture diagram of a cloud platform provided by an embodiment of the present application. As Figure 2 shown, the front-end UI (User Interface Layer) of the cloud platform architecture is the interface for users to interact with the system, responsible for presenting information and receiving user input.

[0187] The interface component is the front-end interface corresponding to each process node, loaded and rendered using front-end frameworks such as Vue.js. WebSocket communication is used for real-time communication between the front end and the back end to ensure the dynamic update and jump of the interface components. The presentation layer is used to present the data processed by the business logic in a user-friendly manner on the front-end UI. Front-end frameworks such as Vue.js are used to build dynamic and responsive user interfaces. Interface logic is used to handle user interaction logic, such as the loading, jumping, and change of interface components. The business layer is responsible for handling business logic, process control, and data flow. The microservice module can encapsulate each medical subsystem as an independent microservice to handle specific business logic. The business flow engine is responsible for creating and managing process instances, handling the logical relationships and data flow directions between business process nodes. Business rules and logical relationships define the specific rules of the business process and the logical relationships between nodes.

[0188] The database is responsible for data storage, retrieval, and management, providing data support for the business layer, including high-value consumable databases, structured data structures, and caches. The operating environment is the infrastructure for the system to run, providing resources such as computing, storage, and network support, including containerization technologies such as Docker and Kubernetes for deploying and managing microservice modules; servers and network devices for providing computing and network resources to ensure the high availability and scalability of the system.

[0189] This architecture design makes the system highly scalable, flexible and maintainable, and can effectively support the requirements of intelligent medical process management.

[0190] The embodiment of the present application also provides a system for an intelligent medical process management method based on cloud computing, as Figure 3 shown, including:

[0191] The first electronic device 10, on which a cloud platform is deployed, and the cloud platform is used to execute the above-mentioned intelligent medical process management method based on cloud computing;

[0192] n second electronic devices 20, each of the second electronic devices 20 is connected to the first electronic device 10, and each of the second electronic devices 20 is deployed with a medical subsystem, where n is an integer greater than 1.

[0193] In a third aspect, the present application provides a cloud platform, which is deployed in the first electronic device and is used to execute the operation steps of the above-mentioned intelligent medical process management method based on cloud computing.

[0194] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0195] The present application is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, and the combination of processes and / or blocks in the flowchart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing devices generate a device for realizing the functions specified in Figure 1 one process or multiple processes and / or blocks Figure 1 one block or multiple blocks.

[0196] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate a manufactured article including an instruction device, and the instruction device realizes the functions in Figure 1 one process or multiple processes and / or blocksFigure 1 the functions specified in one or more boxes

[0197] These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process. Thus, the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one Figure 1 one process or more processes and / or boxes Figure 1 the steps of the functions specified in one or more boxes

[0198] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0199] The memory may include non-permanent memory in the computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of a computer-readable medium.

[0200] Computer-readable media includes permanent and non-permanent, removable and non-removable media and can store information by any method or technology. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0201] It should also be noted that the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, commodity or device comprising a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent in such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising one..." does not exclude the presence of another identical element in the process, method, commodity or device comprising the element.

[0202] The above are only the embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the scope of the claims of the present application.

Claims

1. A smart medical process management method based on cloud computing, characterized in that Applied to a cloud platform which is deployed in an electronic device. The cloud platform includes a microservice module and a business process engine. The method includes: In response to receiving a return application instruction for high-value consumables, obtain the UDI code of the high-value consumables and the return detail list according to the return application instruction; Verify the return detail list according to the UDI code, and determine whether the current business corresponding to the return application instruction starts a business process when the verification passes; When the current business starts a business process, encapsulate each medical subsystem into an independent microservice by using the microservice module; Analyze the business logic to obtain business steps and decision points; Map each business step to one or more microservices, and determine the call order and dependency relationship between all microservices based on the logical order and data dependency relationship of the business steps; Combine and orchestrate all microservices according to the call order and dependency relationship between all microservices, and determine all business process nodes according to the decision points; Map each business process node to the corresponding microservice, and define the input data and output data of each business process node according to the business logic; Based on the input data and output data of each business process node, determine the data flow direction between business process nodes; Define multiple process files according to all business process nodes and data flow directions; Use the business process engine to process all process files to obtain multiple business rules and logical relationships, and generate a dynamic process instance based on all business rules and all logical relationships to achieve the integration of all medical subsystems, where the medical subsystems include a budget management system, a cost management system, and a high-value consumables management system; Based on the process instance, generate a high-value return processing process, and determine the process processing order based on the high-value return processing process. The high-value return processing process includes n process nodes, and each process node corresponds to a front-end interface, where n is an integer greater than 1; Determine the first process node and the last process node among the n process nodes according to the process processing order; Start from the front-end interface corresponding to the first process node, execute loop steps according to the process processing order until jumping to the front-end interface corresponding to the last process node; In response to receiving an end signal from the front-end interface corresponding to the last process node, jump to a preset front-end interface.

2. The method according to claim 1, wherein Verifying the return detail list according to the UDI code includes: Parse the UDI code to obtain a product identifier and a production identifier; Match product information in a preset high-value consumables database according to the product identifier and the production identifier; Compare the product information with the return detail list, and determine that the return detail list passes the verification when the product information corresponds to the return detail list.

3. The method according to claim 2, wherein Determining whether the current business corresponding to the return application instruction starts a business process includes: Extract the key features of the product information and store the key features in a preset structured data structure; Traverse the structured data structure to determine whether there are features that conform to the business process code format; If there are features that conform to the business process code format, determine that there is a business process code in the key features; Use the business flow code as the key to call the microservice module to query the corresponding business port in the cache of the electronic device. The microservice module is used to handle the mapping between the key and the business port. Send a heartbeat request to the business port. In the case of receiving a response signal returned by the business port, determine that the current business corresponding to the return application instruction starts the business flow.

4. The method according to claim 1, characterized in that Based on the process instance, generate a high-value return processing process, including: According to the business flow code, determine the target business rules and target logical relationships in the process instance; Decompose the target business rules according to the target logical relationships to obtain n process nodes, where each process node corresponds to a front-end interface; Convert each process node into an executable sub-process instance through the business flow engine; For each sub-process instance, create an associated interface component in the corresponding front-end interface; Combine all interface components through the target logical relationships to obtain a high-value return processing process; Determine the process processing order based on the high-value return processing process, including: According to the target logical relationships of the high-value return processing process, use a preset topological sorting algorithm to determine the process processing order.

5. The method according to claim 1, characterized in that The loop steps include: Starting from the first process node, use Vue.js to load the interface component of the current active node. The current active node is the process node currently operated by the user; In response to the loading signal of the interface component, communicate with the interface component through WebSocket; In response to the change signal of the interface component, determine the next interface component according to the process processing order and load the next interface component to jump to the front-end interface corresponding to the next interface component. If the front-end interface corresponding to the next interface component is the front-end interface corresponding to the final process node, end the loop steps.

6. A smart medical process management system based on cloud computing, characterized in that, Include: A first electronic device is deployed with a cloud platform, and the cloud platform is used to execute the cloud computing-based intelligent medical process management method according to any one of claims 1 to 5; n second electronic devices, and the n second electronic devices are all connected to the first electronic device, and each of the second electronic devices is deployed with a medical subsystem, where n is an integer greater than 1.

7. A cloud platform, characterized in that, The cloud platform is deployed in the first electronic device according to claim 6 and is used to execute the operation steps of any one of the above claims 1-5.

Images