Component automatic detection method and system based on medical information system, and electronic equipment

Abstract

The invention relates to the technical field of computers, and provides an automatic component detection method based on a medical information system, and the method comprises the steps: obtaining an interface call log of the medical information system; determining all call chains involved in the interface call log; extracting a feature vector in each call chain; performing clustering analysis on the feature vectors to obtain a clustering result; constructing a graph model based on each call chain, and identifying a community structure in the graph model according to a community detection algorithm; and grouping the call chains according to the clustering result and the community structure, and determining the call chain for constructing the target component of the medical information system. Automatic detection and generation of medical information system components are realized, and reliable component division suggestions are provided for modularized system development.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a component automatic detection method, system and electronic equipment based on a medical information system. Background Art

[0002] Most early medical information systems were monolithic architecture systems, which means packaging the entire application into a single, indivisible unit. In this architecture, all functions are tightly integrated, without obvious component divisions, and any small modification may affect the stability and performance of the entire system, making it difficult to expand and maintain. For example, the information construction of the health industry often relies on the self-built systems of hospitals and other related units, and these self-built systems are generally monolithic architecture systems, which not only have poor scalability and low reusability, but also make it difficult to meet the construction of regional cloud capabilities.

[0003] Component-based transformation means splitting the system into multiple independent, loosely coupled components to reduce the direct dependencies between components. This makes it unnecessary or rare to modify other components when modifying or updating a component. This greatly reduces the complexity and maintenance costs of the system and is very suitable for the implementation of middle-office technology, thereby realizing the construction of cloud capabilities.

[0004] Therefore, how to quickly and effectively detect and identify componentizable functions in traditional systems is an important foundation for building cloud capabilities. Summary of the invention

[0005] In order to realize automatic detection and identification of components of traditional systems, and then assist in the rapid development of components, an embodiment of the present application provides a component automatic detection method based on a medical information system, the method comprising: obtaining an interface call log of the medical information system; determining all call chains involved in the interface call log; extracting feature vectors in each of the call chains; performing clustering analysis on the feature vectors to obtain clustering results; constructing a graph model based on each of the call chains, and identifying the community structure in the graph model according to a community detection algorithm; grouping each of the call chains according to the clustering results and the community structure, and determining the call chain for constructing the target component of the medical information system.

[0006] Based on the above method, it is possible to automatically discover the functional components in the medical information system and determine the call chain corresponding to the components, so as to provide a clear code construction scope for component development, thereby assisting in the rapid development of components.

[0007] In one implementation, constructing the graph model based on each of the call chains includes: using the call objects and call relationships in each of the call chains as nodes and edges, respectively, to construct the graph model.

[0008] In one implementation, the method also includes optimizing the target component, including the steps of: determining the key nodes in each of the call chains based on the PageRank algorithm; determining the rationality of the division of the key nodes in the target component based on the principle of maximum influence of the key nodes; wherein the principle of maximum influence of the key nodes includes that the utility corresponding to the key nodes in the target component is maximum; when it is determined that the division is unreasonable, re-dividing the key nodes to obtain an optimized target component.

[0009] Based on the above technical solution, the target components can be further optimized, making the division range of the optimized target components more accurate and reasonable, thereby ensuring that the component division results of the medical information system can meet the actual needs of old system transformation or new system development.

[0010] In one implementation, the method further includes: when determining that the division is reasonable based on the principle of maximum influence of the key node, based on the cross-component call situation, adjusting the component corresponding to the node to obtain an optimized target component.

[0011] Based on the above technical solution, the target components are further optimized according to the cross-component calling situation, and the node division is adjusted to reduce the calls between components, thereby reducing the coupling between components and improving system performance and flexibility.

[0012] In one implementation, the method further includes: determining the code boundary of the target component according to the code module dependency; and generating a code disassembly suggestion based on the code boundary.

[0013] By outputting code disassembly suggestions, developers can fully understand the code boundaries and quickly split the code.

[0014] In one implementation, the method further includes: performing a flow test on the code corresponding to the target component.

[0015] In one implementation, the method further includes: before the grouping step, optimizing the community structure to obtain an optimized community structure, and grouping each of the call chains based on the clustering results and the optimized community structure to determine the call chain of the target component for constructing the medical information system.

[0016] Based on the above technical solution, the accuracy and rationality of the target component division results can be improved by optimizing the community structure.

[0017] In one implementation, the feature vector includes one or more of an interface URL path, database connection information, response time, status code, call frequency, and call parameters.

[0018] In addition, based on the same inventive concept, the present application also provides a component automatic detection system based on a medical information system, and the system is used to implement the above-mentioned component automatic detection method based on a medical information system.

[0019] And, an electronic device includes a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements an automatic detection method of components based on a medical information system. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The drawings constituting a part of the present application are used to provide further understanding of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute improper limitations on the present application.

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0022] Figure 1 A schematic diagram of the structure of a component automatic detection system based on a medical information system provided in an embodiment of the present application is shown.

[0023] Figure 2 A schematic flow chart of a component automatic detection method based on a medical information system provided in an embodiment of the present application is shown.

[0024] Figure 3 A flow chart of a method for optimizing community structure in an embodiment of the present application is shown.

[0025] Figure 4 A schematic diagram of the model in the figure in the embodiment of the present application is shown.

[0026] Figure 5 The embodiment of the present application is shown in FIG. Figure 4 Schematic diagram of community division based on the graph model shown.

[0027] Figure 6 The embodiment of the present application is shown in FIG. Figure 5 Schematic diagram of the optimized community structure shown.

[0028] Figure 7 A flow chart of a component automatic detection method based on a medical information system provided by another embodiment of the present application is shown. DETAILED DESCRIPTION

[0029] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0030] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, and "first", "second" and various digital numbers are only distinguished for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0031] The features, structures or characteristics in this application may be combined in one or more embodiments in any suitable manner. In various embodiments of this application, the size of the sequence number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0032] Some optional features in the embodiments of the present application may be implemented independently in some scenarios without relying on other features to solve corresponding technical problems and achieve corresponding effects. They may also be combined with other features in some scenarios as needed.

[0033] In this application, unless otherwise specified, the same or similar parts between the various embodiments can refer to each other. In the various embodiments of this application, if there is no special description and logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other, and the technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships. The implementation methods of this application do not constitute a limitation on the scope of protection of this application.

[0034] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0035] The automatic component detection method based on the medical information system provided in the embodiment of the present application is applied to the automatic component detection system based on the medical information system. The system is implemented based on computer software and deployed and run on a server.

[0036] In one embodiment, please refer to Figure 1 The component automatic detection system 100 based on the medical information system includes a log acquisition module 101, a log analysis module 102, a component detection module 103, a code analysis module 104, an input and output module 105 and a test module 106.

[0037] The log acquisition module 101 is used to interact with the log system of the medical information system to obtain the interface call log of the medical information system, and send the interface call log to the log analysis module 102 .

[0038] The log analysis module 102 analyzes the received interface call log, determines all call chains involved therein, extracts feature vectors of the call chains, and sends the call chains and feature vectors to the component detection module 103 .

[0039] The component detection module 103 is used to automatically detect and identify components of the received call chain and the corresponding feature vector, and send the identified component information to the code analysis module 104. The code analysis module 104 disassembles the component code according to the component information, and outputs code disassembly suggestions to the developer through the input-output module 105.

[0040] The input-output module 105 receives the component code input by the developer, tests the component code by calling the test module 106, and obtains and outputs the test result.

[0041] Based on the above system, the components of the medical information system can be discovered and disassembled to obtain the corresponding component codes, so that developers can reconstruct the medical information system based on the disassembled component codes, or rebuild the cloud service platform to obtain application services with low coupling, flexible expansion and reuse.

[0042] Please refer to Figure 2 The automatic component detection method based on the medical information system provided in the embodiment of the present application specifically includes the following steps.

[0043] S210, obtaining the interface call log of the medical information system.

[0044] During implementation, the code of the medical information system can be embedded first to output relevant log information of all interface calls and generate an interface call log, where the interface call log includes but is not limited to the interface URL path, database connection information, response time, status code, call frequency, call parameters, the traceID of the called interface, and the parenttraceID of the calling interface.

[0045] Among them, the URL path of the interface is used to reflect the functional module and business logic. The database connection information is used to reflect the source of the data and the processing object. The response time is used to reflect the performance characteristics of the call chain. The status code is used to reflect the success or failure of the request. The call frequency is used to reflect the frequency of interface use, which can be used to analyze the importance of the interface. The call parameters include but are not limited to user ID, resource ID, etc., which are used to determine the context information of the call chain.

[0046] During the operation of the medical information system, the interface call logs are monitored in real time, and all interface call logs can be collected in a unified manner using technical means such as Elasticsearch, Logstash, and Kibana, thereby supporting multi-language and multi-platform log management.

[0047] S220: Determine all call chains involved in the interface call log.

[0048] Generally speaking, a call chain is relatively stable. In a certain period of time, an interface may generate a small number of call chains. Therefore, the call chain can be assembled by sampling the interface call logs. In implementation, the related interface call logs can be connected in series based on traceID and parenttraceID, and then the corresponding call chain can be constructed by analyzing the connected interface call logs.

[0049] In one example, the interface call log can be sampled according to the http status. Specifically, 10 interface call logs related to http 200, http 404, and http 500 are sampled respectively. The status code 200 indicates a normal business flow, and the status code non-200 may trigger an abnormal business flow. Therefore, each path corresponding to the interface call log sampled based on Http 200 is a separate link. If there is an interface call log with a non-200 http status code, but there is another interface call log with a status code of 200 whose parentId points to the interface corresponding to the non-200 interface call log, then this abnormal link is meaningful and the link is retained. If there is no more http in the downstream of a non-200 request, and this non-200 link belongs to an existing link, then this link is skipped.

[0050] For example, after sampling and analysis, the link containing only http 200 is 1-2-3-4, where the numbers represent interface identifiers. There is another link 1-2 (http 500)-6-7, which means this is an abnormal link, but it is meaningful and is retained. There is another link 1-2-3 (http500), which means this part belongs to the first half of the first link, so this link is meaningless and is discarded.

[0051] S230, extracting feature vectors in each call chain.

[0052] In implementation, relevant feature vectors can be extracted from the interface call logs corresponding to each call chain. In one example, the feature vectors include one or more of the interface URL path, database connection information, response time, status code, call frequency, and call parameters.

[0053] S240, performing cluster analysis on the feature vector to obtain a clustering result.

[0054] Specifically, by using clustering algorithms such as K-means and DBSCAN, similar call chains can be clustered together based on the feature vectors of the call chains to form several clusters.

[0055] In one example, the clustering process includes: first, taking the above-mentioned feature vector and the cluster number parameter n_clusters as input, calling the k-means function to generate clusters, and then automatically adjusting the cluster number parameter n_clusters based on the SSE value, i.e., the sum of squared errors (Sum of SquaredErrors), until the optimal n_clusters is determined, and calling the k-means function based on the optimal n_clusters and the feature vector to obtain the final clustering result.

[0056] Code example:

[0057] #Based on the above feature vectors and n_clusters, call k-means to generate clusters

[0058] def kmeans_clustering(feature_vectors,n_clusters):

[0059] vectorizer=TfidfVectorizer()

[0060] X=vectorizer.fit_transform(feature_vectors)

[0061] kmeans=KMeans(n_clusters=n_clusters,random_state=0).fit(X)

[0062] return kmeans.labels

[0063] labels=kmeans_clustering(feature_vectors)

[0064] #Calculate the SSE value under different n_clusters

[0065] sse=[]

[0066] for k in range(1,10):

[0067] kmeans=KMeans(n_clusters=k,random_state=0).fit(X)

[0068] sse.append(kmeans.inertia_)

[0069] #Draw the elbow rule diagram based on the SSE value, and select the number of clusters at the inflection point as the optimal n_clusters

[0070] plt.plot(range(1,10),sse,marker='o')

[0071] plt.xlabel('Number of clusters')

[0072] plt.ylabel('SSE')

[0073] plt.title('Elbow Method for Optimal k')

[0074] plt.show()

[0075] S250: construct a graph model based on each call chain, and identify a community structure in the graph model according to a community detection algorithm.

[0076] In implementation, all call chains are used as input to construct a graph model with interfaces. Specifically, the call objects (interfaces) and call relationships in each call chain are used as nodes and edges, respectively, to construct the graph model.

[0077] In one example, the nodes in the graph model can be determined based on the URL, and the graph model can be constructed with the call relationship as the edge. The code example is as follows.

[0078] def build_graph(call_chains):

[0079] #Create an undirected graph object

[0080] G = nx.Graph()

[0081] #Traverse each call chain

[0082] for chain in call_chains.values():

[0083] #Traverse each pair of adjacent calls in the call chain

[0084] for i in range(len(chain)-1):

[0085] # Extract information about adjacent calls

[0086] url1=chain[i]["url"]

[0087] url2=chain[i+1]["url"]

[0088] response_time=chain[i]["responseTime"]

[0089] #Add an edge to the graph, the weight of the edge is the response time

[0090] G.add_edge(url1,url2,weight=response_time)

[0091] return G

[0092] In implementation, a community detection algorithm, such as the Louvain algorithm, is used to identify functionally related modules. The Louvain algorithm can automatically identify the community structure in the graph by maximizing the modularity value, and cluster closely related calls together.

[0093] S260, grouping the call chains according to the clustering results and the community structure, and determining the call chains of the target components for constructing the medical information system.

[0094] Among them, the target component is the component corresponding to any group, that is, the method provided in the embodiment of the present application can determine the call chain corresponding to all components in the medical information system.

[0095] In implementation, the community structure may be verified according to the clustering result, and when the verification result passes, it is determined to generate the corresponding component based on the community structure.

[0096] The following is an example of the code generated by the component:

[0097] def generate_components(call_chains,labels,partition):

[0098] components = {} # Initialize an empty dictionary to store generated components

[0099] #Traverse the index of each call chain and its corresponding call chain data

[0100] for idx,chain in enumerate(call_chains.values()):

[0101] label=labels[idx]#Get the clustering label of the current call chain

[0102] component_id = partition[chain[0]["url"]]#Get the community ID of the first call in the current call chain

[0103] if component_id not in components:#Check if there is already a component corresponding to this community ID in the components dictionary

[0104] components[component_id] = [] # If not, initialize a new component list

[0105] #Add the current call chain to the corresponding component list

[0106] components[component_id].append(chain)

[0107] #Return the generated component dictionary

[0108] return components

[0109] #By calling the generate_components function, the call chain is divided into multiple components

[0110] components=generate_components(call_chains,labels,partition)

[0111] The following is an explanation with examples.

[0112] For example, a system in the health care industry has several different API call chains, clustering label results, and community division results. The following are specific examples:

[0113] Assume that there are 5 different call chains in the system, represented as a dictionary structure, each call chain contains multiple calls, arranged in order.

[0114] call_chains={1:[{"url":" / patient / get","dbConnection":"db1","responseTime":120,"status":200,"requestParams":{"userId":1}},{"url":" / doctor / get","dbConnection":"db2","responseTime":100,"status":200,"requestParams":{"doctorId":10}}],

[0115] 2:[{"url":" / patient / get","dbConnection":"db1","responseTime":115,"status":200,"requestParams":{"userId":2}},{"url":" / appointment / get","dbConnection":"db3","responseTime":90,"status":200,"requestParams":{"appointmentId":20}}],3:[{"url":" / inventory / get","dbConnection":"db4","responseTime":80,"status":200,"requestParams":{"itemId":5}},{"url":" / order / create","dbConnection":"db5","responseTime":150,"status":201,"requestParams":{"orderId":30}}],

[0116] 4:[{"url":" / inventory / get","dbConnection":"db4","responseTime":75,"status":200,"requestParams":{"itemId":6}},{"url":" / order / update","dbConnection":"db5","responseTime":140,"status":200,"requestParams":{"orderId":31}}],

[0117] 5:[{"url":" / patient / get","dbConnection":"db1","responseTime":110,"status":200,"requestParams":{"userId":3}},{"url" :" / appointment / create","dbConnection":"db3","responseTime":95,"status":201,"requestParams":{"appointmentId":21}}]}

[0118] Assuming that two main functional modules are obtained after cluster analysis, the following labels are obtained to indicate the clustering affiliation of similar call chains.

[0119] labels = [0,0,1,1,0]

[0120] Among them, label 0 means that call chains 1, 2, and 5 are considered to have similar functions and may be related to patient information and appointments.

[0121] Label 1 indicates that call chains 3 and 4 are considered to have similar functions and may be related to inventory and orders.

[0122] Assume that after community detection is performed using a graph algorithm (such as the Louvain algorithm), the following community division results are obtained (with URL as the key and community ID as the value):

[0123] partition={

[0124] " / patient / get":100,

[0125] " / doctor / get":100,

[0126] " / appointment / get":100,

[0127] " / appointment / create":100,

[0128] " / inventory / get":200,

[0129] " / order / create":200,

[0130] " / order / update":200

[0131] }

[0132] Community ID 100 means that API calls related to patients and appointments, such as / patient / get, / doctor / get, / appointment / get, and / appointment / create, are grouped into one community.

[0133] Community ID 200 means that inventory and order-related API calls such as / inventory / get, / order / create, and / order / update are grouped into another community.

[0134] According to the above call_chains, labels and partition, based on the above pseudo code, the generated component results are as follows:

[0135] components = { 100:[ [

[0138] {"url":" / patient / get","dbConnection":"db1","responseTime":120,"status":200,"requestParams":{"userId":1}},

[0139] {"url":" / doctor / get","dbConnection":"db2","responseTime":100,"status":200,"requestParams":{"doctorId":10}}

[0140] ], [

[0142] {"url":" / patient / get","dbConnection":"db1","responseTime":115,"status":200,"requestParams":{"userId":2}},

[0143] {"url":" / appointment / get","dbConnection":"db3","responseTime":90,"status":200,"requestParams":{"appointmentId":20}}

[0144] ], [

[0146] {"url":" / patient / get","dbConnection":"db1","responseTime":110,"status":200,"requestParams":{"userId":3}},

[0147] {"url":" / appointment / create","dbConnection":"db3","responseTime":95,"status":201,"requestParams":{"appointmentId":21}} ]

[0149] ], 200:[ [

[0152] {"url":" / inventory / get","dbConnection":"db4","responseTime":80,"status":200,"requestParams":{"itemId":5}},

[0153] {"url":" / order / create","dbConnection":"db5","responseTime":150,"status":201,"requestParams":{"orderId":30}}

[0154] ], [

[0156] {"url":" / inventory / get","dbConnection":"db4","responseTime":75,"status":200,"requestParams":{"itemId":6}},

[0157] {"url":" / order / update","dbConnection":"db5","responseTime":140,"status":200,"requestParams":{"orderId":31}} ] ]

[0160] }

[0161] Community 100: Contains all call chains related to patients, doctors, and appointments (i.e., call chains 1, 2, and 5), because the URLs of these APIs all belong to community ID 100, and these call chains are functionally grouped together through a clustering algorithm, and are therefore classified into the same component.

[0162] Community 200: contains all call chains related to inventory and orders (i.e., call chains No. 3 and 4), because the URLs of these APIs all belong to community ID 200, and these call chains are functionally clustered into another group, so they are classified into another component.

[0163] Based on the above technical solution, cluster analysis and community detection analysis are performed on the call chains respectively, and the call chains corresponding to the target components are finally obtained based on the analysis results of the two, so as to realize the discovery of system components and determine the corresponding call chains. In the above technical solution, the label can be used as a preliminary classification mark for grouping reference for subsequent community detection. Each label represents a cluster, which reflects the attribution of the call chain in the feature vector space. If the call chains in a community have the same label, it means that they are similar in function and have a close call relationship; if the labels in the community are inconsistent, the grouping of these call chains can be readjusted to try to make the results of the two algorithms consistent.

[0164] It is understandable that the community detection algorithm is more complex in terms of graph structure. If the entire call chain graph is directly divided into communities, the computational cost will be very high. Clustering provides a preliminary grouping based on feature vectors, which reduces the amount of computation required for complex community detection. Therefore, pre-screening through clustering helps improve efficiency.

[0165] Through the dual analysis of clustering and community detection, call chains can be accurately grouped from the perspectives of feature similarity and functional closeness, avoiding the deviation that may be caused by a single method. This joint use increases the accuracy and rationality of component division, ensuring that the resulting components are both independent in logical functions and loosely coupled in call relationships.

[0166] Furthermore, in order to improve the rationality of the target component division, the present application also provides an embodiment to optimize the community structure obtained in step S205 in the above embodiment. Figure 3 , the optimization method comprises the following steps:

[0167] S310: Determine the key nodes in each call chain.

[0168] In implementation, the importance score of each node (interface) in the graph model, i.e., the PageRank score, can be calculated based on the PageRank algorithm, and the node with the highest PageRank score in each call chain is determined as the key node.

[0169] S320, optimizing the community structure based on the optimization strategy and key nodes.

[0170] In implementation, the community structure can be optimized through pre-configured optimization strategies. In one implementation, the setting principles of the optimization strategy include:

[0171] 1. Maximize influence: Ensure that the community module where the key node is located can make full use of its high PageRank score. For example, if node A contributes greatly to the overall performance of module 1, it should continue to stay in module 1.

[0172] 2. Reduce cross-module calls: If key nodes need to frequently interact with other community modules, their assignment may need to be reconsidered. For example, if node A in module 1 needs to frequently call the functions of module 2, unnecessary communication costs may be increased.

[0173] 3. Improve module independence: Let each community module run as independently as possible and reduce coupling between community modules. For example, group closely related functions together to form a highly cohesive and low-coupling community module.

[0174] It is understandable that in actual applications, optimization strategies can also be set according to the actual situation of the system or other development requirements to ensure that the optimization results meet actual business needs.

[0175] The following will illustrate the optimization process with examples.

[0176] Please refer to Figure 4 , the graph model includes call chains AE, ABC and DC, and the PageRank scores corresponding to each node are A: 0.35, B: 0.15, C: 0.25, D: 0.10, E: 0.15. In this way, it can be determined that node A is the key node in call chains AE and ABC, and C is the key node in call chain DC.

[0177] Please refer to Figure 5 , based on the community detection network algorithm Figure 4 The call chain shown in the figure is divided into two community structures: AE, AB and DC.

[0178] Please refer to Figure 6,In the optimization process based on the above principles, if the division of B nodes is adjusted, the contribution of B nodes in the DC community can be greater than in the AE and AB communities. At the same time, after the division is adjusted, the number of cross-community calls is minimized, or the edge length is shortened (i.e., the response time is shortened). In this way, the division of B nodes is readjusted to obtain the optimized community structure.

[0179] The utility of a node in a community can be determined based on its pagerank in the community. If a node contributes the most in a community, that is, ranks first, it should stay in this community during the optimization process. On the contrary, if a node contributes the least in a community, and its ranking moves up after it joins other communities, it means that it is appropriate to move to that community.

[0180] Accordingly, in the above step S260, the optimized community structure is used as input.

[0181] In other embodiments of the present application, the target component may be optimized to obtain an optimized target component, and the optimized target component may be used as the final component division result.

[0182] In the implementation, the rationality of the division of key nodes in the target component is determined based on the principle of maximum influence of key nodes; the principle of maximum influence of key nodes includes that the corresponding utility of key nodes in the target component is the largest. If the division is determined to be unreasonable, the key nodes are re-divided to obtain the optimized target component. If the division is determined to be reasonable, the components corresponding to the nodes are adjusted based on the cross-component call situation to obtain the optimized target component.

[0183] For example, you can refer to the following code example to implement it:

[0184] def optimize_components_with_pagerank(call_chains,labels,partition,pagerank_scores,critical_nodes):

[0185] components = {} # Initialize component dictionary

[0186] #Traverse each call chain

[0187] for idx,chain in enumerate(call_chains.values()):

[0188] #Get the preliminary component ID

[0189] component_id=partition[chain[0]["url"]]

[0190] # Check whether each node is a key node and optimize it

[0191] for node in chain:

[0192] url = node["url"]

[0193] if url in critical_nodes:

[0194] #Use PageRank to optimize component attribution for key nodes

[0195] component_id=optimize_based_on_pagerank(url,agerank_scores,partition)

[0196] #Update component dictionary

[0197] if component_id not in components:

[0198] components[component_id] = []

[0199] components[component_id].append(chain)

[0200] return components

[0201] #According to pagerank, each node is divided into a community corresponding to a component to ensure that the community has the highest score

[0202] def optimize_based_on_pagerank(url,pagerank_scores,partition):

[0203] # Pseudocode: Optimize component division based on PageRank score

[0204] max_pagerank=-1

[0205] best_community=partition[url]

[0206] #Find the community with the highest PageRank score

[0207] for community_id in set(partition.values()):

[0208] if pagerank_scores.get(url,0)>max_pagerank:

[0209] max_pagerank=pagerank_scores[url]

[0210] best_community=community_id

[0211] return best_community

[0212] #Call the optimization function

[0213] components=optimize_components_with_pagerank(call_chains,labels,partition,pagerank_scores,critical_nodes)

[0214] It is worth noting that based on Figure 2 The target component initially generated by the method shown is generated based on the clustering results and community structure, which is a stable and certain result. However, there is uncertainty in the above optimization process, which needs to be adjusted dynamically according to the adjustment parameters and actual evaluation criteria. For example, the division parameters of key nodes can be adjusted. Therefore, in the actual implementation process, when optimizing components, manual analysis and data verification are required to ensure that the optimization results meet the actual development requirements.

[0215] After obtaining the call chain corresponding to the target component based on the above method, the embodiment of the present application can further realize the disassembly of the component code.

[0216] Please refer to Figure 7 Based on the above method, the method provided in the embodiment of the present application further includes the following steps:

[0217] S710, determining the code boundary of the target component according to the code module dependency.

[0218] In implementation, the code boundary of the target component can be analyzed based on the function call relationship in the code module involved in the call chain corresponding to the target component. In one example, the dependency between code modules can be determined by static analysis tools or dynamic tracing tools. SonarQube and PMD can be selected as static code analysis tools, and Jaeger and Zipkin can be selected as dynamic tracing tools. Then, the code boundary of the target component can be determined by analyzing the dependency between code modules.

[0219] S720: Generate code disassembly suggestions based on code boundaries.

[0220] Determine the code content corresponding to the target component based on the code boundary, and determine the business functions that the target component can achieve based on the code content, and then generate code disassembly suggestions based on the business functions, so that developers can disassemble the system code based on the code disassembly suggestions and build an independently deployable component installation package corresponding to the target component.

[0221] In one implementation, the target component code installation package can be further subjected to traffic testing. Specifically, the rationality of component disassembly can be verified through traffic scheduling tools, such as using traffic scheduling tools such as Istio or Envoy to perform traffic testing on the target component to ensure that it can run independently and correctly handle traffic. At the same time, the performance and stability of the target component under different loads and traffic can be verified.

[0222] Based on the above technical solutions, high-availability and highly reusable independent components can be automatically generated through full-link monitoring, AI algorithms, code dependency analysis and traffic scheduling verification, which improves the development efficiency of component-based transformation of medical information systems or new system development, as well as the operation and maintenance capabilities of the transformed and new systems. Through intelligent and automated component generation and optimization, the flexibility, scalability and performance of the system are improved, ensuring the security and data integrity of the system.

[0223] In addition, an embodiment of the present application also provides an electronic device, which includes a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction, when executed by the processor, implements a method as in any one of the implementations in the embodiments of the present application; wherein the processor may adopt a general-purpose central processing unit (CPU), a microprocessor, an application specific integrated circuit (ASIC), a graphics processing unit (GPU), or one or more integrated circuits, for executing relevant programs to implement the method in any one of the implementations in the embodiments of the present application.

[0224] The processor may also be an integrated circuit electronic device with signal processing capability. In the implementation process, each step of the method in any implementation of the embodiments of the present application may be completed by an integrated logic circuit of hardware in the processor or by instructions in software form.

[0225] The above-mentioned processor can also be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware decoding processor to be executed, or the hardware and software modules in the decoding processor can be combined and executed.

[0226] The software module may be located in a random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, register or other mature storage media in the art. The storage medium is located in the memory, and the processor reads the information in the memory, and combines its hardware to complete the functions required to be performed by the units included in the data processing device of the embodiment of the present application, or executes the method in any one of the implementation modes in the embodiment of the present application.

[0227] The above are all preferred embodiments of the present application, and the protection scope of the present application is not limited thereto. Therefore, any equivalent changes made according to the structure, shape, and principle of the present application should be included in the protection scope of the present application.

Claims

1. A component automatic detection method based on a medical information system, characterized in that: The method comprises: Obtain the interface call log of the medical information system; Determine all call chains involved in the interface call log; Extracting feature vectors in each of the call chains; Performing cluster analysis on the feature vector to obtain a clustering result; Building a graph model based on each of the call chains, and identifying a community structure in the graph model according to a community detection algorithm; The call chains are grouped according to the clustering results and the community structure to determine the call chains for constructing the target components of the medical information system.

2. The method according to claim 1, characterized in that: The constructing of the graph model based on each of the call chains includes: The calling objects and calling relationships in each of the calling chains are used as nodes and edges respectively to construct the graph model.

3. The method according to claim 1, characterized in that The method further comprises optimizing the target component, comprising the steps of: Determine the key nodes in each of the call chains based on the PageRank algorithm; Based on the principle of maximum influence of key nodes, determining the rationality of the division of the key nodes in the target component; wherein the principle of maximum influence of key nodes includes that the utility corresponding to the key nodes in the target component is maximum; When it is determined that the division is unreasonable, the key nodes are re-divided to obtain optimized target components.

4. The method according to claim 3, characterized in that The method further comprises: When the reasonable division is determined based on the principle of maximum influence of the key nodes, the components corresponding to the adjustment nodes are adjusted based on the cross-component calling situation to obtain the optimized target components.

5. The method according to claim 1, 3 or 4, characterized in that: The method further comprises: determining the code boundary of the target component according to the code module dependency; Based on the code boundaries, a code disassembly suggestion is generated.

6. The method according to claim 5, characterized in that The method further comprises: A flow test is performed on the code corresponding to the target component.

7. The method according to claim 1, characterized in that The method further comprises: Before the grouping step, the community structure is optimized to obtain an optimized community structure, and each of the call chains is grouped based on the clustering result and the optimized community structure to determine the call chain of the target component for constructing the medical information system.

8. The method according to claim 1, characterized in that The feature vector includes one or more of the following: interface URL path, database connection information, response time, status code, call frequency, and call parameters.

9. A component automatic detection system based on a medical information system, characterized in that: The system is used to implement the method according to any one of claims 1 to 8.

10. An electronic device, characterized in that: The method comprises a processor, a memory, and a program or instruction stored in the memory and executable on the processor, wherein the program or instruction implements the method according to any one of claims 1 to 8 when executed by the processor.

Images