An automated underwriting assessment method, apparatus and system

Abstract

This application discloses an automated underwriting assessment method, apparatus, and system, solving the technical problem that existing underwriting systems cannot directly perform semantic understanding and automated decision-making on unstructured medical examination report images, resulting in an inability to form a complete closed-loop processing flow. The method includes: acquiring medical examination report image data and associated insurance application information; performing character recognition on the images to obtain text data; converting the text data into formatted input data according to underwriting medical terminology mapping rules; inputting the formatted input data into a large language model to obtain structured medical examination indicator data containing examination items and their values ​​or descriptions; and logically matching the structured medical examination indicator data with a pre-configured underwriting rule knowledge base to generate underwriting conclusion data. This application achieves a complete, systematic closed-loop processing flow from image input to conclusion output, improving the system's automated parsing and decision-making capabilities for unstructured report data.

Description

Technical Field

[0001] This application relates to the field of insurance science and technology, and in particular to an automated underwriting assessment method, apparatus and system. Background Technology

[0002] Underwriting, as a crucial means of risk control during the underwriting stage for insurance companies, plays a vital role in the sound operation of these companies through its standardization, structuring, professionalization, and intelligentization. In the manual underwriting stage, methods such as medical examinations, investigations, and requesting supplementary information are typically used to screen clients for health risks. Medical examinations, in particular, are a key means of assessing client health. They are usually provided voluntarily by the client or arranged by the insurance company for the insured to undergo examinations at designated medical institutions or hospitals. The company uses the results of the medical examination report to determine whether to reject, approve, or increase the insured amount, among other underwriting conclusions. It can be said that medical examinations are one of the most core and important tasks in the underwriting process.

[0003] Currently, the existing underwriting technology process is relatively simple, such as Figure 1 As shown, sales staff enter insurance application information and submit underwriting applications. The core business system matches customer information and uses a regulatory engine to assess the application. Some applications are automatically approved, while others, after triggering certain factors, are transferred to a manual underwriting queue. The majority of these manual underwriting applications are medical underwritings, which heavily rely on manual processing. This results in inefficiency, slow speed, and a poor customer experience in the current underwriting model. With increasing business volume, the workload for underwriters also increases. The large amount of manual processing affects the timeliness of policy underwriting and reduces customer satisfaction. Given the rapid development of artificial intelligence and the digital economy, digital transformation is imperative for insurance companies. Innovative methods for automating the entire underwriting process based on customer medical examination reports are an inevitable trend for business development.

[0004] However, current processes still suffer from significant drawbacks in underwriting scenarios involving medical examination reports, including slow underwriting efficiency, poor customer experience, and high dropout / cancellation rates. The heavy reliance on manual processing has become a bottleneck for large-scale business development. Therefore, there is an urgent need for a method that can automate the entire underwriting process for customer medical examination reports to overcome these shortcomings and achieve intelligent, standardized, and efficient underwriting. Summary of the Invention

[0005] This application discloses an automated underwriting assessment method, apparatus, and system, which solves the problem that existing underwriting systems cannot directly perform semantic understanding and automated decision-making on unstructured medical examination report images, resulting in the need for the processing flow to be interrupted outside the system and the inability to form a closed loop of the entire process.

[0006] In a first aspect, embodiments of this application provide an automated underwriting assessment method, executed by a computer system, comprising the following steps:

[0007] Obtain medical examination report imaging data and related insurance application information;

[0008] The image data of the physical examination report is subjected to character recognition to obtain text data;

[0009] According to the underwriting medical terminology mapping rules, the text data is converted into formatted input data;

[0010] The formatted input data is input into a large language model to obtain structured physical examination index data; the structured physical examination index data includes at least one examination item extracted from the text data and its corresponding value or description;

[0011] The structured medical examination index data is logically matched with a pre-configured underwriting rule knowledge base to generate the underwriting conclusion data.

[0012] In one embodiment, the acquisition of the medical examination report image data is performed based on an application identifier associated with the insurance application information.

[0013] In some embodiments, the application identifier is generated when the insurance application information meets preset conditions, which include at least one of the following: the insured amount exceeds a preset threshold; the insured's age exceeds a preset threshold; there is a specific positive medical history identifier in the health declaration questionnaire; the insured product type is a high-risk category.

[0014] In one embodiment, before performing character recognition processing, the method further includes the step of performing image quality detection and / or serialization sorting processing on the physical examination report image data.

[0015] In one embodiment, before character recognition processing, the method further includes the step of: segmenting the physical examination report image data by department to obtain sub-image data corresponding to different departments; and performing character recognition on each of the sub-image data.

[0016] In one embodiment, the formatted input data includes prompt word templates for guiding the large language model to output the structured physical examination index data according to a predetermined data structure.

[0017] In one embodiment, the underwriting rule knowledge base includes coded decision rules and their corresponding threshold parameters; the logical matching is to compare the numerical values ​​or descriptions in the structured medical examination indicator data with the threshold parameters and execute the decision rules.

[0018] Secondly, embodiments of this application also provide an automated underwriting assessment device for implementing the automated underwriting assessment method described in any embodiment of the first aspect, comprising: an acquisition module for acquiring medical examination report image data and associated insurance application information; a processing module for performing character recognition on the medical examination report image data to obtain text data; and for inputting the formatted input data into a large language model to obtain structured medical examination indicator data; and for logically matching the structured medical examination indicator data with a pre-configured underwriting rule knowledge base to generate underwriting conclusion data; and a determination module for converting the text data into formatted input data according to underwriting medical terminology mapping rules.

[0019] Thirdly, embodiments of this application also provide an automated underwriting assessment system, comprising: an underwriting server, deployed with the apparatus described in the second aspect embodiment, or configured to perform the method described in any one of the first aspect embodiments; a user terminal, communicatively connected to the underwriting server, for providing an interface for inputting insurance application information and a medical examination report image confirmation interface; an image server, for storing and providing the medical examination report image data; and a notification server, for pushing medical examination instruction data containing an application identifier to the user terminal or the medical examination institution system.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in any one of the embodiments of the first aspect.

[0021] Fifthly, embodiments of this application also provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any embodiment of the first aspect.

[0022] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0023] First, by constructing an automated processing pipeline comprising image preprocessing and OCR modules, an underwriting medical terminology standardization module, a large language model intelligent parsing module, and an underwriting rule engine module, data-driven and automated connections are achieved across all stages of the underwriting process. This eliminates system waiting and manual intervention caused by process breakpoints, improving the system's real-time processing capability for unstructured medical examination reports. Second, by guiding the large language model through underwriting medical terminology mapping rules to perform semantic parsing and structured information extraction from medical examination reports, non-standardized clinical descriptions are converted into standardized underwriting terms. This solves the technical challenge of multi-source heterogeneous report data not being directly recognized and processed by the rule engine, improving the system's structured parsing accuracy for complex examination items such as ultrasound imaging. Finally, by logically matching structured medical examination indicator data with a coded underwriting rule knowledge base, unified configuration and automated execution of underwriting decision logic are achieved, avoiding inconsistencies and execution deviations caused by scattered rules and manual execution. This application realizes a fully systematic closed-loop processing from medical examination report image input to underwriting conclusion data output. Attached Figure Description

[0024] 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:

[0025] Figure 1 Flowchart of existing technology underwriting process;

[0026] Figure 2 This is a schematic diagram of an application scenario system according to an embodiment of this application;

[0027] Figure 3 This is a flowchart of an automated underwriting assessment method according to an embodiment of this application;

[0028] Figure 4 This is a flowchart of an automated underwriting assessment method on the server side, as described in an embodiment of this application.

[0029] Figure 5 This is a flowchart of an automated underwriting assessment method on the terminal device side, as described in an embodiment of this application.

[0030] Figure 6 This is a schematic diagram illustrating the automation of medical examination document underwriting to replace manual labor in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of the module for automatically issuing medical examination notices in an embodiment of this application;

[0032] Figure 8 This is a schematic diagram of the pre-underwriting function at the sales front end in an embodiment of this application;

[0033] Figure 9 This is a structural diagram of an automated underwriting assessment device according to an embodiment of this application;

[0034] Figure 10 A schematic diagram of an embodiment of an automated underwriting assessment system provided in this application.

[0035] Figure 11 This is a structural diagram of an embodiment of the server-side device of this application;

[0036] Figure 12 This is a structural diagram of an embodiment of the terminal device of this application;

[0037] Figure 13 This is a schematic diagram of another embodiment of the server-side device of this application;

[0038] Figure 14 This is a structural diagram of another embodiment of the terminal device of this application. Detailed Implementation

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

[0040] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0041] Figure 2 This is a schematic diagram of an application scenario system according to an embodiment of this application. The system includes a user terminal 11, an underwriting server 12, an image server 13, and a notification server 14.

[0042] User terminal 11 can be a personal computer, smartphone, tablet, etc. operated by insurance customers, sales personnel, or underwriting personnel. It is connected to the underwriting server 12 to provide an interface for inputting insurance application information and a physical examination report image confirmation interface, and to initiate requests, upload materials, receive and display information.

[0043] The underwriting server 12 is equipped with the automated underwriting assessment program of this application. It is used to receive requests from user terminal 11, execute core data processing and intelligent assessment logic including character recognition, terminology mapping, large language model parsing and rule matching, and generate underwriting conclusion data.

[0044] The image server 13 is connected to the underwriting server 12 and is used to store the image data of the medical examination report and provide the corresponding image files according to the request of the underwriting server 12.

[0045] The notification server 14 is connected to the underwriting server 12 and the user terminal 11 to push medical examination instruction data containing the application identifier to the user terminal 11 or the medical examination institution system.

[0046] The underwriting server 12 is logically divided into multiple service modules, such as a receiving and distributing module, an image preprocessing and OCR module, a large language model service module, and an underwriting rule engine module. Further, these modules exchange data via RESTful APIs or gRPC protocols, using JSON Schema as the data format. The system interfaces with the insurance company's core business system and the medical examination institution's management system through standardized APIs to achieve synchronization of insurance application information, issuance of medical examination instructions, and acquisition of report images.

[0047] The user terminal described in this application includes a personal computer, a smartphone, a tablet computer, or client software running on the aforementioned devices.

[0048] The underwriting server, image server, and notification server mentioned in this application include physical servers, virtual servers, or a distributed cluster consisting of multiple devices.

[0049] This application contains several embodiments. Figure 3 The corresponding text describes the process of the method described in the first aspect. Figure 5 The accompanying drawings illustrate another embodiment of the method, which uses “request data,” “application identifier,” and “processing confirmation instruction” to describe the interaction steps.

[0050] Figure 3 This is a flowchart of an automated underwriting assessment method according to an embodiment of the present application, including steps 210-250.

[0051] In a first aspect, embodiments of this application provide an automated underwriting assessment method, including the following steps:

[0052] Step 210: Obtain the medical examination report image data and the associated insurance application information.

[0053] Step 210A: The system receives request data containing insurance information associated with the target insurance application.

[0054] Specifically, the method described in this application begins with receiving a request from an upstream business system or client. The request data is the fundamental input for initiating the automated underwriting assessment process, and its core is the insurance information, typically including the insured's identity, the type of insurance product, the requested insurance amount, and the results of the health declaration questionnaire. The request data can be received through a standardized API (such as a RESTful API) interface and parsed according to a predefined data structure (such as JSON format). After receipt, the system will verify and temporarily store the data, providing input for subsequent rule-based judgments.

[0055] Step 210B: The system sends physical examination instruction data containing the application identifier.

[0056] After receiving the request data, the system enters the logical judgment and task generation phase. The core of this step is to generate and output a key instruction set that drives the subsequent physical examination process—the physical examination instruction data. This data must contain a globally unique application identifier generated by the system. This identifier will serve as the unique key for all subsequent steps to associate with and track this physical examination task.

[0057] Specifically, the medical examination instruction data is a structured electronic instruction object, whose fields typically include: a unique application identifier (e.g., generated using a UUID algorithm), a summary of the insured's basic information, a list of required medical examination items determined according to insurance product rules and underwriting information, and system-recommended cooperative medical examination institutions and selectable time periods. This data object can be serialized into common formats such as JSON or XML for easy transmission and parsing over a network.

[0058] Step 210C: Obtain the medical examination report image data according to the application identifier.

[0059] Once the client completes the medical examination according to the instructions, their report will be generated in the form of a digital image. The task of this step is to automatically and accurately acquire the medical examination report image file bound to a specific application identifier. The system uses the generated and issued application identifier as a key index to proactively query, retrieve, or receive the corresponding report image from the connected medical examination institution's information system or designated file storage service.

[0060] In one embodiment, to improve the accuracy and efficiency of subsequent processing, preprocessing can be performed immediately after the image data is acquired. For example, multi-page report images can be segmented by department, automatically dividing them into multiple sub-image data blocks according to the examination department (such as "blood routine", "ultrasound", "electrocardiogram"), so as to enable more targeted identification and analysis in the future.

[0061] Step 210D: The system receives a confirmation instruction for processing the image data in the physical examination report.

[0062] After the medical examination report image data is ready and may have undergone preliminary preprocessing, the system needs to wait for a clear start signal to begin the core intelligent analysis process. This step is the one that receives this signal. The processing confirmation instruction is usually triggered by customer service personnel, underwriting staff, or the customer themselves reviewing the displayed medical examination report images on the terminal interface (such as the underwriting workbench or customer APP), for example, by clicking the "Start Intelligent Underwriting" or "Confirm Image Clarity" button. This instruction is sent to the backend through the system interface, authorizing the system to perform subsequent in-depth processing on the specified image data.

[0063] Step 220: Perform character recognition on the image data of the physical examination report to obtain text data.

[0064] After obtaining processing authorization, the system first converts the image information into text information that can be understood and processed by a computer. This is achieved through Optical Character Recognition (OCR) technology. Before performing OCR, to ensure recognition quality, the system typically performs a series of intelligent preprocessing steps on the image, including but not limited to:

[0065] Image quality detection: Using a trained image quality assessment model, the system automatically judges the sharpness, contrast, and integrity of images, and prompts images that do not meet the quality standards to be re-uploaded.

[0066] Serialization and sorting: For multi-page reports, by recognizing page numbers in the images or analyzing page structure features (such as department titles), potentially out-of-order image pages are arranged in the correct logical order of the report.

[0067] After preprocessing, a dedicated OCR engine performs batch recognition on qualified images (or sub-images after departmental classification) and outputs raw text data. Although the text may have messy formatting or occasional recognition errors, it contains all the textual information of the report.

[0068] Step 230: Convert the text data into formatted input data according to the underwriting medical terminology mapping rules.

[0069] The raw text output by OCR contains a large number of non-standardized clinical descriptions from different medical institutions. This step aims to standardize these non-standard descriptions into standard descriptions within the underwriting field. The system accesses a built-in underwriting medical terminology knowledge base, which stores mapping rules from diverse clinical expressions to standard underwriting terminology. By applying these rules, the system automatically scans, matches, and replaces the identified text, for example, uniformly converting terms such as "sinus rhythm" and "regular heart rhythm" from various hospital reports into the standard term "normal heart rate."

[0070] After terminology standardization, the system further constructs formatted input data from the cleaned text according to a predefined template. This data is typically a carefully crafted prompt text that includes system instructions for the large language model, the expected output format (such as specifying a JSON structure), and the report body content after terminology standardization.

[0071] Step 240: Input the formatted input data into the large language model to obtain structured physical examination index data.

[0072] The structured physical examination index data includes at least one examination item extracted from the text data and its corresponding value or description.

[0073] The system submits the generated formatted input data to a large language model trained with underwriting domain knowledge for processing. This large language model has been adaptively trained through a large number of underwriting cases, medical literature, and underwriting rules, giving it a strong semantic understanding capability in insurance underwriting scenarios.

[0074] After receiving input, the model performs deep semantic analysis and information extraction tasks. It can understand complex medical descriptive contexts, accurately identify various examination indicators, abnormal findings, specific values, units of measurement, and location information, and organize this information according to a preset structure (such as key-value pairs) to output highly structured physical examination indicator data.

[0075] Step 250: Logically match the structured physical examination index data with the pre-configured underwriting rule knowledge base to generate the underwriting conclusion data.

[0076] In this step, the underwriting conclusion data is generated based on the structured medical examination index data.

[0077] Finally, the system sends the machine-readable structured medical examination data to the underwriting rule engine for automated decision-making. This engine loads a pre-configured, coded underwriting rule knowledge base, which contains logical mappings between various diseases, abnormal indicators, and underwriting conclusions (such as standard coverage, additional premiums, exclusions, and rejection).

[0078] The rule engine uses structured data as "facts" to match and reason against rules in the knowledge base. For example, a rule might be encoded as: "IF (Examination Item == 'Liver Cyst' AND Value < 1 AND Unit == 'cm') THEN Conclusion = 'Standard Coverage'". The engine automatically performs such logical calculations to generate underwriting conclusion data. This conclusion data itself is also structured, typically containing fields such as conclusion code, rate adjustment coefficient, and exclusion list, making it easy for downstream systems to parse and process.

[0079] Figure 4 This is a flowchart of an automated underwriting assessment method for server equipment, as described in an embodiment of this application, including steps 310-360.

[0080] Step 310: Receive the request data; the request data includes insurance information associated with the target insurance application.

[0081] Specifically, the data received by this method originates from the upstream processing stage. For example, for underwriting applications that cannot pass self-review, the self-review failure factor is pushed to the new generation underwriting platform. This method determines whether it meets the criteria for directly issuing a standard notification. If the customer has no abnormalities at the time of application, but only has issues such as medical examinations exceeding the coverage amount or exceeding the age limit, a medical examination notification needs to be issued in this case.

[0082] In this step, the insurance information is the foundational data for initiating the process, typically including the insured's identity information, type of insurance, coverage amount, and answers to the health declaration questionnaire. The medical examination trigger flag is a crucial logical signal indicating that the current insurance application needs to enter the medical examination underwriting sub-process. For example, for a 50-year-old customer applying for critical illness insurance with a coverage amount of 800,000 yuan, the system may generate this flag due to their "exceeding the coverage amount" and "exceeding the age limit."

[0083] In one embodiment, the request data further includes a physical examination trigger identifier;

[0084] The physical examination trigger indicator includes indications for at least one of the following situations:

[0085] The insured amount exceeds a preset threshold;

[0086] The insured's age exceeds a preset threshold.

[0087] This embodiment defines two of the most typical physical examination trigger conditions. The preset threshold can be dynamically set according to the risk strategy of different insurance products. For example, for critical illness insurance, the coverage threshold may be set to 500,000 yuan, and the age threshold may be set to 50 years old.

[0088] In one embodiment, the medical examination trigger identifier is generated by the front-end underwriting rule engine based on the insurance information.

[0089] This embodiment provides a more complete system view. The medical examination trigger identifier is not generated out of thin air, but is generated by a professional module called the pre-installed underwriting rule engine. This engine can be regarded as an automated decision-making system integrated into the insurance company's core business system. Its working principle is as follows: when the salesperson enters and submits the insurance information, the engine will automatically perform risk assessment and rule matching based on the insurance information (such as coverage amount, age, product type, health declaration, etc.). For insurance applications whose assessment result indicates that further medical examination underwriting is required, the engine will generate a corresponding medical examination trigger identifier (i.e., self-underwriting failure factor) and output it along with the insurance information as the starting point of the input process of this method.

[0090] The underwriting rule engine in this application embodiment is the core of the rule triggering and scheduling module of this application. It replaces the experience judgment in manual review with a coded and configurable rule set, realizes the automatic and unified triggering of physical examination requirements, and avoids the processing differences caused by human negligence or inconsistent standards from the source. It is the first technical guarantee for improving process standardization and efficiency.

[0091] Step 320: Send the first response dataset; the first response dataset determines the medical examination instruction data based on the insurance information; the medical examination instruction data includes an application identifier.

[0092] In one embodiment, if the request data also includes a medical examination trigger identifier, then in response to the medical examination trigger identifier, medical examination instruction data is determined based on the insurance information; the medical examination instruction data includes an application identifier.

[0093] Once the system confirms that the data contains a physical examination trigger identifier, it automatically executes the subsequent instruction generation process. For example... Figure 7 As shown, the fully automated underwriting assessment method for customer medical examination reports automatically issues notification letters through factor validation, determining the type of notification letter and immediately issuing standard medical examination notification letters, reducing manual intervention in the notification issuance process. By replacing manual work with this fully automated underwriting assessment method for customer medical examination reports, manual processing costs are saved, errors are reduced, underwriting efficiency is improved, and customer waiting time is significantly shortened.

[0094] The system employs condition-triggered automation. The physical examination instruction data is a set of instructions generated by the system that drives the subsequent physical examination process; its core element contains a unique application identifier.

[0095] Specifically, the medical examination instruction data is a structured electronic data object, whose core fields include: a unique application identifier (UUID format), basic information of the insured, a list of required medical examination items (generated according to product rules), a list of recommended medical examination institutions and available appointment time slots, and the validity period of the instruction. This data object can be serialized into JSON or XML format to drive subsequent online appointment and report tracking processes.

[0096] This embodiment of the application is executed by a notification server or data notification service module. This module accesses the electronic notification template library, automatically generates structured medical examination instruction data based on the triggering results of the rule engine and insurance information, and pushes it to the terminal or medical examination institution system through the data interaction interface module. This technology completely replaces the manual creation and issuance of notifications, transforming repetitive, manually created offline operations into efficient and accurate inter-system data exchange. It is a key technological step in solving the problems of poor customer experience and time-consuming, labor-intensive processes.

[0097] This identifier is used throughout the entire process to uniquely track and associate the physical examination task and all subsequent related data (such as reports and conclusions), and is the key to achieving automated association throughout the entire process.

[0098] Step 330: Receive the application identifier.

[0099] Step 340: Send a second response dataset, which corresponds to the application identifier and contains medical examination report image data.

[0100] Specifically, after receiving the application identifier in step 330, the server triggers an internal processing flow: based on the application identifier, it obtains the physical examination report image data.

[0101] After completing the medical examination as instructed, the customer's report will be submitted in image format. This step solves the efficiency bottleneck in the traditional process: after the customer's medical examination report is generated, most of them need to be scanned into electronic images by counter staff and uploaded to the system. Underwriters then check the medical examination results by reviewing the images page by page and record any abnormal results. This method, however, automatically associates and retrieves the digitized report image through the application identifier.

[0102] This step enables the automatic integration of physical examination results into the digital world. The system uses the application identifier as an index key to actively retrieve or receive matching medical examination report image files from the system connected to the medical examination institution or a designated storage location, completely eliminating manual transmission and scanning processes. The acquired medical examination report image data is included in the second response dataset sent in step 340.

[0103] In one embodiment, the internal processing of obtaining the medical examination report image data based on the application identifier further includes the following optimization steps:

[0104] The physical examination report image data is segmented by department to obtain sub-image data corresponding to different departments;

[0105] The character recognition processing is performed separately based on the sub-image data.

[0106] This embodiment is an optimized preprocessing method. "Department-based segmentation processing" refers to using image recognition technology to automatically segment a complete report image according to department (such as blood routine, electrocardiogram, ultrasound).

[0107] For example, the "Ultrasound Description" area in the report page can be cut out separately. This allows subsequent OCR to more accurately identify the layout and terminology characteristics of different departments, improving the overall processing effect. The sub-image data after being processed by department is included in the second response dataset sent in step 340 for use in subsequent processes.

[0108] Step 350: Receive a confirmation instruction for processing the image data in the physical examination report;

[0109] Step 360: Send the third response dataset; the third response dataset contains underwriting conclusion data; the underwriting conclusion data is generated in response to the processing confirmation instruction by performing character recognition and intelligent evaluation processing on the medical examination report image data.

[0110] Specifically, in one embodiment, in response to the processing confirmation instruction received in step 350, the server performs a series of intelligent processing on the medical examination report image data to generate underwriting conclusion data. This processing specifically includes the following sub-steps:

[0111] Step 360-1: Perform character recognition on the image data of the physical examination report to obtain the first text data;

[0112] Before performing character recognition processing, a preprocessing step is included for the image data of the physical examination report, which includes at least one of the following:

[0113] Image quality inspection and / or serialization sorting: Image processing models are used to detect image sharpness. If the quality is not up to standard, the image needs to be re-acquired. Images that may be out of order are intelligently sorted to form a correct report sequence.

[0114] The serialization and sorting process employs an algorithm based on image content analysis:

[0115] First, try to sort the pages in ascending order by recognizing the page numbers in each image using OCR; if the page numbers are missing or cannot be recognized, use layout analysis technology to detect the header, chapter title (such as "blood routine", "electrocardiogram") or examination item name, and then sort them logically according to the known general structure template of the physical examination report.

[0116] Departmental segmentation processing: Using image recognition technology, the complete report image is automatically segmented according to the examination department (such as blood routine, electrocardiogram, ultrasound) to obtain sub-image data corresponding to different departments; in this case, the character recognition will be performed separately for the sub-image data to improve recognition accuracy.

[0117] The departmental segmentation process achieves departmental matching through the following methods:

[0118] The convolutional neural network (CNN) is used to identify features in the header area of ​​the report image to locate the department name text area; the text in this area is identified by OCR and matched with a preset "department classification keyword dictionary" (such as containing "ultrasound", "radiology", "laboratory department" etc.); finally, based on the matching results and the layout information, the report is cut into sub-image data blocks corresponding to different departments.

[0119] After completing the above preprocessing, the system performs optical character recognition (OCR) on qualified images (or sub-images).

[0120] After acquiring the images, they need to be converted into processable text information. This method introduces intelligent processing at this stage: it fully utilizes AI machine learning and image processing (CV) capabilities to construct an image quality detection model, an image ranking model, and an OCR model to perform structured and normalized processing on the medical examination report, forming a standardized digital result. The image quality detection model checks the image quality; if the quality is substandard, the customer is required to retake and upload the image. After the images are uploaded, since users may not upload them in the correct order, an image ranking algorithm is needed to sort the images. After sorting, the images are uniformly fed into the OCR model for text recognition and department matching, and the OCR-processed results are then passed to the main processing program.

[0121] The character recognition processing, or OCR technology, converts text in an image into computer-readable text. The first text data is the raw recognition result, which may contain formatting issues and occasional typos, but it already provides a basis for analysis. This step integrates two intelligent preprocessing sub-steps: image quality detection and serialization sorting. The former ensures clear and usable input, while the latter addresses the issue of out-of-order uploads, jointly guaranteeing the accuracy and robustness of OCR processing.

[0122] This embodiment of the application is completed collaboratively by an image acquisition and preprocessing module and an optical character recognition module. The image quality detection unit, serialization and sorting unit, and departmental segmentation unit within the image acquisition and preprocessing module, through the integration of image processing models and specific algorithms, simulate and surpass the quality judgment, sequencing, and report classification behaviors of manually reviewing images page by page. This transforms the inefficient operation relying on human vision and experience into automated, standardized pipeline processing, which is one of the core technical aspects for improving underwriting timeliness. The optical character recognition module then converts the preprocessed images into text data in batches, providing raw materials for subsequent intelligent analysis.

[0123] Step 360-2: Convert the first text data into formatted input data according to the underwriting medical terminology mapping rules;

[0124] After obtaining the original text, it needs to be converted into a format suitable for understanding by a large language model and conforming to underwriting professional standards. The mapping rules for underwriting medical terminology are stored in a dedicated underwriting medical knowledge base, used to map non-standardized clinical descriptions to standardized underwriting terminology. This demonstrates the deep application capability of this method in the professional field: extracting, classifying, correcting errors, and structuring the digitized content, it can support the identification and normalization of more than 1,200 physical examination items. In particular, it realizes the structured and normalized analysis and automatic interpretation of ultrasound imaging examinations (B-ultrasound, X-ray, electrocardiogram, etc.) with high medical professional requirements, lowering the threshold for underwriting work and improving the efficiency of policy processing.

[0125] The underwriting medical terminology mapping rules are the core knowledge base of this solution, which completes the conversion from non-standard clinical language to standard insurance terminology.

[0126] For example, different descriptions of "sinus rhythm" and "regular heart rhythm" from various hospitals are uniformly mapped to the standard term "normal heart rate." Formatted input data is text with a clear structure and standardized terminology generated after applying this rule, specifically prepared to guide the large language model in accurate analysis. This formatted input data can be part of a specific prompt word template designed for the large language model, which guides the model to output information according to a predetermined structure.

[0127] The formatted input data includes carefully crafted prompts to guide the large language model. These prompts typically consist of three parts: system instructions, output format definitions, and the text content to be processed.

[0128] For example: "You are an insurance underwriting assistant. Please extract all abnormal examination items from the following medical examination report text and output it as a JSON list, with each item containing the fields 'Examination Item', 'Result', 'Unit', and 'Location'. Output only JSON. Report text: [Insert standardized text here]". This type of structured prompt guides the model to perform accurate and uniformly formatted information extraction.

[0129] This embodiment of the application is executed by the underwriting medical terminology standardization module. The module's built-in underwriting medical terminology knowledge base, as a professional domain knowledge base, solves the technical problem of inconsistent terminology in medical reports. By codifying mapping rules, the module automatically performs terminology conversion and text formatting, generating formatted input data suitable for large language models. This process replaces the step where underwriters manually record abnormal results, requiring them to rely on their personal medical knowledge for interpretation and translation. It is a key technological foundation for achieving professionalization and standardization in underwriting processing, directly improving the accuracy and consistency of subsequent analysis.

[0130] Step 360-3: Input the formatted input data into a large language model trained with underwriting knowledge to obtain structured physical examination indicator data;

[0131] The system hands over the formatted data to a large language model for processing: the main processing program extracts and structures the data for each physical examination item by department. The core of this process lies in leveraging the general capabilities of the large model to extract and structure the examination information from the OCR-extracted reports, categorized by department. The key challenge is departmental matching. Report formats from different hospitals and physical examination institutions are highly inconsistent, requiring various methods to provide the large model with correct content input and prompts. Finally, the standardized extraction results from the large model are fed into the rule engine, which then provides the final underwriting conclusion.

[0132] The large language model is adaptively trained with underwriting domain knowledge, enabling it to understand medical terminology and risk logic in underwriting scenarios. After receiving formatted input data, the model performs deep semantic understanding, identifies anomalous information, and outputs highly structured data.

[0133] The structured physical examination indicator data is the output of a large language model, for example, a data object in JSON format containing fields such as "examination items", "values", "locations", "department classifications", and "whether abnormal". It transforms text into field-based data that can be directly processed by machines.

[0134] For example, structured fields such as "Examination item: liver cyst", "size: 0.5cm", and "location: right lobe" can be extracted from an ultrasound description. This solves the problem that traditional methods struggle to understand complex medical text.

[0135] Specifically, the structured physical examination indicator data is in a machine-readable standardized format, such as a JSON array, where each element represents a physical examination indicator and includes, but is not limited to, the following fields: check_item (examination item, mapped to standard terminology), value (numerical value or description), unit (unit), position (location, if applicable), category (department classification), is_abnormal (whether it is abnormal, boolean value), and reference_range (reference range).

[0136] For example: {"check_item": "liver cyst", "value": "0.5", "unit": "cm", "position": "right lobe", "category": "ultrasound", "is_abnormal": true, "reference_range": "none"}. This structured approach provides precise input for subsequent rule engine evaluation.

[0137] This embodiment of the application is executed by the large language model intelligent parsing module. The core of this module is a large language model trained with underwriting domain knowledge. As a key component of the intelligent parsing and decision-making module, it undertakes the tasks of deep and precise analysis. Through semantic understanding and information extraction, this module transforms unstructured natural language text into highly structured, machine-readable medical examination indicator data. This technique not only simulates the thought process of a human underwriter reading reports and extracting key information, but also overcomes potential omissions and subjective biases in manual extraction through algorithmic consistency. It is the core of achieving intelligence and provides high-quality data input for automated decision-making.

[0138] Step 360-4: Based on the pre-configured underwriting rule knowledge base, generate the underwriting conclusion data according to the structured medical examination index data.

[0139] Finally, the system makes underwriting decisions based on the results of intelligent analysis: it segments the underwriting decision knowledge base and, based on large language model capabilities, constructs intelligent decision-making capabilities suitable for insurance company underwriting scenarios, and applies them in various manual underwriting operation scenarios. Through in-depth analysis of customers' medical examination reports using large language models, it accurately analyzes customers' health abnormalities and diseases, and, referring to underwriting evaluation rules, automatically provides underwriting conclusions such as standard risk, rejection, and conditional coverage. This effectively reduces the risk of adverse selection for customers, the workload and intensity of underwriters, and avoids differences in conclusions caused by different manual underwriting standards, achieving automation, intelligence, and standardization of underwriting conclusions.

[0140] The system inputs machine-readable structured medical examination data into a pre-configured underwriting rule engine, which loads a coded, versioned underwriting rule knowledge base for logical calculation and matching. For example, if the rule states "liver cysts <1cm can be insured at standard rates," and the customer's data matches, the engine automatically generates underwriting conclusion data with a specific data structure (such as fields containing conclusion codes and rate adjustment coefficients). This achieves the final leap from information understanding to business decision-making.

[0141] The underwriting conclusion data is also a structured data object, whose standard fields may include: conclusion_code (conclusion code, such as 'STANDARD', 'RATED', 'DECLINED'), premium_adjustment_factor (rate adjustment factor), exclusion_list (list of exclusions, an array of disease or site codes), effective_date (conclusion effective date), and comment (underwriting remarks). This structured conclusion facilitates direct parsing and processing by downstream processes such as the sales front-end and core business systems.

[0142] The underwriting rule engine (e.g., based on open-source rule engines such as Drools or Jess, or a self-developed engine) loads pre-configured, version-manageable business rules from the underwriting rule knowledge base at runtime. These rules are typically written in "IF-THEN" format, such as: "IF (Examination Item == 'Liver Cyst' AND Value < 1 AND Unit == 'cm') THEN Conclusion = 'Standard Risk Coverage'". The engine takes structured medical examination data as facts as input, performs pattern matching with rules in the rule base, triggers rules that meet the conditions, and derives the final underwriting conclusion.

[0143] This application's embodiment is executed by an intelligent decision-making module for underwriting rules. This module includes an underwriting rule engine and an underwriting evaluation rule knowledge base, constituting the intelligent decision-making engine of this application. By codifying and configuring underwriting rules and encapsulating them within the rule engine, this application ensures that all underwriting judgments are executed based on the same set of version-controllable and auditable logical rules, fundamentally solving the management problems of inconsistent underwriting standards, the probability of errors in manual judgment, and inconsistent standards.

[0144] The final underwriting conclusion data is included in the third response dataset sent in step 360.

[0145] In one embodiment, the method further includes the step of sending the underwriting conclusion data to the sales front-end system.

[0146] This embodiment expands the application scenarios of this method, enabling it to provide real-time references in the sales process, thereby improving the sales experience and success rate: such as Figure 8 As shown, during the customer registration process, the customer uploads their physical examination report, the system automatically performs image recognition, large-scale model analysis, and issues a final underwriting conclusion.

[0147] This application's embodiment constitutes a pre-underwriting scenario at the sales front end. By encapsulating the capabilities of the aforementioned image preprocessing and recognition module, underwriting medical terminology standardization module, large language model intelligent parsing module, and underwriting rule intelligent decision-making module as services, and providing them to the sales front end via a data interaction interface module, risk previews can be offered early in the insurance application process. This technology application effectively reduces the high dropout and cancellation rates caused by uncertainty in later underwriting conclusions by managing customer expectations, thereby improving business conversion rates.

[0148] In one embodiment, after sending the physical examination instruction data in step 320 and before receiving the application identifier in step 330, an online appointment step is also included:

[0149] Send the physical examination indication data to the client;

[0150] Receive physical examination appointment confirmation data from the client.

[0151] This embodiment corresponds to the online medical examination appointment scenario, which greatly optimizes the customer experience and reduces operating costs: online appointment for medical examination reports, for insurance applications that meet the requirements for automatic issuance of medical examination notices, the system automatically completes the generation and issuance of medical examination notices. Through integration with medical examination institutions, customers can select the medical examination institution and examination time they need to make an appointment online. After the appointment is made, in case of special circumstances, the appointment information can be modified or canceled. By providing customers with online and transparent medical examination appointment services, it meets customers' flexible and diverse medical examination needs, greatly improves the customer's medical examination experience, eliminates the need for back-office staff to make appointments and accompany customers to medical examinations offline, and greatly reduces labor costs.

[0152] This application embodiment is implemented through an online appointment service module. This module provides a graphical user interface (GUI) and calls the appointment API of the medical examination institution's system, transforming the high-cost, poor-experience manual operations of repeated communication and accompanying clients to medical examinations—such as online data interaction—into online data interaction that clients can complete themselves. This is not only a key technical means to improve customer experience, but also directly improves overall process efficiency and reduces operating costs by reducing manual intervention.

[0153] This example illustrates the complete closed loop of building online appointment capabilities. The client refers to the app or mini-program used by the customer. This enables customers to make appointments independently, completely replacing the traditional model of offline communication and accompaniment by office staff.

[0154] like Figure 6 As shown, by performing the above steps 310-360, this application realizes the automation of the underwriting process for medical examination documents in the underwriting stage, replacing manual labor, and constructs an assessment method that integrates automation, online processing, intelligence, and digitalization.

[0155] Figure 5 This is a flowchart of an automated underwriting assessment method on the terminal device side, which is used in a terminal device and includes steps 410-460.

[0156] Step 410: Send request data; the request data includes insurance information associated with the target insurance application.

[0157] Specifically, in response to user actions (e.g., sales personnel entering and submitting insurance information, or customers confirming information on a self-service insurance application interface), the terminal device generates and sends request data to the server. The insurance information is the request data that initiates the automated underwriting assessment process, typically including the insured's identity information, the type of insurance, the coverage amount, and answers to the health declaration questionnaire. In one embodiment, if the user's action triggers a medical examination judgment by the underwriting rules engine, the request data may also contain a medical examination trigger identifier generated by the front-end or related systems. For example, when a user enters high coverage or advanced age information on the interface, the front-end logic can immediately generate and attach this identifier.

[0158] Step 420: Receive and display the first response dataset; the first response dataset contains physical examination instruction data; the physical examination instruction data contains an application identifier.

[0159] The terminal device receives the first response dataset from the server and displays it on the user application interface. The physical examination instruction data is a set of instructions issued by the system to guide the subsequent physical examination process, and its core component is a unique application identifier. This identifier is used to uniquely track and associate the physical examination task in all subsequent stages.

[0160] In one embodiment, the terminal device provides an online medical examination appointment service interface based on the medical examination instruction data, either simultaneously with or after displaying the data. Users can use this interface to view available medical examination institutions and appointment slots, and complete self-service appointment, rescheduling, or cancellation. This function realizes the online and self-service transformation of the medical examination process, greatly improving the customer experience.

[0161] Step 430: Send the application identifier.

[0162] Once the user completes the physical examination according to the instructions and the examination report is ready, the terminal device sends an application identifier to notify the server. This step can be triggered actively by the user (e.g., by clicking "Report Ready" in the app) or automatically executed by the terminal device after receiving a push notification from the physical examination institution or the server. The application identifier acts as a key, informing the server which physical examination report image to retrieve.

[0163] Step 440: Receive and display the second response dataset; the second response dataset contains medical examination report image data.

[0164] The terminal device receives a second response dataset from the server, which contains medical examination report image data corresponding to the application identifier. The terminal device displays these images on the user interface for the user to view and confirm. The image data may be a complete report image or a preprocessed sub-image (such as an image segmented by department).

[0165] In one embodiment, after displaying the medical examination report image data, the terminal device also provides a user interface for confirming the medical examination report image data. For example, it may provide buttons such as "Image clear, start underwriting" or "Re-upload". The confirmation command issued by the user through this interface will be used to generate subsequent processing confirmation commands.

[0166] Step 450: Send a confirmation instruction for processing the image data in the physical examination report.

[0167] The terminal device responds to the user's operation on the confirmation interface described in step 440 by generating and sending a processing confirmation instruction to the server. This processing confirmation instruction is a clear signal from the user authorizing or requesting the system to begin intelligent analysis and underwriting assessment of the displayed medical examination report images.

[0168] Step 460: Receive and display the third response dataset; the third response dataset contains underwriting conclusion data.

[0169] The terminal device receives the third response dataset from the server and clearly displays the final underwriting conclusion data on the user interface. This conclusion data is the result generated by the server in response to the processing confirmation instruction, after performing a series of processes such as character recognition and intelligent assessment on the medical examination report image data. Its form may be "Standard risk approved", "Conditional coverage (surcharge / exclusion)", "Rejection", etc., and may be accompanied by a brief explanation or instructions for subsequent steps.

[0170] In one embodiment, the third response dataset also includes a list of insurance application materials (if the conclusion is that manual underwriting is required) or other recommended insurance product names (if the original intended product is not approved), providing users with further action guidelines or alternative solutions.

[0171] like Figure 6 As shown, by performing the above steps 410-460, this application constructs a user interaction process on the terminal side that seamlessly connects with the automated underwriting process on the server side.

[0172] It should be noted that the above-mentioned terminal device side implementation corresponds to the aforementioned server device side implementation (steps 310-360) and can be freely combined to form a complete automated underwriting assessment scheme, and does not constitute a limitation on the scope of protection.

[0173] This example describes a pre-underwriting scenario at the sales front end. In this scenario, the input to the process is the customer's historical medical examination report uploaded by the salesperson, rather than data triggered by underwriting. The system quickly performs analysis and feeds back the underwriting conclusion data to the sales front end for the customer's reference before purchasing insurance, significantly improving the sales experience and efficiency.

[0174] It should be noted that the above embodiments can be freely combined and do not constitute a limitation on the scope of protection.

[0175] The above embodiments are merely preferred embodiments of this application. Those skilled in the art can freely combine the above embodiments involving different stages such as image preprocessing, department segmentation, large model analysis, and rule decision-making as needed to constitute different implementations of this application, all of which fall within the protection scope of this application.

[0176] The method described in this application has achieved significant results in practical applications. Through practical verification, as of March 2025, the method achieved a structured recognition rate of 97% and an accuracy rate of 93%. The accuracy rate of underwriting conclusions reached 96%, approaching the level of manual underwriting, and it prioritized machine-based replacement of manual labor for applications with standard underwriting conclusions. The underwriting time of this method is significantly shorter than that of manual underwriters, achieving industry-leading results and improving processing consistency and timeliness. It saves a considerable amount of time required for manual underwriting, resulting in faster underwriting speeds and higher-quality underwriting services for customers.

[0177] Figure 9 This is a structural diagram of an automated underwriting assessment device according to an embodiment of this application.

[0178] An automated underwriting assessment apparatus for implementing the automated underwriting assessment method as described in any one of the first aspects, comprising:

[0179] The acquisition module 11201 is used to acquire the image data of the physical examination report and the associated insurance application information, as described in step 210 of the embodiment.

[0180] The acquisition module serves as the interface between the device and external data sources (such as medical examination institution information systems, cloud storage services, and core business systems). It automatically acquires medical examination report images and corresponding insurance application information through a preset data synchronization protocol or interface, providing input for subsequent processing.

[0181] The acquisition module 1201 is also used to perform character recognition on the physical examination report image data to obtain text data, as described in step 220 of the embodiment.

[0182] Preferably, the processing module includes multiple functional units:

[0183] The image acquisition unit is used to acquire image data from medical examination reports and related insurance application information.

[0184] Image preprocessing and character recognition unit: After preprocessing the acquired image data such as image quality detection, serialization sorting and / or departmental segmentation, optical character recognition is performed to output the original text data.

[0185] The generation module 1203 is also used to input formatted input data into a large language model to obtain structured physical examination index data; and to perform logical matching between the structured physical examination index data and a pre-configured underwriting rule knowledge base to generate underwriting conclusion data, as described in steps 240-250 of the embodiment.

[0186] Large Language Model Intelligent Parsing Unit: Encapsulates or calls a large language model service trained with underwriting domain knowledge, receives formatted input data, performs semantic parsing and information extraction, outputs inspection items and their corresponding values ​​or descriptions according to a predetermined data structure, and generates structured physical examination index data, as described in step 240 of the embodiment.

[0187] Intelligent decision-making unit for underwriting rules: It has a built-in underwriting rule engine, loads a codeable underwriting rule knowledge base, and performs logical matching between structured medical examination index data and judgment rules and threshold parameters in the rule base to automatically generate underwriting conclusion data containing at least one of the conclusion code, premium rate coefficient, and exclusion liability list, as described in step 250 of the embodiment.

[0188] The conversion module 1202 is used to convert the text data obtained by the processing module into formatted input data according to the underwriting medical terminology mapping rules, as described in step 230 of the embodiment.

[0189] The conversion module has a built-in underwriting medical terminology knowledge base, which stores a set of mapping rules between clinical terms and underwriting standard terms. This module automatically matches and replaces terms, converting the non-standardized clinical description text output by OCR into standardized text that conforms to underwriting professional standards, and constructing specific prompt word templates to guide the large language model, thus generating the formatted input data.

[0190] It should be noted that, Figure 9 The core logic module structure of the device in this application is shown. Figures 3-8 The embodiments describe the specific implementation and interaction process of the device, and its functional modules can be connected with... Figure 9 The corresponding logical modules.

[0191] Figure 10 A schematic diagram of an embodiment of an automated underwriting assessment system provided in this application includes:

[0192] The underwriting server 1301 is equipped with the apparatus as described in the second aspect embodiment, or is configured to perform the method as described in any one of the first aspect embodiments, as described in steps 210-250, 310-360.

[0193] User terminals 900 and 1100 are communicatively connected to the underwriting server and are used to provide an interface for inputting insurance application information and a physical examination report image confirmation interface. Preferably, the user terminal can be configured to implement the method as described in any embodiment of the first aspect, as described in steps 210-250 and 410-460. The user terminal can be a mobile terminal device or a fixed-line terminal device.

[0194] Image server 1302 is used to store and provide the image data of the physical examination report.

[0195] The notification server 1303 is used to push medical examination instruction data containing the application identifier to the user terminal or medical examination institution system.

[0196] Figure 11 This is a structural diagram of an embodiment of the server-side device of this application.

[0197] This application also proposes a server-side device for implementing the automated underwriting assessment method described in any embodiment of this application. The server-side device is used to perform, for example... Figure 9 The functions described in steps 210-250 and 310-360 are a server or server cluster 800, which includes a business acceptance service module 801, an underwriting processing service module 802, a data notification service module 803, a first database 804, a second database 805, and a third database 806 that are interconnected.

[0198] The business acceptance service module 801 is used to receive data from the terminal device, including: request data (containing insurance information), application identifier and processing confirmation instruction.

[0199] The underwriting processing service module 802 is used to determine whether physical examination instruction data needs to be generated in response to the request data; and to determine and schedule the intelligent evaluation and processing flow of the physical examination report image data in response to the processing confirmation instruction.

[0200] The data processing service module 802 is used to perform core data processing and communication, and its specific functions include:

[0201] The physical examination instruction generation is based on the instruction of the determination module 802 and the first database 804, and generates physical examination instruction data containing the application identifier.

[0202] Image acquisition: Based on the application identifier, acquire the physical examination report image data from the connected external system.

[0203] Intelligent assessment and processing: Performs a series of processing steps on the image data of the physical examination report, such as character recognition, medical terminology mapping, and large language model parsing, to generate structured physical examination indicator data.

[0204] Underwriting conclusion generation: Based on the structured medical examination index data and the third database 806, underwriting conclusion data is generated.

[0205] The data notification service module 803 is used to send the first response dataset, the second response dataset, and the third response dataset.

[0206] The first database 804 (physical examination triggering and instruction rule base) stores the mapping relationship between preset insurance information elements and physical examination triggering conditions and physical examination instruction content. For example, it stores the correspondence between conditions such as "insured amount > threshold X" or "age > threshold Y" and "physical examination notice needs to be issued" and corresponding physical examination item instructions. It is used to replace the process of manually judging physical examination needs and formulating notices in the prior art, realizing automatic triggering and instruction generation.

[0207] The second database, 805 (Underwriting Medical Terminology Mapping and Knowledge Base), stores the mapping rules for underwriting medical terminology and serves as domain knowledge support for the professional parsing of the large language model. It maps non-standardized clinical descriptions from various medical institutions (such as "sinus rhythm") to standardized underwriting terms (such as "normal heart rate"), and provides the large language model with contextual knowledge to guide its accurate extraction of physical examination indicators (such as lesion size and location). This addresses the problems of inconsistent formats and significant differences in terminology in physical examination reports, enabling precise structuring of complex medical texts (especially ultrasound and imaging reports).

[0208] The third database 806 (underwriting decision rule base) stores the pre-defined mapping relationship between insurance products and underwriting evaluation rules. It receives structured medical examination indicator data from the processing module, performs logical calculations and matching according to established rules, and outputs conclusions such as "standard coverage," "conditional coverage," or "rejection." This serves to replace the experience-based judgment of human underwriters, achieving automated and standardized decision-making in underwriting.

[0209] The specific methods for implementing the server receiving module 801, determining module 802, processing and sending module 803, and each database function are as described in the various method embodiments of this application, and will not be repeated here.

[0210] Figure 12 This is a structural diagram of an embodiment of the terminal device of this application.

[0211] This application also proposes a terminal device for implementing the automated underwriting assessment method described in any embodiment of this application, wherein the terminal device is used to perform, for example... Figure 5 And the functions described in steps 410-460.

[0212] To implement the above technical solution, this application proposes a terminal device 900, which includes a terminal transmitting module 901, a terminal receiving module 902, and a terminal determining module 903 connected to each other.

[0213] The terminal sending module 901 is used to send data to the server device, including: request data (containing insurance information), application identifier and processing confirmation instruction.

[0214] The terminal receiving module 902 is used to receive response datasets from the server-side device, including: a first response dataset (containing physical examination instruction data), a second response dataset (containing physical examination report image data), and a third response dataset (containing underwriting conclusion data).

[0215] The terminal determination module 903 is used to perform the following functions:

[0216] Determine the content of the request data to be sent, the application identifier, and the processing confirmation instruction.

[0217] Determine subsequent operations associated with the first response dataset, such as providing an online medical examination appointment interface.

[0218] Determine subsequent operations associated with the second response dataset, such as providing a confirmation interface for the medical examination report image data.

[0219] Determine subsequent actions associated with the third response dataset, such as displaying the underwriting conclusion and related information.

[0220] The specific methods for implementing the functions of the terminal sending module 901, the terminal receiving module 902, and the terminal determining module 903 are as described in the various method embodiments of this application, and will not be repeated here.

[0221] Figure 13 A schematic diagram of a server-side device according to another embodiment of this application is shown. As shown, the server-side device 1000 includes a processor 1001, a communication interface 1002, and a memory 1003. The communication interface is used to implement communication functions with terminal devices and external medical examination systems. The memory 1003 stores a computer program, which, when executed by the processor 1001, is used to implement the steps performed by the server in the automated underwriting assessment method as described in any embodiment of this application (such as...). Figure 4 (as described in steps 310-360). The processor 1001, communication interface 1002, and memory 1003 are interconnected and work together through a bus system.

[0222] Figure 14 A block diagram of a terminal device according to another embodiment of this application is shown. The terminal device 1100 includes at least one processor 1101, a memory 1102, a user interface 1103, and at least one network interface 1104. The various components in the terminal device 1100 are coupled together via a bus system. The user interface 1103 includes a display, keyboard, or touchscreen, etc., for running an automated underwriting assessment interactive interface. The memory 1102 stores a computer program, which, when executed by the processor 1101, is used to implement the steps performed by the terminal device in the automated underwriting assessment method as described in any method embodiment of this application (such as...). Figure 5 (as described in steps 410-460). The network interface 1104 is used to enable communication with the server.

[0223] Those skilled in the art will understand that the embodiments of this application can be provided as methods 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. Based on the embodiments in this application, the developed automated underwriting assessment system can automate the entire process of processing customer medical examination reports, replacing manual underwriting in the underwriting stage, or providing pre-underwriting conclusions at the sales front end, effectively improving underwriting efficiency, accuracy, and consistency, enhancing customer experience, and promoting the high-quality development of insurance business.

[0224] Furthermore, this application may take the form of a computer program product implemented 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.

[0225] For example, the memory 1003, 1102 of this application may include non-permanent memory in a computer-readable medium, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM.

[0226] Therefore, this application also proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the automated underwriting assessment method as described in any method embodiment of this application.

[0227] The automated underwriting assessment method, device, and system provided in this application integrate intelligent image recognition, medical terminology mapping, and large language model parsing technologies to achieve fully automated processing and intelligent underwriting decisions for medical examination reports. This system significantly improves the efficiency, accuracy, and standardization of underwriting operations, effectively replacing manual labor in the underwriting process, reducing operating costs, and enhancing the customer's insurance application experience.

[0228] 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 process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0229] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when an element is “connected” or “coupled” to another element, it may be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein may include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0230] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical, terminological, and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

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

Claims

1. An automated underwriting assessment method, characterized in that, Including the following steps: Obtain medical examination report imaging data and related insurance application information; The image data of the physical examination report is subjected to character recognition to obtain text data; According to the underwriting medical terminology mapping rules, the text data is converted into formatted input data; The formatted input data is input into a large language model to obtain structured physical examination index data; the structured physical examination index data includes at least one examination item extracted from the text data and its corresponding value or description; The structured medical examination index data is logically matched with a pre-configured underwriting rule knowledge base to generate the underwriting conclusion data.

2. The automated underwriting assessment method as described in claim 1, characterized in that, The acquisition of the medical examination report image data is performed based on the application identifier associated with the insurance application information; The application identifier is generated when the insurance application information meets preset conditions, which include at least one of the following: The insured amount exceeds a preset threshold; The insured's age exceeds a preset threshold; The health disclosure questionnaire contained specific markers of positive medical history. The insured product is classified as a high-risk product.

3. The automated underwriting assessment method as described in claim 1, characterized in that, Before character recognition processing, the following steps are included: The physical examination report image data is subjected to image quality detection and / or serialization sorting processing.

4. The automated underwriting assessment method as described in claim 1, characterized in that, Before performing character recognition processing, the following steps are also included: The physical examination report image data is segmented by department to obtain sub-image data corresponding to different departments; The character recognition is performed separately for each of the sub-image data.

5. The automated underwriting assessment method as described in claim 1, characterized in that, The formatted input data includes prompt word templates to guide the large language model to output the structured physical examination index data according to a predetermined data structure.

6. The automated underwriting assessment method as described in claim 1, characterized in that, The underwriting rule knowledge base contains coded judgment rules and their corresponding threshold parameters. The logical matching involves comparing the numerical values ​​or descriptions in the structured physical examination indicator data with the threshold parameters and executing the judgment rules.

7. An automated underwriting assessment device, used to implement the automated underwriting assessment method as described in any one of claims 1 to 6, characterized in that, include: The acquisition module is used to acquire image data from a physical examination report and related insurance application information; and to perform character recognition on the image data from the physical examination report to obtain text data. The conversion module is used to convert the text data into formatted input data according to the underwriting medical terminology mapping rules; The generation module is used to input the formatted input data into a large language model to obtain structured physical examination indicator data; and to logically match the structured physical examination indicator data with a pre-configured underwriting rule knowledge base to generate underwriting conclusion data.

8. An automated underwriting assessment system, characterized in that, Include: An underwriting server is deployed with the apparatus as described in claim 7, or configured to perform the method as described in any one of claims 1 to 6; The user terminal is connected to the underwriting server and is used to provide an interface for inputting insurance application information and an interface for confirming medical examination report images. An image server is used to store and provide the image data of the physical examination report; The notification server is used to push medical examination instruction data containing the application identifier to the user terminal or medical examination institution system.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 6.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 6.

Images