A system and method for electronic medical record information extraction

Abstract

The application provides an electronic medical record information extraction system and method, belonging to the technical field of medical information extraction. It aims to solve the problems of inaccuracy, non-standardization and logical inconsistency when extracting information from free-text medical records. The scheme includes: generating prompt words containing structured field definitions and rules; inputting the prompt words into a large language model with medical text to obtain preliminary results; calling a medical knowledge base to correct the terms in the results; performing logical verification on the corrected results, including time sequence and cross-field consistency verification, to generate the final structured medical record information. The application significantly improves the accuracy, standardization and logical consistency of medical record information by guided extraction and multi-level verification, and introduces a feedback correction mechanism to form a closed loop, providing a high-quality data foundation for clinical applications.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of artificial intelligence, and in particular to a system and method for extracting electronic medical record information. BACKGROUND

[0002] With the development of medical informatization, electronic medical records have become the core data source for clinical diagnosis and treatment and scientific research analysis. However, a large amount of current electronic medical record content, such as transcribed records of doctor-patient conversations and doctor-entered medical history records, exists in the form of unstructured free text. The expression of these texts is diverse, and the information is scattered, making it difficult to be directly structured and utilized by computer systems.

[0003] In order to extract valuable medical information from unstructured text, existing technologies have made various explorations. Early technologies mainly used rule-based and medical dictionary-based methods to extract information through pre-set regular expressions and keyword matching. Although this method is simple to implement, its accuracy and recall rate are not ideal when faced with complex sentence patterns and varied colloquial expressions, and the construction and maintenance of the rule base is extremely costly. Subsequently, traditional machine learning and deep learning-based methods were introduced, such as conditional random field models, recurrent neural networks, or transformer models. These methods learn to identify entities and relationships from text by training on a large amount of labeled data, and their performance is superior to rule-based methods to some extent, but their effectiveness is heavily dependent on the size of high-quality labeled data, and the models themselves lack deep medical knowledge and logical reasoning capabilities, making it difficult to process long texts with complex temporal relationships and effectively filter out noise information such as idle chatter and mistakes in doctor-patient conversations.

[0004] In recent years, large language models have shown great potential in information extraction due to their strong natural language understanding and generation capabilities. Some studies have begun to explore the use of prompt engineering to guide large language models to directly extract structured information from medical records. For example, by constructing instruction templates, the model is required to extract specific fields in the medical record, and combined with a medical knowledge base, the extracted medical terms are standardized and corrected. However, this method still has obvious defects: first, simple prompts cannot accurately constrain the output of the model, resulting in unstable result formats and information hallucinations or omissions; second, the model itself cannot guarantee the absolute consistency of the extracted information in terms of temporal sequence and medical logic, for example, it may confuse a symptom that occurred three days ago with a symptom that occurred one day ago in the timeline, or incorrectly categorize chronic disease information that should belong to "past medical history" into the "chief complaint" of the current visit; finally, existing solutions are linear extraction processes that lack effective verification and correction mechanisms for the extracted results, resulting in insufficient reliability of the output information and making it difficult to meet the stringent requirements of clinical applications. SUMMARY

[0005] The purpose of the present application is to provide an electronic medical record information extraction system and method, aiming to solve the problems of inaccurate, non-standard, inconsistent logic and lack of effective correction mechanism in the prior art when processing free text medical records, so as to improve the clinical usability of the finally generated electronic medical record.

[0006] To achieve the above purpose, the present application provides an electronic medical record information extraction system, comprising:

[0007] A data acquisition module is configured to acquire multi-module medical text data, wherein the multi-module medical text data comprises doctor-patient conversation voice transcription text, free text medical record, and OCR-recognized imaging and test report.

[0008] A prompt word generation module is configured to generate prompt words containing a hierarchical structure for a preset medical information extraction task.

[0009] A model inference module is configured to combine the prompt words containing the hierarchical structure with the preprocessed multi-module medical text data, and input them into a preset large language model to obtain a preliminary extraction result containing candidate medical information.

[0010] A term correction module is configured to call a preset medical knowledge base to compare and standardize the medical terms in the preliminary extraction result.

[0011] A logic verification module is configured to perform logic verification on the extraction result corrected by the term correction module, wherein the logic verification comprises at least one of time sequence relationship verification and cross-field information consistency verification to generate final structured medical record information.

[0012] Further, the prompt words containing the hierarchical structure comprise:

[0013] a system layer for defining global output format and constraints, a task layer for setting extraction priority and strategy, a field layer for constructing templates and constraints for specific medical fields, and a verification layer for guiding the large language model to perform self-checking.

[0014] Further, the logic verification performed by the logic verification module comprises at least one of the following operations:

[0015] Performing time sequence relationship verification to sort the sequence of symptom occurrence according to the time expression in the original text, and converting the relative time expression into a standardized absolute time stamp;

[0016] Performing cross-field information consistency verification to eliminate redundancy of repeated or semantically similar symptoms.

[0017] Further, the logic verification module is further configured to: when the logic verification finds errors or inconsistencies, generate a correction prompt word, and control the model reasoning module to input the correction prompt word, the original text and the context information into the large language model again, instructing the large language model to make targeted corrections to form a closed-loop correction process.

[0018] Further, the system further comprises:

[0019] A text preprocessing module is arranged between the data collection module and the model reasoning module, configured to preprocess the medical text data to remove casual conversation, noise and non-medical related content.

[0020] Further, the system further comprises: a structured output module configured to convert the final structured medical record information into a preset data format and interface to a hospital information system or an electronic medical record system; and the preset data format includes JSON, XML, FHIR or HL7.

[0021] To achieve the above-mentioned purposes, the present application also provides a method for extracting electronic medical record information, which is applied to the system for extracting electronic medical record information.

[0022] Collecting multi-module medical text data, wherein the multi-module medical text data includes doctor-patient conversation voice transcription text, free text medical record, and OCR-recognized imaging and test report.

[0023] Generating prompt words containing hierarchical structure for a preset medical information extraction task.

[0024] Combining the prompt words containing hierarchical structure with the preprocessed multi-module medical text data, and inputting the combination into a preset large language model to obtain a preliminary extraction result containing candidate medical information.

[0025] Calling a preset medical knowledge base to compare and standardize the medical terms in the preliminary extraction result.

[0026] Performing logic verification on the extraction result corrected by the term correction module, wherein the logic verification includes at least one of time sequence relationship verification and cross-field information consistency verification to generate final structured medical record information.

[0027] Further, after generating the prompt words containing hierarchical structure for the preset medical information extraction task, before inputting the combination of the prompt words containing hierarchical structure and the preprocessed multi-module medical text data into the preset large language model to obtain the preliminary extraction result containing candidate medical information, the method further comprises:

[0028] The medical text data is preprocessed to remove non-medical related content.

[0029] Compared with the prior art, the present application has the following beneficial effects:

[0030] 1. Improve the accuracy and standardization of information extraction: By using prompt words containing a hierarchical structure (system layer, task layer, field layer, and verification layer), the output behavior of large language models can be accurately constrained, effectively reducing the problems of model hallucinations, errors, or unstable formats. Combined with the term correction module, medical terms are standardized to ensure that the extraction results meet the clinical term specifications, thereby significantly improving the accuracy and structuredness of the information.

[0031] 2. Enhance logical consistency and clinical reasonableness: Through the logical verification module, the time sequence relationship (such as the sequence of symptom occurrence, relative time standardization) and cross-field information consistency (such as redundant symptom resolution) are verified, which can effectively avoid logical contradictions such as timeline confusion and field classification errors, ensuring that the generated electronic medical record has consistency and traceability in medical logic, meeting the stringent requirements of clinical decision-making.

[0032] 3. Compatible with multi-source data and efficient denoising: The system can integrate medical-patient conversation transcription text, free text medical records, OCR reports, and other multi-module medical data, and remove non-medical noise such as small talk and errors through the text preprocessing module, thereby focusing on key medical information and improving data utilization efficiency and extraction efficiency.

[0033] 4. Improve clinical usability and system integration: The structured medical record information generated can be converted into standard data formats such as JSON and FHIR, seamlessly integrating with hospital information systems or electronic medical record systems, directly supporting clinical diagnosis and treatment, scientific research analysis, and other applications, solving the pain point of non-structured text being difficult to directly utilize, and enhancing the practicality and promotional value of the system.

[0034] In summary, through the synergistic effect of multi-level prompt word design, term standardization, logical verification, and closed-loop correction, the present application fundamentally solves the problems of inaccurate, non-standard, and inconsistent logic in the prior art, and provides a high-reliability and high-availability solution for the automatic generation of electronic medical records.

[0035] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. BRIEF DESCRIPTION OF DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description only represent some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0037] Figure 1 is a system composition schematic diagram of electronic medical record information extraction according to an exemplary embodiment;

[0038] Figure 2 is a method flow schematic diagram of electronic medical record information extraction according to an exemplary embodiment. DETAILED DESCRIPTION

[0039] In order to make the purposes, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described in detail below. Obviously, the described embodiments are only some of the embodiments of the present application, not all. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0040] In the specific implementation, please refer to Figure 1 , Figure 1 is a system composition schematic diagram of electronic medical record information extraction according to an exemplary embodiment, the system comprises:

[0041] The data acquisition module 10 is used to acquire multi-module medical text data; the multi-module medical text data comprises: doctor-patient conversation voice transcription text, free text medical record, and OCR-recognized imaging and laboratory reports.

[0042] The prompt word generation module 20 is used to generate prompt words containing hierarchical structure for a preset medical information extraction task.

[0043] The model inference module 30 is used to combine the prompt words containing hierarchical structure and the preprocessed multi-module medical text data, and input them into a preset large language model to obtain a preliminary extraction result containing candidate medical information.

[0044] The term correction module 40 is used to call a preset medical knowledge base to compare and standardize the medical terms in the preliminary extraction result.

[0045] The logic verification module 50 is configured to perform logic verification on the extraction result after correction by the term correction module, wherein the logic verification comprises at least one of time sequence relationship verification and cross-field information consistency verification, so as to generate final structured medical record information.

[0046] In a specific implementation, the present application combines guided extraction with multi-level verification, especially introduces a feedback correction mechanism after logic verification failure, forms a closed-loop process of "extraction-verification-correction", can effectively overcome the randomness and illusion of large language model output, significantly improves the accuracy and coherence of the extracted medical record information in time sequence and medical logic. Secondly, by combining the medical knowledge base for term correction, the colloquial and non-standard medical expressions can be converted into unified medical terms, improving the quality and usability of structured data. In addition, the present application can automatically filter noise information, process complex context and time relationship, and can self-correct logical errors, with high automation, effectively reducing the workload of doctors, and improving the efficiency of medical record recording. Finally, the present application can output structured data conforming to industry standards, enhancing the traceability, reusability and cross-system sharing ability of medical record data, providing a high-quality data basis for clinical auxiliary decision-making, medical research and other downstream applications.

[0047] Embodiment 1

[0048] Figure 2 is a method flow diagram of electronic medical record information extraction according to an exemplary embodiment. The purpose of this flow is to convert an unstructured medical text (for example, a voice transcription record of a doctor-patient conversation) into a structured, standardized and logically consistent electronic medical record data. The functions of each module and the execution steps of the method will be described in detail below in conjunction with a specific application scenario.

[0049] Suppose the system receives a doctor-patient conversation text converted by voice recognition technology: "Doctor, I have been coughing for the past two days, and I have a fever. Last night, the highest temperature was 38.9℃, and I felt a little short of breath."

[0050] Firstly, in the medical data acquisition step S1, the data acquisition module 10 is responsible for receiving the text. It can be understood that the data acquisition module 10 can be configured with multiple interfaces, for example, an interface for receiving real-time voice stream and calling external voice recognition services to convert into text, or an interface for receiving text messages pushed by a hospital information system, or an interface for receiving user-uploaded medical record photos. In this scenario, the data acquisition module 10 receives the above medical text in the form of a string.

[0051] Subsequently, the collected text is sent to the text preprocessing module to perform the text preprocessing step. The main function of this module is to purify the input text and remove noise irrelevant to the medical information extraction task. For the input text "Doctor, I have been coughing for two days and have a fever. Last night, the temperature was 38.9°C, and I feel a little short of breath.", the text preprocessing module will perform a series of operations, including but not limited to: 1. Identifying and removing honorifics such as "Doctor"; 2. Based on the pre-set common error mapping table, correcting the errors or homophones that may be introduced by speech recognition; 3. Carrying out sentence segmentation and punctuation completion to ensure the integrity of the text syntax structure. After processing, the output of the pure text is: "I have been coughing for two days and have a fever. Last night, the temperature was 38.9°C, and I feel a little short of breath." It should be noted that this step helps to reduce the complexity of subsequent large language model processing, thereby improving the accuracy of extraction.

[0052] After preprocessing, the process enters the prompt word generation step S20, which is performed by the prompt word engineering and hierarchical extraction module 20. This step is a key link to guide the large language model to perform accurate extraction. The module generates a prompt word containing structured field definitions and extraction rules for the pre-set medical information extraction task (e.g., generating an outpatient initial diagnosis medical record). This prompt word is not a simple instruction, but a structured text template. For example, module 20 will generate the following prompt word:

[0053] {"task": "Extract structured medical record information from the provided patient self-report text.", "output_schema": {"chief complaint": "string / / The patient's main complaint for this visit, concise and to the point", "present illness history": {"time of onset": "string / / Relative or absolute time of the first appearance of symptoms", "symptom list": [{"symptom name": "string", "symptom description": "string / / Details including the nature, degree, frequency, duration of the symptom", "relevant time": "string / / Time of the specific symptom's appearance or exacerbation"}]}, "vital signs": {"temperature": {"value": "float", "unit": "string / / Celsius", "measurement time": "string"}}, "past medical history": "string / / Patient's past disease history, return 'none' if none", "allergy history": "string / / Patient's drug or food allergy history, return 'none' if none"}, "extraction_rules": ["Strictly follow the JSON format of 'output_schema' to return the result.", "All time-related fields, please parse and output as much as possible.", "For the 'temperature' field, if the temperature value mentioned in the text is higher than 37.1 degrees Celsius, it should be judged as 'fever' and reflected in the'symptom list'.", "If a field is not mentioned in the text, return null."]}

[0054] The above prompt words clearly define the required extraction fields (such as chief complaint, present illness history, etc.), data types and hierarchical structure, and additional specific extraction rules.

[0055] Correspondingly, the process advances to the large language model reasoning step S3. The model reasoning module 30 combines the prompt words generated in the previous step with the pre-processed medical text into a complete input, and calls a pre-configured large language model service. The large language model can be a general transformer-based large model, or a special model fine-tuned on medical data. The input to the model can be shown as follows:

[0056] [system instruction]: please process the user-provided text according to the following task definition, output format and rules. [task definition, output format and rules]: {... the above JSON format of prompt words...} [user-provided text]: "I have been coughing for the past two days, and I have a fever. Last night, I measured it, and the highest temperature was 38.9℃. I feel a little short of breath."

[0057] After understanding these instructions and context, the large language model performs inference and generates a preliminary extraction result containing candidate medical information. This result follows the format requirements of the prompt words, but its content may contain irregularities or logical inconsistencies. For example, the model might output:

[0058] { "Chief Complaint": "Cough, Fever", "Present Illness": { "Onset Time": "These past two days", "Symptom List": [ { "Symptom Name": "Cough", "Symptom Description": "Constant cough", "Related Time": "These past two days"}, { "Symptom Name": "Fever", "Symptom Description": "Highest temperature 38.9℃", "Related Time": "Last night"}, { "Symptom Name": "Shortness of breath", "Symptom Description": "Feeling a little short of breath", "Related Time": null} ]}, "Vital Signs": { "Temperature": { "Value": 38.9, "Unit": "℃", "Measurement Time": "Last night"}}, "Past Medical History": null, "Allergy History": null}

[0059] Next, the process enters the medical knowledge base correction step S4, where the medical knowledge base correction module 40 processes the preliminary extraction results. The main task of this module is terminology standardization. Internally, the module connects to one or more pre-defined medical knowledge bases, such as a database containing a large number of colloquial expressions and their correspondences with standard medical terms. This database can be stored in key-value pairs, such as {"shortness of breath": "difficulty breathing", "lack of energy": "fatigue", "diarrhea": "diarrhea"}. The medical knowledge base correction module 40 iterates through the "symptom name" and "symptom description" fields in the preliminary extraction results, replacing the identified colloquial expression "shortness of breath" with the standard medical term "difficulty breathing". The corrected result then becomes:

[0060] { ... "Symptom List": [ ..., { "Symptom Name": "Difficulty Breathing", "Symptom Description": "Feeling a little short of breath", "Related Time": null} ], ...}

[0061] This step greatly improves the standardization and professionalism of the final generated medical records, laying the foundation for subsequent data analysis and system integration.

[0062] Next, the logical consistency and chronological order verification module 50 performs the logical consistency verification step S5, which is a core step in ensuring the accuracy and reliability of medical record information. This module performs at least two verifications on the results after terminology correction: chronological order relationship verification and cross-field information consistency verification.

[0063] For temporal relationship verification, module 50 parses all time-related fields, such as “two days ago” in “onset time” and “last night” in “associated time”. It converts these relative time expressions into standardized absolute timestamps based on the current date (assuming the operation is performed on August 17, 2025). For example, “two days ago” is parsed as the start of the onset date range, i.e., “2025-08-15”; “last night” is parsed as “2025-08-16”. Module 50 also verifies whether the logical order of event occurrences is reasonable based on these timestamps, e.g., the fever time (2025-08-16) is later than or equal to the first onset time (2025-08-15), which is a valid logical relationship.

[0064] For cross-field information consistency verification, module 50 checks whether there are contradictions or redundancies between different fields. In this example, it verifies whether the rule in the prompt is correctly executed: it checks that the temperature in “vital signs” is 38.9°C, which is higher than 37.1°C, and that there is indeed a “fever” symptom in the “symptom list” in “present illness history”, confirming that the information is consistent. In addition, it checks whether there is a simple repetition between “chief complaint” and the symptoms in “present illness history”, and may integrate them. In this example, the verification module confirms that the logic is basically consistent.

[0065] In this embodiment, since all verifications pass, the process smoothly enters the final step of storing structured medical record information. The structured output and storage module is responsible for converting the verified and logically rigorous medical record information into the pre-set final data format. This format can be a common JSON or XML, or a format that meets the medical industry standard, such as Fast Healthcare Interoperability Resources or Health Level Seven Standard. For example, the final generated resource may contain a Condition resource (for recording cough, fever, and difficulty breathing) and an Observation resource (for recording a temperature of 38.9°C), and be associated by reference to the same Encounter resource. Finally, this structured data is pushed to the hospital information system or electronic medical record system for storage and utilization.

[0066] Through the above steps, the system and method of this embodiment successfully convert a piece of colloquial, unstructured conversation into high-quality structured medical record data containing accurate timelines, standardized terminology, and logically consistent information.

[0067] Embodiment 2

[0068] This embodiment, based on Embodiment 1, focuses on demonstrating how the system achieves closed-loop correction through a feedback correction mechanism when errors are detected during logical verification. A judgment step is added after the logical consistency verification step. If the verification fails, the step of generating error correction prompts is triggered, and the system re-enters the large language model inference step.

[0069] Let's take a different medical text scenario as an example. The data acquisition module 10 receives a text message: "I've been dizzy for three days and have a history of high blood pressure."

[0070] After text preprocessing, the text is fed into subsequent steps. In the initial large language model inference step, because the large language model may not perfectly distinguish between acute and chronic issues in the medical record, it may produce a logically flawed preliminary extraction result. For example, the model might consider "hypertension" as both a problem in the current visit and a past medical history, resulting in the following output:

[0071] { "Chief Complaint": "Dizziness, hypertension", "Present Illness": { "Onset Time": "Three days ago", "Symptom List": [ { "Symptom Name": "Dizziness", "Symptom Description": "Dizziness for three days", "Related Time": "Three days ago"} ]}, "Past Medical History": "History of Hypertension", ...}

[0072] After the medical knowledge base correction step (in this case, there are no obvious terms that need to be corrected), the result is sent to the logical consistency and time sequence verification module for verification (step S5). This module has a series of deeper medical logic rules built in, one of the key rules being: "The chief complaint field should record the acute or major problem that caused this visit, while long-term chronic diseases should be recorded in the past medical history field and should not appear in the chief complaint."

[0073] When performing cross-field information consistency checks, the verification module 50 detected that the term "hypertension" appeared in both the "chief complaint" and "past medical history" fields. According to the built-in rule base, "hypertension" is a chronic disease, and its appearance in the "chief complaint" field constitutes a logical conflict.

[0074] At this point, in the judgment step, the verification result is determined to be "No" (i.e., verification failed), thus triggering the feedback correction process. The process then proceeds to the step of generating error correction prompts. The logical consistency and time sequence verification module generates a targeted error correction prompt based on the specific error type detected. This error correction prompt is no longer a general extraction instruction, but a specific correction instruction. For example, the system will generate the following error correction information, which will then be packaged into a new prompt by the prompt generation module:

[0075] {"context": {"original_text": "I have been dizzy for three days, and I have a history of high blood pressure.", "previous_attempt": {"output": {"chief_complaint": "dizziness, high blood pressure", "past_medical_history": "history of high blood pressure",...}, "error_found": "Logical inconsistency: the chronic condition 'high blood pressure' is incorrectly included in the 'chief_complaint' field."}, "correction_instruction": "Please correct the errors in the 'previous_attempt' above. According to medical documentation standards, the 'chief_complaint' field should not contain a history of chronic conditions. Please remove 'high blood pressure' from the 'chief_complaint' field and generate a new complete JSON output containing only the correct information."}

[0076] The information extraction system now initiates a second request to the large language model service, a correction request. The model inference module 30 sends this new prompt containing the context and explicit correction instruction to the large language model.

[0077] Upon receiving this correction request, the large language model focuses on the pointed-out error. Due to the specific instruction, the model easily understands and performs the correction. It re-examines the original text and the previous output and generates a corrected result. This process can be seen as a kind of "self-reflection and correction" of the model. The corrected output is:

[0078] { "chief_complaint": "dizziness", "present_illness_history": { "time_of_onset": "three days ago", "symptom_list": [ { "symptom_name": "dizziness", "symptom_description": "dizziness for three days", "related_time": "three days ago"} ]}, "past_medical_history": "history of high blood pressure",...}

[0079] This corrected result is again sent to the medical knowledge base correction module 40 and the logic verification module 50. This time, when the logic verification module 50 performs the verification again, it finds that "high blood pressure" only appears in the "past_medical_history" field, and the "chief_complaint" field content is correct, the logical inconsistency has been eliminated. Therefore, in the judgment step, the verification result is "yes", and the process continues.

[0080] Finally, the structured output and storage module formats and stores or pushes this closed-loop corrected and logically rigorous medical record information to the downstream system.

[0081] Through this "extraction-verification-feedback-correction" closed-loop mechanism, the system of the present application can actively discover and correct logical errors that the large language model may make during initial reasoning, thereby greatly improving the accuracy and clinical usability of the final output result, achieving significant improvement compared to the existing linear extraction process.

[0082] Embodiment 3

[0083] This embodiment details how the prompt word generation module 20 constructs and applies complex hierarchical prompt words to achieve fine-grained control over the reasoning process of the large language model. As an optional implementation, the hierarchical prompt word structure is one of the key technologies for improving extraction quality and dealing with complex medical scenarios.

[0084] According to one specific implementation scheme of the present application, the prompt word can be designed to contain four levels: the system level, the task level, the field level, and the verification level. These four levels work together to set a complete set of behavior standards and work processes for the large language model.

[0085] Take a more complex patient self-reporting scenario as an example: "I have had diabetes for ten years and have been taking metformin. Yesterday I started a fever and cough, and I took some cephalexin, but it didn't work."

[0086] When this text enters the prompt word generation step, the prompt word hierarchical module 30 will construct a structured prompt word containing four levels as follows:

[0087] System level prompt word: This layer is responsible for defining global, bottom-level behavior constraints to ensure the format and basic specifications of the output. It is usually used as the initial instruction for interacting with the large language model. For example: "system_prompt": "You are a professional medical information extraction AI assistant. Your task is to extract information from the provided text according to user instructions. All your outputs must strictly follow the JSON format specified by the user. All time-related strings must be parsed and converted to 'YYYY-MM-DD' format. For fields that cannot be found in the text, you must return null values instead of omitting the field." This layer of instructions ensures that the "skeleton" of the model output remains stable and predictable regardless of the task.

[0088] Task-level prompts: This layer sets the overall goal and strategy for the specific extraction task, helping the model understand the context and determine the priority of information extraction. For example: "task_prompt": "The current task is to process an outpatient visit record about a respiratory infection. Please focus on symptoms (present illness) and recent medications related to this illness. At the same time, it is crucial to strictly distinguish these acute issues from the patient's chronic medical history (past medical history) and their long-term medications." This layer's instructions guide the model to focus on acute information such as "fever, cough, cephalosporins," while being careful not to confuse it with "diabetes, metformin."

[0089] Field-level hints: This layer is the most specific. For each medical field to be extracted, it defines not only the name and data type, but may also include specific extraction templates and constraints containing medical knowledge. For example:

[0090] The json file "field_definitions": [{"name": "Present Illness History","description": "Records symptoms and events directly related to this visit.","structure": { "Symptoms": "string[]", "Start Time":"string", "Related Medications": "string[]"}},

[0091] {"name": "Past Medical History", "description": "Records the patient's long-term, chronic disease history."}

[0092] "structure": { "Disease Name": "string", "Disease Course": "string", "Long-Term Medication": "string[]"},

[0093] "rules": ["For example: hypertension, diabetes, coronary heart disease, etc."]},{"name": "Allergy history","description": "Record the patient's known drug or food allergy history."

[0094] "rules": ["If the text mentions antibiotics such as 'cephalosporins', special attention should be paid to whether there are any allergy descriptions."]}] At the field level, examples are added to "Patient History" to help the model better identify chronic diseases; context-sensitive dynamic rules are added to "Allergy History" to enhance risk identification capabilities.

[0095] Validation Prompt: As an innovation of this application, this layer embeds instructions within the prompts to guide the large language model to perform a preliminary "self-check." This encourages the model to perform a pre-validation of logical consistency before generating the final output. For example: "validation_prompt": "Before generating the final JSON output, please perform the following self-check:

[0096] 1. Confirm that the relevant medications (such as cephalosporins) in the present medical history are logically related to the reported symptoms (such as fever and cough).

[0097] 2. Confirm that the 'long-term medication' (such as metformin) in the 'past medical history' matches the recorded chronic disease (such as diabetes).

[0098] 3. Check for any discrepancies between the information in the 'present illness' and 'past medical history' sections.

[0099] When these four levels of prompts are integrated and input into the large language model inference module 30 along with the original text, the model performs a highly structured and controlled inference process. It first understands the global format requirements (system layer), then clarifies the task focus (task layer), then matches and extracts information from the text according to detailed field definitions and rules (field layer), and finally performs an internal logical review based on the instructions of the validation layer before output.

[0100] Therefore, for the input text "I've had diabetes for ten years and have been taking metformin. Yesterday I started having a fever and cough, and I took some cephalosporin, but it didn't work.", a model that follows this hierarchical prompt word structure is more likely to directly generate a high-quality, logically clear preliminary result, such as:

[0101] { "Chief Complaint": "Fever, Cough", "Present Illness": { "Symptoms": ["Fever", "Cough"], "Start Time": "2025-08-16", "Related Medications": ["Cephalexin"]}, "Past Medical History": { "Disease Name": "Diabetes Mellitus", "Duration of Disease": "Ten Years", "Long-Term Medications": ["Metformin"]}, "Allergy History": null}

[0102] This result has quite accurately separated acute and chronic information and associated drugs with corresponding medical histories. Even if the result still has minor flaws, the processing burden on the subsequent medical knowledge base correction module 40 and logic verification module 50 has been greatly reduced.

[0103] Through the deepening application of the hierarchical prompt words, the system of the present application can avoid common errors to the greatest extent in the reasoning stage, so that the whole information extraction process is more efficient and accurate, and the output data is more rich and intelligent.

[0104] It can be understood that the same or similar parts in the above embodiments can be mutually referred to, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0105] It should be noted that in the description of the present application, the terms "first", "second" and the like are only used for descriptive purposes and should not be construed as indicating or implying relative importance. In addition, in the description of the present application, unless otherwise specified, the meaning of "a plurality of" or "multiple" is at least two.

[0106] It should be understood that when an element is referred to as being "fixed to" or "disposed on" another element, it can be directly on the other element or a middle element can be present at the same time; when an element is referred to as being "connected" to another element, it can be directly connected to the other element or a middle element can be present at the same time, in addition, "connected" used herein can include wireless connection; the phrase "and / or" used herein includes any unit and all combinations of the associated listed items.

[0107] Any process or method descriptions in flow charts or described elsewhere herein can be understood as representing code modules, segments, or portions of code that include one or more executable instructions for implementing specific logic functions or steps in the process, and the various embodiments of the present application can include additional implementation with additional functions, in which the order of the steps can be changed, including according to the involved functions, in a substantially simultaneous manner or in reverse order, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0108] It should be understood that the parts of the present application can be realized by hardware, software, firmware or their combination. In the above embodiments, a plurality of steps or methods can be realized by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if realized by hardware, and as in another embodiment, it can be realized by any one or their combination of the following technologies known in the art: discrete logic circuit with logic gate circuit for implementing logic function on data signal, application specific integrated circuit with suitable combination logic gate circuit, programmable gate array (PGA), field programmable gate array (FPGA) and the like.

[0109] Those skilled in the art can understand that all or part of the steps of the method carried out by the above-mentioned embodiments can be instructed by a program to the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0110] In addition, each functional unit in each embodiment of the present application can be integrated into one processing module, or each unit can exist physically alone, or two or more units can be integrated into one module. The integrated module can be realized in the form of hardware or in the form of a software functional module. When the integrated module is realized in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer readable storage medium.

[0111] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0112] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example" or "some examples" means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative description of the above terms does not necessarily mean the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0113] Although the embodiments of the present application have been shown and described above, it can be understood that the above-mentioned embodiments are exemplary and cannot be understood as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present application.

Claims

1. A system for electronic medical record information extraction, characterized by, The system comprises: a data acquisition module for acquiring multi-module medical text data; the multi-module medical text data comprises: doctor-patient conversation voice transcription text, free text medical record, and OCR-recognized imaging and test report; a prompt word generation module for generating prompt words containing a hierarchical structure for a preset medical information extraction task; a model inference module for inputting the prompt words containing the hierarchical structure and the preprocessed multi-module medical text data to a preset large language model to obtain a preliminary extraction result containing candidate medical information; a term correction module for calling a preset medical knowledge base to compare and standardize medical terms in the preliminary extraction result; a logic verification module for performing logic verification on the extraction result corrected by the term correction module, wherein the logic verification comprises at least one of time sequence relationship verification and cross-field information consistency verification to generate final structured medical record information; the prompt words containing the hierarchical structure comprise: a system layer for defining a global output format and constraints, a task layer for setting extraction priority and strategy, a field layer for constructing templates and constraints for specific medical fields, and a verification layer for guiding the large language model to perform self-checking; the logic verification performed by the logic verification module comprises at least one of the following operations: performing time sequence relationship verification to sort the sequence of symptom occurrence according to the time expression in the original text, and converting relative time expressions into standardized absolute time stamps; performing cross-field information consistency verification to eliminate redundant symptoms or semantically similar symptoms.

2. The system of claim 1, wherein, The logic verification module is further configured to generate a correction prompt word when the logic verification finds errors or inconsistencies, and control the model inference module to input the correction prompt word and the original text and context information into the large language model again to instruct it to make targeted corrections to form a closed-loop correction process.

3. The system of claim 1, wherein, The system further comprises: a text preprocessing module configured between the data acquisition module and the model inference module, for preprocessing the medical text data to remove idle chat, noise, and non-medical related content.

4. The system of claim 1, wherein, Further comprising: a structured output module for converting the final structured medical record information into a preset data format and connecting to a hospital information system or an electronic medical record system; the preset data format comprises JSON, XML, FHIR, or HL7.

5. A method for electronic medical record information extraction, applied to the system for electronic medical record information extraction according to any one of claims 1-4, characterized in that, The method comprises: acquiring multi-module medical text data; the multi-module medical text data comprises: doctor-patient conversation voice transcription text, free text medical record, and OCR-recognized imaging and test report; generating prompt words containing a hierarchical structure for a preset medical information extraction task; inputting the prompt words containing the hierarchical structure and the preprocessed multi-module medical text data to a preset large language model to obtain a preliminary extraction result containing candidate medical information; calling a preset medical knowledge base to compare and standardize medical terms in the preliminary extraction result; Logical verification is performed on the extraction result after the correction by the term correction module, and the logical verification includes at least one of time sequence relationship verification and cross-field information consistency verification to generate final structured medical record information.

6. The method of claim 5, wherein, Before the step of inputting the prompt word with the hierarchical structure into the preset large language model to obtain the preliminary extraction result containing the candidate medical information, the method further includes: The medical text data is preprocessed to remove non-medical related content.

Images