A method and device for automatically generating an electronic medical record

CN122266613BActive Publication Date: 2026-08-11SHANGHAI MEEHEALTH INFORMATION TECHNOLOGY CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2026-05-25
Publication Date
2026-08-11

AI Technical Summary

Technical Problem

[0004]然而,现有的低代码电子病历编辑器缺乏对非结构化或半结构化原始病历文档的智能化解析与自动转换能力

Benefits of technology

[0017]By employing the above technical solution, the text content of each field in a structured electronic medical record document is extracted and the field semantic vector is calculated. This converts the semantic information of the fields into a computable vector representation, obtains the standard semantic vectors corresponding to each standard data source path in a preset basic data source library, and calculates the semantic similarity score between the field semantic vector and each standard semantic vector. The most suitable data source path is found based on semantic level rather than simple string matching, improving the accuracy of data source binding. Automatic binding is determined by whether the highest score is greater than or equal to a preset similarity threshold. When the highest score reaches the threshold, the field is matched with the corresponding standard data source. The path binding enables fully automated data source configuration under high confidence conditions, completing the binding of most fields without manual intervention. When the highest score is lower than the preset similarity threshold, the field is marked as pending binding and a prompt message is generated, avoiding incorrect binding under low confidence conditions. By receiving custom data source paths input by the user for fields in the pending binding state, the accuracy of data source configuration is ensured. At the same time, the custom data source paths are added to the preset basic data source library, enabling the data source knowledge base to be continuously expanded and optimized. After all fields are bound, an electronic medical record template is generated and output, ensuring the data integrity and usability of the output template.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122266613B_ABST
    Figure CN122266613B_ABST
Patent Text Reader

Abstract

A method and apparatus for automatically generating electronic medical records (EMRs) relates to the field of healthcare informatics technology. The method involves receiving a user-inputted original document containing medical record information and an output structured document type; parsing the original document to obtain multiple text blocks and their geometric layout, content, and format information; determining the structure type of each text block based on its geometric layout, content, and format information; generating a structured EMR document based on the structure types of the text blocks and the output structured document type; identifying text blocks with special control types; matching and binding corresponding special controls in the structured EMR document based on the semantic information of the text blocks' content; binding corresponding data source paths based on the semantic information of each field in the structured EMR document; and outputting an EMR template. This method improves the efficiency of EMR template generation.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of healthcare informatics technology, specifically to a method and apparatus for automatically generating electronic medical records. Background Technology

[0002] With the rapid development of medical informatization, electronic medical records (EMRs) have become an indispensable and important component of the modern healthcare system. EMRs not only effectively record patients' consultation information, examination results, and medical history, but also provide fundamental support for the sharing, retrieval, and analysis of medical data. To standardize medical records and improve the interoperability of information systems, medical institutions typically need to create structured EMR templates that conform to specific standard formats. These structured templates form the basis for the front-end interaction and data flow of various medical software, such as emergency clinical information systems.

[0003] Currently, the industry primarily uses low-code electronic medical record (EMR) editor technology to build EMR templates. These editor systems typically include core modules such as template creation and data source management. Technically, low-code editors provide a visual interactive interface and have a built-in rich library of form components, covering various controls such as text boxes, tables, radio buttons, checkboxes, and dropdown lists. They render the corresponding form layout by receiving drag-and-drop and layout commands from the front-end interface and set the parameters of each control through a property configuration interface. Simultaneously, the system's data source management module pre-connects to available data source paths in the back-end database, establishing a binding relationship between front-end form fields and the underlying data source through a mapping mechanism.

[0004] However, existing low-code electronic medical record editors lack the ability to intelligently parse and automatically convert unstructured or semi-structured original medical record documents. Current technologies only provide a basic component assembly framework and cannot automatically extract and understand the geometric layout, text content, and formatting features of the original medical record. They also cannot automatically identify special control types based on contextual semantics and accurately match the underlying data source path. This results in a significant time commitment to generating complex medical record templates when dealing with massive amounts of existing medical records or when replicating existing medical record formats. Summary of the Invention

[0005] This application provides a method and apparatus for automatically generating electronic medical records. The method enables intelligent parsing and automatic conversion of unstructured or semi-structured original documents, thereby improving the efficiency and accuracy of generating electronic medical record templates.

[0006] Firstly, this application provides a method for automatically generating electronic medical records. The method includes: receiving an original document containing medical record information input by a user, and an output structured document type specified by the user; parsing the original document to obtain multiple text blocks and their geometric layout information, content information, and format information; constructing a page structure diagram based on the spatial adjacency relationships between the multiple text blocks, wherein nodes in the page structure diagram correspond to text blocks, and edges connecting nodes correspond to the spatial adjacency relationships between text blocks; calculating the geometric layout information, content information, and format information of each node in the page structure diagram to obtain feature vectors; and calculating the spatial distance between the feature vectors of each node and the prototype vector of a preset structure type to obtain the corresponding feature vectors of each node. An initial confidence vector is generated, containing the initial probability that each node belongs to each preset structure type. Based on the topological structure of the page structure graph, the initial confidence vector of each node is corrected to obtain the final confidence vector. The structure type of the text block corresponding to each node is determined based on the final confidence vector. A structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. Target text blocks with a structure type of special control are identified. Based on the semantic information of the target text block, the corresponding special controls are matched and bound in the structured electronic medical record document. Based on the semantic information of each field in the structured electronic medical record document, the corresponding data source path is matched and bound from the preset basic data source library, and an electronic medical record template is output.

[0007] By adopting the above technical solution, the system can automatically complete the entire process of converting original medical records into structured templates from user-inputted raw documents. This eliminates the need for manual dragging and dropping of controls and configuration of attributes. By acquiring the geometric layout, content, and format information of text blocks and constructing a page structure diagram to express the spatial adjacency relationships between text blocks, the system can accurately understand the layout and structure characteristics of the original document. By calculating the feature vectors of nodes and performing spatial distance calculations with the prototype vectors of preset structure types, the system can initially determine the possible structure type to which each text block belongs, obtaining an initial confidence vector containing the initial probability that each node belongs to each preset structure type. The process of correcting the initial confidence vector based on the topological structure of the page structure diagram can fully... By leveraging the contextual and spatial constraints between text blocks, the accuracy of structure type identification is improved, resulting in a final confidence vector. After generating a structured electronic medical record document, target text blocks with special control types are identified, and corresponding special controls are automatically matched and bound based on the semantic information of the target text blocks, achieving intelligent control type identification. Based on the semantic information of each field in the structured electronic medical record document, the corresponding data source path is automatically matched and bound from a preset basic data source library, eliminating the need for manual configuration of field-to-data source mapping relationships, ensuring the accuracy and integrity of data flow, and thus quickly outputting directly applicable electronic medical record templates, meeting the actual needs of medical institutions for rapid production of complex medical record templates.

[0008] Optionally, the geometric layout, content, and format information of each node in the page structure diagram are calculated to obtain feature vectors. Specifically, this includes: extracting the bounding box coordinates of each node based on the geometric layout information, calculating the horizontal and vertical coordinates, width, and height of the corresponding text blocks for each node, and calculating the horizontal and vertical alignment features based on the position information of the text blocks on the page; combining the horizontal and vertical coordinates, width, height, horizontal alignment features, and vertical alignment features to obtain geometric layout features; extracting text characters from the content information of each node, matching the text characters with a preset medical keyword dictionary to obtain keyword scores, calculating symbol scores based on specific symbol features in the text characters, and calculating the ratio of the number of numeric characters in the text characters to the total number of characters to obtain numeric proportions; combining the keyword scores, symbol scores, and numeric proportions to obtain content features; parsing the format information of each node, extracting the font size and weight values ​​of the corresponding text blocks for each node, and combining the font size and weight values ​​to obtain style features; and concatenating the geometric layout features, content features, and style features to obtain the feature vector corresponding to each node.

[0009] By employing the above technical solutions, the horizontal and vertical coordinates, width, and height of text blocks are calculated based on bounding box coordinates. Furthermore, horizontal and vertical alignment features are calculated based on the text block's position on the page to distinguish different structural types such as titles, paragraphs, and table cells. Matching text characters with a preset medical keyword dictionary yields keyword scores, effectively identifying text blocks with medical-related semantics. Calculating symbol scores based on specific symbol features and obtaining numerical proportions by calculating the ratio of numeric characters to the total number of characters accurately distinguishes between numeric fields, date / time fields, and ordinary text fields. Extracting font size and weight values ​​from format information provides style features, utilizing the document's original formatting specifications to aid in structural type identification, as different structural types often possess specific font size and weight characteristics. The feature vector obtained by concatenating geometric layout features, content features, and style features comprehensively integrates information such as the spatial location, semantic content, and visual style of the text block, significantly improving the accuracy of structural type identification. This allows for a correct understanding of the original document's hierarchical structure and logical relationships, thereby generating structured electronic medical record documents that meet practical application needs.

[0010] Optionally, the spatial distance between the feature vector of each node and the prototype vector of the preset structure type is calculated to obtain the initial confidence vector corresponding to each node. Specifically, this includes: obtaining the prototype vector corresponding to each preset structure type, including label structure type, special control structure type, table cell structure type, and paragraph text structure type; calculating the weighted Euclidean distance between the feature vector of each node and the prototype vector of each preset structure type; inputting the weighted Euclidean distance into the distance conversion function to calculate the confidence score; combining the confidence scores of each node for each preset structure type to obtain the preliminary confidence vector; and normalizing the confidence scores in the preliminary confidence vector to generate the initial confidence vector corresponding to each node.

[0011] By adopting the above technical solution, prototype vectors corresponding to each of the preset structure types, including label structure type, special control structure type, table cell structure type, and paragraph text structure type, are obtained. Weighted Euclidean distance is used to calculate the similarity between the node feature vector and the prototype vector of each preset structure type. This can accurately measure the matching degree between text blocks and various structure types in the feature space. The weighted Euclidean distance is input into the distance transformation function to calculate the confidence score, realizing a smooth mapping from distance measurement to probabilistic confidence. This ensures that structure types with closer distances receive higher confidence scores, while those with greater distances receive lower confidence scores. The confidence scores of each node corresponding to each preset structure type are combined to generate an initial confidence vector, so that each node has probability distribution information of all possible structure types to which it belongs. The spatial adjacency relationship between nodes is used to further improve the accuracy of structure type recognition, thereby ensuring that the final generated structured electronic medical record document has the correct logical hierarchy.

[0012] Optionally, based on the topological structure of the page structure graph, the initial confidence vector of each node is corrected to obtain the final confidence vector. Specifically, this includes: obtaining the current node from the page structure graph (where the current node is any node in the page structure graph); obtaining a preset relationship compatibility matrix, which contains compatibility scores for nodes of various preset structure types connected by edges of specific types; obtaining all neighboring nodes of the current node from the page structure graph, and obtaining the confidence score of each neighboring node belonging to various preset structure types, multiplying these scores by the corresponding compatibility scores in the relationship compatibility matrix, and summing the results to obtain the total support of neighboring nodes for the current node belonging to various preset structure types; and then, based on a preset smoothing factor... The initial probability and total support of the current node belonging to each preset structure type are weighted and summed to obtain the updated confidence of the current node belonging to each preset structure type. The updated confidence of the current node belonging to all preset structure types is normalized to obtain the confidence vector of the current node in the current iteration. The iteration process is performed on all nodes in the page structure graph to obtain the confidence vector of all nodes in the current iteration. The change of the confidence vector of all nodes in the current iteration and the confidence vector of the previous iteration are calculated, and the maximum value of the change of all nodes is taken as the overall change. When the overall change is less than a preset threshold, the iteration is stopped and the confidence vector obtained in the current iteration is taken as the final confidence vector.

[0013] By adopting the above technical solution, a preset relationship compatibility matrix is ​​obtained, which can encode the rationality of connecting nodes of different preset structure types through edges of a specific type. By obtaining all neighboring nodes of the current node, multiplying the confidence scores of each neighboring node belonging to various preset structure types with the corresponding compatibility scores in the relationship compatibility matrix and summing them, the total support is obtained. This realizes the synergistic influence of neighboring nodes on the judgment of the current node's structure type. Based on a preset smoothing factor, the initial probability of the current node and the total support are weighted and summed to obtain the updated confidence, avoiding misjudgments caused by over-reliance on neighbor relationships. By normalizing the updated confidence, the probabilistic nature of the confidence vector is ensured, and iterative processing is performed on all nodes in the page structure graph, so that the confidence information can be fully propagated and converged in the entire graph structure. When the overall change of the maximum value among all nodes is less than a preset threshold, the iteration stops and the final confidence vector is obtained. The obtained final confidence vector comprehensively considers the node's own characteristics and global structural constraints, which greatly improves the accuracy of structure parsing of complex layout documents.

[0014] Optionally, a structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. Specifically, this includes: obtaining the element with the largest value in the final confidence vector corresponding to each node, and using the preset structure type corresponding to the element with the largest value as the structure type of the text block corresponding to each node; logically associating and hierarchically combining multiple text blocks according to the structure type of each text block and the spatial adjacency relationship between text blocks in the page structure diagram to construct a document logic tree; if the output structured document type is XML format, converting each level node in the document logic tree into the corresponding XML tag, and using the content information of the text block as the tag value to generate an XML format structured electronic medical record document; if the output structured document type is JSON format, traversing the document logic tree, converting each level node in the document logic tree into a key-value pair structure, and using the content information of the text block as the value corresponding to the key to generate a JSON format structured electronic medical record document.

[0015] By adopting the above technical solution, the element with the largest value in the final confidence vector corresponding to each node is obtained, and the corresponding preset structure type is used as the structure type of the text block. Based on the confidence information that has been iteratively corrected, the most reliable structure type judgment is made, ensuring the accuracy of subsequent document reconstruction. According to the structure type of each text block and the spatial adjacency relationship between text blocks in the page structure diagram, multiple text blocks are logically associated and hierarchically combined to construct a document logic tree. For the case where the output structured document type is XML format, each level node in the document logic tree is converted into the corresponding XML tag, and the content information of the text block is used as the tag value to generate a structured electronic medical record document that conforms to the XML specification, which is convenient for data exchange and integration with medical information systems that adopt the XML standard. For the case where the output structured document type is JSON format, each level node is converted into a key-value pair structure by traversing the document logic tree, and the content information of the text block is used as the value corresponding to the key to generate a lightweight and easy-to-parse JSON format structured electronic medical record document, which adapts to the data processing needs of mobile applications and automatically outputs structured documents that conform to the technical standards of different medical institutions, avoiding the tedious work of manual format conversion.

[0016] Optionally, based on the semantic information of each field in the structured electronic medical record document, the corresponding data source path is matched and bound from a preset basic data source library, and an electronic medical record template is output. Specifically, this includes: extracting the text content of each field from the structured electronic medical record document; calculating the semantic vector of each field based on the text content; obtaining the standard semantic vector corresponding to each standard data source path in the preset basic data source library; calculating the semantic similarity score between the field semantic vector and each standard semantic vector; obtaining the highest score among the semantic similarity scores and determining whether the highest score is greater than or equal to a preset similarity threshold; if the highest score is greater than or equal to the preset similarity threshold, binding the field to the standard data source path corresponding to the highest score; if the highest score is less than the preset similarity threshold, marking the field as pending binding and generating a prompt message; receiving a custom data source path input by the user based on the prompt message for the field in the pending binding state; binding the field to the custom data source path and adding the custom data source path to the preset basic data source library; and generating and outputting an electronic medical record template after all fields in the structured electronic medical record document have been bound.

[0017] By employing the above technical solution, the text content of each field in a structured electronic medical record document is extracted and the field semantic vector is calculated. This converts the semantic information of the fields into a computable vector representation, obtains the standard semantic vectors corresponding to each standard data source path in a preset basic data source library, and calculates the semantic similarity score between the field semantic vector and each standard semantic vector. The most suitable data source path is found based on semantic level rather than simple string matching, improving the accuracy of data source binding. Automatic binding is determined by whether the highest score is greater than or equal to a preset similarity threshold. When the highest score reaches the threshold, the field is matched with the corresponding standard data source. The path binding enables fully automated data source configuration under high confidence conditions, completing the binding of most fields without manual intervention. When the highest score is lower than the preset similarity threshold, the field is marked as pending binding and a prompt message is generated, avoiding incorrect binding under low confidence conditions. By receiving custom data source paths input by the user for fields in the pending binding state, the accuracy of data source configuration is ensured. At the same time, the custom data source paths are added to the preset basic data source library, enabling the data source knowledge base to be continuously expanded and optimized. After all fields are bound, an electronic medical record template is generated and output, ensuring the data integrity and usability of the output template.

[0018] Optionally, after all fields in the structured electronic medical record document are bound, an electronic medical record template is generated and output. This includes: obtaining the attribute configuration information of each special control in the bound structured electronic medical record document; if a special control with empty attribute configuration information is detected, a validation exception report is generated and the user is prompted to configure it; receiving supplementary attribute configuration information input by the user until the attribute configuration information of all special controls is complete; if the attribute configuration information of all special controls is complete, the structured electronic medical record document is rendered into a visual preview interface; receiving the user's confirmation instruction for the visual preview interface, and encapsulating the structured electronic medical record document into a downloadable electronic medical record template.

[0019] By adopting the above technical solution, the attribute configuration information of each special control in the bound structured electronic medical record document is obtained, and the complete running parameters of the special controls are comprehensively checked. When a special control with empty attribute configuration information is detected, a verification exception report is generated and the user is prompted to configure it. The exception detection can detect configuration defects in time during the template generation stage, avoiding the rework cost caused by discovering problems after the template is deployed. By receiving supplementary attribute configuration information input by the user until the attribute configuration information of all special controls is complete, the integrity of the output template is ensured. After the attribute configuration information of all special controls is complete, the structured electronic medical record document is rendered into a visual preview interface, allowing the user to intuitively view the final presentation effect of the template. Only after receiving the user's confirmation instruction on the visual preview interface is the structured electronic medical record document packaged into a downloadable electronic medical record template. This human-machine collaborative confirmation process ensures automation efficiency while taking into account the necessity of manual review, ensuring that the final output electronic medical record template not only conforms to the automatically parsed structural specifications but also meets the user's actual business needs.

[0020] A second aspect of this application provides an apparatus for automatically generating electronic medical records. The apparatus includes a receiving unit, a first processing unit, a second processing unit, and a matching unit. The receiving unit receives an original document containing medical record information input by a user, and a user-specified output structured document type. The first processing unit parses the original document to obtain multiple text blocks and their geometric layout, content, and format information. Based on the spatial adjacency relationships between the text blocks, it constructs a page structure diagram, where nodes in the page structure diagram correspond to text blocks, and edges connecting nodes correspond to the spatial adjacency relationships between text blocks. The second processing unit calculates the geometric layout, content, and format information of each node in the page structure diagram to obtain feature vectors, and then matches the feature vectors of each node with a prototype of a preset structure type. The system performs spatial distance calculations on vectors to obtain initial confidence vectors for each node. These initial confidence vectors contain the initial probability that each node belongs to each preset structure type. Based on the topological structure of the page structure graph, the initial confidence vectors for each node are corrected to obtain final confidence vectors. The structure type of the text block corresponding to each node is determined based on the final confidence vectors. A structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. The matching unit identifies target text blocks with a structure type of special control. Based on the semantic information of the target text block, it matches and binds the corresponding special controls in the structured electronic medical record document. Based on the semantic information of each field in the structured electronic medical record document, it matches and binds the corresponding data source path from the preset basic data source library and outputs the electronic medical record template.

[0021] In a third aspect, this application provides an electronic device including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory, causing the electronic device to perform any of the methods described above in this application.

[0022] In a fourth aspect, this application provides a computer-readable storage medium storing instructions that, when executed, perform any of the methods described above in this application.

[0023] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: Receiving user-inputted original documents, the system can automatically complete the entire process of conversion from original medical records to structured templates, eliminating the need for manual dragging and dropping of controls and configuration attributes. By acquiring the geometric layout information, content information, and format information of text blocks and constructing a page structure diagram to express the spatial adjacency relationship between text blocks, the system can accurately understand the layout structure and features of the original document. By calculating the feature vectors of nodes and performing spatial distance calculations with the prototype vectors of preset structure types, the system can initially determine the possible structure type to which each text block belongs, obtaining an initial confidence vector containing the initial probability that each node belongs to each preset structure type. The initial confidence is based on the topological structure of the page structure diagram. The vector correction process fully utilizes the contextual and spatial constraints between text blocks to improve the accuracy of structure type identification and obtain the final confidence vector. After generating the structured electronic medical record document, it identifies target text blocks with special control types and automatically matches and binds the corresponding special controls based on the semantic information of the target text blocks, realizing intelligent control type identification. According to the semantic information of each field in the structured electronic medical record document, it automatically matches and binds the corresponding data source path from the preset basic data source library, eliminating the need for manual configuration of the mapping relationship between fields and data sources, ensuring the accuracy and integrity of data flow, and thus quickly outputting directly applicable electronic medical record templates, meeting the actual needs of medical institutions for the rapid production of complex medical record templates. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the first process for automatically generating electronic medical records according to an embodiment of this application; Figure 2 This is a schematic diagram of the second process for automatically generating electronic medical records provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0025] Explanation of reference numerals in the attached figures: 300, electronic device; 301, processor; 302, memory; 303, user interface; 304, network interface; 305, communication bus. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0027] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0028] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0029] Therefore, improving the efficiency of electronic medical record template generation is a pressing issue, as existing low-code electronic medical record editors lack the ability to parse and convert unstructured or semi-structured medical record documents. This application provides a method for automatically generating electronic medical records, applied in a server. The server in this application can be a platform providing electronic medical record template services for the medical industry. Figure 1 This is a schematic diagram of the first process for automatically generating electronic medical records according to an embodiment of this application. (Refer to...) Figure 1 The method includes the following steps S101-S107.

[0030] S101: Receives the user input of the original document containing medical record information, as well as the user-specified output structured document type.

[0031] In step S101 above, the system receives the user-inputted original document containing medical record information and the user-specified output structured document type. This is done to maximize compatibility with existing medical record storage formats in medical institutions and meet the data format requirements of different information systems. In actual medical scenarios, medical record information often exists in multiple forms, including images of paper medical records taken by scanners or mobile phones, PDF electronic documents exported from old systems, and DOCX format documents edited using office software. These different formats of original documents each have their own background and usage scenarios. Therefore, it is necessary to support the three most common original document formats—images, PDFs, and DOCXs—as input to ensure the broad applicability of the method.

[0032] By providing a file upload interface that uses the standard HTTP file transfer protocol, users can select locally stored medical records to upload via a web page or client application. After the user selects a file, the front-end program will immediately perform format verification on the file, determining whether the document belongs to one of the three supported formats by reading the file extension and file header identifier.

[0033] While uploading the original document, the system also needs to receive the user-specified output structured document type. This parameter setting ensures that the generated electronic medical record template matches the data interface of the target medical information system. Different medical information systems may use different structured data formats for data exchange. XML and JSON are currently the two most mainstream formats. XML has strict syntax rules and good extensibility, making it suitable for scenarios requiring complex nested structures and namespace definitions. JSON, on the other hand, is more lightweight and easier to parse, and is widely used in modern web and mobile applications. A format selection control is provided on the user interface, allowing users to explicitly select XML or JSON as the output structured document type via a drop-down menu or radio button. This selection information is passed as a parameter to the subsequent document generation module, guiding the system to organize and output electronic medical record data according to the corresponding format's syntax rules.

[0034] For example, the emergency medicine clinical information system of a tertiary hospital uses XML format based on the HL7 CDA standard for exchanging medical record data. Doctors upload a scanned image of an emergency medical record using the above steps and select XML as the output format. After receiving this input information, the system stores the binary data stream of the original document and the output format parameters in a temporary buffer and assigns a unique task identifier to this processing task to track the task status and obtain the processing results in subsequent asynchronous processing. As another example, the mobile application of an internet hospital uses a RESTful API for data transmission. The interface specification requires medical record data to be submitted in JSON format. When the hospital's information administrator needs to convert historical paper medical records into electronic medical records in batches, they can upload the batch-scanned PDF documents one by one, specifying JSON as the output structured document type for each upload. Based on this specification, a JSON format document generator is automatically invoked to ensure that the output electronic medical record template fully complies with the data format requirements of the internet hospital's information system. The automatic electronic medical record generation method involved in this application strictly complies with the requirements of relevant laws and regulations when processing original medical record documents containing patient personal information. In practical applications, the following measures can be taken to ensure information security and privacy protection: Before receiving original medical record documents uploaded by users, the purpose, scope, and method of data processing should be clearly stated in the user agreement, and the user's explicit authorization and consent should be obtained; For sensitive personal information such as patient names, ID numbers, and contact information involved in the original medical record documents, desensitization technology should be used during document parsing and structured processing. For example, the patient's name should be partially hidden (e.g., "Zhang**"), the ID number should be masked (e.g., "110101********1234"), and the middle part of the contact number should be desensitized (e.g., "138****5678") to ensure that the system only processes desensitized data in technical stages such as feature extraction, structure type identification, and template generation, thus avoiding the leakage of sensitive information; All medical record documents and intermediate processing data should be encrypted and stored using the AES-256 encryption algorithm, and the transmission process should be encrypted using the TLS / SSL protocol to prevent data from being illegally intercepted or tampered with during storage and transmission. In addition, a strict access control mechanism is implemented for data access, authorizing only users and system administrators to access relevant data within the necessary scope, and all data access and operation behaviors are recorded through audit logs to ensure that the data processing process is traceable and auditable. Finally, after the electronic medical record template is generated, the original documents and intermediate processing data in the temporary cache are automatically deleted. For data that needs to be persistently stored, such as user-defined data source paths, anonymization is adopted, and only desensitized technical features such as standard semantic vectors are retained in the preset basic data source library. No original information that can directly identify the patient is stored.

[0035] S102: Parse the original document to obtain multiple text blocks and their geometric layout, content, and format information, and construct a page structure diagram based on the spatial adjacency relationship between the multiple text blocks.

[0036] In S102 above, the original document is parsed to obtain multiple text blocks and their geometric layout, content, and format information. Specifically, this includes: if the original document is in image format, optical character recognition is performed on the original document to obtain text blocks and their geometric layout, content, and format information; if the original document is in searchable PDF or DOCX format, the original document is parsed to obtain text blocks and their geometric layout, content, and format information; if the original document is in non-searchable PDF format, the original document is converted to obtain the original image, and optical character recognition is performed on the original image to obtain text blocks and their geometric layout, content, and format information.

[0037] Specifically, the appropriate parsing strategy is selected based on the format of the original document. When the original document is in image format, the Optical Character Recognition (OCR) engine is invoked to process it. OCR technology can automatically identify text content from images and locate the spatial position of the text. The OCR engine not only has text recognition capabilities but also layout analysis capabilities, automatically grouping the recognized text into multiple text blocks according to its spatial distribution on the page. During the recognition process, the OCR engine generates a bounding box for each detected text region. The coordinate information of this bounding box constitutes the geometric layout information of the text block. The horizontal and vertical coordinates of the upper left corner of the text block in the page coordinate system, as well as the width and height of the text block, accurately describe the spatial position and occupied area of ​​the text block in the original document. At the same time, the OCR engine recognizes the sequence of characters within the bounding box and outputs it as a text string. This text string is the content information of the text block, which is the actual semantic content carried by the text block. In addition, the optical character recognition engine can also recognize the format style attributes of text, including font size, font weight, color, alignment, etc. These style attributes together constitute the format information of the text block. The format information can reflect the visual presentation of the text block in the original medical record, which is of great significance for distinguishing different types of text blocks such as titles, body text, and table content.

[0038] For example, when a user uploads a scanned image of an emergency room medical record, the optical character recognition engine will identify the text block corresponding to the tag field "patient name". The geometric layout information of this text block may be 50 pixels on the horizontal axis, 100 pixels on the vertical axis, 80 pixels on the width, and 20 pixels on the height. The content information is the string "patient name". The format information includes attributes such as font size 14 points, bold font weight, and black color. The complete extraction of this information can accurately determine that the text block is a tag-like text element.

[0039] When the original document is a searchable PDF or DOCX format, document parsing technology is used to directly extract text blocks and attribute information. Searchable PDF documents contain a text layer that stores the text content and its layout information in a structured manner. By calling a PDF parsing library to read the document's internal data structure, each text object in the document is traversed, and its text content, coordinate position, font attributes, and other information are extracted, thereby obtaining the geometric layout, content, and formatting information of the text blocks. DOCX format documents are essentially compressed packages based on the Office Open XML standard, containing multiple XML files describing the document's content, styles, and layout. By decompressing the DOCX file and parsing the `document.xml` file, the document's paragraph structure and text content can be obtained. Parsing the `styles.xml` file provides the text's formatting style information. By parsing the structured information in `document.xml`, such as paragraph indentation, spacing, and table rows and columns, and combining it with preset page rendering parameters (such as margins and paper size), the relative positional relationships of each text block are calculated. These relative positional relationships are then converted into normalized layout coordinates (e.g., the horizontal coordinate expressed as a percentage of the page width) as the geometric layout information of the text blocks. Compared to optical character recognition, parsing methods based on the internal structure of documents are more accurate and efficient because the text and formatting information in searchable PDF and DOCX documents are stored precisely in a digital format, eliminating the errors that may arise from image recognition.

[0040] For example, when a user uploads a DOCX document of an inpatient medical record edited in Word, parsing the XML structure of the document can accurately extract the text block corresponding to the "chief complaint" paragraph. The geometric layout information of this text block is calculated through the paragraph's indentation and spacing attributes. The content information is directly read from the text node as "recurrent cough, sputum production, and shortness of breath for 2 weeks". The format information includes the font size of 12 points, the font of SimSun, and the alignment of left alignment. The extraction of this information does not require image recognition, ensuring the accuracy of the data.

[0041] When the original document is a non-searchable PDF, the system needs to convert the original document's format before performing optical character recognition (OCR) processing. Non-searchable PDF documents essentially encapsulate page images within a PDF container, lacking extractable text layers, making it impossible to obtain text content using conventional PDF parsing methods. Upon detecting a non-searchable PDF document, a PDF-to-image tool is invoked to render each page of the PDF as a high-resolution image. During the conversion process, appropriate resolution parameters are set to ensure sufficient clarity in the generated original image; typically, a resolution of 300 DPI ensures the accuracy of subsequent OCR. After conversion, the generated original image is passed as input to the OCR engine, which performs OCR according to the image format document processing flow described above, ultimately obtaining text blocks and their geometric layout, content, and formatting information. This post-conversion recognition processing method effectively handles the large number of scanned PDF medical record documents in medical institutions, ensuring comprehensive processing capabilities for PDF documents from different sources and with different production methods.

[0042] For example, a hospital's historical medical record archive system stores a large number of PDF medical record documents generated by batch scanning. Although these documents have the appearance of PDFs, they only contain page images. When a user uploads such unsearchable PDF documents, each page of the PDF is first converted into a PNG format original image. Then, optical character recognition is performed on each original image. The recognized text blocks, geometric layout information, content information, and format information are completely consistent with the results obtained by directly processing image format documents in terms of data structure, thus realizing the effective parsing of unsearchable PDF documents.

[0043] After obtaining all text blocks and their attribute information, a page structure diagram needs to be constructed based on the spatial adjacency relationships between multiple text blocks. The page structure diagram is a graph data structure where nodes correspond to text blocks, and edges connecting nodes correspond to the spatial adjacency relationships between text blocks. The purpose of constructing the page structure diagram is to explicitly express the spatial topological relationships between text blocks in a medical record document, reflecting the layout organization logic of the medical record. When constructing the page structure diagram, a corresponding node is created for each text block, and each node stores the geometric layout, content, and formatting information of that text block. The spatial relationship between text blocks is calculated to determine whether to establish an edge connection between corresponding nodes. The criteria for judging spatial adjacency include the horizontal or vertical distance between text blocks, the alignment of text block boundaries, and other factors. The shortest distance between the bounding boxes of each pair of text blocks is calculated. If this distance is less than a preset adjacency threshold, the two text blocks are considered spatially adjacent, and an edge is created for the corresponding two nodes in the page structure diagram. Simultaneously, the edge type information is recorded.

[0044] For example, marking the edge connecting a text block to the left of a given text block as "left adjacent" and the edge connecting the text block above it as "top adjacent" allows for a more precise depiction of the spatial relationships between text blocks. For instance, in an outpatient medical record, the "Patient Name" label text block is immediately adjacent to a text box containing the patient's actual name. These two text blocks are spatially adjacent and semantically related. When constructing the page structure diagram, an edge of type "right adjacent" is created between the "Patient Name" node and the "Zhang San" node. The existence of this edge indicates that these two text blocks form a correspondence between the label and the content to be filled in on the page layout, providing important clues for subsequently identifying whether these two text blocks belong to the label structure type or the special control structure type, respectively. Similarly, in a table area of ​​a medical record, multiple cell text blocks are arranged horizontally and vertically to form a row and column structure. By identifying the top, bottom, left, and right adjacent relationships between these text blocks, a graph topology corresponding to the table's row and column structure is constructed in the page structure diagram, allowing the overall structure of the table to be clearly represented through the connection patterns of nodes and edges in the graph.

[0045] Through this systematic parsing and page structure diagram construction process, the original document of any format is converted into a unified structured intermediate representation. This intermediate representation not only contains the content and format information of text blocks, but also explicitly encodes the spatial topological relationships between text blocks through the page structure diagram. S103: Calculate the geometric layout information, content information, and format information of each node in the page structure diagram to obtain feature vectors. Calculate the spatial distance between the feature vectors of each node and the prototype vector of the preset structure type to obtain the initial confidence vector corresponding to each node.

[0046] In S103 above, in medical record documents, text blocks of different structural types exhibit obvious regular differences in geometric layout, content semantics, and format style. For example, title text blocks are usually located at the top of the page with a larger font size and bold weight, table cell text blocks have strict row and column alignment and contain specific delimiters, and label text blocks often contain medical keywords such as "name," "gender," and "age" and are immediately adjacent to the filling area. Therefore, it is necessary to extract discriminative features of text blocks from three dimensions: geometry, content, and style, in order to effectively distinguish text blocks of different structural types. The initial confidence vector contains the initial probability of each node belonging to each preset structural type.

[0047] The geometric layout, content, and formatting information of each node in the page structure diagram are calculated to obtain feature vectors. Specifically, this includes: extracting the bounding box coordinates of each node based on the geometric layout information, calculating the horizontal and vertical coordinates, width, and height of the corresponding text blocks for each node, and calculating the horizontal and vertical alignment features based on the position of the text blocks on the page; combining the horizontal and vertical coordinates, width, height, horizontal alignment features, and vertical alignment features to obtain geometric layout features; extracting text characters from the content information of each node, matching the text characters with a preset medical keyword dictionary to obtain keyword scores, calculating symbol scores based on specific symbol features in the text characters, and calculating the ratio of the number of numeric characters in the text characters to the total number of characters to obtain numeric proportions; combining the keyword scores, symbol scores, and numeric proportions to obtain content features; parsing the formatting information of each node, extracting the font size and weight values ​​of the corresponding text blocks for each node, and combining the font size and weight values ​​to obtain style features; and concatenating the geometric layout features, content features, and style features to obtain the feature vector corresponding to each node.

[0048] Specifically, feature vectors are calculated from the geometric layout, content, and formatting information of each node in the page structure diagram. When processing the geometric layout information, the bounding box coordinates of each node are extracted. These coordinates describe the precise position of the text block in the page coordinate system. The x and y coordinates of the top-left corner of the text block are extracted to represent its starting position, and the width and height are extracted to represent its spatial scale. These four basic geometric parameters collectively characterize the spatial occupancy of the text block. Based on this, horizontal and vertical alignment features are further calculated according to the text block's position on the page. The horizontal alignment feature reflects the alignment relationship between the text block and the left, center, or right boundary of the page, while the vertical alignment feature reflects the alignment relationship between the text block and the top, middle, or bottom of the page. These alignment features can effectively identify whether a text block belongs to a specific layout role, such as a centered title, a left-aligned label, or a right-aligned value. Left alignment is determined by calculating the distance between the left edge of the text block and the left edge of the page; center alignment is determined by calculating the offset between the center line of the text block and the center line of the page; and right alignment is determined by calculating the distance between the right edge of the text block and the right edge of the page. Similar calculations are performed for the vertical direction. The horizontal and vertical coordinates, width, height, horizontal alignment features, and vertical alignment features are combined to form a multi-dimensional geometric layout feature vector, which comprehensively describes the spatial distribution characteristics of the text block.

[0049] For example, in an outpatient medical record, the title text block "XX Hospital Outpatient Medical Record" located in the center of the page is extracted. The bounding box coordinates of the title text block are 200 pixels on the horizontal axis, 50 pixels on the vertical axis, 400 pixels in width, and 30 pixels in height. Through calculation, it is found that the center line of the text block is very close to half the width of the page, and the horizontal alignment feature is determined to be center alignment. Since the vertical axis is small, the vertical alignment feature is determined to be near the top. These geometric layout features clearly indicate that the text block may be a title structure type.

[0050] When processing content information, text characters are extracted from the content information of each node. These text characters carry the semantic content of the text block, and it is necessary to analyze the degree of association between the text characters and different structural types from a semantic perspective. First, the text characters are matched with a preset medical keyword dictionary to calculate the keyword score. The preset medical keyword dictionary is a pre-constructed vocabulary containing common medical terms and medical record field names, including keywords related to basic patient information such as "name," "gender," "age," and "ethnicity," keywords related to clinical manifestations such as "chief complaint," "present illness," and "past medical history," keywords related to examination and diagnosis such as "physical examination," "auxiliary examination," and "diagnosis," and keywords related to treatment plans such as "treatment opinions" and "medication records." The keyword score is quantified by calculating the number and importance of medical keywords contained in the text characters. The higher the keyword score, the more likely the text block is to be a tag-type or title-type structure. Simultaneously, specific symbol features in the text characters are statistically analyzed to calculate symbol scores. These specific symbols include punctuation marks such as colons, commas, periods, semicolons, and table separators such as vertical and horizontal lines. Different text block structures exhibit significant differences in symbol usage; for example, label text blocks typically end with a colon, table cell text blocks may contain vertical line separators, and plain text paragraphs contain more periods and commas. Symbol scores are calculated by statistically analyzing the frequency of each type of symbol and combining it with symbol position information. Furthermore, the ratio of numeric characters to the total number of characters in the text is calculated to obtain the numeric proportion. The numeric proportion effectively distinguishes between numerical and textual content. In medical records, fields such as age, date, and test results typically contain a higher proportion of numeric characters, while fields such as chief complaint and medical history description are mainly composed of Chinese characters with a lower numeric proportion. The keyword scores, symbol scores, and numeric proportions are combined to form a comprehensive content feature vector, which characterizes the semantic features of the text block from multiple perspectives.

[0051] For example, for the text block "Patient Name:" in the medical record, the keyword "Patient Name" was matched in the preset medical keyword dictionary, and a high keyword score was calculated. At the same time, a colon symbol was detected at the end of the text, and the symbol score was also high. However, the text block does not contain any numeric characters, and the proportion of numeric characters is zero. Based on these three content features, it is preliminarily determined that the text block is likely to belong to the tag structure type.

[0052] When processing formatting information, the formatting information of each node is parsed to extract the font size and weight values ​​of the corresponding text blocks. The font size value in the formatting information reflects the display size of the text, usually in points. Heading text often uses a larger font size, such as 16 or 18 points, while body text uses a standard font size, such as 12 or 14 points. Table content may use a smaller font size, such as 10 points, to fit the cell space. The weight value reflects the thickness of the text, including normal weight and bold weight. Headings and labels often use bold weight for emphasis, while ordinary body text uses normal weight. These two key style attributes are extracted from the formatting information, and the font size and weight values ​​are combined to obtain a style feature vector. This vector concisely and effectively captures the visual presentation style of the text blocks.

[0053] For example, the title text block "Diagnosis Result" in a medical record, when parsed, shows a font size of 16 points and a weight of 700 (bold), which closely matches the typical characteristics of the title structure. Similarly, the content of a regular cell in a table, "White Blood Cell Count," shows a font size of 10 points and a weight of 400 (normal), which conforms to the general specifications for table content.

[0054] After extracting geometric layout features, content features, and style features, these three types of features are concatenated to obtain the complete feature vectors corresponding to each node. The concatenation operation links the three independent feature vectors dimensionally to form a high-dimensional joint feature vector. This joint feature vector comprehensively includes all discriminative information of the text block in three dimensions: spatial location, semantic content, and visual style, providing rich feature representations for subsequent structural type recognition. For example, for a certain tag text block, the geometric layout feature might be a 5-dimensional vector representing the horizontal coordinate, vertical coordinate, width, height, and alignment; the content feature might be a 3-dimensional vector representing keyword score, symbol score, and number proportion; and the style feature might be a 2-dimensional vector representing font size and weight. After concatenation, a 10-dimensional complete feature vector is obtained, which fully describes all observable characteristics of the tag text block.

[0055] Furthermore, after extracting the feature vectors of each node, the spatial distance between the feature vectors of each node and the prototype vectors of the preset structure types is calculated to obtain the initial confidence vectors corresponding to each node. Specifically, this includes: obtaining the prototype vectors corresponding to each preset structure type, including label structure type, special control structure type, table cell structure type, and paragraph text structure type; calculating the weighted Euclidean distance between the feature vectors corresponding to each node and the prototype vectors of each preset structure type; inputting the weighted Euclidean distance into the distance conversion function to calculate the confidence score; combining the confidence scores of each node for each preset structure type to obtain the preliminary confidence vector; and normalizing the confidence scores in the preliminary confidence vector to generate the initial confidence vectors corresponding to each node.

[0056] Specifically, after obtaining the feature vectors of each node, it is necessary to calculate the spatial distance between these feature vectors and the prototype vectors of the preset structure types to obtain the initial confidence vectors corresponding to each node. The preset structure types include several predefined text block structure roles commonly found in medical record documents. These include, but are not limited to, title structure types, label structure types, paragraph text structure types, table cell structure types, and special control structure types. Among these, label structure types, special control structure types, table cell structure types, and paragraph text structure types are the most common and representative structure roles in electronic medical record documents. The label structure type corresponds to text blocks in the medical record form used to identify the meaning of fields, such as identifying text like "patient name," "gender," "age," and "chief complaint." These text blocks typically contain medical keywords, end with symbols such as colons, may be bolded, and are spatially adjacent to the filling area or data value. Special control structure types correspond to form control areas that require user interaction input or selection, such as radio buttons, checkboxes, drop-down lists, and date pickers. These text blocks typically contain limited option text, have specific layout patterns such as horizontal or vertically arranged option groups, and semantically represent enumerated values ​​or Boolean values. Table cell structure types correspond to data units organized in tabular form in medical records, such as the contents of individual cells in examination result tables or medication record tables. These text blocks have strict row and column alignment, clear cell boundaries, concise content, and often contain numerical values ​​or brief descriptions. Paragraph text structure types correspond to continuous textual narratives in medical records, such as detailed descriptions of the present illness or written records of physical examinations. These text blocks are typically longer, contain complete sentence structures, and may have line breaks within paragraphs, but the overall text forms a semantically coherent paragraph.

[0057] Each preset structure type maintains a prototype vector, with the same dimension as the node feature vector. The values ​​in each dimension of the prototype vector represent the typical or expected values ​​for that structure type in the corresponding feature dimension. These prototype vectors can be obtained by averaging the sample feature vectors of each structure type on the labeled training dataset, or by training with supervised learning methods to obtain the optimal prototype vector representation, ensuring that samples of the same class are close to the prototype vector while samples of different classes are far from it, thus achieving optimal class separability. For example, the prototype vector of a label structure type might have a high value in the keyword score dimension because label text often contains medical keywords, a high value in the symbol score dimension because labels often end with a colon, a value corresponding to bold in the character weight dimension, and a small value in the width dimension because label text is usually short. The prototype vector of a special control structure type might have a medium value in the numerical proportion dimension, reflect grouped arrangement characteristics in the horizontal alignment feature dimension, and contain features of specific symbols such as brackets or square brackets in the symbol score dimension. The prototype vectors of table cell structures may exhibit strong regularity in the alignment dimension of geometric layout features, correspond to a relatively uniform size distribution in the width and height dimensions, and reflect simplicity and data-driven characteristics in the content feature dimension. The prototype vectors of paragraph text structures may correspond to larger values ​​in the width dimension because paragraph text typically occupies more page space, may have lower keyword scores because paragraph text is primarily narrative rather than keyword stuffing, and may also have lower numerical proportions.

[0058] After obtaining the prototype vectors corresponding to each preset structure type, the weighted Euclidean distance between the feature vector of each node and the prototype vector of each preset structure type is calculated. The weighted Euclidean distance is an extension of the Euclidean distance. During the calculation, different weight coefficients are assigned to different feature dimensions, thus highlighting the role of those feature dimensions that are more critical to structure type discrimination and suppressing the influence of feature dimensions with weaker discriminative power or higher noise. Specifically, let the feature vector of node i be Fi, containing n feature dimensions denoted as Fi = (fi1, fi2, ..., fin), let the prototype vector of a certain preset structure type k be Pk, containing the same n feature dimensions denoted as Pk = (pk1, pk2, ..., pkn), and let the weight coefficient vector corresponding to each feature dimension be W = (w1, w2, ..., wn). Then, the weighted Euclidean distance D between the feature vector of node i and the prototype vector of structure type k is calculated according to the weighted Euclidean distance formula. ikThe weights in the weight vector W are typically determined through feature importance analysis or machine learning methods. Feature dimensions with high importance correspond to larger weights, while those with low importance correspond to smaller weights, ensuring that distance calculations fully reflect the differences in the discriminative power of the features. For example, when determining the tag structure type, keyword scores and symbol scores, two content feature dimensions, may be assigned higher weights because they are highly indicative of tag recognition, while certain geometric layout features, such as absolute horizontal coordinate positions, may be assigned lower weights because tags can appear in different locations on the page.

[0059] By calculating the weighted Euclidean distance, the degree of feature difference between each node and various preset structural type prototypes can be quantified. The smaller the distance value, the closer the node's features are to the prototype features of that structural type, and the greater the likelihood that the node belongs to that structural type. For example, for the text block node "Gender:" in a medical record, after extracting the feature vector, calculating the weighted Euclidean distance between this feature vector and the prototype vector of the label structural type might yield a small value, such as 5.36, because this node is highly similar to the label prototype in key feature dimensions such as keyword score, symbol score, and word weight. However, calculating the weighted Euclidean distance between this feature vector and the prototype vector of the paragraph text structural type might yield a larger value, such as 24.641, because this node's smaller width and higher keyword score are significantly different from the paragraph text prototype. Similarly, calculating the weighted Euclidean distance between this node and the prototype vector of the special control structural type might yield 11.195, and the weighted Euclidean distance with the prototype vector of the table cell structural type might yield 18.61. These four distance values ​​reflect the similarity between the node and the four preset structural types, respectively.

[0060] After obtaining the weighted Euclidean distances between each node and each preset structure type, these distance values ​​need to be converted into more interpretable confidence scores. The weighted Euclidean distances are input into a distance transformation function to calculate the confidence scores. The design goal of the distance transformation function is to convert the smaller the distance value (the better) into the larger the confidence score (the better), while ensuring that the range of confidence scores has good numerical properties for subsequent processing. The distance transformation function is defined as follows: the confidence score is equal to the reciprocal of the weighted Euclidean distance plus 1, that is, the weighted Euclidean distance D between node i and structure type k. ik The corresponding confidence score S ik Equals 1 divided by D ik Add 1. This transformation function has several excellent properties, when the distance D ik When the confidence score S equals 0, meaning the node features perfectly match the prototype, the confidence score S is... ik The value reaches its maximum when it equals 1, and increases with distance D. ik Increase the confidence score S ikThe distance is monotonically decreasing and approaches 0 but is always positive. This monotonically decreasing characteristic ensures an inverse correspondence between distance and confidence. Adding 1 to the denominator avoids the numerical error of dividing by 0 when the distance is 0, and at the same time limits the range of confidence scores to between 0 and 1, which conforms to the conventional value conventions for probability or confidence.

[0061] For example, the weighted Euclidean distance of 5.36 between the "Gender:" node and the tag structure type prototype is calculated using the distance transformation function to give a confidence score of 1 divided by 5.36 plus 1, which equals 0.157. The confidence score corresponding to the distance of 24.641 between this node and the paragraph text structure type prototype is 1 divided by 24.641 plus 1, which equals 0.039. The confidence score corresponding to the distance of 44.195 between this node and the special control structure type prototype is 1 divided by 11.195 plus 1, which equals 0.082. The confidence score corresponding to the distance of 18.608 between this node and the table cell structure type prototype is 1 divided by 18.608 plus 1, which equals 0.161.

[0062] After calculating the confidence scores for each node corresponding to each preset structure type, these confidence scores are combined to generate the initial confidence vector for each node. For the case containing four preset structure types, the initial confidence vector for each node is a four-dimensional vector. The first component represents the confidence score for the node belonging to the label structure type, the second component represents the confidence score for the node belonging to the special control structure type, the third component represents the confidence score for the node belonging to the table cell structure type, and the fourth component represents the confidence score for the node belonging to the paragraph text structure type. The confidence scores in the initial confidence vector are then normalized so that the sum of the confidence scores equals 1, thus generating the initial confidence vector for each node. For the "Gender:" node mentioned above, the initial confidence vector is (0.157, 0.082, 0.051, 0.039). After normalizing the initial confidence vector, we get the initial confidence vector (0.477, 0.249, 0.155, 0.119). This vector indicates that the node is most likely to belong to the label structure type, followed by the special control structure type, then the table cell structure type, and least likely to belong to the paragraph text structure type. This is consistent with the actual structural role of the node.

[0063] For example, consider a medical history description in a medical record: "The patient developed a recurrent cough two weeks ago without any obvious cause, mainly a dry cough with a small amount of white phlegm, without fever or chest pain." After extracting the feature vector, the weighted Euclidean distance with each prototype vector is calculated. This might yield a confidence score of 0.114 for a distance of 7.8 with the label structure type, 0.098 for a distance of 9.2 with the special control structure type, 0.105 for a distance of 8.5 with the table cell structure type, and 0.400 for a distance of 1.5 with the paragraph text structure type. The combined initial confidence vector is (0.114, 0.098, 0.105, 0.400). Normalizing the initial confidence vector yields an initial confidence vector of (0.159, 0.137, 0.146, 0.558), clearly indicating that this node most likely belongs to the paragraph text structure type, consistent with its actual role as medical history narrative content. This method of generating initial confidence vectors based on weighted Euclidean distance and distance transformation functions establishes a quantified basis for determining the structural type of each node in the page structure graph. These initial confidence vectors fully utilize the geometric, content, and style features of the nodes themselves, and provide preliminary classification results through similarity comparison with prototypes of each structural type. Compared to rigid single classification labels, the initial confidence vectors retain confidence assessments for multiple possible structural types. This soft probabilistic representation can reflect the uncertainty of classification and provides a flexible initial state for subsequent contextual reasoning using graph neural networks combined with spatial adjacency relationships between nodes.

[0064] S104: Based on the topology of the page structure graph, the initial confidence vector of each node is corrected to obtain the final confidence vector.

[0065] In S104 above, after extracting the feature vectors of each node and calculating the initial confidence vector, the initial confidence vector of each node is corrected based on the topological structure of the page structure graph to obtain the final confidence vector. The correction process is to optimize the accuracy of the structure type judgment by utilizing the spatial relationship and semantic association between nodes.

[0066] Based on the topology of the page structure graph, the initial confidence vector of each node is corrected to obtain the final confidence vector. Specifically, this includes: obtaining the current node from the page structure graph (which can be any node in the graph); obtaining a preset relationship compatibility matrix, which contains compatibility scores for nodes of various preset structure types connected by edges of specific types; obtaining all neighboring nodes of the current node from the page structure graph, and obtaining the confidence score of each neighboring node belonging to various preset structure types, multiplying this score with the corresponding compatibility score in the relationship compatibility matrix, and summing the results to obtain the total support of the neighboring nodes for the current node belonging to various preset structure types; and, based on a preset smoothing factor, adjusting the initial confidence vector of each node. The initial probability of the previous node belonging to each preset structure type is weighted and summed with the total support to obtain the updated confidence of the current node belonging to each preset structure type. The updated confidence of the current node belonging to all preset structure types is normalized to obtain the confidence vector of the current node in the current iteration. Iteration is performed on all nodes in the page structure graph to obtain the confidence vector of all nodes in the current iteration. The change in the confidence vector of all nodes in the current iteration is calculated from the previous iteration, and the maximum value of the change of all nodes is taken as the overall change. When the overall change is less than a preset threshold, the iteration is stopped and the confidence vector obtained in the current iteration is taken as the final confidence vector.

[0067] Specifically, the current node is obtained from the page structure diagram. The current node can be any node in the page structure diagram. In actual implementation, all nodes in the page structure diagram are traversed, and correction operations are performed on each node sequentially. This can be achieved by maintaining a list of nodes to record all nodes in the page structure diagram, and selecting nodes one by one as the current processing object through a loop. For example, assuming the page structure diagram contains N nodes labeled as node 1 to node N, node 1 is first selected as the current node for confidence correction. After correction, node 2 is selected as the current node, and so on until all nodes have been processed. The initial confidence vector of the current node has been calculated in the above steps using the spatial distance between the feature vector and the prototype vector. This initial confidence vector contains the initial probability that the current node belongs to each preset structure type, denoted as vector B. i =(b i1 b i2 b i3 b i4 ), where b i1 b represents the initial probability that node i belongs to the label structure type. i2 b represents the initial probability of belonging to a special control structure type. i3 b represents the initial probability of belonging to a table cell structure type. i4This represents the initial probability of belonging to the paragraph text structure type, and the sum of the four initial probabilities equals 1.

[0068] After obtaining the current node, a preset relationship compatibility matrix is ​​further obtained. This matrix contains compatibility scores for nodes of various preset structural types connected by specific types of edges. Edges in the page structure diagram represent spatial or semantic relationships between nodes. Different edge types correspond to different semantic associations; for example, horizontal proximity edges indicate that two nodes are adjacent horizontally, vertical proximity edges indicate that they are adjacent vertically, and parent-child relationship edges indicate that there is an inclusion or subordinate relationship between nodes. The relationship compatibility matrix quantifies the rationality or compatibility of nodes of different structural types connected by different types of edges. This matrix is ​​a multidimensional tensor or a collection of multiple two-dimensional matrices, with each edge type corresponding to a compatibility matrix. The relationship compatibility matrix is ​​pre-constructed based on the structural patterns of medical record documents and expert knowledge. This can be achieved by statistically analyzing the frequency of connections between nodes of different structural types through different edge types in a large number of medical record samples, and then normalizing the frequency to obtain the compatibility score.

[0069] For example, for horizontal proximity edge types, the proportion of times a node of the label structure type and a node of the special control structure type are connected by a horizontal proximity edge in the medical record sample is counted out of all horizontal proximity connections of label nodes. This proportion is used as the compatibility score of label type and special control type connected by horizontal proximity edges. Assuming that statistical analysis shows that horizontal proximity between label nodes and special control nodes is more common, because field labels in medical records such as "Gender:" are often adjacent to radio button controls on the right, the compatibility score of label type and special control type connected by horizontal proximity edges is relatively high, possibly 0.8. Conversely, horizontal proximity between label type and paragraph text type is less common, so the compatibility score is lower, possibly 0.1. A compatibility matrix is ​​constructed for each edge type in this way, with rows and columns corresponding to various preset structure types, and matrix elements Ctype(t)... i , t j ) represents the structure type t i Node and structure type t j The compatibility score is calculated by connecting nodes via edges of type `type`. The design of the compatibility matrix reflects domain knowledge of node relationships in medical records, providing a quantitative basis for relational constraints in subsequent confidence level adjustments.

[0070] The process retrieves all neighboring nodes of the current node from the page structure graph, and obtains the confidence score of each neighboring node for each preset structure type. This score is then multiplied by the corresponding compatibility score in the relationship compatibility matrix and summed to obtain the total support of the neighboring nodes for the current node's various preset structure types. The page structure graph, as a directed or undirected graph, records the connection relationships between nodes, with each edge connecting two nodes and its type labeled. The set of all neighboring nodes of the current node i is read and denoted as Ni, where brackets i and j represent edges, and curly braces represent the vertical lines indicating an edge between node i and node j. The edge type between the current node and each neighboring node is also recorded. For each neighboring node j, the confidence vector B for that neighboring node in the current iteration is obtained. j =(b j1 b j2 b j3 b j4 The confidence vector is the initial confidence vector of the neighboring nodes in the first iteration, and in subsequent iterations it is the confidence vector updated in the previous iteration.

[0071] Further obtain the edge type (type) between the current node and its neighbor node j. ij And extract the corresponding edge type compatibility matrix Ctype from the preset relationship compatibility matrix. ij Neighbor node j belongs to structure type t with respect to current node i. k Support is calculated by comparing the confidence scores of neighbor node j for each structural type with the scores of nodes of that structural type via edge type. ij With type t k The sum of the products of the compatibility scores of connected nodes, i.e., the formula for calculating support: ; where b jl Neighbor node j belongs to structure type t l confidence score, Ctype ij (t) l , t k ) is a structure type t l Node and structure type t k The compatibility score of nodes connected by edges of type type-ij is calculated. The total support of the current node for each preset structural type is obtained by summing the support scores of all neighboring nodes, denoted as S. i .

[0072] For example, suppose the current node i is a text block node in the medical record, and the initial confidence vector is B. i= (0.6, 0.2, 0.1, 0.1), indicating that this node is more likely to belong to the label structure type. The current node i has two neighboring nodes: neighbor j1 is located to the right of the current node and connected by a horizontal proximity edge, and neighbor j2 is located below the current node and connected by a vertical proximity edge. The confidence vector of neighbor j1 is B. j1 = (0.1, 0.7, 0.1, 0.1), indicating that this node is more likely to belong to a special control structure type. The confidence vector of neighbor node j2 is B. j2 = (0.7, 0.1, 0.1, 0.1), indicating that this node is also likely to belong to the label structure type. Obtain the compatibility matrices of horizontal and vertical neighboring edges from the preset relationship compatibility matrix. Assume that in the horizontal neighboring edge compatibility matrix, the compatibility score between label type and special control type is 0.8, and the compatibility score between label types is 0.2; in the vertical neighboring edge compatibility matrix, the compatibility score between label types is 0.6, and the compatibility score between label types and special control types is 0.3. The support s of neighboring node j1 for the current node i to belong to the label type. ij1 The formula is 0.1 multiplied by 0.2, plus 0.7 multiplied by 0.8, plus 0.1 multiplied by 0.1, plus 0.1 multiplied by 0.1, which equals 0.6. Here, 0.1 represents the confidence that neighbor node j1 belongs to the label type, 0.2 represents the compatibility score between label type nodes connected by horizontal proximity edges, 0.7 represents the confidence that neighbor node j1 belongs to the special control type, and 0.8 represents the compatibility score between special control type nodes and label type nodes connected by horizontal proximity edges. Subsequent terms are calculated similarly. The support s of neighbor node j2 for current node i belonging to the label type is also calculated. ij2 The formula is 0.7 multiplied by 0.6 plus 0.1 multiplied by 0.3 plus 0.1 multiplied by 0.1 plus 0.1 multiplied by 0.1, which equals 0.47. Therefore, the total support of neighboring nodes for the current node i belonging to the label type is S. i =0.6 + 0.47 = 1.07. Through similar calculations, we can obtain the total support of neighboring nodes for the current node belonging to other structural types.

[0073] Based on a preset smoothing factor, the initial probability of the current node belonging to each preset structure type is weighted and summed with the total support to obtain the updated confidence score of the current node belonging to each preset structure type. The preset smoothing factor, denoted as α, is a parameter between 0 and 1, used to balance the influence of the initial probability calculated from the node's own features and the support of neighboring nodes on the confidence score update. The value of the smoothing factor α determines the degree to which the node's own information is preserved and the degree of dependence on neighboring information during the confidence score correction process. A value closer to 1 indicates a greater reliance on the node's own initial judgment, while a value closer to 0 indicates a greater reliance on the support of neighboring nodes. In practical applications, the smoothing factor α can be fine-tuned on the training dataset through cross-validation experiments to achieve the optimal structure type recognition accuracy on the validation set. A typical α value range is 0.3 to 0.7. The current node i belongs to structure type t. k The formula for calculating the update confidence level is: ; where b i (t k ) represents the type t to which the current node belongs. k The initial probability, S i (t k The parentheses indicate that the neighboring node belongs to type t in relation to the current node. k Total support, b i11 (t k ) represents the structure type t to which the current node i belongs. k The updated confidence level. Continuing the example above, assuming the preset smoothing factor α equals 0.5, the initial probability that the current node i belongs to the label type is 0.6, and the total support of neighboring nodes belonging to the label type is 1.07, then the updated confidence level is b. i11 (Label) = 0.5 * 0.6 + 0.5 * 1.07 = 0.835. Similarly, calculate the update confidence score for the current node belonging to other structure types. Assuming the initial probability of belonging to a special control type is 0.2 and the total support is 0.8, the update confidence score is b. i11 (Special control) = 0.5 * 0.2 + 0.5 * 0.8 = 0.5. By using a weighted summation method, the confidence score update comprehensively considers the judgment of the node's own characteristics and the constraints of the relationship between neighboring nodes. This ensures that the confidence score update maintains respect for the node's own characteristics while incorporating prior knowledge of the node relationships in the graph structure, thereby improving the accuracy of the judgment.

[0074] The update confidence scores of the current node belonging to all preset structure types are normalized to obtain the confidence vector of the current node in the current iteration. Since the update confidence scores are obtained through weighted summation, the sum of the individual update confidence scores may not equal 1. To maintain the probabilistic nature of the confidence vector—that is, the sum of the confidence scores for all structure types is 1—the update confidence scores need to be normalized. The normalization formula is: ; where b i11 (t k To update the confidence level, b i12 (t k ) represents the normalized confidence level, T represents the preset set of structure types, and t l This is an index variable for iterating through all preset structure types. Continuing the example above, assume the update confidence scores for the current node belonging to the four structure types are: label 0.835, special control 0.5, table 0.3, and paragraph 0.2, with a sum of 1.835. The normalized confidence scores are for label type b... i12 (Label) = 0.455, Special control type b i12 (Special control) = 0.272, Table type b i12 (Table) = 0.163, Paragraph type b i12 (Paragraph) = 0.109. After normalization, the sum of the four values ​​is 0.455 + 0.272 + 0.163 + 0.109, which is approximately equal to 1. The normalized confidence vector is denoted as B. i12 =(0.455, 0.272, 0.163, 0.109), this vector serves as the confidence vector for the current node in the current iteration. Normalization ensures that the confidence vector maintains a mathematically reasonable probability distribution, allowing subsequent iterative updates and structure type determinations to be based on a consistent probabilistic framework.

[0075] The above iterative process is performed on all nodes in the page structure graph to obtain the confidence vector of all nodes in the current iteration. After completing the confidence update and normalization of the current node, the normalized confidence vector obtained by the current node in this iteration is saved to the node attributes or a temporary storage area. The next node in the page structure graph is selected as the new current node, and the steps of obtaining neighboring nodes, calculating total support, weighted summation, and normalization are repeated until all N nodes in the page structure graph have been processed. In actual implementation, a synchronous update strategy or an asynchronous update strategy can be adopted. The synchronous update strategy means that the confidence update of all nodes in one iteration is based on the confidence value of the previous iteration. That is, the neighboring node confidence used when calculating the support of neighboring nodes in the current iteration is the result of the previous iteration. Only after all nodes have completed the calculation of updated confidence is the confidence vector of all nodes uniformly updated to the new value. Asynchronous update strategy means that the confidence update of a node can immediately use the latest calculated confidence of its neighboring nodes. That is, if a neighboring node has been updated in the current iteration, its latest confidence is used when calculating the neighboring support of the current node. In this embodiment, a synchronous update strategy is preferred to ensure the mathematical stability and reproducibility of the iteration process. After all nodes are updated, the confidence vectors of all nodes in the current iteration are obtained. These confidence vectors have incorporated the inter-node relationship information compared to the initial confidence vectors, reflecting the structural type tendency of the nodes under the graph structure constraints.

[0076] Calculate the change in the confidence vector of all nodes in the current iteration compared to the initial confidence vector. When the change in the confidence vector of all nodes is less than a preset threshold, stop the iteration and use the confidence vector obtained in the current iteration as the final confidence vector. The change in the confidence vector is used to measure the convergence of the iterative update process. When the change is sufficiently small, it indicates that the confidence distribution of the nodes has stabilized, and continuing the iteration will not bring significant changes. At this point, the iteration can be terminated, and the current confidence vector can be output as the final result. Calculate the difference between the confidence vector of each node in the current iteration and the confidence vector of the previous iteration. Commonly used difference measurement methods include Euclidean distance, Manhattan distance, or maximum component difference. For example, the formula for calculating the change in confidence of node i using Euclidean distance is: Where K is the number of preset structure types, b i (t) k (Current and b) i (t) k The previous iteration and the previous iteration respectively refer to the current iteration and the iteration in which node i belongs to type t. kThe confidence level is calculated. The change in confidence level for all N nodes is calculated, and the largest change is taken as the overall change index, or the average change is taken as the index. A threshold for change is preset, typically between 0.001 and 0.01. When the overall change is less than the threshold, the iteration is considered to have converged, the iteration is stopped, and the confidence vector of all nodes obtained in the current iteration is taken as the final confidence vector.

[0077] If the change in the confidence vector of all nodes is greater than or equal to a preset threshold, the confidence vector obtained in the current iteration is used as the initial confidence vector for the next iteration, and the process returns to retrieve the current node for the next iteration. The logic of the iteration process is to gradually optimize the confidence distribution by repeatedly utilizing the relationship information between nodes in the graph structure. Each iteration is updated based on the result of the previous iteration, allowing the propagation and correction of confidence to spread throughout the graph and eventually reach a globally consistent stable state. In practical applications, a maximum iteration limit is set to avoid infinite loops, for example, setting the maximum number of iterations to 10 or 20. When the number of iterations reaches the upper limit but the change is still not lower than the threshold, the iteration is forcibly stopped and the current confidence vector is output. Continuing the example above, assuming that after the first iteration, the confidence vectors of all nodes are calculated, and the overall change of 0.05 is greater than the change threshold of 0.01, then a second iteration is performed. In the second iteration, the result of the first iteration is used as the initial confidence vector, and the steps of obtaining neighboring nodes, calculating total support, weighted summation, and normalization are executed again to obtain the confidence vector of the second iteration. The change of 0.02 is still greater than the change threshold, so a third iteration is performed. Assuming that after the third iteration, the change of 0.008 is less than the change threshold of 0.01, then the iteration is considered to have converged and the iteration is stopped. The confidence vectors of all nodes obtained in the third iteration are used as the final confidence vectors. By iteratively correcting the initial confidence vectors of each node based on the topological structure of the page structure graph, the spatial relationships and semantic associations between text block nodes in the electronic medical record document are fully utilized. This makes the determination of the node's structural type no longer an isolated decision but incorporates the global information and local constraints of the graph structure. The corrected final confidence vector has higher accuracy and consistency than the initial confidence vector because the structural type judgment results of neighboring nodes support or inhibit the current node through the compatibility matrix, making the distribution of structural types more coordinated and reasonable in space.

[0078] S105: Determine the structure type of the text block corresponding to each node based on the final confidence vector, and generate a structured electronic medical record document based on the structure type of each text block and the output structured document type.

[0079] In step S105 above, after determining the structural type of the text block corresponding to each node based on the final confidence vector, the identified structural information is converted into a standardized electronic medical record document for subsequent use in the electronic medical record editor. Since different electronic medical record systems have different requirements for data formats, this application supports two mainstream structured document formats: XML and JSON, ensuring the standardization and compatibility of the generated documents through a unified conversion mechanism. The structure type of the text block corresponding to each node is determined based on the final confidence vector. A structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. Specifically, this includes: obtaining the element with the largest value in the final confidence vector corresponding to each node, and using the preset structure type corresponding to the element with the largest value as the structure type of the text block corresponding to each node; logically associating and hierarchically combining multiple text blocks according to their structure types and the spatial adjacency relationships between text blocks in the page structure diagram to construct a document logic tree; if the output structured document type is XML, converting each level node in the document logic tree into corresponding XML tags, and using the content information of the text block as the tag value to generate an XML-formatted structured electronic medical record document; if the output structured document type is JSON, traversing the document logic tree, converting each level node in the document logic tree into a key-value pair structure, and using the content information of the text block as the value corresponding to the key to generate a JSON-formatted structured electronic medical record document.

[0080] Specifically, the final confidence vector corresponding to each node is obtained. The element with the largest value in this vector is identified, and its position index corresponds to a preset structure type. This preset structure type is then used as the final structure type of the corresponding text block. For example, if the final confidence vector of a node is [0.06, 0.12, 0.78, 0.04], and the third element has the largest value of 0.78, and the third type in the preset structure type set is "table cell," then the text block corresponding to this node is determined to be of the table cell type. In this way, a clear structure type label is determined for each node in the page structure diagram.

[0081] After determining the structural types of all text blocks, the logical structure of the document is constructed based on these structural types and the spatial adjacency relationships between the text blocks. The spatial adjacency relationships between each text block are extracted from the page structure diagram. These relationships are described by the edges constructed in the previous steps, including spatial positional information such as vertical adjacency, horizontal adjacency, and containment relationships between text blocks. Based on the structural types and spatial adjacency relationships of the text blocks, a document logic tree is constructed by hierarchically combining them according to the semantic logic of the medical record document. The root node of the document logic tree represents the entire medical record document. The first-level child nodes represent the main chapters or areas of the medical record, such as "Basic Information Area," "Chief Complaint Area," "Physical Examination Area," and "Diagnosis Result Area." Deeper-level child nodes represent the specific content elements within each area. For example, if a text block is identified as a "Table Title" type, and the multiple adjacent text blocks below it are of the "Table Row" type, these text blocks are organized into a logical table node. The table title serves as the title attribute of this table node, each table row serves as a child node of this table node, and each table row may contain multiple "Table Cell" type text blocks as deeper-level child nodes. This recursive hierarchical combination transforms a flat collection of text blocks into a document logic tree with clear hierarchical relationships.

[0082] After constructing the document logic tree, the corresponding format conversion is performed based on the output structured document type selected by the user in the first step. If the user selects XML format, the document logic tree is traversed, and each level node in the tree is converted into the corresponding XML tag structure. The root node is converted into the root tag of the XML document. For table structures, table nodes are converted into... <row>Tags, table cells converted <cell>Labels, text content within cells as <cell>The value of the tag. For list structures, convert the list nodes to... <list>Tags, list items converted <item>Tags. For fields that require binding to special controls, add the control type attribute to the corresponding XML tag, for example... <gender controltype=""radio”"> male< / gender> This indicates that the field needs to be bound to a radio button control. Through this conversion mechanism, a complete and well-structured XML-formatted electronic medical record document is generated. This document conforms to XML syntax specifications and can be directly parsed and used by electronic medical record systems that support XML format.

[0083] If the user chooses to output in JSON format, the document logic tree is traversed again, but a different transformation strategy is used to convert each level of nodes in the tree into a key-value pair structure. The root node is converted into a JSON object, the first-level child nodes are converted into keys of this object, and the content or substructure of each child node is converted into the value of the corresponding key. For example, the root node "Medical Records" in the document logic tree is converted into a JSON object {}, the first-level child node "Basic Information" is converted into a key "basicInfo" of this object, and the value corresponding to this key can be another JSON object containing key-value pairs of fields such as patient name, gender, and age. For table structures, table nodes are converted into a JSON array, where each element represents a row, and each row is a JSON object containing key-value pairs of each cell. For list structures, list nodes are converted into JSON arrays, where each element corresponds to the content of a list item. For fields that need to be bound to special controls, a key of the control type is added to the corresponding JSON object, for example, {"gender":"Male", "controltype":"radio"}, indicating that the field needs to be bound to a radio button control. The content of the text blocks is used as the values ​​corresponding to the keys to populate the JSON structure. Through this conversion mechanism, a complete and well-structured JSON-formatted electronic medical record document is generated. This document conforms to the JSON syntax specification and can be directly parsed and used by electronic medical record systems that support JSON format.

[0084] S106: Identify target text blocks with a structure type of special control, and match and bind corresponding special controls in the structured electronic medical record document based on the semantic information of the target text block.

[0085] In step S106 above, after generating the structured electronic medical record document, fields requiring special controls are further processed so that users can use appropriate interactive controls when entering data in the electronic medical record editor. Because the medical record document contains many fields with fixed options, such as gender, blood type, marital status, and allergy history, these fields should not be allowed to accept arbitrary text input by the user. Instead, special controls such as radio buttons, checkboxes, and drop-down lists should be used to limit the range of selectable values, thereby ensuring data standardization and accuracy and avoiding inconsistencies or errors caused by free input. First, all text blocks in the structured electronic medical record document are traversed, and target text blocks identified as special control types in the above steps are selected. These target text blocks have been marked as areas requiring special controls during the structured parsing stage. The structure type indicates that the field corresponding to this text block should use special controls instead of ordinary text input boxes for data entry.

[0086] Semantic information of each target text block is acquired, including field names, field descriptions, and possible option texts. Natural language processing (NLP) techniques are used to perform semantic analysis on the field names, extracting core semantic features. A special control type knowledge base can be established, containing mappings between common medical field names and control types. For example, the "gender" field maps to radio button controls with options "male" and "female"; the "blood type" field maps to dropdown list controls with options "A," "B," "AB," and "O"; and the "allergy history" field maps to checkbox controls with options including "drug allergy," "food allergy," and "no allergy." The knowledge base also includes synonyms and variations of field names. The semantic information of the target text block is matched against the special control type knowledge base. A semantic similarity calculation method is used to find the most suitable control type for that field, and the control type with the highest score is selected as the matching result.

[0087] For example, for a target text block named "Patient Gender," semantic matching of "Patient Gender" with the "Gender" template in the knowledge base is performed to identify the core semantic meaning as "gender," thus determining that a radio button control should be used, and retrieving the standard options "Male" and "Female" for this control from the knowledge base. After determining the control type and options, control definition information is added to the corresponding location in the structured electronic medical record document. For XML format documents, control type and option attributes are added to the XML node corresponding to the target text block, for example, ... <gender> male< / gender> Modified to <gender controltype=""radio”options="男,女”"> male< / gender> This indicates that the field uses a radio button control with options "Male" and "Female," and the current default value is "Male." For JSON format documents, add control-related keys to the corresponding key-value pairs, for example, modifying {"gender":"Male"} to {"gender":{"value":"Male","controltype":"radio","options":["Male","Female"]}}. Through this control binding mechanism, all fields in the structured electronic medical record document that require special controls are configured with corresponding control types and control properties. This allows users to directly use these special controls for data entry after importing the generated electronic medical record template into the electronic medical record editor, without having to manually configure control types and options for each field individually. This greatly improves the usability of the electronic medical record template and ensures the standardization and accuracy of the entered data through the constraint function of the controls.

[0088] S107: Based on the semantic information of each field in the structured electronic medical record document, match and bind the corresponding data source path from the preset basic data source library, and output the electronic medical record template.

[0089] In step S107 above, after binding the special controls, it is necessary to match and bind the corresponding data source paths for all fields in the structured electronic medical record document. This ensures that the medical record fields can be associated with the data in the backend database during actual use of the electronic medical record system, enabling automatic data filling and persistent storage. Because the electronic medical record system needs to read various types of patient medical data from the backend database to fill the medical record fields during runtime, and also needs to write new data entered by doctors back to the database, each medical record field must have a clearly defined data source path. Traditional data source binding methods require users to manually search and select the data source path for each field. Due to the large number and complex hierarchy of medical data source paths, manual matching is not only extremely inefficient but also prone to binding errors or omissions. To solve this problem, this application adopts an intelligent matching algorithm based on semantic similarity calculation to automatically find the most suitable data source path for each field.

[0090] Based on the semantic information of each field in the structured electronic medical record (EMR) document, the system matches and binds the corresponding data source paths from a preset basic data source library and outputs an EMR template. Specifically, this includes: extracting the text content of each field from the structured EMR document; calculating the semantic vector for each field; obtaining the standard semantic vectors corresponding to each standard data source path in the preset basic data source library; calculating the semantic similarity score between the field semantic vector and each standard semantic vector; obtaining the highest score among the semantic similarity scores and determining whether the highest score is greater than or equal to a preset similarity threshold; if the highest score is greater than or equal to the preset similarity threshold, binding the field to the standard data source path corresponding to the highest score; if the highest score is less than the preset similarity threshold, marking the field as pending binding and generating a prompt message; receiving the user's input of a custom data source path for the pending-binding field based on the prompt message; binding the field to the custom data source path and adding the custom data source path to the preset basic data source library; and generating and outputting the EMR template after all fields in the structured EMR document have been bound.

[0091] Specifically, the text content of each field is extracted from structured electronic medical record documents. This text content typically consists of field names or descriptions, such as "patient name," "date of birth," and "blood pressure value." Natural language processing and feature extraction are then performed on the text content of each field. A pre-trained semantic coding model can be used to convert the text content into a high-dimensional vector representation, obtaining the corresponding semantic vector for each field. Semantic vectors can capture the deep semantic information of the text, allowing fields with similar semantics to be recognized as similar even if their expressions differ. For example, the three different expressions "patient name," "patient's name," and "name" are very close in semantic space because they refer to the same concept. A pre-established basic data source library is constructed, containing paths to commonly used medical data fields, such as "patient.basicInfo.name" representing the patient's name in basic information, "patient.basicInfo.birthDate" representing the patient's date of birth in basic information, and "patient.vitalSigns.bloodPressure" representing the patient's blood pressure in vital signs. For each standard data source path in the preset basic data source library, a corresponding standard semantic vector is pre-calculated and stored. These standard semantic vectors are also obtained by encoding the semantic description of the data source path.

[0092] The semantic vector of each field is compared with the standard semantic vectors of all standard data source paths in the preset base data source library, and a semantic similarity score is calculated between them. Semantic similarity is usually calculated using cosine similarity, which is the cosine of the angle between two vectors. The closer the cosine value is to 1, the more similar the two vectors are, and the closer their corresponding semantics are. By traversing all standard data source paths, a set of semantic similarity scores is generated for each field, and each score corresponds to a candidate data source path. The highest score is selected from this set of scores, and the standard data source path corresponding to the highest score is considered to be the data source path that best matches the semantics of the current field. To ensure the accuracy of the matching, a preset similarity threshold is also set. The preset similarity threshold is usually set to a value between 0.7 and 0.9, indicating that a match is considered successful only when the semantic similarity reaches a certain level. It is determined whether the highest score is greater than or equal to the preset similarity threshold. If the highest score is greater than or equal to the preset similarity threshold, a suitable data source path is considered to have been found, and the field is automatically bound to the standard data source path corresponding to the highest score. For example, if the similarity score between the semantic vector of the field "patient name" and the standard semantic vector of the data source path "patient.basicInfo.name" is 0.92, and this score is the highest among all candidate paths, and 0.92 is greater than the preset similarity threshold of 0.8, then the "patient name" field will be bound to the "patient.basicInfo.name" data source path.

[0093] If the highest score is less than the preset similarity threshold, it indicates that there is no standard data source path in the preset basic data source library that semantically matches the current field sufficiently. This may be because the field is a custom field of the medical institution or a new field not yet covered by the preset basic data source library. In this case, automatic binding cannot be completed, the field is marked as pending binding, and a prompt message is generated to notify the user that manual processing is required. The prompt message includes the field's name, location, the highest similarity score found by the system, and the corresponding candidate data source path for user reference. The list of fields in the pending binding state is prominently displayed on the user interface, allowing users to view detailed information about these fields. Based on the prompt message, the user enters a custom data source path for the fields in the pending binding state. This path can be an actual data source path found by the user from the backend database documentation, or a data source path added by the user according to their own system configuration.

[0094] For example, if a medical institution uses a custom "weight upon admission" field, and this field does not have a corresponding standard path in the preset basic data source database, the user can manually enter "patient.admissionInfo.weight" as the custom data source path. After receiving the user's input custom data source path, the field is bound to the custom data source path, completing the data source configuration for that field. Simultaneously, to improve the efficiency and intelligence of subsequent processing, the user-provided custom data source path and its corresponding field semantic information are added to the preset basic data source database, and a standard semantic vector for that custom data source path is calculated and stored. This way, when encountering semantically similar fields in the future, this newly added data source path can be automatically matched, eliminating the need for the user to manually enter it again, thus achieving dynamic expansion and continuous optimization of the data source database.

[0095] The matching and binding process described above continues until all fields in the structured electronic medical record (EMR) document have been bound to the data source path. A final verification and encapsulation of the entire EMR template is required to ensure its correct use within the EMR system. Because the EMR template directly impacts doctors' data entry efficiency and accuracy in practical applications, any missing or incorrect configuration may lead to system malfunctions or data loss; therefore, a comprehensive check is essential before output. Once all fields in the structured EMR document are bound, the EMR template is generated and output. This includes: obtaining the attribute configuration information of each special control in the bound structured EMR document; if a special control with empty attribute configuration information is detected, a verification exception report is generated and the user is prompted to configure it; supplementary attribute configuration information is received from the user until the attribute configuration information of all special controls is complete; if the attribute configuration information of all special controls is complete, the structured EMR document is rendered into a visual preview interface; the user's confirmation instruction for the visual preview interface is received, and the structured EMR document is encapsulated into a downloadable EMR template.

[0096] Specifically, the system retrieves the attribute configuration information of each special control in the bound structured electronic medical record document. This attribute configuration information includes key parameters such as control type, option list, default value, validation rules, and display format. It iterates through all nodes marked as special controls in the document, reading and verifying the completeness of the attribute configuration one by one. During the verification process, if a special control with empty attribute configuration information is detected—for example, a radio button control without an option list or a date picker control without a specified date format—the system immediately generates a validation exception report. This report details all incompletely configured controls and their missing attribute items, and prominently prompts the user to supplement the configuration through the user interface. The system receives supplementary attribute configuration information input by the user. The user can directly fill in the relevant configurations for controls with missing attributes on the prompt interface, such as adding an option list to a radio button or specifying the "YYYY-MM-DD" format for a date picker. Validation continues until the attribute configuration information of all special controls is complete, ensuring that each control has all the parameters required for normal operation in the electronic medical record system.

[0097] Once all special control property configuration information is confirmed to be complete, the structured electronic medical record document is rendered into a visual preview interface. The visual preview interface simulates the actual display effect of the electronic medical record system, converting the structured document in XML or JSON format into a user-friendly visual form. Users can intuitively see the layout structure, field positions, control styles, and data filling effects of the medical record in the preview interface. For example, radio buttons will be displayed as circular buttons, checkboxes as square check boxes, and tables will be presented according to the defined row and column structure. The preview interface supports interactive operations; users can try clicking controls, filling in sample data, and verifying whether the controls respond correctly, the layout is reasonable, and the field names are accurate. If users find any problems during the preview process, such as an inappropriate field position or an incorrect control option, they can return to the editing interface to make adjustments, save their changes, and regenerate the preview interface. The system receives user confirmation commands for the visual preview interface. Once the user is satisfied with the preview and clicks the confirmation button, the final template encapsulation process begins.

[0098] Structured electronic medical record (EMR) documents are packaged into downloadable EMR template files. The packaging process includes document formatting, metadata addition, integrity checks, and file packaging. Based on the output format selected by the user in the first step, the document is formatted into XML or JSON standard format, and necessary document header information and version identifiers are added to ensure the template file conforms to the import specifications of the EMR system. All metadata, such as control configurations, data source bindings, and style definitions, are fully embedded into the template file, making it a self-contained independent document that can be directly used in any compatible EMR system. A download link is generated and provided to the user, who can download the EMR template file for local storage or directly import it into the target EMR system. Through this series of rigorous verification and packaging processes, the output EMR template is ensured to have high integrity and usability. Users can use it directly without any additional formatting adjustments or data source configurations, thus achieving a fully automated conversion of EMR templates from paper documents to usable electronic templates.

[0099] In one possible implementation, besides using a page structure diagram to determine the structural type of each text block, the original document undergoes OCR recognition. The recognized results are saved as an intermediate document in Markdown or JSON format. This intermediate document retains the text content, paragraph structure, table row and column information, and font styles recognized by the OCR. A structural judgment algorithm then performs semantic analysis on the intermediate document returned by the OCR. By analyzing the semantic features of the text content, formatting tags, and contextual relationships, different structural types in the medical record are identified. Specifically, the structural judgment algorithm preliminarily determines the structural characteristics of text blocks by parsing formatting tags in the intermediate document, such as heading tags, table tags, and list tags in Markdown, or node type attributes in JSON.

[0100] Further semantic analysis of the text content identifies text blocks with specific semantic patterns. For example, text blocks containing keywords such as "name," "gender," and "age" typically correspond to a label structure type; text blocks containing options such as "male / female" and "yes / no" typically correspond to a special control structure type; text blocks with clear row and column separation correspond to a table cell structure type; and continuous long text blocks correspond to a paragraph text structure type. Structure types include label structure types, used to represent field labels in medical records, such as static descriptive text like "patient name" and "date of birth"; special control structure types, used to represent fields requiring interactive controls, such as gender selection boxes and allergy history checkboxes; table cell structure types, used to represent tabular data in medical records, such as examination result tables and medication record tables; and paragraph text structure types, used to represent free text paragraphs in medical records, such as chief complaints and medical history descriptions. This method, based on intermediate document semantic analysis, can accurately identify the structure type of each text block without relying on a page structure diagram.

[0101] In one possible implementation, structured electronic medical record documents can also be generated using a large model with prompt words. Medical record images or PDF documents are directly input into a large language model. Leveraging the model's multimodal understanding and text generation capabilities, carefully designed prompt words guide the model to recognize the medical record content and output a structured document according to predefined XML or JSON syntax rules. The prompt words are instruction text containing a task description, output format requirements, and examples, used to guide the large language model to understand the task objective and generate compliant output. The prompt words include XML or JSON tag definition specifications, clearly indicating how various medical record elements should be represented, such as which tags should be used for basic patient information, how table structures should be nested, and how special controls should be defined. The prompt words also include node nesting rules, specifying how information at different levels should be organized. For example, a patient information node should contain name, gender, and age sub-nodes, and each sub-node may contain more granular attribute information. The prompt word embeds a data source binding path mapping table, which lists the correspondence between common medical record fields and data source paths. For example, the "patient name" field corresponds to the "patient.basicInfo.name" data source path, and the "visit date" field corresponds to the "visit.admissionDate" data source path, so that the large language model can complete the binding of data source paths synchronously when generating structured documents.

[0102] The prompts also include several standardized transformation cases as a reference for few-shot learning. These cases demonstrate the complete transformation process from raw medical records to structured documents. Each case contains an input medical record sample and a corresponding standardized output document. Through multiple cases of different types, the large language model can learn the general patterns and specific rules of medical record transformation. For example, a case might include a transformation example of an admission record, demonstrating how to convert text such as "Patient Zhang San, male, 45 years old" into an XML structure containing name, gender, and age nodes, and binding the corresponding data source path to each node. Medical record images or PDF documents, along with the prompts, are input into the large language model. The model first understands the input medical record content, identifies the various types of information contained in the medical record, and then generates a structured document according to the format specifications in the prompts and the transformation cases, following predefined XML or JSON syntax rules. The generated structured document contains complete medical record content, a correct node hierarchy, appropriate control definitions, and accurate data source path bindings, and can be directly used as an electronic medical record template.

[0103] like Figure 2 As shown, the system first receives raw medical record documents in various formats from the user, including image formats such as PNG, PDF documents, and DOCX documents. The user also inputs the desired structured document type, and the subsequent document generation strategy is determined based on the user's selection. Different processing methods are used to parse the input document according to its format type, obtaining text blocks and their geometric layout, content, and format information. The geometric layout, content, and format information of the text blocks are then analyzed to determine the structure type. Based on the identified structure type of each text block, different conversion algorithms and strategies are applied to generate structured electronic medical record documents in XML or JSON format, respectively. After generating the structured document, text blocks requiring special controls are processed. The control type is automatically matched based on the semantic information of the fields, and the controls are bound to the corresponding document nodes. For fields requiring data source binding, the text content of each field is extracted from a preset basic data source library, and the field semantic vector is calculated. Then, the standard semantic vectors of each standard data source path in the data source library are obtained, and the best matching data source path is determined by calculating the semantic similarity score. The system determines whether the highest similarity score is greater than or equal to a preset similarity threshold. If the highest score meets the threshold, the field is directly bound to the corresponding standard data source path. If the highest score is lower than the threshold, the field is marked as pending binding, and a prompt message is generated to notify the user to manually provide a custom data source path. After the user provides the new data source path, the binding is completed, and the custom data source path is added to the basic data source library for subsequent use. Once all fields in the structured electronic medical record document have completed data source binding, the generated document undergoes final verification. The electronic medical record document with completed control and data source binding is rendered into a visual preview interface for user confirmation, and the structured electronic medical record document is packaged into a standardized electronic medical record template file available for download.

[0104] This application embodiment also provides an apparatus for automatically generating electronic medical records. The apparatus includes a receiving unit, a first processing unit, a second processing unit, and a matching unit. The receiving unit receives an original document containing medical record information input by a user, and an output structured document type specified by the user. The first processing unit parses the original document to obtain multiple text blocks and their geometric layout information, content information, and format information. Based on the spatial adjacency relationships between the multiple text blocks, it constructs a page structure diagram, wherein nodes in the page structure diagram correspond to text blocks, and edges connecting nodes correspond to the spatial adjacency relationships between text blocks. The second processing unit calculates the geometric layout information, content information, and format information of each node in the page structure diagram to obtain feature vectors, and matches the feature vectors of each node with the prototype vectors of a preset structure type. The system performs spatial distance calculations to obtain the initial confidence vector for each node, which contains the initial probability that each node belongs to each preset structure type. Based on the topological structure of the page structure graph, the initial confidence vectors of each node are corrected to obtain the final confidence vector. The structure type of the text block corresponding to each node is determined according to the final confidence vector, and a structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. The matching unit identifies target text blocks with a structure type of special control, matches and binds the corresponding special controls in the structured electronic medical record document based on the semantic information of the target text block content. Based on the semantic information of each field in the structured electronic medical record document, the corresponding data source path is matched and bound from the preset basic data source library, and the electronic medical record template is output.

[0105] In one possible implementation, the second processing unit is used to extract the bounding box coordinates of each node based on geometric layout information, calculate the horizontal and vertical coordinates, width, and height of the text block corresponding to each node, and calculate the horizontal alignment features and vertical alignment features based on the position information of the text block on the page; combine the horizontal and vertical coordinates, width, height, horizontal alignment features, and vertical alignment features to obtain geometric layout features; extract the text characters from the content information of each node, match the text characters with a preset medical keyword dictionary to obtain keyword scores, calculate symbol scores by statistically analyzing specific symbol features in the text characters, and calculate the ratio of the number of numeric characters in the text characters to the total number of characters to obtain numeric proportions; combine the keyword scores, symbol scores, and numeric proportions to obtain content features; parse the format information of each node, extract the font size and weight values ​​of the text block corresponding to each node, combine the font size and weight values ​​to obtain style features; and concatenate the geometric layout features, content features, and style features to obtain the feature vector corresponding to each node.

[0106] In one possible implementation, the receiving unit is used to obtain the prototype vectors corresponding to each preset structure type. The preset structure types include label structure type, special control structure type, table cell structure type, and paragraph text structure type. The second processing unit is used to calculate the weighted Euclidean distance between the feature vector corresponding to each node and the prototype vector of each preset structure type. The weighted Euclidean distance is input into a distance conversion function for calculation to obtain a confidence score. The confidence scores of each node corresponding to each preset structure type are combined to obtain a preliminary confidence vector. The confidence scores in the preliminary confidence vector are normalized to generate the initial confidence vector corresponding to each node.

[0107] In one possible implementation, the receiving unit is configured to obtain the current node from the page structure graph, where the current node is any node in the page structure graph; obtain a preset relationship compatibility matrix, which contains compatibility scores of nodes of various preset structure types connected by edges of specific types; obtain all neighboring nodes of the current node from the page structure graph, and obtain the confidence score of each neighboring node belonging to various preset structure types, multiply it with the corresponding compatibility scores in the relationship compatibility matrix, and sum them to obtain the total support of the neighboring nodes for the current node belonging to various preset structure types; the second processing unit is configured to, based on a preset smoothing factor, process the current node belonging to each preset structure type... The initial probability of each structure type is weighted and summed with the total support to obtain the updated confidence score of the current node belonging to each preset structure type. The updated confidence scores of the current node belonging to all preset structure types are normalized to obtain the confidence vector of the current node in the current iteration. Iteration is performed on all nodes in the page structure graph to obtain the confidence vector of all nodes in the current iteration. The change in the confidence vector of all nodes in the current iteration is calculated compared with the confidence vector of the previous iteration, and the maximum value of the change among all nodes is taken as the overall change. When the overall change is less than a preset threshold, the iteration is stopped and the confidence vector obtained in the current iteration is taken as the final confidence vector.

[0108] In one possible implementation, the receiving unit is used to obtain the element with the largest value in the final confidence vector corresponding to each node, and use the preset structure type corresponding to the element with the largest value as the structure type of the text block corresponding to each node; the second processing unit is used to logically associate and hierarchically combine multiple text blocks according to the structure type of each text block and the spatial adjacency relationship between text blocks in the page structure diagram to construct a document logic tree; if the output structured document type is XML format, then each level node in the document logic tree is converted into the corresponding XML tag, and the content information of the text block is used as the tag value to generate an XML format structured electronic medical record document; if the output structured document type is JSON format, then the document logic tree is traversed, each level node in the document logic tree is converted into a key-value pair structure, and the content information of the text block is used as the value corresponding to the key to generate a JSON format structured electronic medical record document.

[0109] In one possible implementation, the receiving unit is used to extract the text content of each field from the structured electronic medical record document, calculate the semantic vector of each field corresponding to the text content; obtain the standard semantic vector corresponding to each standard data source path in the preset basic data source library, and calculate the semantic similarity score between the field semantic vector and each standard semantic vector; obtain the highest score among the semantic similarity scores, and determine whether the highest score is greater than or equal to a preset similarity threshold; the matching unit is used to bind the field to the standard data source path corresponding to the highest score if the highest score is greater than or equal to the preset similarity threshold; if the highest score is less than the preset similarity threshold, mark the field as pending binding and generate a prompt message; receive the custom data source path input by the user for the field in the pending binding state based on the prompt message, bind the field to the custom data source path, and add the custom data source path to the preset basic data source library; after all fields in the structured electronic medical record document have been bound, generate and output the electronic medical record template.

[0110] In one possible implementation, the receiving unit is used to acquire the attribute configuration information of each special control in the structured electronic medical record document that has been bound; the matching unit is used to generate a verification exception report and prompt the user to configure it if a special control with empty attribute configuration information is detected, and to receive supplementary attribute configuration information input by the user until the attribute configuration information of all special controls is complete; if the attribute configuration information of all special controls is complete, the structured electronic medical record document is rendered into a visual preview interface; the user's confirmation instruction on the visual preview interface is received, and the structured electronic medical record document is packaged into a downloadable electronic medical record template.

[0111] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0112] This application also discloses an electronic device. (See reference...) Figure 3 , Figure 3 This application provides a schematic diagram of the structure of an electronic device. The electronic device 300 may include: at least one processor 301, at least one network interface 304, a user interface 303, a memory 302, and at least one communication bus 305.

[0113] The communication bus 305 is used to enable communication between these components.

[0114] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0115] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0116] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 302, and by calling data stored in memory 302. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and application requests; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0117] The memory 302 may include random access memory (RAM) or read-only memory. Optionally, the memory 302 may include a non-transitory computer-readable storage medium. The memory 302 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 302 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described above, etc. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 302 may also be at least one storage device located remotely from the aforementioned processor 301.

[0118] like Figure 3 As shown, the memory 302, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for automatically generating electronic medical records.

[0119] exist Figure 3 In the electronic device 300 shown, the user interface 303 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 301 can be used to call the application program that automatically generates electronic medical records stored in the memory 302. When executed by one or more processors, the electronic device performs one or more of the methods described in the above embodiments.

[0120] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0121] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some service interfaces; indirect couplings or communication connections between devices or units may be electrical or other forms.

[0123] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0125] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0126] The above description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure.< / item> < / list> < / cell> < / cell> < / row> Tags, table rows converted

Claims

1. A method for automatically generating electronic medical records, characterized in that, The method includes: Receive the user input of the original document containing medical record information, and the output structured document type specified by the user; The original document is parsed to obtain multiple text blocks and their geometric layout, content, and format information. Based on the spatial adjacency relationship between the multiple text blocks, a page structure diagram is constructed, wherein the nodes in the page structure diagram correspond to the text blocks, and the edges connecting the nodes correspond to the spatial adjacency relationship between the text blocks. The geometric layout, content, and format information of each node in the page structure diagram are calculated to obtain feature vectors. The spatial distance between the feature vectors of each node and the prototype vectors of preset structure types is calculated to obtain an initial confidence vector for each node. The initial confidence vector contains the initial probability that each node belongs to each preset structure type. Specifically, the calculation of the geometric layout, content, and format information of each node in the page structure diagram to obtain feature vectors includes: Based on the geometric layout information, the bounding box coordinates of each node are extracted, and the horizontal and vertical coordinates, width, and height of the text block corresponding to each node are calculated. Horizontal alignment features and vertical alignment features are calculated based on the text block's position on the page. The horizontal and vertical coordinates, width, height, horizontal alignment features, and vertical alignment features are combined to obtain geometric layout features. Text characters are extracted from the content information of each node, and the text characters are matched with a preset medical keyword dictionary to obtain keyword scores. Specific symbol features in the text characters are statistically analyzed to obtain symbol scores, and the ratio of the number of numeric characters to the total number of characters in the text characters is calculated to obtain a numeric ratio. The keyword scores, symbol scores, and numeric ratios are combined to obtain content features. The format information of each node is parsed, and the font size and weight values ​​of the text block corresponding to each node are extracted. The font size and weight values ​​are combined to obtain style features. The geometric layout features, content features, and style features are concatenated to obtain the feature vector corresponding to each node. Based on the topology of the page structure graph, the initial confidence vector of each node is corrected to obtain the final confidence vector. The structure type of the text block corresponding to each node is determined based on the final confidence vector, and a structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. Identify target text blocks whose structure type is a special control type, and match and bind corresponding special controls in the structured electronic medical record document based on the semantic information of the target text blocks; Based on the semantic information of each field in the structured electronic medical record document, the corresponding data source path is matched and bound from the preset basic data source library, and an electronic medical record template is output.

2. The method according to claim 1, characterized in that, The step of calculating the spatial distance between the feature vectors of each node and the prototype vector of a preset structure type to obtain the initial confidence vector corresponding to each node specifically includes: Obtain the prototype vectors corresponding to each of the preset structure types, including label structure type, special control structure type, table cell structure type, and paragraph text structure type; Calculate the weighted Euclidean distance between the feature vector corresponding to each node and the prototype vector of each preset structure type; The confidence score is calculated using the weighted Euclidean distance input distance transformation function. The confidence scores of each node corresponding to each preset structure type are combined to obtain a preliminary confidence vector; The confidence scores in the preliminary confidence vector are normalized to generate the initial confidence vector corresponding to each node.

3. The method according to claim 2, characterized in that, The process of refining the initial confidence vector of each node based on the topology of the page structure graph to obtain the final confidence vector specifically includes: The current node is obtained from the page structure diagram, where the current node is any node in the page structure diagram; Obtain a preset relationship compatibility matrix, which contains compatibility scores of nodes of various preset structure types connected by edges of specific types; Obtain all neighboring nodes of the current node from the page structure diagram, and obtain the confidence score of each neighboring node belonging to various preset structure types. Multiply these scores with the corresponding compatibility scores in the relationship compatibility matrix and sum them to obtain the total support of the neighboring nodes for the current node belonging to various preset structure types. Based on a preset smoothing factor, the initial probability of the current node belonging to each of the preset structure types is weighted and summed with the total support to obtain the updated confidence of the current node belonging to each of the preset structure types; The update confidence of the current node belonging to all preset structure types is normalized to obtain the confidence vector of the current node in the current iteration; Iterative processing is performed on all nodes in the page structure diagram to obtain the confidence vector of all nodes in the current iteration; Calculate the change in the confidence vector of all nodes in the current iteration compared to the confidence vector in the previous iteration, and take the maximum value of the changes of all nodes as the overall change. When the overall change is less than a preset threshold, the iteration stops and the confidence vector obtained in the current iteration is used as the final confidence vector.

4. The method according to claim 1, characterized in that, The generation of structured electronic medical record documents based on the structure type of each text block and the output structured document type specifically includes: Obtain the element with the largest value in the final confidence vector corresponding to each node, and use the preset structure type corresponding to the element with the largest value as the structure type of the text block corresponding to each node. Based on the structural type of each text block and the spatial adjacency relationship between the text blocks in the page structure diagram, multiple text blocks are logically associated and hierarchically combined to construct a document logic tree; If the output structured document type is XML format, then each level node in the document logic tree is converted into the corresponding XML tag, and the content information of the text block is used as the tag value to generate a structured electronic medical record document in XML format; If the output structured document type is JSON format, then the document logic tree is traversed, each level node in the document logic tree is converted into a key-value pair structure, and the content information of the text block is used as the value corresponding to the key to generate a structured electronic medical record document in JSON format.

5. The method according to claim 1, characterized in that, The step of matching and binding corresponding data source paths from a preset basic data source library based on the semantic information of each field in the structured electronic medical record document, and outputting an electronic medical record template, specifically includes: The text content of each field is extracted from the structured electronic medical record document, and the semantic vector of each field is calculated from the text content. Obtain the standard semantic vectors corresponding to each standard data source path in the preset basic data source library, and calculate the semantic similarity scores between the field semantic vector and each of the standard semantic vectors respectively. Obtain the highest score among the semantic similarity scores, and determine whether the highest score is greater than or equal to a preset similarity threshold; If the highest score is greater than or equal to the preset similarity threshold, then the field is bound to the standard data source path corresponding to the highest score; If the highest score is less than the preset similarity threshold, the field is marked as pending binding and a prompt message is generated. Receive the user's custom data source path input for the field to be bound based on the prompt information, bind the field to the custom data source path, and add the custom data source path to the preset basic data source library; Once all fields in the structured electronic medical record document have been bound, the electronic medical record template is generated and output.

6. The method according to claim 5, characterized in that, Once all fields in the structured electronic medical record document have been bound, the electronic medical record template is generated and output, specifically including: Obtain the attribute configuration information of each special control in the structured electronic medical record document that has been bound; If a special control with empty attribute configuration information is detected, a validation exception report is generated and the user is prompted to configure it. Supplementary attribute configuration information input by the user is received until the attribute configuration information of all special controls is complete. If all the attribute configuration information of the special controls is complete, the structured electronic medical record document will be rendered as a visual preview interface. Upon receiving the user's confirmation instruction on the visual preview interface, the structured electronic medical record document is packaged into a downloadable electronic medical record template.

7. A device for automatically generating electronic medical records, characterized in that, The device includes a receiving unit, a first processing unit, a second processing unit, and a matching unit. The receiving unit receives the user-inputted original document containing medical record information, as well as the user-specified output structured document type. The first processing unit parses the original document to obtain multiple text blocks and their geometric layout information, content information, and format information. Based on the spatial adjacency relationship between the multiple text blocks, it constructs a page structure diagram, wherein the nodes in the page structure diagram correspond to the text blocks, and the edges connecting the nodes correspond to the spatial adjacency relationship between the text blocks. The second processing unit calculates the geometric layout information, content information, and format information of each node in the page structure diagram to obtain feature vectors. It then calculates the spatial distance between the feature vectors of each node and the prototype vectors of preset structure types to obtain an initial confidence vector for each node. The initial confidence vector contains the initial probability that each node belongs to each preset structure type. Specifically, the calculation of the geometric layout information, content information, and format information of each node in the page structure diagram to obtain feature vectors includes: extracting the bounding box coordinates of each node based on the geometric layout information; calculating the horizontal and vertical coordinates, width, and height of the text block corresponding to each node; and calculating the horizontal alignment feature and vertical alignment feature based on the position information of the text block on the page. The horizontal and vertical coordinates, width, height, horizontal alignment feature, and vertical alignment feature are combined to obtain geometric layout features. The text characters in the content information of each node are extracted, and the... The text characters are matched with a preset medical keyword dictionary to obtain keyword scores. Specific symbol features in the text characters are statistically analyzed to obtain symbol scores, and the ratio of the number of numeric characters to the total number of characters in the text characters is calculated to obtain a numeric ratio. The keyword scores, symbol scores, and numeric ratios are combined to obtain content features. The format information of each node is parsed, and the font size and weight values ​​of the text blocks corresponding to each node are extracted. The font size and weight values ​​are combined to obtain style features. The geometric layout features, content features, and style features are concatenated to obtain the feature vector corresponding to each node. Based on the topological structure of the page structure diagram, the initial confidence vector of each node is corrected to obtain a final confidence vector. The structure type of the text blocks corresponding to each node is determined based on the final confidence vector, and a structured electronic medical record document is generated based on the structure type of each text block and the output structured document type. The matching unit identifies target text blocks whose structure type is a special control type, matches and binds corresponding special controls in the structured electronic medical record document based on the semantic information of the target text block; matches and binds corresponding data source paths from a preset basic data source library according to the semantic information of each field in the structured electronic medical record document, and outputs an electronic medical record template.

8. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions, the user interface and the network interface are used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-6.

Citation Information

Patent Citations

  • Text information extraction method, system and equipment and medium

    CN113094509A

  • Text content processing method and device, computer equipment and storage medium

    CN113822283A