A method and system for automatically generating a dental laboratory order mail draft

Abstract

The present application relates to the field of dental data processing, and more particularly to a dental technology work order mail draft automatic generation method and system, a first source instruction table and a second source instruction table are obtained, corresponding data extraction rules are determined according to the table source type, instruction fields and customer identification fields are extracted, and format preservation processing is performed on the dental site field to output in text form; a mail subject index cache is established or updated according to the customer identification field, historical mail records are retrieved in the cache, if retrieved, it is marked as a reply type and mail header information is obtained, and if not retrieved, it is marked as a new mail type; the instruction field is filled into the mail template to generate mail content data, and the mail header parameters are determined according to the mail type; a mail draft is generated and saved to the draft box. The present application can automatically complete the analysis of dental order instructions and the generation of mail drafts, and reduce the efficiency and accuracy problems of manual operation.

Description

Technical Field

[0001] This application relates to the field of dental data processing technology, and in particular to a method and system for automatically generating dental technician order email drafts. Background Technology

[0002] In the dental technician order processing process, communication between dental labs and dental clinics is primarily conducted via email. Customer service personnel need to draft the order instructions sent by customers into emails before sending them to ensure accurate transmission of order information and to create a written record. Order instructions are mainly in the form of Excel spreadsheets, typically containing patient information, tooth position numbers, restoration types, material requirements, processing deadlines, etc. The same order may also include two separate files: a scanned case order sheet and a physical document Linex instruction sheet, along with several STL dental model files, and intraoral or model photos as attachments. Currently, the drafting of these emails is entirely manual. Customer service personnel need to open each instruction sheet, identify and copy the valid information, manually search the inbox and sent emails for historical emails from the same customer or order to avoid duplicate communication or opening the wrong email thread, find the corresponding attached images, and finally paste all the above content into the email body and save it as a draft. The entire process involves a large number of repetitive operations, and different customer service personnel may have different processing methods, making it difficult to guarantee consistent results.

[0003] Furthermore, dental instruction forms contain some easily overlooked technical details. Tooth position data in these forms is often recorded in formats such as "3 / 4," "11," and "8," with fractions like "3 / 4" easily converted to date formats in Excel. Additionally, the position of the tooth position field is not fixed, and there is no standardized naming convention for column headings, leading to uncertainty when reading data. A deeper problem lies in the existence of multiple parallel tooth position marking standards in dentistry (such as the FDI standard and the Universal numbering standard). The same tooth position number may point to different tooth locations under different standards, and most instruction forms do not indicate which standard they use, creating inherent ambiguity in the accurate interpretation of tooth position information. When two forms for the same order use different standards, manual interpretation is easily confused. Summary of the Invention

[0004] To address one or more problems in the prior art, the main objective of this application is to provide a method and system for automatically generating dental technician order email drafts.

[0005] To achieve the aforementioned objectives, this application proposes a method for automatically generating dental technician order email drafts, the method comprising: Obtain the first source instruction table and the second source instruction table; The first source instruction table and the second source instruction table are analyzed separately. Based on the source type of each instruction table, the corresponding data extraction rules are determined, and the instruction field and customer identifier field in each instruction table are extracted. During the extraction process, the tooth position field is processed to preserve the format, and the original input content of the instruction table is preserved in text form. Based on the customer identifier field, establish or update the email subject index cache, which is used to record the correspondence between processed email subjects and the customer identifier field; Retrieve historical email records that match the customer identifier field in the index cache. If a record is found, obtain the thread association information of the historical email and mark it as a first type. If no record is found, mark it as a second type. The instruction fields are filled into the email template according to a preset mapping relationship to generate email content data; Based on the first type or the second type, and in conjunction with the thread association information, determine the email header parameters for the email draft to be generated; An email draft is generated based on the email content data and the email header parameters, and the email draft is saved to the drafts folder.

[0006] This application also provides a system for automatically generating dental technician order email drafts, including: The acquisition module is used to acquire the first source instruction table and the second source instruction table; The parsing and extraction module is used to parse the first source instruction table and the second source instruction table respectively. Based on the source type of each instruction table, it determines the corresponding data extraction rules and extracts the instruction field and customer identifier field from each instruction table. During the extraction process, the tooth position field is processed to preserve the format, and the original input content of the instruction table is preserved in text form. The module is used to establish or update the email subject index cache based on the customer identifier field. The index cache is used to record the correspondence between processed email subjects and the customer identifier field. The retrieval module is used to retrieve historical email records that match the customer identifier field in the index cache. If a record is found, the thread association information of the historical email is obtained and it is marked as a first type. If no record is found, it is marked as a second type. The generation module is used to fill the instruction fields into the email template according to a preset mapping relationship to generate email content data; The determination module is used to determine the email header parameters of the email draft to be generated based on the first type or the second type and in combination with the thread association information. The save module is used to generate an email draft based on the email content data and the email header parameters, and save the email draft to the drafts folder.

[0007] This application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described above.

[0008] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the methods described above.

[0009] The method and system for automatically generating dental technician order email drafts in this application form a complete end-to-end automated process from obtaining the instruction table to generating and saving the email draft, eliminating the need for manual switching between steps. By automatically matching extraction rules based on the source type, customer service personnel do not need to remember the field distribution of the scanned document table and the physical document table; they only need to submit the files to the system to complete data extraction. During the extraction stage, the tooth position field is format-preserving, ensuring that tooth position combinations containing slashes are preserved in their original form, avoiding information loss caused by the table processing software mistakenly converting tooth position data to dates during parsing. The system automatically establishes an email subject index cache after the first run, and only incrementally updates new emails thereafter. Historical email verification does not require searching through each email individually or relying on remote retrieval from the mail server, and retrieval efficiency does not decrease with the increase in the total number of emails. After retrieving historical emails, the system automatically obtains the thread association information in the email header, ensuring that newly generated drafts can be accurately assigned to existing email threads or used as the starting point of a new thread, preventing communication for the same order from being scattered across multiple unrelated threads. The final draft is saved to the drafts folder instead of being sent directly, retaining the manual review step and balancing processing efficiency and security. This allows customer service personnel to complete the entire process from the original form to the email to be sent with the assistance of the system. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a method for automatically generating dental technician order email drafts according to an embodiment of this application. Figure 2 This is a flowchart illustrating a method for automatically generating dental technician order email drafts according to an embodiment of this application. Figure 3 This is a schematic block diagram of a dental technician order email draft automatic generation system according to an embodiment of this application; Figure 4 This is a schematic block diagram of the structure of a computer device according to an embodiment of this application.

[0011] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] Reference Figure 1 This application provides a method for automatically generating draft dental technician order emails, the method comprising: S1. Obtain the first source instruction table and the second source instruction table; S2. Parse the first source instruction table and the second source instruction table respectively. Based on the source type of each instruction table, determine the corresponding data extraction rules and extract the instruction field and customer identifier field from each instruction table. During the extraction process, perform format preservation processing on the tooth position field to preserve the original input content of the instruction table in text form. S3. Based on the customer identifier field, establish or update the email subject index cache, wherein the index cache is used to record the correspondence between processed email subjects and the customer identifier field; S4. Retrieve historical email records that match the customer identifier field in the index cache. If a record is found, obtain the thread association information of the historical email and mark it as the first type. If no record is found, mark it as the second type. S5. Fill the instruction field into the email template according to the preset mapping relationship to generate email content data; S6. Based on the first type or the second type, and in conjunction with the thread association information, determine the email header parameters for the email draft to be generated; S7. Generate an email draft based on the email content data and the email header parameters, and save the email draft to the drafts folder.

[0014] As described in steps S1-S2 above, the method for automatically generating dental technician order email drafts provided in this embodiment of the invention can be deployed on a server computer. Customer service personnel can access the web service page of the server computer through a browser to operate it. The server computer is pre-configured with operating parameters such as mail server connection parameters, translation interface call parameters, and image storage paths. These parameters are centrally stored in a configuration file for easy maintenance and modification later. In actual operation, customer service personnel drag or select the scanned case order sheet and physical document Linex instruction sheet corresponding to the dental order to be processed, and submit them to the server through the upload area provided by the web interface. For ease of description, the scanned document sheet is referred to as the first source instruction sheet, and the physical document sheet is referred to as the second source instruction sheet. After receiving the above sheet files, the server saves them to the specified input directory. Subsequently, the server parses each received sheet file separately. Because scanned document tables and physical document tables typically differ in field arrangement, column header naming conventions, and data formats—for example, the first three columns of a scanned document table might be patient name, tooth position number, and restoration type, while the same information in a physical document table might be distributed across columns four through six—the system needs to invoke corresponding data extraction rules based on the table's source type. Specifically, during parsing, the server first identifies whether the currently processed table belongs to the primary or secondary source. Then, based on the identification result, it selects the mapping table corresponding to that source type from multiple pre-set field mapping tables. Following the correspondence between the column positions recorded in the mapping table and the target fields, it reads the required data from the specified column positions in the table. The extracted target data includes at least the customer identification field of the order and the instruction fields needed for subsequent emails.

[0015] It is worth noting that this embodiment performs special format preservation processing on the tooth position field in the table during the extraction of instruction fields. Since tooth position data in dental tables often appears in fractional form, for example, a row with "3 / 4" in the tooth position field indicates that the order involves a combination of the third and fourth teeth. However, in common spreadsheet software, this type of input containing forward slashes is easily automatically recognized as a date format and converted to a date sequence value for storage, resulting in a discrepancy between the actual data type stored in the cell and the text format expected by the user. If the displayed value or numerical value of the cell is read directly, the result will not be the original "3 / 4" but a date or an incorrect value. Therefore, this embodiment does not directly use the default value retrieval method of the spreadsheet software when extracting the tooth position field. Instead, it obtains the original data storage state of the cell and outputs the original content entered in the cell as text. After this processing, regardless of how the spreadsheet software interprets the data type of the cell internally, the final extracted tooth position information always remains consistent with the content initially entered by the user in the table, thus avoiding information distortion caused by automatic format conversion. After the above parsing and extraction process, the system obtained cleaned instruction table data, which contains all the field information required for subsequent email generation, and the tooth position field has been correctly preserved in text format.

[0016] As described in steps S3-S4 above, after determining the email pattern, the instruction fields extracted in the first step need to be organized into email content. Fields extracted from instruction tables from different sources may belong to different aspects of the same order. For example, the scanned document table may record the patient's basic information and tooth position number, while the physical document table may record specific processing materials, color requirements, and delivery deadlines. The instruction fields of the same order are filled into the corresponding positions in the email template according to a preset mapping relationship. The email template is a pre-defined format framework that defines the email subject format, body structure, and the order of each field. For example, the email subject combines the customer name, order number, and date into a fixed-format subject string according to agreed rules, while the body arranges the patient name, tooth position number, restoration type, material requirements, processing deadline, and reminders into a clearly structured table or paragraph format. During the filling process, instruction fields from different tables are also matched based on the customer identifier field. When a customer identifier appears in multiple instruction tables, the system merges the instruction fields from these tables into the data record of the same order. If certain instruction fields exist in multiple tables with inconsistent content, the system selects data from one of the tables as the basis for filling, according to a preset priority rule. After this processing, a complete email content dataset containing the email body and subject is generated. This data is stored locally in a structured format for use in subsequent steps. As described in steps S4-S7 above, after the email content data is ready, it is necessary to determine how to construct the underlying communication structure of the email based on the email pattern determined in step two. Email communication relies on several key fields carried in the email header. When an email is a reply to an existing email, the email header needs to include an identifier field for the replied email and a referenced email list field. The former indicates which specific email this email is replying to, and the latter records the complete tracking path of the entire email thread. Email clients rely on these two fields to chain multiple emails together into a single thread for display. If the current order is marked as a reply type, the unique identifier of the email and the referenced email list information from the historical email records will be retrieved when generating the email draft. The unique identifier of the historical email is filled into the identifier field of the replied email in the draft to be generated, and the unique identifier is also appended to the end of the referenced email list field of the draft to be generated. After this setting, when the customer opens this draft in the email client and finally sends it, the email will automatically appear below the original email thread, thus maintaining the continuity of the communication record. If the current order is marked as a new email type, the draft to be generated does not need to set the identifier field and referenced mailing list field for the reply email; the draft will be treated as the starting email of an independent email session. After completing the email header parameter settings, the email content data, email subject, and email header parameters are combined into a complete email draft. At this time, the system does not send the email directly, but connects to the draft folder of the mail server via the Internet Message Access Protocol (IMP) and writes the email draft to the draft folder. Customer service personnel can then open the draft folder in the email client to view the generated draft content, make final edits and confirmations on the email body, verify the completeness of attachments, and manually click send after confirming that everything is correct. This "generate to draft folder, manually review and send" processing method leverages the high efficiency of automated generation while retaining the security mechanism of final human review, avoiding the risk of sending erroneous information directly to the customer due to system parsing errors or data anomalies.

[0017] As described above, the entire process from obtaining the instruction form to generating and saving the email draft forms a complete end-to-end automated workflow, eliminating the need for manual switching between steps. By automatically matching extraction rules based on the source type, customer service personnel do not need to remember the field distribution of the scanned document form and the physical document form; they only need to submit the files to the system to complete data extraction. During the extraction process, the tooth position field is formatted, ensuring that tooth position combinations containing slashes are preserved in their original form as filled in, avoiding information loss caused by the form processing software mistakenly converting tooth position data to dates during parsing. The system automatically establishes an email subject index cache after the first run, and subsequent updates are only incrementally added emails. Historical email verification does not require searching through each email individually or relying on remote retrieval from the mail server, and retrieval efficiency does not decrease with the increase in the total number of emails. After retrieving historical emails, the system automatically obtains the thread association information in the email header, ensuring that newly generated drafts can be accurately assigned to an existing email thread or used as the starting point of a new thread, preventing communication for the same order from being scattered across multiple unrelated threads. The final draft is saved to the drafts folder instead of being sent directly, retaining the manual review step and balancing processing efficiency and security. This allows customer service personnel to complete the entire process from the original form to the email to be sent with the assistance of the system.

[0018] In one embodiment, prior to performing format preservation processing on the tooth position field, the method further includes identifying the tooth position field in the instruction table, including: Get the column header of the current cell or the top row field of the current cell; Match the column header or the row header field with a preset tooth position keyword library to determine the matching result; If a match is successful, the current column or row will be recognized as the tooth position field; If the match fails, retrieve the data content of each cell in the current column or row, calculate the string length of the data content of each cell and count the length distribution, count the proportion of numeric characters in the data content of each cell, and count the ratio of the number of duplicate values ​​in the data content of each cell to the total number of cells. If the mode of the length distribution is less than or equal to the first preset threshold, the proportion of the numeric characters falls within a preset value range, and the ratio is less than or equal to the second preset threshold, then the current column or the current row is identified as a tooth position field. If the mode of the length distribution is greater than the first preset threshold, or the proportion of numeric characters does not fall within the preset value range, or the ratio is greater than the second preset threshold, then the current column or the current row is identified as a non-tooth position field, and the process jumps to the next column or the next row to perform matching again.

[0019] As mentioned above, parsing the instruction table requires extracting the tooth position field. However, in actual business scenarios, the column position of the tooth position field varies across instruction tables from different sources. Some tables place the tooth position information in the third column, while others place it in the fifth; some tables use column headers for labeling, while others do not set any column headers at all. Furthermore, the naming conventions for column headers lack uniformity; Chinese tables may use "tooth position" or "tooth position," while English tables may use "TOOTH" or "TOOTH," and some tables even use abbreviations or numbers instead of full headers. Therefore, before performing format preservation processing for the tooth position field, it is first necessary to determine which column or row in the table belongs to the tooth position field.

[0020] This embodiment employs a two-stage recognition mechanism to accomplish this task. The first stage is based on matching and recognition using column headers or row header fields. The column header of the current cell is read, or, if the table organizes data by rows, the row header field is read, and this text is matched against a pre-defined keyword library for tooth positions. This keyword library pre-includes commonly used dental terms related to tooth positions, such as tooth position, dentition, TOOTH, and various common abbreviations and variations. If a match is successful, it means the column header clearly indicates that its content belongs to tooth position data, and the current column or row is directly identified as a tooth position field. Subsequent formatting processing will be performed on that column or row. However, relying solely on header matching has significant coverage limitations. If the table does not have column headers, or if the header uses an unconventional naming method not included in the keyword library, header matching will fail. At this point, the second stage begins, analyzing the characteristics of the data content itself in each cell of the column or row, using the inherent patterns of the data to determine whether it belongs to a tooth position field. The analysis in the second stage is based on the inherent characteristics of tooth position data across three statistical dimensions. The first dimension is string length. While tooth position numbers are represented in various forms in tables, their length is generally short. A single tooth position number typically does not exceed two characters, and even combined tooth position numbers, including those containing forward slashes or hyphens, are generally between four and six characters long. In contrast, fields such as patient names, addresses, remarks, and product descriptions in tables often contain long text, with character lengths significantly exceeding the typical length range of tooth position numbers. By statistically analyzing the string length distribution of all non-empty cells in the column or row, and taking the most frequent length value as the mode, if the mode is less than or equal to a preset threshold, it indicates that the data in that column is predominantly short strings, consistent with the basic length characteristics of tooth position data. The second dimension is the proportion of numeric characters. The core component of tooth position numbers is numbers; whether it's a single tooth number or a combined tooth position representation, it inevitably contains numeric characters. Furthermore, tooth position numbers are not purely continuous numbers; combined tooth position numbers contain separators such as forward slashes or hyphens, which means that the proportion of numeric characters in all characters in this field usually falls within a specific range. The first dimension is the percentage of numeric characters in each cell's data content relative to the total number of characters in that cell. Then, the statistical value of this percentage is calculated for all cells in that column or row. If this statistical value falls within a preset range, it indicates that the data in that column matches the characteristics of the tooth position field in terms of numeric content. The third dimension is the repetition rate of the deduplicated values. In a dental instruction table, although the tooth position number in the same column may have several different values, the total number of tooth positions is limited, and the number of these possible values ​​is far less than the total number of rows in that column. In other words, different tooth position numbers will appear repeatedly in that column. For example, a column may contain fifty rows of data, but its tooth position number may only have a dozen or so possible values, and each value may appear multiple times in the table.The number of unique values ​​in a column or row after deduplication is counted, and the ratio of this number to the total number of cells is calculated. If this ratio is less than or equal to a preset threshold, it indicates that the data in that column has a high repetition rate, which matches the value distribution characteristics of tooth position data. Only when all three conditions mentioned above are met is the column or row identified as a tooth position field. All three conditions are indispensable, constraining the data format of the tooth position field from the perspectives of length constraint, numerical content constraint, and value repetition rate constraint, thereby distinguishing the column from other types of fields. If any condition is not met, the current column or row is determined to be a non-tooth position field, and the column or row is skipped, continuing to check the next column or row. In specific implementations, the specific values ​​of the above thresholds can be set and adjusted according to the statistical distribution of actual business data. For example, the first preset threshold can be set to 4 or 5, the preset value range can be set to 20% to 90%, the second preset threshold can be set to 50%, etc. These values ​​do not constitute a limitation on the scope of protection of this invention. After the above two-stage identification process, it is finally determined which column or row in the current instruction table belongs to the tooth position field, and then the aforementioned format preservation processing can be performed on the tooth position data in that column or row in subsequent steps.

[0021] Reference Figure 2 In one embodiment, the method for performing format preservation processing on the tooth position field includes: S21. Read the original data storage value of the cell containing the tooth position field; S22. Obtain the original data type identifier of the cell, wherein the original data type identifier includes a date type identifier, a numeric type identifier, and a text type identifier; S23. If the original data type identifier is a date type identifier, then the original data storage value is converted into a date format string in reverse according to the original input format of the cell and then output. S24. If the original data type identifier is a numeric type identifier, then the original data storage value is directly converted into text format and output. S25. If the original data type identifier is a text type identifier, then the original data storage value is directly read and output.

[0022] As described above, after locating the tooth position field, the next step is to perform format preservation processing on the located tooth position field. As mentioned earlier, tooth position data in dental spreadsheets is at risk of being automatically formatted in common spreadsheet software. A typical scenario is that when a user enters a tooth position combination like "3 / 4" in a spreadsheet cell, the spreadsheet software will determine that the input conforms to a common date expression and automatically recognize and store it as date data. The cell actually stores a string of date sequence values, not the "3 / 4" text initially entered by the user. While the cell display may present a visual effect similar to "March 4th," the underlying stored data has lost its original input information.

[0023] To address this issue, this embodiment does not use the conventional method of directly reading the cell display value or numerical value when performing format preservation processing. Instead, it first reads the original data storage value of the cell from the spreadsheet file. This original data storage value is the actual data entity stored in the cell and is not affected by the spreadsheet software's display settings or formatting rules. After reading the original data storage value, the original data type identifier of the cell is further obtained. Different spreadsheet software records the data type information of each cell in the file structure when storing cell data, indicating whether the cell stores a date, a number, or plain text. This data type identifier is written by the spreadsheet software based on its automatic judgment logic when the user inputs data, reflecting the software's internal determination of the cell's data type. Common type identifiers include date type identifiers, number type identifiers, and text type identifiers. After obtaining the original data type identifier, branch processing is performed according to the type indicated by the identifier. If the original data type identifier is a date type identifier, it means that the spreadsheet software judged the content as a date when the user input it and performed date format conversion for storage. At this point, the original data storage value contains a date sequence value or a date string, while the user's original input might be a combination of tooth positions such as "3 / 4", "1-2", or "4 / 5". To restore the stored date data to the user's original text format, this embodiment reverses the date data to a date format string according to the cell's original input format before outputting it. Different versions of spreadsheet software follow different conversion rules when converting text to dates, but the original text input pattern is limited. Based on the cell's original data type identifier and the spreadsheet file's regional language settings, the original input format can be determined, thus allowing the date data to be reversed back to the corresponding text expression. If the original data type identifier is a numeric type identifier, it means the spreadsheet software stored the content as a numeric value, and the original data storage value contains a numeric tooth position number, such as the user-input number sequence "11" or "8", etc., without any fundamental change in format after storage. In this case, the original data storage value can be directly converted to text format and output, with the output content being the same as the user's input. If the original data type identifier is text, it means the spreadsheet software recognizes the content as text and stores it as is; the original data storage value contains the text content initially entered by the user. In this case, the original data storage value is directly read and output without any format conversion. After the above branch processing, regardless of the data type recorded at the underlying layer of the spreadsheet file, the final output will always be the content initially entered by the user in the spreadsheet, thus ensuring that the data type field can be used correctly in the subsequent email content generation process.To illustrate the process with a common example, when a user enters "3 / 4" in a cell, the spreadsheet software might mark the cell's data type as a date when saving the file and record the stored value as a date sequence value corresponding to a certain year. In this embodiment, when it reaches that cell, it first reads the cell's original data storage value as a date sequence value, then obtains the data type identifier as a date type. Therefore, it reverses the date conversion rules followed when the cell was entered, ultimately outputting "3 / 4" instead of the converted date expression.

[0024] In one embodiment, after the step of extracting the instruction fields and customer identifier fields from each of the instruction tables, and before the step of filling the instruction fields into the email template, the method further includes: Obtain the first tooth position number value from the first source instruction table and the second tooth position number value from the second source instruction table; Based on the numerical range distribution characteristics and format characteristics of the tooth position number values ​​in the first source instruction table, a first candidate standard corresponding to the first tooth position number value is determined; based on the numerical range distribution characteristics and format characteristics of the tooth position number values ​​in the second source instruction table, a second candidate standard corresponding to the second tooth position number value is determined. The first tooth position number value is mapped to a first tooth position entity set according to each of the first candidate standards, and the second tooth position number value is mapped to a second tooth position entity set according to each of the second candidate standards; Compare the first set of tooth entities with the second set of tooth entities. If there is a first candidate standard and a second candidate standard that make the first set of tooth entities consistent with the second set of tooth entities, then the candidate standard shall be used as the target standard for the first source instruction table and the second source instruction table respectively. If, after traversing all candidate standard combinations, there is no first candidate standard and second candidate standard that make the first tooth position entity set consistent with the second tooth position entity set, then a data inconsistency flag is generated, and the data inconsistency flag is associated with and stored in the customer identifier field of the current order.

[0025] It's worth noting that after extracting the instruction and customer identification fields, the tooth position numbers from the instruction field need to be populated into the email template. However, a deeper problem arises at this point. Multiple parallel tooth position marking standards exist in the dental field. The International Dental Federation standard divides the oral cavity into four quadrants: the upper right quadrant is numbered 1, the upper left 2, the lower left 3, and the lower right 4. Each tooth within this quadrant is numbered sequentially from 1 to 8 from the center outwards, resulting in two-digit tooth position numbers, such as 11 representing the upper right first incisor. The General Numbering Standard numbers all teeth clockwise from the upper right to 32, so the same tooth might be represented as the number 8 under this standard. The Pelmer standard uses symbols to represent quadrants and numbers 1 to 8 to represent tooth positions. All these standards are used clinically, and different regions, clinics, and even dental labs use different standards. This creates a recognition dilemma. When a form contains a tooth position number, such as the number 8, it's impossible to determine which tooth that number refers to without knowing which standard the form uses, as this number may represent different tooth positions in different standards. Most instruction forms don't specify which standard they use when they are created, and since scanned and physical document forms are often created by different people at different times, the two forms may use different standards. Customer service personnel often rely on experience to make judgments when processing manually, and misjudgments are prone to occur when faced with unfamiliar forms.

[0026] To address this issue, this embodiment introduces a standard identification and mapping mechanism based on dual-table cross-validation after extracting the instruction fields and before filling the tooth position numbers into the email template. First, the extracted tooth position number values ​​are obtained from the first source instruction table, referred to as the first tooth position number values. The extracted tooth position number values ​​are also obtained from the second source instruction table, referred to as the second tooth position number values. Typically, the scanned document table and the physical document table for the same order each contain several tooth position numbers, which reflect all or some of the tooth positions involved in the order. Then, based on the numerical range distribution characteristics and format characteristics of the tooth position number values ​​in the first source instruction table, the tooth position marking standard that the table may adopt is determined, referred to as the first candidate standard. The numerical range distribution characteristics refer to the overall numerical distribution of all tooth position numbers in the table. For example, if all numbers fall within the range of 11 to 48, with tens digits all between 1 and 4, and units digits all between 1 and 8, then it conforms to the numbering rules of the International Dental Federation standard; if all numbers fall within the range of 1 to 32, it may conform to the general numbering standard or the American Dental Association standard. Format features refer to the way tooth position numbers are written, such as whether the number contains slashes, hyphens, or quadrant symbols. Different standards have different inherent characteristics in the numbering range and various format features. Based on these characteristics, it is possible to preliminarily determine which standard(s) the table adopts.

[0027] Specifically, because the International Dental Federation (IDF) standard numbers are always two digits with the tens digit being only 1 to 4, the general numbering standard numbers are integers from 1 to 32 with a specific partitioning order, the American Dental Association (ADA) standard numbers are also from 1 to 32 but with a different partitioning order, and the Pelmer standard numbers are only from 1 to 8 and used in conjunction with quadrant symbols, the numerical range distribution and format characteristics of all tooth position numbers in the same table together constitute the basis for determining the standard to which it belongs. In actual implementation, there may be only one first candidate standard, or there may be multiple candidate standards. Similarly, the second candidate standard is determined based on the tooth position number values ​​in the second source instruction table. After obtaining the respective candidate standards, the first tooth position number values ​​are mapped to the corresponding tooth position entity set according to each first candidate standard. The tooth position entity set refers to a group of tooth entities obtained after interpreting the number according to a specific standard. Each tooth has a unique spatial location anatomically. For example, the tooth numbered 11 in the IDF standard and the tooth numbered 8 in the general numbering standard, although different in numbering format, both point to the same physical tooth after being mapped to a tooth position entity. Therefore, mapping the first tooth position number value to an entity set according to a certain standard yields a list of definite spatial locations. If mapped according to another standard, the entity sets will differ because the same number may correspond to different tooth positions in different standards. Similarly, the second tooth position number value is mapped to a second tooth position entity set according to each of the second candidate standards. Next, the first tooth position entity sets are compared with the second tooth position entity sets. The core logic of the comparison is that the scanned document table and the physical document table for the same order describe the same set of teeth. Therefore, regardless of the standard used by each table, as long as they are interpreted according to the correct standard, the mapped tooth position entity sets should be the same. If both tables use the correct standard, the two entity sets should be consistent; if one table's candidate standard is incorrect, the mapped entity set will not match the other table. Therefore, one candidate standard is selected from the first candidate standard, and one candidate standard is selected from the second candidate standard. These are then combined, mapped to entity sets, and compared. If a set of candidate standards exists that makes the two entity sets completely consistent, it means that this set of standards can unify the interpretation of tooth positions in the two tables. Based on this, the first candidate standard in this set is determined to be the target standard for the first source instruction table, and the second candidate standard is determined to be the target standard for the second source instruction table. If, after traversing all combinations of candidate standards, no set of candidate standards can be found that makes the two entity sets consistent, it means that there is a fundamental conflict in the interpretation of tooth position information in the two tables that cannot be eliminated by standard selection. In this case, a data inconsistency flag is generated and associated with the customer identifier field of the current order for subsequent manual verification.

[0028] In one embodiment, after the step of determining the second candidate criterion corresponding to the second tooth position number value, the method further includes: Obtain the order type information of the current order, which is extracted from the instruction field; Determine whether the current order meets the preset space verification trigger condition based on the order type information; If satisfied, a spatial verification step is performed, which includes continuity verification and symmetry verification. If the condition is not met, the spatial verification step is skipped, and the tooth position number value is filled into the email template according to the target standard.

[0029] As mentioned above, after the dual-table cross-validation is completed, i.e., after the target standards of the first and second source instruction tables have been determined, the tooth position number values ​​need to be filled into the email template according to the target standards. However, before performing this filling operation, this embodiment further introduces a spatial verification trigger judgment step based on the order type. The purpose of this step is to determine whether the current order needs to perform spatial structure-level verification on the tooth position data, because not all types of dental orders involve the spatial arrangement relationship between multiple teeth, and for orders involving only a single tooth, the significance of spatial verification is limited.

[0030] Specifically, in this embodiment, when executing the trigger judgment, the order type information of the current order is first obtained from the extracted instruction fields. Different technicians may have different naming methods for order types, but they are usually identified by specific fields in the instruction table, such as fixed bridges, implant bridges, removable dentures, complete dentures, single crowns, veneers, etc. Among them, fixed bridges and implant bridges involve the spatial arrangement of multiple teeth on the dental arch. Taking a fixed bridge as an example, its basic structure uses the natural teeth on both sides of the edentulous area as abutment teeth to support the bridge body. Therefore, the instruction usually includes the abutment tooth positions and the bridge body tooth positions. These tooth positions are arranged continuously on the dental arch. If one of the tooth positions is not adjacent to other tooth positions in space, it may cause the bridge body to fail to be placed. Similarly, symmetrical tooth extraction involves the extraction of the same tooth in symmetrical positions on the left and right sides, requiring the tooth positions in the instruction to be symmetrically distributed on both sides. For these order types involving the spatial arrangement of multiple teeth, this embodiment presets spatial verification trigger conditions. The triggering condition is specifically represented by a list of order types, which includes the names of order types that require spatial verification. After obtaining the order type information of the current order, it is matched against the types in the preset list. If a match is successful, the triggering condition is deemed met, and the spatial verification step is initiated. If the triggering condition is met, the spatial verification step is executed, which further includes continuity verification and symmetry verification. Continuity verification is used to detect whether the teeth involved in the instruction are arranged continuously on the dental arch, while symmetry verification is used to detect whether the teeth in the instruction are symmetrically distributed on the left and right sides. The specific execution process of these two verification methods will be described in detail in subsequent embodiments. If the triggering condition is not met, it means that the current order does not involve the spatial arrangement of multiple teeth or does not require spatial structure verification. In this case, the entire spatial verification step is skipped, and the tooth position number values ​​are directly filled into the email template according to the determined target standard. Through the above triggering judgment, this embodiment can selectively perform spatial verification according to the actual needs of the order type, thereby avoiding unnecessary verification steps when the order type itself does not constrain the spatial arrangement.

[0031] In one embodiment, the spatial verification step includes a continuity verification, wherein the continuity verification step includes: Obtain the first tooth position entity set or the second tooth position entity set, and analyze the quadrant assignment of each tooth position based on the obtained results; Based on the quadrant affiliation of each tooth position, the teeth positions are grouped by quadrant, and arranged in the order of tooth position number within the same quadrant; Check whether two adjacent tooth position numbers are spatially adjacent in the order of arrangement; Based on the test results, adjacent tooth positions are grouped into the same continuous segment, and non-adjacent tooth positions are grouped into different continuous segments. The number of tooth positions in each continuous segment is counted, and the maximum number of tooth positions in each continuous segment is taken as the length of the longest continuous segment. If the maximum continuous segment length is less than a preset continuity threshold, a continuity anomaly marker is generated.

[0032] As mentioned above, during continuity verification, the tooth position entity set is first obtained from either the first or second source instruction table. In the previous dual-table cross-validation step, the tooth position numbers in the first source instruction table were mapped to the first tooth position entity set according to their target standard, and the tooth position numbers in the second source instruction table were mapped to the second tooth position entity set according to their target standard. These two entity sets have been confirmed to be consistent after verification. Therefore, during continuity verification, one of these two entity sets can be selected, and the obtained tooth position entity set represents the complete tooth position information confirmed after verification for the current order. After obtaining the tooth position entity set, the quadrant assignment of each tooth position needs to be analyzed. This analysis relies on knowledge of the fixed correspondence between tooth positions and quadrants in dental anatomy. Taking the International Dental Federation standard as an example, its numbering rules already include quadrant information. In this standard, the tens digit of the number directly indicates the quadrant in which the tooth is located, and the units digit indicates the specific position of the tooth within that quadrant. For example, in number 11, the tens digit is 1, indicating that it belongs to the upper right quadrant. After obtaining the set of tooth position entities, for each tooth position entity in the set, its quadrant is determined according to the correspondence of its number under the corresponding standard rules. After determining the quadrant affiliation of each tooth position, teeth belonging to the same quadrant are grouped together. Within each group, the teeth are arranged in ascending order of their numbers. The rationale for this is that in dental anatomy, teeth on the dental arch have a definite arrangement order within the same quadrant, which is consistent with their number size; arranging them in numerical order represents the natural arrangement order of teeth within that quadrant on the dental arch. Next, adjacent tooth position numbers are checked sequentially to determine if they are spatially adjacent. Adjacency refers to whether two tooth position numbers are adjacent on the dental arch. Since each tooth has a definite position on the dental arch, the adjacency relationship between any two tooth positions is also definite. This can be determined by using a pre-defined adjacency table or by judging whether adjacent tooth position numbers are consecutive according to the numbering rules. After obtaining the adjacency detection results for each pair of adjacent teeth, the teeth within the same quadrant are divided into continuous segments based on these results. Specifically, starting with the tooth with the smallest number in the quadrant, adjacent tooth pairs are checked sequentially for adjacency. If a pair of adjacent teeth is detected as adjacent, these two teeth are assigned to the same continuous segment; if a pair of adjacent teeth is detected as non-adjacent, these two teeth are assigned to two different continuous segments, i.e., the continuous segment is cut off at that position. For example, if three teeth numbered 11, 12, and 14 are arranged in a quadrant, and 11 and 12 are detected as adjacent, then 11 and 12 are assigned to the same continuous segment containing two teeth; if 12 and 14 are detected as non-adjacent, then 14 is assigned to another continuous segment containing one tooth. In this example, 11 and 12 form a continuous segment of length 2, and 14 forms a continuous segment of length 1.After dividing the order into all continuous segments, the number of tooth positions contained in each segment is counted, and the maximum number of tooth positions in all segments is taken as the maximum continuous segment length. The maximum continuous segment length reflects the degree of continuous distribution of tooth positions on the dental arch in the current order. Next, the maximum continuous segment length is compared with a preset continuity threshold, which is set according to different order types. Taking a fixed bridge order as an example, a fixed bridge requires at least two consecutive tooth positions as bridge support. If the current order is marked as a fixed bridge type, and the maximum continuous segment length is less than the continuity threshold corresponding to this type, it means that the tooth positions in the instruction cannot form a sufficient continuous span on the dental arch. In this case, a continuity anomaly marker is generated, and this marker is associated with the customer identification field of the current order and stored for subsequent manual verification.

[0033] In this embodiment, the continuity check essentially maps discrete tooth position numbers back to spatial relationships on the dental arch. It determines whether the tooth positions meet the continuity requirements of a specific order type by detecting whether they maintain a continuous arrangement. This scheme converts spatial relationships into calculable continuous segment lengths for quantitative judgment. The core process is as follows: first, obtain the set of tooth position entities confirmed by dual-table verification; then, group and sort them by quadrant to restore the spatial arrangement on the dental arch; divide continuous segments by detecting whether adjacent tooth positions are adjacent; finally, compare the maximum continuous segment length with the threshold corresponding to the order type to determine whether the spatial continuity requirements are met. If the maximum continuous segment length is insufficient, it indicates that the tooth position distribution is too discrete and cannot meet the requirements of the order type in terms of dental arch spatial structure; therefore, an anomaly marker is generated.

[0034] In one embodiment, the spatial verification step further includes a symmetry verification, wherein the symmetry verification step includes: Obtain the first tooth position entity set or the second tooth position entity set, and determine the corresponding contralateral tooth position for each tooth position according to the preset contralateral tooth position mapping table; The ratio of the number of teeth with contralateral tooth positions to the total number of teeth positions is used as the symmetry ratio. If the symmetry ratio is less than a preset symmetry threshold, a symmetry anomaly marker is generated.

[0035] As mentioned above, the spatial verification step further includes symmetry verification. Symmetry verification and continuity verification are two independent verification dimensions. The former focuses on whether the distribution of tooth positions on both sides of the dental arch is balanced, while the latter focuses on whether the arrangement of tooth positions within the same quadrant is continuous. For certain types of dental orders, the symmetrical distribution of tooth positions on both sides is an important business requirement. Taking symmetrical tooth extraction as an example, such orders require the extraction of corresponding teeth on both sides, such as the extraction of the upper right first premolar and the upper left first premolar, or the extraction of the lower right second molar and the lower left second molar. If the order instruction only includes the tooth positions on the left side and lacks the corresponding tooth positions on the right side, or only includes the tooth positions on the right side and lacks the corresponding tooth positions on the left side, it may affect the final treatment plan and fabrication. The symmetry verification process first obtains the set of tooth position entities from either the first source instruction table or the second source instruction table. As mentioned earlier, after cross-validation of the two tables, the set of tooth position entities in the first source instruction table and the second source instruction table has been confirmed to be consistent, so one of them can be used. Then, the corresponding contralateral tooth position for each tooth position is determined according to a pre-defined contralateral tooth position mapping table. This mapping table records the correspondence between corresponding teeth on both sides in dental anatomy, a factual correspondence determined in the dental field based on the inherent anatomical feature of bilateral symmetry in the human jawbone structure. For example, the upper right first incisor and the upper left first incisor are contralateral teeth, as are the lower right first premolar and the lower left first premolar. This mapping table covers all tooth position pairings with contralateral correspondences in the entire mouth. Although the tooth position numbering format differs under different tooth position marking standards, each standard's internal numbering system has a definite correspondence rule to determine the contralateral tooth position for any tooth position. After obtaining the corresponding contralateral tooth positions for each tooth position, each tooth position in the current tooth position entity set is checked one by one to determine whether the corresponding contralateral tooth position also exists in the entity set. Then, the number of tooth positions with contralateral tooth positions in the current set is counted, and the ratio of this number to the total number of tooth positions in the current set is calculated. This ratio is called the symmetry ratio. For example, if the current set contains four tooth positions, and the opposite teeth of three of these tooth positions are present in the set, while the opposite tooth of the fourth tooth position is not present, then the symmetry rate is three-quarters. Next, the calculated symmetry rate is compared with a preset symmetry threshold. This threshold is related to the order type. For order types requiring strict left-right symmetry, such as symmetrical tooth extractions, the threshold can be set to 100%, meaning that the opposite tooth of every tooth position in the set must be present. For order types with relatively relaxed symmetry requirements, such as removable dentures, the threshold can be appropriately lowered.If the calculated symmetry rate is less than the preset symmetry threshold, it indicates that the tooth position distribution on both sides of the current order is not balanced enough and fails to meet the tooth position symmetry requirements for this order type. In this case, a symmetry anomaly marker is generated and associated with the customer identifier field of the current order for subsequent manual verification. If the symmetry rate is greater than or equal to the preset symmetry threshold, the tooth position distribution of the order is determined to have passed the symmetry check, and no symmetry anomaly marker is generated.

[0036] In another embodiment, the step of comparing the first set of tooth entities with the second set of tooth entities further includes: Determine whether there is a subset relationship between the first set of tooth position entities and the second set of tooth position entities; If the first set of tooth position entities is consistent with the second set of tooth position entities, then the candidate standard set is used as the target standard. If the first set of tooth position entities and the second set of tooth position entities have a subset relationship, then the parent set of entities with more information is determined, the candidate standard corresponding to the parent set of entities is used as the target standard, and the subset relationship is recorded as the tooth position coverage information of the current order. If the first set of tooth position entities and the second set of tooth position entities are neither consistent nor have a subset relationship, a data inconsistency flag is generated, and the data inconsistency flag is associated with and stored in the customer identifier field of the current order.

[0037] As described above, in the dual-table cross-validation embodiment, the tooth position number values ​​of the first source instruction table are mapped to a first tooth position entity set according to each candidate standard, and the tooth position number values ​​of the second source instruction table are mapped to a second tooth position entity set according to each candidate standard. The target standard is then determined by comparing the two entity sets. The basic logic of the comparison is: if there exists a set of candidate standards that makes the two entity sets consistent, then that set of candidate standards is determined as the target standard; if none of the candidate standard combinations can make the two sets consistent, then the data is determined to be inconsistent. However, in actual business, the range of tooth positions covered by the scanned document instruction table and the physical document instruction table is not always exactly the same. A common scenario is that the scanned document table records the complete tooth position information involved in the order, while the physical document table only records the tooth position information that needs to be processed. For example, the scanned document table of an order contains instruction information for four teeth, while the physical document table only contains processing requirements for two of those teeth. In this case, although the tooth position entity sets contained in the two tables are different, one set is completely contained within the other set, and there is a subset relationship between them. If the comparison logic of the aforementioned embodiment is followed, the two sets will be judged as inconsistent and an anomaly mark will be generated because they are inconsistent. However, in fact, the information in the two tables does not conflict, but their coverage is different.

[0038] To address this issue, this embodiment further introduces a subset relationship identification and processing mechanism in the comparison step. During the comparison, it first determines whether a subset relationship exists between the first set of tooth position entities and the second set of tooth position entities. A subset relationship means that all elements in one set are contained in another set. This is determined by sequentially checking whether every tooth position entity in one set exists in the other set. If both exist, then that set is a subset of the other set. If the two sets are identical, meaning they contain exactly the same elements, then the candidate standard is used as the target standard, following the method described in the previous embodiment. If the two sets are inconsistent but a subset relationship exists—meaning all tooth position entities in one set are contained in the other set, and the other set contains additional tooth position entities—it indicates that the tooth position information in the two tables does not conflict at the entity level; only the coverage differs. In this case, the candidate standard corresponding to the parent set entity set with the larger information content is determined as the target standard. The parent set is used because it contains all the information of the subset, providing a more complete picture of the tooth positions in the order, and avoiding the loss of additional information in the parent set due to using the subset as the standard. Simultaneously, this subset relationship is recorded as the tooth position coverage information for the current order, so that the recipient is informed in subsequent emails that the processed physical part only covers a portion of the teeth positions in the scanned part, and the remaining teeth positions may belong to other batches or require further confirmation. If two sets are neither consistent nor have a subset relationship (i.e., the two sets intersect but do not contain each other, or the two sets do not overlap at all), it indicates an irreconcilable conflict at the entity level regarding the tooth position information in the two tables. In this case, following the processing method described in the previous embodiment, a data inconsistency marker is generated and associated with the customer identifier field of the current order for storage. Through this mechanism, this embodiment can avoid misjudging normal data as abnormal when the coverage of the two tables differs, while retaining complete information in the parent set for subsequent email content generation.

[0039] In another embodiment, the invention is deployed in the office automation environment of a dental lab. This lab processes 20 to 30 orders daily from multiple dental clinics. Each order includes a scanned document instruction form and a physical document instruction form, along with an STL dental model scan and a photograph of the patient's mouth. Before this invention, customer service personnel had to manually open each form, copy the order information, search historical emails in their inbox, find the corresponding attachments, and finally manually draft the email, taking an average of 8 to 10 minutes per order. After adopting this invention, customer service personnel access a web service on the server computer via a browser and upload all instruction forms received that day in batches in the first step of the operation interface. The server automatically calls the corresponding data extraction rules based on the form's source type. During the extraction process, the tooth position field is format-preserving to ensure that tooth position combinations recorded in 3 / 4 format are not mistakenly converted to date format by the form processing software. After extraction, the server retrieves historical email records from the local email subject index cache based on the customer identifier field. Since the index cache only traverses historical emails on the mail server on the first run, subsequent runs only incrementally update newly added emails, and each retrieval can be completed within seconds. After retrieving historical emails, the server automatically obtains the email's unique identifier and the list of referenced emails, sets the current draft email to reply mode, and ensures the email is correctly categorized into its original email thread. The server then populates the instruction fields into the email template, generating a complete email body containing the tooth position number, patient information, restoration type, and material requirements. It also searches for matching attachments and finally generates a complete email draft, saving it to the drafts folder. Customer service personnel can then open the drafts folder to verify the draft before sending it. This automated office and email processing workflow reduces the average processing time for a single order to 2-3 minutes, eliminating information distortion caused by manual copying and errors in standard recognition.

[0040] Reference Figure 3 This application also provides a dental technician order email draft automatic generation system, including: Module 1 is used to obtain the first source instruction table and the second source instruction table; The parsing and extraction module 2 is used to parse the first source instruction table and the second source instruction table respectively. Based on the source type of each instruction table, it determines the corresponding data extraction rules and extracts the instruction field and customer identifier field from each instruction table. During the extraction process, the tooth position field is processed to preserve the format, and the original input content of the instruction table is preserved in text form. Module 3 is used to establish or update the email subject index cache based on the customer identifier field. The index cache is used to record the correspondence between processed email subjects and the customer identifier field. The retrieval module 4 is used to retrieve historical email records that match the customer identifier field in the index cache. If a record is found, the thread association information of the historical email is obtained and it is marked as a first type. If no record is found, it is marked as a second type. The generation module 5 is used to fill the instruction field into the email template according to a preset mapping relationship to generate email content data; The determining module 6 is used to determine the email header parameters of the email draft to be generated based on the first type or the second type and in combination with the thread association information. The saving module 7 is used to generate an email draft based on the email content data and the email header parameters, and save the email draft to the drafts folder.

[0041] As described above, it is understood that each component of the dental technician order email draft automatic generation system proposed in this application can realize the function of any of the dental technician order email draft automatic generation methods described above, and the specific structure will not be described in detail.

[0042] Reference Figure 4 This application also provides a computer device, which may be a server, and its internal structure may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores monitoring data and other data. The network interface is used for communication with external terminals via a network connection. When executed by the processor, the computer program implements a method for automatically generating draft dental technician order emails.

[0043] The processor described above executes the automatic generation method for dental technician order email drafts, including: obtaining a first source instruction table and a second source instruction table; parsing the first source instruction table and the second source instruction table respectively, determining the corresponding data extraction rules according to the source type of each instruction table, and extracting the instruction field and customer identifier field from each instruction table. During the extraction process, the tooth position field is format-preserving, and the original input content of the instruction table is preserved in text form; establishing or updating an email subject index cache according to the customer identifier field, the index cache being used to record the correspondence between processed email subjects and customer identifier fields; retrieving historical email records that match the customer identifier field from the index cache, if a record is found, obtaining the thread association information of the historical email and marking it as a first type, otherwise marking it as a second type; filling the instruction field into the email template according to a preset mapping relationship to generate email content data; determining the email header parameters of the email draft to be generated according to the first type or the second type, combined with the thread association information; generating an email draft according to the email content data and the email header parameters, and saving the email draft to the drafts folder.

[0044] One embodiment of this application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for automatically generating draft dental technician order emails, including the following steps: obtaining a first source instruction table and a second source instruction table; parsing the first source instruction table and the second source instruction table respectively, determining the corresponding data extraction rules according to the source type of each instruction table, and extracting the instruction field and customer identifier field from each instruction table; performing format preservation processing on the tooth position field during the extraction process to preserve the original input content of the instruction table in text form; and establishing or updating the email subject according to the customer identifier field. An index cache is used to record the correspondence between processed email subjects and customer identifier fields. Historical email records matching the customer identifier field are retrieved from the index cache. If a record is found, the thread association information of the historical email is obtained and it is marked as a first type; otherwise, it is marked as a second type. The instruction field is filled into the email template according to a preset mapping relationship to generate email content data. Based on the first or second type, and combined with the thread association information, the email header parameters for generating the email draft are determined. An email draft is generated based on the email content data and the email header parameters, and the email draft is saved to the drafts folder.

[0045] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in this application and in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0046] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method 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, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0047] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for automatically generating draft dental technician order emails, characterized in that, The method includes: Obtain the first source instruction table and the second source instruction table; The first source instruction table and the second source instruction table are analyzed separately. Based on the source type of each instruction table, the corresponding data extraction rules are determined, and the instruction field and customer identifier field in each instruction table are extracted. During the extraction process, the tooth position field is processed to preserve the format, and the original input content of the instruction table is preserved in text form. Based on the customer identifier field, establish or update the email subject index cache, which is used to record the correspondence between processed email subjects and the customer identifier field; Retrieve historical email records that match the customer identifier field in the index cache. If a record is found, obtain the thread association information of the historical email and mark it as a first type. If no record is found, mark it as a second type. The instruction fields are filled into the email template according to a preset mapping relationship to generate email content data; Based on the first type or the second type, and in conjunction with the thread association information, determine the email header parameters for the email draft to be generated; An email draft is generated based on the email content data and the email header parameters, and the email draft is saved to the drafts folder.

2. The method for automatically generating dental technician order email drafts according to claim 1, characterized in that, Before performing format preservation processing on the tooth position field, the method further includes identifying the tooth position field in the instruction table, including: Get the column header of the current cell or the top row field of the current cell; Match the column header or the row header field with a preset tooth position keyword library to determine the matching result; If a match is successful, the current column or row will be recognized as the tooth position field; If the match fails, retrieve the data content of each cell in the current column or row, calculate the string length of the data content of each cell and count the length distribution, count the proportion of numeric characters in the data content of each cell, and count the ratio of the number of duplicate values ​​in the data content of each cell to the total number of cells. If the mode of the length distribution is less than or equal to the first preset threshold, the proportion of the numeric characters falls within a preset value range, and the ratio is less than or equal to the second preset threshold, then the current column or the current row is identified as a tooth position field. If the mode of the length distribution is greater than the first preset threshold, or the proportion of numeric characters does not fall within the preset value range, or the ratio is greater than the second preset threshold, then the current column or the current row is identified as a non-tooth position field, and the process jumps to the next column or the next row to perform matching again.

3. The method for automatically generating dental technician order email drafts according to claim 2, characterized in that, The method for performing format preservation processing on the tooth position field includes: Read the original data storage value of the cell containing the tooth position field; Obtain the original data type identifier of the cell, which includes a date type identifier, a numeric type identifier, and a text type identifier; If the original data type identifier is a date type identifier, then the original data storage value is converted back to a date format string according to the original input format of the cell and then output. If the original data type identifier is a numeric type identifier, then the original data storage value is directly converted into text format and output. If the original data type identifier is a text type identifier, then the original data storage value is directly read and output.

4. The method for automatically generating dental technician order email drafts according to claim 1, characterized in that, After the step of extracting the instruction fields and customer identifier fields from each of the instruction tables, and before the step of filling the instruction fields into the email template, the method further includes: Obtain the first tooth position number value from the first source instruction table and the second tooth position number value from the second source instruction table; Based on the numerical range distribution characteristics and format characteristics of the tooth position number values ​​in the first source instruction table, a first candidate standard corresponding to the first tooth position number value is determined; based on the numerical range distribution characteristics and format characteristics of the tooth position number values ​​in the second source instruction table, a second candidate standard corresponding to the second tooth position number value is determined. The first tooth position number value is mapped to a first tooth position entity set according to each of the first candidate standards, and the second tooth position number value is mapped to a second tooth position entity set according to each of the second candidate standards; Compare the first set of tooth entities with the second set of tooth entities. If there is a first candidate standard and a second candidate standard that make the first set of tooth entities consistent with the second set of tooth entities, then the candidate standard shall be used as the target standard for the first source instruction table and the second source instruction table respectively. If, after traversing all candidate standard combinations, there is no first candidate standard and second candidate standard that make the first tooth position entity set consistent with the second tooth position entity set, then a data inconsistency flag is generated, and the data inconsistency flag is associated with and stored in the customer identifier field of the current order.

5. The method for automatically generating dental technician order email drafts according to claim 4, characterized in that, After the step of determining the second candidate criterion corresponding to the second tooth position number value, the method further includes: Obtain the order type information of the current order, which is extracted from the instruction field; Determine whether the current order meets the preset space verification trigger condition based on the order type information; If satisfied, a spatial verification step is performed, which includes continuity verification and symmetry verification. If the condition is not met, the spatial verification step is skipped, and the tooth position number value is filled into the email template according to the target standard.

6. The method for automatically generating dental technician order email drafts according to claim 5, characterized in that, The spatial verification step includes a continuity verification, wherein the continuity verification step includes: Obtain the first tooth position entity set or the second tooth position entity set, and analyze the quadrant assignment of each tooth position based on the obtained results; Based on the quadrant affiliation of each tooth position, the teeth positions are grouped by quadrant, and arranged in the order of tooth position number within the same quadrant; Check whether two adjacent tooth position numbers are spatially adjacent in the order of arrangement; Based on the test results, adjacent tooth positions are grouped into the same continuous segment, and non-adjacent tooth positions are grouped into different continuous segments. The number of tooth positions in each continuous segment is counted, and the maximum number of tooth positions in each continuous segment is taken as the length of the longest continuous segment. If the maximum continuous segment length is less than a preset continuity threshold, a continuity anomaly marker is generated.

7. The method for automatically generating dental technician order email drafts according to claim 6, characterized in that, The spatial verification step further includes symmetry verification, wherein the symmetry verification step includes: Obtain the first tooth position entity set or the second tooth position entity set, and determine the corresponding contralateral tooth position for each tooth position according to the preset contralateral tooth position mapping table; The ratio of the number of teeth with contralateral tooth positions to the total number of teeth positions is used as the symmetry ratio. If the symmetry ratio is less than a preset symmetry threshold, a symmetry anomaly marker is generated.

8. A system for automatically generating draft dental technician order emails, characterized in that, include: The acquisition module is used to acquire the first source instruction table and the second source instruction table; The parsing and extraction module is used to parse the first source instruction table and the second source instruction table respectively. Based on the source type of each instruction table, it determines the corresponding data extraction rules and extracts the instruction field and customer identifier field from each instruction table. During the extraction process, the tooth position field is processed to preserve the format, and the original input content of the instruction table is preserved in text form. The module is used to establish or update the email subject index cache based on the customer identifier field. The index cache is used to record the correspondence between processed email subjects and the customer identifier field. The retrieval module is used to retrieve historical email records that match the customer identifier field in the index cache. If a record is found, the thread association information of the historical email is obtained and it is marked as a first type. If no record is found, it is marked as a second type. The generation module is used to fill the instruction fields into the email template according to a preset mapping relationship to generate email content data; The determination module is used to determine the email header parameters of the email draft to be generated based on the first type or the second type and in combination with the thread association information. The save module is used to generate an email draft based on the email content data and the email header parameters, and save the email draft to the drafts folder.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images