Oral orthodontic data management and control method, device and equipment based on knowledge graph

Abstract

Embodiments of the present disclosure disclose an orthodontic data management and control method, device and equipment based on a knowledge graph. A specific implementation of the method includes: obtaining multi-modal orthodontic data uploaded by a user; performing structured feature extraction on the obtained multi-modal orthodontic data to obtain initial feature information; performing entity mapping processing on the initial feature information to obtain key feature information; generating enhanced information based on the key feature information and a pre-constructed orthodontic knowledge graph; generating a structured target planning scheme according to the enhanced information and the key feature information; generating a control instruction set according to the structured target planning scheme; and controlling an external execution device based on the control instruction set. The implementation provides a solid and complete technical foundation for realizing the precision, automation and intelligence of a clinical assistance process.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to a method, apparatus, and device for managing oral orthodontic data based on knowledge graphs. Background Technology

[0002] With the deepening application of artificial intelligence technology in the field of medical and health data processing, building specialized information processing and assistance systems using large language models (LLM) combined with retrieval-enhanced generation (RAG) technology has become an important direction for the intelligent development of the orthodontic field. Existing technical solutions are typically based on a general large language model architecture, enhancing the professionalism of the model-generated content by retrieving relevant text fragments from external medical literature databases. This aims to alleviate the potential "illusion" problem and knowledge update lag issues that may exist with general models in specialized fields, thereby providing users with more valuable information support.

[0003] However, existing technologies still face significant technical bottlenecks when dealing with the highly specialized and logically complex field of orthodontics. First, the traditional RAG architecture suffers from fundamental flaws: fragmented information and a lack of deep, associative reasoning capabilities. Its core relies on vectorization and similarity matching of unstructured text, resulting in mostly isolated, semantically similar text blocks that fail to capture and provide the inherent, structured logical relationship networks within the professional knowledge system (e.g., multi-layered associations between specific clinical manifestations, interventions, and applicable conditions). This leads to generated answers or suggestions lacking coherent logical chains and contextual support, making it difficult to complete complex analytical tasks requiring multi-step reasoning. Second, building a high-quality domain knowledge base faces an inherent contradiction between "construction efficiency" and "knowledge accuracy." Relying entirely on manual annotation and construction by domain experts to ensure knowledge quality is extremely costly and lacks scalability, making it difficult to adapt to the rapid accumulation and iteration of knowledge. Conversely, relying entirely on large models for automated knowledge extraction to improve efficiency lacks effective professional supervision and verification mechanisms, resulting in high noise and poor consistency in the extraction results, directly impacting the reliability of all downstream tasks. Furthermore, the functional boundaries of existing solutions are mostly limited to generating text or structured suggestions. How to automatically and accurately transform the generated planning schemes containing executable steps into control instructions and parameters that can directly drive the operation of physical equipment (such as 3D scanners and CNC machining equipment), and realize a complete technical closed loop from "data analysis and decision-making" to "physical execution control", constitutes a key technical obstacle that has not yet been fully resolved.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose methods, apparatuses, electronic devices, and computer-readable media for managing orthodontic data based on knowledge graphs to address one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a knowledge graph-based method for managing and controlling orthodontic data, including: acquiring multimodal orthodontic data uploaded by users; performing structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information; performing entity mapping processing on the initial feature information to obtain key feature information; generating enhancement information based on the key feature information and a pre-constructed orthodontic knowledge graph; generating a structured target planning scheme based on the enhancement information and the key feature information; generating a set of control instructions based on the structured target planning scheme; and controlling external execution devices based on the set of control instructions.

[0008] Secondly, some embodiments of this disclosure provide a knowledge graph-based orthodontic data management and control device, comprising: an acquisition unit configured to acquire multimodal orthodontic data uploaded by a user; an extraction unit configured to perform structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information; a mapping unit configured to perform entity mapping processing on the initial feature information to obtain key feature information; a first generation unit configured to generate enhancement information based on the key feature information and a pre-constructed orthodontic knowledge graph; a second generation unit configured to generate a structured target planning scheme based on the enhancement information and the key feature information; a third generation unit configured to generate a set of control instructions based on the structured target planning scheme; and a control unit configured to control an external execution device based on the set of control instructions.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0011] Fifthly, some embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0012] The knowledge graph-based orthodontic data management method provided by the above embodiments of the present invention effectively overcomes the core defects of existing technologies in information integration, deep reasoning, and physical execution by constructing a fully intelligent "data-knowledge-decision-control" chain, achieving end-to-end automated processing from multi-source clinical data to executable device instructions. Specifically, it addresses the three major problems pointed out in the background technology: 1) weak logical reasoning ability of traditional RAG due to information fragmentation; 2) the contradiction between efficiency and accuracy in the construction of domain knowledge base; and 3) the disconnect between intelligent decision-making and physical device execution. This method provides a complete solution through the systematic design of the following steps: First, it acquires multimodal orthodontic data uploaded by users and performs structured feature extraction on the acquired data to obtain initial feature information. Thus, this method establishes an entry point for processing complex clinical data, enabling the normalization and preliminary structuring of multi-source heterogeneous information such as text and images, laying a unified and standardized data foundation for subsequent precise knowledge association, and solving the problem of messy and difficult-to-use raw data. Next, it performs entity mapping processing on the above initial feature information to obtain key feature information. Therefore, this method performs deep semantic alignment between the extracted original features and a pre-constructed orthodontic knowledge graph, transforming non-standard clinical descriptions into standardized entities and their attributes defined in the graph. This step injects rigorous domain knowledge, ensuring the accuracy of the system's core "cognition" and providing a key prerequisite for overcoming information fragmentation and achieving accurate reasoning. Then, based on the aforementioned key feature information and the pre-constructed orthodontic knowledge graph, enhanced information is generated. Thus, this method employs a hybrid retrieval mechanism, not only acquiring semantically relevant text fragments (vector retrieval), but more importantly, obtaining structured related information subgraphs along the relational paths of the knowledge graph (graph retrieval). This provides the system with a broad and deep context, containing logical chains such as "sign-intervention," which directly empowers the deep and interpretable reasoning of subsequent steps, fundamentally solving the problem of information silos in traditional RAGs. Subsequently, based on the aforementioned enhanced information and key feature information, a structured goal planning scheme is generated. Thus, based on high-quality knowledge enhancement, this method drives a large language model to perform logical deduction, producing a structured scheme that includes state classification, planning goals, and specific task sequences. This approach not only boasts text readability but also a clear, machine-readable structure, achieving a fundamental leap from data and knowledge to actionable planning, answering the questions of "what to do" and "how to do it." Next, based on the aforementioned structured goal planning scheme, a set of control instructions is generated. Thus, this method achieves the crucial transformation from abstract planning to concrete instructions. By mapping and encapsulating task sequences described in natural language into standardized control instructions (such as opcodes and parameters) that can be recognized by the device, high-level planning can be accurately and unambiguously interpreted, paving the way for execution in the physical world.Finally, based on the aforementioned set of control instructions, external execution devices are controlled. Thus, this method completes the final closed loop from the digital world to the physical world, directly driving hardware devices such as intraoral scanners and 3D printers to perform specific operations. This step directly overcomes the technical obstacle of the "closed loop from decision-making to execution" pointed out in the background technology, achieving true automated control. Furthermore, this method cleverly balances the contradiction between accuracy and efficiency in knowledge base construction through a knowledge graph construction paradigm of "expert-annotated seeds + automated expansion of large models." Each link in the entire process is interconnected, forming an integrated technical system with a high-quality knowledge graph at its core, hybrid retrieval as an enhancement method, structured generation as the output form, and instruction-driven execution as the execution end. In summary, this invention not only improves the depth and reliability of data processing and intelligent assistance in the field of orthodontics, but also provides a solid technical foundation for achieving precision, automation, and intelligence in clinical assistance processes by bridging the "last mile" to device control. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the knowledge graph-based orthodontic data management method according to this disclosure; Figure 2 This is a schematic diagram of the structure of some embodiments of the knowledge graph-based orthodontic data management device according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0017] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0018] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0019] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0020] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Figure 1 A flowchart 100 is shown, illustrating some embodiments of a knowledge graph-based orthodontic data management method according to this disclosure. This knowledge graph-based orthodontic data management method includes the following steps: Step 101: Obtain multimodal orthodontic data uploaded by the user.

[0022] In some embodiments, the implementing entity (e.g., a computing device) of the knowledge graph-based orthodontic data management method can acquire multimodal orthodontic data uploaded by users. This multimodal orthodontic data refers to a heterogeneous data set provided by users (e.g., doctors, technicians, or patients) in orthodontic-related clinical or assessment scenarios, exhibiting two or more forms of representation or sources. The term "modality" here refers to a specific type or form of data, such as text, image, or structured measurements. Specifically, the multimodal orthodontic data includes text data and image data. Text data can be information recorded in the form of natural language characters, typically used to describe non-quantitative observations, complaints, medical history, or assessment conclusions. Image data can be information recorded in the form of two-dimensional or three-dimensional digital images, capable of visually reflecting the anatomical morphology, structural relationships, and partial functional status of the oral and maxillofacial region. In practice, the implementing entity (e.g., the server deploying the method) receives user-uploaded or input data through its provided user interface (e.g., a web application or client software). The specific process includes providing users with a clear data upload entry point or input form. The system receives files submitted by users through the aforementioned entry points or content entered through forms. The received raw data is parsed and its format validated to ensure it can be processed in subsequent steps. For example, the implementing entity can use a front-end page of a diagnostic support system to identify content entered by the user in a "Chief Complaint and Medical History" text box, such as "Patient's chief complaint is malocclusion of the anterior teeth, with a history of orthodontic treatment," as text data. Multiple files submitted by the user through a file upload control, including a panoramic X-ray (two-dimensional image) and an intraoral three-dimensional scan data file (three-dimensional image), are identified as image data. Measurement values ​​selected or filled in by the user through a structured form, such as a mandibular plane angle (SN-MP angle) of 38 degrees, are also identified as text data. These are structured assessment results obtained through standardized clinical examinations and recorded in numerical or graded form.

[0023] Step 102: Perform structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information.

[0024] In some embodiments, the aforementioned execution entity may perform structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information.

[0025] In some optional implementations of certain embodiments, the aforementioned execution entity may perform structured feature extraction on the acquired multimodal orthodontic data through the following steps to obtain initial feature information: Step one involves performing natural language understanding processing on the text data in the aforementioned multimodal orthodontic data to obtain a text feature set. This text feature set includes various text feature terms. The text feature set is a data structure used to store all structured results extracted from the text data. Each basic unit comprising this set is called a text feature term, representing the smallest unit of information with independent clinical semantics identified from a text segment. Natural language understanding processing refers to the process of automatically analyzing human language using computational models to identify specific types of entities, attributes, and relationships between them. In practice, the aforementioned execution entity uses pre-trained language models and sequence labeling algorithms to process text data. Specifically, BERT (Bidirectional Encoder Representations from Transformers) or its variants can be used as the base model. The processing flow is as follows: First, the input text is segmented and converted into word vectors, which are then input into the BERT model. Its deep bidirectional Transformer structure is used to obtain the context-related feature representation of each word. Next, based on this representation, a Conditional Random Field (CRF) layer is used for sequence labeling. According to a predefined list of orthodontic entity types (such as a list covering malocclusion, clinical manifestations, and appliances), each word or sub-word in the text is assigned an entity label (e.g., B-Condition, I-Condition, O), thus completing entity recognition. For example, "Angle Class II" is identified as a malocclusion entity. Subsequently, for the identified entity pairs, a relation classifier (usually a neural network classifier based on the entity pair's contextual feature vector) is used to determine and label whether a predefined relation type (e.g., "has_symptom") exists between them. For example, given the text data "The patient complains of malocclusion of the anterior teeth, and clinical examination reveals Angle Class II malocclusion with deep overbite," the executing agent can use the BERT-CRF model mentioned above to identify three entities: "malocclusion of the anterior teeth," "Angle Class II malocclusion," and "deep overbite." A relation classifier then determines a "has_symptom" relationship (clinical manifestation) between "Angle Class II malocclusion" and "deep overbite." Each identified entity, its attributes (such as type), and the relationships between entities are constructed into a structured data object and stored as a text feature item in the text feature set.

[0026] Step two involves performing image feature extraction processing on the image data from the aforementioned multimodal orthodontic data to obtain an image feature set. This image feature set includes various image feature items. The image feature set is a data structure used to store all quantitative or qualitative descriptions automatically identified and measured from the image data. Each basic unit comprising this set is called an image feature item. An image feature item typically corresponds to a specific anatomical landmark, a measured line segment, a calculated angle or distance value, or a classification description of the morphology of a certain region in the image. Image feature extraction processing refers to the process of automatically locating key anatomical structures from medical images and calculating their geometric or morphological parameters through image processing and computer vision algorithms. In practice, the aforementioned execution entity utilizes deep learning models for key point detection and image analysis. For two-dimensional images such as lateral cephalometric radiographs, a landmark detection model based on a Convolutional Neural Network (CNN) (such as a model with an architecture similar to U-Net or Hourglass) can be used. This model is trained on a large dataset of lateral cephalometric radiographs annotated with anatomical landmarks. It can directly input an entire X-ray and output a series of predefined anatomical landmarks (such as the nasal root point Na, the upper alveolar base point A, and the lower alveolar base point B). After obtaining the landmark coordinates, clinically required measurements, such as the SNA angle (the angle between the line connecting SN and NA), can be calculated through simple geometric operations. For three-dimensional images such as intraoral scan data, a deep learning-based crown segmentation network (such as PointNet++ or a 3D U-Net variant) can be used for tooth segmentation, and then parameters such as arch width and crowding can be calculated. For example, for an input lateral cephalometric X-ray, the execution agent uses a trained CNN keypoint detection model to predict the pixel coordinates of landmarks S, N, A, and B. Subsequently, based on these coordinates, the SNA angle is calculated to be 82 degrees, the SNB angle to be 79 degrees, and the ANB angle to be 3 degrees. Therefore, the image feature set will contain multiple image feature items, some of which could be: an image feature item representing the "marker point S" and its coordinates, an image feature item representing the "measurement item SNA angle" and its value of 82 degrees, and an image feature item representing the "measurement item ANB angle" and its value of 3 degrees.

[0027] Step three involves integrating the aforementioned text feature set and image feature set to obtain initial feature information including each feature item. Data integration refers to merging, associating, and organizing feature sets from two different sources—text and images—into a unified and coherent data entity. The initial feature information is the output of this process; it is a comprehensive structured data body containing all text and image feature items, serving as input for subsequent knowledge mapping and reasoning steps. In practice, the executing entity first loads all feature items from the text and image feature sets into a common data workspace. Subsequently, data cleaning and alignment operations are performed, such as semantic association based on the clinical concepts described by the feature items (e.g., associating the measurement results of "maxillary protrusion" in the text feature item with "increased SNA angle" in the image feature item through a concept mapping table). Then, the system eliminates obvious redundant or conflicting information (e.g., verifying whether the same concept is consistently expressed in different modalities by setting rules). Finally, all processed features are organized according to a predefined structured format (such as a list containing all features or a dictionary object conforming to a specific JSON Schema) to form the final initial feature information. For example, the execution entity integrates the text feature set obtained in step one with the image feature set obtained in step two. The system automatically associates the text feature "Angle Class II malocclusion" with the measurement result of "ANB angle greater than 4 degrees" in the image feature set through an internal mapping table, because both clinically point to a specific sagittal misalignment problem. At the same time, the text feature "deep overbite" may be associated with the "overbite value" measured in the image. Finally, all associated and cleaned features are integrated into a data structure called "initial feature information," which explicitly contains entities and relationships extracted from the text and measurement values ​​and markers extracted from the image, preparing for the next step of entity mapping processing.

[0028] Step 103: Perform entity mapping processing on the initial feature information to obtain key feature information.

[0029] In some embodiments, the execution entity may perform entity mapping processing on the initial feature information to obtain key feature information.

[0030] In some optional implementations of certain embodiments, the execution entity may perform entity mapping processing on the initial feature information through the following steps to obtain key feature information: Step 1: For each feature item in the initial feature information above, perform the following steps: Sub-step one involves evaluating the semantic similarity between the aforementioned feature items and each entity node in the pre-constructed orthodontic knowledge graph, obtaining the semantic similarity evaluation results. Semantic similarity evaluation refers to the quantification process of calculating the semantic closeness between a textual feature item and the name or description text of each entity node in the knowledge graph. The pre-constructed orthodontic knowledge graph is a large-scale domain-specific knowledge base organized in a graph structure, and its construction includes two core stages. The first stage is expert knowledge injection: Orthodontic experts manually annotate a batch of high-quality (entity, relation, entity) triples as seeds based on core textbooks and clinical guidelines, for example, annotating ("Angle Class II malocclusion", "has_treatment", "functional appliance"). The second stage is large-model-driven expansion: using the aforementioned seed triples as few-sample examples, structured fine-tuning instructions (Prompt) are constructed to drive a large language model (e.g., Qwen2-32B) to automatically extract new, structurally consistent triples from a massive amount of unstructured medical literature. Ultimately, all triples are stored in a graph database (such as Neo4j), with entities becoming nodes, relations becoming edges, and associated with the original text descriptions to form a queryable knowledge graph. In practice, the aforementioned execution entity first converts the natural language description text of the current feature item (e.g., "crowded teeth") and the names and description texts of all entity nodes read from the knowledge graph into high-dimensional semantic vectors. This conversion is typically accomplished using a pre-trained text embedding model (e.g., BGE or text2vec), which maps text to a point in the semantic space. Then, by calculating the cosine similarity between the feature item vector and each entity node vector, a set of values ​​is obtained, which represents the semantic similarity evaluation results. The range of cosine similarity is [-1, 1], with values ​​closer to 1 indicating greater semantic similarity. For example, for a feature item "deep anterior tooth overlay," the execution entity uses the BGE model to convert it into a vector V_f. Simultaneously, the descriptive texts of the entities "deep cover," "cover," and "Angle Class II malocclusion" in the knowledge graph are also converted into vectors V_e1, V_e2, and V_e3. The cosine similarity between V_f and V_e1 is calculated to be 0.92, the similarity with V_e2 is 0.85, and the similarity with V_e3 is 0.70. These values ​​are the semantic similarity evaluation results.

[0031] Sub-step two involves matching the aforementioned feature terms with the corresponding standardized entity nodes in the pre-constructed orthodontic knowledge graph based on the semantic similarity evaluation results. Matching refers to the process of determining the semantically closest standardized corresponding entity node in the knowledge graph for a feature term from the original data, based on the quantified semantic proximity. In practice, the executing entity sets a predefined similarity threshold (e.g., 0.75). It iterates through all calculated semantic similarity evaluation results, filters out all results exceeding the threshold, and selects the entity node corresponding to the result with the highest similarity. If the highest similarity result is below the threshold, it is determined that the feature term has no explicit correspondence in the existing knowledge graph and can be marked as "unmapped" for subsequent processing. For example, based on the results of sub-step one, the feature term "deep overbite" has the highest similarity of 0.92 with the entity "deep overbite," exceeding the threshold of 0.75. Therefore, the executing entity successfully matches this feature term to the standardized entity node named "deep overbite" in the knowledge graph.

[0032] Sub-step three involves retrieving attribute information and superordinate concept information associated with the standardized entity node from the pre-constructed orthodontic knowledge graph. Attribute information refers to a series of feature value pairs predefined in the knowledge graph to describe the standardized entity node in detail. Superordinate concept information refers to the parent entity node information, directly above the entity node in the semantic classification hierarchy defined by the knowledge graph, representing its broader category. In practice, after successfully matching a standardized entity node, the executing entity initiates a query to the graph database. The query retrieves all direct relationships of the node, i.e., all neighboring nodes and their relationship types directly connected by an edge. From the returned results, neighboring nodes with the relationship type "has_property" (having an attribute) are parsed as attribute information; neighboring nodes with the relationship type "is_a" (is a) are parsed as superordinate concept information. This neighboring node information typically includes its unique identifier, name, and descriptive text. For example, for a matched “deep coverage” node, after performing a main query graph, it may be found that it is connected to a node named “Sagittal Incompatibility” (superordinate concept information) through the “is_a” relationship, and connected to an attribute node such as “Common value range: 3-5mm” through the “has_property” relationship.

[0033] Sub-step four involves supplementing and standardizing the aforementioned attribute information and hypernym information to obtain the target feature item. Supplementation and standardization refer to the process of enhancing and unifying the expression of the original feature item using standardized semantic information retrieved from the knowledge graph. The target feature item is the output of this process; it is a new data object integrating the original clinical description and the structured knowledge of the knowledge graph. In practice, the executing entity creates a structured data object to represent the target feature item. This object contains at least the following fields: the original feature item text (orig_text), the mapped standardized entity ID (std_entity_id) and name (std_entity_name), a list of properties (each item being a key-value pair), and a list of hypernyms. This process ensures that clinical features from different doctors or medical records, whose expressions may be inconsistent (such as "large coverage" or "protrusion"), can be normalized to the same authoritative knowledge entity ("deep coverage"), along with its clinical definition, typical values, or classification affiliation, and other key background knowledge. For example, the original feature term is "deep overbite of anterior teeth". After mapping and supplementation, the generated target feature term may be a JSON object: {"orig_text":"deep overbite of anterior teeth", "std_entity":{"id":"Overjet001","name":"deep overbite"},"properties":[{"key":"measurement definition","value":"horizontal distance from the incisal edge of the upper anterior teeth to the labial surface of the lower anterior teeth"}],"hypernyms":["sagittal inconsistency"]}.

[0034] Step two involves generating key feature information based on the obtained target feature items. Key feature information refers to a new, standardized, and semantically rich feature set formed by replacing all successfully mapped feature items in the initial feature information with their corresponding enhanced target feature items. This set serves as the direct input for subsequent knowledge-enhanced retrieval and intelligent reasoning. In practice, the execution entity iterates through each feature item in the initial feature information list. For each feature item, if a target feature item was successfully generated in step one, its original representation in the list is replaced with that target feature item. For feature items that fail to match (e.g., low similarity or no corresponding entity), their original text is retained, and an "unstandardized" label is added. After all feature items have been processed, this updated list (containing target feature items and labeled original feature items) is output as key feature information. For example, the initial feature information might be ["Angle Class II", "Mandibular Retrusion", "High Angle"]. After entity mapping processing, the generated key feature information could be a list containing three target feature items. The first target feature standardizes "Angle Class II" into the "Angle Class II malocclusion" entity in the knowledge graph and supplements its classification definition; the second standardizes "mandibular retrusion" and associates it with its possible superordinate concept "sagittal incongruence"; the third standardizes "high angle" and associates it with its measurement method. This list constitutes the key feature information available for subsequent steps.

[0035] Step 104: Generate enhancement information based on key feature information and a pre-constructed orthodontic knowledge graph.

[0036] In some embodiments, the aforementioned executing entity may generate enhanced information based on the aforementioned key feature information and a pre-constructed orthodontic knowledge graph.

[0037] In some optional implementations of certain embodiments, the aforementioned execution entity can generate enhanced information based on the aforementioned key feature information and a pre-constructed orthodontic knowledge graph through the following steps: Step 1: For each target feature item included in the above key feature information, perform the following steps: Sub-step one involves performing a multi-hop relation query in the pre-constructed orthodontic knowledge graph, using the standardized entity node corresponding to the aforementioned target feature as the query starting point. The standardized entity node corresponding to the target feature refers to the node with a unique identifier in the knowledge graph that was successfully matched for the target feature during the entity mapping process in step 103. Multi-hop relation query specifically refers to the process of starting from the query starting node, traversing along predefined relation edges in the knowledge graph, and obtaining all neighboring nodes, relations, and associated text directly connected to it within one step (i.e., "one hop"). The pre-constructed orthodontic knowledge graph is a large semantic network consisting of "entity-relationship-entity" triples, stored in a graph database (such as Neo4j). In practice, the executing entity first extracts the unique identifier (ID) of the standardized entity node mapped to the target feature from its data structure. Then, it sends a query to the graph database using a graph query language (such as Cypher). This query pattern specifies that, starting from the node identified by this ID, it matches all other nodes reachable within a one-step range from that node via any type of relation edge, and simultaneously returns the relation edges themselves, as well as the descriptive text associated with all relevant nodes and relations. For example, for a target feature whose mapped normalized entity is "Angle Class II malocclusion," the executing agent initiates a one-hop query starting from the entity's ID in the atlas (e.g., "Malocclusion_II"). The query results may include: "deep coverage" entity nodes connected by the "has_symptom" relation and their descriptions, "functional orthodontic appliance" entity nodes connected by the "has_treatment" relation and their descriptions, etc.

[0038] Sub-step two involves obtaining all associated entity nodes, relation edges, and descriptive texts connected to the query starting point via relation edges, and defining these as the first search result. The first search result specifically refers to the structured set of all data obtained through the one-hop graph retrieval described above; essentially, it is a local knowledge subgraph centered on the query starting point and including its direct neighbors. In practice, the executing entity receives and parses the query results returned by the graph database. This result is typically a list containing multiple "start-relation-end" triples, each with accompanying descriptive text for the node and relation. The executing entity encapsulates this data into a structured list or graph data object and marks it as the "first search result." The key value of this result lies in explicitly preserving the direct semantic relationships between entities. For example, continuing from the previous example, the first search result might be organized into a list: Item 1: (Angle Class II malocclusion, has_symptom, deep overbite), description: "manifested as protrusion of the upper anterior teeth"; Item 2: (Angle Class II malocclusion, has_treatment, functional appliance), description: "suitable for patients in the growth and development period".

[0039] Sub-step three involves performing natural language fusion processing on the aforementioned target feature items to obtain the query vector. Natural language fusion processing refers to the process of integrating various textual information contained in the target feature items (such as original descriptions, standard entity names, and superordinate concepts) into a coherent natural language query statement. The query vector is a high-dimensional real-number vector representing the overall semantics of this fused query text, converted using a pre-trained text embedding model. In practice, the execution entity combines key text fields from the target feature items (such as `orig_text`, `std_entity.name`, and `hypernyms`) into a query according to a predetermined template. Subsequently, a pre-trained text embedding model (e.g., the `bge-small-zh-v1.5` model) is used to convert this query text into a fixed-dimensional semantic vector (query vector). For example, given a target feature term {"orig_text":"crowded teeth", "std_entity":{"name":"crowded dentition"}, "hypernyms":["malocclusion"]}, the execution agent merges it into the query: "Crowded teeth, which is a type of malocclusion, referring to crowded dentition". Then, the bge-small-zh-v1.5 model is used to transform this query into a 768-dimensional query vector V_query.

[0040] Sub-step four involves performing an approximate nearest neighbor search on the query vector within the pre-constructed orthodontic knowledge graph. Approximate nearest neighbor search is an algorithm for efficiently finding the Top-K vectors semantically most similar to a given query vector in a high-dimensional vector space. The search object here is a vector library composed of pre-generated vectors of descriptive texts for all entities and relations in the knowledge graph. In practice, before executing this step, the system generates corresponding semantic vectors for all descriptive texts and stores them in a vector database (such as Milvus) while constructing the pre-constructed orthodontic knowledge graph, and simultaneously establishes an efficient index (such as HNSW). At this point, the executing entity submits the query vector V_query generated in sub-step three to the search interface of this vector database. The database uses its index to quickly calculate and return a preset number (e.g., 10) vectors with the highest cosine similarity to V_query and their corresponding original text identifiers. For example, the executing entity inputs V_query into the vector database, which retrieves the 10 text fragment IDs with the highest similarity. These IDs may correspond to different descriptions in the atlas, such as the definition of "crowded teeth", the cause of "insufficient arch length", and the indications for "arch expansion treatment".

[0041] Sub-step five involves obtaining text fragments semantically similar to the query vectors mentioned above, and identifying these text fragments as the second search results. The second search results specifically refer to the set of all relevant text fragments obtained through vector similarity retrieval. These fragments focus on broad semantic matching and are not limited by fixed relational paths. In practice, the execution entity extracts the corresponding complete text content from the original text storage of the knowledge graph based on the list of text fragment IDs returned by the vector database, organizes it into a list, and marks it as the second search result. For example, continuing the previous example, the second search result might be a text list containing fragments such as: "Dental crowding refers to tooth volume exceeding bone volume...", "For mild crowding, proximal enamel removal can be used...", "Insufficient arch length is a common cause of crowding...".

[0042] Step two involves fusing and reordering the obtained first and second search results to generate enhanced information. This fusing and reordering process combines structured results from graph retrieval with semantically similar results from vector retrieval, reordering and filtering them based on their overall relevance to the current query, ultimately forming a unified and information-rich knowledge set. The enhanced information is the output of this process; it is an optimized and ordered knowledge package containing multi-faceted relevant information. In practice, the executing entity first merges all first search results (structured triples and their text) and second search results (text fragments) obtained for the current target feature into a candidate list. Then, a reordering model (e.g., the open-source BGE reordering model mentioned in the disclosure document) is used to finely score the merged list. This model takes the original query text and each candidate item as input and outputs a relevance score. Finally, the executing entity sorts all items in descending order based on the score, selects a certain number of the top-ranked items, organizes them in a uniform format (e.g., text summary), and outputs the final enhanced information. For example, for the feature "crowded teeth," the agent merges the structured results related to "arch expansion treatment" retrieved from graph retrieval with the text fragments on "etiology" retrieved from vector retrieval. After scoring by the BGE re-ranking model, "etiology and diagnostic methods" might be ranked first, followed by "mild treatment options." The final enhanced information is an ordered list, with a summary integrating key information likely at the beginning.

[0043] Step 105: Generate a structured target planning scheme based on the enhanced information and key feature information.

[0044] In some embodiments, the aforementioned execution entity may generate a structured target planning scheme based on the aforementioned enhanced information and the aforementioned key feature information.

[0045] In some optional implementations of certain embodiments, the aforementioned execution entity can generate a structured target planning scheme based on the aforementioned enhanced information and key feature information through the following steps: Step one involves formatting the augmented information to obtain formatted augmented information. Formatting refers to converting the augmented information output from step 104, which may contain various data formats (such as structured triples or plain text fragments), into one or more coherent natural language text segments that conform to the input format requirements of the large language model. The formatted augmented information is the output of this process, integrating scattered knowledge points into a logically coherent text description that can be directly used as context. In practice, the executing entity uses a predefined text organization template to link the various entries in the augmented information (e.g., a relation triple and its description, or a piece of plain text evidence). The template might be "Based on relevant knowledge: Entry 1 description: ...; Entry 2 description: ...". This process aims to eliminate structural differences in the original data and generate a fluent descriptive text that facilitates interaction with the large language model. For example, if the enhanced information includes the entries "Angle Class II malocclusion is often accompanied by deep overbite" and "For adolescent Angle Class II cases, functional appliances may be considered", then the formatted text paragraph may be: "According to relevant knowledge: Angle Class II malocclusion is often accompanied by deep overbite. For adolescent Angle Class II malocclusion cases, clinical intervention with functional appliances may be considered." Step two involves combining the formatted enhanced information with the key feature information using natural language to obtain the input context. Natural language combination refers to integrating the formatted enhanced information (as background knowledge) with the key feature information obtained from step 103 (as the current patient's specific situation) into a complete and coherent natural language paragraph according to a specific narrative logic. The input context is the output of this process; it is a comprehensive text containing both "known general knowledge" and "current specific situation," providing a complete information foundation for generating a targeted solution. In practice, the executing entity uses a context construction template. This template typically includes two parts: the first part, followed by a guide word and formatted enhanced information, states general medical knowledge; the second part, followed by a guide word, summarizes the core descriptions (such as their entity names) of each target feature item in the key feature information, stating the patient's characteristics. The two parts are combined into a coherent paragraph. For example, the input context might be constructed as follows: "The relevant medical knowledge is as follows: Angle Class II malocclusion is often accompanied by deep overbite. Functional appliances may be considered for adolescent Angle Class II malocclusion cases. The key characteristics of the current patient include: Angle Class II malocclusion, with deep overbite, and age of adolescent." Step three involves concatenating the input context with the preset prompt template to obtain the complete prompt. The preset prompt template is a predefined piece of natural language text containing task instructions and output format requirements, used to guide the large language model in a goal-oriented generation task. The complete prompt is the output of this process; it is a combination of instructions, background knowledge, and a specific question, constituting a complete input to the large language model. In practice, the executing entity reads the preset prompt template from the configuration. This template typically includes a role definition (e.g., "You are an orthodontic expert"), a task description (e.g., "Please develop a treatment plan for the patient based on the following knowledge"), output structure requirements (e.g., "Please output the following parts: status classification, planning goals, phased tasks"), and a placeholder for inserting the input context. The executing entity fills this placeholder with the input context text generated in step two, completing the concatenation and forming the final complete prompt sent to the large language model. For example, a preset prompt template might be: "You are an orthodontic expert. Based on the provided medical knowledge and patient characteristics, please develop a structured planning solution. The solution should include: 1. Status classification; 2. Planning goals; 3. Phased task sequence. Medical knowledge and patient characteristics are as follows: {input_context}". The executor fills the aforementioned input context into the {input_context} position to receive the complete prompt.

[0046] Step four involves performing intent parsing on the complete prompt to obtain the core query intent and key clinical constraints. Intent parsing refers to the process of automatically identifying and extracting the core question (i.e., the core query intent) and all possible limiting conditions (i.e., key clinical constraints) that may affect the decision from the complete prompt using the deep semantic understanding capabilities of the large language model. The core query intent is typically a general question statement, while the key clinical constraints are a list of decisive factors among patient characteristics that influence the choice of treatment plan. In practice, the executing entity constructs a prompt specifically for intent parsing, which takes the complete prompt as input and requires the large language model to identify it. For example, the additional instructions might be: "Please extract from the above query: 1. What is the core problem to be solved? 2. What are the necessary clinical constraints?" Subsequently, the executing entity calls the large language model (e.g., the Qwen2-32B model or the deepseek model) to process the parsed prompt and parses the model's output to extract the textual expressions of the core query intent and key clinical constraints. For example, after the aforementioned complete prompt is processed by intent parsing, the core query intent may be: "Develop an orthodontic plan for an adolescent patient with Angle Class II malocclusion and deep overbite"; the key clinical constraints are "Patient age: adolescent", "Malocclusion type: Angle Class II", and "Main symptom: deep overbite".

[0047] Step 5: Based on the core query intent and the complete hints mentioned above, generate various relevant medical concepts and relational paths. Relevant medical concepts refer to key medical terms or entities closely related to the core query intent and identified from the input context (especially the augmented information). Relational paths refer to the logical sequences of connections between these concepts in the knowledge graph. In practice, the executing entity again utilizes the text understanding and association capabilities of the large language model. It constructs an analysis hint, requiring the model to list all relevant medical concepts based on the core query intent, from the background information provided by the complete hints (i.e., the input context), and describe the reasoning or supporting relationships (i.e., relational paths) between them. The output of the large language model is parsed into a list of concepts and relationships. For example, based on the above intent, the model might identify relevant medical concepts including: "Angle Class II malocclusion," "deep overbite," "functional appliance," and "growth and development period." The generated relational paths might include: "Angle Class II malocclusion," "common manifestations," "deep overbite"; "adolescent patients," "in the growth and development period"; "Angle Class II patients in the growth and development period," "applicable," and "functional appliance."

[0048] Step Six: Based on the aforementioned key clinical constraints, the relevant medical concepts and relational paths are screened to obtain core knowledge evidence. Screening refers to filtering, evaluating, and prioritizing the concepts and paths generated in Step Five according to the conditions in the key clinical constraints, retaining the most relevant and directly supportive information for the current decision. Core knowledge evidence is the set of key information retained after screening, used to support the generation of the final plan. In practice, the implementing entity uses key clinical constraints (such as "adolescents," "Angle Class II," and "deep coverage") as screening criteria. It traverses all relevant medical concepts and relational paths obtained in Step Five, evaluating the degree of matching and relevance of each piece of information with these constraints. For example, a path about "adult orthognathic surgery" will be filtered out because it does not conform to the "adolescent" constraint; while a path about "functional appliances promoting mandibular growth" will be retained and given high priority due to a high degree of matching. Finally, the retained items are organized as core knowledge evidence. For example, after screening, core knowledge evidence may include: "Evidence A: Angle Class II malocclusion is characterized by deep overbite" and "Evidence B: Functional appliances are suitable for Angle Class II malocclusion patients in the growth and development period (adolescents)".

[0049] Step Seven: Based on the aforementioned core knowledge evidence and key feature information, generate a reasoning chain. This reasoning chain refers to a coherent text that combines core knowledge evidence (general medical principles) with key feature information (the patient's specific situation), using logical deduction to form a step-by-step reasoning process from "problem" to "solution." In practice, the executing entity uses natural language, presenting the core knowledge evidence as the major premise and the key feature information as the minor premise, guiding the large language model through a syllogistic logical deduction. The executing entity might construct the following prompt: "Based on core knowledge evidence: {core knowledge evidence}, and combined with the patient's specific characteristics: {key feature information}, please deduce the intervention logic for this patient step by step." The coherent argument generated by the large language model accordingly constitutes the reasoning chain. For example, the generated chain of reasoning might be: "The patient is an adolescent in the growth and development stage (from key feature information). Evidence B indicates that functional appliances are suitable for Angle Class II malocclusion patients in the growth and development stage (from core knowledge evidence). The patient has been diagnosed with Angle Class II malocclusion with deep overbite (from key feature information and evidence A). Therefore, intervention with a functional appliance can be considered to utilize growth potential to improve jaw relationships while correcting deep overbite." Step eight involves professionally converting the above reasoning chain into a structured preliminary draft text. Professional text conversion refers to transforming the logical reasoning chain into a preliminary draft text containing multiple prescribed sections, according to the professional expression habits and predetermined structural framework of clinical planning protocols. The structured preliminary draft text is the output of this process; it already possesses a rudimentary plan, but the expression may not be standardized or precise enough. In practice, the implementing entity provides a template containing plan paragraph headings (such as "Status Classification," "Planning Goals," and "Preliminary Intervention Approach"), and requires the large language model to reorganize the content of the reasoning chain and fill in these headings to form a draft. This is essentially using the large language model for text restructuring and formatting. For example, based on the above reasoning chain, the converted structured preliminary draft text might include: Status Classification: Angle Class II malocclusion, deep overbite, growth and development stage. Planning Goals: Utilize growth potential to improve Class II jaw relationships and correct deep overbite of the anterior teeth. Preliminary Intervention Approach: Consider using functional orthodontic appliances for treatment.

[0050] Step nine involves performing terminology standardization verification on the aforementioned preliminary draft text to obtain the initial planning text. Terminology standardization verification refers to the process of replacing any non-standard, colloquial, or synonymous medical terms in the draft with standardized terms defined in a knowledge graph or standard terminology database. The initial planning text is the output after verification, and its terminology is accurate and standardized. In practice, the implementing entity maintains a standard orthodontic terminology dictionary (which can interface with the entity database of the knowledge graph). It scans the preliminary draft text, identifies the specialized terms, and matches and replaces them with those in the standard dictionary. For example, "gum" is replaced with "alveolar bone," and "protruding mouth" is replaced with "anterior labial inclination." This process can be achieved using a dictionary-based lookup and replace algorithm. For example, "adjusting the relationship between the upper and lower teeth" in the draft might be standardized to "establishing a normal molar relationship and anterior overbite / overjet" after verification.

[0051] Step 10: Extract the state classification field, planning target field, and phased task description field from the initial planning text. These three fields are the three core components of the structured goal planning scheme. This step involves parsing and separating these three independent parts from the continuous initial planning text using information extraction techniques. In practice, the implementing entity utilizes natural language processing techniques, such as rule-based pattern matching or trained sequence labeling models, to identify the content belonging to each part of the initial planning text. For example, the state classification field is determined by searching for text following keywords such as "state classification:" or "diagnosis:"; the planning target field is determined by searching for text following words such as "target:" or "aims to"; and the phased task description field is determined by searching for lists or paragraphs guided by phrases such as "task:" or "first phase:". For example, from a text, the following might be extracted: the status classification field contains "Angle Class II malocclusion, deep overbite"; the planning goal field contains "correcting deep overbite and improving profile"; and the phased task description field contains "Phase 1: wearing functional appliances for 12 months...".

[0052] Step 11 involves mapping and organizing the extracted fields according to a predefined structured architecture to obtain a structured target planning scheme. This predefined structured architecture is a framework that defines the data organization of the final scheme, explicitly specifying the format and relationships of the three parts: state classification information, planning target information, and task sequence information, as well as their subfields. The structured target planning scheme is the final output, a machine-readable, well-structured data object. In practice, the execution entity creates a data object conforming to the predefined architecture (e.g., a specific JSON Schema or protocol buffer definition). Then, the state classification field text extracted in Step 10 is filled into the "State Classification Information" attribute of this object; the planning target field text is filled into the "Planning Target Information" attribute; and the phased task description text is parsed into multiple "Task Phase Information" objects (each object containing subfields such as operation description, execution object, and expected parameters), and a list is created and filled into the "Task Sequence Information" attribute. This generates the final structured target planning scheme. For example, the final structured goal planning scheme might be a JSON object: json{“Status Classification Information”:“Angle Class II malocclusion, deep overbite, growth and development period”,“Planning Goal Information”:“Utilize growth potential to improve jaw relationship and correct deep overbite”,“Task Sequence Information”:[{“Operation Description”:“Wearing functional orthodontic appliance”,“Execution Object”:“Patient”,“Expected Parameters”:“Duration: 12 months”},... / / Other stage tasks]}.

[0053] Step 106: Generate a set of control instructions based on the structured target planning scheme.

[0054] In some embodiments, the aforementioned execution entity may generate a set of control instructions based on the aforementioned structured target planning scheme.

[0055] In some optional implementations of certain embodiments, the aforementioned execution entity can generate a set of control instructions based on the aforementioned structured target planning scheme through the following steps: Step 1: For each task stage information in the above task sequence information, perform the following sub-steps: Sub-step one involves generating a task item to be executed corresponding to the task stage based on the operation description, execution object, and expected parameters corresponding to the task stage information. Here, the task item to be executed refers to the intermediate data representation formed after preliminary parsing and structuring of a task stage information. It transforms the core actions, objectives, and specific parameter requirements described in the natural language of the task stage information into a more standardized form suitable for machine automation. In practice, the executing entity parses the data structure of the task stage information. It extracts the text of the "Operation Description" field (e.g., "Print maxillary dental model"), the text of the "Execution Object" field (e.g., "maxilla"), and the text or numerical value of the "Expected Parameters" field (e.g., "Material: Medical plaster, 1:1 scale") from this structure. Then, the executing entity organizes this information according to a predefined task item data format to generate a task item object to be executed. This format typically clearly distinguishes between action types, target identifiers, and parameter dictionaries. For example, for a task stage information {"Operation Description": "Print maxillary dental model", "Execution Object": "Maxillary", "Expected Parameters": "Material: Medical plaster, Scale 1:1"}, the generated task item to be executed might be {"action": "print_dental_model", "target": "maxilla", "params": {"material": "medical_gypsum", "scale": "1:1"}}.

[0056] Sub-step two involves mapping the generated task items to be executed to control opcodes. Control opcodes are standardized codes representing a series of atomic operation commands that the target external execution device (or its underlying controller) can directly recognize and execute. Mapping refers to searching and determining the uniquely corresponding device-level operation code based on the action type and target defined in the task item, within a pre-configured mapping table. In practice, the execution entity maintains a device-operation mapping table. This table records all operation commands supported by different types of external execution devices (such as "3D printers" and "intraoral scanners"), and assigns a unique opcode (usually a string or numeric code) to each command. The execution entity reads the action and target fields from the task item and uses them as a key to query this mapping table. If a match is found, the corresponding opcode is extracted; otherwise, error handling or the default mapping process may be triggered. For example, for a task item {"action": "print_dental_model", "target": "maxilla", ...}, after querying the mapping table, it might map to the opcode "CMD_PRINT_STL" for the "3D printer" device. This opcode instructs the printer to perform a model printing job.

[0057] Sub-step three involves encapsulating the aforementioned execution object and expected parameters according to the data format corresponding to the control opcode, resulting in the raw control instruction corresponding to the task to be executed. Encapsulation refers to assembling the control opcode, the specific execution object identifier (e.g., "maxilla"), and all relevant expected parameters into a complete instruction data packet that can be directly sent via network or bus, according to the specific communication protocol and data format required by the target external execution device. The raw control instruction is a single device instruction generated in this process that has not yet undergone global scheduling and conflict checking. In practice, the execution entity determines the target device's communication protocol (e.g., TCP / IP-based JSON-RPC or a specific binary protocol) based on the control opcode. It then creates an instruction object or data frame conforming to the protocol format. The header or command field of this data structure is filled with the control opcode, while the data payload is filled with the serialized target and params information from the task to be executed, according to the protocol specification. For example, for the opcode "CMD_PRINT_STL," the corresponding protocol might require a JSON instruction. The encapsulated raw control commands might look like this: {"cmd":"CMD_PRINT_STL","job_id":"job_001","target":"maxilla","params":{"material":"medical_gypsum","scale":"1:1","file_url":"http: / / server / model_maxilla.stl"}}. Here, job_id is a unique task identifier generated by the system, and file_url is the address of the 3D model file automatically associated with target.

[0058] Step two involves sorting the obtained raw control instructions based on the order of the task stages in the task sequence information, resulting in a set of raw control instructions. Sorting refers to arranging the raw control instructions generated for each task stage in Step one strictly according to the chronological order of the task stages specified in the "Task Sequence Information" list in the structured goal planning scheme, maintaining an execution sequence consistent with clinical logic. The set of raw control instructions is a sorted, sequentially arranged list of instructions. In practice, when the executing entity traverses the task sequence information and generates raw control instructions, it appends the index number of the corresponding original task stage in the sequence to each instruction. After processing all task stages, the executing entity sorts all raw control instructions in ascending order based on this index number, forming an ordered list, which is the set of raw control instructions. For example, the task sequence information contains [Stage A, Stage B, Stage C]. The generated raw control instructions are instr_A, instr_B, and instr_C, respectively. The sorted set of raw control instructions is the ordered list [instr_A, instr_B, instr_C].

[0059] Step three involves conflict detection and resolution processing of the original control instruction set to obtain the control instruction set. Conflict detection and resolution involves analyzing whether there are resource competition, timing overlaps, or logical contradictions (i.e., conflicts) between different instructions in the original control instruction set, and automatically adjusting instruction parameters or execution order according to preset rules to eliminate conflicts upon detection. The control instruction set is the final output after this processing; it is a sequence of instructions that has passed compatibility checks and can be directly or after scheduling sent to external execution devices. In practice, the execution entity runs a conflict detection module. This module may check for the following types of conflicts: 1) Device resource conflicts: whether two or more instructions require the same device to perform mutually exclusive operations within the same time period; 2) Time window conflicts: whether the execution time windows of the instructions overlap and are unacceptable based on the estimated execution duration; 3) Parameter logic conflicts: whether there are contradictions in the parameter settings of the instructions (e.g., requiring two different working modes for the same device). The detection algorithm may be based on a rule base or constraint solving. If a conflict is detected, the resolution strategy may include: inserting a waiting time for the conflicting instructions, adjusting the execution order of the instructions (within the allowable clinical logic range), or modifying a non-critical parameter of the instruction. After all conflicts are resolved, the original set of control instructions is updated to form the final set of control instructions. For example, suppose in the original set of control instructions, instr_A commands a 3D printer to print a model (estimated time 4 hours), and instr_B commands the same printer to perform calibration (which needs to be completed before printing). The conflict detection module detects a device resource conflict. Based on the rule of "calibration takes precedence over printing," the resolution module automatically adjusts the order of instr_B to before instr_A, and may add a "wait for calibration to complete" trigger condition to instr_A, thereby generating a conflict-free final set of control instructions.

[0060] Step 107: Control the external execution device based on the set of control instructions.

[0061] In some embodiments, the aforementioned execution entity may control external execution devices based on the aforementioned set of control instructions.

[0062] In some optional implementations of certain embodiments, the aforementioned execution entity can control the external execution device based on the aforementioned set of control instructions through the following steps: The first step involves parsing the aforementioned set of control instructions to obtain the control information corresponding to each control instruction. This control information includes the target device identifier, operation type, execution parameters, and execution constraints. Instruction parsing refers to the process of deconstructing and interpreting each instruction data in the control instruction set output in step 106, which has undergone conflict resolution, to extract independently identifiable and processable metadata. The control information obtained after parsing is a structured data object used to uniquely identify a control task and guide its execution. The target device identifier is a string or code used to uniquely identify a specific external execution device, such as "Printer_01" or "Scanner_Chairside". The operation type is a standardized description defining the core action the device needs to perform, such as "start_print" or "initiate_scan". Execution parameters are the specific configurations or input data necessary to complete the operation type, such as the URL of the print file or the scan resolution setting. Execution constraints are rules that limit the timing or prerequisites for the instruction's execution, such as "must be executed after task A is completed" or "execute when the system is idle". In practice, the aforementioned execution entity traverses the list of control instructions, parsing each instruction data (which may be a JSON object or a binary data block) in the list. Based on the pre-known instruction data format or protocol specification, it extracts the target device identifier field, operation type field, execution parameter field containing key-value pairs, and optional execution constraint field from each instruction, and encapsulates this information into a new control information object. For example, a control instruction data set might be {"device_id":"3DP_001","command":"CMD_PRINT","params":{"file":"model.stl","material":"resin"},"constraint":"after_calibration"}. After parsing and processing, the obtained control information object is: {“target_device_id”:“3DP_001”,“operation_type”:“CMD_PRINT”,“execution_params”:{“file”:“model.stl”,“material”:“resin”},“execution_constraint”:“after_calibration”}.

[0063] The second step involves logically sorting and resolving conflicts among the control instructions based on their respective execution constraints and target device identifiers, resulting in a globally ordered instruction queue. Logical sorting and conflict resolution involve analyzing the dependencies, resource contention, and potential conflicts between instructions based on their execution constraints and target device identifiers, and then globally and optimally sorting all instructions to form a deterministic, conflict-free execution sequence. The globally ordered instruction queue is the output of this process; it is a list of sequentially arranged control information objects that defines the logical order of execution for all control tasks. In practice, the execution entity first analyzes the execution constraints in all control information and constructs a dependency graph between instructions. For example, if instruction B's constraint is "after instruction A," an edge is created from A to B. Simultaneously, instructions with the same target device identifier are checked to determine if their operation types are logically or resource-wise mutually exclusive. Next, the execution entity runs a scheduling algorithm (such as a topology-based algorithm or a more complex resource scheduling algorithm) to calculate a feasible execution order while satisfying all constraints and avoiding resource conflicts. Ultimately, all control information is arranged in this order, forming a globally ordered instruction queue. For example, suppose there are three control pieces of information: A (Device: Printer, Constraint: None), B (Device: Printer, Constraint: After A), and C (Device: Scanner, Constraint: None). After logical sorting and conflict resolution, since A and B target the same printer and B depends on A, while C has no resource conflict with them, the resulting globally ordered instruction queue may be [A, C, B] or [A, B, C], depending on the scheduling strategy.

[0064] The third step involves grouping the globally ordered instruction queue based on the target device identifiers to obtain device-level instruction sequences. These device-level instruction sequences include individual device-level instructions. Grouping refers to categorizing the control information in the globally ordered instruction queue into different sub-sequences according to their target device identifiers. A device-level instruction sequence is a sub-sequence of control information extracted from the globally ordered instruction queue and maintaining its original relative order, specifically for a particular external execution device. A device-level instruction refers to each piece of control information in this sub-sequence; in this context, it is called a device-level instruction because it belongs to a specific device. In practice, the execution entity traverses the globally ordered instruction queue. It maintains a dictionary or mapping table with the target device identifier as the key. For each piece of control information in the queue, it is appended to the instruction list of the corresponding device based on its target device identifier. After traversal, the instruction list corresponding to each target device identifier constitutes a device-level instruction sequence, and the order of the instructions in the list is consistent with the order in which they appear in the globally ordered instruction queue (for instructions related to that device). For example, the globally ordered instruction queue is [A(device P), B(device S), C(device P)]. After grouping, we obtain the device-level instruction sequence [A, C] for device P and the device-level instruction sequence [B] for device S. A and C are called device-level instructions for device P.

[0065] The fourth step involves performing cross-device timing coordination processing on the aforementioned device-level instruction sequences to obtain a global scheduling timing diagram. Cross-device timing coordination processing refers to the process of assigning a specific planned execution time point (or time window) to each device-level instruction in all device-level instruction sequences, considering the estimated execution duration of each device-level instruction, the device's ready state, and potential cross-device collaborative dependencies. The global scheduling timing diagram is the output of this process; it is a data structure describing the planned start and end times of each device-level instruction on the absolute or relative time axis, as well as the timing relationships between instructions. In practice, the aforementioned execution entity may employ a timeline-based scheduling algorithm. The input consists of each device-level instruction sequence and the estimated duration of each device-level instruction (which can be estimated from its operation type and execution parameters or obtained by looking up a table). The scheduler, on the simulated timeline, assigns a start time to each device-level instruction, satisfying the following conditions: instructions on the same device are executed sequentially; instructions on different devices are executed in parallel as much as possible; and any explicitly declared cross-device timing constraints are respected (e.g., a print instruction can only begin after a scan instruction is completed). The final output global scheduling sequence diagram can be a Gantt chart data table, listing the ID, planned start time, and planned duration of each device-level instruction. For example, the instruction sequence of device P [A (lasts 2 hours), C (lasts 1 hour)] and the instruction sequence of device S [B (lasts 0.5 hours)], after coordination, may generate a global scheduling sequence diagram that specifies: B starts at time T0 and ends at T0+0.5 hours; A starts at time T0 and ends at T0+2 hours; C starts at time T0+2 hours (because it needs to be after A) and ends at T0+3 hours.

[0066] Fifth, for each device-level instruction sequence in the above-mentioned device-level instruction sequences, perform the following steps: The first sub-step involves generating the execution start time and duration for each device-level instruction in the aforementioned device-level instruction sequence, based on the aforementioned global scheduling timing diagram. The execution start time refers to the absolute or relative point in time when the device-level instruction is scheduled to begin execution. The duration refers to the estimated time required to complete the operation corresponding to the instruction. In practice, for a given device-level instruction sequence, the execution entity iterates through each device-level instruction in the sequence. For each device-level instruction, based on its unique identifier (or its correspondence in the sequence and the global scheduling timing diagram), it queries the global scheduling timing diagram generated in the fourth step to determine its assigned planned start time and planned duration, and associates these two time values ​​with the device-level instruction. For example, for device-level instruction A in the instruction sequence of device P, the planned start time is found to be T0, and the planned duration is 2 hours, as determined by the global scheduling timing diagram. Therefore, the execution start time of instruction A is determined to be T0, and the duration is 2 hours.

[0067] The second sub-step generates a trigger timing plan corresponding to the aforementioned device-level instruction sequence based on the execution start times and durations corresponding to each of the generated device-level instructions. The trigger timing plan is a list of instruction trigger events arranged chronologically for a specific external execution device. Each trigger event contains a device-level instruction and its planned execution start time. In practice, the execution entity pairs all device-level instructions in the same device-level instruction sequence with their respective execution start times, forming (instruction, start time) pairs. These pairs are then sorted according to their execution start times from earliest to latest, forming an ordered list. This list is the trigger timing plan corresponding to the device. It can be viewed as a calendar of tasks to be executed, sorted by timestamps. For example, if device P's device-level instruction sequence contains instruction A (start time T0) and instruction C (start time T0+2h), the generated trigger timing plan would be: [{"instruction":A, "start_time":T0}, {"instruction":C, "start_time":T0+2h}].

[0068] Step 6: In response to reaching the execution start time corresponding to any device-level instruction in any triggering timing plan, obtain the control instruction corresponding to the aforementioned device-level instruction, as well as the corresponding control information. Responding to reaching the execution start time means that the system real-time clock or scheduler detects that the current time has reached or exceeded the planned start time set by a device-level instruction in a triggering timing plan. The control instruction corresponding to the device-level instruction refers to the original instruction data generated in step 106, which has not undergone the processing of the previous steps in step 107, and corresponds to the current device-level instruction (actually control information). The corresponding control information refers to the structured information contained in the current device-level instruction itself. In practice, the aforementioned execution entity runs a high-precision timer or scheduling loop to continuously monitor the triggering timing plans of all devices. When it detects that the current time has reached the start time in a certain plan item, an event is triggered. This event handler obtains the device-level instruction object from the plan item and uses this device-level instruction object (i.e., control information) to retrieve the original control instruction data corresponding to its generation in step 106 (usually associated through the instruction ID). Simultaneously, the target device identifier, operation type, execution parameters, and other information (i.e., control information) contained in the device-level instruction object itself are also directly obtained for subsequent device driving. For example, when the system time reaches T0+2h, the monitor triggers a plan item {"instruction":C, "start_time":T0+2h} for device P. The processor obtains the device-level instruction C from this plan item, then finds its corresponding original control instruction data in storage through the ID of instruction C, and simultaneously directly reads the control information already contained in instruction C.

[0069] Step 7: Based on the acquired control information, drive the target external execution device corresponding to the target device identifier in the control information to perform the physical operation corresponding to the operation type and execution parameters in the control information. Driving the device to perform a physical operation means converting the abstract operation type and parameters in the control information into actual electrical signals, data packets, or mechanical actions through the device's specific communication interface and protocol, thereby controlling the target external execution device to complete a specific task that produces an effect in the physical world. The target external execution device can be a task-level external execution device or a servo-level external execution device. Task-level external execution devices can receive and execute high-level, discrete task instructions (such as "start printing" or "execute scan"), and their internal controller is responsible for decomposing these instructions into low-level motions or operations. Examples include 3D printers and automated model polishing machines. Servo-level external execution devices not only receive task instructions but, more importantly, possess high-precision force / torque sensing capabilities and low-level servo drive interfaces (such as EtherCAT and CANopen), allowing the system to continuously and frequently fine-tune their pose or torque. Examples include intraoral scanners with force feedback, robot-assisted wire bending machines, and surgical navigation robotic arms. In practice, the aforementioned execution entity first determines the device interface (e.g., a specific network address, serial port, or API endpoint) to which it needs to communicate based on the target device identifier in the control information. Then, it encapsulates the operation type and execution parameters into a device-recognizable drive command according to the device's predefined communication protocol and data format. Finally, it sends this drive command to the target external execution device via a corresponding communication link (e.g., Ethernet, USB, Bluetooth). After receiving and parsing the command, the device's internal controller or actuator initiates the corresponding physical operation. For example, the control information might be {"target_device_id":"3DP_001","operation_type":"CMD_PRINT","execution_params":{"file":"model.stl","material":"resin"}}. The execution entity finds the network API address of the corresponding 3D printer based on "3DP_001," then constructs an HTTP POST request conforming to the printer's API specification. The request body contains the command to start the printing job, model file path, material type, and other parameters, and sends the request out. Once the printer receives the request, it begins loading the model.stl file from the specified path and starts the printing process using resin material, which is a physical manufacturing process.

[0070] The first to seventh steps of the control execution phase in this disclosure are an inventive point that solves the technical problem that "existing intelligent orthodontic systems have a disconnect between the issuance and execution of control commands, manifested as a disconnect between planning schemes and equipment protocols, and a lack of global timing scheduling and conflict pre-resolution in multi-device collaborative execution, making it difficult for intelligent diagnosis and treatment decisions to be orderly, reliably, and efficiently translated into physical world actions in complex multi-device processes." Existing technologies have the following shortcomings in macro-level task execution control: Firstly, the structured task sequences generated by intelligent planning cannot be directly adapted to heterogeneous orthodontic medical devices, lacking a unified parsing and compilation layer from clinical task description to specific device control commands; secondly, in clinical processes involving multiple devices (such as scanners and printers), there are logical dependencies and resource competition among commands, but traditional control systems lack a global perspective for sequencing and conflict pre-resolution mechanisms, easily leading to execution deadlock or timing chaos; thirdly, even if there are no command conflicts, in multi-device parallel scenarios, there is a lack of scientific cross-device timing coordination and triggering mechanisms based on precise time points, making it difficult to optimize overall execution efficiency and predict the execution process. Solving the above problems would allow for the construction of a deterministic control loop at the macro level, encompassing instruction compilation, global optimization and sorting, device task decomposition, and time-driven execution, ensuring the orderly and automated operation of complex clinical processes. To achieve this, this disclosure proposes the following: First, the control instruction set is parsed to obtain the control information corresponding to each instruction. This deconstructs and standardizes the control instruction data packets generated at the upper layer, which have a unified format but diverse content, into structured objects containing key metadata such as target device identifier, operation type, execution parameters, and constraints. This resolves the format mismatch between abstract control instructions and the information required by specific device drivers, providing clear and standardized data input for all subsequent scheduling and execution steps. Second, based on each execution constraint and target device identifier, each control instruction is logically sorted and conflict-resolved to obtain a globally ordered instruction queue. Therefore, before actually driving the physical device, based on the logical sequence of instructions (constraints) and the exclusivity of device resources (same device identifier), all instructions to be executed are topologically sorted and conflict detected and eliminated globally. This produces a theoretically optimal or feasible execution sequence without logical contradictions or resource contention, eliminating runtime crashes or errors that may be caused by instruction interleaving from the decision-making source and ensuring the fundamental feasibility of the execution process. The third step involves grouping the aforementioned globally ordered instruction queue based on the identifiers of each target device to obtain device-level instruction sequences.Therefore, the optimized global execution blueprint is logically divided according to the execution responsibility entity (i.e., specific equipment), generating a unique task sub-list for each device that maintains its relative order in the global queue. This achieves a clear decomposition from the "overall collaborative operation map" to "individual combat instructions," laying the foundation for subsequent refined management of individual devices. The fourth step involves cross-device timing coordination processing of each device-level instruction sequence to obtain a global scheduling timing diagram. Thus, after fully considering the estimated time consumption of each task, the device readiness status, and potential cross-device collaboration timing requirements, a qualified specific plan start time and end time are assigned to each instruction on all devices, creating a macroscopic and visualized "collaborative operation schedule." This achieves parallel arrangement of tasks on different devices and minimizes the overall execution time, optimizing system resource utilization and process efficiency from a time perspective. The fifth step involves generating a corresponding trigger timing plan for each device-level instruction sequence based on the aforementioned global scheduling timing diagram. Thus, the schedule generated in step four, which is geared towards global coordination, is transformed into a "timed task list" that each device controller can directly interpret and monitor. This list clearly defines the precise timestamp when each device-level instruction is triggered for execution, realizing a reliable conversion from a collaborative scheduling plan to a single-device executable trigger event, and providing a direct basis for a highly deterministic time-driven execution mode. Step six: In response to the arrival of the execution start time corresponding to any device-level instruction in the trigger sequence plan, the control instructions and control information corresponding to the aforementioned device-level instructions are obtained. Thus, through a system-level high-precision timing monitoring module, the tasks to be executed are captured with millisecond-level accuracy at the planned time point, and their corresponding complete drive data packets (original control instructions) and parsed information (control information) are accurately indexed and loaded. This ensures that the correct control instructions are accurately awakened and ready at the precisely planned time, solving the problem of randomness in trigger timing caused by event-driven or polling mechanisms. Step seven: Based on the acquired control information, the target external execution device is driven to perform the corresponding physical operation. Thus, the parsed structured control information is ultimately converted into drive commands recognizable by the device through device-specific communication interfaces and protocols, and sent to reliably trigger physical devices (such as starting a 3D printer to begin manufacturing or commanding an intraoral scanner to begin data acquisition) to complete the predetermined clinical operation. This completes the final signal conversion and energy drive from digital intelligent decision-making to physical change in the physical world, realizing the physical closed loop of the entire intelligent control process. In summary, the first to seventh steps of this embodiment are interconnected, starting from the entire chain of "instruction parsing, global sorting and resolution, device task decomposition, cross-device timing scheduling, trigger plan generation, precise time triggering to final reliable drive," jointly constructing a macroscopic deterministic control closed loop that is pre-planned, conflict-resolved, parallel-schedulable, and time-triggered for complex multi-device processes.This ensures that automated processes involving multiple devices in orthodontic clinical practice (such as "scan first, then design, then print") can be executed reliably, orderly, and efficiently according to the preset optimal logic and timing. It accurately transforms the macro blueprint of intelligent decision-making into coordinated actions in the physical world, fundamentally improving the automation level, execution reliability, and overall efficiency of the system in handling complex tasks.

[0071] In addressing the technical problem of "closed loop from decision-making to execution" using the aforementioned technical solution in step 107, the following technical issues often arise for the operational scenarios of the precision orthodontic equipment to be applied (e.g., intraoral scanning relying on force-position interaction, robot-assisted archwire bending, implant guide navigation, or soft tissue retraction): When a servo-level external execution device (i.e., a precision device with force sensing and a low-level servo interface) dynamically interacts with the fragile biological tissues or complex geometric structures in the patient's oral cavity, traditional programmed control commands based on pre-planned trajectories and fixed parameters (from step 107) lack the ability to instantaneously perceive and adjust the real-time interactive forces and motion states. This may lead to unexpected contact force exceeding limits, motion trajectory deviation, or interaction instability due to individual anatomical differences, tissue deformation, patient micro-movements, or tool wear, thereby directly affecting the accuracy, safety, and efficiency of the operation. Simple timing scheduling and task-level control cannot solve this kind of dynamic adaptation problem of low-level physical interaction. To address the following requirements for this application scenario: While ensuring macroscopic task coordination, we aim to further achieve high precision, high security, and dynamic adaptive compensation capabilities for microscopic, continuous physical interaction processes. Therefore, we have decided to adopt the following solution: Optionally, the aforementioned implementing entity may also perform the following steps: The first step involves real-time acquisition of multimodal state monitoring data corresponding to any target external execution device when it begins to perform any physical operation. This multimodal state monitoring data includes device motion trajectory data and force sensing data. "Responding to the start of any physical operation" refers to the data acquisition initiation event automatically triggered by the system after step 107 (seventh step) successfully drives the target external execution device and confirms its operation. The target external execution device refers to a physical device capable of performing precise orthodontic-related operations, such as an intraoral scanner, a CNC wire bending machine, or the end effector of a surgical robot. Multimodal state monitoring data refers to a set of real-time measurements synchronously acquired from multiple sensors installed on or integrated into the device, reflecting the device's operating status and its interaction with the environment. Device motion trajectory data refers to a data sequence acquired through encoders, visual tracking systems, or inertial measurement units (IMUs) describing the changes in the position, velocity, and acceleration of the device's end effector in three-dimensional space over time. Force sensing data refers to the sequence of force and torque components in three translational and three rotational directions, acquired by a six-dimensional force / torque sensor, describing the interaction between the end effector of the device and the manipulated object (such as the patient's dentition or gingival tissue). In practice, after the aforementioned actuator sends the drive command in step 107, it immediately sends a synchronization start command to the data acquisition system connected to the target external actuator. This acquisition system reads the counting signal from the motion encoder and the analog or digital output from the force sensor in parallel at a fixed high frequency (e.g., 1 kHz). The acquired raw signals, after analog-to-digital conversion, unit conversion, and preliminary filtering, are encapsulated into data packets with precise timestamps and streamed to the actuator for processing in real time. For example, when controlling an intraoral scanner with force feedback to start scanning, the system simultaneously begins acquiring trajectory data (position, attitude) output from the optical positioning system of the scanning head and contact force data output from its end effector force sensor.

[0072] The second step involves time synchronization and alignment of the aforementioned multimodal state monitoring data to obtain a synchronized data stream. This time synchronization and alignment process involves using algorithms such as interpolation or sliding window matching to normalize the motion trajectory data stream and force sensing data stream from different sensors (which may have inherent delays due to transmission or processing links) onto a unified and strictly corresponding time base, based on their precise timestamps. The aim is to eliminate time differences caused by sensor heterogeneity and transmission jitter, ensuring that the motion and force states at the same physical moment can be accurately correlated. The synchronized data stream is the output of this step; it is a sequence of "(motion, force)" data pairs with perfectly aligned timestamps. In practice, the aforementioned execution entity receives the time-stamped motion and force data packets from the first step. Since the sampling times of different sensors and the data preprocessing time may differ by microseconds, the system employs a timestamp-based sliding window alignment algorithm. This algorithm searches for the force data with the closest timestamp within a very small tolerance window (e.g., ±1 millisecond) for each motion data timestamp. If a perfectly matching force data timestamp is not found, linear interpolation is used to calculate the force value corresponding to that moment of motion based on two adjacent force data points within the window. After this processing, the two original independent data streams are merged into a single, strictly synchronized data stream, providing an accurate foundation for subsequent feature extraction.

[0073] The third step involves dynamic feature extraction processing of the aforementioned synchronized data stream to obtain a comprehensive feature vector. Dynamic feature extraction refers to the process of calculating a set of mathematical features that compactly and multidimensionally characterize the dynamic properties of the current physical interaction within a real-time sliding analysis time window (e.g., synchronized data from the past 100 milliseconds), based on time synchronization. The comprehensive feature vector is the output of this process; it is a high-dimensional real-number vector formed by concatenating multiple calculated feature values ​​in a predetermined order, and serves as the input to the downstream model. In practice, the aforementioned execution entity maintains a fixed-length first-in-first-out (FIFO) data buffer, the capacity of which corresponds to a preset window time length (e.g., 100 data points at a 1kHz sampling rate). This buffer continuously stores the latest synchronized (motion, force) data pairs generated in the second step. Upon receiving a new set of synchronized data, the buffer discards the oldest set and incorporates the new data, thus enabling the window to slide. All dynamic feature calculations are completed instantaneously based on all data in the current buffer. This mechanism ensures that the system always extracts features based on the most recent and representative interaction history data, thus achieving an optimized balance between feature stability and system response agility for precise orthodontic operations. For example, features include: the norm of the instantaneous velocity and acceleration vectors of the motion trajectory (reflecting the intensity of the motion), the amplitude and direction cosines of the contact force and torque vectors, the spectral energy of the motion and force signals in a specific frequency band (e.g., 0-20Hz) (reflecting the frequency domain characteristics of the interaction), and a real-time correlation metric between the motion trajectory and the force vector (which can initially reflect impedance characteristics). Finally, all feature values ​​calculated in this window (e.g., 20) are combined in a fixed order into a one-dimensional vector, i.e., a comprehensive feature vector. For example, for a six-DOF robot end effector, this step may generate a comprehensive feature vector containing multiple types of information, including position, velocity, force, and frequency domain energy.

[0074] The fourth step involves inputting the aforementioned comprehensive feature vector into the dynamic physical interaction model to obtain the dynamic interaction impedance between the end effector of the external execution device and the manipulated object. The dynamic physical interaction model is a trained machine learning model whose function is to estimate the dynamic interaction impedance at the contact point between the device's end effector and the manipulated object based on real-time collected motion-force dynamic features. This dynamic interaction impedance is a physical concept, modeled here as a set of parameters describing the dynamic characteristics of the manipulated object (such as biological tissue) resisting changes in the device's end effector motion at the contact point. It can typically be modeled as a set of stiffness, damping, and inertia parameters, or an approximate representation of the frequency response. In practice, the execution entity maintains a pre-trained dynamic physical interaction model. This model can be a deep neural network (such as a multilayer perceptron, MLP), where the dimension of the input layer matches the length of the comprehensive feature vector, and the output layer outputs impedance parameters (e.g., 12 parameters in total, a 6x6 diagonal stiffness matrix and a diagonal damping matrix). The model's training data comes from controlled environments where the target external execution device interacts with various simulated oral tissue materials, simultaneously recording high-precision motion and force data, as well as real interaction impedance parameters obtained through specialized equipment measurement or system identification methods. The training objective is to minimize the error (e.g., mean square error) between the model's predicted impedance parameters and the actual impedance parameters. During the deployment phase, the execution subject inputs the comprehensive feature vector obtained in the second step into the model, and after forward propagation, the model outputs an estimated dynamic interaction impedance parameter vector. For example, for a scanning operation, the model might output an impedance parameter vector indicating that the current scanning head's contact area with the gingiva exhibits "low stiffness, moderate damping" characteristics.

[0075] The fifth step involves comparing and evaluating the dynamic interactive impedance with the preset target interactive impedance to obtain the impedance error. The preset target interactive impedance is a pre-defined ideal interactive impedance parameter between the device end and the object being operated on, based on the safety and effectiveness requirements of the current physical operation. For example, a compliant state of "low stiffness, high damping" is desired during safe contact probing, while a rigid state of "high stiffness, low damping" is desired during stable cutting. The comparison and evaluation refers to the difference between the dynamic interactive impedance parameters estimated by the calculation model and the target interactive impedance parameters. The impedance error is a quantitative representation of this difference, which can be a scalar value (such as Euclidean distance) or a vector of the same dimension as the impedance parameters (the differences between the parameters). In practice, the executing entity queries the corresponding target interactive impedance parameter vector from a preset configuration library based on the type of physical operation currently being performed (which can be determined from the operation type in the control information). Then, the dynamic interactive impedance parameter vector output by the model in the third step is compared element-by-element with this target vector, and the difference is calculated. A common evaluation method is to calculate the Euclidean distance between the two vectors, or to sum the differences in each dimension in a weighted manner to obtain a comprehensive impedance error scalar. For example, if the target impedance is Kt = [100,100,...], Bt = [10,10,...], and the estimated impedance is Ke = [120,90,...], Be = [8,12,...], then the calculated impedance error vector may be [20,-10,..., -2, 2,...], and its norm (such as the L2 norm) can be used as the overall error scalar.

[0076] Step 6: In response to the obtained impedance error exceeding a preset stability threshold, a high-frequency fine-tuning command is generated based on the impedance error. The preset stability threshold is a configurable scalar value used to determine whether the current interaction state deviates sufficiently from the desired target, thus requiring the initiation of compensation control. The high-frequency fine-tuning command refers to a command calculated to make minor adjustments to the device's current execution command in order to reduce the impedance error; its generation and issuance frequency is much higher than the main control command (e.g., reaching hundreds of hertz). In practice, the aforementioned execution entity compares the impedance error (scalar or vector) calculated in step 4 with the preset stability threshold. If the error exceeds the threshold, the fine-tuning command generation process is triggered. The generation algorithm is usually based on impedance control principles. A common implementation is to input the impedance error vector into a proportional-derivative (PD) controller. This controller calculates, based on the magnitude and rate of change of the error, the adjustment amount needed to adjust the expected motion trajectory of the device's end effector (or directly the desired torque of the servo motor) to make the actual impedance return to the target impedance. This adjustment amount is encapsulated into a lightweight command containing minute displacement or torque increment information, which is the high-frequency fine-tuning command. For example, when the vertical contact stiffness is detected to be higher than expected (error exceeds the threshold), the PD controller may output a displacement increment command of "adjusting upward by 0.1 mm from the current planned position".

[0077] Step 7: The high-frequency fine-tuning command and the control command corresponding to the physical operation are superimposed and fused to obtain the real-time optimized control command. The control command corresponding to the physical operation refers to the original control command (from step 106) that is currently driving the device to perform the current physical operation. It contains the basic target position, velocity, or torque trajectory of the operation. Superposition and fusion refers to applying the minute adjustment represented by the high-frequency fine-tuning command to the reference trajectory or command defined by the original control command in real time, using addition or other integration methods, thereby generating a new control command that has been instantaneously corrected. In practice, the executing entity also holds the original control command corresponding to the current physical operation (or its decomposed current desired state, such as the desired position) while generating the high-frequency fine-tuning command. The fusion process is performed at the command level or the state level. For example, if the original command is a position command and the fine-tuning command is a position increment, the two are directly added to obtain a new, optimized target position command, i.e., the real-time optimized control command. This process needs to be completed quickly within one control cycle (e.g., 1 ms) to ensure real-time performance.

[0078] Step 8: Based on the aforementioned real-time optimized control instructions, update the execution parameters in the control information corresponding to the physical operation. The control information corresponding to the physical operation refers to the control information data structure related to the physical operation obtained in step 107. Execution parameters are a field in this data structure, storing the specific parameters used to define the operation. Updating means replacing or modifying the corresponding execution parameter values ​​in the control information with the new parameter values ​​(such as a new target position or a new force threshold) contained in the real-time optimized control instructions. In practice, the executing entity determines the specific parameters that need to be updated based on the type and content of the real-time optimized control instructions. For example, if the fine-tuning instruction is a position increment, then the parameters related to "target position" or "trajectory path point" in the control information are updated; if it is a force increment, then the "force control target value" parameter is updated. The updated control information reflects the latest, real-time optimized operational intent.

[0079] Step nine involves controlling the underlying servo driver of the target external actuator to continue performing the aforementioned physical operations based on the updated control information. The underlying servo driver refers to the core controller in the target external actuator that directly controls the motor's movement. "Continuing execution" means, without interrupting the current operation of the device, sending a new drive command generated based on the updated control information to the servo driver in real time. This allows the servo driver to adjust its output according to the new, optimized parameters, thereby changing the device's motion or force output and achieving online optimization of the interaction process. In practice, the actuator combines the updated control information (especially the updated execution parameters) with the operation type and target device identifier, and repackages it into a new drive command according to the requirements of the device drive protocol (such as EtherCAT or CANopen). This command is sent to the underlying servo driver of the target external actuator via a high-speed fieldbus or real-time network. After receiving and parsing the command, the driver immediately adjusts the setpoints in its control loop (such as the position loop setpoint and torque loop setpoint), causing a small but rapid change in the motion or output characteristics of the device's end effector. This reduces impedance errors and makes the physical interaction process closer to the expected safety, stability, or efficiency goals. For example, after updating the target position, the servo driver adjusts the motor current to slightly raise the scanning head, thereby reducing the contact force and adjusting the excessive interaction stiffness back to the desired range.

[0080] The dynamic physical interaction closed-loop control method for servo-level devices in this embodiment is an inventive point of this disclosure. It solves the technical problem that "on the basis of realizing a macro-closed loop from decision-making to execution, when performing dynamic physical interaction between precision orthodontic devices (such as force feedback scanners and surgical robots) and fragile biological tissues, existing solutions lack the ability to instantaneously perceive and adjust the real-time interaction force and motion state, leading to operational instability, decreased accuracy, and safety risks caused by individual differences, tissue deformation, or patient micro-movements." Existing technologies have the following shortcomings in dynamic adaptive control of physical interactions: First, the system is in an "open-loop blind control" state when executing pre-planned instructions, and cannot perceive the dynamic contact force and motion state between the device end and oral tissue in real time, resulting in a delayed response to abnormal changes during the interaction process (such as force over-limit and trajectory deviation). Second, there is a lack of a model that can map the real-time acquired multimodal physical signals (motion and force) into a quantifiable model to evaluate the dynamic characteristics of the interaction, making it difficult for the system to "understand" whether the current physical interaction is "compliant" or "rigid," "stable" or "unstable." Third, the control strategy relies entirely on preset fixed parameters and lacks the ability to make online, high-frequency fine adjustments based on the real-time interaction state, making it unable to adapt to uncertainties such as tissue deformation and physiological micro-movements of the patient during operation. Fourth, even if an adjustment intention is generated, there is a lack of a closed-loop path that seamlessly integrates it with the original control instructions and drives the underlying servo mechanism in real time, making adaptive adjustment impossible to implement. Solving the above problems would add a real-time "perception-understanding-decision-fine-tuning" intelligent reflex arc to high-precision orthodontic operations on a millisecond-level timescale, ensuring the macro-level tasks are executed as planned while guaranteeing the safety, compliance, and accuracy of the micro-level physical interaction process. To achieve this effect, this disclosure proposes: First, in response to any target external execution device starting to perform any physical operation, real-time acquisition of multimodal state monitoring data corresponding to the target external execution device. Thus, at the instant the servo-level device (such as an intraoral scanner or surgical robot) begins to contact the patient's tissue, a high-frequency, multimodal data acquisition network is simultaneously activated to acquire precise motion trajectory data and six-dimensional force / torque sensing data from the device's end effector, providing the system with a real-time "eye" to "observe" the physical interaction process, solving the problem of the system being "invisible" to the real physical world state during the execution phase, and establishing a data foundation for closed-loop control. Second, the above-mentioned multimodal state monitoring data undergoes time synchronization alignment processing to obtain a synchronized data stream. Therefore, based on their precise timestamps, the device motion trajectory data streams and force sensing data streams from different sensors with inherent acquisition and transmission delays are strictly aligned and interpolated in the time domain to generate a time-corresponding sequence of "motion-force" data pairs. This solves the fundamental problem that multi-source heterogeneous sensor data cannot be directly correlated and analyzed due to time differences, and provides a high-quality, time-bias-free data foundation for subsequent accurate feature extraction.The third step involves dynamic feature extraction processing of the aforementioned synchronized data stream to obtain a comprehensive feature vector. Thus, within a real-time sliding short-term analysis window (e.g., the most recent 100 milliseconds), a set of mathematical features (such as instantaneous kinematic features, contact mechanics features, and frequency domain energy features) that can comprehensively and compactly characterize the current dynamic interaction from the synchronized "motion-force" data are calculated in real time. This transforms the original spatiotemporal data stream into a unified, structured, and dynamically information-rich digital feature vector, solving the problem of how to extract key information from massive amounts of real-time data for the intelligent model to understand instantly. The fourth step involves inputting the aforementioned comprehensive feature vector into the dynamic physical interaction model to obtain the dynamic interaction impedance between the end effector of the external execution device and the operated object. Therefore, by utilizing a pre-trained machine learning model, the real-time dynamic features extracted in the previous step are mapped to the key physical characteristic parameter "dynamic interaction impedance" (such as stiffness and damping). This allows the system to "understand" the dynamic behavior of the device's end-effector contacting oral tissue, including its hardness and damping characteristics. This provides a quantifiable model-based indicator for evaluating the safety and stability of the interaction, solving the problem of the system's lack of deep understanding and quantitative description of complex physical interactions. The fifth step compares and evaluates the dynamic interaction impedance with the preset target interaction impedance to obtain the impedance error. Thus, by comparing the interaction impedance estimated in real-time by the model with the preset safe and efficient target impedance based on the current operation type (such as "exploration" or "cutting"), the deviation (impedance error) between the two is accurately calculated. This enables rapid and quantitative diagnosis of whether the current physical interaction state deviates from the expected target, providing a clear decision-making basis for triggering control actions. The sixth step, in response to the impedance error exceeding a preset stability threshold, generates a high-frequency fine-tuning command based on the impedance error. Therefore, when an abnormal interaction state is diagnosed (such as excessively hard contact or excessive jitter), the system immediately calculates the minute displacement or torque adjustment amount to correct the deviation based on principles such as impedance control, and encapsulates it into a high-frequency (e.g., hundreds of hertz) fine-tuning command. This enables the system to generate a targeted compensation strategy in a very short time, providing an "intelligent reflection" capability and solving the problem that fixed parameter control cannot respond to real-time dynamic changes. The seventh step involves superimposing and fusing the aforementioned high-frequency fine-tuning command with the control command corresponding to the aforementioned physical operation to obtain an instantaneously optimized control command. This allows for real-time fusion of the generated fine-tuning command with the original planned control command at the command or state layer, producing a new target command that has undergone instantaneous correction. This achieves seamless integration of the adjustment intention and the control baseline, ensuring that the fine-tuning action can be smoothly and coherently embedded into the predetermined execution flow, avoiding conflicts or abrupt changes between the control action and the main task. The eighth step involves updating the execution parameters in the control information corresponding to the aforementioned physical operation based on the aforementioned instantaneously optimized control command.Therefore, the new parameters (such as the updated target position and force threshold) contained in the fused optimized instructions are used to refresh the state representation inside the control system in real time, keeping the system's control intent synchronized with the latest and optimized execution target, thus preparing the data for the final drive device. In the ninth step, based on the updated control information, the underlying servo driver of the aforementioned target external execution device continues to execute the physical operations. Thus, the updated control information is sent to the underlying servo driver of the device via a high-speed real-time network (such as EtherCAT), and the drive motor immediately operates according to the adjusted parameters, causing a small but rapid change in the motion or output of the device's end effector. This compensates for impedance errors in real time, guiding the physical interaction process back to a safe, stable, and compliant ideal state, completing the final closed loop from perception to execution. In summary, the first to ninth steps of this embodiment are closely connected, constructing a millisecond-level dynamic physical interaction adaptive closed loop nested within the macroscopic task execution flow, from "real-time perception, temporal alignment, feature extraction, model-based understanding, quantitative evaluation, decision generation, instruction fusion, state update to servo drive." This endows the operation of high-precision and high-risk servo-grade orthodontic equipment (such as scanning and surgery) with real-time "tactile intelligence" and "reflex adjustment" capabilities, enabling it to actively adapt to individual anatomical differences, compensate for tissue deformation, and suppress unexpected disturbances. This fundamentally elevates the operation mode from rigid program control to safe, compliant, and precise dynamic interactive adaptation, enhancing the safety, success rate, and patient comfort of clinical operations. This represents a further deepening and manifestation of the core value of this disclosed technical solution in high-end clinical application scenarios.

[0081] The knowledge graph-based orthodontic data management method provided by the above embodiments of the present invention effectively overcomes the core defects of existing technologies in information integration, deep reasoning, and physical execution by constructing a fully intelligent "data-knowledge-decision-control" chain, achieving end-to-end automated processing from multi-source clinical data to executable device instructions. Specifically, it addresses the three major problems pointed out in the background technology: 1) weak logical reasoning ability of traditional RAG due to information fragmentation; 2) the contradiction between efficiency and accuracy in the construction of domain knowledge base; and 3) the disconnect between intelligent decision-making and physical device execution. This method provides a complete solution through the systematic design of the following steps: First, it acquires multimodal orthodontic data uploaded by users and performs structured feature extraction on the acquired data to obtain initial feature information. Thus, this method establishes an entry point for processing complex clinical data, enabling the normalization and preliminary structuring of multi-source heterogeneous information such as text and images, laying a unified and standardized data foundation for subsequent precise knowledge association, and solving the problem of messy and difficult-to-use raw data. Next, it performs entity mapping processing on the above initial feature information to obtain key feature information. Therefore, this method performs deep semantic alignment between the extracted original features and a pre-constructed orthodontic knowledge graph, transforming non-standard clinical descriptions into standardized entities and their attributes defined in the graph. This step injects rigorous domain knowledge, ensuring the accuracy of the system's core "cognition" and providing a key prerequisite for overcoming information fragmentation and achieving accurate reasoning. Then, based on the aforementioned key feature information and the pre-constructed orthodontic knowledge graph, enhanced information is generated. Thus, this method employs a hybrid retrieval mechanism, not only acquiring semantically relevant text fragments (vector retrieval), but more importantly, obtaining structured related information subgraphs along the relational paths of the knowledge graph (graph retrieval). This provides the system with a broad and deep context, containing logical chains such as "sign-intervention," which directly empowers the deep and interpretable reasoning of subsequent steps, fundamentally solving the problem of information silos in traditional RAGs. Subsequently, based on the aforementioned enhanced information and key feature information, a structured goal planning scheme is generated. Thus, based on high-quality knowledge enhancement, this method drives a large language model to perform logical deduction, producing a structured scheme that includes state classification, planning goals, and specific task sequences. This approach not only boasts text readability but also a clear, machine-readable structure, achieving a fundamental leap from data and knowledge to actionable planning, answering the questions of "what to do" and "how to do it." Next, based on the aforementioned structured goal planning scheme, a set of control instructions is generated. Thus, this method achieves the crucial transformation from abstract planning to concrete instructions. By mapping and encapsulating task sequences described in natural language into standardized control instructions (such as opcodes and parameters) that can be recognized by the device, high-level planning can be accurately and unambiguously interpreted, paving the way for execution in the physical world.Finally, based on the aforementioned set of control instructions, external execution devices are controlled. Thus, this method completes the final closed loop from the digital world to the physical world, directly driving hardware devices such as intraoral scanners and 3D printers to perform specific operations. This step directly overcomes the technical obstacle of the "closed loop from decision-making to execution" pointed out in the background technology, achieving true automated control. Furthermore, this method cleverly balances the contradiction between accuracy and efficiency in knowledge base construction through a knowledge graph construction paradigm of "expert-annotated seeds + automated expansion of large models." Each link in the entire process is interconnected, forming an integrated technical system with a high-quality knowledge graph at its core, hybrid retrieval as an enhancement method, structured generation as the output form, and instruction-driven execution as the execution end. In summary, this invention not only improves the depth and reliability of data processing and intelligent assistance in the field of orthodontics, but also provides a solid technical foundation for achieving precision, automation, and intelligence in clinical assistance processes by bridging the "last mile" to device control.

[0082] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a knowledge graph-based orthodontic data management device. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0083] like Figure 2 As shown, a knowledge graph-based orthodontic data management device 200 in some embodiments includes: an acquisition unit 201, an extraction unit 202, a mapping unit 203, a first generation unit 204, a second generation unit 205, a third generation unit 206, and a control unit 207. The acquisition unit 201 is configured to acquire multimodal orthodontic data uploaded by a user; the extraction unit 202 is configured to perform structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information; the mapping unit 203 is configured to perform entity mapping processing on the initial feature information to obtain key feature information; the first generation unit 204 is configured to generate enhancement information based on the key feature information and a pre-constructed orthodontic knowledge graph; the second generation unit 205 is configured to generate a structured target planning scheme based on the enhancement information and the key feature information; the third generation unit 206 is configured to generate a set of control instructions based on the structured target planning scheme; and the control unit 207 is configured to control external execution devices based on the set of control instructions.

[0084] It is understandable that the units described in the device 200 are related to the reference. Figure 1The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0085] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0086] like Figure 3 As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0087] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0088] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0089] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0090] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0091] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: acquire multimodal orthodontic data uploaded by the user; perform structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information; perform entity mapping processing on the initial feature information to obtain key feature information; generate enhancement information based on the key feature information and a pre-constructed orthodontic knowledge graph; generate a structured target planning scheme based on the enhancement information and the key feature information; generate a set of control instructions based on the structured target planning scheme; and control an external execution device based on the set of control instructions.

[0092] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0093] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0094] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including an acquisition unit, an extraction unit, a mapping unit, a first generation unit, a second generation unit, a third generation unit, and a control unit. The names of these units do not necessarily limit the unit itself; for example, the acquisition unit may also be described as "a unit that acquires multimodal orthodontic data uploaded by a user."

[0095] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0096] Some embodiments of this disclosure also provide a computer program product, including a computer program that, when executed by a processor, implements any of the above-described knowledge graph-based orthodontic data management methods.

[0097] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A knowledge graph-based method for managing orthodontic data, comprising: Acquire multimodal orthodontic data uploaded by users; Structured feature extraction was performed on the acquired multimodal orthodontic data to obtain initial feature information; The initial feature information is subjected to entity mapping processing to obtain key feature information; Based on the key feature information and the pre-constructed orthodontic knowledge graph, enhanced information is generated; Based on the enhanced information and the key feature information, a structured target planning scheme is generated; Based on the structured target planning scheme, a set of control instructions is generated; Based on the set of control commands, external execution devices are controlled.

2. The method according to claim 1, wherein, The process of extracting structured features from the acquired multimodal orthodontic data to obtain initial feature information includes: Natural language understanding processing is performed on the text data in the multimodal orthodontic data to obtain a text feature set, wherein the text feature set includes various text feature items; Image feature extraction processing is performed on the image data in the multimodal orthodontic data to obtain an image feature set, wherein the image feature set includes each image feature item; The text feature set and the image feature set are integrated to obtain initial feature information including each feature item.

3. The method according to claim 2, wherein, The entity mapping process performed on the initial feature information to obtain key feature information includes: For each feature item in the initial feature information, perform the following steps: The semantic similarity of the feature terms with each entity node in the pre-constructed orthodontic knowledge graph is evaluated to obtain the semantic similarity evaluation results. Based on the semantic similarity evaluation results, the corresponding standardized entity nodes in the pre-constructed orthodontic knowledge graph are matched for the feature terms; Obtain attribute information and higher-level concept information associated with the standardized entity nodes from the pre-constructed orthodontic knowledge graph; Based on the acquired attribute information and the higher-level concept information, the feature items are supplemented and standardized to obtain the target feature items; Based on the obtained target feature terms, key feature information is generated.

4. The method according to claim 3, wherein, The generation of enhanced information based on the key feature information and the pre-constructed orthodontic knowledge graph includes: For each target feature item included in the key feature information, perform the following steps: Using the standardized entity node corresponding to the target feature item as the query starting point, perform a multi-hop relationship query in the pre-constructed orthodontic knowledge graph; Obtain each associated entity node, each relation edge, and each description text that are connected to the query starting point through relation edges, and determine the obtained associated entity nodes, each relation edge, and each description text as the first search result; The target feature terms are subjected to natural language fusion processing to obtain a query vector; In the pre-constructed orthodontic knowledge graph, an approximate nearest neighbor search is performed on the query vector; Obtain text fragments that are semantically similar to the query vector, and determine the obtained text fragments as the second search results; The obtained first search results and second search results are merged and reordered to generate enhanced information.

5. The method according to claim 4, wherein, The step of generating a structured target planning scheme based on the enhanced information and the key feature information includes: The enhanced information is formatted to obtain formatted enhanced information; The formatted enhanced information and the key feature information are combined using natural language to obtain the input context; The input context is concatenated with a preset prompt template to obtain a complete prompt; The complete prompt is processed by intent parsing to obtain the core query intent and key clinical constraints; Based on the core query intent and the complete prompt, generate various related medical concepts and various relationship paths; Based on the aforementioned key clinical constraints, the relevant medical concepts and their relational paths are screened to obtain core knowledge evidence. Based on the core knowledge evidence and the key feature information, a reasoning chain is generated; The inference chain is professionally converted into text to obtain a structured preliminary text draft. The initial draft text was validated using terminology standardization to obtain the initial planning text; Extract the status classification field, planning target field, and phased task description field from the initial planning text; The extracted fields are mapped and organized according to a predefined structured architecture to obtain a structured target planning scheme. The structured target planning scheme includes state classification information, planning target information and task sequence information. The task sequence information includes operation description, execution object and expected parameter information for each task stage.

6. The method according to claim 5, wherein, The step of generating a set of control instructions based on the structured target planning scheme includes: For each task stage information in the task sequence information, perform the following steps: Based on the operation description, execution object and expected parameters corresponding to the task stage information, generate the task items to be executed corresponding to the task stage; Map the generated tasks to be executed to control opcodes; The execution object and expected parameters are encapsulated according to the data format corresponding to the control opcode to obtain the original control instruction corresponding to the task item to be executed; Based on the order of the task stage information in the task sequence information, the obtained original control instructions are sorted to obtain the original control instruction set. The original set of control commands is subjected to conflict detection and resolution to obtain a new set of control commands.

7. A knowledge graph-based orthodontic data management device, comprising: The acquisition unit is configured to acquire multimodal orthodontic data uploaded by the user; The extraction unit is configured to perform structured feature extraction on the acquired multimodal orthodontic data to obtain initial feature information; The mapping unit is configured to perform entity mapping processing on the initial feature information to obtain key feature information; The first generation unit is configured to generate enhanced information based on the key feature information and a pre-constructed orthodontic knowledge graph; The second generation unit is configured to generate a structured target planning scheme based on the enhanced information and the key feature information. The third generation unit is configured to generate a set of control instructions based on the structured target planning scheme; The control unit is configured to control an external execution device based on the set of control commands.

8. An electronic device, comprising: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 6.

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

Images