Method for generating medical information system source code based on low-code platform

Abstract

The invention discloses a method for generating medical information system source codes based on a low-code platform. The method comprises the following steps: firstly, acquiring an original medical field configuration description file edited and generated by a user in a medical business visual modeling device; analyzing the file, and extracting a function component definition and component relation graph; constructing a functional component registry according to component definition, and recursively instantiating each component into a clinical pathway execution graph representing business logic in combination with the relation graph; and finally, converting the execution graph into a deployable source code conforming to a target technology stack specification. According to the method, medical services are abstracted through visual modeling, clinical pathways and data dependence are accurately expressed through a graph structure, automatic and standardized generation from service requirements to high-quality source codes is achieved, and the efficiency, normalization and maintainability of medical information system development are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of low-code platform-based generation of medical information system source code, and more specifically, to a method for generating medical information system source code based on a low-code platform. Background Technology

[0002] With the accelerating pace of healthcare informatization, hospitals and various medical institutions have an increasingly urgent need for customized and professional information systems. Traditional healthcare information system development primarily relies on professional developers manually writing code, which suffers from long development cycles, high technical barriers, slow response to business changes, and low standardization between different systems. Especially for complex clinical business processes (such as electronic medical records, closed-loop medical orders, and clinical pathway management), the complex business logic, frequent data interactions, and strict adherence to healthcare regulations and data standards result in persistently high system construction and maintenance costs under the traditional development model.

[0003] The emergence of low-code development platforms has provided a new approach to rapidly building applications, allowing users to configure application logic visually and reduce reliance on traditional coding. However, existing low-code platforms still face significant limitations when applied in the medical field: First, their generalized components and models often fail to accurately express complex medical business semantics and clinical pathway logic; second, the generated applications are mostly interpreted runtime models, which are insufficient in terms of performance, security, and integration capabilities with other specialized medical systems; finally, the generated code is usually deeply bound to the runtime of a specific platform, making it difficult to export as standard, independently deployable, and customizable source code, thus limiting the system's autonomy, long-term maintainability, and the flexibility of its technical architecture.

[0004] Therefore, the industry urgently needs a dedicated method and system that can deeply integrate medical knowledge, support visual and structured business modeling, and efficiently and accurately convert models into high-quality, deployable source code, so as to truly realize the agility, standardization and industrialization of medical information system development. Summary of the Invention

[0005] The purpose of this invention is to provide a method for generating source code for a medical information system based on a low-code platform, in order to solve the above-mentioned problems existing in the prior art.

[0006] The application is as follows: A method for generating source code for a medical information system based on a low-code platform includes: Obtain the original medical domain configuration description file of the target medical application. The original medical domain configuration description file is obtained by the user through interactive editing in the medical business visualization modeler of the low-code development platform. The configuration description file for the medical field is parsed to generate functional component definitions and component relationship graphs for the target medical application. The functional component definitions are used to define the attributes and behavioral logic of each business component in the target medical application, and the component relationship graphs are used to describe the hierarchical structure and data flow / control flow connection relationships of each business component. Based on the functional component definitions, construct the functional component registry for the target medical application; Based on the functional component registry and component relationship graph, each business component is recursively instantiated into a clinical path execution graph, which is represented by a graph structure, where nodes are business component instances and edges are data flow or control flow dependencies. The clinical pathway execution graph is converted into deployable and executable source code that meets the technical stack requirements of the target medical information system, and serves as the final executable code corresponding to the target medical application.

[0007] Further, constructing the functional component registry of the target medical application based on the functional component definition includes: An initial registry is constructed using a key-value pair data structure. The initial registry is used to store the mapping relationship between the unique identifier of a component and the corresponding component implementation. The component implementation is the specific implementation code of the component or a module reference. Based on the functional component definition, obtain the component identifier, component type, configuration attribute set, and reference information of nested sub-components for each business component from the original medical domain configuration description file; Based on the component type, configuration attribute set, and reference information of nested sub-components, the specific implementation code or module reference of each component is dynamically generated or associated to obtain the component implementation of each component; Establish a mapping relationship between the component identifier of each component and the component implementation of each component to obtain the registration entry of each component; The registration entry for each component is stored in the initial registry to obtain the functional component registry of the target medical application.

[0008] Furthermore, the functional component registry includes a mapping relationship between the component identifier of each component and the component implementation of each component, and the component relationship graph is used to describe the hierarchical structure and connection relationship of each business component; The step of recursively instantiating each business component into a clinical pathway execution graph based on the functional component registry and component relationship graph includes: Based on the hierarchical structure of each business component, create corresponding directed graph nodes, with each node representing a business component; Based on the data flow / control flow connection relationships in the component relationship graph, directed edges are created between the directed graph nodes to assemble and generate a clinical path execution graph that represents the complete business logic; Recursively traverse each target directed graph node in the clinical pathway execution graph; For each target directed graph node traversed, obtain the component identifier corresponding to that node; Obtain the target component implementation corresponding to the component identifier from the mapping relationship in the functional component registry; Using the target component implementation, each target directed graph node is instantiated to generate a corresponding component instance, ultimately resulting in a clinical path execution graph containing instantiated component nodes and actual data dependency edges.

[0009] Furthermore, the step of creating corresponding directed graph nodes based on the hierarchical structure of each business component includes: Traverse the hierarchical structure of each business component to determine the top-level component and the nested components under the top-level component. Based on the top-level components and their definition information, the starting node of the clinical pathway execution graph is generated; Based on the nested components at each level and their respective component definition information, subsequent nodes corresponding to the nested components at each level are recursively generated.

[0010] Furthermore, the directed graph nodes include a start node and subsequent nodes; The step of creating directed edges between the directed graph nodes based on the data flow / control flow connection relationships in the component relationship graph, and assembling to generate a clinical path execution graph representing the complete business logic, includes: Obtain a basic directed graph framework representing the initial logic of the application; Based on the connection relationships in the component relationship graph, the positions and connection relationships of the starting node and subsequent nodes in the basic directed graph framework are determined. The connection relationships include data flow direction, triggering conditions, and execution order. Based on the positions and connections, the starting node, subsequent nodes, and their connecting edges are inserted into the basic directed graph framework to form the clinical pathway execution graph.

[0011] Furthermore, the step of converting the clinical pathway execution graph into deployable and executable source code that meets the requirements of the target medical information system's technology stack includes: Iterate through the clinical path execution graph to obtain the business component instance corresponding to each directed graph node; Obtain the instantiation code snippet corresponding to each business component instance; The instantiated code fragments of each business component instance are subjected to syntax analysis and compilation transformation to obtain an intermediate representation. Deep semantic analysis is performed on the intermediate representation, and the dependencies defined by the edges between nodes in the clinical pathway execution graph are combined to determine the exact version or implementation of each called business function or API in the instantiated code fragment; Functions / APIs with a single deterministic version or implementation and fixed dependencies are identified as static binding items, while functions / APIs with multiple versions, dynamic bindings, or dependencies that change according to the execution graph path are identified as dynamic binding items, resulting in a set of static binding items and a set of dynamic binding items for each business component instance; Based on the topology of the clinical pathway execution graph, the generation and assembly order of the code is determined, and the static binding item set and dynamic binding item set of each business component instance are converted and integrated into deployable source code that conforms to the target technology stack specification.

[0012] Furthermore, the step of converting and integrating the static binding item set and dynamic binding item set of each business component instance into deployable source code that conforms to the target technology stack specification includes: For each business component instance, generate direct call code for static binding items and generate indirect call code based on clinical pathway execution graph routing or service discovery for dynamic binding items, thus obtaining a complete call logic code set for each instance; The complete call logic code set of each business component instance is arranged according to the execution order and dependency relationship defined in the clinical pathway execution graph, and then combined and rendered with the project structure template, dependency configuration and deployment description file of the target technology stack to generate the final deployable source code project.

[0013] Furthermore, generating direct calling code for the static binding items of each business component instance includes: Obtain the underlying service framework or basic library files pre-generated for the target technology stack; Based on the clinical pathway execution graph, the execution context of each node is analyzed, and all function / API identifiers in the static binding items of each business component instance are parsed and located to the specific implementation location in the underlying service framework or basic library file, so as to obtain the function offset or reference path of each static binding item. Based on the function offset or reference path, and its upstream and downstream node information in the clinical pathway execution graph, generate source code statements that include direct imports, context passing, and calls.

[0014] Further, obtaining the instantiated code snippet corresponding to each business component instance includes: Load the mapping relationship between pre-built component instances and code template storage paths; In the mapping relationship, based on the component type and configuration, and combined with the position and inbound / outbound edge information of the instance node in the clinical pathway execution graph, the storage path of the standardized code template or code generator with context awareness corresponding to each business component instance is found. Based on the storage path, the code generator is read or invoked, and relevant context parameters of the clinical pathway execution graph are passed in to generate instantiated code snippets corresponding to each business component instance that conform to its configuration attributes and runtime context.

[0015] Furthermore, the method also includes source code adaptation and optimization steps: Identify the clinical and technical requirements of the target deployment environment, including medical data standards, database types, privacy computing frameworks, and front-end device compatibility; Based on the identified environmental requirements, the corresponding adapter code is selected from the preset adaptation rule base. The adapter code includes a medical data format converter, a privacy and security enhancement module, and a cross-platform rendering adapter. When finally generating deployable source code, the selected adapter code is automatically injected into the corresponding data flow node or computing node in the clinical pathway execution graph. The generated source code is then subjected to targeted performance optimization and medical compliance checks to ensure that the generated system meets the operational and regulatory requirements of the target medical environment.

[0016] Compared with the prior art, the present invention achieves the following beneficial effects: This invention first obtains the original medical domain configuration description file edited and generated by the user in a medical business visualization modeler; then, it parses the file to extract functional component definitions and component relationship graphs; next, it constructs a functional component registry based on the component definitions and recursively instantiates each component into a clinical path execution graph representing the business logic, combined with the relationship graph; finally, it converts the execution graph into deployable source code that conforms to the target technology stack specifications. This invention abstracts medical business through visual modeling and accurately expresses clinical paths and data dependencies using graph structures, achieving automated and standardized generation from business requirements to high-quality source code, significantly improving the efficiency, standardization, and maintainability of medical information system development. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a method for generating source code for a medical information system based on a low-code platform, as provided in an embodiment of the present invention. Figure 2 This is a schematic diagram of a medical business visualization modeler that generates medical information system source code based on a low-code platform, provided in an embodiment of the present invention. Figure 3 This is a mouse hover diagram illustrating a component selection example for generating medical information system source code based on a low-code platform, as provided in an embodiment of the present invention. Figure 4 This is a drag-and-drop illustration of a component selection example for generating medical information system source code based on a low-code platform, provided in an embodiment of the present invention. Figure 5 This is a schematic diagram of a low-code development platform version management system for generating medical information system source code based on a low-code platform, provided by an embodiment of the present invention. Detailed Implementation

[0018] The present invention will now be described in detail with reference to the accompanying drawings.

[0019] Example 1

[0020] This invention provides a method for generating source code for a medical information system based on a low-code platform, such as... Figure 1 This includes the following steps: S1. Obtain the original medical domain configuration description file of the target medical application. The original medical domain configuration description file is obtained by the user through interactive editing in the medical business visualization modeler of the low-code development platform. The target medical application refers to a specific medical information system that is to be developed or has already been developed. It is built on a low-code platform and can be an electronic medical record system, a medical order management system, a medical image reporting system, or other types of medical software products. The original medical domain configuration description file is the core metadata file describing the structure and behavior of the target medical application. It contains all the necessary business information of the application, such as medical business component definitions, clinical data models, user interface layouts, business rules, and process logic. The low-code development platform is a dedicated development platform for medical informatics. Medical domain experts (such as clinical engineers and IT personnel) can create applications by dragging and dropping medical business components, setting business attributes, and defining clinical logic. The medical business visualization modeler is a core tool in the low-code development platform, allowing users to edit and design medical business logic and processes through a graphical interface. Users can add business components, adjust clinical pathway structures, configure data interfaces, and set medical rules in the modeler.

[0021] In this embodiment, developers can access the medical business visualization modeler by triggering the "Create New Medical Project" function in a low-code development platform. Developers can create a new medical application project in the modeler, such as building an "Outpatient Electronic Medical Record System." The medical business visualization modeler is as follows: Figure 2As shown, users can use the drag-and-drop functionality in the modeler to add necessary medical business components, such as patient information registration forms, prescription creation panels, test and examination requisition forms, report viewers, etc. Component selection, for example... Figure 3 and such Figure 4 As shown. The developers also configured the application's core medical data model, defining the relationships between clinical entities such as patients, diagnoses, medical orders, and laboratory tests. Using a medical business visualization modeler, the developers further configured the application's clinical pathways, user roles and permissions, and interface styles. After editing, the developers saved the data, and the low-code platform generated a raw medical domain configuration description file. This file, in a structured data format (such as JSON or YAML), contains all the application's business definitions, process configurations, and constraint information, serving as the sole input source for subsequent source code generation.

[0022] It should be noted that the aforementioned medical business visualization modeler provides an interactive design environment based on directed graphs for defining and orchestrating clinical pathways, specifically including: The medical business component library contains predefined medical business functional units, which include at least: patient management component, medical order processing component, test and examination request component, medical record document component, medical rule engine component, and system integration component; The visualization canvas allows users to add components from the medical business component library to the canvas by dragging and dropping, and define the data flow and triggering conditions between components by connecting lines to build a clinical business process diagram. The Medical Business Properties panel is used to configure each business component added to the canvas in detail. The configuration content includes, but is not limited to: data source binding of the component, business logic rules, clinical terminology codes (such as ICD-10, LOINC), user role permissions, and interface mapping with other systems. The clinical pathway simulator is used to perform sandbox simulations of existing business process diagrams to verify their logical correctness, data integrity, and process closure.

[0023] The components in the medical business component library are encapsulated based on a medical domain meta-model. Each component includes: Functional semantic tags are used to identify the core functions of the components in the clinical pathway, such as "identity registration", "diagnosis entry", and "medication review". The input / output interface specification defines the data format and structure received and generated by the component, and the interface specification follows medical information exchange standards such as HL7 FHIR. Built-in business rule templates are used to pre-set common usage rules for the component types. Users can enable, parameterize, or customize them in the property panel. A compliance constraint statement is used to declare the medical regulations and safety requirements that the components must meet in design and operation, such as patient privacy protection levels and operational audit requirements.

[0024] The user interacts and edits the medical business visualization modeler on the low-code development platform, including: The user creates a starting node on the visualization canvas that represents the medical business process in the target medical application; Select the required business components from the medical business component library and drag them onto the canvas as activity nodes in the medical business process; Connect the start node, activity node, and end node using connecting lines, and set the flow conditions on the connecting lines. The flow conditions are defined based on clinical data, time, or user roles. Through the medical business attribute panel, specific parameters can be configured for each activity node, completing the transformation from abstract components to specific business logic instances; After configuration, the clinical pathway simulator is used to simulate the entire medical business process by inputting test data, observing data flow and status changes, and iteratively optimizing the medical business process based on the simulation results.

[0025] The interactive editing by the user in the medical business visualization modeler of the low-code development platform also includes: The user's interactive editing process in the medical business process modeler is recorded in real time and converted into a structured, machine-readable medical domain configuration description file; The process of generating the medical domain configuration description file includes: The system listens for all user operations on the canvas, including adding, deleting, modifying, and configuring attributes. Each business component is instantiated as a configuration object. The properties of the configuration object include type, unique identifier, position in the canvas, all configured property values, and connection relationships with other component instances. All configuration objects and connections are organized and serialized according to a preset JSON Schema or XML Schema to form the final original medical domain configuration description file.

[0026] S2. Parse the medical domain configuration description file to generate the functional component definition and component relationship graph of the target medical application. The functional component definition is used to define the attributes and behavioral logic of each business component in the target medical application. The component relationship graph is used to describe the hierarchical structure and data flow / control flow connection relationship of each business component. S3. Construct the functional component registry of the target medical application according to the functional component definition; S4. Based on the functional component registry and component relationship graph, each business component is recursively instantiated into a clinical path execution graph, which is represented by a graph structure, where nodes are business component instances and edges are data flow or control flow dependencies. S5. Convert the clinical pathway execution graph into deployable and executable source code that meets the technical stack requirements of the target medical information system, and use it as the final executable code corresponding to the target medical application.

[0027] Deployable and executable source code refers to high-level programming language code (such as Java, TypeScript, etc.) that can be directly processed by the compiler or interpreter of the target technology stack and can be compiled, built, and run in a production environment. The target medical information system technology stack refers to the specific combination of development frameworks, programming languages, databases, and middleware used to generate the medical information system, such as Java Spring Boot microservice architecture paired with the Vue.js front-end framework, or .NET Core paired with React, etc. The final executable code refers to a complete software program that can be independently deployed, run, and implement the predetermined medical business functions. The code management version of the low-code development platform is as follows: Figure 5 As shown.

[0028] In this embodiment, the specific process of converting a clinical pathway execution graph into deployable and executable source code that meets the requirements of the target medical information system's technology stack includes: traversing and obtaining each target business component instance in the clinical pathway execution graph; obtaining the instantiated code fragment corresponding to each target business component instance; performing syntax analysis and semantic transformation on the instantiated code fragment of each target business component instance to obtain an intermediate representation form corresponding to the target technology stack; performing deep business logic analysis on the intermediate representation form to determine the precise implementation version of each called business function or API in the instantiated code fragment of each target business component instance; identifying functions / APIs with a single deterministic version and fixed dependencies as static binding items, and identifying functions / APIs with multiple versions, dynamic binding, or dependencies that change according to the execution graph path as dynamic binding items, thereby obtaining a set of static binding items and a set of dynamic binding items for each target business component instance; determining the code generation order and module dependencies based on the topology of the clinical pathway execution graph, and converting and integrating the set of static binding items and the set of dynamic binding items for each target business component instance into a deployable source code project that conforms to the target technology stack specifications.

[0029] Specifically, the process of converting and integrating the static and dynamic binding sets of each target business component instance into deployable source code that conforms to the target technology stack specifications includes: generating source code for direct import and invocation for the static bindings of each target business component instance, and generating indirect invocation source code for the dynamic bindings based on clinical pathway execution graph routing resolution or service discovery mechanisms, thus obtaining the complete business logic implementation code set for each instance; structuring the complete business logic implementation code set of each target business component instance according to the business execution order and module dependency relationships defined in the clinical pathway execution graph, and then combining and integrating it with the standard project structure template, dependency management configuration file, data access layer code, and deployment description file of the target technology stack to generate the final deployable source code project that can be directly imported into an integrated development environment (IDE) for building.

[0030] Specifically, the process of generating direct call code for the static binding items of each target business component instance includes: obtaining the underlying service framework or basic public library file pre-generated for the target technology stack; analyzing the execution context and data flow of each node according to the clinical pathway execution graph, parsing and accurately locating all function / API identifiers in the static binding items of each target business component instance to the specific class and method positions in the underlying service framework or basic public library file, and obtaining the complete reference path of each static binding item; and generating source code statements containing precise package import, dependency injection, and context parameter passing based on the complete reference path and its upstream and downstream node information in the clinical pathway execution graph.

[0031] Specifically, the process of obtaining the instantiated code fragment corresponding to each target business component instance includes: loading a pre-established mapping relationship library between component instance types and standardized code template storage paths; in this mapping relationship library, based on the business type and specific configuration attributes of the component, and combined with the topological position of the instance node in the clinical pathway execution graph and the business context defined by the incoming / outgoing edges, finding the storage path of a standardized code template or dedicated code generator with context awareness and configuration adaptation capabilities corresponding to each target business component instance; based on the storage path, reading or dynamically calling the corresponding code generator, and passing in the relevant context parameters and configuration attributes of the clinical pathway execution graph, generating an instantiated code fragment corresponding to each target business component instance that conforms to its own configuration and is integrated with the overall business process context.

[0032] Furthermore, after obtaining the final executable code corresponding to the target medical application, the source code project can be compiled, packaged, and deployed in any server, cloud platform, or container environment that meets the requirements of the target technology stack.

[0033] In this application embodiment, on the one hand, the clinical pathway execution graph of this application accurately represents the data flow, control flow dependencies, and complete clinical business processes between medical business component instances using a graph structure. Therefore, the business logic of each component can be converted into deployable source code that conforms to industrial-grade standards in an orderly and efficient manner. This enables medical business models designed based on low-code platforms to directly produce high-quality, maintainable production-grade code, eliminating the tedious work and consistency risks of traditional manual coding, and achieving the goal of "visual design and automated development," thereby greatly improving the development efficiency and delivery quality of medical information systems. On the other hand, this application recursively instantiates each business component into a structured clinical pathway execution graph through a functional component registry and a component relationship graph. The functional component definition clearly defines the attributes and behaviors of each component, and the relationship graph describes the hierarchy and interaction relationships between components. This allows the generated execution graph to unambiguously represent the internal logic and architecture of complex medical systems, which not only facilitates developers' understanding and maintenance but also lays a solid foundation for subsequent accurate and automated code generation.

[0034] Specifically, this embodiment first obtains the original medical domain configuration description file edited and generated by the user in the medical business visualization modeler; then, it parses the file to extract functional component definitions and component relationship graphs; next, it constructs a functional component registry based on the component definitions and recursively instantiates each component into a clinical pathway execution graph representing the business logic, combined with the relationship graph; finally, it converts the execution graph into deployable source code that conforms to the target technology stack specifications. This embodiment abstracts medical business through visual modeling and accurately expresses clinical pathways and data dependencies using graph structures, achieving automated and standardized generation from business requirements to high-quality source code, significantly improving the efficiency, standardization, and maintainability of medical information system development.

[0035] In the above embodiments, specifically, constructing the functional component registry of the target medical application according to the functional component definition includes: An initial registry is constructed using a key-value pair data structure. The initial registry is used to store the mapping relationship between the unique identifier of a component and the corresponding component implementation. The component implementation is the specific implementation code of the component or a module reference. Based on the functional component definition, obtain the component identifier, component type, configuration attribute set, and reference information of nested sub-components for each business component from the original medical domain configuration description file; Based on the component type, configuration attribute set, and reference information of nested sub-components, the specific implementation code or module reference of each component is dynamically generated or associated to obtain the component implementation of each component; Establish a mapping relationship between the component identifier of each component and the component implementation of each component to obtain the registration entry of each component; The registration entry for each component is stored in the initial registry to obtain the functional component registry of the target medical application.

[0036] It should be noted that, in this embodiment, this step constructs a core asset index hub for the medical application. The functional component registry is essentially a directory system maintained in memory for rapid retrieval and instantiation of business components. Its construction process is as follows: An initial empty registry is constructed using a key-value data structure (such as Java's HashMap or a similar efficient data structure). The "keys" of this registry are unique identifiers for each component (e.g., "patient_registration_form_v1.2"), while the "values" are the component implementations. Here, "component implementation" is an abstract concept that may refer to several specific forms: Pre-compiled binary module references: For some standard, mature medical business components (such as the "Patient Resources" processing module that conforms to the HL7 FHIR standard), the actual package can be a pre-packaged JAR file, DLL library, or a reference path to a Node.js module.

[0037] Dynamically generated code snippets: For user-defined or configurable components, the system will call the template engine in real time to generate a specific Java class, TypeScript interface or SQL script based on its definition, and use the location of this code in memory or temporary file as its implementation.

[0038] Remote service interface proxy: For components that depend on external microservices or third-party APIs (such as components that call external "drug knowledge bases"), the component can be a proxy object of a configured REST client or gRPC stub.

[0039] The core of the construction process is to extract metadata from the parsed functional component definitions. The system will traverse the original configuration description file and extract the component identifier (for unique identification), component type (such as "form component", "rule engine component", "data integration component"), detailed set of configuration attributes (such as data fields, validation rules, style definitions) and reference information of nested sub-components (such as a "medical order entry panel" component referencing two sub-components, "drug selector" and "dosage calculator").

[0040] Based on this information, the system performs implementation parsing: for standard components of known types, the corresponding implementation modules are loaded directly from the platform's built-in component repository; for highly customized components, the code template dynamic generation engine is triggered to assemble a code skeleton that conforms to its business logic based on its type and configuration attributes.

[0041] Finally, the system creates an entry for each component in the registry, establishing a mapping relationship from the abstract business component identifier to its specific technical implementation (implementation). This registry is a crucial bridge for subsequently transforming the visual business model into executable code.

[0042] In the above embodiments, specifically, the functional component registry includes a mapping relationship between the component identifier of each component and the component implementation of each component, and the component relationship graph is used to describe the hierarchical structure and connection relationship of each business component; The step of recursively instantiating each business component into a clinical pathway execution graph based on the functional component registry and component relationship graph includes: Based on the hierarchical structure of each business component, create corresponding directed graph nodes, with each node representing a business component; Based on the data flow / control flow connection relationships in the component relationship graph, directed edges are created between the directed graph nodes to assemble and generate a clinical path execution graph that represents the complete business logic; Recursively traverse each target directed graph node in the clinical pathway execution graph; For each target directed graph node traversed, obtain the component identifier corresponding to that node; Obtain the target component implementation corresponding to the component identifier from the mapping relationship in the functional component registry; Using the target component implementation, each target directed graph node is instantiated to generate a corresponding component instance, ultimately resulting in a clinical path execution graph containing instantiated component nodes and actual data dependency edges.

[0043] In the above embodiments, specifically, the step of creating corresponding directed graph nodes based on the hierarchical structure of each business component includes: Traverse the hierarchical structure of each business component to determine the top-level component and the nested components under the top-level component. Based on the top-level components and their definition information, the starting node of the clinical pathway execution graph is generated; Based on the nested components at each level and their respective component definition information, subsequent nodes corresponding to the nested components at each level are recursively generated.

[0044] It should be noted that the above steps demonstrate how to assemble discrete components into a workable business process: Step 1: Create directed graph nodes The system first traverses the hierarchical structure described in the component relationship graph in a top-down manner. For example, an "outpatient visit process" is the top-level component, which contains sub-components such as "registration," "triage," and "doctor consultation." The system creates a directed graph node in memory for each component (whether top-level or nested). This node is a data structure that currently only contains meta-information such as the component's identifier and type, without loading the specific implementation. This process is recursive, meaning the system will delve deeper into each level of nesting until all leaf nodes (components that no longer contain sub-components) have been created.

[0045] Step 2: Assemble the clinical pathway execution diagram After creating all nodes, the system draws directed edges between these nodes based on the data flow (e.g., "patient information" flowing from the registration node to the triage node) and control flow (e.g., the "triage completed" event triggering the "doctor's consultation" start) connections defined in the component relationship graph. For example, an edge from the "registration successful" node points to the "triage queue" node, and the edge may be labeled with the variable name (patientInfo) of the data transfer. In this way, a static, descriptive relationship graph is transformed into a dynamic, traversable directed graph, which we call the clinical pathway execution graph.

[0046] Step 3: Node Instantiation The next step is the "flesh-and-blood" process. The system recursively traverses every node in the execution graph. For each node (the target directed graph node), it uses the node's identifier as the "key" to query the previously established functional component registry. It retrieves the corresponding component implementation (i.e., the concrete implementation code or module reference) from the registry. Then, the system calls the initialization method of this implementation, instantiating it based on the node's context in the graph (such as predecessor nodes, successor nodes, and passed data constraints). The instantiation result is a business component instance, a runtime object containing specific business logic, bound data, and ready to be invoked.

[0047] Ultimately, a complete clinical pathway execution graph is generated, consisting of instantiated component nodes and edges representing actual dependencies. The clinical pathway execution graph accurately describes the execution logic and data flow of medical services.

[0048] In the above embodiments, specifically, the directed graph nodes include a start node and subsequent nodes; The step of creating directed edges between the directed graph nodes based on the data flow / control flow connection relationships in the component relationship graph, and assembling to generate a clinical path execution graph representing the complete business logic, includes: Obtain a basic directed graph framework representing the initial logic of the application; Based on the connection relationships in the component relationship graph, the positions and connection relationships of the starting node and subsequent nodes in the basic directed graph framework are determined. The connection relationships include data flow direction, triggering conditions, and execution order. Based on the positions and connections, the starting node, subsequent nodes, and their connecting edges are inserted into the basic directed graph framework to form the clinical pathway execution graph.

[0049] In the above embodiments, specifically, converting the clinical pathway execution graph into deployable and executable source code that meets the requirements of the target medical information system's technology stack includes: Iterate through the clinical path execution graph to obtain the business component instance corresponding to each directed graph node; Obtain the instantiation code snippet corresponding to each business component instance; The instantiated code fragments of each business component instance are subjected to syntax analysis and compilation transformation to obtain an intermediate representation. Deep semantic analysis is performed on the intermediate representation, and the dependencies defined by the edges between nodes in the clinical pathway execution graph are combined to determine the exact version or implementation of each called business function or API in the instantiated code fragment; Functions / APIs with a single deterministic version or implementation and fixed dependencies are identified as static binding items, while functions / APIs with multiple versions, dynamic bindings, or dependencies that change according to the execution graph path are identified as dynamic binding items, resulting in a set of static binding items and a set of dynamic binding items for each business component instance; Based on the topology of the clinical pathway execution graph, the generation and assembly order of the code is determined, and the static binding item set and dynamic binding item set of each business component instance are converted and integrated into deployable source code that conforms to the target technology stack specification.

[0050] In the above embodiments, specifically, the step of converting and integrating the static binding item set and dynamic binding item set of each business component instance into deployable source code that conforms to the target technology stack specification includes: For each business component instance, generate direct call code for static binding items and generate indirect call code based on clinical pathway execution graph routing or service discovery for dynamic binding items, thus obtaining a complete call logic code set for each instance; The complete call logic code set of each business component instance is arranged according to the execution order and dependency relationship defined in the clinical pathway execution graph, and then combined and rendered with the project structure template, dependency configuration and deployment description file of the target technology stack to generate the final deployable source code project.

[0051] It should be noted that the key transformation from an "executable model" to "deployable code" in the above steps is as follows: Step 1: Extraction and Conversion The system traverses the clinical pathway execution graph, and for each instantiated business component instance in the graph, obtains its corresponding instantiated code snippet. These code snippets are oriented towards a general intermediate representation. The system first performs syntax analysis on them to ensure structural correctness, and then compiles them into a language-independent intermediate representation (such as an extended form of an abstract syntax tree, AST).

[0052] Step Two: Semantic Analysis and Binding Decision This is the core of improving the quality of generated code. The system performs deep semantic analysis on the intermediate representation, focusing on function or API calls. Combining information from the edges in the clinical pathway execution graph (such as data dependencies and execution conditions), the system needs to determine the precise target of each call point. For example: Static bindings: These are cases where the graph structure is defined and the calling target is unique. For example, a function that "calculates a patient's age" has a fixed implementation logic and calls the same standard library function in any path within the graph; the system will recognize this as a static binding.

[0053] Dynamic bindings: For targets that depend on runtime state or graph execution paths, such as a "send notification" component, whether it ultimately calls the SMS API or the App push API may depend on the settings in the patient's profile, which cannot be determined during static graph analysis. The system will identify it as a dynamic binding and generate indirect call code based on configuration or service discovery.

[0054] Step 3: Code Generation and Assembly The system determines the final source code file organization order and module division based on the topology of the clinical pathway execution graph (such as dependencies and execution order). Then, it "translates" the static binding set and dynamic binding set of each component instance into the specific syntax of the target technology stack (e.g., selecting Java Spring Boot as the backend technology stack).

[0055] In the above embodiments, specifically, generating direct calling code for the static binding items of each business component instance includes: Obtain the underlying service framework or basic library files pre-generated for the target technology stack; Based on the clinical pathway execution graph, the execution context of each node is analyzed, and all function / API identifiers in the static binding items of each business component instance are parsed and located to the specific implementation location in the underlying service framework or basic library file, so as to obtain the function offset or reference path of each static binding item. Based on the function offset or reference path, and its upstream and downstream node information in the clinical pathway execution graph, generate source code statements that include direct imports, context passing, and calls.

[0056] In the above embodiments, specifically, obtaining the instantiated code fragment corresponding to each business component instance includes: Load the mapping relationship between pre-built component instances and code template storage paths; In the mapping relationship, based on the component type and configuration, and combined with the position and inbound / outbound edge information of the instance node in the clinical pathway execution graph, the storage path of the standardized code template or code generator with context awareness corresponding to each business component instance is found. Based on the storage path, the code generator is read or invoked, and relevant context parameters of the clinical pathway execution graph are passed in to generate instantiated code snippets corresponding to each business component instance that conform to its configuration attributes and runtime context.

[0057] It should be noted that the above steps detail how to generate code for different types of bindings. For static bindings: Assuming the target technology stack is Spring Boot, and the system has a pre-generated underlying service framework that includes basic public service classes such as PatientService and OrderService, when the system analyzes that a certain component instance needs to call the PatientService.updateStatus() method, it will locate: precisely find the fully qualified name of the PatientService class (com.hospital.core.PatientService) and the signature of the updateStatus method in the framework file, and then generate the calling code: combine the context of this node in the clinical pathway execution graph (e.g., the patientId passed from the previous node and the business logic of the current node) to generate Java code; For dynamically bound items and overall project assembly: Using dynamically bound items makes the code more flexible. For example, for the dynamic binding of "send notification", after generating the complete set of call logic code for all component instances, the system will organize these code blocks into the corresponding Service or Controller classes according to the order defined in the clinical path execution graph. Finally, these business logic codes are combined and rendered with the Spring Boot standard project skeleton (including directory structure, pom.xml dependencies, application.properties configuration file, Dockerfile, etc.) selected from the project structure template library, and output a complete source code project that can be opened directly with an IDE, compiled with Maven, and deployed with Docker.

[0058] In the above embodiments, specifically, the method further includes source code adaptation and optimization steps: Identify the clinical and technical requirements of the target deployment environment, including medical data standards (such as HL7 FHIR version), database type, privacy computing framework, and front-end device compatibility; Based on the identified environmental requirements, the corresponding adapter code is selected from the preset adaptation rule base. The adapter code includes a medical data format converter, a privacy and security enhancement module, and a cross-platform rendering adapter. When finally generating deployable source code, the selected adapter code is automatically injected into the corresponding data flow node or computing node in the clinical pathway execution graph. The generated source code is then subjected to targeted performance optimization and medical compliance checks to ensure that the generated system meets the operational and regulatory requirements of the target medical environment.

[0059] It should be understood that the above embodiments are one or more embodiments of the present invention, and there are many other embodiments and variations based on the present invention; any variations and modifications made by those skilled in the art through the present invention without making pioneering innovations are all within the protection scope of the present invention.

Claims

1. A method for generating source code for a medical information system based on a low-code platform, characterized in that, The method includes: Obtain the original medical domain configuration description file of the target medical application. The original medical domain configuration description file is obtained by the user through interactive editing in the medical business visualization modeler of the low-code development platform. The configuration description file for the medical field is parsed to generate functional component definitions and component relationship graphs for the target medical application. The functional component definitions are used to define the attributes and behavioral logic of each business component in the target medical application, and the component relationship graphs are used to describe the hierarchical structure and data flow / control flow connection relationships of each business component. Based on the functional component definitions, construct the functional component registry for the target medical application; Based on the functional component registry and component relationship graph, each business component is recursively instantiated into a clinical path execution graph, which is represented by a graph structure, where nodes are business component instances and edges are data flow or control flow dependencies. The clinical pathway execution graph is converted into deployable and executable source code that meets the technical stack requirements of the target medical information system, and serves as the final executable code corresponding to the target medical application.

2. The method for generating medical information system source code based on a low-code platform according to claim 1, characterized in that, The step of constructing the functional component registry for the target medical application based on the functional component definition includes: An initial registry is constructed using a key-value pair data structure. The initial registry is used to store the mapping relationship between the unique identifier of a component and the corresponding component implementation. The component implementation is the specific implementation code of the component or a module reference. Based on the functional component definition, obtain the component identifier, component type, configuration attribute set, and reference information of nested sub-components for each business component from the original medical domain configuration description file; Based on the component type, configuration attribute set, and reference information of nested sub-components, the specific implementation code or module reference of each component is dynamically generated or associated to obtain the component implementation of each component; Establish a mapping relationship between the component identifier of each component and the component implementation of each component to obtain the registration entry of each component; The registration entry for each component is stored in the initial registry to obtain the functional component registry of the target medical application.

3. The method for generating medical information system source code based on a low-code platform according to claim 1, characterized in that, The functional component registry includes a mapping relationship between the component identifier of each component and the component implementation of each component, and the component relationship graph is used to describe the hierarchical structure and connection relationship of each business component; The step of recursively instantiating each business component into a clinical pathway execution graph based on the functional component registry and component relationship graph includes: Based on the hierarchical structure of each business component, create corresponding directed graph nodes, with each node representing a business component; Based on the data flow / control flow connection relationships in the component relationship graph, directed edges are created between the directed graph nodes to assemble and generate a clinical path execution graph that represents the complete business logic; Recursively traverse each target directed graph node in the clinical pathway execution graph; For each target directed graph node traversed, obtain the component identifier corresponding to that node; Obtain the target component implementation corresponding to the component identifier from the mapping relationship in the functional component registry; Using the target component implementation, each target directed graph node is instantiated to generate a corresponding component instance, ultimately resulting in a clinical path execution graph containing instantiated component nodes and actual data dependency edges.

4. The method for generating medical information system source code based on a low-code platform according to claim 3, characterized in that, The step of creating corresponding directed graph nodes based on the hierarchical structure of each business component includes: Traverse the hierarchical structure of each business component to determine the top-level component and the nested components under the top-level component. Based on the top-level components and their component definition information, the starting node of the clinical pathway execution graph is generated; Based on the nested components at each level and their respective component definition information, subsequent nodes corresponding to the nested components at each level are recursively generated.

5. The method for generating source code of a medical information system based on a low-code platform according to claim 3, characterized in that, The directed graph nodes include a start node and subsequent nodes; The step of creating directed edges between the directed graph nodes based on the data flow / control flow connection relationships in the component relationship graph, and assembling to generate a clinical path execution graph representing the complete business logic, includes: Obtain a basic directed graph framework representing the initial logic of the application; Based on the connection relationships in the component relationship graph, the positions and connection relationships of the starting node and subsequent nodes in the basic directed graph framework are determined. The connection relationships include data flow direction, triggering conditions, and execution order. Based on the positions and connections, the starting node, subsequent nodes, and their connecting edges are inserted into the basic directed graph framework to form the clinical pathway execution graph.

6. The method for generating source code of a medical information system based on a low-code platform according to claim 1, characterized in that, The step of converting the clinical pathway execution diagram into deployable and executable source code that meets the requirements of the target medical information system's technology stack includes: Iterate through the clinical path execution graph to obtain the business component instance corresponding to each directed graph node; Obtain the instantiation code snippet corresponding to each business component instance; The instantiation code fragments of each business component instance are subjected to syntax analysis and compilation transformation to obtain an intermediate representation. Deep semantic analysis is performed on the intermediate representation, and the dependencies defined by the edges between nodes in the clinical pathway execution graph are combined to determine the exact version or implementation of each called business function or API in the instantiated code fragment; Functions / APIs with a single deterministic version or implementation and fixed dependencies are identified as static binding items, while functions / APIs with multiple versions, dynamic bindings, or dependencies that change according to the execution graph path are identified as dynamic binding items, resulting in a set of static binding items and a set of dynamic binding items for each business component instance; Based on the topology of the clinical pathway execution graph, the generation and assembly order of the code is determined, and the static binding item set and dynamic binding item set of each business component instance are converted and integrated into deployable source code that conforms to the target technology stack specification.

7. The method for generating medical information system source code based on a low-code platform according to claim 6, characterized in that, The step of converting and integrating the static binding item set and dynamic binding item set of each business component instance into deployable source code that conforms to the target technology stack specification includes: For each business component instance, generate direct call code for static binding items and generate indirect call code based on clinical pathway execution graph routing or service discovery for dynamic binding items, thus obtaining a complete call logic code set for each instance; The complete call logic code set of each business component instance is arranged according to the execution order and dependency relationship defined in the clinical pathway execution graph, and then combined and rendered with the project structure template, dependency configuration and deployment description file of the target technology stack to generate the final deployable source code project.

8. A method for generating source code for a medical information system based on a low-code platform according to claim 7, characterized in that, The step of generating direct call code for the static binding items of each business component instance includes: Obtain the underlying service framework or basic library files pre-generated for the target technology stack; Based on the clinical pathway execution graph, the execution context of each node is analyzed. All function / API identifiers in the static binding items of each business component instance are parsed and located to the specific implementation location in the underlying service framework or basic library file, so as to obtain the function offset or reference path of each static binding item. Based on the function offset or reference path, and its upstream and downstream node information in the clinical pathway execution graph, generate source code statements that include direct imports, context passing, and calls.

9. A method for generating source code for a medical information system based on a low-code platform according to claim 6, characterized in that, The step of obtaining the instantiated code fragment corresponding to each business component instance includes: Load the mapping relationship between pre-built component instances and code template storage paths; In the mapping relationship, based on the component type and configuration, and combined with the position and inbound / outbound edge information of the instance node in the clinical pathway execution graph, the storage path of the standardized code template or code generator with context awareness corresponding to each business component instance is found. Based on the storage path, the code generator is read or invoked, and relevant context parameters of the clinical pathway execution graph are passed in to generate instantiated code snippets corresponding to each business component instance that conform to its configuration attributes and runtime context.

10. A method for generating source code for a medical information system based on a low-code platform according to any one of claims 1-9, characterized in that, The method also includes source code adaptation and optimization steps: Identify the clinical and technical requirements of the target deployment environment, including medical data standards, database types, privacy computing frameworks, and front-end device compatibility; Based on the identified environmental requirements, the corresponding adapter code is selected from the preset adaptation rule base. The adapter code includes a medical data format converter, a privacy and security enhancement module, and a cross-platform rendering adapter. When finally generating deployable source code, the selected adapter code is automatically injected into the corresponding data flow node or computing node in the clinical pathway execution graph. The generated source code is then subjected to targeted performance optimization and medical compliance checks to ensure that the generated system meets the operational and regulatory requirements of the target medical environment.

Images