CN119889624B

CN119889624B - Intelligent medical procedure management method and system based on cloud computing and cloud platform

Info

Publication number: CN119889624B
Application number: CN202510365372.2A
Authority: CN
Inventors: 毕磊; 卢云; 李静静; 鲁萍; 周兰
Original assignee: Wuhan Topyourself Informtion Technoligy Development Co ltd
Current assignee: Wuhan Topyourself Informtion Technoligy Development Co ltd
Priority date: 2025-03-26
Filing date: 2025-03-26
Publication date: 2025-07-11
Anticipated expiration: 2045-03-26
Also published as: CN119889624A

Abstract

The application discloses a cloud computing-based intelligent medical process management method, a cloud computing-based intelligent medical process management system and a cloud platform, and relates to the field of medical informatization management, wherein the method comprises the steps of receiving a return application instruction of high-value consumables, and acquiring UDI codes and a return detail list; the method comprises the steps of verifying a return list according to UDI codes, determining whether a current service corresponding to a return application instruction starts a service flow or not if the return list passes verification, creating a flow instance based on a cloud platform if the service flow is started, generating a high-value return processing flow based on the flow instance, determining a flow processing sequence based on the high-value return processing flow, determining a first flow node and a final flow node in n flow nodes according to the flow processing sequence, executing circulation steps from a front end interface corresponding to the first flow node according to the flow processing sequence, jumping to a front end interface corresponding to the final flow node, receiving an end signal of the front end interface corresponding to the final flow node, and jumping to a preset front end interface. The application can effectively improve the user experience.

Description

Intelligent medical procedure management method and system based on cloud computing and cloud platform

Technical Field

The embodiment of the application relates to the field of medical informatization management, in particular to an intelligent medical process management method and system based on cloud computing and a cloud platform.

Background

In modern medical systems, the management of high value consumables has been a complex and important issue. High value consumables generally refer to medical supplies such as artificial joints, cardiac stents, etc. that are relatively expensive, less frequently used, but are critical to medical quality and patient safety. These consumables not only directly affect the medical costs and hospital benefits, but also are closely related to the therapeutic effect and satisfaction of the patient. With the continuous progress of medical technology and the increasing demand for medical services, the use of high-value consumables is also increasing, which presents great challenges for inventory management, cost control and quality assurance in hospitals.

In this context, the return processing of high-value consumables forms a non-negligible part of the daily operations of medical institutions. Returns may occur in a variety of situations, such as product quality problems, expiration, package damage, order errors, and the like. The effective return management not only can reduce the economic loss of hospitals, but also can improve the resource utilization efficiency and ensure that patients obtain the best medical service. However, since high value consumables generally involve multiple departments and systems, such as budget management, cost management, inventory management, etc., the return process flow is often complicated and cumbersome.

In conventional medical systems, the return processing of high value consumables typically involves multiple independent systems and departments. Such systems include, but are not limited to, budget management systems, cost management systems, high value consumable management systems, finance systems, supply chain management systems, and the like. Each system has its specific functions and data structures, and there is often a lack of efficient integration and information sharing mechanisms between these systems.

At present, the high-value consumable material returning flow is that medical staff or inventory managers put forward a returning application in a high-value consumable material management system, wherein the returning application comprises product information, a returning reason and the like, a related department director checks the returning application in the system to confirm the rationality and the necessity of returning goods, a budget management system needs to adjust the budget of a related department or item according to the returning situation, a cost management system needs to recalculate the cost of the related medical service or item, and the high-value consumable material management system needs to update the inventory information to re-warehouse or mark the returned product as a state to be returned. In this process, operators are required to frequently switch between different systems, manually enter or transfer data. Due to lack of unified flow management, the order and dependency between the steps may not be clear, resulting in that an operator may encounter an obstacle at a step, requiring a return to the previous step for reprocessing.

In summary, in the existing high-value return processing flow of the medical system, each system may enter for multiple times, and sometimes entering into one flow can remind that the previous flow can be processed before the current flow is processed, or because data needs to be manually input or updated in multiple systems, data is inconsistent or wrong easily, so that multiple times of entering into the system are needed to check and correct, therefore, the working efficiency of operators is seriously reduced in the existing high-value return processing flow, and the use experience sense of the operators is affected.

Disclosure of Invention

The embodiment of the application provides a cloud computing-based intelligent medical process management method and system and a cloud platform, which are used for effectively improving the working efficiency of operators and the use experience of a medical system.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical scheme:

in a first aspect, a cloud computing-based intelligent medical procedure management method is provided, and is applied to an electronic device, wherein the electronic device is deployed with a cloud platform, and the method includes:

Responding to receiving a return application instruction of a high-value consumable, and acquiring a UDI code and a return detail list of the high-value consumable according to the return application instruction;

verifying the return detail list according to the UDI code, and determining whether a current service corresponding to the return application instruction starts a service flow or not under the condition that verification is passed;

Under the condition that the current service starts a service flow, creating a flow instance based on the cloud platform, wherein the flow instance is used for integrating a medical subsystem;

Generating a high-value goods returning processing flow based on the flow example, and determining a flow processing sequence based on the high-value goods returning processing flow, wherein the high-value goods returning processing flow comprises n flow nodes, each flow node corresponds to a front end interface, and n is an integer greater than 1;

determining a first flow node and a final flow node in n flow nodes according to the flow processing sequence;

Starting from the front-end interface corresponding to the first flow node, executing the circulation steps according to the flow processing sequence, and jumping to the front-end interface corresponding to the final flow node;

And responding to receiving an ending signal of the front-end interface corresponding to the final flow node, and jumping to a preset front-end interface.

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

Analyzing the UDI code to obtain a product identifier and a production identifier;

According to the product identifier and the production identifier, matching in a preset high-value consumable database to obtain product information;

comparing the product information with the return list, and determining that the return list passes verification if the product information corresponds to the return list.

In another possible implementation manner of the first aspect, the cloud platform includes a micro service module, and the determining whether the current service corresponding to the return application instruction starts a service flow includes:

Extracting key features of the product information, and storing the key features into a preset structured data structure;

Traversing the structured data structure to determine whether features conforming to a traffic stream code format exist;

if the characteristics conforming to the service flow code format exist, determining that the service flow codes exist in the key characteristics;

The service flow code is used as a key, the micro service module is called to inquire a corresponding service port in a cache of the electronic equipment, and the micro service module is used for processing mapping between the key and the service port;

and sending a heartbeat request to the service port, and determining a current service opening service flow corresponding to the return application instruction under the condition that a response signal returned by the service port is received.

In another possible implementation manner of the first aspect, the cloud platform further includes a service flow engine, and the creating a flow instance based on the cloud platform in a case that a current service starts a service flow includes:

under the condition that the current service starts the service flow, adopting the micro-service module to package each medical subsystem into an independent micro-service;

Based on all the micro services, adopting preset business logic to determine the data flow direction between all business process nodes and the business process nodes;

defining a plurality of flow files according to all the business flow nodes and the data flow;

And processing all the flow files by adopting the business flow engine to obtain a plurality of business rules and logic relations, and generating a dynamic flow instance based on all the business rules and all the logic relations so as to integrate all the medical subsystems, wherein the medical subsystems comprise a budget management system, a cost management system and a high-value consumable management system.

In another possible implementation manner of the first aspect, the determining, based on all the micro services, a data flow direction between all the business process nodes and the business process nodes using preset business logic includes:

All the micro services are combined and arranged by adopting preset service logic, and all service flow nodes are determined;

Mapping each business process node to a corresponding micro-service, and defining input data and output data of each business process node according to the business logic;

and determining the data flow direction between the business process nodes based on the input data and the output data of each business process node.

In another possible implementation manner of the first aspect, the combining and arranging all the micro services with preset service logic, determining all the service flow nodes includes:

analyzing the service logic to obtain service steps and decision points;

determining calling sequence and dependency relationship among all the micro services according to the service steps;

and combining and arranging all the micro services according to the calling sequence and the dependency relationship among all the micro services, and determining all the business flow nodes according to the decision point.

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

Determining a target business rule and a target logic relationship in the flow instance according to the business flow code;

Decomposing the target business rule according to the target logic relationship to obtain n flow nodes, wherein each flow node corresponds to one front-end interface;

converting each of the process nodes into an executable sub-process instance by the traffic flow engine;

For each sub-flow instance, creating an interface component associated therewith in the corresponding front-end interface;

and combining all the interface components through the target logic relationship to obtain a high-value return processing flow.

The determining a flow processing sequence based on the high-value return processing flow comprises the following steps:

And determining a flow processing sequence by adopting a preset topology ordering algorithm according to the target logic relation of the high-value return processing flow.

In another possible implementation manner of the first aspect, the cycling step includes:

starting from the first flow node, loading an interface component of a current active node by using Vue. Js, wherein the current active node is a flow node currently operated by a user;

responding to a loading signal of an interface component, and communicating with the interface component through a WebSocket;

and responding to a change signal of the interface components, determining the next interface component according to the flow processing sequence, loading the next interface component, and jumping to a 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 flow node, the circulation step is ended.

In a second aspect, the present application provides a cloud computing-based intelligent medical procedure management method system, including:

the intelligent medical procedure management method based on cloud computing comprises the steps that a cloud platform is deployed on first electronic equipment and is used for executing the intelligent medical procedure management method based on cloud computing;

And n second electronic devices, wherein n second electronic devices are connected with the first electronic device, each second electronic device is provided with a medical subsystem, and n is an integer greater than 1.

In a third aspect, the present application provides a cloud platform, where the cloud platform is deployed in a first electronic device, and is configured to execute the operation steps of the intelligent medical procedure management method based on cloud computing.

Through the technical scheme, a unified flow example is created through the cloud platform, so that integration of a budget management system, a cost management system and a high-value consumable management system is realized, information islands among medical subsystems are broken, and the problem that different systems need to be frequently switched in the traditional flow is solved. Secondly, the return detail list is verified through the UDI code, so that the accuracy and consistency of data are ensured, and the condition that the data are wrong and need to enter the system for checking and correcting for many times is reduced. The high-value return processing flow comprises n flow nodes, each node corresponds to a front end interface, the operation flow is greatly simplified, and the whole return processing process is clearer. By determining the flow processing sequence and defining the first flow node and the final flow node, the problem that the sequence and the dependency relationship of each step in the traditional flow are not clear is solved, and the situation that an operator encounters an obstacle in a certain step and needs to return to the previous step for reprocessing is avoided. Starting from the first flow node, the circulation steps are executed according to a preset sequence until the final flow node, and the procedural processing mode greatly improves the continuity and efficiency of operation. In conclusion, the technical scheme not only improves the operation efficiency and reduces the risk of operation errors, but also greatly reduces the return processing delay, thereby improving the operation efficiency and economic benefit of hospitals. Meanwhile, because the operation is smoother, unnecessary repeated operation and system switching are reduced, the working pressure and fatigue of staff are also reduced, and the working satisfaction is improved. Therefore, by introducing the intelligent medical procedure management method based on cloud computing, a plurality of problems existing in the existing medical subsystem high-value consumable return processing procedure can be effectively solved, and the overall operation efficiency and the user experience are remarkably improved.

Additional features and advantages of embodiments of the application will be set forth in the detailed description which follows.

Drawings

Fig. 1 is a flow diagram of an intelligent medical flow management method based on cloud computing according to an embodiment of the present application;

Fig. 2 is a schematic diagram of a cloud platform according to an embodiment of the present application;

Fig. 3 is a schematic structural diagram of an intelligent medical procedure management system based on cloud computing according to an embodiment of the present application.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it should be understood that the detailed description described herein is merely for illustrating and explaining the embodiments of the present application, and is not intended to limit the embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

It should be noted that, if directional indications (such as up, down, left, right, front, and rear are referred to in the embodiments of the present application), the directional indications are merely used to explain the relative positional relationship, movement conditions, and the like between the components in a specific posture (as shown in the drawings), and if the specific posture is changed, the directional indications are correspondingly changed.

In addition, if there is a description of "first", "second", etc. in the embodiments of the present application, the description of "first", "second", etc. is for descriptive purposes only and is not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions of the embodiments may be combined with each other, but it is necessary to base that the technical solutions can be realized by those skilled in the art, and when the technical solutions are contradictory or cannot be realized, the combination of the technical solutions should be considered to be absent and not within the scope of protection claimed in the present application.

Fig. 1 schematically shows a flow diagram of a cloud computing-based intelligent medical flow management method according to an embodiment of the application. As shown in fig. 1, an embodiment of the present application provides a cloud computing-based intelligent medical procedure management method, which is applied to an electronic device, where the electronic device is deployed with a cloud platform, and the method may include the following steps.

S110, responding to a received return application instruction of the high-value consumable, and acquiring a UDI code and a return detail list of the high-value consumable according to the return application instruction;

S120, verifying the returned goods list according to the UDI code, and determining whether a current service corresponding to the returned goods application instruction starts a service flow or not under the condition that verification is passed;

S130, under the condition that a service flow is started by a current service, creating a flow instance based on a cloud platform, wherein the flow instance is used for integrating a medical subsystem, and the medical subsystem comprises a budget management system, a cost management system and a high-value consumable management system;

S140, generating a high-value goods returning processing flow based on a flow instance, and determining a flow processing sequence based on the high-value goods returning processing flow, wherein the high-value goods returning processing flow comprises n flow nodes, each flow node corresponds to a front end interface, and n is an integer greater than 1;

S150, determining a first flow node and a final flow node in n flow nodes according to the flow processing sequence;

S160, starting from a front end interface corresponding to the first flow node, executing the circulation steps according to the flow processing sequence, and jumping to a front end interface corresponding to the last flow node;

S170, responding to receiving an end signal of the front end interface corresponding to the final flow node, and jumping to a preset front end interface.

In this embodiment, the electronic device may be a device with a processor, such as a tablet computer, desktop, laptop, handheld computer, wearable device, notebook computer, ultra-mobilepersonalcomputer, UMPC, or netbook. Of course, the electronic device may also be a server. The embodiment of the application does not limit the specific form of the electronic equipment.

And responding to the received return application instruction of the high-value consumable, and acquiring the UDI code and the return list of the high-value consumable according to the return application instruction. In this embodiment, the user interface of the electronic device may receive a return application instruction input by the user, where the instruction includes basic information of a return, such as a return reason, a return number, and the like. After receiving the instruction, automatically analyzing the instruction content, and extracting a unique equipment identifier (UDI code) and a return list of the high-value consumable. The UDI code is an internationally universal unique identification code for medical devices, comprising a product identifier and a production identifier, capable of uniquely identifying each medical device. The return details list contains detailed information of the returned goods, such as the goods name, specification, quantity, lot number, etc. In the implementation, firstly, a high-value consumable management database is accessed, and corresponding high-value consumable records are inquired and matched according to the UDI code and information in a returned detail list. The user can fill in the return information through the return application form interface and submit the return information. The background program receives the form data, parses the UDI code and the return details, and then compares with records in the database.

And verifying the returned detail list according to the UDI code, and determining whether the current service corresponding to the returned application instruction starts the service flow or not under the condition that the verification is passed, so that the UDI code is used as a unique identifier to comprehensively verify the returned detail list. The verification process includes checking validity of the UDI code, comparing the UDI code to information in the return details, verifying whether the return quantity exceeds the original purchase quantity, and the like. In this embodiment, the UDI code parsing module is first invoked to decompose the UDI code into a product identifier and a production identifier, and then matches with records in the high-value consumable database. And meanwhile, checking each item of information in the return detail list to ensure that the information accords with the product information corresponding to the UDI code. After the verification is passed, whether the current service corresponding to the return application instruction starts the service flow or not can be determined. In implementations, the UDI code may be parsed first, and then each item of information in the return list is compared one by one. If any inconsistency is found, the user is immediately marked and prompted to make corrections. And for the verification passing condition, a preset business rule base can be queried, and whether a specific business process needs to be started or not is determined according to the characteristics of the current return application so as to ensure the accuracy and consistency of return information and prevent the return processing problem caused by information errors. Meanwhile, by intelligently judging whether to start the business process, corresponding processing modes can be adopted for different types of return applications, so that the flexibility and the efficiency of return processing are improved.

Under the condition that the current business starts the business flow, a flow instance is created based on the cloud platform, wherein the flow instance is used for integrating a medical subsystem, and the medical subsystem comprises a budget management system, a cost management system and a high-value consumable management system. A dynamic flow instance may be built using the cloud platform. The process example serves as a middle layer, and an original independent budget management system, a cost management system and a high-value consumable management system are integrated. The creation process of the flow instance firstly involves the definition and encapsulation of each subsystem interface, ensuring that data can be smoothly transmitted between different systems. The flow nodes and data flow direction are then determined according to predefined business logic. Each flow node corresponds to a particular business operation, such as budget checks, cost accounting, inventory updating, etc. The distributed computing and storage capacity of the cloud platform enables the process instance to efficiently process a large number of concurrent requests and achieve real-time synchronization of data. In specific implementation, a micro-service architecture can be adopted, each subsystem is packaged into independent service, and unified management and calling are carried out through an API gateway. The process instances may be implemented using a workflow engine that is capable of defining a process file and managing the process instances to enable seamless integration of multiple medical subsystems so that operations involved in the high value consumable return processing can be completed on a unified platform. The method not only improves the consistency and the instantaneity of the data, but also effectively simplifies the operation flow and reduces the time loss and the potential error caused by the system switching. Meanwhile, the implementation mode based on the cloud platform can easily cope with the increase of the traffic and the addition of new functions.

Based on the flow example, a high-value goods returning processing flow is generated, and a flow processing sequence is determined based on the high-value goods returning processing flow, wherein the high-value goods returning processing flow comprises n flow nodes, each flow node corresponds to a front-end interface, and n is an integer greater than 1. The present embodiment may translate an abstract flow instance into a concrete, operational high-value return processing flow. Specifically, a high-value return processing flow including a plurality of flow nodes may be dynamically generated according to the business rules and the logic relationships defined in the flow instance. Each process node represents a specific step or decision point in the high value return processing process, such as return application audit, inventory verification, financial processing, etc. The connection relationship between the flow nodes determines the processing sequence of the flow, including logic such as sequential execution, parallel execution, or conditional branching. Specifically, each flow node may be assigned a unique identifier and associated with a corresponding front-end interface. The front-end interface is a window for a user to interact with the system, and embodiments may employ a workflow engine to manage the generation and execution of the flow. For example, a flow may be defined using BPMN (business flow instance and notation) and then converted to an executable flow instance by a workflow engine. For the front-end interface, a modular development mode can be adopted, and an independent interface module is created for each flow node, and can be dynamically combined and displayed according to the needs of the flow. The determination of the flow processing sequence can be realized through a topological sorting algorithm, so that the follow-up nodes are executed after all the preconditions are met. Finally, a structured and visualized high-value return processing flow is generated, so that the complex return processing flow becomes clear and controllable. The front-end interface corresponding to each flow node provides an intuitive operation entrance, and operators can clearly know the current flow stage and the operation to be executed. Not only standardized returns processing flow, reduced human error, but also improved transparency and traceability of the whole process, and is favorable for subsequent audit and optimization.

And determining a first flow node and a final flow node in the n flow nodes according to the flow processing sequence. In the present embodiment, the start point (first flow node) and the end point (final flow node) of the entire flow can be identified and determined by analyzing the connection relationship between the structure of the flow chart and the nodes based on the generated high-value return processing flow. The first flow node is an entry of a high-value return processing flow and can be a submitting or preliminary auditing link of a return application. The final flow node represents the final state of the whole processing process, such as return completion, refund check-out or related document archiving. The process of determining these two key nodes involves a path analysis algorithm in graph theory. Specifically, a directed graph may be constructed, where each flow node serves as a vertex in the graph, and the connection between the nodes serves as a directed edge. Then, by a depth-first search or breadth-first search algorithm, the vertex without the incoming edge is found out to be used as a first flow node, and the vertex without the outgoing edge is found out to be used as a final flow node. By explicit head-to-tail nodes, the lifecycle of the flow instance, e.g., when to create a new flow instance, and when to end and archive the completed flow, can be better managed. The method improves the accuracy and efficiency of flow management, and simultaneously provides a basis for optimization and analysis of the flow.

Starting from the front-end interface corresponding to the first flow node, executing the circulation steps according to the flow processing sequence, and jumping to the front-end interface corresponding to the final flow node. Each process node may be activated one by one and a corresponding front-end interface presented according to a predetermined path based on the previously determined process sequence. The process is dynamic and interactive, and the process node to be activated next can be determined according to the operation and input of the user. The execution of each flow node involves the background processing of data verification, business rule checking, database operations, etc., while requiring the user to provide the necessary information or make decisions via the front-end interface. In implementations, the state of a currently active node may be maintained and the next node to be activated may be determined based on conditions and rules in the flow definition. The process may continue all the way to the final flow node. A state machine model may be employed to manage execution of the flow. Each flow node may be considered a state, and transitions between nodes correspond to changes in state. The watcher mode or the publish-subscribe mode is used to handle inter-node communications and state changes. The switching of the front-end interface can be realized by a Single Page Application (SPA) technology, for example, a vue.js framework is used, and corresponding interface components are dynamically loaded according to the current active node. The background uses technologies such as WebSocket and the like to communicate with the front end in real time, so that the synchronization of data and the continuity of flow are ensured, and a smooth and visual return processing experience is provided for users. The user can clearly see the current flow stage and complete all necessary operations through a unified interface. The system can automatically guide the user to complete each operation, and reduces the possibility of operation errors and omission. Meanwhile, the transparency and the controllability of the whole processing process are improved, and a manager can know the processing progress and the state of any return application at any time. In addition, the whole process is systematic and standardized, so that the subsequent data analysis and flow optimization are facilitated.

And responding to receiving an end signal of the front-end interface corresponding to the final flow node, and jumping to a preset front-end interface. After the entire high value return process flow is completed, an explicit end mechanism and subsequent guidelines are required. When the user completes the last operation on the front-end interface corresponding to the end flow node and triggers the end signal, the signal is captured, and then a series of end operations are executed. The end operations may include final validation and submission of data, updating of relevant system states, generation of process reports, and the like. After the above operation is completed, the user interface can be automatically jumped to a predefined front-end interface, which can be a summary page, displaying the result and key information of the whole return processing, or a main page of the cloud platform, to guide the user to start a new operation. In implementations, an event listening mechanism may be used at the front end to listen for a particular operation (e.g., clicking a "done" button) by the user on the end flow node interface. When this operation is detected, the front end sends an end signal to the background. After receiving the signal, the background triggers an ending process flow to execute necessary data processing and status updating. After completion, the background will send a jump instruction to the front end, including the URL or routing information of the target page. After the front end receives the instruction, the user is guided to a preset front end interface by using a route navigation or page redirection mode.

According to the embodiment, a unified flow instance is created through the cloud platform, so that integration of a budget management system, a cost management system and a high-value consumable management system is realized, information islands among the systems are broken, and the problem that different systems need to be frequently switched in the traditional flow is solved. Secondly, the return detail list is verified through the UDI code, so that the accuracy and consistency of data are ensured, and the condition that the data are wrong and need to enter the system for checking and correcting for many times is reduced. The high-value return processing flow comprises n flow nodes, each node corresponds to a front end interface, the operation flow is greatly simplified, and the whole return processing process is clearer. By determining the flow processing sequence and defining the first flow node and the final flow node, the problem that the sequence and the dependency relationship of each step in the traditional flow are not clear is solved, and the situation that an operator encounters an obstacle in a certain step and needs to return to the previous step for reprocessing is avoided. Starting from the first flow node, the circulation steps are executed according to a preset sequence until the final flow node, and the procedural processing mode greatly improves the continuity and efficiency of operation. In conclusion, the technical scheme not only improves the operation efficiency and reduces the risk of operation errors, but also greatly reduces the return processing delay, thereby improving the operation efficiency and economic benefit of hospitals. Meanwhile, because the operation is smoother, unnecessary repeated operation and system switching are reduced, the working pressure and fatigue of staff are also reduced, and the working satisfaction is improved. Therefore, by introducing the intelligent medical procedure management method based on cloud computing, a plurality of problems existing in the existing medical subsystem high-value consumable return processing procedure can be effectively solved, and the overall operation efficiency and the user experience are remarkably improved.

In one implementation of this embodiment, verifying the return list according to the UDI code includes the steps of:

s210, analyzing the UDI code to obtain a product identifier and a production identifier;

S220, matching in a preset high-value consumable database according to the product identifier and the production identifier to obtain product information;

S230, comparing the product information with the return list, and determining that the return list passes verification when the product information corresponds to the return list.

UDI codes, collectively referred to as unique device identification codes, are a complex string of characters that contains a product identifier and a production identifier. The parsing process first needs to identify the coding format of UDI codes, and common standards are GS1, HIBCC, ICCBBA, and the like. Taking the GS1 standard as an example, UDI codes are typically composed of an Application Identifier (AI) and a data field. The product identifier portion contains a global trade item code (GTIN), and the production identifier portion contains information such as lot number, serial number, date of production, etc. In parsing, the UDI code is first split into a number of data segments by a specific separator (e.g., brackets or special characters). The meaning of each data segment is then identified according to a predefined data structure template. For example, in the UDI code "(01) 47964367965424 (17) 220531 (10) a213B4", the 14 digits following "(01)" are GTIN, i.e., the product identifier, the 6 digits following "(17)" are the expiration date, and the alphanumeric combination following "(10)" is the lot number, which together constitute the product identifier.

And according to the product identifier and the production identifier obtained by analysis, matching is carried out in a preset high-value consumable database. In this embodiment, a database is preset for storing high-value consumable information. The database is a hybrid architecture of a relational database (such as MySQL) and a non-relational database (such as MongoDB) so as to consider query efficiency and data flexibility. In the query process, an exact match is first made in the database using the product identifier (e.g., GTIN) as the primary key. If a corresponding record is found, the information in the production identifier (e.g., lot number, date of production) is further used for secondary screening. Fuzzy matching algorithms may be used because there may be subtle differences in the format of the production identifier. For example, for lot number "A213B4", variations of "a213B4", "A-213-B4", etc. are considered. In actual operation, queries may be performed using SQL statements in conjunction with regular expressions. If no matching record is found in the master database, the history database or an external data source may be queried. Finally, the product information obtained by matching should include detailed information such as complete product name, specification, manufacturer, approval document, etc., and provide comprehensive reference data for subsequent return detail verification.

Comparing product information with a return list, first, defining key fields for comparison, including product name, specification and model, production lot number, date of production, validity period, etc. The comparison process adopts a field-by-field matching mode, and in this embodiment, consistency of the data format also needs to be considered. For example, the product name may have synonyms or abbreviations, and similarity may be calculated using a word vector model. For numeric fields, such as specifications, units are normalized and then compared. In addition, the present embodiment also needs to check the quantity information to ensure that the return quantity does not exceed the original purchase quantity. If all the key information can be corresponding and the quantity is reasonable, confirming that the return list passes verification.

According to the embodiment, the UDI code is adopted to verify the returned goods list, so that the inventory management efficiency of the medical institution can be effectively improved. Through accurate product identification and information matching, problem batches can be rapidly positioned, and quality tracing and risk management are facilitated.

In one implementation manner of the embodiment, the cloud platform includes a micro service module, and determines whether a current service corresponding to a return application instruction starts a service flow, including the following steps:

s310, extracting key features of product information, and storing the key features into a preset structured data structure;

s320, traversing the structured data structure to determine whether features conforming to the code format of the service flow exist;

s330, if the characteristics conforming to the service flow code format exist, determining that the service flow codes exist in the key characteristics;

s340, taking the service flow code as a key, calling a micro service module to inquire a corresponding service port in a cache of the electronic equipment, wherein the micro service module is used for processing mapping between the key and the service port;

S350, sending a heartbeat request to the service port, and determining a current service opening service flow corresponding to the return application instruction under the condition that a response signal returned by the service port is received.

The key features of the product information are firstly extracted and stored in a preset structured data structure, and the key features can comprise unique identifiers (such as UDI codes or internal codes) of the products, product names, specification models, production lot numbers, production dates, validity periods, manufacturers and other core information. Feature extraction may use Natural Language Processing (NLP) techniques, such as Named Entity Recognition (NER), to identify and extract these features from unstructured text. After the extraction is completed, the features are stored in a preset structured data structure. A structured data structure refers to a data structure, such as a hash table, B-tree, or relational database table, that is capable of efficiently organizing and quickly retrieving data. The structured storage is not only convenient for subsequent data processing and retrieval, but also ensures the consistency and the integrity of the data.

Traversing the structured data structure determines whether features exist that conform to the traffic stream code format. Specifically, the service flow code is a character string with a specific format, and is used for identifying and triggering a specific service flow. For example, if the traffic flow code is "BF-RTN-001", where "BF" indicates a traffic flow, "RTN" indicates a return flow, and "001" is a specific number of the flow. The traversal process first defines a regular expression to match the format. Each field stored in the structured data structure is then traversed and matched. If a character string conforming to the format is found in any field, the character string is marked as a found service flow code, so that key service flow information is effectively extracted from complex product information, and necessary guidance is provided for subsequent flow processing.

When features conforming to the traffic stream code format are found while traversing the structured data structure, it is determined that traffic stream codes exist in the key features.

And taking the service flow code as a key, and calling the micro-service module to inquire a corresponding service port in the cache of the electronic equipment. In particular, the traffic codes are used as keys to find the corresponding traffic ports. "traffic port" generally refers to a network address and port number of a microservice instance that provides a particular traffic service. The micro service module is a service registration center and is responsible for maintaining the mapping relation between keys (service stream codes) and service ports. The mapping relation is stored in a cache of the electronic equipment, so that the query efficiency is improved. The cache may be implemented using an in-memory database (e.g., redis) or a distributed cache system. The query process comprises the steps that firstly, a micro service module receives a query request containing a service flow code, then, service port information corresponding to the code is searched in a cache, if the service port information is found, the port information is returned, and if the service port information is not found, a back-end database is queried or a service discovery mechanism is triggered, finally, decoupling between the service flow and a specific service instance can be achieved, and the flexibility and the expandability of the system are improved.

Sending a heartbeat request to a traffic port and acknowledging the response is a service availability verification procedure to ensure that the found traffic port is active and able to process the request normally. The heartbeat request is a lightweight POST request sent to a particular URL path of the traffic port. The request does not contain specific traffic data and is used only to check if the service is online and in response. When sending heartbeat requests, an appropriate timeout period, typically between 100-500 milliseconds, needs to be set to balance the effects of response speed and 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 similar normal status indication, it can be confirmed that the traffic port is active and the current traffic has started the traffic flow. If no response is received or the response state is abnormal, error processing is needed, the retry can be performed, and after the retry is performed for a preset number of times, the service unavailability is reported to the upper layer. Specifically, if three consecutive heartbeat requests fail, the service instance is marked as unavailable and temporarily removed from the available list.

The embodiment realizes the accurate positioning and verification from the original data to the specific service instance, remarkably improves the automation degree and the processing efficiency, and can rapidly and accurately route the return application instruction to the correct business processing flow. Meanwhile, through the micro-service architecture and heartbeat detection, the expandability and the reliability are enhanced. Not only is the management of complex business processes simplified, but also a foundation is provided for dynamic service scheduling and load balancing, so that the high-value return processing process is more flexible, efficient and stable.

In one implementation manner of the embodiment, the cloud platform further includes a service flow engine, and when the current service starts a service flow, a flow instance is created based on the cloud platform, including the following steps:

s410, under the condition that the current service starts the service flow, packaging each medical subsystem into an independent micro service by adopting a micro service module;

S420, based on all micro services, adopting preset business logic to determine all business process nodes and data flow directions among the business process nodes;

S430, defining a plurality of flow files according to all the business flow nodes and the data flow;

S440, processing all flow files by adopting a business flow engine to obtain a plurality of business rules and logic relations, and generating a dynamic flow instance based on all business rules and all logic relations to realize integration of all medical subsystems, wherein the medical subsystems comprise a budget management system, a cost management system and a high-value consumable management system.

Under the condition that the current service starts the service flow, each medical subsystem is packaged into an independent micro-service by adopting a micro-service module so as to convert the medical subsystem which can be originally in a single architecture or tightly coupled into a loosely coupled and independently deployed micro-service. First, functional analysis and boundary division are performed for each medical subsystem (budget management system, cost management system, high-value consumable management system). Specifically, the core function and the external interface of each system may be identified. For example, the budget management system comprises functional modules such as budget planning, budget adjustment, budget execution tracking and the like. Next, a micro-service interface is determined for each identified functional module, and then the existing code is reconstructed, encapsulating each functional module into a separate service container, such as a Docker container. The code which originally directly accesses the database can be changed to operate through a unified data access layer, and the configuration such as the database connection information and the like is extracted into the environment variable or the configuration file. In addition, asynchronous communications may be implemented using message queues. Finally, basic functions such as health checking, logging, monitoring, etc. are implemented for each micro-service to ensure its manageability and observability in a distributed environment. Finally, the original tightly coupled system becomes more modularized and expandable, each micro service can be independently developed, tested and deployed, and the flexibility and maintainability are greatly improved.

Based on all micro services, a preset business logic is adopted to determine all business process nodes and data flow directions between the business process nodes so as to convert abstract business requirements into specific 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 involved nodes may include return application submission, budget impact assessment, cost accounting, inventory updating, financial processing, and the like. Each node corresponds to a call to one or more micro services. Next, logical relationships and data flow between nodes are defined. For example, after the return application is submitted, the budget impact assessment and cost accounting need to be triggered simultaneously, and the two nodes may execute in parallel, while inventory updating must be performed after the cost accounting is completed, which is a serial relationship. The definition of the data flow direction includes determining the input and output data for each node. For example, the output of the return application node (e.g., return merchandise information, quantity, amount) will be input to the budget assessment and cost accounting node. In actual implementation, these nodes and relationships may be visualized using a business process modeling tool (e.g., BPMN 2.0). Finally, these definitions are converted into a format that can be understood and executed by the traffic engine, typically an XML or JSON formatted configuration file.

Defining a plurality of flow files according to all business flow nodes and data flow directions is a process of converting abstract flows into specific executable files to convert the business flow nodes and data flow directions determined in S420 into standardized file formats that can be parsed and executed by the business flow engine. Typically, the executable file is in XML or JSON format, following a particular business process definition language (e.g., BPEL, XPDL, or custom DSL). First, a separate flow file is created for each primary business process. For example, there may be one main flow file describing the entire return flow, and multiple sub-flow files each describing specific links such as budget assessment, cost accounting, etc. When creating these files, basic information defining the flow, such as metadata of the flow ID, version number, creation time, and the like, is required. Next, each business process node needs to be converted into a specific element in the process file. Taking the XML format as an example, a node is defined as id= "submitRefundRequest", name= "submit return application", SERVICETASK IMPLEMENTATION = "refunded service. Subtrequest", outlining > flow1.

The id and name attributes are used for uniquely identifying and describing the node, the SERVICETASK element designates the micro-service call corresponding to the node, and the outing element defines the data flow direction. Then, connections and data flows between nodes need to be defined. This is achieved by id= "flow1", sourceRef = "submitRefundRequest", TARGETREF = "budgetAssessment". This means that data flows from the "submit return application" node to the "budget assessment" node.

And finally, processing all flow files by adopting a service flow engine to obtain a plurality of service rules and logic relations, and generating a dynamic flow instance based on all the service rules and logic relations. Specifically, first, the traffic flow engine loads and parses all the flow files defined in S430. The parsing process includes verifying the grammar correctness of the file, checking the integrity of the nodes and connections, parsing the attributes and configurations of the various elements. In the parsing process, the engine builds a flow model in memory, which reflects the structure and attributes of the flow.

Next, the engine needs to extract business rules and logical relationships from the parsed flow model. Business rules include conditional branching, data validation rules, rights checking, etc. For example, one business rule extracted by the engine may be that when the budget is sufficient (equal to or greater than the refund amount), the flow goes to the refund approval link. Logical relationships describe the execution order and dependencies among nodes, including serial, parallel, conditional branches, etc.

After extracting rules and relationships, the engine needs to translate these abstract definitions into executable code or instructions. A memory data structure containing all business rules and relationships may be constructed. Finally, based on the business rules and the logical relationships, the engine creates a dynamic flow instance. This example is a runtime representation of the flow definition, containing information about the state of the current flow, the nodes that have been executed, the nodes that are to be executed, etc. During the instantiation process, the engine needs to initialize the flow variables, set the initial state, and be ready to execute the first node. The embodiment can convert static flow definition into executable and dynamic flow examples, and realizes integration of medical subsystems. In this way, different subsystems (such as budget management, cost management and high-value consumable management) can work cooperatively under a unified flow frame, so that the flexibility and efficiency of the whole system are improved.

The present embodiment achieves a high degree of modularity and scalability by encapsulating the medical subsystem as a micro-service. The service flow nodes and the data flow based on the micro-service architecture design provide clear structures and logic frameworks for complex medical service flows. The business process nodes and the data flow direction are converted into standardized process files, so that the readability and maintainability of process definition are improved, and a uniform interface is provided for integration among different systems. Finally, the dynamic and flexible flow execution is realized through the processing and instantiation of the files by the service flow engine. The adaptability and the response speed of the system are greatly improved, complex demand changes in the medical industry can be rapidly dealt with, meanwhile, high-efficiency coordination among different subsystems is guaranteed, and a comprehensive and high-efficiency business process management solution is provided for medical institutions.

In one implementation manner of the embodiment, based on all micro services, a preset business logic is adopted to determine data flow directions between all business process nodes and the business process nodes, and the method includes the following steps:

s510, combining and arranging all micro services by adopting preset business logic, and determining all business process nodes;

S520, mapping each business process node to a corresponding micro service, and defining input data and output data of each business process node according to business logic;

S530, determining the data flow direction between the business process nodes based on the input data and the output data of each business process node.

In this embodiment, all the micro services are first combined and arranged by using preset service logic, and all the service flow nodes are determined. Specifically, preset business logic can be deeply analyzed, and the business logic can be determined through a business requirement document. Taking the medical equipment purchasing process as an example, the preset business logic can comprise a plurality of links such as demand report, budget audit, supplier selection, contract signing, payment processing and the like. These business logic are then matched to the encapsulated microservices. For example, a budget audit link corresponds to a micro-service of a budget management system.

In combining and orchestrating micro-services, dependencies, execution order, and parallelism possibilities between micro-services need to be considered. For example, a budget audit must be performed after a demand report, while a vendor qualification audit may be performed in parallel with the budget audit. In actual practice, a workflow modeling tool (e.g., BPMN 2.0 editor) may be used to visualize the orchestration process, creating a preliminary flow chart.

The business process node is determined to be the result of the orchestration process. Each node represents an independent business step, typically corresponding to the invocation of one or more micro-services. For example, a "budget audit" node includes a plurality of micro-service calls to query budget information, calculate available budgets, update budget status, and the like. In defining nodes, it is necessary to clarify the responsibilities, execution conditions, and completion criteria of each node.

And mapping each business process node to a corresponding micro-service, defining input data and output data of each business process node according to business logic to establish clear association between the business process node and specific micro-service realization, and defining how data flows among the nodes. First, the functional requirements of each business process node are analyzed to determine the micro-services they need to invoke. For example, a "budget audit" node needs to invoke a micro-service of the budget management system to check available budgets, update budget status, etc. This mapping process may be one-to-one (one node corresponds to one micro-service) or one-to-many (one node needs to invoke multiple micro-services). The application is not limited in this regard.

In actual operation, a mapping table or configuration file may be created, and the correspondence between each node and the micro-service is recorded in detail. For example:

Node name budget auditing

Corresponding microservices:

Service name BudgetCheckService

Method checkBudget

Service name BudgetUpdateService

Method updateBudgetStatus

Next, input data and output data are defined for each node. Input data is information required for node execution, output from upstream nodes or external input. The output data is the result of the node execution and is passed to downstream nodes or as the final output of the process. For example, the input data of the budget auditing node comprises a purchase application ID, a request amount and a department number, and the output data comprises auditing results (passing/rejecting), available budget amount and auditing opinion.

And finally, determining the data flow direction between the business process nodes based on the input data and the output data of each business process node so as to establish a complete end-to-end data flow diagram for describing the transmission of the data in the whole business process. First, the output of each node is matched to the inputs of other nodes. An initial data flow graph may be created with nodes connected by arrows, with the transferred data items marked on the arrows. A flow chart tool (e.g., visio or draw. Io) may be used for rendering.

In practice, a data flow matrix may be used to detail data transfer between nodes. The rows of the matrix represent the data provider (source node), the columns represent the data consumer (destination node), and the intersecting cells are filled with the transferred data items.

In the embodiment, by adopting the preset business logic combination and arrangement micro-service, clear business process nodes are determined, and a structured framework is provided for the whole process. Each node is mapped to a specific micro-service and input and output data of the node are defined, so that not only is the tight combination of business logic and technical realization realized, but also an explicit interface definition is provided for data transfer. And finally, the whole process is connected in series to form a whole by determining the data flow direction among the nodes, so that smooth transmission and correct conversion of the data in the whole service process are ensured. The flexibility and maintainability of the system are greatly improved, so that complex medical service flows can be realized in a modularized and extensible mode. Meanwhile, a solid foundation is provided for system integration, exception handling and flow optimization, changes of service requirements can be responded quickly, and overall operation efficiency is improved.

In one implementation manner of this embodiment, all the micro services are combined and arranged by using preset business logic, and all the business process nodes are determined, including the following steps:

s610, analyzing service logic to obtain service steps and decision points;

s620, determining calling sequence and dependency relationship among all micro services according to the business steps;

s630, combining and arranging all the micro services according to the calling sequence and the dependency relationship among all the micro services, and determining all the business flow nodes according to the decision points.

In this embodiment, the business logic is first parsed, converting the business logic into explicit, executable business steps and decision points. In a specific implementation, key business steps and decision points can be identified by describing the main flow and the alternative flow of each use case in detail. For example, a "budget review" use case includes the steps of 1. Receiving a purchase request, 2. Checking a department budget, 3. Deciding whether the budget is sufficient, 4. Approving the request if sufficient, 5. Refusing the request or starting a budget adjustment procedure if insufficient.

Decision points are places in the flow where different execution paths need to be selected according to specific conditions. Each decision point has an explicit condition and corresponding action.

The parsing result may be consolidated into a structured document. The method comprises a detailed step list, a decision point list, a business rule and constraint condition list and a key term vocabulary, wherein each step has clear input, processing logic and output, the decision point list comprises conditions and possible results of each decision point, and the key term vocabulary ensures that all related parties have consistent understanding of important concepts.

And determining the calling sequence and the dependency relationship among all the micro services according to the business steps. Specifically, in this embodiment, a service directory or API document is preset to describe the functions, interfaces, and data models of each micro service in detail. Each business step is mapped to one or more micro-services. When determining the calling sequence, the method can be realized through the logic sequence and the data dependency relationship of the business process. For example, a budget audit must be performed after the delivery application is submitted because it requires the data of the delivery application as input. The determination of dependencies involves not only direct call sequencing but also data dependencies and state dependencies. For example, the data dependent budget management service relies on the return amount data provided by the return application service.

And finally, combining and arranging all micro services according to the calling sequence and the dependency relationship among all the micro services, and determining all the business process nodes according to the decision points.

Specifically, a workflow engine is first used to build a complete flow orchestration model. In the orchestration process, each business step needs to be converted into a task or activity in the flow. Each task needs to be associated with a corresponding micro-service. This may be achieved by specifying a service call in the flow definition. For example, a "budget audit" task may invoke the checkBudget method of the budget management service.

The decision point appears in the flow as a Gateway (Gateway). BPMN provides multiple types of gateways such as an exclusive gateway (Exclusive Gateway), a parallel gateway (PARALLEL GATEWAY), and a inclusive gateway (Inclusive Gateway). For example, after a budget audit, an exclusive gateway may be used to decide whether to continue the flow or return the modification based on the audit results.

According to the embodiment, clear business steps and decision points are obtained by analyzing the business logic, and a structural basis is provided for the whole flow. The abstract business logic is then converted into a concrete technology implementation path by determining the calling order and dependency relationships between the micro services. Finally, by combining and orchestrating the micro-services and integrating the decision points, a complete, executable business process is created. Not only ensures the close correspondence between the technical realization and the business requirement, but also improves the flexibility and maintainability of the system.

In one implementation of the present embodiment, a high-value return processing flow is generated based on a flow instance, including the steps of:

s710, determining a target business rule and a target logic relationship in a flow instance according to the business flow code;

S720, decomposing a target business rule according to a target logic relationship to obtain n flow nodes, wherein each flow node corresponds to a front-end interface;

s730, converting each flow node into an executable sub-flow instance through a service flow engine;

s740, for each sub-flow instance, creating an interface component associated with the sub-flow instance in a corresponding front-end interface;

S750, combining all interface components through the target logic relationship to obtain a high-value return processing flow.

Firstly, determining a target business rule and a target logic relationship in a flow example according to a business flow code, so as to extract a key business rule and a logic relationship between the business rule and the logic relationship from the existing flow example, and laying a foundation for the generation of a subsequent high-value return processing flow. In this embodiment, a custom parser implementation may be used. For example, using JAXB (Java Architecture for XML Binding), the XML formatted traffic code may be parsed into Java objects for further processing and analysis. After the parsing is completed, a structured data model can be obtained that contains all nodes, conditions, and variables.

Next, target business rules may be extracted from the data model. For example, a business rule may be that "returns of high value goods (value over 1000 yuan) must go through quality inspection". This rule is embodied in the transition condition from the "return application" to the "quality check" node.

In extracting business rules, the rules may be organized and represented in a decision table or a decision tree. For example, a decision table may be created listing different returns (e.g., merchandise value, return reasons, purchase time, etc.) and corresponding process flows. At the same time, there is a need to identify target logical relationships. The target logic relationship is mainly embodied in connection and condition judgment between nodes. For example, there is a "dependency" between "return cause verification" and "quality detection", i.e. quality detection can only be performed after verification of the return cause. The logical relationships may be represented graphically, such as a flow chart or state transition diagram.

And decomposing the target business rule according to the target logic relationship to obtain n flow nodes, wherein each flow node corresponds to a front-end interface so as to split the target business rule into a series of independent but interrelated flow nodes, and each node can intuitively display and operate on the front-end interface.

First, for target business rules, the resolution based on target logical relationships requires compliance with resolution principles including, but not limited to, independence of functions, integrity of data, convenience of user interaction, and the like. For example, in a high-value return process flow, the business rule of "return application" needs to be split into a plurality of flow nodes, namely return information input, return reason selection, return voucher uploading and return address confirmation.

Each flow node has explicit inputs, processing logic, and outputs. For example, the input to 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.

In actual operation, the flow nodes and their relationships may be visualized using a flow chart or state diagram. For example, BPMN (business process model and notation) tools are used to create detailed flowcharts, each node representing a task or activity, and the links between nodes representing logical relationships.

For example, for the "return reason select" node, the front end interface may include a multi-choice list showing all possible return reasons, a text box allowing the user to enter other reasons, the "ok" and "return" buttons, and a progress indicator showing the current location throughout the process.

Each process node is converted into an executable sub-process instance by a traffic flow engine to convert the process node into a software entity that can be actually run and managed. The business flow engine can explain the flow definition, coordinate the execution of tasks, manage the flow state and process abnormal conditions. The traffic flow engine may be Activiti.

The definition of each flow node is converted into a format that the engine can understand, such as an XML file. Next, a corresponding business logic needs to be implemented for each flow node. For example, for a "return reason selection" node, the following functions may be implemented, namely loading the optional return reason from a database or profile, verifying the user's selection, updating the status of the return application based on the selected reason, and deciding the node to execute next.

The business logic described above may be implemented by writing Java classes or scripts and associating it with a flow definition.

An associated interface component is created for each sub-flow instance. The functional requirements and data interaction requirements of each sub-flow instance may be analyzed, and corresponding interface components may be designed and implemented according to the requirements. In specific implementation, a componentized development method can be adopted to package the interface elements corresponding to each sub-flow into independent components. These components may include forms, buttons, lists, dialog boxes, and the like, common user interface elements. In actual operation, these components may be built using Vue. Each component is capable of operating independently and of data interaction with backend services.

And finally, combining all the created interface components according to the target logic relationship to finally form a complete high-value return processing flow interface. In practice, the logic sequence of the entire high value return process flow needs to be first combed. The method comprises a plurality of links such as goods returning application, auditing, logistics arrangement, refund processing and the like. And determining the placement positions and the display sequence of the interface components according to the sequence and the interdependence relationship of the links. In the combination process, the consistency and intuitiveness of the operation of the user are required to be considered. For example, a step navigation bar may be used to show the progress of the entire process, allowing the user to clearly know which stage is currently in and which steps need to be completed. At the same time, attention is paid to data transfer and state synchronization between the individual components. For example, subsequent logistics arrangement components should be able to automatically retrieve and display relevant order information after the return application is approved.

To implement complex logical relationships, state management tools (e.g., vuex) are introduced to uniformly manage the states and data flows of the various components. Therefore, under a complex service scene, each component can keep the consistency and real-time performance of data.

The embodiment constructs a high-value return processing flow interface with complete functions and user friendliness. The interface can accurately reflect complex business logic, and each sub-flow has its own interface components which can not only operate independently, but also cooperate closely through carefully designed logic relationships. The final interface can adapt to different use scenes and user requirements. Through state management and a data synchronization mechanism, consistency and instantaneity of data in the whole flow are ensured, user experience is effectively improved, and meanwhile, efficiency and accuracy of return processing are improved.

In one implementation of the present embodiment, determining a flow process order based on a high-value return process flow includes the steps of:

s810, determining a flow processing sequence by adopting a preset topology ordering algorithm according to a target logic relation of the high-value return processing flow.

According to the embodiment, the high-value return processing flow can be converted into a Directed Acyclic Graph (DAG) according to the target logic relation of the high-value return processing flow, and then a reasonable processing sequence is obtained through a topological sorting algorithm.

First, each process node in the high-value return process flow (e.g., return application, audit, logistics arrangement, refund process, etc.) needs to be considered a vertex in the graph. The dependencies between these nodes are then denoted directed edges. For example, the refund process must be performed after the refund application is approved, and there will be a directed edge from the "audit" node to the "refund process" node.

After the complete directed graph is constructed, a topology ordering algorithm is applied next, and the topology ordering algorithm in this embodiment is Kahn algorithm, which basically includes the steps of 1. Find out all vertices with degree of entry 0 in the graph, and add them to a queue. These vertices represent flow nodes where processing can begin immediately. 2. When the queue is not empty, a vertex is fetched from the queue and added to the ordering result. 3. For a fetched vertex, the ingress of all its neighboring vertices is subtracted by 1. If the degree of ingress of a certain neighboring vertex becomes 0, it is added to the queue. 4. Steps 2 and 3 are repeated until the queue is empty. 5. If the final graph has vertices that are not accessed, a loop exists in the graph, i.e., there is a loop dependency in the business process, in which case special processing or error reporting is required.

The method adopts a topological sorting algorithm to determine the processing sequence of the high-value return processing flow, and provides a clear route map for the execution of the whole flow. Not only can complex business logic and dependency be accurately reflected, but also potential cyclic dependency problems can be automatically identified and solved. By converting the business flow into the directed acyclic graph and applying the topological sorting algorithm, a logic-compliant and efficient processing sequence can be obtained, complex and changeable business scenes can be adapted, parallel processing and dynamic adjustment are supported, so that the efficiency and flexibility of return processing are effectively improved, and the user experience is improved.

In one implementation of this embodiment, the cycling step includes:

s910, starting from a first flow node, loading an interface component of a current active node by using Vue. Js, wherein the current active node is a flow node currently operated by a user;

S920, responding to a loading signal of the interface component, and communicating with the interface component through a WebSocket;

s930, determining a next interface component according to the flow processing sequence in response to the change signal of the interface component, and loading the next interface component to jump to a 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 flow node, the circulation step is ended.

The Vue. Js is a JavaScript front end framework, which adopts a componentized development mode and is suitable for constructing complex Single Page Applications (SPAs). In this step, first a first flow node needs to be determined, which is typically the entry point of the entire high-value return process flow, such as the return application page.

The process of loading the component by using the Vue.js firstly comprises dynamic component loading, the Vue.js provides a component element, and dynamic rendering of the component can be realized by matching with the is attribute. In addition, vue.js supports asynchronous components, and corresponding component code is loaded when needed. This can be implemented by the defineAsyncComponent function of Vue, which accepts as parameters a factory function back to Promise. In actual implementation, a component mapping table may be created that maps the name of each flow node to the corresponding component. The corresponding component may then be obtained from this mapping table according to the name of the currently active node and rendered using the dynamic component function of Vue.

And responding to the loading signal of the interface component, and communicating with the interface component through the WebSocket. WebSocket is a protocol for full duplex communication over a single TCP connection, which provides a method for establishing a persistent connection between a client and a server, suitable for real-time interactive scenarios. In the high-value return processing flow, real-time data exchange between the server and the client can be realized by using the WebSocket, and when the interface component is loaded, the interface component sends a loading signal which triggers the establishment process of the WebSocket connection.

In this embodiment, the establishment of the WebSocket connection includes the steps of 1. The client (browser) initiates a WebSocket connection request. 2. The server receives the request and performs a handshake if WebSocket is supported. 3. After the handshake is successful, webSocket connection is established, and bidirectional communication can be performed at this time.

In the vue.js application, webSocket connections may be initialized in the mount lifecycle hooks of the components. 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 may be sent, and after the server receives the message, the server may perform corresponding processing, such as updating the flow state, preparing related data, and so on.

The real-time communication realized by the WebSocket can greatly improve the response speed and the user experience of the high-value return processing flow. For example, when an administrator reviews a return request, the electronic device may immediately push a notification to the user via WebSocket, and the user interface may update the status in real time without refreshing the page.

And responding to the change signal of the interface component, and determining and loading the next interface component according to the flow processing sequence. When the user completes the operation on the current interface and triggers the change signal, the next interface component to be displayed can be determined according to the predefined flow processing sequence, and loading and jumping can be performed.

The change signal is typically triggered by a user operation, such as submitting a form, clicking a confirm button, or the like. When the change signal is triggered, the parent component or a specialized flow control component captures the event and then determines the next component according to the flow processing order. The flow processing order previously obtained by the topology ordering algorithm may be used.

For example, a flowchart object may be maintained and then, after determining the next component based on the current component name, the dynamic component functionality of vue.js may be used to load it. This may be achieved by updating a responsive variable. By the method, dynamic circulation of the high-value return processing flow can be realized, and the whole processing process is smoother and more efficient. The user can complete all necessary steps according to a predefined flow sequence, and the system can flexibly cope with various possible situations.

The implementation mode realizes high dynamic property and interactivity through realizing the circulation step and the high-value goods return processing flow. Starting from the first flow node, the corresponding interface components can be dynamically loaded according to the operation of a user and the predefined flow sequence, and real-time communication is kept through WebSocket. Not only improving the user experience, but also greatly enhancing the flexibility and response speed of the system. The user can smoothly complete the whole return processing flow, and the system can update the state in real time, push important notices and dynamically adjust the flow according to actual conditions.

In summary, fig. 2 shows an architecture diagram of a cloud platform according to an embodiment of the present application, where, as shown in fig. 2, an architecture front end UI (user interface layer) of the cloud platform is an interface between a user and a system, and is responsible for displaying information and receiving user input.

And the interface component loads and renders the front-end interface corresponding to each flow node by using a front-end framework such as Vue. WebSocket communication is used for real-time communication between the front end and the back end, and dynamic updating and jumping of interface components are ensured. The presentation layer is used for presenting the data processed by the business logic on the front-end UI in a user-friendly mode. Front end frameworks such as vue.js are used to build dynamic, responsive user interfaces. Interface logic is used to handle user interaction logic such as loading, jumping, and changing of interface components. The business layer is responsible for processing business logic, flow control and data flow. The micro-service module may encapsulate each medical subsystem into an independent micro-service that handles specific business logic. The business flow engine is responsible for creating and managing flow instances, handling logical relationships and data flows between business flow nodes. Business rules and logical relationships define the logical relationships between the nodes and specific rules of a business process.

The database is responsible for storing, retrieving and managing data, and provides data support for the business layer, and comprises a high-value consumable database, a structured data structure and a cache. The running environment is an infrastructure for system running, provides resource support for computing, storage, networks and the like, comprises containerization technologies such as Docker, kubernetes for deploying and managing micro-service modules, and servers and network equipment for providing computing and network resources and ensuring high availability and expandability of the system.

The architecture design ensures that the system has high expandability, flexibility and maintainability, and can effectively support the requirements of intelligent medical procedure management.

The embodiment of the application also provides a cloud computing-based intelligent medical procedure management method system, as shown in fig. 3, comprising the following steps:

the first electronic device 10 is deployed with a cloud platform, and the cloud platform is used for executing the intelligent medical procedure management method based on cloud computing;

n second electronic devices 20, each second electronic device 20 is connected with the first electronic device 10, and each second electronic device 20 is provided with a medical subsystem, n is an integer greater than 1.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, etc., such as Read Only Memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises an element.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and variations of the present application will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. which come within the spirit and principles of the application are to be included in the scope of the claims of the present application.

Claims

1. A smart medical process management method based on cloud computing, characterized in that it is applied to a cloud platform, the cloud platform is deployed in an electronic device, the cloud platform includes a microservice module and a business flow engine, and the method includes:

In response to receiving a return application instruction for a high-value consumable, obtaining a UDI code and a return details list of the high-value consumable according to the return application instruction;

Verify the return details list according to the UDI code, and if the verification is successful, determine whether the current business corresponding to the return application instruction has opened the business flow;

When the current business starts the business flow, the microservice module is used to encapsulate each medical subsystem into an independent microservice;

Analyze business logic to obtain business steps and decision points;

Map each business step to one or more microservices, and determine the calling order and dependencies between all microservices based on the logical order and data dependencies of the business steps;

Combine and orchestrate all microservices according to the calling sequence and dependencies between them, and determine all business process nodes based on decision points;

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

Determine the data flow between business process nodes based on the input data and output data of each business process node;

Define multiple process files based on all business process nodes and data flows;

The business flow engine is used 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, including the budget management system, cost management system, and high-value consumables management system;

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, each process node corresponds to a front-end interface, and n is an integer greater than 1;

Determine the first process node and the last process node among n process nodes according to the process processing sequence;

Starting from the front-end interface corresponding to the first process node, execute the loop steps according to the process processing sequence until jumping to the front-end interface corresponding to the final process node;

In response to receiving an end signal of the front-end interface corresponding to the final process node, jump to the preset front-end interface.

2. The method according to claim 1, characterized in that verifying the return details list according to the UDI code comprises:

Parse the UDI code to obtain the product identifier and production identifier;

According to the product identifier and the production identifier, the product information is matched in the preset high-value consumables database;

The product information is compared with the return detail list, and when the product information corresponds to the return detail list, it is determined that the return detail list verification has passed.

3. The method according to claim 2, characterized in that determining whether the current business corresponding to the return application instruction has opened a business flow comprises:

Extract key features of product information and store the key features into a preset structured data structure;

Traverse the structured data structure to determine whether there are features that conform to the business flow code format;

If there is a feature that conforms to the business flow code format, it is determined that the business flow code exists in the key feature;

Using the business flow code as a key, the microservice module is called to query the corresponding business port in the cache of the electronic device, and the microservice module is used to process the mapping between the key and the business port;

Send a heartbeat request to the business port, and when a response signal is received from the business port, determine the current business corresponding to the return application instruction to start the business flow.

4. The method according to claim 1, characterized in that, based on the process instance, a high-value return processing process is generated, comprising:

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 relationship 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 interface component associated with it in the corresponding front-end interface;

Combine all interface components through target logical relationships to obtain a high-value return processing flow;

Determine the process sequence based on the high-value returns process, including:

According to the target logical relationship of the high-value return processing flow, a preset topological sorting algorithm is used to determine the process processing order.

5. The method according to claim 1, wherein the circulating step comprises:

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 a loading signal of the interface component, communicating with the interface component via WebSocket;

In response to the change signal of the interface component, the next interface component is determined according to the process processing order, and the next interface component is loaded 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, the loop step is ended.

6. A cloud computing-based intelligent medical process management system, characterized by comprising:

A first electronic device, deployed with a cloud platform, wherein the cloud platform is used to execute the cloud computing-based smart medical process management method according to any one of claims 1 to 5;

There are n second electronic devices, each of which is 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 described in claim 6, and is used to execute the operating steps of any method described in any one of claims 1-5 above.