Method and device for docking various medical consumable management systems, terminal and medium

Abstract

The invention relates to the technical field of data processing, and particularly provides a method and device for docking multiple medical consumable management systems, a terminal and a medium, and the method comprises the steps: extracting key parameters from a protocol document received from any medical consumable management system, and distributing semantic tags for the key parameters; querying a target parameter corresponding to the key parameter from a pre-constructed knowledge graph by calculating the semantic similarity between the semantic tag and an entity; and generating a conversion rule according to the key parameters and the corresponding target parameters, and converting the protocol document into a standardized protocol document by using the conversion rule. According to the method, the key parameters are automatically extracted, the semantic tags are distributed, and the target parameters are intelligently mapped in combination with the knowledge graph, so that traditional point-to-point customized development or complex middleware configuration is avoided, and manpower, time and economic costs required by system docking are greatly reduced.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of data processing, and particularly relates to a method and device for interfacing multiple medical consumable management systems, a terminal and a medium. BACKGROUND

[0002] In modern medical management, the wide application of consumable management systems (such as SPD systems, high-value consumable cabinet systems, and operating room consumable systems) has significantly improved management efficiency and safety. However, due to the use of private and heterogeneous data protocols and interface standards by different manufacturers and systems deployed at different times, data interconnection and intercommunication between systems face great challenges. In the prior art, the implementation of multi-system interfacing usually relies on customized point-to-point interface development or complex middleware conversion, which not only has a long development cycle and high cost, but also has poor scalability and maintenance difficulties, making it difficult to adapt to the needs of medical institutions frequently introducing new systems or upgrading existing systems. In particular, the differences in protocol documents make semantic understanding and mapping of key parameters (such as consumable identification, inventory status, and order information) a bottleneck, and there is an urgent need for a universal interfacing method that can intelligently analyze heterogeneous protocols, automatically adapt semantic differences, and efficiently generate standardized data to solve the "information silo" problem of global medical consumable management. SUMMARY

[0003] In view of the above deficiencies of the prior art, the present application provides a method, device, terminal and medium for interfacing multiple medical consumable management systems to solve the above technical problems.

[0004] In a first aspect, the present application provides a method for interfacing multiple medical consumable management systems, comprising: extracting key parameters from protocol documents received from any medical consumable management system and assigning semantic tags to the key parameters; querying target parameters corresponding to the key parameters from a pre-constructed knowledge graph by calculating the semantic similarity between the semantic tags and entities; generating conversion rules according to the key parameters and corresponding target parameters, and converting the protocol documents into standardized protocol documents using the conversion rules.

[0005] In an optional embodiment, extracting key parameters from protocol documents received from any medical consumable management system comprises: obtaining the length of the protocol document, and if the length exceeds a set length threshold, using a sliding window processing mechanism in combination with a pre-trained BERT model to extract key parameters from the protocol document.

[0006] In an optional embodiment, assigning semantic tags to the key parameters comprises: synonymy mining and semantic similarity calculation method are used to screen matching terms from a predefined term set as semantic labels of the key parameter.

[0007] In an optional embodiment, a target parameter corresponding to the key parameter is queried from a pre-constructed knowledge graph by calculating semantic similarity between the semantic label and the entity. The semantic similarity between the semantic label of the key parameter and the entity is calculated based on a word vector method. Context information of the key parameter is obtained, and the context information includes interface function description and context parameter relationship. The matching degree of the context information of the key parameter and the context information of the entity is calculated. An entity with both the semantic similarity and the matching degree reaching a corresponding threshold is screened out as the target parameter corresponding to the key parameter.

[0008] In an optional embodiment, the semantic similarity between the semantic label of the key parameter and the entity is calculated based on a word vector method, including: The semantic label and the entity are both converted into word vectors, and the cosine similarity between the word vectors is calculated, and the cosine similarity is taken as a basic score. The data types of the key parameter and the entity are compared to see whether they are the same or compatible, and a corresponding type score is generated based on the comparison result. The value ranges of the key parameter and the entity are compared, and a corresponding value score is generated based on the value range overlap. The semantic similarity between the semantic label of the key parameter and the entity is obtained by weighted summation of the basic score, the type score and the value score.

[0009] In an optional embodiment, a conversion rule is generated according to the key parameter and the corresponding target parameter, including: According to the positions of the source parameter and the target parameter in the JSON data structure, a corresponding JSON Path expression is constructed by parsing the syntax rules of the JSON data.

[0010] In an optional embodiment, the method further includes: According to the consumable type corresponding to the key parameter, attributes of the key parameter are expanded.

[0011] In a second aspect, the application provides a device for interfacing with multiple medical consumable management systems, including: A semantic recognition module is configured to extract a key parameter from a protocol document received from any medical consumable management system, and assign a semantic label to the key parameter. The parameter matching module is configured to query a target parameter corresponding to the key parameter from a pre-constructed knowledge graph by calculating semantic similarity between the semantic label and the entity. The document conversion module is configured to generate a conversion rule according to the key parameter and the corresponding target parameter, and convert the protocol document into a standardized protocol document by using the conversion rule.

[0012] In a third aspect, a terminal is provided, comprising: The memory is configured to store a program for interfacing with multiple medical consumable management systems. The processor is configured to implement the steps of the method for interfacing with multiple medical consumable management systems when the program for interfacing with multiple medical consumable management systems is executed.

[0013] In a fourth aspect, a computer readable medium is provided, and the medium stores a program for interfacing with multiple medical consumable management systems. The program for interfacing with multiple medical consumable management systems is executed by a processor to implement the steps of the method for interfacing with multiple medical consumable management systems provided in the first aspect.

[0014] The method, device, terminal and medium for interfacing with multiple medical consumable management systems provided by the present application automatically extract key parameters and assign semantic labels, intelligently map target parameters in combination with a knowledge graph, avoid traditional point-to-point customized development or complex middleware configuration, and greatly reduce the manpower, time and economic cost required for system interfacing. The automatic parameter mapping and rule generation based on semantic similarity calculation are used to realize efficient and accurate conversion of protocol documents, reduce the risk of manual configuration errors, and ensure the real-time and reliability of standardized data. The method is independent of specific manufacturer protocols and can flexibly adapt to multiple heterogeneous medical consumable management systems. The continuous updating of the knowledge graph can easily incorporate new systems or new protocols, significantly improve the universality and future expansion capability of the solution, and effectively break down the information silos. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, brief descriptions will be given below for the drawings needed to be used in the embodiments or prior art descriptions. Obviously, for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0016] Figure 1 is a schematic flowchart of the method of one embodiment of the present application.

[0017] Figure 2 is a schematic block diagram of the device of one embodiment of the present application.

[0018] Figure 3A structural schematic diagram of a terminal provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order for those skilled in the art to better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor should fall within the scope of protection of the present application.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present application belongs. The terminology used in the description of the present application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application.

[0021] The method for interfacing multiple medical consumable management systems provided in the embodiments of the present application is executed by a computer terminal, and accordingly, the device for interfacing multiple medical consumable management systems runs in the computer terminal.

[0022] Figure 1 is a schematic flowchart of the method of an embodiment of the present application. In which, Figure 1 The execution subject can be a device for interfacing multiple medical consumable management systems. The order of the steps in the flowchart can be changed according to different needs, and some can be omitted.

[0023] As Figure 1 shown, the method comprises: S1. extracting key parameters from a protocol document received from any medical consumable management system, and assigning semantic labels to the key parameters; S2. querying a target parameter corresponding to the key parameters from a pre-constructed knowledge graph by calculating the semantic similarity of the semantic labels and entities; S3. generating a conversion rule according to the key parameters and the corresponding target parameters, and converting the protocol document into a standardized protocol document using the conversion rule.

[0024] In an embodiment of the present application, based on step S1, a possible embodiment will be given below to describe the specific implementation thereof non-restrictively.

[0025] S101. obtaining the length of the protocol document, if the length exceeds a set length threshold, adopting a sliding window processing mechanism, and extracting key parameters from the protocol document in combination with a pre-trained BERT model.

[0026] The BERT model is selected as the basic model for protocol semantic parsing. To adapt to the professional characteristics of the protocol document, a domain adaptation fine-tuning strategy is adopted. A large amount of labeled data is collected from public protocol document corpus and professional protocol documents of target industries (such as medical care, supply chain, etc.). The labeled data includes interface function description, parameter name and accurate semantic label. By fine-tuning BERT on these data, the model can better understand the professional terms and semantic structure in the protocol document.

[0027] In the actual parsing process, a sliding window mechanism is used to process long text protocols. Since protocol documents are usually long, directly inputting the model can easily lead to insufficient memory or information loss. By setting a suitable size of the sliding window, a part of the document is processed each time, and the overlapping window method is used to ensure the integrity of the information. At the same time, combined with part-of-speech tagging and named entity recognition technology, the model can more accurately locate and extract key parameter information.

[0028] S102. Adopting synonym mining and semantic similarity calculation method to screen matching terms from the pre-defined term set for the key parameter as the semantic label of the key parameter.

[0029] The accurate extraction and standardization of semantic labels are the basis for subsequent processing. For the extracted parameter names, synonym mining and semantic similarity calculation method are used to unify parameters with the same or similar semantics into standard semantic labels. For example, for "order number", "order ID", "order serial number", etc., the cosine similarity between word vectors is calculated, and when the similarity exceeds the set threshold, it is mapped to the unified semantic label #OrderID.

[0030] To cope with new terms or undefined terms that may appear in the protocol document, a dynamic semantic label expansion mechanism is constructed. Unsupervised learning algorithms such as clustering algorithms are used to analyze the clustering of unlabeled parameters and discover potential semantic categories. At the same time, combined with manual review and feedback mechanism, the newly discovered semantic categories are included in the standard semantic label system, ensuring the continuous improvement and update of the semantic label system.

[0031] In an embodiment of the present application, based on step S2, a possible embodiment will be given below to non-restrictively explain the specific implementation scheme.

[0032] When constructing the protocol knowledge graph, first, according to the business logic and professional knowledge of the target industry (such as supply chain, medical treatment, etc.), a unified industry ontology is constructed. Taking the supply chain field as an example, the core entity categories such as Order (order), Inventory (inventory), and Product (product) are defined, and the relationships between entities are clearly defined, such as the "contains" relationship between Order and Product, and the "association" relationship between Order and Inventory.

[0033] The ontology editing tool (such as Protégé) is used to design and build the ontology model, and the ontology is formally described by OWL (Web Ontology Language) language to ensure the semantic accuracy and scalability of the ontology. In the entity relationship modeling process, not only the static relationship between entities is considered, but also the dynamic relationship of time, space and other dimensions is introduced to more comprehensively reflect the actual situation in the business scenario.

[0034] With the development of business and changes in agreements, the knowledge graph needs to be updated and maintained continuously. An automatic knowledge graph update mechanism is designed, which automatically triggers the knowledge graph update process when new protocol documents or protocol changes are detected. First, the semantic extraction and parameter association of new protocol documents are performed to identify the added or changed entities and relationships.

[0035] Then, a conflict detection and fusion algorithm is used to handle the conflicts between new information and the existing knowledge graph. For repeated entities and relationships, by comparing their attributes and confidence, the more accurate information is selected for retention; for inconsistent information, manual review and domain expert knowledge are combined for correction and fusion. At the same time, the integrity and consistency of the knowledge graph are checked regularly to ensure the quality and usability of the knowledge graph.

[0036] S201. The semantic similarity between the semantic label of the key parameter and the entity is calculated based on the word vector method.

[0037] When converting semantic labels and entities into word vectors, a pre-trained word vector model is used, such as Word2Vec, GloVe, or BERT generated by the Transformer architecture. For words in semantic labels and entities, their corresponding vector representations are obtained by querying the pre-trained model's word vector table. If the word does not exist in the word vector table, character-level vector representation or context-based dynamic word vector generation methods (such as BERT's TokenEmbedding) are used to obtain its vector representation. For semantic labels and entities composed of multiple words, different aggregation strategies are adopted to generate the overall vector. Common strategies include simple average pooling, which calculates the arithmetic mean of the word vectors of all words that make up the semantic label or entity to obtain the overall vector of the semantic label or entity; or weighted average pooling, which assigns different weights according to the importance of the words in the semantic label or entity, and then calculates the weighted average. For example, the weight of a word is calculated by the TF-IDF (Term Frequency-Inverse Document Frequency) algorithm, and a word with high importance is given a higher weight, thus more accurately reflecting the semantic features of the semantic label or entity.

[0038] After obtaining the word vector representation of the semantic label and entity, the cosine similarity between them is calculated as the basic score. Cosine similarity measures the similarity of two vectors by calculating the cosine of the angle between them.

[0039] Compare whether the data types of the key parameters and the entity are the same or compatible, and generate a corresponding type score based on the comparison result. Define the similarity score rule of data types. If the data types of the key parameters and the entity are exactly the same, such as both being string type, integer type, etc., the type score is full score (set to 1); if the data types are compatible, for example, the key parameter is integer type and the entity is long integer type, they can be converted to each other in practical application without affecting the semantics, then a certain score (such as 0.8) is given according to the compatibility degree; if the data types are completely incompatible, such as the key parameter is string type and the entity is Boolean type, the type score is 0. In this way, the influence of data types on semantic similarity is quantified.

[0040] Compare the value range of the key parameters and the entity, and generate a corresponding value score based on the value range overlap. For numerical key parameters and entities, calculate the ratio of the intersection length to the union length of their value ranges as the value range overlap. For non-numerical value ranges (such as enumeration types), the overlap is calculated by judging the proportion of the number of intersection elements to the number of union elements, and then the value score is obtained.

[0041] By weighted sum of the basic score, type score and value score, the semantic similarity of the key parameter and the entity is obtained. Different dimensions of scores are given corresponding weights to reflect their importance in semantic similarity calculation. The determination of weights can adopt subjective weighting method (such as expert scoring method), according to the experience and knowledge of domain experts, to set appropriate weights for each dimension; or objective weighting method (such as entropy weight method, principal component analysis method, etc.), through analysis of a large amount of historical data, according to the variation degree of each dimension data to determine the weight, so that the weight distribution is more objective and scientific.

[0042] S202. Obtain context information of the key parameter, the context information including interface function description and context parameter relationship; and calculate a matching degree of the context information of the key parameter and context information of an entity.

[0043] The context information of the key parameter includes interface function description and context parameter relationship. In obtaining the interface function description, natural language text describing interface function is extracted by text analysis on the interface definition part in the protocol document. Text segmentation, part-of-speech tagging, named entity recognition and other technologies in natural language processing are used to preprocess the interface function description text, and key information and semantic elements are extracted. For obtaining the context parameter relationship, a parameter relationship graph is constructed. The key parameter is taken as a central node, and parameters having an association relationship with the key parameter in the same interface or related interfaces are taken as adjacent nodes. The edges between the nodes and the weights of the edges are determined by analyzing the position, calling sequence, data transmission mode and other information of the parameters in the protocol document. The weight can reflect the closeness of the association between the parameters. For example, if two parameters have a nested relationship in the data structure, the edge weight between them is high; if they only appear in the same interface in sequence but have no direct data interaction, the edge weight is low. In this way, the context information of the key parameter is comprehensively obtained, providing rich data support for subsequent matching degree calculation.

[0044] The matching degree of the context information of the key parameter and the context information of the entity is calculated. For the interface function description part, a text similarity calculation method is used, such as a text similarity calculation based on word vectors (similar to the method of calculating the semantic label similarity with the entity in the foregoing). The interface function description text of the key parameter and the context function description text related to the entity are converted into vector representation, and the cosine similarity between them is calculated as the matching degree score of the interface function description. For the context parameter relationship, the matching degree is calculated by comparing the structural similarity of the parameter relationship graph of the key parameter and the parameter relationship network (which can be constructed by the relationship between entities in the knowledge graph) in which the entity is located. The graph edit distance algorithm is used to calculate the minimum cost of the addition, deletion and modification of vertices and edges of two graphs, and the normalized score is taken as the structural similarity score.

[0045] S203. Screen out the entity whose semantic similarity and matching degree both reach the corresponding threshold value as the target parameter corresponding to the key parameter.

[0046] The entities with both semantic similarity and matching degree reaching the corresponding threshold are screened as the target parameters corresponding to the key parameters. The setting of the threshold needs to be adjusted according to the specific application scene and data characteristics. The method of experiment can be used to test on a large number of historical data, analyze the accuracy and recall rate of parameter matching under different thresholds, and select the threshold that makes the accuracy and recall rate reach a good balance as the screening standard. In the screening process, all entities to be matched are traversed, for each entity, it is judged whether its semantic similarity and context information matching degree meet the set threshold requirement at the same time. If both indicators reach the threshold, the entity is determined as the target parameter corresponding to the key parameter; if any one of the indicators does not reach the threshold, the entity is excluded. Through this strict screening mechanism, it is ensured that the target parameters screened have a high matching degree in terms of semantics and context with the key parameters, thereby improving the accuracy and reliability of parameter mapping.

[0047] In an embodiment of the present application, based on step S3, a possible embodiment will be given below to non-restrictively illustrate the specific implementation thereof.

[0048] S301. Dynamically generating conversion rules.

[0049] To realize efficient generation of conversion rules, conversion rule templates suitable for different protocol types are designed in advance. For XML format protocol, XSLT (Extensible Stylesheet Language Transformation) template is adopted, and the mapping position of source parameters and target parameters, data conversion operations (such as data type conversion, format rearrangement, etc.) and document structure adjustment logic are defined in the template. For example, when processing order protocol, the XSLT template can stipulate that the data of the order_id node in the source document is extracted and mapped to the PurchaseOrderNumber node in the standardized document, and filled according to a specific format. For JSON format protocol, JSONPath expression template is designed. The template includes path positioning rules of source parameters, output path definition of target parameters and data conversion operation instructions. For example, the id parameter in the {"order":{"id":"123"}} structure in the source JSON document is mapped to the corresponding position of the standardized document {"PurchaseOrder":{"Number":"123"}}, and necessary verification and format conversion can be performed on the data. After obtaining the matching result of the key parameters and the target parameters, the parameter information is dynamically filled into the conversion rule template. For the source parameters, according to the path information (obtained by syntax analysis) of the source parameters in the protocol document, the corresponding source parameter placeholder position in the template is determined; for the target parameters, according to the structure design of the standardized protocol document, the target position in the template is determined. For example, if the source protocol document is in XML format and the key parameter order_id is located at the path / order / order_id, the target parameter PurchaseOrderNumber should be at the path / purchaseOrder / PurchaseOrderNumber in the standardized document. When filling the XSLT template, replace the source path / order / order_id with the source parameter placeholder in the template, replace the target path / purchaseOrder / PurchaseOrderNumber with the target parameter placeholder, and integrate the parameter mapping relationship into the conversion logic in the template. During the filling process, data type conversion and format adjustment also need to be considered. If the source parameter is of string type, but the target parameter requires a specific format of date type, a corresponding data conversion function should be added during template filling, such as using the date() function in XSLT to convert the string to date format, to ensure that the converted data meets the requirements of the standardized protocol document. After generating the conversion rules, the rules need to be verified for effectiveness and optimized for performance. Effectiveness verification is performed by simulating input source protocol document data, executing the conversion rules, and checking whether the output results meet the format and semantic requirements of the standardized protocol document. A unit test framework is used to write test cases covering different types of parameter mapping scenarios to verify the correctness of the conversion rules in various situations. For performance optimization, for complex conversion rules such as XSLT scripts containing a large number of nested structures or loop operations, code compression techniques are used to reduce the script size, and algorithm optimization (such as reducing unnecessary node traversal, merging repeated operations, etc.) is used to improve the efficiency of rule execution. At the same time, a rule performance evaluation index system is established, such as execution time and memory usage, to test the performance of the optimized rules and ensure their efficient operation in actual applications.

[0050] S302. Convert the protocol document.

[0051] Before converting the protocol document, first parse the syntax of the source protocol document. For XML documents, use DOM (Document Object Model) or SAX (Simple API for XML) parser to parse the document into a tree structure, making it easy to obtain node information and parameter positions in the document. For JSON documents, use a JSON parsing library to convert them into object or array form for subsequent parameter extraction and processing. During parsing, record the path information, data type, and context information of each key parameter to provide accurate data basis for subsequent application of conversion rules. At the same time, perform integrity and format checking on the document to ensure that the source protocol document meets the expected format specifications and avoids conversion failures due to document format errors. The generated conversion rule is applied to the source protocol document. According to the conversion rule type, the corresponding execution engine is selected. For XSLT rules, the XSLT processor is used to load the rule and the source XML document, process the document according to the conversion logic defined by the rule, replace the source parameters with the target parameters, and adjust the document structure to generate the conversion result in the intermediate format. For JSONPath expression rules, the JSON processing tool is used to locate the source parameters according to the expression, convert them to the target parameter format, and reorganize them according to the standardized document structure to generate the converted JSON document. During the application of the conversion rule, the conversion progress and abnormal situations are monitored in real time. If parameter mapping fails, data types do not match, etc., error information is recorded in time and the conversion is terminated for subsequent troubleshooting and correction. The converted document is subjected to standardization verification to ensure that it meets the format specifications and semantic requirements of the target protocol. The verification content includes document structure integrity (such as whether all required nodes and attributes are included), data type consistency (such as whether numerical parameters meet the specified precision and range), semantic accuracy (such as whether the parameter meaning is consistent with the standardized definition), etc. The pattern verification technology is adopted to define XMLSchema or JSONSchema for the standardized protocol document, and the converted document is subjected to pattern matching by the verifier to check whether it meets the defined standard pattern. If the verification passes, the converted document is output as a standardized protocol document for subsequent data interaction between systems; if the verification fails, the conversion rule or the source protocol document is corrected, and the conversion and verification process is executed again until a standardized protocol document that meets the requirements is generated.

[0052] In some embodiments, the device for interfacing with multiple medical consumable management systems can include a plurality of functional modules composed of computer program segments. The computer programs of each program segment in the device for interfacing with multiple medical consumable management systems can be stored in the memory of a computer terminal and executed by at least one processor to perform the functions of interfacing with multiple medical consumable management systems (see Figure 1 Description).

[0053] In this embodiment, the device for interfacing with multiple medical consumable management systems can be divided into a plurality of functional modules according to the functions it performs, as shown in Figure 2 The module referred to by the present application refers to a series of computer program segments that can be executed by at least one processor and can complete a fixed function, which are stored in the memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0054] a semantic recognition module, configured to extract a key parameter from a protocol document received from any medical consumable management system, and assign a semantic label to the key parameter; a parameter matching module, configured to query a target parameter corresponding to the key parameter from a pre-constructed knowledge graph by calculating semantic similarity between the semantic label and the target parameter; a document conversion module, configured to generate a conversion rule according to the key parameter and the target parameter, and convert the protocol document into a standardized protocol document by using the conversion rule.

[0055] Figure 3 The method for interfacing with multiple medical consumable management systems provided by the embodiments of the present application can be applied to a terminal. Those skilled in the art can understand that the terminal structure involved in the embodiments of the present application does not constitute a limitation on the terminal, and the terminal can include more or fewer components than the illustration, or combine certain components, or different component arrangements. In the embodiments of the present application, the terminal includes but is not limited to a laptop computer, a desktop computer, a workstation, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The terminal can also represent various forms of mobile devices, such as a personal digital processor, a cellular phone, a smart phone, a wearable terminal, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of the present application described herein and / or claimed.

[0056] The terminal 300 can include a processor 310, a memory 320, and a communication unit 330. These components communicate through one or more buses, and those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation on the present application, and it can be a bus structure or a star structure, and can include more or fewer components than the illustration, or combine certain components, or different component arrangements.

[0057] The memory 320 can be used to store execution instructions of the processor 310, and the memory 320 can be implemented by any type of volatile or non-volatile storage terminal or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the terminal 300 can execute part or all of the steps in the following method embodiments.

[0058] The processor 310 is a control center of the storage terminal, connects various parts of the entire electronic terminal by using various interfaces and lines, and performs various functions of the electronic terminal and / or processes data by running or executing software programs and / or modules stored in the memory 320 and calling data stored in the memory. The processor can be composed of an integrated circuit (IC), for example, can be composed of a single packaged IC, or can be composed of a plurality of packaged ICs connected together. For example, the processor 310 can only include a central processing unit (CPU). In the embodiments of the present application, the CPU can be a single operation core or can include multiple operation cores.

[0059] The communication unit 330 is configured to establish a communication channel, so that the storage terminal can communicate with other terminals. The communication unit 330 receives user data sent by other terminals or sends user data to other terminals.

[0060] The present application also provides a computer medium, wherein the computer medium can store a program, and the program can include some or all steps in the embodiments provided by the present application when executed. The medium can be a magnetic disc, an optical disc, a read-only memory (ROM) or a random access memory (RAM), etc.

[0061] Those skilled in the art can clearly understand that the technology in the embodiments of the present application can be realized by means of software and necessary general hardware platforms. Based on such understanding, the technical solutions in the embodiments of the present application can be embodied in the form of a software product, which is stored in a medium such as a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disc or an optical disc, etc. The medium can store program codes, and includes a plurality of instructions for causing a computer terminal (which can be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the method described in the embodiments of the present application.

[0062] In the present specification, the same or similar parts among various embodiments can be referred to each other. In particular, for the terminal embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0063] In several embodiments provided by the present application, it should be understood that the disclosed apparatus and method can be implemented in other manners. For example, the described apparatus embodiments are merely schematic. For example, the division of the modules is merely a logical function division. For another example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or modules, and can be in electrical, mechanical or other forms.

[0064] The modules described as separated components can or can not be physically separated, and the components displayed as modules can or can not be physical modules, i.e., can be located in one place, or can be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purposes of the embodiments.

[0065] In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0066] Although the present application has been described in detail by referring to the preferred embodiments thereof, it is to be understood that such an explanation is by way of illustration only and not by way of limitation. The scope of the present application should be limited only by the appended claims. Numerous modifications and adaptations will occur to those skilled in the art without departing from the spirit and true scope of the present application, and it is intended that all such modifications and adaptations be included within the scope of the claims.

Claims

1. A method for connecting multiple medical consumables management systems, characterized in that: include: Extracting key parameters from a protocol document received from any medical consumables management system, and assigning semantic tags to the key parameters; By calculating the semantic similarity between the semantic label and the entity, querying the target parameter corresponding to the key parameter from the pre-built knowledge graph; A conversion rule is generated according to the key parameters and the corresponding target parameters, and the protocol document is converted into a standardized protocol document using the conversion rule.

2. The method according to claim 1, characterized in that Extract key parameters from protocol documents received from any medical consumables management system, including: The length of the protocol document is obtained. If the length exceeds a set length threshold, a sliding window processing mechanism is used in combination with a pre-trained BERT model to extract key parameters from the protocol document.

3. The method according to claim 1, characterized in that Assigning semantic labels to the key parameters includes: Synonym mining and semantic similarity calculation methods are used to screen matching terms for the key parameters from a predefined term set as semantic labels for the key parameters.

4. The method according to claim 1, wherein By calculating the semantic similarity between the semantic tag and the entity, querying the target parameter corresponding to the key parameter from the pre-built knowledge graph, including: The word vector-based method calculates the semantic similarity between the semantic labels of key parameters and entities; Obtaining context information of key parameters, wherein the context information includes interface function description and contextual parameter relationships; Calculating a matching degree between the context information of the key parameter and the context information of the entity; Entities whose semantic similarity and matching degree both reach corresponding thresholds are screened out as target parameters corresponding to the key parameters.

5. The method according to claim 4, characterized in that The word vector-based method calculates the semantic similarity between the semantic labels of key parameters and entities, including: Convert the semantic label and the entity into word vectors, calculate the cosine similarity between the word vectors, and use the cosine similarity as the basic score; Compare the key parameters with the entity's data type to see if they are identical or compatible, and generate a corresponding type score based on the comparison results; Compare the value ranges of key parameters and entities, and generate corresponding value scores based on the overlap between the value ranges; By taking a weighted sum of the basic score, type score and value score, the semantic similarity between the semantic label of the key parameter and the entity is obtained.

6. The method according to claim 1, characterized in that Generate conversion rules based on key parameters and corresponding target parameters, including: According to the position of the source and target parameters in the JSON data structure, the corresponding JSON Path expression is constructed by parsing the grammatical rules of the JSON data.

7. The method according to claim 1, characterized in that The method further comprises: According to the consumable type corresponding to the key parameter, an attribute is extended for the key parameter.

8. A system for connecting to multiple medical consumables management systems, characterized in that: include: A semantic recognition module, configured to extract key parameters from a protocol document received from any medical consumables management system and assign semantic tags to the key parameters; A parameter matching module is used to query the target parameters corresponding to the key parameters from the pre-built knowledge graph by calculating the semantic similarity between the semantic label and the entity; The document conversion module is used to generate conversion rules according to key parameters and corresponding target parameters, and convert the protocol document into a standardized protocol document using the conversion rules.

9. A terminal, characterized in that: include: Memory, used to store programs for connecting to various medical consumables management systems; A processor is configured to implement the steps of the method for docking multiple medical consumables management systems as described in any one of claims 1 to 7 when executing the program for docking multiple medical consumables management systems.

10. A computer-readable medium storing a computer program, characterized in that: The readable medium stores a program for docking multiple medical consumables management systems. When the program for docking multiple medical consumables management systems is executed by the processor, the steps of the method for docking multiple medical consumables management systems as described in any one of claims 1-7 are implemented.

Images