Patient file generation method and device and medium

Abstract

The invention discloses a patient file generation method and device applied to clinical tests and a medium, and relates to the technical field of data processing. The method comprises the steps that field metadata and text description information are typeset and combined through a visual editor, a patient file structure module is constructed, visual self-defined editing is achieved, and different medical fields and scene requirements can be rapidly met. By constructing the converted patient data, integration of multi-source data is realized, so that when the structured template is modified, traversing and searching of each data source are not needed, the data integration rate is improved, batch patient archive generation of multi-target patient IDs is supported, the patient archive generation efficiency is improved, the structured template can be stored in a template library after being designed, and the generation efficiency of the patient archives is improved. And when other application scenes need, the information can be directly called, so that the time consumption and the error probability of newly creating the patient file are reduced while the unified management of the structured template is realized. Therefore, the generation efficiency and quality of the patient file are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, device and medium for generating patient records. Background Technology

[0002] Patient profiles, as core medical documents in the healthcare field, integrate key data such as basic patient information, medical history, treatment records, and examination and test results. They serve as crucial evidence for clinical diagnosis and treatment, scientific research analysis, multidisciplinary collaboration, and medical quality control. However, current practices in using patient profiles in the medical field have some shortcomings. For example, existing patient profile templates are mostly in fixed formats, requiring professional technical personnel to adjust the underlying format and modify the template when adapting them to different medical fields and treatment scenarios, which is time-consuming and labor-intensive. Existing patient profiles only support clinical trial teams manually integrating multi-source data from a single patient, significantly increasing the non-therapeutic workload of clinical trial teams. Furthermore, existing patient profile templates are mostly stored in a scattered manner, lacking a unified template library for management. This means that when a new template needs to be created for a new scenario, the template format and data association rules must be designed from scratch, which is also time-consuming.

[0003] In summary, existing methods for generating patient profiles have some shortcomings in terms of template flexibility, data integration efficiency, batch processing capabilities, and template management, resulting in poor efficiency and quality of existing patient profile generation. Therefore, providing a method for generating patient profiles to improve efficiency and quality and reduce the workload of clinical trial teams is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a method, device, and medium for generating patient profiles. The main purpose is to improve the efficiency and quality of patient profile generation, and reducing the workload of clinical trial teams is an urgent problem to be solved.

[0005] In a first aspect, embodiments of this application provide a method for generating patient records, the method comprising: obtaining patient data corresponding to multiple target patients from multiple data sources; The patient data was converted to a data standard according to the CDISC standard to obtain the converted patient data. Synchronize the field metadata of different diagnostic scenarios in the transformed patient data to the visual editor; Based on the visual editor, the field metadata and text description information are formatted and combined to obtain several patient file structure modules; An initial structured template is constructed based on the aforementioned patient file structure modules, and data association rules are set for the target positions where field data needs to be inserted in the initial structured template, so as to bind the corresponding field data in the transformed patient data. Convert the initial structured template containing the data association rules into a JSON-formatted structured template; Based on the target patient ID and the data association rules, extract the corresponding field data from the transformed patient data; The field data is populated into the structured template to generate the patient profile corresponding to the target patient ID.

[0006] In one implementation of this application, converting the initial structured template containing the data association rules into a JSON-formatted structured template includes: Identify the text content, formatting style, and data association rules in the initial structured template; The text content, the format style, and the data association rules are converted into JSON data according to a preset format to obtain the structured template in JSON format. The data association rules adopt a three-part association rule, which includes three key pieces of information: Domain, table name, and column name, used to identify the location of each field data in the data warehouse storing the converted patient data.

[0007] In one implementation of this application, extracting the corresponding field data from the transformed patient data based on the target patient ID and the data association rules includes: The corresponding three-segment association rule is determined based on the target patient ID; Based on the three-segment association rules, the target table and target column of the corresponding Domain in the data warehouse are located; Extract the field data from the target column; The step of filling the field data into the structured template to generate the patient file corresponding to the target patient ID includes: The patient's file is obtained by integrating the field data with the text content and the format style.

[0008] In one implementation of this application, setting data association rules for the target positions where field data needs to be inserted in the initial structured template to bind the corresponding field data in the transformed patient data includes: Receive the identifier of the data association rule input by the user at the target location; The identifier is parsed into a three-part association rule consisting of a preset Domain, a preset table, and a preset column; Based on the metadata index of the transformed patient data, verify whether the preset Domain, preset table and preset column in the three-segment association rule correspond to the registered data path; If the verification is successful, a real-time mapping channel is established at the target location with the corresponding field data in the converted patient data to bind the corresponding field data in the converted patient data.

[0009] In one implementation of this application, the method includes: Obtain semantic prompts input by the user, and extract keywords from the semantic prompts; The target structured template is generated by combining the structure of similar structured templates in the structured template library with the data association rules using the AIGC model.

[0010] In one implementation of this application, after generating the patient file corresponding to the target patient ID, the method further includes: In response to the user's selected export format command, load the corresponding document conversion engine; The patient's file is converted into a target format document using the document conversion engine.

[0011] In one implementation of this application, after generating the patient file corresponding to the target patient ID, the method further includes: In response to the update and publication event of the converted patient data, the patient profile is updated based on the updated patient data; By comparing the changes in field data in the patient's file and the updated patient's file, the changed data is obtained; The changed data is distinguished by color, and the types of changed data include newly added field data, deleted field data, and modified field data; The patient records are incrementally stored in association with the updated patient records to form a version iteration chain.

[0012] In one implementation of this application, the method further includes: When the field data is clicked in the patient's file, the traceability identifier associated with the field data is retrieved; Based on the traceability identifier, the original field data certificate is retrieved. The original field data certificate includes the data source type, original collection timestamp, and historical parameters of the field data.

[0013] Secondly, embodiments of this application also provide a patient record generation device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: obtain patient data corresponding to multiple target patients from multiple data sources; perform data standard conversion on the patient data according to the CDISC standard to obtain converted patient data; synchronize field metadata for different diagnostic scenarios in the converted patient data to a visual editor; based on the visual editor, format and combine the field metadata and text description information to obtain several patient record structure modules; construct an initial structured template according to the several patient record structure modules, and set data association rules for the target positions in the initial structured template where field data needs to be inserted, so as to bind the corresponding field data in the converted patient data; convert the initial structured template with the set data association rules into a JSON format structured template; extract the corresponding field data from the converted patient data according to the target patient ID and the data association rules; and fill the field data into the structured template to generate a patient record corresponding to the target patient ID.

[0014] Thirdly, embodiments of this application also provide a non-volatile computer storage medium for generating patient records, storing computer-executable instructions. These instructions are configured to: obtain patient data corresponding to multiple target patients from multiple data sources; perform data standard conversion on the patient data according to the CDISC standard to obtain converted patient data; synchronize field metadata for different diagnostic scenarios in the converted patient data to a visual editor; format and combine the field metadata and text description information based on the visual editor to obtain several patient record structure modules; construct an initial structured template based on the several patient record structure modules, and set data association rules for the target positions in the initial structured template where field data needs to be inserted, to bind the corresponding field data in the converted patient data; convert the initial structured template with the set data association rules into a JSON-formatted structured template; extract the corresponding field data from the converted patient data according to the target patient ID and the data association rules; and fill the field data into the structured template to generate a patient record corresponding to the target patient ID.

[0015] This application provides a method, device, and medium for generating patient profiles, comprising: acquiring patient data corresponding to multiple target patients from multiple data sources; performing data standard conversion on the patient data according to the CDISC standard to obtain converted patient data; synchronizing the field metadata of different diagnostic scenarios in the converted patient data to a visual editor; formatting and combining the field metadata and text description information based on the visual editor to obtain several patient profile structure modules; constructing an initial structured template based on the several patient profile structure modules, and setting data association rules for the target positions where field data needs to be inserted in the initial structured template to bind the corresponding field data in the converted patient data; converting the initial structured template with the set data association rules into a JSON format structured template; extracting the corresponding field data from the converted patient data according to the target patient ID and the data association rules; and filling the field data into the structured template to generate a patient profile corresponding to the target patient ID. The method offers the following advantages: By using a visual editor to format and combine field metadata and textual descriptions, a patient profile structure module is constructed, enabling visual and customizable editing. This allows for rapid adaptation to different medical fields and scenarios. By constructing a structured template containing data association rules, modifications to the patient profile structure module can be automated without manual field updates, based on these rules. Furthermore, by constructing a CDISC standard dataset (i.e., the transformed patient data), multi-source data integration is achieved. Modifying the structured template eliminates the need to traverse and search through each data source, improving data integration efficiency. The CDISC standard dataset conforms to the CDISC standard. This method is executed for at least one target patient, enabling batch generation of patient profiles with multiple target patient IDs, thus improving patient profile generation efficiency. The structured template, once designed, can be stored in a template library and directly accessed in other application scenarios, reducing the time and error probability of creating new patient profiles while maintaining unified management of the structured templates. Therefore, this application improves the efficiency and quality of patient profile generation, reducing the workload of clinical medical staff, medical researchers, and clinical trial teams. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart of a patient record generation method provided in this application embodiment; Figure 2 This is a schematic diagram of the internal structure of a patient record generation device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] This application provides a method, device, and medium for generating patient profiles to achieve the following objectives: improve the efficiency and quality of patient profile generation, and reduce the workload of clinical trial teams.

[0019] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0020] Figure 1 This is a flowchart illustrating a patient record generation method provided in an embodiment of this application. Figure 1 As shown in the embodiment of this application, a method for generating patient records is provided. This method is applied in clinical trials and specifically includes the following steps: Step 101: Obtain patient data corresponding to multiple target patients from multiple data sources; In some embodiments, the patient data includes, but is not limited to, clinical trial data associated with multiple target patients.

[0021] Step 102: Perform data standard conversion on the patient data according to the CDISC standard to obtain the converted patient data; It's important to understand that the Clinical Data Exchange Standards Association (CDISC) is dedicated to providing standardized data exchange and management guidelines for clinical research, covering multiple stages including data collection, analysis, and submission. Typically, non-standardized data is converted into standardized, programmable fields based on project requirements and a standardized dictionary. For example, gender identifiers such as "male," "male," "1," and "Man" are standardized to "Male," thus achieving the data standardization conversion.

[0022] In some embodiments, when performing step 102, the following implementation methods may also be used, including but not limited to: importing multi-source raw data, i.e., patient data from different data sources; using built-in CDISC standard verification rules in the system to perform format verification and standardization conversion on the multi-source raw data; generating a standardized dataset containing a unique patient identifier (Patient ID), storing it in a data warehouse, and supporting real-time data updates and version management. This generates a structured dataset, i.e., the converted patient data, providing a unified data foundation for subsequent data matching. The multi-source data may be EDC data, and the CDISC standard may be SDTM or ADaM.

[0023] Step 103: Synchronize the field metadata of different diagnostic scenarios in the transformed patient data to the visual editor; In some embodiments, the visual editor is used to provide a drag-and-drop interface, allowing writers to build template structures by dragging and dropping modules (such as basic information, past medical history, examination results, etc.), and set format attributes such as module titles, font styles, and spacing to achieve the layout and combination of field metadata and text description information.

[0024] Step 104: Based on the visual editor, the field metadata and text description information are formatted and combined to obtain several patient file structure modules; It is important to understand that the patient file structure module is a sub-module that makes up the patient file. The field metadata is used to limit the types of data content that can be filled in the form controls, and the text description information is used to form the static text annotation section in the patient file structure module.

[0025] Step 105: Construct an initial structured template based on the aforementioned patient file structure modules, and set data association rules for the target positions where field data needs to be inserted in the initial structured template, so as to bind the corresponding field data in the transformed patient data; In some embodiments, the data association rule adopts a three-segment data association, also known as a three-segment association rule, which is used to establish the association relationship between the structured template and the structured dataset by the writer inputting an association rule in the format of "Domain.A table.B column" (such as "DM.PATIENT.NAME" to associate the NAME column data of the PATIENT table in the DM domain) at the position where data needs to be inserted in the initial structured template.

[0026] In some embodiments, the custom templates, i.e. the structured templates, are classified and stored according to dimensions such as medical field (e.g., internal medicine, surgery) and scenario type (e.g., diagnosis, follow-up, scientific research), and support retrieval by keywords (e.g., "tumor" "chronic disease"), while recording the usage frequency and version iteration history of the templates.

[0027] Step 106: Convert the initial structured template containing the data association rules into a JSON-formatted structured template; Step 107: Extract the corresponding field data from the transformed patient data according to the target patient ID and the data association rules; Step 108: Fill the field data into the structured template to generate the patient file corresponding to the target patient ID.

[0028] This application provides a patient record generation method that uses a visual editor to drag and drop and combine field metadata to construct a patient record structure module. This enables visual custom editing and can quickly adapt to the needs of different medical fields and scenarios. By constructing a structured template containing data association rules, modifications to the patient record structure module can be automated without manual updates of field data, based on the data association rules. By constructing a CDISC standard dataset, i.e., the converted patient data, multi-source data integration is achieved. This eliminates the need to traverse and search through each data source when modifying the structured template, improving the data integration rate. This method is executed for at least one target patient, enabling batch generation of patient records for multiple target patient IDs, thus improving the efficiency of patient record generation. The structured template, once designed, can be stored in a template library and directly called when needed in other application scenarios. This achieves unified management of the structured template while reducing the time consumption and error probability of creating new patient records. Therefore, this application improves the efficiency and quality of patient record generation and reduces the workload of clinical medical staff, medical researchers, and clinical trial teams.

[0029] As a refinement of the above embodiments, when performing step 106 to convert the initial structured template with the data association rules into a JSON-formatted structured template, the following implementation methods can also be adopted, but are not limited to: identifying the text content, format style, and data association rules in the initial structured template; converting the text content, format style, and data association rules into JSON data according to a preset format to obtain the JSON-formatted structured template, wherein the data association rules adopt a three-segment association rule, and the three-segment association rule includes three key pieces of information, namely Domain, table name, and column name, which are used to identify the location of each field data in the data warehouse storing the converted patient data.

[0030] To more intuitively demonstrate the structured template in JSON format, this application provides corresponding code examples, the details of which are as follows: { / / Template unique identifier, used for internal system reference and version management "template_id": "TPL_001", / / Template name, for user identification (e.g., displayed when a doctor selects a template). "template_name": "Internal Medicine Outpatient Patient Template", / / Global style configuration: Defines the basic layout style for the entire document "style": { "font": "SimSun", / / Font type "font_size": 12, / / Font size (unit: points) "alignment": "left" / / Overall alignment (left alignment) }, / / The template content consists of multiple "modules", each module representing a logical block. "content": [ { / / Module title, corresponding to the "Patient Profile Structure Module" generated by dragging and dropping in the visual editor. "module": "Basic Information", / / List of specific elements within this module "elements": [ { / / Plain text element (static content, no data binding) "type": "text", "content": "Patient Name:" }, { / / Dynamic data elements: Field values ​​need to be retrieved from the data warehouse "type": "data", / / Three-part association rule: Domain.table.column, used to locate the data source. / / DM = Demographic domain, PATIENT = Table name, NAME = Field name "rule": "DM.PATIENT.NAME", / / This field is rendered with a bold style. "style": "bold" }, { "type": "text", "content": "Age:" }, { "type": "data", / / Bind the age field; the system will verify the validity of this rule through the metadata index. "rule": "DM.PATIENT.AGE" / / If no style is specified, the global style configuration will be inherited. } ] }, { "module": "Check Results", "elements": [ { / / Table-type elements are used to display structured data with multiple rows and columns. "type": "table", / / Table header definition (static text) "header": ["Inspection Items", "Inspection Time", "Results", "Reference Range"], / / Data association rules for each column of the table (corresponding to the table header in order) / / LB = Laboratory Test Domain, LAB_TEST = Data Table, with each field corresponding to the project name, date, result value, and reference range. "data_rules": [ "LB.LAB_TEST.TEST_NAME", "LB.LAB_TEST.TEST_DATE", "LB.LAB_TEST.RESULT", "LB.LAB_TEST.REF_RANGE" ] During rendering, the system will query all records in the transformed patient data that match these rules. / / And dynamically populate the table (supports multiple rows, such as multiple record checks). } ] } ] } As a refinement of the above embodiments, when performing step 107, which involves extracting the corresponding field data from the transformed patient data based on the target patient ID and the data association rules, the following implementation methods can also be adopted, but are not limited to: determining the corresponding three-segment association rules based on the target patient ID; locating the target table and target column of the corresponding domain in the data warehouse based on the three-segment association rules; extracting the field data from the target column; and filling the field data into the structured template to generate the patient profile corresponding to the target patient ID, which includes: integrating the field data with the text content and the format style to obtain the patient profile. Based on the JSON data generated after template parsing, the corresponding patient's association data is extracted from the standardized dataset in combination with the Patient ID, completing the automatic matching and integration of data and template content. When the structured template or patient profile is modified (such as adjusting the module order or modifying the text style), it is only necessary to re-parse the template to generate new JSON data, and the data matching rules remain unchanged. There is no need to re-query the data, and the updated Patient Profile can be generated quickly.

[0031] In some embodiments, the method of this application allows writers to select the presentation method of the Patient Profile according to their needs. Specifically, the data layout format can be automatically adjusted according to the user's selection to generate a corresponding archive document. Presentation methods include: text presentation, where the integrated data is displayed in paragraph-style text format, suitable for rapid reading scenarios; table presentation, where structured data is displayed in tabular format, suitable for data comparison and analysis scenarios; and hybrid presentation, which combines text descriptions with tabular data, suitable for scenarios such as multidisciplinary consultations and detailed medical records. Writers can select the presentation method through the interface to achieve real-time system preview and generate the corresponding document.

[0032] In some embodiments, when extracting the corresponding field data from the transformed patient data according to the target patient ID and the data association rules, the following implementation methods can also be used, but are not limited to: receiving a batch-imported list of target patient IDs; creating data extraction tasks in parallel for each target patient ID in the list; scheduling and executing data extraction according to task priority queues; immediately pushing the extracted field data to the filling pipeline when any task is completed; dynamically monitoring the status of each task and updating the batch generation progress and abnormal task alarms in real time on the interface. That is, the method of this application supports importing multiple patient ID lists, and the system batch-executes the data matching, integration and presentation configuration process to generate the patient profile of all patients with one click, which greatly improves the processing efficiency of large-scale scenarios. The specific process can also be implemented in the following ways, but are not limited to: importing an Excel or CSV file containing multiple patient IDs; selecting a target template, i.e., the structured template and presentation method; the system batch-triggers the data matching, integration and format conversion process to generate the file document corresponding to each patient ID, i.e., the patient file; supporting the storage or download of all documents by patient ID category. The target template is determined according to the clinical scenario and specialty needs. Specialized diseases require matching specialty-specific templates. For example: Cardiology: the template should include fields such as electrocardiogram results, cardiac function classification, dynamic blood pressure monitoring, and antithrombotic drug usage records; Obstetrics and Gynecology: the template should differentiate between sub-templates for prenatal checkups, delivery, and postpartum follow-up, and include specialty information such as gestational age, fetal heart rate monitoring, delivery method, and neonatal score; Psychiatry: the template should include modules such as psychiatric symptom assessment scales (e.g., PANSS, SDS), medication adherence, and social function assessment.

[0033] As a refinement of the above embodiments, when performing step 105, which involves setting data association rules at the target location where field data needs to be inserted into the initial structured template to bind the corresponding field data in the converted patient data, the following implementation methods can also be adopted, but are not limited to: receiving the identifier of the data association rule input by the user at the target location; parsing the identifier into a three-part association rule consisting of a preset Domain, a preset table, and a preset column; verifying, based on the metadata index of the converted patient data, whether the preset Domain, preset table, and preset column in the three-part association rule correspond to a registered data path; if the verification shows that they exist, establishing a real-time mapping channel at the target location with the corresponding field data in the converted patient data to bind the corresponding field data in the converted patient data.

[0034] To facilitate understanding of the above embodiments, this application provides an exemplary description, including: when a user enters a data association rule identifier (such as "DM.patient.AGE") at a specified location in the patient file template, the system will parse it into a three-part rule consisting of a Domain, a table name, and a column name, and verify whether the rule corresponds to a registered valid data path based on the metadata index of the converted patient data; if the verification is successful, a real-time mapping channel with the corresponding field in the data warehouse will be automatically established at that location, thereby achieving accurate binding and dynamic filling of field data. The metadata index is a structured "data map" built by the system after the CDISC standard conversion is completed. It is used to record and manage the organizational structure and legality information of the converted patient data. Specifically, it includes: a list of registered legal domains (such as DM, LB, etc., and the use of undefined domains is prohibited), valid data tables associated with each domain (such as the DM domain containing patient tables, subject tables, etc.), and standard fields contained in each table (such as the patient table containing AGE, SEX, etc.). This index serves as the verification basis for the three-part association rule (Domain.table.column) to verify whether the data path entered by the user actually exists and conforms to the preset specifications.

[0035] As a refinement of the above embodiments, the method may also adopt, but is not limited to, the following implementation methods, for example: obtaining semantic prompt words input by the user and extracting keywords from the semantic prompt words; generating a target structured template by combining the structure of similar structured templates in the structured template library with the data association rules through the AIGC model.

[0036] In some embodiments, the process of generating target structured templates based on the AIGC model can also be implemented in, but is not limited to, the following ways: The writer inputs a prompt (e.g., "Patient Profile template for post-breast cancer follow-up, including basic information, surgical records, chemotherapy regimen, and tumor marker test results"); the system extracts key information from the prompt (e.g., "breast cancer" in the medical field, "post-breast cancer follow-up" in the scenario, module requirements, etc.); the AIGC model combines similar template structures and data association rules in the template library to generate an initial template; the writer can fine-tune the AI-generated template (e.g., adjust the module order, modify the style), and save it to the template library after confirmation. By training the AIGC model based on historical template data in the template library, writers can trigger AI to automatically generate Patient Profile templates adapted to specific scenarios simply by inputting prompts, reducing the manual cost of template creation.

[0037] In some embodiments, the process of generating target structured templates based on the AIGC model can also be implemented in, but is not limited to, the following ways: when a user triggers an AIGC generation command, the system dynamically identifies the generation mode selected by the user; if the blank generation mode is selected, the system converts the text requirements input by the user into a structured template framework based on a natural language command parsing engine; if the reference generation mode is selected, the system automatically extracts the layout features and field distribution patterns of the reference document and generates a new template with a preset similarity; if the optimization generation mode is selected, the system compares the existing template with the CDISC best practice standard through a difference analysis module, outputs optimization suggestions, and automatically reconstructs the template structure; after any mode is completed, the generated template is loaded into a visual editor in real time for the user to adjust.

[0038] As a refinement of the above embodiments, after generating the patient file corresponding to the target patient ID, the method may also adopt, but is not limited to, the following implementation methods, for example: in response to the user's selected export format instruction, loading the corresponding document conversion engine; and converting the patient file into a target format document based on the document conversion engine.

[0039] In some embodiments, by integrating mainstream document format conversion engines, preset style mapping rules for different formats are implemented (such as converting fonts and table styles in the system to standard PDF / DOCX styles). Batch export is supported, with files categorized and packaged by format. Naming rules are automatically added to exported files (e.g., "PatientID_Name_Generation Date.Format") for easy document management. By receiving and integrating structured patient records (i.e., patient files) after data matching and integration, the system automatically performs format conversion and generates downloadable document files based on the user-selected export format (PDF, DOCX, etc.), ensuring that the style of the exported files matches the system preview style.

[0040] In some embodiments, the system application adapted to the method of this application adopts a responsive design to adapt to different terminal screen sizes. The web version supports direct access via a browser, and the APP version supports iOS and Android systems. Structured data is transmitted through standardized interfaces to ensure real-time data synchronization between the two ends. A built-in high-efficiency search engine supports fuzzy search and precise filtering, and filtering conditions can be saved as frequently used templates for reuse. By providing access points for viewing and operating the Patient Profile on both the APP and web ends, the structured data is displayed synchronously on different terminals, and interactive operations such as searching, filtering, and sorting are supported, ensuring consistency and smoothness of multi-terminal operations.

[0041] As a refinement of the above embodiments, after generating the patient profile corresponding to the target patient ID, the method may also adopt, but is not limited to, the following implementation methods, for example: in response to the update and release event of the converted patient data, update the patient profile based on the updated patient data; compare the changes in field data in the patient profile and the updated patient profile to obtain changed data; distinguish the changed data by color, and the types of changed data include added field data, deleted field data, and modified field data; incrementally store the patient profile and the updated patient profile together to form a version iteration chain. It can be understood that when the data source changes, or the statistical algorithm changes and modifies the patient data, the patient profile needs to be updated synchronously with the update of the patient data.

[0042] As a refinement of the above embodiments, the method may also be implemented in, but is not limited to, the following ways: when the field data is clicked in the patient file, the traceability identifier associated with the field data is retrieved; the original field data certificate is retrieved based on the traceability identifier, the original field data certificate including the data source type, original collection timestamp and historical parameters of the field data.

[0043] In some embodiments, the system application adapted to the method of this application also includes two sub-functions: data version management and data traceability. The data version management sub-function takes data release as the trigger node, automatically generates a new version Patient Profile and records the complete version iteration history; the data traceability sub-function associates a complete data source link with each field, so that the source of the data can be found and its destination can be traced. Data Version Management: Version generation is triggered by the release of converted patient data. Specifically, after patient data cutoff and standardization, and after QC approval, the patient profile is updated based on the updated patient data. The process is as follows: After each patient data cutoff, the system automatically captures the current CDISC standard dataset and generates a new version of the Patient Profile using the currently used template. The version number can be named according to the rule "Release Date_Sequence Number" (e.g., 20240520_V1) for easy tracing of the corresponding data cutoff point. Incremental storage is used to save only the differences between versions, reducing storage costs. A visual version comparison interface is provided, clearly displaying differences through color coding (blue for new additions, red for deletions, and green for modifications). Clicking the "Modified" icon directly retrieves the original data before modification and the dataset information at the corresponding release point. Data Traceability: During the data processing stage, a unique traceability identifier is added to each data field, linking it to the original data source information. When the profile is generated, the identifier is embedded in the corresponding field, and clicking it displays the complete traceability chain in a pop-up window. In some embodiments, the implementation process of the method of this application further includes: collecting multi-source raw patient data, standardizing it according to the CDISC standard through the data processing module to generate a structured dataset containing Patient IDs, and storing it in a data warehouse; the writer builds a template structure through the visual editor of the template management module, sets "three-segment" association rules at the locations where data needs to be inserted, and saves it to the template library after completion; or inputs prompt words through the AIGC template generation module, generates a template by AI, and then fine-tunes and confirms it; the system calls the template parsing module to read the target template, extract the text content, style information and "three-segment" rules, and convert it into structured JSON data; inputs the target Patient ID (single or batch), and the data matching and integration module extracts the corresponding patient data from the data warehouse according to the rules in the JSON data and integrates it with the template content; selects the presentation method (text / table / mixed), and the presentation method configuration module automatically adjusts the format to generate a Patient Profile. Documents; in batch scenarios, all patient documents can be output in batches; the archives can be viewed through the APP or Web, and the structured data operation functions can be used to search, filter, and sort; exported to PDF, DOCX, and other formats as needed; if version comparison is required, the version traceability function can be triggered to view change details; when data is questionable, the source of the data can be located through the traceability function.

[0044] To facilitate understanding of the implementation process of the above embodiments, this application provides an exemplary description in conjunction with an application scenario, including: batch processing multi-source follow-up data (including outpatient medical records, imaging examinations, laboratory tests, medication records, etc.) of 20 patients; generating structured follow-up files that conform to hospital MDT discussion standards, including fixed modules (patient basic information, postoperative recovery indicators, comparison of examination results, medication adherence, and suggestions for further treatment); the files support collaborative viewing by doctors from multiple departments on the web, PDF export, and data traceability to ensure data accuracy. Specifically: The system automatically captures multi-source raw data from 20 target patients through an interface, including: outpatient follow-up records and medication lists from the Hospital Information System (HIS); chest CT image reports from the Picture Archiving and Communication System (PACS); tumor marker (such as CEA and SCC) test results from the Laboratory Information System (LIS); and postoperative recovery records and past medical history from the Electronic Medical Record System (EMR).

[0045] The data processing module initiates automated processing, primarily based on the CDISC (Clinical Data Exchange Standards Association) standard to standardize and transform multi-source data: First, it unifies data formats, converting unstructured text (such as handwritten follow-up records by doctors) and semi-structured tables (such as test results) exported from different systems into structured fields; second, it standardizes terminology coding, assigning ICD-10 codes (such as C34.901 for lung adenocarcinoma), LOINC codes (such as CEA: 10981-3) to test items, and ATC codes to drugs; third, it cleans data, removing duplicate data (such as duplicate uploaded CT reports) and completing missing key fields (such as follow-up time and test instrument model).

[0046] After processing, a structured dataset containing "Patient ID + standardized fields + coding information" is generated (e.g., Patient ID: LC2024001, with fields including "follow-up date, CEA value, CT result, current medication name, etc."). This dataset is automatically stored in the system data warehouse, and a data processing completion receipt is generated, triggering the system to enter the preparation state for the next step of template creation.

[0047] The system automatically reads the standardized list of lung cancer follow-up-related fields (such as tumor markers, imaging results, medication records, etc.) from the data warehouse and synchronizes them to the visual editor of the template management module, providing field references for manually created templates.

[0048] The clinical trial team at the lung cancer center (the writers) created the template using a web-based visual editor: They built the template structure, creating five fixed modules based on MDT discussion needs: basic patient information, postoperative recovery indicators, comparison of examination results, medication adherence, and treatment recommendations. They set up a three-part association rule, binding data warehouse fields to the locations where data needs to be inserted. For example, in the "Tumor Marker Results" section, they set the rule: [Data Source: LIS system, Corresponding Field: CEA value, Matching Condition: Patient ID matches and follow-up time is 6 months post-surgery]. In the "CT Imaging Conclusion" section, they set the rule: [Data Source: PACS system, Corresponding Field: Chest CT results, Matching Condition: Patient ID matches and examination time is 6 months post-surgery]. They added fixed text content, such as the template title "Lung Cancer Postoperative 6-Month Follow-up Patient Profile" and explanatory text for each module (e.g., "Comparison of Examination Results: Comparison of changes in indicators before and 6 months post-surgery").

[0049] If the clinical trial team does not need to build from scratch, they can input the prompt words into the AIGC template generation module: "Generate a 6-month follow-up Patient Profile template for lung cancer surgery, including basic patient information, postoperative recovery indicators, tumor marker results, chest CT conclusions, and medication record modules. Data association positions need to be reserved, and it should conform to CDISC standards and the hospital's MDT discussion format." After the AI ​​automatically generates the initial template, the clinical trial team only needs to fine-tune the "three-segment" association rules (such as adding specific field matching conditions) to complete the template creation.

[0050] Once the template is created, click "Save to Template Library". The system will automatically assign a unique template ID to the template (e.g., Temp-LC-FU-001) and synchronize the template's structure information and list of association rules to the pending queue of the template parsing module, awaiting subsequent parsing instructions.

[0051] After receiving the "batch generate archives" instruction from the clinical trial team, the system automatically calls the template parsing module to read the target template with ID Temp-LC-FU-001 from the template library. The input data includes the template's text content (fixed text), style information (font, module layout, table format), and "three-part" association rules. The template parsing module automatically decomposes and transforms the input template information: ① Extracts text and style, splits the fixed text in the template into modules, and records the layout format of each module (e.g., "Patient Basic Information" is a first-level heading with bold font, and test results are displayed in a table); ② Parses the "three-part" rules, converting the rules described in natural language into machine-recognizable structured instructions, such as parsing "match CEA value 6 months post-surgery" as "where follow-up time is '6 months post-surgery' and field name is 'CEA value'"; integrates it into JSON data, and generates a standardized JSON file with the structure of "template ID, module list, text / style of each module, association rule instructions, and data source identifier".

[0052] The parsed JSON data (including the full structured information of the template) is automatically sent to the data matching and integration module. At the same time, the system verifies the integrity of the JSON data (such as whether any association rules are missing and whether the data source is valid). After the verification is successful, the system sends an "executionable data matching" signal to the data matching and integration module.

[0053] The clinical trial team entered the Patient IDs of 20 patients (e.g., LC2024001 to LC2024020) in batches into the system. The data matching and integration module received the input list of Patient IDs, read the JSON data generated in the previous step (including association rule instructions), and retrieved the standardized dataset of the corresponding patients from the data warehouse.

[0054] The module performs automated matching and integration according to the following logic: Batch matching: Based on the association rule instructions in the JSON, data is matched one by one by Patient ID. For example, matching Patient ID=LC2024001 with corresponding data such as "CEA value 6 months postoperatively (5.2 ng / mL)" and "Chest CT scan shows 'postoperative changes in the right lung, no obvious signs of recurrence'"; Data filling: The matched patient data is accurately inserted into the reserved field positions in the template JSON, while retaining the template's fixed text and style information; Conflict handling: If a patient's data in a certain field is missing (e.g., a certain test item was not performed), the system automatically fills in the "Data not collected" flag and marks it as "to be supplemented"; If there is data abnormality (e.g., CEA value exceeds the normal range), it is automatically marked as "abnormal" and highlighted.

[0055] After integration, 20 sets of personalized structured data (each corresponding to one patient) with "Patient ID, template content, and populated data" are generated. This data is stored according to the template module and is simultaneously passed to the presentation configuration and generation module, waiting for format adjustment and document generation.

[0056] The presentation configuration module receives the 20 personalized structured data sets passed in the previous step, and reads the presentation parameters selected by the clinical trial team (by checking "hybrid presentation" through the system interface, i.e., a combination of text and tables; batch output mode).

[0057] The module automatically performs format adjustment and document generation: It optimizes the format according to the "hybrid presentation" requirement, displaying patient basic information and treatment suggestions in text format, and tumor marker results and examination time comparisons in tabular format, ensuring clear layout that conforms to MDT reading habits; it batch generates documents, generating complete Patient Profile documents for each of the 20 patients in Patient ID order, while adding a unified hospital logo, template ID, and generation timestamp to each document; quality verification automatically checks the document format integrity (e.g., whether there are missing modules, whether tables are complete) and data filling accuracy (e.g., whether Patient ID matches data). After successful verification, the system batch generates 20 Patient Profile documents, stores them in the system document library, and simultaneously generates a "Batch generation complete" notification pushed to the clinical trial team's account. The document data is synchronized to the multi-terminal access module, supporting subsequent viewing and operation.

[0058] It is important to understand that the method described in this application can be applied to both constructing a Patient Profile and a Narrative. Both are core documents in clinical research reports and key materials for regulatory review. They are related and complementary, with the core differences being their presentation format, information dimensions, and usage scenarios. Simply put: a Patient Profile is a standardized data dashboard for the patient (presenting only data), while a Narrative is a complete interpretation of the clinical story based on that data (similar to a case file describing the patient's condition). Furthermore, the patient profiles mentioned in this application can also be replaced with case narrative documents.

[0059] Regarding the technical solution of this application, there are some alternative approaches in the prior art, but all of them have obvious defects and cannot fully meet the requirements. Specific comparisons are as follows: Comparative Example 1: Manually Linking Data Using an Excel Template: A fixed template is set in Excel, and data sources are linked using function formulas. Drawbacks: Template modifications require manual adjustment of function formulas, which is prone to errors; it cannot generate multiple patient files in batches; the presentation method is limited, and the data linking rules are restricted by Excel's functionality, making it difficult to adapt to complex medical scenarios.

[0060] Comparative Example 2: Custom Forms in Traditional Electronic Medical Record Systems: Some electronic medical record systems support custom forms as Patient Profile templates. Drawbacks: Forms are tightly bound to the data source; template modifications require reconfiguration of the data interface, resulting in poor flexibility; batch generation functionality is lacking; AIGC template generation is not supported, leading to low efficiency in template reuse and creation.

[0061] Comparative Example 3: General Document Generation Tool: This tool uses Word templates and Excel data sources to achieve simple data filling. Limitations: It only supports basic text filling and cannot handle complex module structure adjustments; its data association rules are simple and cannot adapt to CDISC standard datasets; it lacks batch generation and classification management functions, resulting in insufficient adaptability to large-scale scenarios.

[0062] Comparative Example 4: AI Directly Generates Patient Profile Text: Patient profiles are generated directly from patient data using AIGC, using natural language descriptions. Drawbacks: Lack of structured template support leads to disorganized data presentation; inability to precisely control module content and style; difficulty in tracing the data source of the generated results, failing to meet the requirements for traceability of medical data.

[0063] Comparative Example 5: Simple Electronic Records System: Some systems support the generation and viewing of basic patient records, but only support single-format export and lack multi-terminal adaptability; data is stored as unstructured text, making efficient filtering and sorting impossible; lacking version management and data traceability functions, it is difficult to locate the cause when data errors occur, resulting in insufficient medical security.

[0064] The above five comparative examples demonstrate that none of the existing alternatives can simultaneously achieve the core requirements of template customization, automatic data matching, batch generation, flexible presentation, and intelligent template management. The technical solution of this application is irreplaceable.

[0065] In summary, the embodiments of this application can achieve the following effects, including: 1. By using a visual editor to drag and drop and combine field metadata, a patient profile structure module can be constructed, enabling visual custom editing. This allows for rapid adaptation to different medical fields and scenarios. By constructing a structured template containing data association rules, modifications to the patient profile structure module can be automated without manual field updates, based on these rules. Furthermore, by constructing a CDISC standard dataset (i.e., the transformed patient data), multi-source data integration is achieved. Modifying the structured template eliminates the need to traverse and search through each data source, improving data integration efficiency. This method is executed for at least one target patient, enabling batch generation of patient profiles for multiple target patient IDs, thus improving patient profile generation efficiency. The structured template, once designed, can be stored in a template library and directly accessed in other application scenarios, reducing the time and error probability of creating new patient profiles while maintaining unified management of the structured templates. Therefore, this application improves the efficiency and quality of patient profile generation, reducing the workload of clinical medical staff, medical researchers, and clinical trial teams.

[0066] 2. Supports free switching between text, table, and mixed presentation modes without the need for manual data format reconstruction, meeting the usage needs of different scenarios and improving document usability.

[0067] 3. The multi-format export function adapts to diverse needs such as archiving, sharing, and editing. The dual-platform viewing of the APP and Web breaks the limitations of the scene, allowing the clinical trial team to access patient record information anytime, anywhere, and improving the convenience of work.

[0068] 4. Structured data supports search, filter, and sort functions, which greatly improves data retrieval efficiency; the version comparison function with data cutoff as the node clearly presents the data change trajectory at different cutoff points through "New", "Delete", and "Modified" identifiers; the automatic source tracing function can quickly locate the source of data errors, providing strong support for medical quality control and data traceability.

[0069] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a patient record generation device, the structure of which is as follows: Figure 2 As shown.

[0070] Figure 2 This is a schematic diagram of the internal structure of a patient record generation device provided in an embodiment of this application. Figure 2 As shown, the device includes: At least one processor 201; And a memory 202 that is communicatively connected to at least one processor; The memory 202 stores instructions executable by at least one processor 201, which in turn executes the instructions to enable the processor 201 to: acquire patient data corresponding to multiple target patients from multiple data sources; perform data standard conversion on the patient data according to the CDISC standard to obtain converted patient data; synchronize the field metadata of different diagnostic scenarios in the converted patient data to a visual editor; format and combine the field metadata and text description information based on the visual editor to obtain several patient file structure modules; construct an initial structured template based on the several patient file structure modules, and set data association rules for the target positions in the initial structured template where field data needs to be inserted to bind the corresponding field data in the converted patient data; convert the initial structured template with the set data association rules into a JSON format structured template; extract the corresponding field data from the converted patient data according to the target patient ID and the data association rules; and fill the field data into the structured template to generate the patient file corresponding to the target patient ID.

[0071] Some embodiments of this application provide corresponding to Figure 1A non-volatile computer storage medium stores computer-executable instructions, which are configured to: obtain patient data corresponding to multiple target patients from multiple data sources; perform data standard conversion on the patient data according to the CDISC standard to obtain converted patient data; synchronize the field metadata of different diagnostic scenarios in the converted patient data to a visual editor; format and combine the field metadata and text description information based on the visual editor to obtain several patient file structure modules; construct an initial structured template based on the several patient file structure modules, and set data association rules for the target positions where field data needs to be inserted in the initial structured template to bind the corresponding field data in the converted patient data; convert the initial structured template with the set data association rules into a JSON format structured template; extract the corresponding field data from the converted patient data according to the target patient ID and the data association rules; and fill the field data into the structured template to generate a patient file corresponding to the target patient ID.

[0072] The various embodiments in this application 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 embodiments for IoT devices and media 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.

[0073] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0074] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. 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.

[0075] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products 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 flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0076] 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.

[0077] 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.

[0078] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0079] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0080] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0081] 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.

[0082] The above description is merely an embodiment of this application and is not intended to limit 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 principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for generating patient records, characterized in that, The method includes: Obtain patient data corresponding to multiple target patients from multiple data sources; The patient data was converted to a data standard according to the CDISC standard to obtain the converted patient data. Synchronize the field metadata of different diagnostic scenarios in the transformed patient data to the visual editor; Based on the visual editor, the field metadata and text description information are formatted and combined to obtain several patient file structure modules; An initial structured template is constructed based on the aforementioned patient file structure modules, and data association rules are set for the target positions where field data needs to be inserted in the initial structured template, so as to bind the corresponding field data in the transformed patient data. Convert the initial structured template containing the data association rules into a JSON-formatted structured template; Based on the target patient ID and the data association rules, extract the corresponding field data from the transformed patient data; The field data is populated into the structured template to generate the patient profile corresponding to the target patient ID.

2. The method according to claim 1, characterized in that, The step of converting the initial structured template containing the data association rules into a JSON-formatted structured template includes: Identify the text content, formatting style, and data association rules in the initial structured template; The text content, the format style, and the data association rules are converted into JSON data according to a preset format to obtain the structured template in JSON format. The data association rules adopt a three-part association rule, which includes three key pieces of information: Domain, table name, and column name, used to identify the location of each field data in the data warehouse storing the converted patient data.

3. The method according to claim 2, characterized in that, The step of extracting the corresponding field data from the transformed patient data based on the target patient ID and the data association rules includes: The corresponding three-segment association rule is determined based on the target patient ID; Based on the three-segment association rules, the target table and target column of the corresponding Domain in the data warehouse are located; Extract the field data from the target column; The step of filling the field data into the structured template to generate the patient file corresponding to the target patient ID includes: The patient's file is obtained by integrating the field data with the text content and the format style.

4. The method according to claim 2, characterized in that, The step of setting data association rules for the target positions where field data needs to be inserted in the initial structured template, in order to bind the corresponding field data in the transformed patient data, includes: Receive the identifier of the data association rule input by the user at the target location; The identifier is parsed into a three-part association rule consisting of a preset Domain, a preset table, and a preset column; Based on the metadata index of the transformed patient data, verify whether the preset Domain, preset table and preset column in the three-segment association rule correspond to the registered data path; If the verification is successful, a real-time mapping channel is established at the target location with the corresponding field data in the converted patient data to bind the corresponding field data in the converted patient data.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: Obtain semantic prompts input by the user, and extract keywords from the semantic prompts; The target structured template is generated by combining the structure of similar structured templates in the structured template library with the data association rules using the AIGC model.

6. The method according to claim 5, characterized in that, After generating the patient profile corresponding to the target patient ID, the method further includes: In response to the user's selected export format command, load the corresponding document conversion engine; The patient's file is converted into a target format document using the document conversion engine.

7. The method according to claim 6, characterized in that, After generating the patient profile corresponding to the target patient ID, the method further includes: In response to the update and publication event of the converted patient data, the patient profile is updated based on the updated patient data; By comparing the changes in field data in the patient's file and the updated patient's file, the changed data is obtained; The changed data is distinguished by color, and the types of changed data include newly added field data, deleted field data, and modified field data; The patient records are incrementally stored in association with the updated patient records to form a version iteration chain.

8. The method according to claim 7, characterized in that, The method further includes: When the field data is clicked in the patient's file, the traceability identifier associated with the field data is retrieved; Based on the traceability identifier, the original field data certificate is retrieved. The original field data certificate includes the data source type, original collection timestamp, and historical parameters of the field data.

9. A patient record generation device, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform a patient record generation method as described in any one of claims 1-8.

10. A computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, a patient record generation method as described in any one of claims 1-8 is implemented.

Images