Disease diagnosis and treatment path arrangement method, device, equipment and medium

Abstract

This application discloses a method, apparatus, device, and medium for orchestrating disease diagnosis and treatment pathways, relating to the field of digital healthcare technology. The method includes: constructing a node library based on acquired business scenario data from the disease diagnosis and treatment process; creating a current orchestration process and configuring a starting node for the current orchestration process in response to user orchestration operation instructions; selecting multiple treatment nodes corresponding to the business requirements information in the diagnosis and treatment business scenario from the node library, and adding each treatment node to the current orchestration process; configuring business items, process flow, and transition logic for each treatment node based on the node library; and configuring a termination node for the current orchestration process after configuring each treatment node, thereby generating a disease-specific diagnosis and treatment pathway corresponding to the business requirements information. This application can significantly shorten the iteration cycle of diagnosis and treatment pathways and further improve the efficiency of constructing and maintaining disease-specific diagnosis and treatment pathways.

Description

Technical Field

[0001] This application relates to the field of digital medical technology, and in particular to a method, apparatus, equipment and medium for arranging disease diagnosis and treatment pathways. Background Technology

[0002] With the rapid development of medical informatization, precision medicine and personalized treatment have become core trends in modern medicine. Disease treatment pathways, also known as clinical pathways, refer to a standardized treatment procedure for a specific disease. They are comprehensive models of clinical treatment, guided by evidence-based medicine and guidelines to promote treatment organization and disease management. In clinical practice, research on the design and implementation of disease treatment pathways is particularly important for standardizing medical practices, controlling medical costs, and improving the quality of care.

[0003] Currently, treatment pathways in related technologies often exist in personalized forms such as tables, documents, or static flowcharts. However, this approach lacks a unified executable expression model. The same type of disease is often repeatedly constructed in different departments, different hospital areas, and different information system versions, resulting in poor reusability of the pathways. Furthermore, the path operation logic needs to rely on solidified code implementation. However, when the path is adjusted, multiple parties need to be involved in communication, which makes the path iteration cycle long and leads to low efficiency in the construction and maintenance of treatment pathways. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, equipment, and medium for arranging disease diagnosis and treatment pathways, so as to solve the technical problem of low efficiency in the construction and maintenance of disease diagnosis and treatment pathways in traditional solutions.

[0005] To achieve the above objectives, this application provides the following solution: Firstly, this application provides a method for arranging disease diagnosis and treatment pathways, including: Based on the business scenario data acquired during the disease diagnosis and treatment process, a node library is constructed; In response to the user's orchestration operation command, create the current orchestration process and configure the starting node for the current orchestration process; Based on the business needs information in the diagnosis and treatment business scenario, select multiple processing nodes corresponding to the business needs information from the node library, and add each of the processing nodes to the current orchestration process; Based on the node library, each processing node is configured with business items, process flow, and transfer logic. Once each processing node is configured, a termination node is configured for the current orchestration process to generate the disease diagnosis and treatment path corresponding to the business requirement information.

[0006] Secondly, this application provides a device for arranging disease diagnosis and treatment pathways, the device comprising: The module is used to build a node library based on the business scenario data acquired during the disease diagnosis and treatment process; A creation module is used to respond to user orchestration operation commands, create the current orchestration process, and configure a start node for the current orchestration process; The selection module is used to select multiple processing nodes corresponding to the business needs information in the diagnosis and treatment business scenario from the node library, and add each of the processing nodes to the current orchestration process. The configuration module is used to configure business items, process flow, and transfer logic for each processing node based on the node library. The generation module is used to configure a termination node for the current orchestration process after each treatment node is configured, so as to generate the disease diagnosis and treatment path corresponding to the business requirement information.

[0007] Thirdly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the disease diagnosis and treatment pathway arrangement method described in any one of the above.

[0008] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the disease diagnosis and treatment pathway arrangement method described in any one of the above.

[0009] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides a method, apparatus, device, and medium for arranging disease diagnosis and treatment pathways. Compared with existing technologies, this solution constructs a node library based on disease diagnosis and treatment business scenario data, achieving standardized and modular encapsulation of basic functional units in the diagnosis and treatment pathway. This provides underlying data support for the unified expression and reuse of subsequent diagnosis and treatment pathways. By responding to user arrangement operation commands, it creates an arrangement process and configures starting nodes, thereby enabling visualization and process-oriented guidance of the diagnosis and treatment pathway construction process. By selecting corresponding treatment nodes from the node library based on business requirement information and adding them to the arrangement process, it fully utilizes the standardized resources of the node library, avoiding the repeated construction of similar disease-specific diagnosis and treatment pathways in different departments, hospital areas, and information systems, significantly improving efficiency. This approach enhances the reusability and standardization of treatment pathways. Furthermore, it configures business items, process flow, and workflow logic for each treatment node, transforming the traditional code-based path execution logic into a visual and configurable parameter setting method. This eliminates the need for technical personnel to implement path logic through coding, reducing communication costs and development workload for medical staff, IT personnel, and other stakeholders during path adjustment. Finally, after node configuration, a termination node is configured to generate the final disease-specific treatment pathway, forming a complete closed-loop, standardized, and executable treatment pathway model. This unifies the expression and execution specifications of treatment pathways, significantly shortening the iteration cycle and comprehensively improving the efficiency of disease treatment pathway construction and maintenance. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of the application environment for the disease diagnosis and treatment pathway arrangement method provided in one embodiment of this application; Figure 2 A flowchart illustrating a method for arranging disease diagnosis and treatment pathways according to an embodiment of this application; Figure 3 A flowchart illustrating a method for constructing a node library based on business scenario data, provided as an embodiment of this application; Figure 4 A flowchart illustrating a method for arranging disease diagnosis and treatment pathways according to an embodiment of this application; Figure 5 A flowchart illustrating a method for configuring business items, process flow, and transfer logic for each processing node, provided in an embodiment of this application; Figure 6A flowchart illustrating a method for arranging disease diagnosis and treatment pathways according to another embodiment of this application; Figure 7 A schematic diagram of the functional modules of a disease diagnosis and treatment pathway arrangement device provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] As mentioned in the background section, hospitals generate a large amount of structured and unstructured data related to diagnosis and treatment activities. These activities have gradually evolved from "fixed processes within a single system" to "complex collaborative processes across systems, multiple roles, and multiple stages." The core function of disease treatment pathways is to reduce treatment variability, optimize the allocation of medical resources, and improve the homogenization of treatment, while simultaneously ensuring efficiency and medical safety. They serve as a core carrier for modern medical quality management, medical insurance payment control, and the implementation of smart healthcare. In disease-specific treatment scenarios, common pathway components include, but are not limited to: patient enrollment, initial assessment, examination and testing, diagnosis confirmation, treatment plan selection, medication and follow-up, complication management, discharge, and rehabilitation. However, these components often involve complex flow relationships such as branching, conditional triggering, regression, and looping. Therefore, constructing effective treatment pathways is crucial for standardizing diagnosis and treatment.

[0015] Currently, the diagnostic and treatment pathway structures in related technologies often exist in personalized forms such as documents, tables, or static flowcharts, lacking a unified, executable expression model. Similar diseases are often repeatedly constructed across different departments, hospital campuses, and information system versions, resulting in poor reusability and high migration costs. Furthermore, the pathway logic is deeply bound to the code, requiring the involvement of multiple personnel from R&D and testing when adjusting the pathway, leading to long iteration cycles. It also lacks the ability to dynamically express complex clinical scenarios (precisely defining context-related steps, multi-dimensional branch judgment conditions, automatic cross-step data flow, and multi-role collaboration triggering mechanisms), and lacks logical verification and end-to-end traceability functions, making modular configuration and low-cost deployment impossible, resulting in low efficiency in diagnostic and treatment pathway construction. Moreover, related technologies struggle to express the differences in "related business items of the same node in different scenarios." For example, the same "follow-up assessment" node may require different business items (examination items, assessment scales, educational content, risk warnings, etc.) depending on different disease stages, patient stratifications, and treatment plans. Traditional static pathways cannot accurately express these differences and maintain maintainability. Furthermore, there is a lack of systematic definition of branching conditions, node interactions, and data flow: disease-specific paths are often not only sequential steps, but also involve triggering conditions between nodes, input and output data, parallel / mutually exclusive relationships, dependencies, and data flow rules. The lack of a unified model can easily lead to ambiguity, conflict, or untraceability when the path is executed or implemented.

[0016] To address the aforementioned shortcomings, this application provides a method for orchestrating disease diagnosis and treatment pathways. Compared to existing technologies, this solution constructs a node library based on disease diagnosis and treatment business scenario data, achieving standardized and modular encapsulation of basic functional units in the treatment pathway. This provides underlying data support for the unified expression and reuse of subsequent treatment pathways. By responding to user orchestration operation commands, it creates an orchestration process and configures starting nodes, thereby enabling visualization and process-oriented guidance of the treatment pathway construction process. By selecting corresponding treatment nodes from the node library based on business requirement information and adding them to the orchestration process, it fully utilizes the standardized resources of the node library, avoiding the duplication of similar disease-specific treatment pathways in different departments, hospital areas, and information systems, significantly improving the reusability and standardization of treatment pathway construction. The system then configures business items, process flow, and transfer logic for each treatment node, transforming the traditional code-based path operation logic into a visual and configurable parameter setting method. This eliminates the need for technical personnel to implement path logic through coding, reducing communication costs and development workload for medical staff, IT personnel, and other stakeholders during path adjustment. Finally, after node configuration, a termination node is configured to generate the final disease-specific treatment path, forming a complete closed-loop standardized and executable treatment path model. This unifies the expression and execution specifications of treatment paths, significantly shortening the iteration cycle of treatment paths and comprehensively improving the efficiency of disease treatment path construction and maintenance.

[0017] The method for arranging disease diagnosis and treatment pathways provided in this application embodiment can be applied to, for example... Figure 1 The application environment for the disease diagnosis and treatment pathway orchestration method shown is as follows. This application environment includes: terminal 102, server 104, and data storage system. Terminal 102 communicates with server 104 via a network. The data storage system can store acquired business scenario data. The data storage system can be set up independently, integrated into server 104, or placed in the cloud or on other servers. After acquiring the business scenario data, terminal 102 can send it to server 104. After acquiring the business scenario data, server 104 performs a node library construction operation and performs a diagnosis and treatment pathway orchestration operation based on the node library. Furthermore, in some embodiments, the disease diagnosis and treatment pathway orchestration method can also be implemented independently by server 104 or terminal 102. For example, terminal 102 can directly perform diagnosis and treatment pathway orchestration processing to form a disease-specific diagnosis and treatment pathway.

[0018] The terminal 102 can be, but is not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The server 104 can be implemented using a standalone server or a server cluster composed of multiple servers, or it can be a cloud server.

[0019] In one exemplary embodiment, such as Figure 2 As shown, a method for arranging disease diagnosis and treatment pathways is provided. This method is executed by a computer device, specifically by a terminal or server alone, or by both a terminal and a server. In this embodiment, the method is applied to... Figure 1 Taking server 104 as an example, the explanation includes the following steps S201 to S205. Wherein: Step S201: Construct a node library based on the business scenario data obtained during the disease diagnosis and treatment process.

[0020] It should be noted that the aforementioned business scenario data refers to all data involved in the diagnosis and treatment process within the context of a medical service scenario. This business scenario data can be imported from external devices, obtained from a blockchain or database, or generated custom-defined based on actual needs. This embodiment does not impose any limitations on the method of acquiring business scenario data.

[0021] Before orchestrating disease-specific treatment pathways, it is necessary to construct a node library corresponding to the treatment business scenarios by combining the business scenario data generated during the disease diagnosis and treatment process. This node library refers to a configurable asset collection formed by structurally encapsulating event types, operation nodes, and business items. The node library provides a source of candidate nodes for pathway orchestration. This node library exists in at least one of the following forms: a standardized structured database, a collection of configuration files, or a visual component library. It is used to uniformly store and manage various standardized treatment nodes and their configuration information. Specifically, it can be displayed in database form, such as node data tables stored in relational or non-relational databases; it can also be represented as a collection of structured configuration files such as XML, JSON, or YAML; it can be represented as a component library or object library; or it can be represented as a knowledge graph or rule base.

[0022] The aforementioned node library includes at least: node metadata, node version information, node business item templates, node input / output constraints, node configurable parameters, node interaction interface definitions, and constraint rules for connecting nodes. The node library supports classification and retrieval by disease, department, institution, and scenario tag.

[0023] In one embodiment, a specific implementation method for constructing a node library based on business scenario data acquired during the disease diagnosis and treatment process is also provided; please refer to [link to relevant documentation]. Figure 3 As shown, the method includes: Step S301: Conduct a systematic analysis of the business scenario data, extract all event types involved in the disease diagnosis and treatment process, and form an event type set.

[0024] Step S302: Perform business logic analysis on each event type in the event type set to determine multiple operation nodes corresponding to the event type.

[0025] Step S303: Perform business analysis on each operation node to determine the set of business items contained in the operation node.

[0026] Step S304: The event type, operation node and its associated business item set are encapsulated in a structured manner to build a node library.

[0027] Understandably, the above event types are used to characterize key business signals or scenario conditions that trigger the execution of the disease diagnosis and treatment process, and are used to drive node selection, node activation, or branch judgment in path orchestration. Event types can originate from key behaviors in the diagnosis and treatment process, such as: "baseline assessment event", "diagnosis issuance event", "document writing event", "treatment decision event", "medication follow-up event", or "other".

[0028] An operation node is a business action unit that needs to be executed under the drive of an event type, and is used to carry out a certain type of diagnosis and treatment activity or management activity. An operation node can be represented by business actions such as "issuing a diagnosis", "saving documents", "issuing medical orders", "requesting surgery", and "requesting consultation". In the orchestration process, operation nodes can be referenced, instantiated and parameterized as reusable functional components.

[0029] The business item set includes the business elements required for the operation nodes to perform processing operations; the processing operations include at least one of the following: collection, verification, display, calculation, output, and push operations; the business item set includes at least one of the following business items and corresponding metadata: data-related business items, rule-related business items, interaction-related business items, and interface-related business items; the metadata includes: business item identifier, name, description, data type, unit, coding system, data source, collection method, calculation method, visibility, editability, access control, and audit requirements.

[0030] It is understandable that the processing operations required for "issuing a diagnosis" may include "admission diagnosis, preliminary diagnosis, and revised diagnosis," etc.; "saving documents" may include "admission records, progress notes, and discharge records," etc.; and "issuing medical orders" may include "medication orders," "examination requests," and "laboratory tests," etc. Business rule elements include threshold judgment, code mapping, mandatory field validation, and completion status. Business action elements include display components, prompt policies, and permission policies, etc.

[0031] Please see Figure 4 As shown, the disease diagnosis and treatment pathway orchestration method in this application includes a construction phase and an application phase. In the construction phase, the disease-specific diagnosis and treatment business is abstractly modeled to form a callable node library. In the application phase, based on the node library, the current orchestration process is visually edited, and business items and branch logic are configured to generate the disease-specific diagnosis and treatment pathway. Specifically, in the construction phase, after obtaining the business scenario data, the diagnosis and treatment business scenario is first analyzed and abstracted to obtain a set of event types. For each event type, an operation node is abstractly defined, and for each operation node, a set of business items is abstractly defined, thus forming a callable node library.

[0032] Specifically, after acquiring business scenario data, the systematic analysis of this data begins with defining the entire treatment cycle for a specific disease. This involves in-depth analysis based on clinical guidelines, expert consensus, and industry standards corresponding to the disease, abstracting and defining the entire treatment cycle from initial screening, enrollment and registration, initial diagnosis, intervention and treatment, disease monitoring, to post-discharge follow-up and long-term chronic disease management. This clarifies the boundaries and stages of the entire business scenario, laying the foundation for subsequent scenario decomposition. Secondly, based on the defined treatment cycle, key business trigger points within the treatment process are comprehensively reviewed to cover the driving sources in various scenarios. These key business trigger points include various trigger forms such as manual operation triggers by medical staff, medical management actions, timed periodic triggers, clinical data anomaly triggers, and patient condition status changes. Typical key business trigger points include, for example, "completing the initial assessment," "starting treatment plan A," "the follow-up examination time expires," "a risk warning appears," and "failed follow-up and retrying." Finally, the key business trigger points identified are standardized, categorized, named, and defined in a standardized manner. Trigger points with the same business semantics, similar triggering mechanisms, and similar business attributes are grouped into the same event type. At the same time, each event type is configured with a unique identifier, detailed business description, applicable diagnosis and treatment scenario scope, trigger source type, and precise triggering conditions, forming a standardized and structured set of event types, providing underlying data support for subsequent node library construction and diagnosis and treatment path orchestration.

[0033] The event type set includes at least one of the following: baseline assessment event, diagnosis issuance event, enrollment event, documentation completion event, treatment decision event, medication follow-up event, and termination event.

[0034] For a set of event types, in the process of abstracting and defining the corresponding operation nodes for each event type, the business objectives under the event type are first determined. Specifically, this involves combining clinical diagnosis and treatment guidelines with actual business scenarios to match a unique business objective for each event type. This business objective is used to define the diagnosis and treatment tasks and core execution objectives that need to be achieved after the event is triggered, ensuring that the execution direction of the node aligns with clinical needs. For example, for a diagnosis issuance event, the business objective is to complete the preliminary diagnosis of a specific disease or issue an admission diagnosis; for a document completion event, the business objective is to standardize the completion and archiving of corresponding medical and nursing documents; for a treatment strategy event, the business objective is to issue targeted laboratory tests, imaging examinations, or develop individualized treatment intervention plans.

[0035] Next, the business objectives are broken down into reusable action units. Specifically, the core principle is to balance reusability and scheduling flexibility. The business objectives of various events are progressively broken down into uniformly granular and independently executable basic action units, forming standardized operation nodes. This avoids overly coarse granularity leading to reuse difficulties, or overly fine granularity causing cumbersome scheduling. For example, for a document completion event, its overall business objective can be broken down into independent action units such as editing the document, saving the document, submitting for review, and archiving the document. For a treatment strategy event, it can be broken down into action units such as selecting examination items, entering medical orders, confirming the plan, and issuing instructions, ensuring that each action unit can be reused across events and scenarios.

[0036] Finally, standardized common attributes are defined for the operation nodes. The specific process involves uniformly configuring the attributes of each operation node obtained from the decomposition, giving the nodes complete standardized information, and realizing standardized management, visual orchestration, and automated flow of nodes. The common attributes of each operation node should include at least: node identifier (globally unique ID, used to distinguish and locate nodes), node name (standardized naming, intuitively reflecting the node function), node description (detailed description of the node's execution content and clinical use), input requirements (prerequisite data and conditional constraints required for node execution), output results (feedback information and data products generated after the node is completed), configurable parameters (business parameters and process parameters that support custom adjustments), applicable event types (limiting the event scenarios to which the node can belong), connectable constraints (limiting the scope of the node's prerequisite and postrequisite nodes), and default interaction mode (execution modes such as manual triggering, automatic execution, and semi-automatic interaction).

[0037] The aforementioned operation nodes can support multi-role collaboration attributes, such as the node execution role being a doctor, nurse, patient, or administrator.

[0038] In the process of abstracting and encompassing the set of business items for operation nodes, a detailed analysis of each operation node is first carried out. Combining the clinical diagnosis and treatment business logic and execution requirements, the set of business items covered by a single operation node is abstracted and refined to achieve a refined decomposition and standardized definition of the node execution content. The specific abstract dimensions of the set of business items include the following aspects: (a) data-related business items, (b) rule-related business items, (c) interaction-related business items, and (d) interface-related business items.

[0039] Among them, data-related business items are used to define the core diagnostic and treatment data that needs to be called, entered, processed, and stored during the execution of operation nodes, and serve as the basic carrier for the implementation of node business. For example, these include various types of structured and semi-structured diagnostic and treatment data such as: patient basic information, disease diagnosis results, examination and test items, assessment scale items and scoring results, treatment plan parameters, medication dosage information, follow-up record fields, and key fields of medical documents, ensuring the integrity and standardization of data flow during node execution.

[0040] Rule-based business items are used to constrain the execution logic, data compliance, and process judgment standards of operation nodes, avoiding deviations and logical conflicts in diagnosis and treatment operations. Examples include: mandatory data verification rules, numerical range verification rules, medical code mapping rules, indicator threshold judgment rules, multi-condition combination logic, execution priority rules, diagnosis and treatment plan conflict resolution rules, and workflow permission judgment rules. Through standardized rule settings, the compliance and accuracy of node execution are ensured.

[0041] Interactive business items are used to standardize the human-computer interaction mode and front-end display logic of operation nodes, improve the convenience of orchestration and execution, and optimize the clinical operation experience. Specifically, this involves front-end display component types (forms, lists, charts, and tooltips), hierarchical prompt strategies (strong prompts, weak prompts, and blocking prompts), data default value and recommended value generation strategies, operation error prompt templates, interactive button permissions, page jump logic, etc., to achieve standardized configuration of node interaction logic.

[0042] Interface-type business items are used to define the data interaction and collaboration mechanisms between operation nodes and external systems, ensuring cross-system data interoperability and process linkage. This includes interface definitions, data synchronization methods, real-time transmission protocols, event callback methods, interface permission verification, data encryption rules, etc., for interaction with external systems such as Hospital Information System (HIS), Electronic Medical Record System (EMR), and Laboratory Inspection System (LIS / PACS), so as to achieve seamless integration between operation nodes and existing medical information systems.

[0043] In this step, through the above-mentioned multi-dimensional business item abstraction, a complete set of business items is formed for a single operation node, further refining the node's functional core, and providing refined data and logical support for subsequent node configuration, process orchestration, and automated path execution.

[0044] Furthermore, after obtaining the event types, operation nodes, and their associated business item sets, these sets are structurally encapsulated to form a configurable node library. During the construction process, node templates are first encapsulated. Specifically, the standardized operation nodes are abstracted into reusable and extensible node templates. Each node template predefines the node's general execution capabilities, inherent attributes, and open configurable items, without binding to specific business scenarios or parameter values. In subsequent treatment path orchestration examples, only personalized parameter configuration based on this node template is needed to quickly generate node instances adapted to the current business. This not only ensures the consistency of the underlying logic but also considers the flexibility of scenario adaptation, significantly improving node reuse efficiency.

[0045] Then, business item templates are implemented and shared for reuse. Specifically, common business items frequently used in clinical diagnosis and treatment (such as vital sign collection, scale scoring rules, medication contraindication judgment, and mandatory data verification) are standardized and encapsulated to form independent business item templates. These templates can be shared and referenced across different node templates and different disease-specific treatment paths to avoid redundant development. For disease-specific business items that are not universal, disease-specific classification tags are added for isolation and management. This ensures maximum reuse of common business items while also taking into account the independence and specificity of disease-specific business items.

[0046] Finally, node connection constraint management is performed. Specifically, standardized connectable constraint rules are defined for various node templates in the node library, clarifying the pre- and post-relationships and flow logic restrictions between nodes. Exemplary constraint rules include: an evaluation node can be connected to a treatment node or a review node; if an audit node fails, it will revert to a supplementary data node; and a diagnosis node requires a preceding patient information collection node. In subsequent visual orchestration, the system can automatically perform compliance checks based on these constraint rules, providing real-time alerts and blocking of illegal connections to avoid orchestration logic errors.

[0047] Optionally, the node library is uniformly maintained and managed by a supporting node library management module. The node library management module includes at least: a node template management unit, a business item template management unit, a version management unit, a connection constraint management unit, and a release and permission management unit. The above division of functional units is only an illustrative example and does not constitute a specific limitation on the module architecture. They can be merged or split according to actual deployment needs.

[0048] Compared to existing technologies that rely on documents, tables, or static flowcharts to maintain treatment pathways, or that solidify pathway logic in code, this application abstracts business scenarios into event types, operation nodes, and business items, and encapsulates them in a structured, configurable node library. Nodes are selected and added from this library during the orchestration process. This node library includes node metadata, version information, business item templates, input / output constraints, and configurable parameters, and supports retrieval by disease / department / institution / tag, thereby improving reuse and selection efficiency. Through node library reuse and visual orchestration, the workload of building disease-specific pathways from scratch, repetitive configuration, and repetitive development can be significantly reduced. This makes the construction and modification of disease-specific treatment pathways faster and more batch-processable, reduces the cost of cross-department / cross-institution migration, and further improves the efficiency of disease-specific pathway construction and iteration.

[0049] In this step, multi-dimensional business items are abstracted for each operation node to form a complete set of business items for a single operation node. This further refines the functional core of each operation node, thereby providing refined data and logical support for subsequent node configuration, process orchestration, and automated path execution.

[0050] Step S202: In response to the user's orchestration operation command, create the current orchestration process and configure the starting node for the current orchestration process.

[0051] The aforementioned current orchestration process refers to a disease-specific diagnosis and treatment pathway model in the orchestration tool, which consists of a starting node, several operation nodes, inter-node connections, and a termination node. This orchestration process can be further associated with metadata such as specific diseases, applicable populations, applicable departments, applicable hospital areas, applicable stages, activation conditions, and deactivation conditions.

[0052] Please continue reading Figure 4As shown, in the application phase, when a user needs to orchestrate a treatment pathway for a specific disease, they can create the current orchestration process in the orchestration tool, set a starting node for the current orchestration process, select and add treatment nodes from the node library according to business needs, configure associated business items for each treatment node, define subsequent nodes or branch nodes for each treatment node, and define the interaction relationships and flow rules between each treatment node. Finally, the end node is set in the orchestration tool. The orchestration tool can be understood as a disease-specific treatment pathway construction software system that supports visual drag-and-drop modeling, no-code configuration of treatment nodes and branch rules, and has process verification, version management, and release capabilities. It features a visual workflow orchestration canvas, allowing users to complete workflow modeling of treatment pathways through interactive methods such as dragging, selecting, and connecting lines. It enables the addition, layout, and flow configuration of start nodes, treatment nodes, and end nodes, and supports visual configuration of business items, parameters, rules, and branch conditions for each node. It also has workflow legality verification, version management, and path publishing functions, enabling the construction, debugging, and deployment of disease-specific treatment pathways without the need for coding development, thus achieving rapid orchestration and implementation of treatment pathways.

[0053] For the application phase, before creating the current orchestration process, process metadata is created first. Specifically, this involves creating and refining the basic metadata of the current orchestration process to achieve standardized identification and regulated management. This process metadata includes: process name, scope of application, characteristics of the applicable population and patient inclusion / exclusion criteria, effective and deprecation dates, and the responsible personnel for editing and reviewing the process. Through complete metadata definition, the management attributes and application boundaries of the orchestration process can be clearly defined, facilitating subsequent path archiving, querying, and iterative updates. For example, the process name could be "Standardized Treatment Pathway for a Certain Disease V1.0," and the scope of application could be limited to specific hospital areas, implementing departments, and target diseases.

[0054] After completing the creation of process metadata, a starting node is configured for the current orchestration process. The starting node serves as the entry point for the entire treatment pathway and is used to identify the starting node of the treatment task. Its business semantics can correspond to operations such as patient enrollment, hospital admission and record keeping, and preliminary hospital admission assessment in actual clinical scenarios. At the same time, corresponding triggering conditions can be bound to the starting node according to the needs of clinical automation. Triggering conditions include, for example, automatically creating a path instance when the patient meets the disease inclusion criteria, manual triggering by medical staff, and automatic transfer to the starting node after the patient completes the pre-examination triage.

[0055] This step involves creating the current orchestration process and setting the starting node in a planned manner. This clarifies the execution entry point and startup mechanism of the treatment pathway, ensuring the orderly execution of subsequent orchestration processes.

[0056] Step S203: Based on the business requirements information in the diagnosis and treatment business scenario, select multiple processing nodes corresponding to the business requirements information from the node library, and add each processing node to the current orchestration process.

[0057] The business requirement information in this medical service scenario refers to the set of requirements, business constraints, scenario characteristics, and construction goals used to define, guide, and generate corresponding disease-specific treatment pathways for a target disease or specific clinical treatment scenario. This information clarifies the applicable objects, application scenarios, functional scope, and compliance requirements of the treatment pathway orchestration, providing a basis for subsequently selecting suitable treatment nodes from the node library. The business requirement information includes, but is not limited to: the name or disease code of the target disease, the type of applicable department, the characteristics of the applicable patient population, the treatment stage (e.g., initial visit, follow-up visit, emergency, hospitalization, rehabilitation), the hospital level and campus characteristics, medical insurance payment type constraints, treatment pathway compliance standards, pathway complexity requirements, and user-defined business rules.

[0058] Optionally, the business requirement information in the above-mentioned diagnosis and treatment business scenarios can be obtained by receiving business requirement parameters manually input, selected or uploaded by users through a visual interactive interface; it can also be obtained by parsing from a preset requirement configuration file, requirement template or business configuration table; or it can be obtained by data interaction with the hospital information system (HIS), electronic medical record system (EMR), clinical data center or disease management platform, and obtaining the requirement information of the corresponding business scenario through interface calls and parsing.

[0059] It is understandable that the aforementioned business requirements information refers to the set of clinical execution requirements and business rules that are clearly defined for a specific disease in a specific patient population and at a specific stage of diagnosis and treatment. Specifically, it includes the operational items that need to be performed in the diagnosis and treatment process, the information content that needs to be displayed and collected, and the corresponding process branches when different judgment conditions are met.

[0060] For example, for suspected pancreatic cancer patients or high-risk groups, business requirements necessitate prioritizing key examinations such as imaging examinations (e.g., abdominal ultrasound, upper abdominal MRI, enhanced abdominal CT) and laboratory tests (complete blood count, liver function, amylase, lipase, coagulation function). This includes clearly defining the specific content of each examination, data sources, result integrity requirements, alerts or blocking strategies for abnormal results, and branching rules for decision-making regarding further examinations or treatment based on examination results. "Imaging examinations" and "laboratory tests" constitute the corresponding node library. Similarly, for follow-up assessment nodes, business requirements differ depending on the tumor stage or treatment plan. Some scenarios emphasize the control of repeated examination items and time points, while others focus on monitoring adverse drug reactions and adherence. Still others require additional personalized educational content and risk warnings. These personalized clinical requirements arising from patient stratification, disease stage, or treatment plan differences all fall under the specific business requirements of disease-specific diagnosis and treatment.

[0061] In one embodiment, based on the business requirement information in the diagnosis and treatment business scenario, multiple processing nodes corresponding to the business requirement information are selected from the node library, including: Based on the event type in the business requirements information, select a node template from the node library; instantiate the node template as a node instance of the current orchestration process, and assign instance attributes to the node instance; instance attributes include instance identifier; set the initial parameters of the node instance to the default values ​​of the node template; when the node template is used multiple times in the current orchestration process, select to reference the same node template and configure different parameters for different node instances to form multiple processing nodes.

[0062] Optionally, when a node template is used only once in the current orchestration process, multiple disposal nodes are formed after setting the initial parameters of the node instance to the default values ​​of the node template.

[0063] In this embodiment, based on the previously abstracted types of diagnostic and treatment events, process stage divisions, and actual business execution requirements, corresponding node templates are first selected and retrieved from the node library. The selection process can rely on tags such as event type, node function, and applicable scenarios for rapid retrieval, ensuring that the selected node templates are highly compatible with the current diagnostic and treatment process and business objectives, and preventing the introduction of invalid nodes. Then, node instantiation configuration is performed. Specifically, the node templates selected from the node library are transformed into node instances adapted to the current orchestration process, and a globally unique instance identifier is assigned to each node instance. At the same time, the basic attributes, common business items, and connection constraint rules of the node template are inherited, realizing the rapid implementation of standardized templates into process instances and ensuring the uniformity of the underlying logic of the nodes.

[0064] Next, the initial parameters of the nodes are inherited and adaptively populated. Specifically, the initial parameters of the node instance are preferentially inherited from the preset default values ​​of the corresponding node template to ensure the standardization of basic parameters. At the same time, based on the context information of the current orchestration process, some common parameters are automatically and adaptively populated, such as the default execution department, corresponding medical staff role, and treatment time period bound to the process, eliminating the need for users to manually enter them repeatedly and improving orchestration efficiency. Finally, node deduplication control and reuse optimization are implemented. Specifically, for scenarios where the same node template needs to be called multiple times in the current orchestration process, there is no need to repeatedly create or define the node template. Only the original standardized node template needs to be referenced. By configuring differentiated parameters and personalized business items for different node instances, the reuse of a single template in multiple instances can be achieved. This not only avoids the redundancy problem caused by repeated node definitions, but also ensures that each instance adapts to the personalized needs of the corresponding process stage.

[0065] This step involves acquiring and parsing business requirement information within the diagnostic and treatment business scenario. This enables scenario-based and precise matching of treatment node selection, avoiding the disconnect between the path and actual business caused by blindly selecting nodes. It ensures that the final generated disease-specific diagnostic and treatment path aligns with the actual application scenarios of departments, hospitals, and information systems, further enhancing the applicability and reusability of the diagnostic and treatment path.

[0066] Step S204: Based on the node library, configure the business items, process flow, and transfer logic for each processing node.

[0067] Step S205: After configuring each treatment node, configure a termination node for the current orchestration process to generate a disease diagnosis and treatment path corresponding to the business requirement information.

[0068] Specifically, after selecting multiple processing nodes corresponding to business requirements from the node library and adding each processing node to the current orchestration process, the system configures business items for each processing node based on the node library, defining the business item content associated with each processing node in a specific scenario. It also configures the process flow for each processing node, defining the associated nodes extended by each processing node under specific business scenario conditions; these associated nodes include subsequent nodes or branch nodes. Furthermore, it configures the associations between nodes in the orchestration process, defining the interaction relationships between nodes. Finally, it configures a termination node for the current orchestration process. The termination node is the end node in the disease-specific treatment pathway orchestration process, used to identify the execution endpoint of the treatment pathway, forming a closed loop in the process. When the process reaches the termination node, it indicates that the current disease-specific treatment pathway has been completed, and no further node transitions are performed. The system can then complete process archiving, status updates, and log recording accordingly.

[0069] Compared with existing technologies, this solution builds a node library based on disease diagnosis and treatment business scenario data, achieving standardized and modular encapsulation of basic functional units in the treatment pathway, providing underlying data support for the unified expression and reuse of subsequent treatment pathways; by responding to user orchestration operation commands, creating orchestration processes and configuring starting nodes, it enables visualization and process guidance in the treatment pathway construction process; by selecting corresponding treatment nodes from the node library based on business needs information and adding them to the orchestration process, it fully utilizes the standardized resources of the node library, avoiding the duplication of similar disease-specific treatment pathways in different departments, hospital areas, and information systems, significantly improving the reusability and standardization of treatment pathway construction; and further enhancing the overall effectiveness of the solution. By configuring business items, process flow, and workflow logic for each node, the traditional path execution logic, which relies on solidified code, can be transformed into a visual and configurable parameter setting method. This eliminates the need for technical personnel to implement path logic through coding, reducing communication costs and development workload for medical staff, IT personnel, and other stakeholders during path adjustment. Finally, after the node configuration is completed, a termination node is configured to generate the final disease-specific diagnosis and treatment path, forming a complete closed-loop standardized and executable diagnosis and treatment path model. This unifies the expression and execution specifications of diagnosis and treatment paths, thereby significantly shortening the iteration cycle of diagnosis and treatment paths, comprehensively improving the efficiency of disease diagnosis and treatment path construction and maintenance, and reducing the cost of path implementation and promotion.

[0070] In one embodiment, a specific implementation method is also provided for configuring business items, process flow, and transfer logic for each processing node based on a node library. Please refer to [link to relevant documentation]. Figure 5 As shown, the method includes: Step S401: Based on the node library, configure the target business items associated with each treatment node in the diagnosis and treatment business scenario.

[0071] The target business item is a business item selected from the set of all business items and associated with the diagnosis and treatment business scenario. The diagnosis and treatment business scenario can be a business scenario corresponding to a specific disease. Configuring the associated target business item for the treatment node includes setting at least one of the following: data source, data type, value range or encoding system, mandatory field validation rules, display format, calculation / aggregation rules, trigger prompt rules, and access control rules for the target business item.

[0072] Specifically, each treatment node is configured with the target business item associated with the diagnosis and treatment business scenario, including: Receive the business item body; the business item body includes at least one of the following: selected business item, appended business item, and custom business item; selected business item refers to the business item to be enabled selected from the pre-set business items in the node template in the node library, appended business item refers to the associated business item added from the business item template library, and custom business item refers to the business item custom-built within the allowed range; configure the value and source for the business item body; configure the verification rules and prompt rules for the business item body; the verification rules include: mandatory field verification, range verification, and logical consistency verification, and the prompt rules include: prompt level, prompt text, and blocking strategy.

[0073] Configure the display format and interactive information for the main business item; the display format includes: display layout, field grouping, and control conditions; the interactive information is used to represent the visibility and operability of the target business item for different roles; configure the output information and the accumulated information for the main business item; the output information includes: the set of output business items after the disposal node is completed, and the output format; the accumulated information includes: whether it is written into the disease record, whether it forms quality indicators, and whether it forms a follow-up task.

[0074] The business item whose main body has all information configured is used as the target business item.

[0075] In this embodiment, business items are configured for each operation node to define the specific business items associated with each operation node in the current disease diagnosis and treatment scenario, thereby solving the technical problem that the elements of concern and execution logic of the same node template differ in different business scenarios.

[0076] The specific configuration process includes: (a) selection and expansion of business item sets; (b) configuration of business item values ​​and sources; (c) configuration of verification rules and prompting strategies; (d) configuration of display and interaction permissions; and (e) configuration of output results and data accumulation.

[0077] Specifically, the system selects the necessary business items for the current diagnosis and treatment scenario from the pre-defined standard business items in the node template, or adds externally common business items from the global business item template library. It can also add custom business items within the system's allowed customization scope, forming the main business item body of the current node instance. Then, it configures the business item values ​​and sources, assigning data sources to each business item body. These sources include form collection, external system synchronization, historical data inheritance, and algorithm calculations. Further configuration of data mapping relationships and value priority rules is possible, such as prioritizing the use of the latest test results and otherwise using values ​​from the admission record.

[0078] Next, the configuration of validation rules and prompt strategies is executed. Rules for mandatory data validation, numerical range validation, and logical consistency validation are configured for the main business item. Prompt levels, prompt text, and execution blocking strategies are defined to ensure the compliance and accuracy of node execution. The configuration of display format and interactive information is also performed. For display format, this includes configuring the front-end layout, field grouping method, default collapsed state, and read-only or editable attributes. Field visibility and operation permissions are configured for different medical roles to achieve differentiated interactive control; for example, higher-level roles have a wider range of operation permissions, while lower-level roles have a narrower range. Finally, the configuration of output information and data accumulation information for the main business item is performed. Specifically, the set of business items and data format output after node execution are defined for subsequent process nodes to call, and accumulation strategies such as whether to write relevant data into disease records, whether to form quality control indicators, and whether to generate follow-up tasks are configured.

[0079] Optionally, the business item configuration supports a scenario-based conditional mechanism, which means that multiple sets of differentiated rules can be configured for the same business item. When different patient stratification, disease staging, or treatment plan scenarios are met, the corresponding value retrieval logic, prompt logic, or display logic will be automatically adapted to improve the refinement and adaptability of the diagnosis and treatment path.

[0080] In this embodiment, the operation node is split into an architecture that separates node templates from scenario-based business item configurations. The general execution capabilities and basic attributes are uniformly encapsulated in the node template. This allows for independent configuration of the business item set, data source, verification rules, interaction logic, and output strategy for each node instance when orchestrating specific treatment paths for different business scenarios. It also supports differentiated rule configuration based on scenario conditions. Thus, while reusing the same node template, it enables flexible customization of the elements of interest and execution logic in different scenarios. This effectively solves the technical problem of poor adaptability of the same node template in different business scenarios and the inability to balance universality and personalization.

[0081] Step S402: Configure associated nodes for each treatment node in the diagnosis and treatment business scenario; associated nodes include: subsequent nodes or branch nodes.

[0082] Among them, the associated nodes extended by the configuration disposal node include at least one of the following: configuring trigger condition expressions, condition priorities, mutual exclusion relationships, parallel relationships, rollback conditions, timeout conditions, manual confirmation conditions, and exception handling strategies for the connection between nodes.

[0083] Step S403: Configure the flow logic information between each node in the current orchestration process; the flow logic information between each node includes one processing node and one associated node, two associated nodes, and two processing nodes; the flow logic information includes: interaction rules, data flow rules, and triggering conditions.

[0084] The aforementioned interaction rules and data flow rules refer to the unified constraints between nodes regarding control flow and data flow. Control flow is used to describe the relationships such as node activation, completion, failure, rollback, parallelism, and mutual exclusion; data flow is used to describe the input-output mapping, sharing, aggregation, and inheritance relationships of business items between nodes.

[0085] The associated nodes for each treatment node in the corresponding diagnosis and treatment business scenario are configured. These associated nodes define the flow direction and branching relationships after the current treatment node is completed. Specifically, they include two categories: subsequent nodes and branch nodes. Subsequent nodes refer to the next standard node to which the current treatment node directly flows under normal execution conditions and without branching decisions, forming a linear and continuous diagnosis and treatment process. Branch nodes refer to multiple candidate nodes to which branching jumps occur based on preset business rules, decision conditions, or execution results. This enables flow branching control under different diagnosis and treatment scenarios, different patient states, or different execution results. Configuring associated nodes clarifies the flow path and branching logic of each treatment node, ensuring the integrity and executability of the diagnosis and treatment path orchestration.

[0086] This includes configuring the flow logic information between each node in the current orchestration process, including: Identify nodes with relationships to be connected from each processing node; connect these nodes in the orchestration canvas to form directed edges; each directed edge includes at least: a source node, a target node, a connection type, and connection conditions; for any node to be connected, if it has multiple subsequent nodes, configure trigger conditions for the directed edges corresponding to each subsequent node; the trigger conditions are calculated based on process context variables, the output business items of the node to be connected, and the external system status; when multiple processing nodes need to be executed in parallel, configure parallel branches, rendezvous nodes, and rendezvous conditions for multiple processing nodes; if a node to be connected needs to supplement data, be re-evaluated, or fail and retry, configure fallback connection and retry strategies for the node to be connected; configure abnormal branch nodes and processing strategies for abnormal situations; abnormal situations include: node failure, timeout, data loss, and interface anomalies; establish mapping relationships for data transfer between each processing node and configure data scope; mapping relationships include field mapping, unit conversion, encoding conversion, aggregation calculation, and default value inheritance; configure interaction rules between each processing node; interaction rules include control interaction rules, collaborative interaction rules, and data interaction rules.

[0087] Specifically, the directed connections between nodes are first defined. Taking the diagnostic and treatment orchestration tool as a visual orchestration canvas, nodes with related relationships are identified from various treatment nodes. Directed connection edges are established between these nodes in the visual orchestration canvas to define the flow direction. Each directed connection edge contains at least four core pieces of information: source node, target node, connection type, and connection conditions. This standardizes the binding of flow relationships between nodes and lays the foundation for the diagnostic and treatment process framework. Then, a parallel branching and rendezvous mechanism is set up. Specifically, for scenarios with multiple exits from a single node, a corresponding conditional expression is configured for each branch connection. The conditional expression can be logically calculated based on parameters such as process context variables, current node output business items, and real-time status of external systems. To eliminate branch ambiguity and ensure orderly flow, branch priority and mutual exclusion rules are further configured. A priority routing strategy is defined when multiple conditions are simultaneously met to avoid flow ambiguity caused by overlapping conditions and ensure that process branches are unique and compliant.

[0088] It also sets up a parallel branching and rendezvous mechanism, specifically for complex clinical diagnosis and treatment scenarios. When multiple nodes need to be executed in parallel at a certain stage, such as parallel processing of examination requests, health education, and nursing assessments, a parallel branching structure is defined, and rendezvous nodes and rendezvous conditions are configured accordingly. The rendezvous conditions include three categories: completion of all parallel nodes, completion of any parallel node, and completion of key parallel nodes, adapting to the needs of different clinical collaboration scenarios. Then, a rollback and retry flow strategy is configured. Specifically, for nodes to be connected in scenarios such as data supplementation, reassessment, or execution failure, a reverse rollback connection and retry mechanism is established to clarify the process backflow path in abnormal scenarios. Exemplary rollback and retry flow strategies include rolling back to the data supplementation node when the review fails, and jumping to the delayed retry node when the follow-up fails, thereby ensuring that the diagnosis and treatment process can be corrected in a closed loop.

[0089] Furthermore, comprehensive exception handling branch rules are configured to pre-configure dedicated exception branch nodes and corresponding handling strategies for unexpected situations such as node execution failures, timeouts, missing core data, and abnormal external interface calls. This prevents processes from becoming interrupted or unreachable, improving the stability of the treatment pathway. Standardized data flow rules between nodes are also configured. By establishing data transfer mapping relationships between upstream and downstream treatment nodes, these mapping relationships include rules for field matching mapping, unit conversion, encoding format conversion, data aggregation calculation, and default value inheritance. Data scope is also configured, limiting data to use only within the current path instance, cross-node sharing, or writing back to disease records, ensuring secure and compliant data flow. Finally, node interaction control rules are configured, specifically detailing various interaction logics between nodes, including control interaction rules, collaborative interaction rules, and data interaction rules. Control interaction rules include completion triggers, failure triggers, and manual confirmation triggers; collaborative interaction rules include transfer, countersigning, and consultation; and data interaction rules include input and output docking, enabling orderly linkage between nodes.

[0090] Furthermore, after configuring the business items, process flow, and transfer logic for the treatment nodes, it is necessary to configure termination nodes and closed-loop strategies. By configuring one or more termination nodes for the orchestrated diagnosis and treatment process, the termination nodes can represent differentiated business semantics such as "completed path", "aborted path", "transferred to other paths", and "loss to follow-up". At the same time, the termination nodes are bound to the termination trigger conditions and process archiving strategies, ultimately forming a complete, compliant, and automated disease diagnosis and treatment path.

[0091] In one embodiment, after generating the disease-specific diagnosis and treatment path corresponding to the business requirement information, the above method further includes: Perform consistency checks on the configured current orchestration process; consistency checks include at least one of the following: connectivity check, branch condition completeness check, data dependency check, permission conflict check, and version compatibility check.

[0092] Specifically, after constructing the disease-specific diagnosis and treatment pathway, a consistency check needs to be performed before saving or publishing. This check includes: verifying the connectivity of the process from the starting node to the ending node to ensure there are no isolated nodes or unreachable branches; verifying the completeness of branch conditions to ensure that all branches are fully covered and free from conflicts or ambiguities; verifying the data dependencies between nodes to confirm that upstream outputs and downstream inputs match and avoid missing data or abnormal references; verifying conflicts between role permissions and operation scopes to prevent permission overstepping or configuration contradictions; and verifying the compatibility of the structure, node attributes, and constraint rules between path versions to ensure that the process can be inherited and run normally during iterative updates.

[0093] Optionally, the above node template includes corresponding metadata, which includes: template identifier, template name, event type identifier, applicable stage, applicable role, input business item list, output business item list, configurable parameter list, default parameter value, connectable constraints, version number, status (draft, published, deprecated), etc.

[0094] Node instances include corresponding metadata, such as: instance identifier, reference template identifier, instance name, instance parameters, enable conditions, disable conditions, execution strategy (automatic, manual, semi-automatic), execution time limit, responsible role, and audit strategy. Business items include corresponding metadata, such as: business item identifier, name, data type, unit, coding system, data source (collection, synchronization, calculation / inheritance), value retrieval rules, validation rules, display rules, permission rules, and audit rules. Connection relationship metadata may include: connection identifier, source node instance, target node instance, connection type (sequential, conditional, parallel, rollback, exception), conditional expression, priority, mutual exclusion flag, timeout strategy, and triggering event. Process metadata may include: process identifier, disease identifier, version number, scope of application, release status, change history, enable strategy, termination strategy, and archiving strategy.

[0095] In one embodiment, the conditional expression can adopt a Boolean logic expression model, supporting AND / OR / NOT, comparison operations, set inclusion, null value checks, etc.; and the expression can be parsed into an executable syntax tree for easy verification and runtime evaluation. To reduce ambiguity, the orchestration tool can provide a visual condition builder, restricting the expression construction process to an interpretable and verifiable set of rules.

[0096] In one embodiment, the aforementioned treatment pathway orchestration tool may include multiple modules: a node library management module, a service item configuration module, a rules and conditions module, and a verification and release module. The service item management module is connected to the service item configuration module, the rules and conditions module, and the verification and release module, respectively.

[0097] The module comprises several key components: The Node Library Management module maintains the creation, editing, publishing, and version management of event types, node templates, and business item templates, and provides retrieval, categorization, access control, and audit logging. The Orchestration and Modeling module allows users to create processes on a visual canvas, set start / end nodes, drag and drop new node instances, connect nodes, and configure connection conditions and priorities. The Business Item Configuration module enables / disables business items associated with node instances, maps fields, sets validation rules, display rules, permission rules, and prompt rules. The Rules and Conditions module provides the construction, parsing, validation, and reuse of conditional expressions and supports rule template management for multiple references. The Validation and Publishing module performs consistency checks and risk warnings before saving / publishing, and completes version generation, publishing approval, canary deployment, and rollback control.

[0098] Please see Figure 6 As shown, Figure 6 The sequence of steps shown is only a preferred implementation. In actual system implementation, some sub-steps can be rearranged or executed in parallel without violating the dependencies between steps. For example, in some application scenarios, process creation and starting node settings can be completed first, and then the node library content can be supplemented and improved according to actual orchestration needs; alternatively, iterative adjustments can be made during the configuration of node business items and the configuration of branch connections between nodes to improve the flexibility of path orchestration.

[0099] For example, the technical solution of this application is illustrated by taking the construction and orchestration of a full-cycle management path for a specific disease as an example. It is understood that this application is applicable to various disease diagnosis and treatment scenarios, and the specific disease, node content, business item fields, and branch conditions can be adaptively adjusted according to the clinical norms and business practices of different medical institutions.

[0100] Step S501: Systematically analyze the business scenario data during the diagnosis and treatment of the specific disease, extract and abstract the event types involved in the diagnosis and treatment process, and form a set of event types. That is, based on the clinical diagnosis and treatment guidelines and full-cycle management process of the specific disease, sort out and abstract key business triggering events to form a standardized set of event types. The event type set specifically includes: patient enrollment events, baseline assessment events, diagnosis issuance events, medical record completion events, treatment plan decision events, medication follow-up events, patient discharge / management termination events, etc.

[0101] Step S502: For the set of event types, perform business logic analysis on each event type and abstractly define the corresponding operation nodes. For example, for the baseline assessment event, abstract the baseline information collection node, scale assessment node, and risk calculation node; for the treatment decision event, abstract the treatment plan selection node, contraindication verification node, and medical order suggestion generation node; for the medication follow-up event, abstract the follow-up task generation node, follow-up result collection node, and medication adherence assessment node, and uniformly define the input and output content and configurable parameters for each operation node.

[0102] Step S503: Analyze each defined operation node in detail and abstract the set of business items covered by each operation node. For example, configure business items such as scale entries, scoring calculation rules, missing value handling rules, risk stratification thresholds, and prompt text templates for the scale assessment node; configure rule-based business items such as diagnostic code sets, test indicator thresholds, drug contraindication associations, and blocking prompt strategies for the contraindication verification node.

[0103] Step S504: The abstracted event types, operation nodes, and associated business items are structurally encapsulated to form a configurable node library for use by the treatment pathway orchestration tool. Specifically, the above-mentioned event types, operation nodes, and standardized business items are uniformly encapsulated into node templates and business item templates. Based on the application scenario, these are categorized with tags such as disease-specific identifiers, hospitalization period, and follow-up period. After review, these are released to form a disease-specific treatment node library, achieving unified management and reuse of nodes and business items.

[0104] Step S505: Based on the specific disease-specific diagnosis and treatment needs, select the corresponding treatment node from the node library in the diagnosis and treatment pathway orchestration tool and add it to the current orchestration process. Specifically, create a new process in the disease-specific pathway orchestration tool, named "Disease-Specific Full-Cycle Management Path V1.0", configure the applicable departments, applicable population, effective period, and other metadata, and set "Patient Enrollment" as the process starting node. At the same time, bind the trigger condition: when a patient meets the disease-specific inclusion and stratification criteria, the diagnosis and treatment pathway instance will be automatically started.

[0105] Step S506: Configure the business items for each added treatment node, defining the target business items associated with each treatment node in a specific diagnosis and treatment business scenario. Specifically, based on the business requirements of the full-cycle management of this disease, select and instantiate relevant nodes sequentially from the node library, including baseline information collection nodes, scale assessment nodes, risk calculation nodes, treatment plan selection nodes, contraindication verification nodes, medical order suggestion generation nodes, follow-up task generation nodes, follow-up result collection nodes, and compliance assessment nodes, and complete the node layout in the orchestration canvas.

[0106] Step S507: Configure the workflow for each treatment node, defining the subsequent nodes or branch nodes that extend from each treatment node under specific business scenario conditions. Specifically, configure scenario-based business items for each node instance: configure target scale items and scoring rules for the scale assessment node; configure indicator sources, normal ranges, and abnormal judgment rules for the contraindication verification node; configure form fields, mandatory field validation rules, and front-end display strategies for the follow-up result collection node; configure recommended content, prompt levels, and operation permission control for the medical advice generation node, achieving personalized adaptation of the same template under this specific disease scenario.

[0107] Step S508: Configure the associations of each node in the orchestration process, defining the interaction relationships, data flow rules, and triggering conditions between nodes. Specifically, configure the flow relationships and branch judgment logic between nodes: set up hierarchical branches after the risk calculation node, with high-risk patients entering the intensive treatment and close follow-up branch, medium-risk patients entering the standard treatment branch, and low-risk patients entering the routine management branch; configure an exception branch after the contraindication verification node, if the verification fails, jump to the alternative selection node, and if the verification passes, proceed normally to the medical order suggestion generation node. At the same time, establish the data flow mapping relationship between nodes, storing key information such as risk stratification results in the process context for subsequent nodes to read and use. Finally, configure the process termination node, corresponding to business scenarios such as patient discharge or long-term follow-up management termination, completing the closed-loop construction of the entire treatment path.

[0108] As can be seen from the above embodiments, this application can quickly construct a full-cycle diagnosis and treatment path for a specific disease by reusing the node library, visual orchestration, and configuring refined business items. While ensuring the standardization of the process, it supports differentiated process control based on patient stratification, disease risk, and treatment plan, and has strong versatility, flexibility, and scalability.

[0109] By unifying and abstracting the event types, operation nodes, and business items in steps S501 to S503, and by explicitly defining the interaction relationships between nodes, data flow rules, and triggering conditions in step S508, the traditional natural language or static chart-based expression of the diagnosis and treatment path can be transformed into a structured model of "event type - operation node - business item". This achieves unified naming and boundary standardization of the same business concept in system configuration and process description, reducing business ambiguity caused by differences in human understanding. At the same time, through the standardized description of the three types of relationships of data interaction, control interaction, and collaborative interaction, the logical deviation and configuration drift in process execution are reduced, significantly improving the standardization and consistency of the expression of the diagnosis and treatment path.

[0110] By configuring the associated business items for each operation node in specific scenarios in step S507, and configuring trigger condition expressions, priorities, mutual exclusion / parallelism, rollback, timeout, manual confirmation, and exception handling strategies for node connections in step eight, branching and extension based on scenario conditions are achieved. Compared to existing fixed table displays or fixed processes, this solution allows configuration of associated business items for each node in specific disease-specific business scenarios, and conditional extension of subsequent nodes or branch nodes. This supports differentiated path configuration and rapid adjustment for different specialties, different patient stratifications, and different stages of diagnosis and treatment, improving flexibility and scalability.

[0111] This application achieves asset management by constructing a reusable and configurable standardized node library in step S504. Combined with steps S505 to S508, it completes a closed-loop configuration process in the disease-specific pathway orchestration tool, including process creation, node addition, business item configuration, branch rule setting, and termination node setting. Through the collaborative support of the abstract analysis module, node definition module, node library construction module, and orchestration configuration module, it replaces the traditional code-based development model with visual configuration. This allows changes to the treatment pathway to be implemented simply through configuration adjustments, significantly reducing reliance on R&D code modifications, reducing the frequency of R&D intervention, and lowering version release costs. At the same time, relying on structured nodes, business items, connection conditions, and data interaction rules, it forms traceable configuration assets, effectively improving the controllability and traceability of pathway maintenance.

[0112] This application standardizes the flow logic between nodes by uniformly configuring node interaction relationships, data flow rules, and triggering conditions in step eight, and combining conditional expressions, branch priorities, mutual exclusion / parallelism, rollback, timeout, manual confirmation, and exception handling strategies. At the same time, it performs consistency checks such as connectivity, branch condition completeness, data dependency, permission conflict, and version compatibility before the path is published, which effectively reduces the probability of process unreachability, conflict, or abnormal interruption in complex branch scenarios, reduces post-launch failures and rework, and significantly improves the correctness and stability of the diagnosis and treatment process. By abstracting the set of business items corresponding to each operation node in step S503, and combining the refined configuration of data source, field type, encoding system, mandatory field validation, display format, calculation aggregation, prompt triggering and permission control of business items in step S507, and relying on the unified definition of data flow rules and triggering conditions between nodes in step S508, the configuration of business items at the node level can accurately plan the data collection, validation, display, calculation and output logic for specific diagnosis and treatment scenarios, avoiding problems such as data collection redundancy, invalid fields or inconsistent prompts, and effectively improving the utilization efficiency and scenario adaptability of data elements.

[0113] In summary, through the hierarchical abstraction and orchestration of the above steps, combined with node libraries, refined configuration of business items, definition of branching and interaction rules and data flow rules, multi-dimensional consistency verification and modular system architecture, comprehensive technical advantages are achieved: higher efficiency in constructing treatment pathways, lower maintenance costs, more standardized and unambiguous process expression, more flexible adaptation to different clinical scenarios, more convenient reuse of nodes and rules and cross-institutional migration, more stable and controllable process operation, and more targeted and consistent data collection and use. Overall, this improves the efficiency of constructing and maintaining disease-specific treatment pathways and reduces the cost of pathway implementation and promotion.

[0114] This application provides a method for orchestrating disease diagnosis and treatment pathways. It is geared towards business activities in the disease-specific diagnosis and treatment process, using "event type—operation node—business item" as the core abstract unit. Key business scenarios in the disease-specific diagnosis and treatment process are structurally modeled and stored as a reusable and configurable node library. In the application phase, an orchestration process is created using an orchestration tool, and a starting node is set. Operation nodes are selected and added from the node library based on specific disease-specific business needs. The business items associated with each operation node under a specific business scenario are configured, and further, subsequent nodes or branch nodes that can be extended under specific business scenario conditions are defined for each operation node. Simultaneously, the interaction relationships, data flow rules, and triggering conditions between nodes are defined. Finally, a termination node is set in the orchestration tool to complete the disease-specific pathway orchestration. This method transforms the traditional disease-specific pathway construction process, which relies on code fixation or manual documentation maintenance, into a visual, configurable, and versionable pathway orchestration process. This improves the efficiency, reusability, and consistency of disease-specific pathway construction, reduces maintenance costs, and enhances adaptability to the differentiated needs of different medical institutions, specialties, and treatment stages.

[0115] Based on the same inventive concept, this application also provides an apparatus for orchestrating the disease diagnosis and treatment pathways described above. The solution provided by this apparatus is similar to the solution described in the above method; therefore, the specific limitations of one or more embodiments of the disease diagnosis and treatment pathway orchestration apparatus provided below can be found in the limitations of the disease diagnosis and treatment pathway orchestration method described above, and will not be repeated here.

[0116] In one exemplary embodiment, such as Figure 7 As shown, a disease diagnosis and treatment pathway orchestration device is provided, the device comprising: Module 510 is used to build a node library based on the business scenario data acquired during the disease diagnosis and treatment process; Create module 520 to respond to user orchestration operation commands, create the current orchestration process, and configure the starting node for the current orchestration process; Select module 530 is used to select multiple processing nodes corresponding to the business needs information from the node library based on the business needs information in the diagnosis and treatment business scenario, and add each processing node to the current orchestration process. Configuration module 540 is used to configure business items, process flow, and transfer logic for each processing node based on the node library. The generation module 550 is used to configure a termination node for the current orchestration process after each treatment node has been configured, so as to generate a disease diagnosis and treatment path corresponding to the business requirement information.

[0117] As an optional implementation, the construction module 510 is specifically used for: Systematically analyze business scenario data to extract all event types involved in the disease diagnosis and treatment process, forming an event type set; event types are used to characterize key business signals or scenario conditions that trigger the execution of the disease diagnosis and treatment process; the event type set includes at least one of the following: baseline assessment event, diagnosis issuance event, enrollment event, document completion event, treatment decision event, medication follow-up event, and termination event; For each event type in the event type set, perform business logic analysis to determine multiple operation nodes corresponding to the event type; an operation node refers to a business action unit that needs to be executed under the drive of an event type. For each operation node, conduct business analysis to determine the set of business items contained in the operation node. The set of business items includes the business elements that the operation node needs to perform processing operations. The processing operations include at least one of the following: collection, verification, display, calculation, output, and push operations. The business elements include business data elements, business rule elements, or business action elements. The set of business items includes at least one of the following business items and corresponding metadata: data-type business items, rule-type business items, interaction-type business items, and interface-type business items. The metadata includes: business item identifier, name, description, data type, unit, coding system, data source, collection method, calculation method, visibility, editability, access control, and audit requirements. The event types, operation nodes, and their associated business item sets are structured and encapsulated to build a node library.

[0118] As an optional implementation, the configuration module 540 is specifically used for: Based on the node library, each treatment node is configured with the target business items associated with the diagnosis and treatment business scenario; Configure associated nodes for each treatment node in the context of the diagnosis and treatment business scenario; associated nodes include: subsequent nodes or branch nodes; associated nodes refer to operation nodes associated with the treatment node; Configure the flow logic information between each node in the current orchestration process; the relationships between each node include one processing node and one associated node, two associated nodes, and two processing nodes; the flow logic information includes: interaction rules, data flow rules, and triggering conditions.

[0119] As an optional implementation, the configuration module 540 is also used for: Select a node template from the node library based on the event type in the business requirements information; Instantiate the node template as a node instance of the current orchestration process, and assign instance attributes to the node instance; instance attributes include instance identifier; Set the initial parameters of the node instance to the default values ​​of the node template; When a node template is used multiple times in the current orchestration process, select to reference the same node template and configure different parameters for different node instances to form multiple disposal nodes.

[0120] As an optional implementation, the configuration module 540 is also used for: Receive business item body; business item body includes at least one of the following: select business item, add business item, and customize business item; select business item refers to the business item to be enabled selected from the preset business items in the node template in the node library, add business item refers to the associated business item added from the business item template library, and customize business item refers to the business item custom-built within the allowed scope; Configure the value and source for the main business item; Configure validation rules and prompt rules for the main business item; validation rules include: mandatory field validation, range validation, and logical consistency validation; prompt rules include: prompt level, prompt text, and blocking strategy. Configure the display format and interactive information for the main business item; the display format includes: display layout, field grouping, and control conditions; the interactive information is used to represent the visibility and operability of the target business item for different roles; Configure output and retention information for the main business items; output information includes: the set of output business items after the treatment node is completed, and the output format; retention information includes: whether it is written into the disease file, whether it forms quality indicators, and whether it forms a follow-up task; The business item whose main body has all information configured is used as the target business item.

[0121] As an optional implementation, the configuration module 540 is also used for: Identify nodes with related relationships from each processing node to be connected; Connect nodes to be connected in the layout canvas to form directed edges; a directed edge must include at least: source node, target node, connection type, and connection condition; For any node to be connected, if there are multiple subsequent nodes, a trigger condition is configured for the directed edge corresponding to each subsequent node; the trigger condition is calculated based on the process context variable, the output business item of the node to be connected, and the external system status. When multiple processing nodes need to be executed in parallel, configure parallel branches, rendezvous nodes, and rendezvous conditions for multiple processing nodes; If the node to be connected needs to supplement information, be re-evaluated, or fail to retry, configure a fallback connection and retry strategy for the node to be connected. Configure abnormal branch nodes and handling strategies for abnormal situations; abnormal situations include: node failure, timeout, data loss, and interface abnormality. Establish mapping relationships for data transfer between various processing nodes and configure data scope; the mapping relationships include field mapping, unit conversion, encoding conversion, aggregation calculation, and default value inheritance; Configure interaction rules between each processing node; the interaction rules include control interaction rules, collaborative interaction rules and data interaction rules.

[0122] As an optional implementation, the above-described apparatus is further used for: Perform consistency checks on the configured current orchestration process; consistency checks include at least one of the following: connectivity check, branch condition completeness check, data dependency check, permission conflict check, and version compatibility check.

[0123] The disease diagnosis and treatment pathway orchestration device provided in this application embodiment achieves standardized and modular encapsulation of basic functional units in the diagnosis and treatment pathway by constructing a node library based on disease diagnosis and treatment business scenario data, providing underlying data support for the unified expression and reuse of subsequent diagnosis and treatment pathways; by responding to user orchestration operation commands, creating an orchestration process and configuring starting nodes, it can realize visualization and process guidance of the diagnosis and treatment pathway construction process; by selecting corresponding treatment nodes from the node library according to business requirement information and adding them to the orchestration process, it makes full use of the standardized resources of the node library, avoids the repeated construction of similar disease-specific diagnosis and treatment pathways in different departments, hospital areas and information systems, and significantly improves the reusability of diagnosis and treatment pathways. The system ensures usability and standardization in its construction. Furthermore, it configures business items, process flow, and workflow logic for each treatment node, transforming the traditionally code-driven path execution logic into a visual and configurable parameter setting method. This eliminates the need for technical personnel to implement path logic through coding, reducing communication costs and development workload for medical staff, IT personnel, and other stakeholders during path adjustment. Finally, after node configuration, a termination node is configured to generate the final disease-specific treatment path, forming a complete closed-loop, standardized, and executable treatment path model. This unifies the expression and execution standards of treatment paths, significantly shortening the iteration cycle and comprehensively improving the efficiency of disease treatment path construction and updating.

[0124] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 8 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores video tag processing data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a method for arranging disease diagnosis and treatment pathways.

[0125] Those skilled in the art will understand that Figure 8The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0126] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0127] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0128] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0129] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0130] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0131] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0132] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0133] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for arranging disease diagnosis and treatment pathways, characterized in that, The methods for arranging the disease diagnosis and treatment pathways include: Based on the business scenario data acquired during the disease diagnosis and treatment process, a node library is constructed; In response to the user's orchestration operation command, create the current orchestration process and configure the starting node for the current orchestration process; Based on the business needs information in the diagnosis and treatment business scenario, select multiple processing nodes corresponding to the business needs information from the node library, and add each of the processing nodes to the current orchestration process; Based on the node library, each processing node is configured with business items, process flow, and transfer logic. Once each processing node is configured, a termination node is configured for the current orchestration process to generate the disease diagnosis and treatment path corresponding to the business requirement information.

2. The method for arranging disease diagnosis and treatment pathways according to claim 1, characterized in that, Based on the acquired business scenario data from the disease diagnosis and treatment process, a node library is constructed, including: The business scenario data is systematically analyzed to extract all event types involved in the disease diagnosis and treatment process, forming an event type set. The event types are used to characterize the key business signals or scenario conditions that trigger the execution of the disease diagnosis and treatment process. The event type set includes at least one of the following: baseline assessment event, diagnosis issuance event, enrollment event, document completion event, treatment decision event, medication follow-up event, and termination event. For each event type in the event type set, a business logic analysis is performed to determine multiple operation nodes corresponding to the event type; the operation node refers to the business action unit that needs to be executed under the drive of the event type. For each operation node, a business analysis is performed to determine the set of business items contained in the operation node. The set of business items includes the business elements for which the operation node needs to perform processing operations. The processing operations include at least one of the following: collection, verification, display, calculation, output, and push operations. The set of business items includes at least one of the following business items and corresponding metadata: data-related business items, rule-related business items, interaction-related business items, and interface-related business items. The metadata includes: business item identifier, name, description, data type, unit, coding system, data source, collection method, calculation method, visibility, editability, access control, and audit requirements. The event types, operation nodes, and their associated business item sets are structured and encapsulated to build a node library.

3. The method for arranging disease diagnosis and treatment pathways according to claim 2, characterized in that, Based on the node library, each processing node is configured with business items, process flow, and transfer logic, including: Based on the node library, each treatment node is configured with the target business item associated with the diagnosis and treatment business scenario; Each treatment node is configured with associated nodes that extend within the aforementioned medical service scenario; these associated nodes include subsequent nodes or branch nodes; and each associated node refers to an operation node associated with the treatment node. Configure flow logic information between nodes in the current orchestration process; the nodes include one processing node and one associated node, two associated nodes, and two processing nodes; the flow logic information includes: interaction rules, data flow rules, and triggering conditions.

4. The method for arranging disease diagnosis and treatment pathways according to claim 1, characterized in that, Based on the business needs information in the diagnosis and treatment business scenario, multiple processing nodes corresponding to the business needs information are selected from the node library, including: Based on the event type in the business requirement information, select a node template from the node library; The node template is instantiated as a node instance of the current orchestration process, and instance attributes are assigned to the node instance; the instance attributes include an instance identifier; Set the initial parameters of the node instance to the default values ​​of the node template; When the node template is used multiple times in the current orchestration process, the same node template is selected and different parameters are configured for different node instances to form multiple disposal nodes.

5. The method for arranging disease diagnosis and treatment pathways according to claim 3, characterized in that, Based on the node library, each treatment node is configured with the target business item associated with the diagnosis and treatment business scenario, including: Receive business item body; the business item body includes at least one of the following: selected business item, appended business item, and custom business item; the selected business item refers to the business item to be enabled selected from the preset business items in the node template in the node library, the appended business item refers to the associated business item appended from the business item template library, and the custom business item refers to the business item custom-built within the allowed scope; Configure the value and source for the main body of the aforementioned business item; Configure verification rules and prompt rules for the main body of the business item; the verification rules include: mandatory field verification, range verification, and logical consistency verification; the prompt rules include: prompt level, prompt text, and blocking strategy. Configure the display format and interactive information for the main body of the business item; the display format includes: display layout, field grouping, and control conditions; the interactive information is used to characterize the visibility and operability of the target business item for different roles; Configure output information and retention information for the main body of the business item; the output information includes: the set of output business items after the treatment node is completed, and the output format; the retention information includes: whether it is written into the disease record, whether it forms quality indicators, and whether it forms a follow-up task. The business item whose main body has all information configured is designated as the target business item.

6. The method for arranging disease diagnosis and treatment pathways according to claim 3, characterized in that, Configure the flow logic information for association between each node in the current orchestration process, including: Identify nodes with related relationships from each processing node to be connected; Connect the nodes to be connected in the arrangement canvas to form directed edges; the directed edges include at least: source node, target node, connection type and connection condition; For any node to be connected, if the node to be connected has multiple subsequent nodes, a trigger condition is configured for the directed edge corresponding to each subsequent node; the trigger condition is calculated based on process context variables, the business items output by the node to be connected, and the external system status. When multiple processing nodes need to be executed in parallel, configure parallel branches, rendezvous nodes, and rendezvous conditions for multiple processing nodes; If the node to be connected needs to supplement information, be re-evaluated, or fail to retry, configure a fallback connection and retry strategy for the node to be connected. Configure abnormal branch nodes and handling strategies for abnormal situations; the abnormal situations include: node failure, timeout, data loss, and interface abnormality; Establish mapping relationships and configure data scope for data transfer between various processing nodes; the mapping relationships include field mapping, unit conversion, encoding conversion, aggregation calculation, and default value inheritance. Configure interaction rules between each processing node; the interaction rules include control interaction rules, collaborative interaction rules and data interaction rules.

7. The method for arranging disease diagnosis and treatment pathways according to claim 1, characterized in that, After generating the specialized diagnosis and treatment path corresponding to the business requirement information, the method further includes: Perform a consistency check on the configured current orchestration process; the consistency check includes at least one of the following: connectivity check, branch condition completeness check, data dependency check, permission conflict check, and version compatibility check.

8. A device for arranging disease diagnosis and treatment pathways, characterized in that, The disease diagnosis and treatment pathway programming device includes: The module is used to build a node library based on the business scenario data acquired during the disease diagnosis and treatment process; A creation module is used to respond to user orchestration operation commands, create the current orchestration process, and configure a start node for the current orchestration process; The selection module is used to select multiple processing nodes corresponding to the business needs information in the diagnosis and treatment business scenario from the node library, and add each of the processing nodes to the current orchestration process. The configuration module is used to configure business items, process flow, and transfer logic for each processing node based on the node library. The generation module is used to configure a termination node for the current orchestration process after each treatment node is configured, so as to generate the disease diagnosis and treatment path corresponding to the business requirement information.

9. A computer device, comprising: The memory and processor contain a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the disease diagnosis and treatment pathway arrangement method according to any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the method for arranging disease diagnosis and treatment pathways as described in any one of claims 1-7.

Images