Multi-stage cascading processing method and system for medical test reports

Abstract

The application discloses a kind of medical inspection report multi-stage cascade processing method and system, wherein the method comprises: obtaining inspection report, and the original table data in the inspection report is cascade pretreated, and standardization table data is generated;Based on the standardization table data, structured index extraction is carried out, and structured index data is obtained, and the result value in the structured index data and reference range determine index state information;Based on the structured index data, generate basic information data and health advice text, wherein the health advice text is generated based on the index state information.The application effectively solves the problem that the expression of inspection report of different hospitals / equipment is quite different and cannot be aligned stably.

Description

Technical Field

[0001] This invention relates to the field of medical information processing technology, and more specifically, to a multi-stage cascade processing method and system for medical test reports. Background Technology

[0002] With the development of medical informatization, most laboratory reports issued by medical institutions are saved in PDF or image format, containing a large amount of structured tabular data. To achieve automated interpretation, it is usually necessary to parse the tables in the laboratory reports and extract information such as test indicators, result values, and reference ranges to generate structured data for subsequent analysis and health advice generation.

[0003] In existing technologies, the processing of laboratory report forms mainly involves extracting text information based on Optical Character Recognition (OCR) technology, followed by field matching and data extraction using fixed rules or templates. For example, table column names are mapped to predefined standard fields using preset field name rules or keyword matching methods. However, due to significant differences in column naming methods, arrangement structures, and abbreviation expressions in laboratory reports generated by different hospitals, different testing equipment, and different information systems, the same field may have multiple different expressions, making it difficult for a single rule matching method to adapt to complex and ever-changing real-world scenarios.

[0004] When test reports use new column name expressions or contain abbreviations, spelling variations, or semantic omissions, traditional rule-based matching methods often fail to correctly establish the mapping relationship between column names and standard fields, leading to field alignment failures and affecting the accuracy of subsequent indicator extraction. Furthermore, relying solely on semantic models for whole-table inference, while possessing some generalization ability, is prone to unstable output when column structures are complex or noisy, resulting in field misalignment or structural drift, making it difficult to guarantee engineering usability.

[0005] Therefore, how to improve the generalization ability of test reports with unknown formats while ensuring matching accuracy, and achieve stable and controllable semantic alignment and standardized processing of column names, has become a technical problem that urgently needs to be solved in the field of automatic parsing of medical test reports. Summary of the Invention

[0006] This invention provides a multi-stage cascade processing method and system for medical test reports, which effectively solves the problem of unstable alignment due to significant differences in the expression of test reports from different hospitals / equipment in the prior art.

[0007] According to one aspect of the present invention, a multi-stage cascaded processing method for medical test reports is provided, comprising: acquiring a test report and performing cascaded preprocessing on the original tabular data in the test report to generate standardized tabular data; extracting structured indicators based on the standardized tabular data to obtain structured indicator data, and determining indicator status information based on the result values ​​and reference ranges in the structured indicator data; generating basic information data and health advice text based on the structured indicator data, wherein the health advice text is generated based on the indicator status information.

[0008] According to another aspect of the present invention, a multi-stage cascaded processing system for medical test reports is also provided, comprising: a first-stage processing module configured to acquire a test report and perform cascaded preprocessing on the original tabular data in the test report to generate standardized tabular data; a second-stage processing module configured to extract structured indicators based on the standardized tabular data to obtain structured indicator data, and determine indicator status information based on the result values ​​and reference ranges in the structured indicator data; and a third-stage processing module configured to generate basic information data and health advice text based on the structured indicator data, wherein the health advice text is generated based on the indicator status information.

[0009] This invention effectively solves the problem of inconsistent and unreliable alignment of test reports from different hospitals / equipment in the prior art. Attached Figure Description

[0010] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0011] Figure 1 This is a flowchart of an optional multi-stage cascade processing method for medical test reports according to an embodiment of the present invention;

[0012] Figure 2 This is a flowchart of an optional intelligent parsing method for medical documents according to an embodiment of the present invention;

[0013] Figure 3 This is a timing diagram of an optional intelligent parsing method for medical documents according to an embodiment of the present invention;

[0014] Figure 4 This is a flowchart of an optional parallel medical record / prescription extraction task according to an embodiment of the present invention;

[0015] Figure 5 This is a flowchart of an optional three-stage inspection report processing method according to an embodiment of the present invention;

[0016] Figures 6 to 8 This is an interface diagram of an optional intelligent medical document parsing APP according to an embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] Figure 1 A flowchart of a multi-stage cascade processing method for medical test reports provided in this embodiment of the invention. The method mainly includes:

[0020] Step S102: Obtain the inspection report and perform cascade preprocessing on the original tabular data in the inspection report to generate standardized tabular data.

[0021] First, based on a preset set of standard column names, the sequence of original column names in the original table data is matched according to rules to establish an initial mapping relationship, resulting in first intermediate structured table data. For example, based on the preset set of standard column names and its synonym mapping dictionary, string matching is performed on each original column name in the sequence of original column names in the original table data to establish an initial mapping relationship between the original column names and the standard column names. Based on the initial mapping relationship, the original table data is aligned with its fields to generate the first intermediate structured table data, wherein the first intermediate structured table data includes matched standard column name fields and unmatched column name fields.

[0022] Secondly, semantic vector matching is performed on the unmatched column name fields in the first intermediate structured table data to establish a supplementary mapping relationship, thereby obtaining the second intermediate structured table data. For example, based on the unmatched column name fields in the first intermediate structured table data, a corresponding column name semantic vector representation is generated. The column name semantic vector representation is then matched with a preset standard column name vector library to determine the candidate standard column names corresponding to each unmatched column name field, and a supplementary mapping relationship is established. Based on the supplementary mapping relationship, the first intermediate structured table data is updated to generate the second intermediate structured table data, wherein the second intermediate structured table data includes standard column name fields after rule matching and vector matching, as well as fields that are still unmatched.

[0023] Finally, semantic inference is performed based on the second intermediate structured table data to establish an inference mapping relationship, and standardized table data is obtained based on the inference mapping relationship. For example, based on the second intermediate structured table data and the still unmatched fields, column name information and sample column data are extracted from the original table data to construct column semantic inference input data; the column semantic inference input data is input into the semantic inference model to perform semantic judgment on each column, and the column semantic judgment result is output. The column semantic judgment result includes the inference mapping relationship between the remaining unmatched column names and the standard column names; based on the inference mapping relationship, the second intermediate structured table data is finally aligned to generate the standardized table data.

[0024] Step S104: Extract structured indicators based on the standardized table data to obtain structured indicator data, and determine indicator status information based on the result values ​​and reference ranges in the structured indicator data.

[0025] For example, based on the standardized tabular data, each row of data is parsed to extract the project name field, result value field, reference range field, and unit field, generating initial indicator data; the result value field in the initial indicator data is subjected to numerical type identification and format cleaning to obtain normalized result value data; the reference range field in the initial indicator data is parsed to extract the upper and lower limit values, obtaining normalized reference range data; the normalized result value data and the normalized reference range data are compared to determine the status information of each indicator; the project name field, the normalized result value data, the normalized reference range data, and the status information are combined to generate the structured indicator data.

[0026] Step S106: Generate basic information data and health advice text based on the structured indicator data, wherein the health advice text is generated based on the indicator status information.

[0027] For example, based on the text content of the test report, basic information fields corresponding to the structured indicator data are extracted to generate basic information data, wherein the basic information fields include at least one of the following: name, gender, age, and report time; the structured indicator data and the basic information data are integrated to construct suggestion generation input data, and health suggestion text is generated based on the suggestion generation input data.

[0028] Figure 2 This invention provides an intelligent parsing method for medical documents. Figure 3 The timing diagram for this method is as follows: Figure 2 , 3 As shown, the method includes the following steps:

[0029] Step S202: Obtain the input file.

[0030] Receive medical report files uploaded by users and recognize them as PDFs or images.

[0031] Specifically, after receiving a medical record file to be interpreted from a user-uploaded file or an external interface, the system first performs file type detection to determine the subsequent parsing path. To avoid misjudgment based solely on the file extension (e.g., missing extension, modified extension, or lost during transmission), the system adopts an extension-independent detection method: it reads the first few bytes of the input file's binary data and matches them with preset file header features to complete the type determination. Specifically, if the first 4 bytes read are "%PDF" or match the header features of a PDF file, the input is determined to be a PDF file; if it does not match the PDF features, it is further matched with the magic number features of common image formats (such as JPEG, PNG, etc.). If the match is successful, the input is determined to be an image file; if it still cannot be recognized, the input is classified as "other types" and enters a degradation strategy, such as directly attempting OCR recognition, prompting the user to re-upload a recognizable format file, or transferring the input to an exception handling process, to ensure the system remains usable in complex input scenarios.

[0032] After completing file type detection and determining the processing path, this embodiment performs preprocessing operations on the input file to improve the accuracy and stability of subsequent OCR recognition. For image files or page images obtained by splitting PDFs, the system can first perform rotation correction and skew correction based on the layout detection or text direction detection results to eliminate recognition interference caused by shooting angle, tilt, or inversion. At the same time, for input images with low resolution, high noise, or uneven lighting, the system can perform enhancement processing such as noise reduction and contrast enhancement to improve the distinguishability of text edges, thereby improving the OCR recognition effect on low-quality images. In an optional embodiment, if the input is a multi-page PDF file, the system can split the PDF into multiple page objects by page and perform parallel or pipelined preprocessing and OCR recognition on each page. Then, the recognition results are summarized and merged according to the original page order to improve the overall processing efficiency and ensure the integrity of the output results.

[0033] Step S204: Perform OCR / parsing.

[0034] If the file is a PDF, the PDF parsing or rendering recognition interface is called to obtain the Markdown text and table structure; if the file is an image, the image OCR interface is called to obtain the Markdown text and table structure. The table is parsed from the Markdown structured result returned by the OCR. If the first row of the table might be a header, it is promoted to column names and the column name strings are normalized.

[0035] In this embodiment, the OCR recognition module is used to convert the input medical record file into a structured text result that can be used for subsequent information extraction and intelligent interpretation. After receiving the input file, the system first reads the file content in binary data stream form and uses the aforementioned file type detection mechanism to determine whether the input is a PDF document or an image file. Subsequently, the system selects and calls the corresponding OCR / parsing interface according to the detection result: when the input is a PDF document, the system can perform page parsing or page-level recognition on the PDF; when the input is an image file, the system performs OCR recognition on the image. The output of the OCR / parsing interface is preferably structured text in Markdown format, which may simultaneously contain structured tag information such as body paragraphs, heading levels, lists, and tables. After the OCR output is acquired, the system uses the Markdown structured text as a unified intermediate representation so that subsequent modules can parse and extract in a consistent manner. Furthermore, the system parses the table tags in the OCR output, identifies and extracts the table content separately from the Markdown text to form a table result, so as to achieve separate storage and subsequent parallel processing of text content and table content.

[0036] To improve the usability of the structured table results and the accuracy of subsequent field extraction, the system further performs column name promotion and normalization processing after table extraction. Specifically, when the OCR output table structure has a clearly defined header area, the system preferentially uses the header as the set of column names for the table and establishes the correspondence between column names and column data accordingly. If the table is missing a header, or the OCR result fails to correctly label the header, the system adopts a degradation strategy: by default, the first row of data in the table is promoted to column names, and the remaining rows are treated as data rows, to ensure that the table can still form a parsable column structure.

[0037] After the column names are determined, the system performs normalization processing on the column names to reduce the risk of field matching failures caused by multi-source input, OCR noise, and differences between full-width and half-width characters. The normalization processing may include: removing extra spaces and leading and trailing whitespace in the column names; standardizing the style of brackets; unifying full-width and half-width characters; and removing invisible or control characters.

[0038] Step S206, report type classification.

[0039] The OCR text is input into a large language model, and combined with prompt words and structured output constraints, the primary and secondary categories are output.

[0040] In this embodiment, the intelligent report classification module is used to automatically determine the type of the input report after OCR recognition, thereby identifying its primary and secondary categories and providing a basis for subsequent traffic routing and differentiated parsing strategies. The system first acquires the structured text content of the OCR output and optionally performs truncation or summarization processing based on the input length limit of the large model. For example, the text is limited to a preset length without destroying key semantic information, or highly relevant segments such as titles, key fields, diagnostic descriptions, test item names, and prescription drug information are prioritized to form text input for classification. Subsequently, the system constructs classification prompts, explicitly writing the classification task, category constraints, and output format requirements into the prompts. These prompts include at least: the task is to identify the primary and secondary categories of the report; the primary category is limited to the enumerated set "medical records, prescriptions, test reports, physical examination reports, and others"; the output must be a strict JSON structure for program parsing; and a fault tolerance specification is provided, i.e., when the model cannot determine the category, "other" is output as the default result. These methods improve classification stability and ensure the controllability and executableness of subsequent links.

[0041] For example, the system performs preliminary classification of medical documents based on a multimodal large model. Given text feature vectors... The file is determined to be a report type using the Softmax function. probability :

[0042]

[0043] in For the model to the first The original score of the report. The system selects the category with the highest probability as the report type identifier and triggers the corresponding parallel parsing task. This is set to the preset total number of categories.

[0044] To ensure that the classification results can be stably parsed by the program and directly used for subsequent automated processing, the system constrains and validates the JSON structure of the large model output. Specifically, a JSON schema corresponding to the classification output can be predefined and validated accordingly. For example, `report_type` must be a required field with a value that is one of the preset enumerations, and `report_sub_type` must be a required field and be a string type. At the same time, the output is restricted from containing non-JSON text or missing key fields. When the output fails the schema validation, the system triggers a repair strategy to improve robustness. The repair strategy may include rule repair and secondary prompts: rule repair is used to automatically truncate possible JSON fragments and fill in common format errors such as missing quotation marks or parentheses or remove redundant prefixes and suffixes. Secondary prompts are used to require the model to output only JSON that conforms to the schema and regenerate it for validation again. If the repair and secondary prompts still fail, the system reverts to the default classification to continue the process, such as classifying the report as "other" or, in a specific scenario, reverting to "medical records" to ensure that the overall processing chain is not interrupted.

[0045] If the report type is a test report, execute steps S208 and S210; if it is another type, execute step S208.

[0046] Step S208, parallel information extraction.

[0047] Information extraction comprises two sub-tasks: basic information extraction and health advice generation. Advice generation can employ differentiated prompt templates based on different report types: for medical records / prescriptions, it should focus on diagnosis, symptoms, medication, and examination recommendations; for laboratory reports, it can focus on abnormal indicators, follow-up recommendations, and dietary and lifestyle adjustments; and for physical examination reports, it should emphasize explanations of abnormal items and corresponding medical guidance. A compliance notice must also be added, clearly stating that the above advice is for reference only and cannot replace the diagnostic opinions of a professional physician.

[0048] The information extraction process will be described in detail below for reports of medical records or prescriptions.

[0049] When a report is categorized as a medical record or prescription, the system breaks down the interpretation process into multiple relatively independent subtasks that are executed in parallel. The preferred subtasks include basic information extraction, medical history information extraction, diagnosis and treatment process extraction, and suggestion generation, in order to shorten the overall processing time.

[0050] Figure 4 shows the flowchart of the parallel extraction task for medical records / prescriptions. In this embodiment, after the report intelligent classification module determines the input report as either a "medical record" or a "prescription," the system enters the medical record / prescription processing module and, as shown in Figure 4, organizes the task execution using a parallel extraction method: the system simultaneously triggers four sub-tasks—basic information extraction, medical history information extraction, diagnosis and treatment information extraction, and health suggestion generation—based on OCR structured text, which run in parallel. Each sub-task extracts or generates information from different information dimensions to shorten the overall processing latency and improve the completeness of the output results. After each sub-task is completed, the system performs field-level merging and consistency processing on the four outputs to form a unified output object. The following describes each sub-task in detail.

[0051] 1) Basic Information Extraction

[0052] In this embodiment, the basic information extraction task is used to extract the basic elements of patients and medical records from OCR text. After parsing the main text paragraphs, header information, and possible table fields, the system extracts basic fields including but not limited to name, gender, age, hospital, department, and record time. The "record time" can be further standardized into a unified date format or Unix timestamp. When some fields are missing in the input text or cannot be reliably identified, the system can return null values ​​and keep the fields in place. Optionally, the system records the source location and confidence level of the fields to improve traceability and fault tolerance.

[0053] 2) Extraction of medical history information

[0054] In this embodiment, the medical history information extraction task is used to extract key content related to medical history from medical records or prescription-related text. The system identifies common medical history paragraph structures, key prompts and semantic clues to organize medical history fields in a structured manner. The extracted fields include, but are not limited to, chief complaint, present illness, past medical history, family history, vaccination history, allergy history, etc.

[0055] 3) Extraction of medical information

[0056] In this embodiment, the diagnostic information extraction task is used to extract diagnostic conclusions, examination and treatment-related information during the medical visit. The system identifies diagnostic descriptions, treatment records, medical orders and examination results from OCR text, and outputs structured fields such as a list of diagnosed diseases, a list of symptoms, a list of drugs, and a list of examination items. At the same time, it can further extract information such as physical examinations, auxiliary examinations, and treatment plans. To facilitate subsequent understanding, the system can normalize diseases / drugs / examination items with the same or different writing styles, and retain the necessary original text evidence or frequency information in the results to improve the reliability and interpretability of the extraction results.

[0057] 4) Health advice generation

[0058] In this embodiment, the health advice generation task is used to generate concise and readable health tips and follow-up suggestions for users without altering the facts of the original medical records. The system generates suggestion text based on disease, symptom, medication, and examination information extracted from the medical records / prescriptions. The length of the suggestion text is configurable (e.g., limited to 150 characters), and the content is required to focus on the diseases / symptoms / examination results explicitly mentioned in the report, emphasizing general and robust health management points such as follow-up visits and check-ups, medication adherence, and lifestyle management. At the same time, it avoids using potentially misleading wording such as "confirmed diagnosis" or "over-inference," ensuring that the output is carefully worded, clearly defined, and suitable for users in various scenarios.

[0059] In this embodiment, after all four parallel subtasks are completed, the system merges their outputs into a unified structured output object according to the field mapping relationship: basic information, medical history information, diagnosis and treatment information and health advice are written into the corresponding fields respectively, and consistency checks and conflict resolution can be performed during the merging stage; the final output object can be provided to the outside world as the medical record / prescription interpretation result for front-end display, user download or interface with downstream systems.

[0060] The following example uses an experience report. When a report is categorized as a physical examination report, the system enters the physical examination report processing module and adopts a relatively simplified processing flow to improve processing speed and robustness while ensuring usability. Specifically, the system breaks down the physical examination report processing into two parallel tasks: Parallel Task A extracts basic information from the OCR structured text, including but not limited to name, gender, age, examination institution / hospital, and examination date, and performs necessary normalization and missing value tolerance on the time field; Parallel Task B uses a large model to extract a "list of abnormal indicator names" from the main text and table content of the physical examination report in one go and generates brief suggestions corresponding to the abnormal items. These suggestions focus on robust expressions such as follow-up reminders, medical advice, and lifestyle management, avoiding inferences beyond the scope of the report's evidence.

[0061] To further improve efficiency and adapt to diverse medical examination templates, the system does not force the parsing and range determination of every value in the medical examination report. Instead, it can selectively parse only key abnormal items or items that are clearly marked as abnormal, thereby reducing the risk of failure due to format differences, missing reference ranges, or OCR noise. After the two types of parallel tasks are completed, the system merges the basic information, the list of abnormal indicator names, and brief suggestions at the field level to form a structured output of the medical examination report for external use.

[0062] In this embodiment, the health advice generation module serves as a general-purpose component, used to output concise, user-oriented advice text based on structured extraction results. It can employ different prompt word templates depending on the report type to ensure content relevance and expression boundaries. Specifically, when the input is a medical record or prescription, the system preferably organizes prompt words around the extracted diagnostic conclusions, symptom descriptions, medication information, and examination / follow-up visit related content, guiding the model to generate advice focusing on medication adherence, follow-up visits, necessary examinations, and lifestyle management. When the input is a test report, the system preferably constructs prompt words around abnormal indicators and their status determination results, emphasizing the explanation of abnormal items, follow-up examinations, and medical reminders, and supplementing with general advice on diet and lifestyle to help users understand the meaning of abnormal indicators and subsequent action directions. When the input is a physical examination report, the system preferably generates brief explanations and medical advice around the list of abnormal item names and verifiable information in the report, avoiding conclusive judgments on unexplained or insufficiently supported evidence.

[0063] To meet compliance and safety requirements, the system uniformly adds a compliance prompt when outputting suggestions, stating that the suggestions are for health management reference only, do not constitute medical diagnosis or treatment plans, and do not replace the professional judgment of doctors. In an optional implementation, the system can also configure the length of the suggestion text, the intensity of the tone, and the level of risk warning to adapt to different product forms and usage scenarios.

[0064] When a report is classified as another type or the model is uncertain, the system can generate only a general summary, provide an unrecognizable prompt, or guide the user to upload clearer and more complete materials to avoid misleading output due to incorrect parsing.

[0065] There is no single way to implement parallel tasks. In different deployment environments, asynchronous I / O combined with thread pools or coroutines can be used to achieve lightweight concurrency. Alternatively, different subtasks can be delivered to multiple consumers for parallel consumption through message queues, or a multi-process / multi-instance horizontal scaling approach can be adopted to support higher concurrency scenarios and larger-scale task processing capabilities.

[0066] Step S210: Three-level cascaded matching and task orchestration.

[0067] Figure 5 shows the three-stage flowchart for test report processing. In this embodiment, when a report is classified as a test report, the system enters the test report processing module, and proceeds as follows: Figure 5 The diagram illustrates a three-stage architecture for structuring and interpreting test data. This architecture sequentially performs table preprocessing, indicator extraction, and parallel auxiliary processing. Table preprocessing unifies diverse tables from different hospitals and equipment into a standardized field system. Indicator extraction generates a computable array of indicators based on the standardized tables and performs field cleaning and status determination. Parallel auxiliary processing, concurrent with indicator extraction, extracts basic information and generates health recommendations, thereby improving overall processing efficiency and output completeness while ensuring the accuracy of the structured data. Figure 5 As shown, the multi-stage cascaded processing method includes the following steps:

[0068] Step S2102, Table preprocessing

[0069] Phase 1 table preprocessing aims to "unify table fields". The system obtains the original table structure from the table list output by OCR and converts it into a computable structured table.

[0070] 1) Matching of three-level cascading column names.

[0071] To achieve a reliable mapping from "original column name to standard column name", this embodiment employs a three-level cascading column name matching mechanism. This three-level cascading column name matching mechanism includes the following steps:

[0072] First, subprocess A rule matching is executed. The system presets a set of synonyms for each standard column name and performs precise matching. For example, "project name" is associated with synonyms such as "project / inspection project / check project / test project", "result value" is associated with synonyms such as "result / inspection result / measured value / project result", and "reference range" is associated with synonyms such as "reference value / reference interval / biological reference interval / reference". At the same time, corresponding synonym sets are set for fields such as "unit, English abbreviation". The original column names are traversed and mappings are established. It is required that all fields (at least including project name, result value, and reference range) must be matched to pass.

[0073] When the rule matching fails to meet the requirement of complete field integrity, the system proceeds to sub-process B, vector similarity matching. The system generates vector embeddings for the original column names in batches and retrieves the candidates that are most similar to the standard column name vectors from the vector library. If the cosine similarity reaches a threshold (c, for example, 0.8, which is configurable), a mapping is established and the completeness of the required fields is checked again.

[0074] For example, the system semantically vectorizes the original column names to be parsed against the standard column name library. Let the original column name vector be... The standard column name vector is By calculating the cosine similarity between the two To determine semantic consistency:

[0075]

[0076] in is the dimension of the feature vector. When ( When the preset threshold is 0.8, the system automatically establishes a mapping relationship between the original field and the standard field.

[0077] If vector matching still fails, the system proceeds to the sub-process C Large Language Model (LLM) inference as a fallback. The system extracts the column names, column numbers, and the first N rows of sample data (e.g., 2 rows) from the table to construct prompt words. The model is required to determine the semantics of each column based on the samples and map them to a standard column name enumeration. The output is constrained by JSONSchema. If the number of columns output by the model is inconsistent with the number of columns in the table, a padding or truncation strategy is executed to align them. This ensures high accuracy for common formats while also providing generalization capabilities for unknown formats.

[0078] 2) Merge duplicate column names and horizontally parallel blocks.

[0079] To address the common issue of horizontally parallel blocks in inspection reports (such as two or more sets of "Project Name / Result / Reference Range / Unit" columns being horizontally repeated, resulting in duplicate column names, as shown in Table 1), the system further detects the repetition patterns in the column name sequence and identifies the column block demarcation points (such as the position of the second occurrence of the "Project Name" column). Based on this, the original table is divided into multiple column blocks. After standard column name mapping and unified renaming are performed on each column block, the multiple column blocks are vertically joined together in the row direction into a single standard structure. Rows with completely empty rows and rows with required fields being empty are deleted to obtain a standardized table output that can be used for unified calculation and extraction.

[0080]

[0081] Table 1

[0082] In another embodiment, the column names and the first N rows of sample data in the table can be converted into context-enhanced column embedding vectors. These vectors simultaneously include column name semantic vectors, numerical or character distribution features of the first N rows, and adjacent contextual column embedding information. A column similarity matrix is ​​constructed based on these vectors, with matrix elements representing the comprehensive semantic and content similarity between columns. The average similarity between adjacent columns is calculated using a sliding window. Column block boundaries are determined based on the average similarity between adjacent columns and a dynamic threshold. This dynamic threshold is automatically adjusted based on the overall mean and standard deviation of the inter-column similarity to achieve adaptive partitioning for different report sources, different table templates, and multiple sets of duplicate column blocks. Anomaly detection is performed on the partitioned column blocks. When the number of columns in a block is inconsistent with the preset standard number of columns or the column name matching degree is lower than the threshold, a closed-loop correction process is automatically triggered. This closed-loop correction process includes: a) performing vector similarity matching between the column names within the block and the standard column name library to align the column names; b) if vector matching still fails to meet the integrity requirements, a large language model is invoked to infer column semantics based on the column name, column number, and the first N rows of sample data, and then based on JSON... The schema constraints output aligned column names. Finally, all column blocks were vertically concatenated in the row direction after correction, and rows with completely empty rows and rows where required fields were empty were deleted.

[0083] 3) Standardized output of tables

[0084] Ultimately, the standardized table should include at least the following fields: item (project name), item_en (abbreviation), value (result value), ref (reference range), and unit (unit), providing consistent input for the next stage of indicator extraction.

[0085] Step S2104: Indicator extraction and field cleaning.

[0086] As shown in Table 2, there are numerous format variations and noise in the fields of medical test reports. Phase 2 extracts the array of test indicators row by row based on the standardized table, and performs field cleaning and standardization to address the common format variations and noise in medical test reports, thereby improving the reliability of subsequent comparison judgments and suggestion generation.

[0087] Specifically, the system performs cleaning on the project name to eliminate serial number prefixes, meaningless symbols, and additional information in parentheses, and unifies the parentheses style; performs cleaning on English abbreviations to remove attached Chinese characters, leading numbers or remaining serial numbers, and preferably converts them to uppercase for standardized retrieval; performs parsing and type annotation on the result value field, which can identify and split comparison symbols (such as >, <, ≥, ≤), extract numerical values and convert them to floating-point numbers when they are parsable, and at the same time retain the string form for qualitative results such as "negative / positive / normal" and mark the type as string to avoid information loss caused by forced numericalization; performs normalization on the reference range field to unify the form of the connection symbol (such as normalizing ~, —, to, etc. to "-"), and extracts the lower / upper limits to form a computable range when it is parsable; performs cleaning on the unit field to remove null value markers, control characters, and extra spaces, so as to unify each indicator field into a comparable, computable, and traceable standard representation.

[0088]

[0089] Table 2

[0090] After the system completes the cleaning of the indicator fields, it determines the indicator status. Preferably, it only performs range comparison on numerical results to obtain interpretable statuses such as "normal / low / high". Specifically, when the result value is numerical and the reference range can be parsed into lower / upper limits, if lower ≤ value ≤ upper, the indicator status is determined as "normal"; if value < lower, it is determined as "low"; if value > upper, it is determined as "high"; when the reference range cannot be parsed (such as missing, abnormally expressed, or only giving a unilateral threshold) or the result value is a string-type qualitative result, the system can set the status to null or mark it as "undetermined" to avoid giving unreliable range judgments when the information is insufficient.

[0091] For example, for the cleaned numerical test results , the system extracts the corresponding lower limit of the reference range and the upper limit , and automatically determines the indicator status and outputs an identifier through the following function :

[0092] This mechanism supports real-time interpretation and abnormal warning of structured data at the medical semantic level.

[0093] Step S2106, parallel auxiliary processing.

[0094] In this embodiment, to improve the completeness and real-time performance of the overall test report output, the system performs auxiliary processing tasks in parallel while performing indicator extraction and status determination. These tasks preferably include two categories: basic information extraction and health suggestion generation. Basic information extraction extracts key information such as name, gender, age, hospital, and report time from the OCR text and performs necessary time standardization and error correction. Health suggestion generation generates explanations and suggestions based on structured abnormal indicators, key test items, and verifiable facts in the report. The suggestions focus on robust expressions such as abnormal item alerts, reminders for follow-up examinations and medical visits, and lifestyle and compliance recommendations, avoiding overdiagnosis or inferences beyond the scope of the report's evidence. Finally, the system integrates and outputs the indicator array, status determination results, basic information, and suggestion text to form a structured interpretation of the test report for the user.

[0095] Step S212: Output the data model.

[0096] In this embodiment, after completing OCR recognition, report classification, traffic routing, and information extraction / suggestion generation of the input report, the system organizes the processing results into a structured output object. The structured output object preferably uses a key-value pair data structure (e.g., JSON or equivalent representation) and employs a combination of "general fields + type-extended fields": general fields describe the basic information and general suggestions required for different report types; type-extended fields carry the differentiated structured content for different report types. Through this unified output data model, the system can output results with a consistent data interface even with diverse input formats and different report types, improving the system's scalability and reusability.

[0097] In this embodiment, the structured output object includes at least the following general fields: a primary report category `report_type` and a secondary report category `report_sub_type`, where the value of `report_type` is limited to one of a preset enumeration set, which includes at least "medical records, prescriptions, laboratory reports, physical examination reports, and others". Additionally, the output object may include basic information fields, including but not limited to name, gender, age, hospital / institution, department, and record_time, where the record time can be standardized into a uniform date format or timestamp format for cross-report alignment and retrieval. Furthermore, the output object includes suggestion text, used to output user-oriented health tips or follow-up recommendations.

[0098] To enhance traceability, in one optional implementation, the output object may also include the OCR raw text (raw_text) and the table raw text or structured table representation (raw_table), used for reviewing the extraction results or for anomaly replay. When the optional field is not enabled or data is missing, the system may not output the field or output an empty value to balance data volume control and traceability requirements. To ensure that the output can be parsed stably, the system preferably requires report_type, report_sub_type, and suggestion to be mandatory fields. When basic information fields cannot be reliably obtained from the input, the system may output an empty value or a default value, and optionally annotate the field source or confidence information, but the present invention is not limited thereto.

[0099] In this embodiment, when a report is determined to be a medical record or prescription, the system further outputs a medical record / prescription extended field, `content`, on top of the general fields. This extended field carries structured information related to medical history and treatment. The `content` may include, but is not limited to: a list of diagnosed diseases (disease), a list of symptoms (symptom), a list of medications (drug), a list of examinations (examine), and fields such as `main_statement`, `cur_disease_history`, and `past_disease_history`. Each list field can be stored as an array, and text fields can be stored as strings. The system can merge the results obtained from parallel extraction tasks into the `content` according to field mapping relationships, maintaining a top-level structure consistent with the general fields so that the caller can parse it in a unified way. When some fields are missing or cannot be confirmed, the system can retain placeholder fields and output null values ​​or empty arrays to avoid parsing failures due to structural inconsistencies. An exemplary output format is given below (for illustrative purposes only and does not constitute a limitation on the field range):

[0100] {

[0101] "report_type": "medical records",

[0102] "report_sub_type": "Outpatient Medical Records",

[0103] "name": "Zhang San",

[0104] "gender": "male",

[0105] "age": 35,

[0106] "hospital": "[Hospital Name]",

[0107] "department": "Respiratory Medicine"

[0108] "record_time": 1735603200,

[0109] "content": {

[0110] "disease": ["upper respiratory tract infection"],

[0111] "symptom": ["cough", "sore throat"],

[0112] "drug": ["acetaminophen"],

[0113] "examine": ["complete blood count"],

[0114] "main_statement": "Cough and sore throat for 2 days",

[0115] "cur_disease_history": "…",

[0116] "past_disease_history": "…"

[0117] },

[0118] "suggestion": "..."

[0119] }

[0120] In this embodiment, when a report is determined to be an inspection report, the system outputs a set of inspection indicators based on general fields. This set of indicators can be represented as an array, where each indicator record is an indicator object. Specifically, the indicator object may include, but is not limited to: the standardized item name (item), the original item representation (item_raw) or its English abbreviation (item_en), the result value (value), the result type (type), the unit (unit), the reference range (ref), and the upper and lower limits of the reference range (lower / upper), and may include a status field (status) to represent "normal / high / low / not determined," etc. The following provides an exemplary indicator object structure (for illustrative purposes only and does not constitute a limitation on the range of fields):

[0121] {

[0122] "item": "White blood cell count",

[0123] "item_raw": "WBC",

[0124] "item_en": "WBC",

[0125] "value": 12.3,

[0126] "type": "float",

[0127] "unit": "10^9 / L",

[0128] "ref": "3.5-9.5",

[0129] "lower": 3.5,

[0130] "upper": 9.5,

[0131] "status": "Slightly high"

[0132] }

[0133] Optionally, based on this embodiment, the present invention also provides a variety of scalable implementation methods to adapt to more types of medical document formats and more complex usage scenarios, and the extensions do not change the overall technical framework of the present invention: "input access—OCR structuring—intelligent classification—streaming scheduling—type-based extraction / interpretation—unified output". For example:

[0134] (1) Regarding the expansion of report categories, the system can add new secondary categories to cover more medical report types, such as imaging reports and ultrasound reports, while keeping the existing primary categories unchanged or expanding them as needed. Correspondingly, dedicated parsing strategies, field extraction templates and suggested generation templates can be configured for the newly added secondary categories, thereby realizing the structured interpretation output of the new reports.

[0135] (2) In terms of language capability expansion, the system can introduce multilingual OCR capability and multilingual classification capability, so that the input file can contain other languages ​​besides Chinese. In this implementation, the system can automatically select the corresponding OCR model, classification prompt word template and field normalization rule according to the text language detection results, so as to ensure that the data model structure can still be output in different language scenarios.

[0136] (3) In terms of longitudinal analysis of test reports, the system can further support the merging of multiple reports and trend analysis based on the parsing of a single test report: for example, aligning multiple test results of the same user by time axis, normalizing and merging indicators with the same name or synonym, and outputting trend change information and re-examination reminders based on the merged sequence, thereby providing users with cross-time dimension health observation and management assistance.

[0137] The intelligent interpretation system described in this invention can be presented through mobile applications / mini-programs / web applications. After completing report uploading, OCR recognition, report classification, and segmented parsing, the application displays the interpretation results in a "partitioned card" format to balance readability, traceability, and user operation efficiency. Figures 6 to 8 As shown, the "Routine Blood Test Report" is used as an example to illustrate the presentation logic and user interaction flow of the application page; the example is only used to illustrate the application layer implementation of the present invention and does not constitute a limitation on the interface layout, interaction details or visual style.

[0138] Compared with existing technologies, this invention has the following advantages: 1) Stable cross-format input processing: Stable support for image and PDF input through file type detection and differentiated OCR / parsing interfaces; 2) Semantic-level report classification: Improved classification accuracy for complex documents based on semantic understanding of a large language model; Strong generalization alignment of tables; 3) Adoption of a three-level cascaded column name matching mechanism of "rule matching → vector similarity → LLM inference" to adapt to column name differences between different hospitals / equipment; 4) Significantly improved efficiency: Parallelization of multiple extractions and suggestion generation through asynchronous parallel task scheduling, improving throughput and reducing single response latency; 5) Stable and parsable output: Significantly reduced parsing failures caused by format drift through structured output constraints such as JSON Schema; 6) Good scalability: Modular design facilitates the expansion of new report types and field systems, supporting continuous evolution.

[0139] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A multi-stage cascade processing method for medical test reports, characterized in that, include: Obtain the inspection report and perform cascaded preprocessing on the original tabular data in the inspection report to generate standardized tabular data; Structured indicators are extracted based on the standardized tabular data to obtain structured indicator data, and indicator status information is determined based on the result values ​​and reference ranges in the structured indicator data. Basic information data and health advice text are generated based on the structured indicator data, wherein the health advice text is generated based on the indicator status information.

2. The method according to claim 1, characterized in that, The original tabular data in the inspection report undergoes cascade preprocessing, including: Based on a preset set of standard column names, the original column name sequence in the original table data is matched according to rules to establish an initial mapping relationship and obtain the first intermediate structured table data; Based on the unmatched column name fields in the first intermediate structured table data, semantic vector matching is performed to establish a supplementary mapping relationship and obtain the second intermediate structured table data. Semantic inference is performed based on the second intermediate structured table data, an inference mapping relationship is established, and standardized table data is obtained based on the inference mapping relationship.

3. The method according to claim 2, characterized in that, Based on a preset set of standard column names, the original column name sequences in the original table data are matched according to rules to establish an initial mapping relationship, resulting in the first intermediate structured table data, including: Based on a preset set of standard column names and its synonym mapping dictionary, string matching is performed on each original column name in the original column name sequence in the original table data to establish an initial mapping relationship between the original column names and the standard column names; Based on the initial mapping relationship, the original table data is aligned with fields to generate the first intermediate structured table data, wherein the first intermediate structured table data includes matched standard column name fields and unmatched column name fields.

4. The method according to claim 3, characterized in that, Based on the unmatched column name fields in the first intermediate structured table data, semantic vector matching is performed to establish supplementary mapping relationships, resulting in the second intermediate structured table data, including: Based on the unmatched column name fields in the first intermediate structured table data, generate corresponding column name semantic vector representations; The semantic vector representation of the column name is matched with a preset standard column name vector library to determine the candidate standard column name corresponding to each unmatched column name field, and a supplementary mapping relationship is established. Based on the supplementary mapping relationship, the first intermediate structured table data is updated to generate the second intermediate structured table data, wherein the second intermediate structured table data includes standard column name fields after rule matching and vector matching, as well as fields that are still not matched.

5. The method according to claim 4, characterized in that, Semantic inference is performed based on the second intermediate structured table data, an inference mapping relationship is established, and standardized table data is obtained based on the inference mapping relationship, including: Based on the second intermediate structured table data and the still unmatched fields, extract the column name information and sample column data from the original table data to construct column semantic inference input data; The column semantic inference input data is input into the semantic inference model, semantic determination is performed on each column, and the column semantic determination result is output. The column semantic determination result includes the inference mapping relationship between the remaining unmatched column names and the standard column names. Based on the inferred mapping relationship, the second intermediate structured table data is finally aligned with its fields to generate the standardized table data.

6. The method according to claim 1, characterized in that, Structured indicators are extracted based on the standardized tabular data to obtain structured indicator data, including: Based on the standardized table data, each row of data is parsed to extract the project name field, result value field, reference range field, and unit field, and generate initial indicator data. The result value fields in the initial indicator data are subjected to numerical type identification and format cleaning to obtain standardized result value data; The reference range field in the initial indicator data is parsed to extract the upper and lower limit values, thus obtaining the normalized reference range data. Based on the comparison between the normalized result value data and the normalized reference range data, the status information of each indicator is determined; The structured index data is generated by combining the project name field, the normalized result value data, the normalized reference range data, and the status information.

7. The method according to claim 4, characterized in that, Based on the structured indicator data, generate basic information data and health advice text: Based on the text content of the test report, basic information fields corresponding to the structured indicator data are extracted to generate basic information data, wherein the basic information fields include at least one of the following: name, gender, age and report time; The structured indicator data is integrated with the basic information data to construct suggestion generation input data, and health suggestion text is generated based on the suggestion generation input data.

8. A multi-stage cascaded processing system for medical test reports, characterized in that, include: The first-stage processing module is configured to acquire the inspection report and perform cascaded preprocessing on the original tabular data in the inspection report to generate standardized tabular data. The second-stage processing module is configured to extract structured indicators based on the standardized tabular data, obtain structured indicator data, and determine indicator status information based on the result values ​​and reference ranges in the structured indicator data. The third-stage processing module is configured to generate basic information data and health advice text based on the structured indicator data, wherein the health advice text is generated based on the indicator status information.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein, when the program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images