A medical record generation and writing-back method, device, equipment and storage medium

Abstract

The application discloses a medical record generation and writing-back method, device and equipment and a storage medium. The medical record generation and writing-back method comprises the following steps: in the case that a medical record processing request is received, accessing according to a login token, reading medical record data of an initial medical record from an electronic medical record database according to the medical record processing request, decoding word data in the medical record data and converting the word data into medical record text, structurally splitting the medical record text to obtain a head structure and a tail structure, identifying a medical record type of the initial medical record, selecting a corresponding target prompt word from a plurality of preset prompt words according to the medical record type, obtaining patient information, inputting the target prompt word and the patient information into a large language model, generating a medical record main text according to a global mandatory writing specification, and recombining the medical record main text, the head structure and the tail structure to obtain a target medical record. The application can standardize a medical record writing template, unify the format of medical record content and improve the efficiency of medical record checking and sorting.

Description

Technical Field

[0001] This invention relates to the technical field of electronic medical record generation, and in particular to a method, apparatus, device, and storage medium for generating and writing back medical records. Background Technology

[0002] Hospital electronic medical record systems are typically supported by multiple business systems, including HIS, LIS, EMR, and nursing handover systems. Patient basic information, past medical history, allergy risks, medication records, surgical records, examination and test results, nursing handover information, and existing medical records are scattered across different interfaces, views, or databases. When doctors write admission notes, initial progress notes, ward round notes, preoperative summaries, discharge notes, and critical value records, they need to repeatedly search, copy, and organize data across multiple systems, which is inefficient and prone to errors.

[0003] There are many types of electronic medical records, each with its own writing standards and templates. Existing solutions typically use generic prompts, which makes it difficult to consistently generate text that meets the format and content requirements of specific medical record types. This results in the need to view different formats of content when reviewing medical records, reducing the efficiency of medical record review and organization. Summary of the Invention

[0004] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a method for generating and writing back medical records, which can standardize the template for writing medical records, unify the format of medical record content, and improve the efficiency of medical record review and organization.

[0005] The present invention also proposes a medical record generation and write-back device.

[0006] The present invention also proposes a medical record generation and write-back device.

[0007] The present invention also proposes a computer-readable storage medium.

[0008] In a first aspect, one embodiment of the present invention provides a method for generating and writing back medical records, including:

[0009] Upon receiving a medical record processing request, access is granted based on the login token;

[0010] According to the medical record processing request, the medical record data of the initial medical record is read from the electronic medical record database, and the word data in the medical record data is decoded and converted into medical record text;

[0011] The medical record text is structurally decomposed to identify and separate the head structure and tail structure;

[0012] Identify the medical record type of the initial medical record, and select the target prompt word corresponding to the medical record type from multiple preset prompt words according to the medical record type;

[0013] Obtain patient information, and use the target prompt words and patient information as input to the large language model, and call the large language model to generate new medical record text according to the globally enforced writing rules;

[0014] The medical record data is recombined based on the main body, header structure, and tail structure, and then written back and updated to obtain the target medical record.

[0015] The medical record generation and write-back method of this invention has at least the following beneficial effects: Access control is implemented at the request reception stage to prevent unauthorized requests from entering subsequent processing flows, avoiding unauthorized access or tampering of patient medical record data, ensuring the legitimacy of user identities in human-computer interaction scenarios, and improving the overall security of the system. Converting the binary worddata stored in the BLOB field into a plain text format that can be directly processed by the large language model preserves the complete order and structural hierarchy of paragraphs, and transforms the XML data into model-readable text input, providing a data foundation for subsequent structural decomposition and model invocation. By precisely splitting the electronic medical record text into three parts—header, body, and tail—the generation scope of the large language model (body only) and the protection scope during write-back (preserving the head and tail) are clearly defined, effectively preventing the generated content from covering key structural information such as the medical record's title, date, and signature. The selected target prompt word is directly used as the core input of the large language model. The large language model needs to generate new medical record body text according to the rules and format defined by the target prompt word. The identified medical record type is intrinsically related to the split head structure, which can help verify the correctness of the head structure. By automatically invoking the HIS patient information interface and nursing handover interface to obtain multi-source patient data, the system automatically aggregates patient information scattered across multiple systems, eliminating the need for doctors to manually switch systems for searching, copying, and pasting. By retaining the header and footer p elements in the original worddata and only replacing the corresponding p elements in the body text, the system accurately preserves the original electronic medical record XML structure. This updates the medical record text while fully retaining structured elements such as titles, dates, signatures, headers, and footers, effectively avoiding formatting corruption and paragraph attribute loss caused by directly overwriting BLOB content.

[0016] According to other embodiments of the medical record generation and write-back method of the present invention, the medical record data includes an electronic medical record text table, wherein the step of reading the initial medical record data from the electronic medical record database according to the medical record processing request, and decoding and converting the word data in the medical record data into medical record text includes:

[0017] Read the BLOB field of the initial medical record from the electronic medical record text table;

[0018] Locate the tab character after worddata in the BLOB field, and read the 10-digit hexadecimal field after the tab character as the binary data of worddata;

[0019] The binary data is decoded into text content according to the AL32UTF8 character set;

[0020] If the text content includes uwword XML, then extract the text of the c element in each p paragraph of the uwword XML, and merge them by paragraph to obtain the medical record text.

[0021] According to other embodiments of the medical record generation and writing method of the present invention, the step of structurally decomposing the medical record text to identify and separate the header structure and the tail structure includes:

[0022] The header structure is determined by scanning the beginning of the medical record text to identify the header line, date line, and blank line;

[0023] The tail structure is determined by scanning forward from the end of the medical record text to identify the date footer, signature line, administrative field, page number, or hospital name.

[0024] According to other embodiments of the medical record generation and write-back method of the present invention, the step of identifying the medical record type of the initial medical record and selecting a target prompt word corresponding to the medical record type from a plurality of preset prompt words according to the medical record type includes:

[0025] The medical record type was determined by three methods in sequence: regular expression matching, keyword mapping, and low-temperature model classification.

[0026] The target prompt word is obtained by selecting from multiple preset prompt words based on the medical record type.

[0027] According to other embodiments of the medical record generation and writing method of the present invention, the step of acquiring patient information and using the target prompt words and the patient information as input to a large language model includes:

[0028] Call the HIS patient information interface to obtain patient data in JSON format, and then convert the patient data into Markdown format;

[0029] Read the Markdown prompt file corresponding to the target prompt;

[0030] Parse the system prompts and assistant prompts in the Markdown prompt file;

[0031] The system prompts, the assistant prompts, and the patient information are used as inputs to the large language model.

[0032] According to other embodiments of the medical record generation and writing method of the present invention, the step of calling the large language model to generate new medical record text according to the globally enforced writing standard includes:

[0033] Generate the body text corresponding to the medical record text based on the global mandatory writing guidelines, the system prompts, the assistant prompts, and the patient information;

[0034] When the medical record processing request comes from the doctor's workbench, the main text is pushed to the client in real time through Server-Sent Events, and the client caches and concatenates the main texts to obtain the medical record main text.

[0035] When the medical record processing request comes from the HIS integration interface, after the large language model generates the main text, the main text is used as the main text of the medical record.

[0036] According to other embodiments of the medical record generation and write-back method of the present invention, after recombining the medical record text, the header structure, and the tail structure to write back and update the medical record data to obtain the target medical record, the method further includes:

[0037] Record audit information in the audit log table;

[0038] In the audit log table, establish index relationships between time and audit information using the time field and the medical record number field, respectively;

[0039] The medical record generation and write-back operations are traced based on the aforementioned audit log table.

[0040] Secondly, one embodiment of the present invention provides a medical record generation and write-back apparatus, comprising:

[0041] The request receiving module is used to access the system based on the login token when a medical record processing request is received.

[0042] The medical record text conversion module is used to read the initial medical record data from the electronic medical record database according to the medical record processing request, and to decode the word data in the medical record data and convert it into medical record text.

[0043] The medical record text splitting module is used to structurally split the medical record text in order to identify and separate the head structure and the tail structure.

[0044] The medical record type recognition module is used to identify the medical record type of the initial medical record and select the target prompt word corresponding to the medical record type from a plurality of preset prompt words according to the medical record type;

[0045] The medical record text generation module is used to obtain patient information, and use the target prompt words and the patient information as input to the large language model, and call the large language model to generate new medical record text;

[0046] The medical record generation and write-back module is used to recombine the medical record body, header structure, and tail structure, write back and update the medical record data, and obtain the target medical record.

[0047] Thirdly, one embodiment of the present invention provides a medical record generation and write-back device, comprising:

[0048] At least one processor, and,

[0049] A memory communicatively connected to the at least one processor; wherein,

[0050] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the medical record generation and write-back method as described in the first aspect.

[0051] Fourthly, one embodiment of the present invention provides a computer-readable storage medium storing computer-executable instructions for causing a computer to perform the medical record generation and write-back method as described in the first aspect.

[0052] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the description and the accompanying drawings. Attached Figure Description

[0053] Figure 1 This is a schematic flowchart of a specific embodiment of the medical record generation and write-back method in this invention; Figure 2 yes Figure 1 A schematic diagram of a specific embodiment of step 102; Figure 3 yes Figure 1 A schematic diagram of a specific embodiment of step 103; Figure 4 yes Figure 1 A schematic diagram of a specific embodiment of step 104; Figure 5 yes Figure 1 A schematic diagram of a specific embodiment of step 105; Figure 6 yes Figure 1A flowchart illustrating another specific embodiment of step 105; Figure 7 This is a schematic flowchart of another specific embodiment of the medical record generation and write-back method in this invention; Figure 8 This is a block diagram of a specific embodiment of the medical record generation and write-back device in this invention. Figure 9 This is a schematic flowchart of another specific embodiment of the medical record generation and write-back method in this invention.

[0054] Figure 2 yes Figure 1 A schematic diagram of a specific embodiment of step 102;

[0055] Figure 4 yes Figure 1 A schematic diagram of a specific embodiment of step 103;

[0056] Figure 4 yes Figure 1 A schematic diagram of a specific embodiment of step 104;

[0057] Figure 5 yes Figure 1 A schematic diagram of a specific embodiment of step 105;

[0058] Figure 6 yes Figure 1 A flowchart illustrating another specific embodiment of step 105;

[0059] Figure 7 This is a schematic flowchart of another specific embodiment of the medical record generation and write-back method in this invention;

[0060] Figure 8 This is a block diagram of a specific embodiment of the medical record generation and write-back device in this invention.

[0061] Figure 9 This is a schematic flowchart of another specific embodiment of the medical record generation and write-back method in this invention.

[0062] Explanation of reference numerals in the attached figures:

[0063] Request receiving module 801, medical record text conversion module 802, medical record text splitting module 803, medical record type recognition module 804, medical record body text generation module 805, medical record generation and write-back module 806. Detailed Implementation

[0064] The following will describe the concept and technical effects of the present invention clearly and completely with reference to embodiments, so as to fully understand the purpose, features and effects of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention.

[0065] In the description of this invention, if directional descriptions are involved, such as "up," "down," "front," "back," "left," "right," etc., indicating the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, it is only for the convenience of describing the invention and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. If a feature is referred to as "set," "fixed," "connected," or "installed" on another feature, it can be directly set, fixed, or connected to the other feature, or it can be indirectly set, fixed, connected, or installed on the other feature.

[0066] In the description of the embodiments of the present invention, the term "several" means one or more, and the term "multiple" means two or more. The terms "greater than," "less than," and "exceeding" should be understood as excluding the stated number, while the terms "above," "below," and "within" should be understood as including the stated number. The terms "first" and "second" should be understood as distinguishing technical features, and not as indicating or implying relative importance, the number of indicated technical features, or the order of the indicated technical features.

[0067] Hospital electronic medical record systems are typically supported by multiple business systems, including HIS, LIS, EMR, and nursing handover systems. Patient basic information, past medical history, allergy risks, medication records, surgical records, examination and test results, nursing handover information, and existing medical records are scattered across different interfaces, views, or databases. When doctors write admission notes, initial progress notes, ward round notes, preoperative summaries, discharge notes, and critical value records, they need to repeatedly search, copy, and organize data across multiple systems, which is inefficient and prone to errors.

[0068] There are many types of electronic medical records, each with its own writing standards and templates. Existing solutions typically use generic prompts, which makes it difficult to consistently generate text that meets the format and content requirements of specific medical record types. This results in the need to view different formats of content when reviewing medical records, reducing the efficiency of medical record review and organization.

[0069] This invention aims to at least solve one of the technical problems existing in the prior art. To this end, this invention proposes a method for generating and writing back medical records, which can standardize the template for writing medical records, unify the format of medical record content, and improve the efficiency of medical record review and organization.

[0070] Reference Figure 1 , Figure 1 A flowchart illustrating the medical record generation and write-back method in an embodiment of the present invention is shown. In some embodiments, the medical record generation and write-back method may include, but is not limited to, steps 101 to 106:

[0071] Step 101: Upon receiving a medical record processing request, access is granted based on the login token.

[0072] In step 101, the server receives a medical record processing request from the doctor's workbench or the HIS integration interface. This request may carry information such as the hospital number, medical record number, doctor's employee number, medical record type, doctor's writing requirements, dialogue number, or text to be replaced. Upon receiving a medical record processing request, the server performs access control based on a login token. Specifically, after completing authentication on the browser side, the user obtains a JWT login token. The front-end includes this token in the request header of each request, and the server back-end verifies the token's validity, granting access after confirming the user's identity and permissions.

[0073] Step 102: Read the initial medical record data from the electronic medical record database according to the medical record processing request, and decode the word data in the medical record data and convert it into medical record text.

[0074] Step 103: Perform structural decomposition on the medical record text to identify and separate the head structure and tail structure.

[0075] Step 104: Identify the medical record type of the initial medical record, and select the target prompt word corresponding to the medical record type from multiple preset prompt words according to the medical record type.

[0076] Step 105: Obtain patient information, and use the target prompt words and patient information as input to the large language model, and call the large language model to generate new medical record text according to the globally enforced writing rules.

[0077] Step 106: Reorganize the medical record based on the main text, header structure, and footer structure, write back and update the medical record data to obtain the target medical record.

[0078] Steps 101 to 106, as illustrated in this embodiment, implement access control during the request reception stage to prevent unauthorized requests from entering subsequent processing flows, avoid unauthorized access to or tampering of patient medical record data, ensure the legitimacy of user identity in human-computer interaction scenarios, and improve the overall security of the system. The binary worddata stored in the BLOB field is converted into a plain text format that can be directly processed by the large language model. This preserves the complete order and structural hierarchy of paragraphs while making the XML data readable text input for the model, providing a data foundation for subsequent structural decomposition and model invocation. By precisely splitting the electronic medical record text into three parts—header, body, and footer—the generation scope of the large language model (body only) and the protection scope during write-back (preserving the head and footer) are clearly defined, effectively preventing the generated content from covering key structural information such as the medical record's title, date, and signature. The selected target prompt word is directly used as the core input of the large language model. The large language model needs to generate new medical record body text according to the rules and format defined by the target prompt word. The identified medical record type is intrinsically related to the split head structure, which can help verify the correctness of the head structure. By automatically invoking the HIS patient information interface and nursing handover interface to obtain multi-source patient data, the system automatically aggregates patient information scattered across multiple systems, eliminating the need for doctors to manually switch systems for searching, copying, and pasting. By retaining the header and footer p elements in the original worddata and only replacing the corresponding p elements in the body text, the system accurately preserves the original electronic medical record XML structure. This updates the medical record text while fully retaining structured elements such as titles, dates, signatures, headers, and footers, effectively avoiding formatting corruption and paragraph attribute loss caused by directly overwriting BLOB content.

[0079] Reference Figure 2 , Figure 2 This diagram illustrates a flowchart of the medical record generation and write-back method in an embodiment of the present invention. In some embodiments, the medical record data includes an electronic medical record text table. The initial medical record data is read from the electronic medical record database according to the medical record processing request, and the word data in the medical record data is decoded and converted into medical record text. Specifically, this includes, but is not limited to, steps 201 to 204:

[0080] Step 201: Read the BLOB field of the initial medical record from the electronic medical record text table.

[0081] Step 202: Locate the tab marker after worddata in the BLOB field, and read the 10-digit hexadecimal field after the tab marker as the binary data of worddata.

[0082] Step 203: Decode the binary data into text content according to the AL32UTF8 character set.

[0083] Step 204: If the text content includes uwword XML, extract the text of the c element in each p paragraph of uwword XML, and merge them by paragraph to obtain the medical record text.

[0084] In steps 201 to 204 of this embodiment, the server executes an SQL query in the electronic medical record text table (such as the EMR_BL_BL02 table) based on the medical record number of the target medical record carried in the request, locating the BLOB field of the corresponding record row. This BLOB field does not store a single piece of data, but rather a combined structure containing worddata binary data and a length field, specifically in the format: worddata binary data + tab marker (ASCII code 9) + 10-digit hexadecimal length field. By locating the tab marker and reading the 10-digit hexadecimal length field, the worddata binary data can be accurately extracted from the BLOB field, avoiding decoding other irrelevant data in the BLOB field and causing text corruption. By extracting and merging the paragraph text in the uwword XML into plain text, the complete order and structural hierarchy of the paragraphs are preserved, and XML data that was originally unprocessable by large language models is transformed into text input that the model can read.

[0085] It's important to note that the data stored in Oracle BLOB fields includes a length marker, which is appended to the worddata data in a fixed format (tab character + 10 hexadecimal digits) to indicate the precise boundaries of the worddata data. By reading the length marker first and then truncating the data, worddata can be accurately extracted from the BLOB field, avoiding text corruption caused by decoding the length marker or other irrelevant data along with it. uwword XML is a proprietary format for electronic medical record systems. This format uses p / c element structures to mark paragraph boundaries and text fragments within paragraphs. Parsing this structure can losslessly convert XML format to plain text format.

[0086] Reference Figure 3 , Figure 3 The diagram illustrates a flowchart of the medical record generation and write-back method in an embodiment of the present invention. In some embodiments, the medical record text is structurally decomposed to identify and separate the header and tail structures, specifically including but not limited to steps 301 to 302:

[0087] Step 301: Scan the beginning of the medical record text to identify the header line, date line, and blank line to determine the header structure.

[0088] Step 302: Scan forward from the end of the medical record text to identify the date page footer, signature line, administrative fields, page number, or hospital name to determine the tail structure.

[0089] In steps 301 to 302 of this embodiment, the server scans line by line from the first line of the medical record text. The header of the medical record text typically contains multiple lines. The server uses the first line as the header line, and subsequent consecutive non-empty lines as date or information lines. When two or more consecutive empty lines are encountered, the header is considered to have ended, and all scanned non-empty lines and the single empty line in between are considered the header structure. The server then scans line by line upwards from the last line of the medical record text. The footer of the medical record text typically includes the record date, doctor's signature, reviewer's signature, page number, or hospital name. The server identifies lines containing date formats, doctor's signatures, administrative fields, page numbers, or hospital names as the footer structure, and stops scanning the footer when two or more consecutive empty lines are encountered. By combining header and footer scanning, the boundaries between the header and footer in various medical record types can be accurately identified, and the text can be correctly separated even if there are differences in format between different hospitals and different medical record types. The splitting result provides clear operational boundaries for subsequent steps—the large language model only generates the main text content between the header and footer to avoid the model miswriting the header and footer; during the write-back, only the main text is replaced while the original header and footer are retained to ensure the integrity of the medical record format.

[0090] It should be noted that the medical record text in the electronic medical record system follows fixed writing standards, with specific formatting features for the header and footer. The header begins with the medical record type name, followed by the patient's basic information and chief complaint, ending with consecutive blank lines. The footer begins with the date, signature, or administrative field, and can be accurately identified by scanning from the footer forward. By combining forward scanning of the header and reverse scanning of the footer, even minor differences in the header or footer formatting can be accurately identified.

[0091] Reference Figure 4 , Figure 4 A flowchart illustrating the medical record generation and write-back method in an embodiment of the present invention is shown. In some embodiments, identifying the medical record type of the initial medical record and selecting a target prompt word corresponding to the medical record type from a plurality of preset prompt words specifically includes, but is not limited to, steps 401 to 402:

[0092] Step 401: The medical record type is determined by three methods in sequence: regular expression matching, keyword mapping, and low temperature model classification.

[0093] Step 402: Select from multiple preset prompts based on the medical record type to obtain the target prompt.

[0094] Steps 401 to 402, as illustrated in this embodiment, involve: Regular expression matching: The server parses the medical record type identifier from the first line of the medical record text and attempts to match various regular expression patterns sequentially. Keyword mapping: If regular expression matching fails, the server performs matching using a keyword mapping table. This mapping table contains mapping relationships between multiple keyword groups and standardized medical record types. Keywords include the medical record type name itself and its abbreviation. Low-temperature model classification: If both regular expression matching and keyword mapping fail to identify the type, the server calls a large language model to perform classification inference using low-temperature parameters. The first few lines are used as model input, and the model is constrained to select and return only from a preset candidate type list. After determining the medical record type, the server selects the corresponding target prompt word from multiple preset prompt words based on that type. Each medical record type corresponds to an independent Markdown prompt word file, with file names corresponding one-to-one with the medical record type, and is stored in the server's prompts directory. The three-tiered progressive recognition method improves the accuracy and fault tolerance of medical record type identification—regular expression matching is fast, keyword mapping has broad coverage, and model classification serves as a fallback solution to handle boundary cases without explicit keywords. Based on the identified specific medical record type, corresponding specialized prompt words are loaded. Compared to using general prompt words, this allows the large language model to generate text according to the writing conventions, paragraph structure, and content requirements of specific medical record types, effectively reducing template mismatches and formatting issues. The target prompt words selected in this step are directly used in the model input construction of step five of claim 1.

[0095] It should be noted that the regular expression pattern includes patterns such as "type + date + subtype", "date + doctor + type", and "date + type". Candidate types include admission records, initial progress notes, ward round records, preoperative summaries, preoperative discussion records, daily progress notes, discharge records, difficult case discussion records, resuscitation records, critical value records, consultation records, etc.

[0096] Reference Figure 5 , Figure 5 The diagram illustrates a flowchart of the medical record generation and write-back method in an embodiment of the present invention. In some embodiments, patient information is acquired, and the target prompt words and patient information are used as input to a large language model, specifically including but not limited to steps 501 to 504:

[0097] Step 501: Call the HIS patient information interface to obtain patient data in JSON format and convert the patient data into Markdown format.

[0098] Step 502: Read the Markdown prompt file corresponding to the target prompt.

[0099] Step 503: Parse the system prompts and assistant prompts in the Markdown prompt file.

[0100] Step 504: Use system prompts, assistant prompts, and patient information as input to the large language model.

[0101] In steps 501 to 504 of this embodiment, the server first calls the HIS patient information interface to obtain patient data in JSON format. The server converts the JSON data into Markdown format, converting each object or array element into a Markdown second-level heading and list item. Simultaneously, the server calls the nursing handover interface to obtain nursing Markdown information, merging the Markdown converted from the HIS patient data with the nursing Markdown information to form complete patient data. The server reads the Markdown prompt file corresponding to the target prompt word, and uses the parsed system prompt words, assistant prompt words, and merged patient data as input to the large language model. By automatically calling the HIS patient information interface and the nursing handover interface to obtain multi-source patient data, automatic aggregation of patient information scattered across multiple systems is achieved, eliminating the need for doctors to manually switch systems for searching, copying, and pasting. The unified conversion of JSON format patient data into Markdown format provides structured contextual information for model input. Separate management of system prompt words and assistant prompt words improves the maintainability and configurability of the prompt words.

[0102] It should be noted that the Markdown prompt file adopts the format of YAML front matter + Markdown body. The front matter contains the system_prompt field (system prompt), and the Markdown body is the assistant prompt. The system prompt defines the role of the large language model (such as "You are a professional internist") and task boundaries; the assistant prompt defines the output format and content requirements.

[0103] Reference Figure 6 , Figure 6 This diagram illustrates a flowchart of the medical record generation and writing-back method in an embodiment of the present invention. In some embodiments, the process of calling a large language model to generate new medical record text according to globally enforced writing standards includes, but is not limited to, steps 601 to 603:

[0104] Step 601: Generate the main text corresponding to the medical record text based on the globally mandatory writing guidelines, system prompts, assistant prompts, and patient information.

[0105] Step 602: When a medical record processing request comes from the doctor's workbench, the main text is pushed to the client in real time through Server-Sent Events, and the client caches and concatenates the main texts to obtain the medical record main text.

[0106] Step 603: When the medical record processing request comes from the HIS integration interface, after the large language model generates the main text, the main text is used as the medical record text.

[0107] In steps 601 to 603 of this embodiment, the server submits system prompts, assistant prompts, and patient information to the large language model interface. The large language model generates the corresponding body text for the medical record text, token by token or segment by segment, based on the role constraints of the system prompts, the format constraints of the assistant prompts, and the content of the patient information. During the generation process, the large language model is constrained by the structural decomposition result in claim 3, and its output is limited to covering only the body text, excluding the header and footer structures. When the medical record processing request comes from the doctor's workbench, the server pushes the generated text segments to the client in real time via Server-Sent Events (SSE) during the generation process. After receiving each text segment, the client caches and concatenates the segments locally. Upon receiving the generation completion event (done event), the client uses the concatenated complete text as the medical record body. When the medical record processing request comes from the HIS integration interface, the server caches and concatenates the text content returned by the large language model segment by segment locally. After the large language model completes all generation, the server uses the complete text content as the medical record body. By differentiating request sources and using different return methods, doctors on the workbench experience a smooth, streaming interactive experience, while the HIS integration side receives a complete synchronous response. Both methods share the same large language model generation logic, maintaining consistency in processing logic. Streaming push notifications allow doctors to begin reviewing generated text content without waiting for complete generation, significantly improving work efficiency.

[0108] It should be noted that when the medical record processing request originates from the doctor's workbench, the doctor can see the generated text content in real time during the AI ​​generation process and can begin reviewing it without waiting for the complete generation. When the medical record processing request originates from the HIS integration interface, the HIS system, as the external caller, receives the complete medical record text, which can be directly used for subsequent processing.

[0109] Reference Figure 7 , Figure 7 A flowchart illustrating the medical record generation and write-back method in an embodiment of the present invention is shown. In some embodiments, after recombining the medical record text, header structure, and footer structure, writing back and updating the medical record data to obtain the target medical record, the medical record generation and write-back method further includes, but is not limited to, steps 701 to 703:

[0110] Step 701: Record audit information in the audit log table.

[0111] Step 702: In the audit log table, establish index relationships between time and audit information based on the time field and the medical record number field, respectively.

[0112] Step 703: Trace the medical record generation and write-back operations based on the audit log table.

[0113] In steps 701 to 703 of this embodiment, when the medical record processing request originates from the doctor's workbench, the server sends a Server-Sent Events completion event to the client, notifying the client that the write-back operation has been successfully completed. Upon receiving the done event, the client can update the interface state without needing to retransmit the complete medical record text, thus saving network bandwidth. When the medical record processing request originates from the HIS integration interface, the HIS system, as the external caller, needs to obtain the complete operation result for subsequent processing. Therefore, the server encapsulates the new medical record text written back to the database and the modified record sequence number into a complete JSON response and returns it to the HIS system. Simultaneously with returning the result, the server inserts a complete audit record into the audit log table. By distinguishing the request source and returning different response contents, the doctor's workbench, having already obtained the text via streaming, only needs to confirm the event to update the interface, avoiding repeated transmission of text data; the HIS integration side obtains the usable operation result through the complete response, and both calling methods obtain the required return content.

[0114] It should be noted that the audit log table is stored in an SQLite database. By establishing an audit log table containing fields such as method, path, status_code, duration_ms, caller_ip, api_key, request_body, response_body, blbh, zyhm, ysgh, old_text, new_text, and error, complete information recording and precise traceability of every medical record generation and write-back operation are achieved. When disputes arise regarding the content of a medical record, the process can be quickly traced back to the relevant operational step to identify the responsible party. By recording the complete content of the original and new medical record texts, the differences before and after rewriting can be compared and analyzed, providing data support for medical quality assessment.

[0115] Additionally, refer to Figure 9 , Figure 9 A flowchart illustrating the medical record generation and write-back method in an embodiment of the present invention is shown. In some embodiments, the medical record generation and write-back method specifically includes:

[0116] S1, the server receives a medical record processing request. The request originates from the doctor's workbench or the HIS integration interface; the doctor's workbench uses a login token for access, while the HIS integration interface verifies the request via the X-API-KEY header. The request may carry the hospital number zyhm, medical record number blbh, doctor's ID ysgh, medical record type record_type, doctor's writing requirements requirement, conversation number conversation_id, or the text to be replaced.

[0117] S2, the server reads electronic medical record data. For a medical record list request, the server queries PORTAL_EMR.V_EMR and returns the hospital number, medical record category, doctor, creation time, and medical record number; for a medical record content request, the server reads the BLOB from EMR_BL_BL02, locates the tab mark after worddata, reads the subsequent 10-digit hexadecimal length field, and decodes the worddata using AL32UTF8; if the content is uwword XML, it extracts the text of the c elements in each p paragraph and merges them into plain text by paragraph.

[0118] S3, the server splits the medical record structure. The server scans the header, date line, and blank line at the beginning of the medical record to determine the header; then it identifies the date footer, signature line, administrative fields, page number, or hospital name from the end backward to determine the tail; the content between the header and tail is the body. The splitting result is used to ensure that the AI ​​only processes the body text.

[0119] S4, the server identifies the medical record type. The server prioritizes parsing patterns such as "type + date + subtype", "date + doctor + type", and "date + type" from the first line of the medical record, and then obtains standardized types such as admission record, initial progress note, initial attending physician ward round record, chief physician ward round record, preoperative summary, preoperative discussion record, daily progress note, 24-hour admission and discharge record, discharge record, difficult case discussion record, preoperative ward round record, resuscitation record, critical value record, and consultation through keyword mapping; if regular expressions and keywords cannot be recognized, a low-temperature model is used for classification, and only candidate type names are allowed to be returned.

[0120] S5, the server obtains the patient context. The server calls the HIS patient interface to obtain patient information such as basic, risk, allergy, medication, surgery, exam, lab, and EMR, and converts the JSON fields into Markdown format; at the same time, it calls the nursing handover interface to obtain nursing Markdown; the two are combined and used as the patient's basic information.

[0121] S6, Server constructs model input. The server reads the corresponding Markdown prompt file according to the standardized medical record type, parses the system_prompt in the front matter and the assistant prompt in the body, and appends a globally enforced writing standard, requiring the model to directly output the final medical record body that can be copied and used, not to repeat the prompt words, and not to output Markdown.

[0122] In S7, the server calls the large language model to generate the main text. For write and rewrite requests in the doctor's workbench, the server uses Server-Sent Events to stream and return answer, status, header, tail, done, or error events. For the HIS AI medical record interface, the server collects the complete model output before entering the database write-back process. The think tag in the model output is buffered and removed, and is not returned to the client.

[0123] S8, the server performs a structure-fidelity write-back. The server uses the model-generated result as new_body; if the original medical record is uwword XML, it retains the first header_lines p elements and the last tail_lines p elements, and only replaces the middle body paragraphs with the p / c elements corresponding to new_body; then it replaces the old worddata with the new worddata, recalculates the 10-digit hexadecimal length field, and synchronously updates BL02 and the existing BLXG modification traces.

[0124] S9, the server returns the results and audits them. The server returns the new medical record text, the modified record number, or the SSE completion event; the audit module records the request path, status code, time consumed, caller IP, hospital number, medical record number, doctor's employee number, original text, new text, response text, and error information.

[0125] In some embodiments, the medical record structure fidelity write-back process includes:

[0126] The electronic medical record content is actually stored in a worddata BLOB. Directly overwriting the entire section with AI output would alter the original title, date, signature, and XML paragraph attributes. This invention employs a "split-generate only the main text-reconstruct" method to write back the data. The original worddata XML is read, and all p elements within the section are obtained. The first p elements are retained based on `header_lines`, and the last p elements are retained based on `tail_lines`. The AI-generated main text is split according to line breaks, and each line is converted into a new p / c element. The text content is then XML-escaped. The section is reconstructed in the order of "original header p element + new main text p element + original tail p element". The old worddata is replaced with the new worddata, and the worddata byte length field is updated simultaneously; if BLXG records exist, the latest modification trace BLOB is updated synchronously.

[0127] Medical record creation and template selection processing:

[0128] When the server creates a new medical record, it first parses the medical record template profile based on the semantic record_type. The profile records the medical record family, BLLB, BLLX, DLLB, MBLB, MBBH, DLJ prefixes, title style, and title suffix. Medical records in the course of treatment use short records with date headings, while document records use a template heading structure.

[0129] The server allocates the BLBH and audit log number using the BSOFT_PRO_GET_MAX method in the PORTAL library, inserts BL01 metadata into the EMR library, then selects a structurally complete record containing BL02 for the same patient, BLLB, and MBBH as the clone source, and copies its worddata container to the new record. If the incoming text is provided, only the text portion in the clone container is replaced and the header is refreshed. When saving is canceled, the server does not delete the record, but instead updates the active lock SDZT in EMR_BL_BLSD from 1 to 0.

[0130] HIS Integration Interface Processing:

[0131] This invention provides an Integration interface for external systems, and all / integration / * paths are authenticated via X-API-KEY. After clicking the AI ​​Medical Record button on the medical record interface, the HIS can call POST / integration / emr / ai-write, and the server will perform a synchronous process of reading the medical record, querying the hospital number, querying the medical record type, rewriting the text using AI, writing back to the database with structural fidelity, and returning the complete content.

[0132] Doctor's workbench interaction processing:

[0133] The doctor's workbench includes a medical record editing page, an AI medical record writing page, and an integration platform page. The medical record editing page allows users to search for medical records by hospital number, read content, perform manual replacements, AI rewriting, and text-level write-back. The AI ​​medical record writing page saves the session state using `conversation_id`: the initial request identifies the type of medical record to be written and asks the doctor to supplement patient information; after supplementation, patient data is retrieved, prompts are loaded, and the record is generated in a streaming manner; subsequent requests can continue to refine the output based on the previous round or switch to a new medical record type.

[0134] Audit and prompt word management:

[0135] The auditing module creates the `audit_logs` table in SQLite, recording fields such as `method`, `path`, `status_code`, `duration_ms`, `caller_ip`, `api_key`, `request_body`, `response_body`, `blbh`, `zyhm`, `ysgh`, `old_text`, `new_text`, and `error`, and indexes it by time and case number. The platform page supports statistics on total call volume, daily call volume, weekly call volume, number of successful and failed calls, average execution time, endpoint distribution, and trends over the past seven days.

[0136] The prompt management module scans Markdown files in the medical_writer / prompts directory, providing interfaces for listing, reading, and updating. After a prompt is updated, the prompt reading cache is cleared, ensuring the latest prompt is used immediately for the next generation or rewrite. The API Key management module generates an emr_prefix key, performs SHA-256 hashing on the key, stores only the prefix, and allows for key revocation or deletion.

[0137] In addition, this application also discloses a medical record generation and write-back device, please refer to... Figure 8 , Figure 8 This invention discloses a module block diagram of a medical record generation and write-back device according to one embodiment. In some embodiments, the request receiving module 801, the medical record text conversion module 802, the medical record text splitting module 803, the medical record type identification module 804, the medical record body text generation module 805, and the medical record generation and write-back module 806 are all communicatively connected.

[0138] Upon receiving a medical record processing request, the request receiving module 801 accesses the system using a login token. The medical record text conversion module 802 reads the initial medical record data from the electronic medical record database according to the request, decodes the worddata in the medical record data, and converts it into medical record text. The medical record text splitting module 803 performs structural splitting on the medical record text to identify and separate the header and footer structures. The medical record type identification module 804 identifies the medical record type of the initial medical record and selects a target prompt word corresponding to the medical record type from multiple preset prompt words. The medical record text generation module 805 acquires patient information and uses the target prompt word and patient information as input to a large language model, then calls the large language model to generate new medical record text. The medical record generation and write-back module 806 recombines the medical record text, header structure, and footer structure, writes back and updates the medical record data, obtaining the target medical record.

[0139] The request receiving module 801 performs access control during the request receiving phase to prevent unauthorized requests from entering subsequent processing flows, avoiding unauthorized access to or tampering of patient medical record data, ensuring the legitimacy of user identities in human-computer interaction scenarios, and improving the overall security of the system. The medical record text conversion module 802 converts the binary worddata stored in the BLOB field into a plain text format that can be directly processed by the large language model. This preserves the complete order and structural hierarchy of paragraphs while making the XML data readable text input for the model, providing a data foundation for subsequent structural splitting and model invocation. The medical record text splitting module 803 precisely splits the electronic medical record text into three parts: header, body, and footer. This clearly defines the generation scope of the large language model (body only) and the protection scope during write-back (retaining the header and footer), effectively preventing the generated content from covering key structural information such as the medical record's title, date, and signature. The target prompt words selected by the medical record type recognition module 804 are directly used as the core input of the large language model. The large language model needs to generate new medical record text according to the rules and format defined by the target prompt words. The recognized medical record type is intrinsically related to the split header structure, which can help verify the correctness of the header structure. The medical record text generation module 805 automatically calls the HIS patient information interface and nursing handover interface to obtain multi-source patient data, realizing the automatic aggregation of patient information scattered in multiple systems, without requiring doctors to manually switch systems to search, copy, and paste. The medical record generation and write-back module 806 retains the header and footer p elements in the original worddata and only replaces the corresponding p elements in the text, achieving accurate preservation of the original electronic medical record XML structure. It updates the medical record text content while fully preserving structured elements such as title, date, signature, header, and footer, effectively avoiding format damage and paragraph attribute loss caused by directly overwriting BLOB content.

[0140] The operation process of the medical record generation and write-back device in this embodiment is specifically described above. Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 as well as Figure 7 The steps S101 to S106, S201 to S204, S301 and S302, S401 and S402, S501 to S504, S601 to S603 and S701 to S703 of the method for generating and writing back medical records are not described in detail here.

[0141] Another embodiment of the present invention discloses a medical record generation and write-back device, comprising: at least one processor, and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform actions such as... Figure 1 Control method steps S101 to S106 Figure 2 Control method steps S201 to S204 Figure 3 Control method steps S301 and S302 Figure 4 Control method steps S401 and S402 Figure 5 Control method steps S501 to S504 Figure 6 The control method steps S601 to S603 and Figure 7 The control method includes steps S701 to S703, which are methods for generating and writing back medical records.

[0142] Another embodiment of the present invention discloses a computer-readable storage medium, the storage medium comprising: storing computer-executable instructions for causing a computer to perform... Figure 1 Control method steps S101 to S106 Figure 2 Control method steps S201 to S204 Figure 3 Control method steps S301 and S302 Figure 4 Control method steps S401 and S402 Figure 5 Control method steps S501 to S504 Figure 6 The control method steps S601 to S603 and Figure 7 The control method includes steps S701 to S703, which are methods for generating and writing back medical records.

[0143] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0144] It will be understood by those skilled in the art that all or some of the steps and systems in the methods disclosed above can be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components can be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software can be distributed on a computer-readable medium, which can include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0145] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments, and various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention. Furthermore, the embodiments of the present invention and the features thereof can be combined with each other unless otherwise specified.

Claims

1. A method for generating and writing back medical records, characterized in that, include: Upon receiving a medical record processing request, access is granted based on the login token; According to the medical record processing request, the medical record data of the initial medical record is read from the electronic medical record database, and the word data in the medical record data is decoded and converted into medical record text; The medical record text is structurally decomposed to identify and separate the head structure and tail structure; Identify the medical record type of the initial medical record, and select the target prompt word corresponding to the medical record type from multiple preset prompt words according to the medical record type; Obtain patient information, and use the target prompt words and patient information as input to the large language model, and call the large language model to generate new medical record text according to the globally enforced writing rules; The medical record data is recombined based on the main body, header structure, and tail structure, and then written back and updated to obtain the target medical record.

2. The method for generating and writing back medical records according to claim 1, characterized in that, The medical record data includes an electronic medical record text table. The step of reading the initial medical record data from the electronic medical record database according to the medical record processing request, and decoding and converting the word data in the medical record data into medical record text, includes: Read the BLOB field of the initial medical record from the electronic medical record text table; Locate the tab character after worddata in the BLOB field, and read the 10-digit hexadecimal field after the tab character as the binary data of worddata; The binary data is decoded into text content according to the AL32UTF8 character set; If the text content includes uwword XML, then extract the text of the c element in each p paragraph of the uwword XML, and merge them by paragraph to obtain the medical record text.

3. The method for generating and writing back medical records according to claim 1, characterized in that, The step of structurally decomposing the medical record text to identify and separate the header and tail structures includes: The header structure is determined by scanning the beginning of the medical record text to identify the header line, date line, and blank line; The tail structure is determined by scanning forward from the end of the medical record text to identify the date footer, signature line, administrative field, page number, or hospital name.

4. The method for generating and writing back medical records according to claim 1, characterized in that, The step of identifying the medical record type of the initial medical record and selecting a target prompt word corresponding to the medical record type from a plurality of preset prompt words includes: The medical record type was determined by three methods in sequence: regular expression matching, keyword mapping, and low-temperature model classification. The target prompt word is obtained by selecting from multiple preset prompt words based on the medical record type.

5. The method for generating and writing back medical records according to claim 1, characterized in that, The process of acquiring patient information and using the target prompt words and the patient information as input to the large language model includes: Call the HIS patient information interface to obtain patient data in JSON format, and then convert the patient data into Markdown format; Read the Markdown prompt file corresponding to the target prompt; Parse the system prompts and assistant prompts in the Markdown prompt file; The system prompts, the assistant prompts, and the patient information are used as inputs to the large language model.

6. The method for generating and writing back medical records according to claim 5, characterized in that, The process of calling the large language model to generate new medical record text according to the globally enforced writing rules includes: Generate the body text corresponding to the medical record text based on the global mandatory writing guidelines, the system prompts, the assistant prompts, and the patient information; When the medical record processing request comes from the doctor's workbench, the main text is pushed to the client in real time through Server-Sent Events, and the client caches and concatenates the main texts to obtain the medical record main text. When the medical record processing request comes from the HIS integration interface, after the large language model generates the main text, the main text is used as the main text of the medical record.

7. The method for generating and writing back medical records according to claim 1, characterized in that, After recombining the medical record data according to the main body, header structure, and tail structure, writing back and updating the medical record data to obtain the target medical record, the method further includes: Record audit information in the audit log table; In the audit log table, establish index relationships between time and audit information using the time field and the medical record number field, respectively; The medical record generation and write-back operations are traced based on the aforementioned audit log table.

8. A medical record generation and write-back device, characterized in that, include: The request receiving module is used to access the system based on the login token when a medical record processing request is received. The medical record text conversion module is used to read the initial medical record data from the electronic medical record database according to the medical record processing request, and to decode the word data in the medical record data and convert it into medical record text. The medical record text splitting module is used to structurally split the medical record text in order to identify and separate the head structure and the tail structure. The medical record type recognition module is used to identify the medical record type of the initial medical record and select the target prompt word corresponding to the medical record type from a plurality of preset prompt words according to the medical record type; The medical record text generation module is used to obtain patient information, and use the target prompt words and the patient information as input to the large language model, and call the large language model to generate new medical record text; The medical record generation and write-back module is used to recombine the medical record body, header structure, and tail structure, write back and update the medical record data, and obtain the target medical record.

9. A medical record generation and write-back device, characterized in that, include: At least one processor, and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the medical record generation and write-back method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions for causing a computer to perform the medical record generation and write-back method as described in any one of claims 1 to 7.

Images