Medical record migration model training method and medical record migration method based on same

Abstract

This application relates to the field of medical informatics and data processing technology, and discloses a method for training a medical record transfer model and a method for transferring medical records based thereon. The method includes: acquiring the diagnostic text of the source medical record; encoding and mapping the chief complaint information in the diagnostic text to obtain the corresponding anchor code; and constructing a simplified source medical record based on the chief complaint information; acquiring a pre-constructed clinical manifestation knowledge graph; inputting the anchor code into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; inputting the anchor code, the list of constrained elements, and the simplified source medical record as training samples into a large language model to obtain a medical record generation model; validating the medical record generation model based on the diagnostic text, and updating the medical record generation model based on the validation results to obtain a medical record transfer model. The technical solution provided by this application solves the transfer problem caused by inconsistent data structure standards between electronic medical record systems, and the problem of inconsistent clinical logic in large models during medical record conversion.

Description

Technical Field

[0001] This application relates to the field of medical informatics and data processing technology, and in particular to a method for training a medical record transfer model and a method for transferring medical records based thereon. Background Technology

[0002] As the core carrier of medical informatization, the level of data structuring in electronic medical records directly affects the operational efficiency of clinical diagnosis and treatment, scientific research and teaching, and medical quality management. In recent years, domestic medical institutions have generally introduced electronic medical record systems from different vendors and with different versions. Each institution often formulates its own detailed standards based on regional characteristics and business needs, resulting in a development pattern of "diverse standards and fragmented versions."

[0003] In real-world business scenarios, medical institutions generally face two major technical challenges: First, during system upgrades or vendor changes, due to differences in structured standards such as medical record field definitions, data types, and coding rules between the old and new systems, historical medical record data often cannot be directly migrated to the new system. Second, traditional practices rely on a large number of manually written scripts to complete data cleaning and field mapping, which is not only time-consuming and costly, but also prone to data distortion or loss due to human error, seriously affecting the continuity and integrity of medical data.

[0004] In recent years, related technologies have attempted to introduce large language models to achieve intelligent medical record conversion. However, large models exhibit an "illusion" phenomenon when generating structured content, potentially fabricating information that does not exist in the source medical record or distorting the original meaning, which is unacceptable in rigorous medical settings.

[0005] Therefore, how to solve the migration problem caused by the lack of unified data structure standards between electronic medical record systems, and the problem of inconsistent clinical logic in large models during medical record conversion, have become the technical problems that need to be solved. Summary of the Invention

[0006] This application provides a method for training a medical record transfer model and a method for transferring medical records based thereon, which solves the problem of transfer between electronic medical record systems caused by inconsistent data structure standards, as well as the problem of inconsistent clinical logic in large models during medical record conversion.

[0007] To achieve the above objectives, the main technical solutions adopted in this application include: In a first aspect, embodiments of this application provide a method for training a medical record transfer model, the method comprising: Obtain the diagnostic text of the source medical record, encode and map the chief complaint information in the diagnostic text, obtain the corresponding anchor code, and construct a simplified source medical record based on the chief complaint information; A pre-constructed clinical manifestation knowledge graph is obtained, and the anchoring code is input into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; wherein, the entity information in the clinical manifestation knowledge graph is used to represent clinical diagnosis and treatment related attribute information; The anchored encoding, the list of constraint elements, and the simplified source medical records are used as training samples to input into the large language model to obtain the medical record generation model. The medical record generation model is validated based on the diagnostic text, and the medical record generation model is updated according to the validation results to obtain a medical record transfer model.

[0008] This embodiment provides a method for training a medical record transfer model. First, diagnostic text is extracted from the source medical record. The chief complaint information within the diagnostic text is encoded and mapped to obtain anchor codes, and a simplified source medical record is constructed. Then, the anchor codes are input into a pre-constructed clinical manifestation knowledge graph. The entity relationships within the clinical manifestation knowledge graph are used to accurately locate and output a list of strongly constrained elements containing entity information such as symptom information, location information, and time characteristics. Next, the anchor codes, the list of constrained elements, and the simplified source medical record are used as training samples and input into a large language model for fine-tuning, resulting in a medical record generation model. This model masters the generation specifications and logic of simulated medical records. Finally, the medical record generation model is validated and its performance evaluated using diagnostic text. Based on the validation results, the model is optimized and its parameters adjusted to obtain a medical record transfer model. This model can adapt to different medical record types or disease types, achieving efficient transfer and application of medical records. The medical record content generated by the method provided in this embodiment is accurate, complete, and conforms to clinical expression standards, significantly improving the efficiency and quality of medical record writing. The strong constraints of the knowledge graph ensure the accurate capture of key elements (symptoms, location, time), reducing omissions and errors. The validated and iteratively optimized medical record transfer model has good generalization ability and can be flexibly applied to various clinical tasks, promoting the intelligentization and standardization of medical record transfer. This solves the transfer problem caused by inconsistent data structure standards between electronic medical record systems, as well as the problem of inconsistent clinical logic in medical record conversion.

[0009] In one embodiment, obtaining a pre-constructed clinical manifestation knowledge graph and inputting the anchoring encoding into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements includes: Assign basic weights to each entity in the clinical manifestation knowledge graph; Obtain the frequency of occurrence of source entity information in the source medical record, and update the basic weights based on the frequency of occurrence; If the updated base weight is greater than a preset threshold, the entity information to which the updated base weight belongs will be used as a strong constraint element. The strong constraint elements are obtained based on the anchoring code, and the strong constraint elements are concatenated to obtain the list of strong constraint elements.

[0010] This embodiment pre-configures a basic weight for each entity in the clinical manifestation knowledge graph. Then, by acquiring the frequency of occurrence of source entity information in the source medical records, the basic weight is dynamically updated using this frequency, ensuring that the basic weight accurately reflects its actual importance in the corresponding anchoring code. When the updated basic weight of an entity exceeds a preset threshold, it is identified as an element with a key constraint effect on the anchoring code, i.e., a strong constraint element. Finally, based on the anchoring code, all eligible strong constraint elements are accurately obtained and concatenated to generate a list of strong constraint elements. Through this complete process from static configuration to dynamic optimization, threshold filtering, and structured output, a list of strong constraint elements highly relevant to the anchoring code can be automatically identified and extracted from massive amounts of medical knowledge, significantly improving the application effect and accuracy of subsequent simulated chief complaints.

[0011] In one implementation, the step of inputting the anchored encoding, the list of constraint elements, and the simplified source medical records as training samples into a large language model to obtain a medical record generation model includes: A simulated complaint is generated based on a trained large language model; The simulated chief complaint is input into a preset simulated medical record generation model to obtain the medical record generation model.

[0012] This embodiment generates a simulated chief complaint using a trained large language model, and then inputs the simulated chief complaint into a preset simulated medical record generation model. Using anchored coding and the simulated chief complaint as the core, combined with diagnostic text, it drives the progressive generation of each stage of the simulated medical record (such as present illness, past medical history, and auxiliary examinations), ensuring consistency and logical self-consistency in the content generated at each stage. The final result is a highly coherent and professionally standardized simulated medical record, with all details revolving around anchored coding and diagnostic text, significantly improving the accuracy of simulated medical record generation.

[0013] In one implementation, the large language model is trained as follows: Obtain the simulated complaint output by the large language model, and obtain the entity coverage rate based on the difference between the entity information in the simulated complaint and the list of constraint elements; Semantic similarity is obtained by comparing the simulated chief complaint with a preset unified medical standard. A composite loss function is constructed based on the entity coverage and the semantic similarity, and the large language model is trained using the composite loss function.

[0014] This embodiment constructs a composite evaluation index of entity coverage and semantic similarity to conduct multi-dimensional quantitative evaluation of the simulated complaints generated by the large language model; based on the composite loss function, it performs dynamic quality control on the generation results, effectively solving the problems of missing entity information and semantic expression deviation in the generation of simulated complaints, significantly improving the clinical applicability and overall accuracy of the generated content, and ultimately achieving high-quality and highly reliable automatic generation of simulated complaints.

[0015] In one implementation, validating the medical record generation model based on the diagnostic text includes: The simulated medical records generated by the medical record generation model are compared with the preset typical clinical manifestation descriptions, and the description similarity is obtained based on the comparison results. Based on the similarity between the diagnostic text and the simulated medical record, the traceability fidelity is obtained; A fusion judgment function is constructed based on the description similarity and the traceability fidelity, and the medical record generation model is verified using the fusion judgment function.

[0016] This embodiment systematically measures the clinical accuracy and diagnostic traceability of generated simulated medical records through a fusion judgment function of descriptive similarity and traceability fidelity. First, in the descriptive similarity calculation, the generated simulated medical record is compared with preset typical clinical manifestation descriptions, and the descriptive similarity is calculated. The closer the descriptive similarity value is to 1, the more the simulated medical record's manifestation conforms to typical clinical characteristics, thus providing a quantitative basis for the quality review of simulated medical records and the optimization of the medical record generation model. Second, by calculating the similarity between the diagnostic text and the simulated medical record, the traceability fidelity is obtained. The closer the traceability fidelity is to 1, the more accurately the generated content reflects the diagnostic text, ensuring the traceability of the simulated medical record. Based on this, a fusion judgment function is constructed to verify the performance of the medical record generation model, providing reliable data support and quantitative basis for the optimization and accuracy evaluation of the medical record generation model.

[0017] In one implementation, obtaining traceability fidelity based on the similarity between the diagnostic text and the simulated medical record includes: Based on the diagnostic text, target text that matches the diagnostic text is found from the simulated medical records to obtain positive similarity; Based on the simulated medical record, target text that matches the simulated medical record is searched from the diagnostic text to obtain reverse similarity; Based on the forward similarity and the reverse similarity, the traceability fidelity is obtained.

[0018] This embodiment employs bidirectional similarity, combining forward and reverse similarity: forward similarity starts from each sentence in the diagnostic text and retrieves the most similar target sentence in the simulated medical record; reverse similarity starts from each sentence in the simulated medical record and retrieves the most similar source target sentence in the diagnostic text. The traceability fidelity is obtained by weighted summation of the forward and reverse similarity values. The closer the traceability fidelity value is to 1, the more accurate the bidirectional similarity between the diagnostic text and the simulated medical record, and the higher the fidelity of information traceability, providing high-quality symmetric data support for subsequent analysis.

[0019] Secondly, embodiments of this application provide a method for medical record migration, the method comprising: Obtain the source medical record to be transferred, and input the source medical record to be transferred into the medical record transfer model obtained by any of the training methods described above to obtain the target medical record.

[0020] Thirdly, embodiments of this application provide a medical record transfer model training device, the device comprising: The source medical record unit is used to obtain the diagnostic text of the source medical record, encode and map the chief complaint information in the diagnostic text, obtain the corresponding anchor code, and construct a simplified source medical record based on the chief complaint information. The list acquisition unit is used to acquire a pre-constructed clinical manifestation knowledge graph, input the anchoring code into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; wherein, the entity information in the clinical manifestation knowledge graph is used to represent clinical diagnosis and treatment related attribute information; The model generation unit is used to input the anchoring code, the list of constraint elements, and the simplified source medical record as training samples into the large language model to obtain a medical record generation model. The verification unit is used to verify the medical record generation model based on the diagnostic text, and update the medical record generation model according to the verification result to obtain the medical record transfer model.

[0021] Fourthly, embodiments of this application provide a computer device, including: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the aforementioned medical record transfer model training method or the aforementioned medical record transfer method.

[0022] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the medical record transfer model training method or the medical record transfer method described above. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a method for training a medical record transfer model, as provided in this application embodiment; Figure 2 A flowchart of step S31 provided in an embodiment of this application; Figure 3 A flowchart of step S51 provided in an embodiment of this application; Figure 4 A flowchart of step S531 provided in an embodiment of this application; Figure 5 A flowchart of step S71 provided in an embodiment of this application; Figure 6 A flowchart of step S731 provided in an embodiment of this application; Figure 7 A medical record transfer model training device is provided as an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] As the core carrier of medical informatization, the degree of data structuring in electronic medical records directly determines the convenience of clinical diagnosis and treatment, the usability of research data, and the level of refinement in medical quality management. In recent years, although domestic medical institutions have generally established electronic medical record systems from different vendors and with different versions, in actual implementation, they have developed their own detailed standards due to regional characteristics and business needs. This situation of "multiple developments and fragmented versions" has led to significant differences in data standards at the implementation level, creating inherent obstacles to subsequent data interconnection and interoperability.

[0027] In real-world business scenarios, medical institutions face two major technical challenges: First, when upgrading systems or changing vendors, the lack of uniformity in structured standards such as field definitions, data types, and coding rules between the old and new systems often prevents the direct migration of massive amounts of historical medical record data to the new system, creating a "data gap." Second, the traditional method of relying on manually written scripts for data cleaning and field mapping is not only time-consuming and costly, but also prone to data distortion or loss due to human error, seriously threatening the continuity, integrity, and accuracy of clinical semantics of medical data.

[0028] Faced with this dilemma, related technologies have begun to explore the use of large language models for intelligent medical record conversion. However, the "illusion" phenomenon that large models exhibit when generating structured content has become a difficult red line to cross. These models may fabricate information not present in the source medical record or distort the original meaning, which is completely unacceptable in a rigorous medical setting.

[0029] In summary, how to solve the migration difficulties caused by inconsistent data structure standards between electronic medical record systems, and the inconsistency of clinical logic in large models during medical record conversion, have become the technical problems that need to be solved.

[0030] To address the aforementioned technical problems, an embodiment of a medical record transfer model training method is provided according to the present application. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] This embodiment provides a method for training a medical record transfer model. Figure 1 A flowchart of a medical record transfer model training method provided in this application embodiment is shown below. Figure 1 As shown, the process includes the following steps: Step S1: Obtain the diagnostic text of the source medical record, encode and map the chief complaint information in the diagnostic text, obtain the corresponding anchor code, and construct a simplified source medical record based on the chief complaint information.

[0032] Specifically, the source medical records are divided into two categories: one is internally structured source medical records, which can be directly read and the diagnostic text extracted in the electronic medical record system; the other is externally unstructured source medical records, covering formats such as images, portable document format (PDF), and text. For externally unstructured medical records, text recognition is performed through a preset integrated OCR engine, and combined with layout analysis algorithms (such as LayoutLM or a deep learning-based layout segmentation model) to convert the externally unstructured medical records into structured text data; and a specialized diagnostic recognition model (such as a fine-tuned BERT-NER model) is called to extract diagnostic text from the structured text data. The diagnostic text contains all the information in the source medical records, including but not limited to chief complaint information, present illness history, past medical history, physical examination, auxiliary examination results, and surgical records, etc. The chief complaint information is directly read based on the diagnostic text. The diagnostic information (such as diabetes, myocardial infarction, etc.) contained in the obtained chief complaint information is input into the International Classification of Diseases (ICD) terminology mapping engine. The ICD terminology mapping engine has a built-in multi-version International Classification of Diseases (ICD) coding library (such as ICD-9, ICD-10, ICD-11) and a synonym mapping table. It can encode and map the diagnostic information to the standard ICD-10 code or convert the encoding between different ICD versions, and perform normalization verification and completion of existing codes. The diagnostic information is finally obtained by the ICD terminology mapping engine as a verified and standardized anchor code, which will serve as the logical benchmark for all subsequent generation and verification stages. At the same time, a diagnostic recognition model (such as a fine-tuned BERT-NER model) is used to semantically filter the diagnostic text according to the chief complaint information, accurately extract the sentences most relevant to the chief complaint information, and construct a concise source medical record. This effectively reduces input noise while retaining key clinical information, so as to eliminate the interference of redundant information on the subsequent simulated chief complaint generation.

[0033] Step S3: Obtain the pre-constructed clinical manifestation knowledge graph, input the anchoring code into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; wherein, the entity information in the clinical manifestation knowledge graph is used to represent clinical diagnosis and treatment related attribute information.

[0034] Specifically, a pre-constructed clinical manifestation knowledge graph is acquired. Based on this, anchor codes are used as input information and integrated with the clinical manifestation knowledge graph. Utilizing the rich relationships and semantic structures between entities in the clinical manifestation knowledge graph, strongly constrained elements matching the anchor codes can be accurately located, and a list of strongly constrained elements strictly conforming to the constraints is output. Entity information can include patient symptom information, location information (the specific body part where the symptoms occur), and temporal characteristics.

[0035] Step S5: Input the anchored encoding, constraint element list, and simplified source medical records as training samples into the large language model to obtain the medical record generation model.

[0036] Specifically, anchor codes, constraint element lists, and simplified source medical records are used as training samples and input into a large language model for learning and fine-tuning. In this way, the medical record generation model can master the generation specifications and expression logic of the diagnostic text in the source medical record, and thus, under the guidance of anchor codes, combine with the diagnostic text to generate high-quality medical record content.

[0037] Step S7: Validate the medical record generation model based on the diagnostic text, and update the medical record generation model according to the validation results to obtain the medical record transfer model.

[0038] Specifically, diagnostic texts were used as a validation dataset to systematically evaluate the performance and clinical consistency of the medical record generation model. By comparing the simulated medical records generated by the model with real diagnostic texts, the accuracy and completeness of the model in symptom description, site localization, temporal feature extraction, and language standardization were analyzed. Based on this, and considering the errors and deficiencies identified during validation, the model was optimized and its parameters adjusted accordingly, such as by introducing feedback mechanisms or optimizing attention mechanisms to improve the ability to capture key elements. After multiple rounds of validation and iteration, a more stable and generalizable medical record transfer model was finally obtained. This model not only adapts to the needs of medical record writing in different clinical scenarios or disease types but also enables efficient transfer and application of knowledge across diverse tasks.

[0039] This embodiment provides a method for training a medical record transfer model. First, diagnostic text is extracted from the source medical record. The chief complaint information within the diagnostic text is encoded and mapped to obtain anchor codes, and a simplified source medical record is constructed. Then, the anchor codes are input into a pre-constructed clinical manifestation knowledge graph. The entity relationships within the clinical manifestation knowledge graph are used to accurately locate and output a list of strongly constrained elements containing entity information such as symptom information, location information, and time characteristics. Next, the anchor codes, the list of constrained elements, and the simplified source medical record are used as training samples and input into a large language model for fine-tuning, resulting in a medical record generation model. This model masters the generation specifications and logic of simulated medical records. Finally, the medical record generation model is validated and its performance evaluated using diagnostic text. Based on the validation results, the model is optimized and its parameters adjusted to obtain a medical record transfer model. This model can adapt to different medical record types or disease types, achieving efficient transfer and application of medical records. The medical record content generated by the method provided in this embodiment is accurate, complete, and conforms to clinical expression standards, significantly improving the efficiency and quality of medical record writing. The strong constraints of the knowledge graph ensure the accurate capture of key elements (symptoms, location, time), reducing omissions and errors. The validated and iteratively optimized medical record transfer model has good generalization ability and can be flexibly applied to various clinical tasks, promoting the intelligentization and standardization of medical record transfer. This solves the transfer problem caused by inconsistent data structure standards between electronic medical record systems, as well as the problem of inconsistent clinical logic in medical record conversion.

[0040] Figure 2 The flowchart for S3 provided in this application embodiment may include the following steps: Step S31: Assign basic weights to each entity in the clinical manifestation knowledge graph.

[0041] Specifically, each entity information is assigned a base weight between 0 and 1. The base weight is initialized using a multi-source information fusion strategy, which integrates the strength of evidence in clinical guidelines, the statistical frequency of real medical record data, and the scores of domain experts, and is calculated through weighted average.

[0042] Step S33: Obtain the frequency of occurrence of source entity information in the source medical record, and update the basic weights based on the frequency of occurrence.

[0043] Specifically, by obtaining the mapping relationship between source entity information and its corresponding anchor code in the source medical record, and combining the frequency of occurrence of source entity information under the corresponding anchor code, the basic weights are dynamically adjusted. For example, in a source medical record with "acute myocardial infarction" as the anchor code, the frequency of occurrence of source entity information (such as symptoms like retrosternal squeezing pain and chest tightness, as well as information on the left shoulder, left arm, jaw, or other source entity information) in the source medical record is statistically analyzed. The frequency of occurrence is then weighted and summed to obtain the proportion of each type of source entity information in its corresponding category. Taking acute myocardial infarction as an example, the symptom information mainly includes retrosternal squeezing pain, nausea and sweating, and chest tightness. First, the total number of occurrences of these three types of source entity information is counted, and this is taken as the total count. Then, based on the proportion of each type of source entity information in the total count, its corresponding frequency of occurrence is calculated. For example, the frequency of occurrence of "retrosternal squeezing pain" is 1568, the total number of occurrences is 1960, and the frequency of occurrence of "retrosternal squeezing pain" is 0.8. This 0.8 is then used as the updated base weight for "retrosternal squeezing pain". Based on the frequency of occurrence, the correlation strength between anchor codes and entity information can be more accurately quantified, thereby enabling dynamic correction and optimization of the base weight.

[0044] Step S35: If the updated basic weight is greater than the preset threshold, the entity information to which the updated basic weight belongs is used as a strong constraint element.

[0045] Specifically, when the updated base weights are greater than a preset threshold, it means that the association strength between the anchored encoding and the corresponding entity information has reached a significant level. Therefore, the entity information to which the base weights belong at this time is taken as a strong constraint element. For example, the strong constraint elements obtained for acute myocardial infarction include retrosternal squeezing pain, chest tightness, left shoulder, left arm, and time features.

[0046] Step S37: Obtain the strong constraint elements based on anchor coding, and concatenate the strong constraint elements to obtain a list of strong constraint elements.

[0047] Specifically, after screening the strong constraint elements, the anchoring code is used to accurately locate the corresponding strong constraint elements in the clinical manifestation knowledge graph. Based on the index order of the encoding or the order of clinical relevance (e.g., Top 5 symptom information, Top 3 location information, Top 2 time features), all the strong constraint elements marked as strong constraints are obtained one by one. On this basis, the obtained strong constraint elements are spliced ​​using preset splicing rules (e.g., sorted by pathophysiological process, arranged by the time sequence of symptom appearance, or combined by semantic association), and finally a complete and ordered list of strong constraint elements is generated, thus providing a foundation for subsequent content generation and content detection.

[0048] This embodiment pre-configures a basic weight for each entity in the clinical manifestation knowledge graph. Then, by acquiring the frequency of occurrence of source entity information in the source medical records, the basic weight is dynamically updated using this frequency, ensuring that the basic weight accurately reflects its actual importance in the corresponding anchoring code. When the updated basic weight of an entity exceeds a preset threshold, it is identified as an element with a key constraint effect on the anchoring code, i.e., a strong constraint element. Finally, based on the anchoring code, all eligible strong constraint elements are accurately obtained and concatenated to generate a list of strong constraint elements. Through this complete process from static configuration to dynamic optimization, threshold filtering, and structured output, a list of strong constraint elements highly relevant to the anchoring code can be automatically identified and extracted from massive amounts of medical knowledge, significantly improving the application effect and accuracy of subsequent simulated chief complaints.

[0049] Figure 3 The flowchart for S5 provided in this application embodiment may include the following steps: Step S51: Generate a simulated complaint based on the trained large language model.

[0050] Specifically, a structured prompt word template was designed, employing a lightweight data exchange format (JSON) to clearly define information layers: including anchor coding, a list of strong constraints, a pre-defined chief complaint format, and a simplified source medical record. For example, for the diagnosis of "acute appendicitis," the anchor coding could be set to "ICD-10: K35.9, Name: Acute Appendicitis," and the prompt word template would clearly list elements such as "migratory right lower quadrant pain" and "McBurney's point tenderness," along with a simplified source medical record as context. This method enables large language models to accurately identify which elements must be followed, preventing key information from being diluted or ignored during generation. By using the universal JSON format, the prompt word template can easily adapt to the input requirements of large models from different vendors or versions, significantly improving the reusability and deployment efficiency of the solution, thereby obtaining accurate simulated chief complaints.

[0051] Step S53: Input the simulated chief complaint into the preset simulated medical record generation model to obtain the medical record generation model.

[0052] Specifically, after generating the simulated chief complaint, the simulated chief complaint, as the core input, together with anchor coding, constitutes a contextual constraint to drive the progressive generation of the simulated medical record generation model. Based on "anchor coding + simulated chief complaint + diagnostic text," progressive guiding logic is designed for each field to be generated. Taking acute myocardial infarction (anchor coding I21.9) as an example, the input includes anchor coding, simulated chief complaint (retrosternal squeezing pain for 3 hours), and diagnostic text. First, the generation order is determined to be present illness to past medical history to auxiliary examinations, and the typical content framework of the present illness is clarified: onset, symptom characteristics, evolution, and treatment process. Next, the entity information of the simulated chief complaint is extracted: symptom information is chest pain, squeezing nature; location information is retrosternal, radiating to the left shoulder; time characteristic is 3 hours ago. The first-level prompts used to generate the present medical history are constructed based on anchored coding (code I21.9, for diagnosing acute myocardial infarction), simulated chief complaint, diagnostic text (e.g., "The patient suddenly experienced oppressive pain behind the sternum radiating to the left shoulder after exertion 3 hours ago, accompanied by profuse sweating. Self-administered nitroglycerin was ineffective, and the patient was transported to our hospital by ambulance. The emergency ECG showed ST segment elevation in leads V1-V4"), and format requirements (chronological order, detailed description of symptom evolution, including details of radiating pain). The simulated medical record generation model generates the present medical history based on the first-level prompts, such as: "The patient suddenly experienced oppressive pain behind the sternum radiating to the left shoulder after exertion 3 hours ago, accompanied by profuse sweating. Self-administered nitroglycerin was ineffective, and the patient was transported to our hospital by ambulance. The emergency ECG showed ST segment elevation in leads V1-V4." This ensures that the symptom information, location information, and time characteristics in the present medical history completely match the simulated chief complaint, the timeline is consistent, and the logic conforms to the clinical pathway for myocardial infarction. Next, the past medical history is generated. The second prompt for generating the past medical history is constructed based on the diagnostic text, anchored encoding, entity information of the simulated chief complaint, diagnostic text, and present medical history. The simulated medical record generation model generates the past medical history based on the second prompt, such as "10-year history of hypertension and 5-year history of type 2 diabetes". Then, auxiliary examinations are generated. The third prompt word used to generate auxiliary tests is based on the diagnostic text, present medical history, and past medical history, and must include specific values. The simulated medical record generation model generates auxiliary examinations, such as "ECG: ST segment elevation 0.3mV in leads V1-V4; cardiac enzymes: CK-MB 85U / L, cTnI 2.5ng / mL". The entire process of generating the simulated medical record forms a progressive logical chain: the generation of each new step is based on all the previous steps, the disease theme is constrained by anchor coding, and the original information is referenced by the diagnostic text. This ensures that the simulated medical record is logically consistent and chronologically reasonable between each step. All details revolve around anchor coding and diagnostic text, ultimately generating a highly coherent and professionally standardized simulated medical record.

[0053] This embodiment generates a simulated chief complaint using a trained large language model, and then inputs the simulated chief complaint into a preset simulated medical record generation model. Using anchored coding and the simulated chief complaint as the core, combined with diagnostic text, it drives the progressive generation of each stage of the simulated medical record (such as present illness, past medical history, and auxiliary examinations), ensuring consistency and logical self-consistency in the content generated at each stage. The final result is a highly coherent and professionally standardized simulated medical record, with all details revolving around anchored coding and diagnostic text, significantly improving the accuracy of simulated medical record generation.

[0054] Figure 4 The flowchart for step S53 provided in the embodiments of this application may include the following steps: Step S531: Obtain the simulated complaint output by the large language model, and obtain the entity coverage rate based on the difference between the entity information in the simulated complaint and the list of constraint elements.

[0055] Specifically, based on the entity information in the simulated complaint output by the large language model, synonym matching is performed on the strongly constrained elements in the strongly constrained element list corresponding to the input anchor code to obtain the number of matched entities, thereby calculating the entity coverage rate, which is expressed as follows: Entity coverage = Number of matching entities / Total number of strongly constrained features Step S533: Obtain semantic similarity based on the similarity comparison between the simulated chief complaint and the preset unified medical standard.

[0056] Specifically, a large language model generates a simulated complaint and compares its semantic similarity with the corresponding anchor code using a pre-defined medical standard, thereby objectively evaluating the quality of the simulated complaint. For each anchor code (e.g., acute myocardial infarction), a "typical clinical manifestation description text" is pre-stored as a pre-defined medical standard, for example: "Acute myocardial infarction often presents as a squeezing pain behind the sternum, which may radiate to the left shoulder and last for several hours." A sentence encoder optimized by the pre-defined medical standard converts the simulated complaint and the pre-defined medical standard into vectors and calculates the similarity. For example, given the same myocardial infarction case, a simulated complaint of "chest tightness and pain accompanied by radiating pain in the left arm, which may radiate to the left shoulder and last for 3 hours" can achieve a semantic similarity of over 0.9; if it is only described as "chest pain," it will score moderately due to the omission of key information such as radiating pain; if it is mistakenly described as "stomach pain and acid reflux," it will score extremely low due to semantic deviation. This process achieves a refined evaluation of the simulated complaint through similarity comparison.

[0057] Step S535: Construct a composite loss function based on entity coverage and semantic similarity, and use the composite loss function to train a large language model.

[0058] Specifically, a composite loss function is constructed based on entity coverage and semantic similarity, and this composite loss function is used to train a large language model. The composite loss function is obtained by weighted summation of entity coverage and semantic similarity, and its expression is as follows: Composite loss function = 0.6 × entity coverage + 0.4 × semantic similarity Then, for each anchor code, the large language model generates a simulated complaint, calculates its composite loss function, and maximizes the expectation using the gradient of the composite loss function. The value of the composite loss function is compared with a preset validation threshold (0.8) as a benchmark to measure whether the simulated complaint meets the quality requirements. If the value of the composite loss function is ≥0.8, the generated simulated complaint is determined to meet the qualified standards in terms of entity information coverage and semantic expression, and conforms to the description requirements corresponding to the anchor code. Therefore, it is output as the final result and enters the subsequent application process. If the value of the composite loss function is <0.8, the simulated complaint is determined to have problems such as missing information, expression deviation, or semantic deviation, and fails to meet the quality requirements. The training sample is expanded and the simulated complaint is re-output until the preset validation threshold is reached to ensure the reliability and clinical applicability of the simulated complaint. This achieves dynamic quality control of the simulated complaint and improves the overall accuracy and practicality of the simulated complaint. After multiple rounds of iterative optimization, the simulated complaints generated by the large language model gradually approach the preset medical standards in terms of entity coverage and semantic similarity, and finally achieve high-quality complaint generation.

[0059] This embodiment constructs a composite evaluation index of entity coverage and semantic similarity to conduct multi-dimensional quantitative evaluation of the simulated complaints generated by the large language model; based on the composite loss function, it performs dynamic quality control on the generation results, effectively solving the problems of missing entity information and semantic expression deviation in the generation of simulated complaints, significantly improving the clinical applicability and overall accuracy of the generated content, and ultimately achieving high-quality and highly reliable automatic generation of simulated complaints.

[0060] Figure 5 The flowchart for step S7 provided in the embodiments of this application may include the following steps: Step S71: Compare the simulated medical record generated by the medical record generation model with the preset typical clinical manifestation description, and obtain the description similarity based on the comparison results.

[0061] Specifically, the simulated medical records are first compared with preset typical clinical manifestation descriptions (e.g., "K35.9: The typical manifestation of acute appendicitis is migratory right lower quadrant abdominal pain, initially periumbilical or upper abdominal pain, which shifts and becomes fixed in the right lower quadrant after several hours, and may be accompanied by nausea, vomiting, fever, tenderness at McBurney's point in the right lower quadrant, rebound tenderness, etc."). Then, a pre-trained encoding model is used to convert the simulated medical records and preset typical clinical manifestations into semantic vectors, and the similarity between the two is calculated using similarity analysis to obtain a description similarity score (e.g., 0.95). The closer this score is to 1, the more closely the simulated medical records match the preset typical clinical manifestation description. This process effectively compares the consistency between the simulated medical records and the preset typical clinical manifestation descriptions, providing a quantitative basis for the quality review of simulated medical records and the optimization of the medical record generation model.

[0062] Step S73: Obtain the traceability fidelity based on the similarity between the diagnostic text and the simulated medical record.

[0063] Specifically, the similarity score between the diagnostic text and the generated simulated medical record is calculated, and the resulting score is the traceability fidelity. The closer the traceability fidelity is to 1, the more accurate the content of the generated simulated medical record is, thus ensuring the traceability of the simulated medical record and providing a quantitative basis for validating the medical record generation model.

[0064] Step S75: Construct a fusion judgment function based on description similarity and traceability fidelity, and use the fusion judgment function to verify the medical record generation model.

[0065] Specifically, by setting weights and The fusion judgment function is obtained by weighted summing of the clinical description similarity S_clinical and the traceability fidelity S_fidelity, which is expressed as follows: A tiered threshold was used as the pass standard: S_total ≥ 0.9, and both clinical description similarity and traceability fidelity were not lower than 0.85. Under these conditions, the generated simulated medical records achieved a high level of consistency in clinical presentation and diagnostic traceability, systematically validating the performance of the medical record generation model and providing quantitative evidence for its optimization and accuracy assessment.

[0066] This embodiment systematically measures the clinical accuracy and diagnostic traceability of generated simulated medical records through a fusion judgment function of descriptive similarity and traceability fidelity. First, in the descriptive similarity calculation, the generated simulated medical record is compared with preset typical clinical manifestation descriptions, and the descriptive similarity is calculated. The closer the descriptive similarity value is to 1, the more the simulated medical record's manifestation conforms to typical clinical characteristics, thus providing a quantitative basis for the quality review of simulated medical records and the optimization of the medical record generation model. Second, by calculating the similarity between the diagnostic text and the simulated medical record, the traceability fidelity is obtained. The closer the traceability fidelity is to 1, the more accurately the generated content reflects the diagnostic text, ensuring the traceability of the simulated medical record. Based on this, a fusion judgment function is constructed to verify the performance of the medical record generation model, providing reliable data support and quantitative basis for the optimization and accuracy evaluation of the medical record generation model.

[0067] Figure 6 A flowchart illustrating the training method of the large language model provided in this application embodiment, the process may include the following steps: Step S731: Based on the diagnostic text, find the target text that matches the diagnostic text from the simulated medical records to obtain positive similarity.

[0068] Specifically, target sentences that are highly similar to the diagnostic text are found in the simulated medical records. For example, for each target sentence in each diagnostic text, the most similar target sentence is retrieved in the simulated medical records, and the similarity is calculated to obtain positive similarity. The higher the similarity, the closer the positive similarity value is to 0. Positive similarity can effectively identify the positive semantic association between the diagnostic text and the simulated medical record, providing high-quality matching data for subsequent analysis and training.

[0069] Step S733: Based on the simulated medical record, find the target text that matches the simulated medical record from the diagnostic text to obtain reverse similarity.

[0070] Specifically, source target sentences that are highly similar to simulated medical records are retrieved from the diagnostic text to achieve reverse semantic matching. For example, for each sentence in the simulated medical record, the most similar source target sentence in the diagnostic text is found, and the similarity is calculated to obtain reverse similarity. The higher the similarity, the closer the reverse similarity value is to 0. Reverse similarity helps to verify the semantic accuracy of simulated medical record records from the perspective of diagnostic text and provides symmetrical data support for subsequent analysis.

[0071] Step S735: Obtain the traceability fidelity based on forward similarity and reverse similarity.

[0072] Specifically, when assessing the semantic consistency between diagnostic texts and simulated medical records, positive similarity is comprehensively utilized. Similar to the reverse Two dimensions allow for a more comprehensive measurement of the correspondence between the two sets of information. A traceability fidelity index is defined to quantify this overall quality in both directions. Weights are assigned. For the two are positively similar Similar to the reverse The weighted average of the two values ​​results in the following representation of the traceability fidelity S_fidelity: The closer the fidelity value S_fidelity is to 1, the more accurate the bidirectional similarity between the diagnostic text and the simulated medical record, and the higher the fidelity of information traceability.

[0073] This embodiment employs bidirectional similarity, combining forward and reverse similarity: forward similarity starts from each sentence in the diagnostic text and retrieves the most similar target sentence in the simulated medical record; reverse similarity starts from each sentence in the simulated medical record and retrieves the most similar source target sentence in the diagnostic text. The traceability fidelity is obtained by weighted summation of the forward and reverse similarity values. The closer the traceability fidelity value is to 1, the more accurate the bidirectional similarity between the diagnostic text and the simulated medical record, and the higher the fidelity of information traceability, providing high-quality symmetric data support for subsequent analysis.

[0074] In one optional embodiment, the source medical record to be transferred is obtained, and the source medical record to be transferred is input into the medical record transfer model obtained by the training method in steps S1 to S5 to obtain the target medical record, wherein the target medical record includes information such as chief complaint, present illness, past medical history and auxiliary examinations.

[0075] Accordingly, please refer to Figure 7 A medical record transfer model training device provided in this application includes: The source medical record unit 101 is used to obtain the diagnostic text of the source medical record, encode and map the chief complaint information in the diagnostic text, obtain the corresponding anchor code, and construct a simplified source medical record based on the chief complaint information.

[0076] The list acquisition unit 103 is used to acquire a pre-constructed clinical manifestation knowledge graph, input anchor codes into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; wherein, the entity information in the clinical manifestation knowledge graph is used to represent clinical diagnosis and treatment related attribute information.

[0077] The model generation unit 105 is used to input the large language model with anchored coding, a list of constraint elements, and a simplified source medical record as training samples to obtain a medical record generation model.

[0078] The verification unit 107 is used to verify the medical record generation model based on the diagnostic text and update the medical record generation model according to the verification results to obtain the medical record transfer model.

[0079] In some optional implementations, the list retrieval unit 103 includes: Assign basic weights to each entity in the clinical manifestation knowledge graph.

[0080] Obtain the frequency of occurrence of source entity information in the source medical record, and update the basic weights based on the frequency of occurrence.

[0081] If the updated base weight is greater than the preset threshold, the entity information to which the updated base weight belongs will be used as a strong constraint element.

[0082] The strongly constrained elements are obtained based on anchored coding, and then concatenated to obtain a list of strongly constrained elements.

[0083] In some optional implementations, the model generation unit 105 includes: A simulated complaint is generated based on a trained large language model.

[0084] Input the simulated chief complaint into the preset simulated medical record generation model to obtain the medical record generation model.

[0085] In some optional implementations, the model generation unit 105 includes: Obtain the simulated complaint output by the large language model, and obtain the entity coverage rate based on the difference between the entity information in the simulated complaint and the list of constraint elements.

[0086] Semantic similarity is obtained by comparing the simulated chief complaint with a pre-set unified medical standard.

[0087] A composite loss function is constructed based on entity coverage and semantic similarity, and this composite loss function is used to train a large language model.

[0088] In some optional implementations, the verification unit 107 includes: The simulated medical records generated by the medical record generation model are compared with the preset typical clinical manifestation descriptions, and the description similarity is obtained based on the comparison results.

[0089] The traceability fidelity is obtained based on the similarity between the diagnostic text and the simulated medical record.

[0090] A fusion judgment function is constructed based on description similarity and traceability fidelity, and the medical record generation model is validated using the fusion judgment function.

[0091] In some optional implementations, the verification unit 107 includes: Based on the diagnostic text, target text that matches the diagnostic text is found from the simulated medical records to obtain positive similarity; Based on simulated medical records, target text that matches the simulated medical records is found from the diagnostic text to obtain reverse similarity; Based on forward similarity and reverse similarity, the traceability fidelity is obtained.

[0092] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0093] In this embodiment, a medical record transfer model training device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0094] Please see Figure 8 , Figure 8 This application provides a schematic diagram of the structure of a computer device, as shown in the embodiment of the present application. Figure 8 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 8 Take a processor 10 as an example.

[0095] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0096] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0097] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0098] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0099] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0100] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It can be understood that the computer, processor, microprocessor controller, or programmable hardware includes a storage component capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0101] The apparatus and units described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0102] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0103] Those skilled in the art will understand that the embodiments of this application can be provided as methods or apparatus. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0104] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, and devices according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0105] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0106] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0107] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0108] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0109] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

[0110] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for training a medical record transfer model, characterized in that, The method includes: Obtain the diagnostic text of the source medical record, encode and map the chief complaint information in the diagnostic text, obtain the corresponding anchor code, and construct a simplified source medical record based on the chief complaint information; A pre-constructed clinical manifestation knowledge graph is obtained, and the anchoring code is input into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; wherein, the entity information in the clinical manifestation knowledge graph is used to represent clinical diagnosis and treatment related attribute information; The anchored encoding, the list of constraint elements, and the simplified source medical records are used as training samples to input into the large language model to obtain the medical record generation model. The medical record generation model is validated based on the diagnostic text, and the medical record generation model is updated according to the validation results to obtain a medical record transfer model.

2. The method according to claim 1, characterized in that, The step of obtaining a pre-constructed clinical manifestation knowledge graph involves inputting the anchored encoding into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements, including: Assign basic weights to each entity in the clinical manifestation knowledge graph; Obtain the frequency of occurrence of source entity information in the source medical record, and update the basic weights based on the frequency of occurrence; If the updated base weight is greater than a preset threshold, the entity information to which the updated base weight belongs will be used as a strong constraint element. The strong constraint elements are obtained based on the anchoring code, and the strong constraint elements are concatenated to obtain the list of strong constraint elements.

3. The method according to claim 1, characterized in that, The process of inputting the anchored encoding, the list of constraint elements, and the simplified source medical records as training samples into a large language model to obtain a medical record generation model includes: A simulated complaint is generated based on a trained large language model; The simulated chief complaint is input into a preset simulated medical record generation model to obtain the medical record generation model.

4. The method according to claim 1, characterized in that, The training method for the large language model is as follows: Obtain the simulated complaint output by the large language model, and obtain the entity coverage rate based on the difference between the entity information in the simulated complaint and the list of constraint elements; Semantic similarity is obtained by comparing the simulated chief complaint with a preset unified medical standard. A composite loss function is constructed based on the entity coverage and the semantic similarity, and the large language model is trained using the composite loss function.

5. The method according to claim 1, characterized in that, The medical record generation model is validated based on the diagnostic text, including: The simulated medical records generated by the medical record generation model are compared with the preset typical clinical manifestation descriptions, and the description similarity is obtained based on the comparison results. Based on the similarity between the diagnostic text and the simulated medical record, the traceability fidelity is obtained; A fusion judgment function is constructed based on the description similarity and the traceability fidelity, and the medical record generation model is verified using the fusion judgment function.

6. The method according to claim 5, characterized in that, Based on the similarity between the diagnostic text and the simulated medical record, the traceability fidelity is obtained, including: Based on the diagnostic text, target text that matches the diagnostic text is found from the simulated medical records to obtain positive similarity; Based on the simulated medical record, target text that matches the simulated medical record is searched from the diagnostic text to obtain reverse similarity; Based on the forward similarity and the reverse similarity, the traceability fidelity is obtained.

7. A method for transferring medical records, characterized in that, The method includes: Obtain the source medical record to be transferred, and input the source medical record to be transferred into the medical record transfer model obtained by the training method described in any one of claims 1-6 to obtain the target medical record.

8. A medical record transfer model training device, characterized in that, The device includes: The source medical record unit is used to obtain the diagnostic text of the source medical record, encode and map the chief complaint information in the diagnostic text, obtain the corresponding anchor code, and construct a simplified source medical record based on the chief complaint information. The list acquisition unit is used to acquire a pre-constructed clinical manifestation knowledge graph, input the anchoring code into the clinical manifestation knowledge graph to obtain a list of strongly constrained elements; wherein, the entity information in the clinical manifestation knowledge graph is used to represent clinical diagnosis and treatment related attribute information; The model generation unit is used to input the anchoring code, the list of constraint elements, and the simplified source medical record as training samples into the large language model to obtain a medical record generation model. The verification unit is used to verify the medical record generation model based on the diagnostic text, and update the medical record generation model according to the verification result to obtain the medical record transfer model.

9. A computer device, characterized in that, include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes the computer instructions to perform the medical record transfer model training method of any one of claims 1 to 6 or the medical record transfer method of claim 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the medical record transfer model training method of any one of claims 1 to 6 or the medical record transfer method of claim 7.

Images