Generation of instructions for treatment planning

Abstract

A method includes obtaining treatment provider instructions associated with a target dental treatment. The instructions may be expressed in natural language. The method further includes providing first input including the instructions to an AI model. The method further includes obtaining output from the AI model including a first treatment protocol in association with the target dental treatment. The method further includes providing an alert to the treatment provider, the alert including the treatment protocol.

Description

Attorney Docket No.: 28510.998 (L0773PCT)GENERATION OF INSTRUCTIONS FOR TREATMENT PLANNINGTECHNICAL FIELD

[0001] Embodiments of the present invention relate to the field of dentistry, and in particular to the generation of treatment protocol instructions by utilizing artificial intelligence models.BACKGROUND

[0002] When a dentist or orthodontist is engaging with current and / or potential patients, it is often helpful to utilize treatment protocols to assist with treatment planning operations. A treatment protocol may include a set of operations, preferences, or other instructions that enable efficient development of a treatment plan for a particular patient or disorder. For example, in orthodontic treatment, a practitioner may have preferences for making certain adjustments to dentition before others, preferences for aggression of tooth movement, or preferences for treatment of one type of malocclusion before another. These treatment protocols help standardize care delivery while accommodating practitioner-specific clinical approaches.

[0003] In conventional systems, generation of a usable treatment protocol may require input by a technician trained to translate a practitioner's protocol notes into a standardized format, such as machine-readable code associated with a particular treatment planning software. Such systems may require significant investment in training and employing technicians to support partnered practitioners, as well as maintenance and management of facilities for the technicians. Further, there may be a loss of efficiency in protocol design related to delays between a practitioner requesting an update to a protocol or a new protocol, the technician receiving the practitioner's notes, and generation of the protocol in the updated format. Such delays may be further exacerbated in cases where additional updates to the protocol are requested by the practitioner, including multiple rounds of communication between the technician and practitioner to update or fine-tune one or more treatment protocols.

[0004] Similarly, when designing a specific treatment plan for a patient, a treatment provider may need to communicate case-specific instructions that differ from or supplement an existing protocol. In some systems, designing a treatment plan may include applying a pre-set protocol, determining that one or more portions of the protocol are incorrector need adjustment for a specific case, requesting a technician update the protocol or treatment plan, and waiting for the updates to be applied. This process may involve multiple steps, multiple rounds of communication, and significant waiting time, reducing the efficiency of treatment planning workflows and potentially delaying patient care. There is a need for improved systems and methods that can automatically translate practitioner instructionsAttorney Docket No.: 28510.998 (L0773PCT)expressed in natural language into machine-readable formats suitable for automated treatment planning operations.SUMMARY

[0005] The following is a simplified summary of the disclosure in order to provide a basic understanding of some aspects of the disclosure. This summary is notan extensive overview of the disclosure. It is intended to neither identify key or critical elements of the disclosure, nor delineate any scope of the particular embodiments of the disclosure or any scope of the claims. Its sole purpose is to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description that is presented later.

[0006] In one aspectof the present disclosure, a method includes obtaining treatment provider instructions associated with a target dental treatment. The instructions may be expressed in natural language. The method further includes providing first input including the instructions to an Al model. The method further includes obtaining output from the Al model including a first treatment protocol in association with the target dental treatment. The method further includes providing an alert to the treatment provider, the alert including the treatment protocol. The alert may be provided in written form, verbal form via audio output, sign language form via visual display, or combinations thereof.

[0007] In another aspect of the present disclosure, a method includes obtaining a plurality of treatment provider instructions associated with dental treatments. The method further includes obtaining a plurality of machine-readable instructions corresponding to the treatment provider instructions. The method further includes training a machine learning model to generate a trained machine learning model. T raining the model includes providing the plurality of treatment provider instructions as training input and the plurality of machine-readable instructions as target output.

[0008] In another aspectof the present disclosure, a method includes obtaining a data model including one or more fields to be filled. The fields may be associated with a dental treatment. The method further includes generating a first prompt in natural language associated with a first one or more of the fields. The method further includes presenting the first prompt. The first prompt may be presented via a GUI. The method further includes obtaining a response to the first prompt. The method further includes providing the response to a trained machine learning model. The method further i ncl udes filli ng the one or more fields using output of the trained machine learning model based on the response.

[0009] In another aspect of the present disclosure, a method includes providing a first set of options related to treatment preferences for a first dental conditions. The method further includes obtaining a first selection of one of the first set of options. The method further includes providing the first selection to a model configured to generate machine-readable code to generate a dental treatment planAttorney Docket No.: 28510.998 (L0773PCT)based on the first selection. The method further includes obtaining form the model the machine-readable code.[OO1O] In another aspect of the present disclosure, a method includes providing a first set of treatment options related to a first treatment goal in association with a first dental condition. The method further includes providing a second set of treatment options related to a second treatment goal in association with the first dental condition. The method further includes obtaining a first selection from the first set of treatment options and a second selection from the second set of treatment options. The method further includes generating a treatment protocol in a machine-readable format including the first selection and the second selection. The method further includes obtaining and indication that the first treatment goal is to be applied to a patient in association with the first dental condition. The method further includes generating a treatment plan for the patient corresponding to the first treatment goal based on the treatment protocol.

[0011] In another aspect of the present disclosure, a method includes providing, via a graphical user interface (GUI), a set of treatment categories in association with operations of a dental treatment. The method further includes providing, for each of the set of treatment categories, a corresponding set of treatment options. The method further includes obtaining, for a first of the set of treatment categories, a selection from the set of treatment options via the GUI. The method further includes providing the selection to a model configured to generate a treatment protocol in a machine-readable format. The method further includes displaying the treatment protocol via the GUI.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The present disclosure is illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings.

[0013] FIG. 1 is a block diagram illustrating an exemplary system architecture, according to some embodiments.

[0014] FIG. 2 illustrates a model training workflow and a model application workflow, according to some embodiments.

[0015] FIG. 3A is a diagram depicting a data flow for generation of a treatment plan using an artificial intelligence (Al) model, according to some embodiments.

[0016] FIG. 3B depicts a graphical user interface (GUI) for providing a user experience for a practitioner for generating a treatment protocol using an Al model, according to some embodiments.

[0017] FIG. 3C is a block diagram of a flow for obtaining practitioner instructions via a chat function, according to some embodiments.Attorney Docket No.: 28510.998 (L0773PCT)

[0018] FIG. 3D is a block diagram of a data flow for generating machine-readable instructions based on practitioner natural language instructions, according to some embodiments.

[0019] FIG. 3E is a block diagram of a data flow for utilizing a GUI-based system for converting practitioner preferences into machine-readable treatment protocols, according to some embodiments.

[0020] FIG. 3F depicts an example GUI for treatment protocol generation based on selections of a practitioner, according to some embodiments.

[0021] FIG. 3G depicts an example GUI for treatment protocol generation based on selections of a practitioner, according to some embodiments.

[0022] FIG. 3H depicts an example GUI including nested treatment categorization and selection of treatment goals, according to some embodiments.

[0023] FIG. 4A is a block diagram of a data flow for generating a treatment plan based on natural language instructions, according to some embodiments.

[0024] FIG. 4B is a diagram of a data flow for generating and implementing a machine-generated prompt for an LLM, according to some embodiments.

[0025] FIG. 40 is a diagram of a data flow for classifying instructions into categories for further processing, according to some embodiments.

[0026] FIG. 4D is an example treatment planning GUI, including an Al assistant, according to some embodiments.

[0027] FIG. 4E is an example process flow for using an Al assistant to update one or more stages of treatment planning, according to some embodiments.

[0028] FIG. 4F is an example treatment planning GUI including an Al assistant chat interface and dental arch diagram, according to some embodiments.

[0029] FIG. 5A is a flow diagram of a method for generating a dataset for a machine learning model, according to some embodiments.

[0030] FIG. 5B is a flow diagram of a method for generating treatment protocol data based on natural language input, according to some embodiments.

[0031] FIG. 50 is a flow diagram of a method fortraining a machine learning or Al model for performing operations associated with generating machine-readable treatment protocol instructions, according to some embodiments.

[0032] FIG. 5D is a flow diagram of a method for filling fields of a data model associated with dental treatment, according to some embodiments.

[0033] FIG. 5E is a flow diagram of a method for generating machine-readable instructions related to dental treatment based on a selection of options, according to some embodiments.Attorney Docket No.: 28510.998 (L0773PCT)

[0034] FIG. 5F is a flow diagram of a method for generating a treatment protocol, and using the treatment protocol to generate a treatment plan in accordance with one or more treatment goals, according to some embodiments.

[0035] FIG. 5G is a flow diagram of a method for using a GUI to generate a treatment protocol based on a set of provided options, according to some embodiments.

[0036] FIG. 6A is a flow diagram of a method for adjusting a treatment planning algorithm based on natural language instructions, according to some embodiments.

[0037] FIG. 6B is a flow diagram of a method for updating a treatment planning algorithm, according to some embodiments.

[0038] FIG. 6C is a flow diagram of a method for updating a set of machine-readable instructions based on natural language input, according to some embodiments.

[0039] FIG. 6D is a flow diagram of a method for generating machine-readable instructions from natural language instructions, according to some embodiments.

[0040] FIG. 6E is a flow diagram of a method for indexing ordered objects in a machine-readable format, based on natural language input, according to some embodiments.

[0041] FIG. 6F is a flow diagram of a method for adjusting a treatment planning algorithm, according to some embodiments.

[0042] FIG. 6G is a flow diagram of a method for translating natural language indexing to machine-readable indexing for updating a treatment planning algorithm, according to some embodiments.

[0043] FIG. 7A is a flow diagram of a method for producing a machine- or model-generated prompt for an LLM, according to some embodiments.

[0044] FIG. 7B is a flow diagram of a method for producing a model-generated prompt, according to some embodiments.

[0045] FIG. 70 is a flow diagram of a method for generating machine-readable instructions from a target category of natural language instructions, according to some embodiments.

[0046] FIG. 7D is a flow diagram of a method for obtaining machine-readable instructions corresponding to a target category of natural language instructions in relation to a dental treatment, according to some embodiments.

[0047] FIG. 7E is a flow diagram of a method for updating a treatment plan based on a target category of natural language instructions, according to some embodiments.

[0048] FIG. 8A is a flow diagram of a method for updating a treatment plan or protocol utilizing an Al assistant, according to some embodiments.Attorney Docket No.: 28510.998 (L0773PCT)

[0049] FIG. 8B is a flow diagram of a method for performing dental treatment planning utilizing an LLM, according to some embodiments.

[0050] FIG. 8C is a flow diagram of a method for using an LLM via a GUI element to perform treatment planning, according to some embodiments.

[0051] FIG. 9A illustrates a tooth repositioning system including a plurality of appliances, in accordance with some embodiments.

[0052] FIG. 9B illustrates a method of orthodontic treatment using a plurality of appliances, in accordance with some embodiments.

[0053] FIG. 10 illustrates a method for designing an orthodontic appliance to be produced by direct fabrication, in accordance with some embodiments.

[0054] FIG. 11 illustrates a method for digitally planning an orthodontic treatment and / or design or fabrication of an appliance, in accordance with some embodiments.

[0055] FIG. 12 is a block diagram illustrating a system for dental treatment planning and intraoral scanning, according to some embodiments.

[0056] FIG. 13 is a block diagram illustrating a computer system, according to some embodiments.DETAILED DESCRIPTION

[0057] The present disclosure relates generally to systems and methods for generating treatment instructions, treatment plans, and treatment protocols in healthcare environments and, more particularly, to the use of artificial intelligence models including large language models for translating natural language instructions from treatment providers into machine-readable treatment protocols and treatment plans. While the present disclosure provides detailed examples in the context of dental and orthodontic applications, the systems and methods described herein may be applicable to other healthcare domains including, but not limited to, orthopedics, physical therapy, surgical planning, prosthetics, rehabilitation medicine, dermatology, ophthalmology, cardiology, oncology, and other medical fields where treatment protocols and treatment plans are generated based on practitioner instructions.

[0058] In various embodiments, the systems and methods described herein may receive treatment provider instructions expressed in natural language, process those instructions using one or more trained Al models, and generate machine-readable instructions suitable for automated treatment planning operations. The treatment provider instructions may relate to general treatment preferences applicable across multiple patients, or may relate to specific instructions for a particular patient case. Graphical user interfaces may also be utilized to present treatment options to practitioners, withAttorney Docket No.: 28510.998 (L0773PCT)selections being converted to machine-readable treatment protocols through deterministic or rule-based mappings.

[0059] The systems and methods disclosed herein may address limitations of conventional approaches that rely on trained technicians to manually translate practitioner instructions into machine-readable formats. By utilizing Al models such as large language models to perform translation operations, the disclosed techniques may reduce turnaround time for treatment protocol generation and updates, reduce reliance on specialized personnel, and enable practitioners to generate or modify treatment protocols without requiring specialized training in machine-readable instruction formats.

[0060] Technologies described herein are related to improving processes of healthcare services by inclusion and utilization of modeling techniques, including machine learning models, artificial intelligence (Al) models, natural language processing (NLP) models, large language models (LLMs), etc. In some healthcare environments, treatment may be planned, augmented, monitored, or the like by computing devices, and various portions of treatment may include generating machine-readable code or instructions for performing these tasks. Al models (e.g., LLMs) may be used to assist in treatment planning, treatment protocol generation, or the like, for various health care services including dental (e.g., orthodontic) health care, orthopedic health care, physical therapy, surgical planning, prosthetics design, rehabilitation medicine, and other medical specialties. Al models may be utilized in translating input from a treatment provider (e.g., a doctor who is not trained in producing machine-readable treatment instructions, three-dimensional modeling related to heath care treatments, or the like) in natural language to a more usable or useful form or format. Graphical user interface (GUI) input may also be used in generating treatment protocols or treatment plans. Treatment options may be provided to a healthcare provider via a GUI, and the provider may generate machine-readable treatment instructions based on their selections of the treatment options.

[0061] For many operations described in this disclosure, it may be convenient to utilize one or more large language models. However, different language models, including NLPs, small language models, or specialized language models may be utilized in place of one or more LLMs described in operations herein. For example, an operation described as including multiple LLMs may include one large language model, one natural processing model, one small language model, and one specialized language model specifically tuned for a target use case (such as a dental treatment case) and still be within the scope of this disclosure. Language processing models can vary greatly in scope, power, usage requirements, training requirements, etc., and a different combination of model properties may be utilized to target various tasks of interest with respect to healthcare treatment planning, dental treatments, orthodontic treatments, etc. For convenience, this class of language models are all typically referred to as “large language models” herein, unless otherwise specified. In particular, the mostAttorney Docket No.: 28510.998 (L0773PCT)generally powerful large language models are often trained on any and all publicly available data, and include many tunable parameters (e.g., on the order of tens of billions to trillions of tunable parameters). Small language models are often more focused, including fewer tunable parameters (e.g., millions or billions of parameters) and may be trained using a subset of publicly available data, such as data from verified sources or data associated with a target field of interest. Specialized language models may be trained using domain specific data, including private data, and may be or include adjustments to general small language models. Utilizing various iterations of these types of language models in any of the language processing operations described herein may be contemplated, and will be recognized to be within the scope of this disclosure.

[0062] A treatment provider may generate one or more protocols for treating health care disorders of interest. For example, a number of common disorders or disorders the practitioner commonly encounters may be candidates for generation of treatment protocols. For example, in the case of orthodontics, a practitioner may have a preference for making some adjustments of dentition before others, preference for aggression of movement, preference for treatment of one type of disorder before another, or the like. Similarly, in orthopedic applications, a practitioner may have preferences for surgical approaches, implant selection, rehabilitation timelines, weight-bearing protocols, or sequencing of treatment phases for conditions such as joint replacement, fracture fixation, ligament reconstruction, or spinal procedures.

[0063] In some systems, generation of a usable protocol may include input by a technician trained to translate a practitioner’s protocol notes to a standardized format, such as machine-readable code (e.g., proprietary code, code associated with a particular treatment planning software, or the like). Such systems may require investment in training and paying a number of technicians to support partnered practitioners, maintenance and management of facilities for the technicians, etc. Further, there may be a loss of efficiency in protocol design related to delays between a practitioner requesting an update to a protocol or a new protocol be developed, the technician receiving the practitioner’s notes, and generation of the protocol in the updated format. Such delays may be further exacerbated in cases where additional updates to the protocol are requested by the doctor, e.g., including multiple rounds of communication between the technician and practitioner to update or fine-tune the one or more treatment protocols. Embodiments provide systems and methods to automatically generate a treatment protocol, such as for dental treatment (e.g., orthodontic treatment and / or palatal expansion treatment), that may obviate the need for a trained technician to generate a treatment protocol.

[0064] Dental arch data may be utilized in treatment of a dental arch. For example, one or more dental malocclusions (e.g., misalignment of teeth) may be treated using an orthodontic treatment plan, which may include collecting and utilizing jaw pair data of a patient. As a further example, generation ofAttorney Docket No.: 28510.998 (L0773PCT)a crown or dental implant may be performed based on dental arch data. Dental arch data may include data of one or more teeth (e.g., including size, shape, positioning, orientation, etc.), a group of teeth, an arch, an upper and lower jaw, etc.

[0065] A treatment provider, based on examination of a health care disorder (e.g., malocclusion) and / or data collected in connection with the health care disorder (e.g., dental arch data), may design a specific treatment plan with respect to the patient exhibiting the health care disorder. The treatment plan may be related to an existing protocol, be based on an existing protocol, include one or more adjustments from an existing protocol, or be generated from scratch (e.g., without reliance on a treatment protocol). In some systems, designing of a treatment plan may include applying a pre-set protocol; determining that one or more portions of the protocol are incorrect, not applied correctly to the specific case, or are to be adjusted with respect to a specific case; requesting a technician update the protocol; and waiting for the updates to be applied. Similar to initial generation of a protocol, such a process may take multiple steps, multiple rounds of communication, a significant amount of waiting time, etc. Embodiments provide systems and methods to automatically generate a treatment plan, such as for dental treatment (e.g., orthodontic treatment and / or palatal expansion treatment), that may obviate the need for a trained technician to generate a treatment treatment plan.

[0066] Methods and systems of the current disclosure may address one or more shortcomings of conventional solutions. Various tools, systems, and methods are described for streamlining generation of treatment instructions, in particular generation ofmachine-readable code for enacting treatment. In some embodiments, selectable options presented via a GUI may be used for generation of treatment protocols and / or treatment plans. In some embodiments, an Al model (e.g., such as a language model including large language models, (LLMs) small language models, specialized language models, neural network, etc.) is utilized for generation of one or more treatment protocols. The Al model may further be utilized for validation and / or checking of the treatment protocols. Al models may further be utilized for updating of one or more treatment protocols. The treatment protocols may be related to a variety of healthcare services, including dental, orthodontic, orthopedic, physical therapy, surgical, prosthetic, rehabilitation, or other services for which creation of a treatment protocol may be of interest. In orthopedic contexts, for example, treatment protocols may specify surgical techniques, implant specifications, post-operative care instructions, physical therapy regimens, and recovery milestones for conditions such as hip or knee replacement, rotator cuff repair, ACL reconstruction, spinal fusion, or fracture management.

[0067] A treatment protocol may be generated through the use of a GUI. In some embodiments, a GUI may be used to provide some options for a treatment protocol to a provider (e.g., such as a doctor). The provider may select between the options (e.g., via drop-down menus, tillable fields, checkAttorney Docket No.: 28510.998 (L0773PCT)boxes, radio buttons, or the like) to generate a treatment protocol or treatment plan based on the provider’s preferences. Once the treatment provider’s preferences are recorded, a script (e.g., machine-readable code for executing the treatment protocol) may be generated based on the selected options. The machine-readable instructions may be applied to current or future treatment planning operations of the treatment provider.

[0068] In some embodiments, a treatment protocol (e.g., a protocol related to a target type of disorder, target treatment type, or the like) may be generated. Generation of the treatment protocol may be performed or assisted by one or more trained Al models. In some embodiments, a treatment provider (e.g., orthodontic practitioner) may provide input in natural language related to treatment protocol for one or more target disorders. The input may be provided by the practitioner via a chat function, a text input, a message (e.g., email), or another input. The input may be provided by the practitioner in natural language. Accordingly, the practitioner may not be required to undergo special training related to treatment protocol generation in order to generate a treatment protocol in embodiments.

[0069] In some embodiments, a number of common treatment preferences, common treatment goals, common treatment targets, or the like may be included in options provided via a GUI for generation of treatment protocols. Treatment operations may include more variation than is included in a form outlined by the GUI. For example, healthcare patients may experience disparate, even unique challenges, which may not be captured in a provided form. In some cases, an Al model may be used in situations where relevant options for treatment are not included or have not yet been included in a formdriven treatment protocol application executed via a GUI. In some cases, machine-readable instructions related to treatment planning (which may include proprietary syntax, mechanics, functions, or the like) may be capable of expressing a larger range of treatments than is feasible, cost-effective, or convenient to express via a set of selectable options presented by a GUI. In such cases, LLM- or other Al-based instruction generation may augment the rule-based instruction generation provided by the GUI.

[0070] A set of treatment categories may be provided to a practitioner. The set of treatment categories may include general treatment principles relevant to many different treatments (e.g., placing attachments or performing interproximal reduction for orthodontic treatments). The set of treatment categories may include specific conditions for treatment. The set of treatment categories may include options related to treatment appliances.

[0071] Under each treatment category, one or more options may be provided for selection by the treatment provider. In some cases, a branching tree of options may be provided, where selections of preferences lead to additional questions or options being presented, which may lead to furtherAttorney Docket No.: 28510.998 (L0773PCT)selections, etc. The options may include different classifications of a treatment category, different treatment goals, different methods of achieving treatment goals, etc.

[0072] In some embodiments, upon filling out a treatment provider’s preferences (or utilizing one or more default selections), machine-readable instructions representing a treatment protocol may be generated. Generation of the machine-readable instructions may be deterministic. For example, rulebased generation may be performed in view of the preference selections made via the GUI. The machine-readable protocol may then be applied to any future patient evaluations to generate or update a treatment plan.

[0073] In some embodiments, such as in the case of utilizing an Al-based architecture for language processing to generate treatment instructions, natural language input may be provided to one or more Al models. In some embodiments, one or more Al models may be used repeatedly. In an example, output from an Al model may be provided as input to another Al model, which may be configured to perform a different operation than the first Al model. In some embodiments, a single Al model (e.g., a general purpose LLM) may be utilized multiple times, with different inputs, combinations of doctor comments and engineered prompt components, etc., for generation of one or more treatment protocols and / or treatment plans.

[0074] In some embodiments, an Al model may be provided doctor or practitioner instructions, which may be accompanied by additional prompt body information. The Al model may be provided with instructions related to protocol generation, protocol editing, treatment planning instructions, additions or changes to a treatment protocol to be used to amend a specific treatment case, or the like. In some embodiments, doctor instructions may be provided to an Al model to perform splitting operations. Splitting operations may split doctor instructions into logical segments. For example, a doctor protocol statement may include a summary of general treatment protocol guidelines for many different disorders, and splitting operations may include separating the instructions into sections each associated with one disorder. In some embodiments, for splitting or other AI / LLM operations, prompt engineering input may be provided in addition to substantive input. For example, a prompt including related instructions, such as “separate the following text into logical sections each related to one dental disorder:” may be provided, with doctor protocol notes appended to it, to perform splitting operations. Any Al model operations may include similar prompt engineering, appended or joined with doctor comments, output of another model, or the like.

[0075] In some embodiments, input corresponding to doctor protocol instructions may be provided to an Al model for text formatting. Text formatting instructions may be provided along with a prompt statement, such as instructing an LLM to perform target formatting operations. Text formatting may receive sections splitting via splitting operations. Text formatting may include resolving relevantAttorney Docket No.: 28510.998 (L0773PCT)abbreviations, unifying medical terminology, indexing, labeling, or the like (such as tooth numbering), unifying text formatting, etc.

[0076] In some embodiments, input related to doctor protocol instructions may be provided to an Al model for performing title detection. For example, sections split up by an Al model may be provided for title detection operations, which may aid in later operations by identifying key concepts, disorders, treatment categories, or the like associated with a section of doctor instructions. Title detection may assist in assigning disorders or protocol types to sections of doctor input.

[0077] In some embodiments, input related to doctor protocol instructions may be provided to one or more transformers. The one or more transformers may generate machine-readable instructions (e.g., coding language statements) related to the doctor protocol instructions. In some embodiments, one statement of the doctor may be translated to one machine-readable instruction, multiple machine-readable instructions, or zero machine-readable instructions, multiple doctor statements may be condensed to a single machine-readable instruction, or the like. The machine-readable instructions may be in a specifically designed or proprietary language, e.g., related to a software used for treatment planning. In some embodiments, different transformers may be configured to provide different interpretations or services. For example, in the case of clear orthodontic aligners, one transformer may be configured to generate code related to appliance attachments, one transformer configured to generate instructions related to final tooth positions, and so on. In some embodiments, the different transformers may be the same Al model (e.g., general purpose LLM), provided with different prompt amendments to adjust operations and / or output of the Al model.

[0078] In some embodiments, input related to doctor protocol instructions (e.g., portions of doctor instructions that were not transformed into machine-readable instructions, or left over doctor instructions) may be provided to a default detector Al model. The default detector may determine whether one or more statements are not of clinical interest, not related to a treatment protocol, already included in treatment statements that have been transformed, or the like. For example, routine steps of a treatment may be included in a protocol without specific instructions, and related statements may be removed from consideration by default detection.

[0079] In some embodiments, input related to doctor protocol instructions (e.g., the set of machine-readable instructions produced by the one or more transformers) may be provided to an Al model for clinical checking. Clinical checking Al models may be provided with natural language input (e.g., doctor input, a section or portion of doctor input, or the like) and corresponding machine-readable instructions, and instructed to predict whether the instructions match the natural language input. Clinical checking may include one or more safety checks, e.g., to determine whether the protocol is inAttorney Docket No.: 28510.998 (L0773PCT)accordance with one or more clinical threshold conditions associated with a treatment. Further checks may also be performed, such as syntax checks (e.g., correcting syntax for compatal abi I ity or the like).

[0080] In some embodiments, multiple Al models may be utilized to assess the quality of generated treatment protocols, treatment plans, or machine-readable instructions. Each of the multiple LLMs may be configured to assume a different evaluator role, enabling assessment of the generated protocol from multiple perspectives. The evaluator roles may include, but are not limited to, a clinical advisor role, a marketing specialist role, a software quality assurance (SQA) engineer role, a regulatory compliance reviewer role, a patient safety analyst role, a usability specialist role, or other roles relevant to evaluating treatment protocols. Each role-specific LLM may be configured through specialized prompts that define the evaluation criteria, priorities, and perspective associated with that role.Alternatively or additionally, role-specific LLMs may be configured through fine-tuning on role-specific evaluation data, or by providing role-specific documentation and evaluation criteria via retrieval-augmented generation.

[0081] In some embodiments, an LLM configured for a clinical advisor role may evaluate the generated protocol for clinical soundness, adherence to best practices, appropriateness of treatment parameters, and alignment with established clinical guidelines. An LLM configured for a marketing specialist role may evaluate the protocol for clarity of communication, patient-friendliness of explanations, and effectiveness of presenting treatment options to patients. An LLM configured for an SQA engineer role may evaluate the protocol for technical correctness, proper handling of edge cases, consistency of machine-readable instructions, and absence of logical errors or contradictions. An LLM configured for a regulatory compliance reviewer role may evaluate the protocol for compliance with applicable regulatory standards, documentation requirements, and safety regulations. An LLM configured for a patient safety analyst role may evaluate the protocol for potential safety concerns, risk factors, and adherence to safety thresholds.

[0082] In some embodiments, the quality assessment using multiple role-specific LLMs may be performed iteratively. Feedback from each of the multiple role-specific LLMs may be aggregated to generate an overall quality score for the generated protocol. The aggregated feedback may identify specific areas of the protocol that may benefit from improvement or revision. In some cases, the feedback from the multiple role-specific LLMs may be provided to a coordinating LLM or aggregation module that synthesizes the individual assessments into a unified quality report. The unified quality report may be provided to a treatment provider for review, or may be used to automatically trigger refinement of the generated protocol. In some embodiments, the quality assessment process may continue iteratively until the generated protocol meets quality thresholds associated with each of the evaluator roles, or until a maximum number of iterations is reached.Attorney Docket No.: 28510.998 (L0773PCT)

[0083] In some embodiments, the doctor instructions may be provided based on a statement directed toward one or more treatment protocols provided by the treatment provider. In some embodiments, doctor instructions may be provided via an interactive model. For example, a chat arrangement facilitated by a graphical user interface (GUI) may be utilized in extracting information in natural language from the treatment provider in order to generate one or more treatment protocols. In some embodiments, a data model may include multiple fields to be filled in relation to one or more treatment protocols, and an Al model may be configured to ask natural language questions in a chat setting in order to fill the fields to generate a treatment protocol. In some embodiments, a verification check may be performed to confirm that the machine-readable instructions accurately reflect the intent of the practitioner's natural language input. The Al model may generate machine-readable instructions based on one or more chat responses. A response generator model (which may be Al-based, deterministic, or the like) may then generate a natural language description of the machine-readable instructions for confirmation by the practitioner via the chat. The natural language description may be presented in written form, verbal form via audio or speech synthesis, sign language form via animated visual display, or combinations thereof.

[0084] In some embodiments, a machine-readable protocol may be generated. The machine-readable protocol may be applied to a specific patient case (e.g., applied to a three-dimensional scan of patient dentition) to generate a treatment plan, which may also include machine-readable instructions. The treatment plan may include indications of final tooth positions, stages of movement, etc. In some embodiments, the machine-readable protocol may be used to generate a treatment algorithm, which may then be applied to patient data to generate a treatment plan. For example, a first machine-readable language may be used to translate natural language instructions to machine-readable instructions, and may be presented in a machine-readable language that somewhat resembles natural language for ease of generation, ease of review, etc. The protocol expressed in the first machine-readable language may then be used to generate a treatment algorithm, which may be used to generate treatment plans. The treatment algorithm may be in a less intuitive language for human understanding, but more easily applied to the task of generating treatment plans based on patient data.

[0085] In some embodiments, doctor instructions related to a specific treatment, specific patient, specific treatment plan, or the like may be provided in natural language to a system. The natural language instructions may be used to augment or supersede treatment operations defined in a treatment protocol. In some embodiments, for a particular dental patient, specific operations may be performed that are different than those expressed in a default treatment plan, default treatment protocol, protocol associated with the treatment provider, or the like. For example, a dental patient may include teeth, implants, pontics, or the like, that are not to be moved during treatment. This may beAttorney Docket No.: 28510.998 (L0773PCT)contrary to a protocol of the treatment provider, but important for proper treatment of this particular patient. Instructions related to treating this patient, including identity of teeth that are notto be moved, may be provided to a treatment planning system.

[0086] In some embodiments, updates to a treatment protocol may be provided in natural language. The updates, with some additional prompt language, may be provided to an LLM. The LLM may be configured (e.g., via prompt engineering) to output a machine-readable code related to updates to be made to a treatment protocol, treatment algorithm, treatment plan, or the like.

[0087] In some embodiments, machine-readable instructions generated from natural language treatment provider instructions may be organized according to a structured format that categorizes orthodontic instructions into distinct categories, each representing a specific aspect of treatment planning. The structured format may support various methods of teeth representation, accommodating different numbering systems and descriptive approaches used by orthodontists. A standardized schema, such as a JSON schema, may define the structure, allowed values, and relationships between different elements of the format. For instructions that do not fit into predefined categories, the structured format may include a default or "other instructions" category, ensuring that no information from the treatment provider instructions is lost during conversion. The structure of the machine-readable format may be extensible, allowing for the addition of new categories or instruction types as orthodontic practices evolve or as new treatment modalities are introduced.

[0088] In some embodiments, the system may distinguish between general treatment preferences and case-specific instructions. General treatment preferences may be applicable to all cases submitted by a treatment provider and may include conditional statements, such as "for cases with missing teeth, perform a specific treatment operation." Case-specific instructions may be more specific, identifying particular teeth, jaws, or patient-specific details that relate to a particular patient rather than general conditions. The system may handle both types of instructions through different processing pipelines that converge at treatment plan generation. In some cases, case-specific instructions provided in natural language may have higher priority than general preferences when both apply to the same treatment parameter, such that the case-specific instructions override or supplement the general preferences for a particular patient.

[0089] In some embodiments, the system may interpret treatment provider instructions contextually, understanding implied meanings based on the surrounding context of the instructions. Ambiguities in the natural language instructions may be resolved based on orthodontic best practices or clinical guidelines. The system may infer missing information based on context or may default to standard treatment approaches when specific details are not provided by the treatment provider. ForAttorney Docket No.: 28510.998 (L0773PCT)example, if a treatment provider specifies a treatment goal without specifying particular teeth, the system may inferthe relevant teeth based on the treatment goal and clinical conventions.

[0090] In some embodiments, a complete automated treatment building workflow may be performed without human intervention for supported instruction types. In such a workflow, an LLM may receive treatment provider instructions and a specially developed prompt, and may return the instructions converted to a machine-readable format. The LLM output may be checked for correctness and compatibility with the treatment planning engine. Upon successful validation, the treatment planning engine may receive the converted instructions along with patient data, such as a three-dimensional model of patient dentition, and may return a treatment plan. This workflow may enable fully automated treatment generation without participation of a CAD designer or treatment planning technician for cases where all instructions are supported and pass validation checks. For cases where instructions are not supported or validation fails, the workflow may fall back to manual treatment planning processes.

[0091] In some embodiments, the machine-readable updates to the treatment may be provided for validation operations. Validation operations may be Al-based, may be deterministic, or the like. Treatment validation may include verifying that all commands and syntax included in the LLM output (e.g., generated treatment protocol, treatment plan, etc. expressed in machine-readable format) include allowed functions or forms, etc. Validated machine-readable treatment updates may be provided to an engine for updating a treatment algorithm. For example, machine-readable treatment updates may be added to a treatment algorithm (which may be based on a treatment protocol), may be used to replace portions of a treatment algorithm, may fill spaces in a treatment algorithm intended to have a higher priority than other portions of the algorithm (e.g., specific instructions for a case being given higher priority than general instructions aligning to doctor preferences), or the like.

[0092] In some embodiments, validation of machine-readable instructions may include checking that instruction types are supported by the treatment planning engine. Validation may also include checking that parameter values fall within acceptable ranges. For example, when a treatment provider requests a specific number of passive aligners, the system may validate that the requested number falls within protocol limits. If instructions include unsupported instruction types or parameter values outside acceptable ranges, this may indicate conversion errors or instructions that cannot be automatically processed. In such cases, the instructions may be directed to a manual treatment planning process for review by trained personnel. Validation rules may be predefined and may be updated as the treatment planning engine capabilities evolve.

[0093] In some embodiments, failure of one or more portions of a procedure designed to use Al models such as LLMs to create or update treatment protocols, treatment algorithms, or treatment plansAttorney Docket No.: 28510.998 (L0773PCT)may cause the operations to be performed in a manual treatment planning process. The manual treatment planning process may include providing the natural language instructions of the doctor to a technician trained to adjust machine-readable language (e.g., protocol generation language, treatment algorithm language, etc.) based on the natural language instructions.

[0094] In some embodiments, an Al model (e.g., an LLM) may be instructed to translate natural language instructions ofa practitioner related to specific teeth into a machine-readable tooth indexing scheme. A prompt provided to an LLM for generating machine-readable instructions from natural language instructions may include instructions for generating, updating, and / or indexing teeth. In some cases, multiple tooth-indexing schemes (e.g., real-world schemes such as Universal Numbering System (UNS), Palmer, and Federation dentaire internationale (FID)) may be supported by an LLM.

[0095] A prompt provided to an LLM may include instructions for translating various methods for indexing objects (e.g., teeth) into a machine-readable format. For example, the prompt may include descriptions of several popular indexing schemes, may include a target output indexing description, may include descriptions of what teeth belong to various categories (e.g., anteriors, upper left molars, etc.), and / or other examples or instructions for assisting the LLM in correctly identifying teeth from a natural language input.

[0096] In some embodiments, validation of instructions may include validating of indexing schemes. In some embodiments, indexing schemes may be applied to patient data to correctly execute doctor instructions. For example, in cases with teeth in unexpected places or orders (e.g., where the patient has missing teeth or extra teeth, large misalignments, etc.), a “true” indexing of the character of teeth may be mismatched from a geometric indexing related to tooth positions. In such cases, instructions including relative positions of teeth or other indexable objects, such as “all teeth between 7 and 10,” or “teeth anterior” to a target tooth, may be misunderstood in an structural indexing. Geometric indexing may be applied to a model of a patient's teeth to match natural language doctor instructions to treatment planning algorithmic instructions.

[0097] In some embodiments, natural language instructions from treatment providers may reference teeth in a variety of ways, and the system may be configured to interpret and convert these varied references into a standardized machine-readable format. Teeth may be referenced individually using various numbering systems, such as "UR1 ", "#8", or "1.1 ", or as multiple individual teeth, such as "UR1 and UR2". Teeth may be referenced as anatomical groups, such as "upper left molars" or "anteriors". Teeth may be referenced as inclusive intervals, such as "between 7 and 10", indicating a range of teeth along the dental arch. Teeth may be referenced by relative position, such as "mesial of UR3" or "distal to the canine", indicating a tooth's position relative to another tooth. Teeth may also be referenced by exclusion from a group, such as "all anteriors except centrals", indicating a set of teethAttorney Docket No.: 28510.998 (L0773PCT)defined by removing specific teeth from a larger anatomical group. The system may be configured to recognize and convert each of these reference types into a structured machine-readable format suitable for automated treatment planning operations.

[0098] In some embodiments, a JSON schema or similar structured data format may be used to represent teeth references in a machine-readable format. The schema may include several components that enable comprehensive representation of teeth references. Individual teeth may be defined as a union of supported numbering systems, such as Palmer notation, Universal Numbering System, and FDI notation, allowing a single tooth to be represented using any of these systems. Tooth groups may represent anatomical groups, such as molars, premolars, canines, incisors, or anteriors, optionally filtered by jaw (upper or lower) and side (left or right). Tooth intervals may define an inclusive range between two teeth, with a begin identifier and an end identifier specifying the boundaries of the interval. Relative positions may specify a tooth relative to another tooth, with a reference tooth identifier and a direction indicator such as mesial or distal. Exclusion logic may represent a group of teeth with specific exclusions, using nested references that include a base set of teeth and an exclude set of teeth to be removed from the base set. This structured representation enables expressive and composable definitions of tooth groups that can be validated programmatically and processed consistently by treatment planning systems.

[0099] In some embodiments, to reduce ambiguity in interpreting tooth references, the treatment provider's preferred numbering system may be explicitly included as input to the natural language processing system. This may be particularly important in regions where FDI notation is standard and clinicians often omit dots in tooth numbers. For example, the instruction "more extrusion on 11" may refer to tooth 1.1 in FDI notation, but may refer to a different tooth in Universal Numbering System notation. By capturing the treatment provider's preferred numbering system, the system may ensure correct interpretation of tooth references and accurate mapping to the patient's digital jaw model. The preferred numbering system may be obtained from treatment provider preferences, from a geographic location associated with the treatment provider, from explicit input provided along with the natural language instructions, or from other sources. The preferred numbering system information may be provided to the Al model along with the natural language instructions to guide the conversion process.

[0100] In some embodiments, an algorithm for mapping teeth representations to a digital three-dimensional model of patient dentition may include a preprocessing step in which teeth in the digital model are sorted based on their geometric position along the jaw arch. This sorting may ensure consistent ordering even in the presence of irregularities such as unerupted teeth, supernumerary teeth, or pontic teeth. The sorting order may be defined such that teeth in the upper jaw are sorted from right to left along the arch, and teeth in the lower jaw are sorted from left to right along the arch. ThisAttorney Docket No.: 28510.998 (L0773PCT)sorted array of teeth may be cached and reused across multiple instructions within the same orthodontic case to optimize performance. The geometric sorting may account for actual tooth positions rather than relying solely on tooth numbering, which may not reflect geometric order in cases involving crowded teeth, missing teeth, extra teeth, or other anatomical variations.

[0101] In some embodiments, matching logic for mapping teeth representations to digital model teeth may depend on the type of representation. For individual teeth representations, a tooth in the digital model may be selected if its identifier matches any entry in the instruction's teeth array. For tooth group representations, a tooth may be selected if it belongs to the specified anatomical group, such as molars or anteriors, optionally filtered by jaw and side. For interval representations, a tooth may be selected if its position in the sorted array lies between the begin and end identifiers of the interval, inclusive. For relative position representations, a tooth may be selected if it is immediately mesial or distal to the referenced tooth based on the geometric ordering along the arch. For exclusion logic representations, the matching set may be computed by first determining all teeth that match the included group, and then subtracting the teeth that match the excluded set. This matching logic may enable accurate translation of varied natural language tooth references into specific sets of teeth in the patient's digital model.

[0102] In some embodiments, for treatment instructions involving interproximal spaces, such as gap closures, interproximal reduction, or black triangle corrections, it may be necessary to derive an array of interteeth intervals from a mapped array of teeth. These intervals may represent the spaces between adjacent teeth and may be used for accurately applying space-related treatment instructions. Given that the array of teeth has been sorted according to anatomical position along the jaw arch, the generation of interteeth intervals may proceed as follows. The mapped array of teeth may first be partitioned into two subarrays, one for the upper jaw and one for the lower jaw, to maintain anatomical coherence. For each jaw-specific subarray, the algorithm may iterate through the list of teeth in order and construct intervals between each pairof adjacent teeth. Each interval may be represented as a pair of tooth identifiers corresponding to the two teeth that bound the interproximal space. This approach may ensure that space-related instructions are accurately and consistently translated into digital treatment plans, even in the presence of anatomical anomalies or incomplete dentition.

[0103] In some embodiments, the system may be configured to handle irregular dental cases where teeth may not follow expected numbering order due to crowding, supernumerary teeth, missing teeth, or unusual tooth positions. When treatment providers refer to teeth using relative position terms such as "mesial" or "distal", they typically refer to geometric position along the dental arch rather than numerical order in a numbering system. The geometric sorting of teeth in the digital model may account for these irregularities, ensuring that relative position references are interpreted correctly. For example,Attorney Docket No.: 28510.998 (L0773PCT)in a case with a supernumerary tooth positioned between two regularly numbered teeth, the geometric sorting may place the supernumerary tooth in its correct position along the arch, enabling accurate interpretation of instructions such as "all teeth mesial to tooth X". By separating the textual representation of teeth from the digital model mapping, the system may improve the performance of the language model, as the language model may focus on interpreting the natural language instructions without needing to process patient-specific geometric data.

[0104] In some embodiments, systems may be in place (e.g., in treatment planning software, protocol generation software, or the like) that are applicable to certain instructions. For example, some categories of instructions may be handled deterministically, some may be handled manually, some may be handled using LLMs or other Al-based models, etc. In some embodiments, natural language instructions may be categorized, and various instructions provided to different systems for resolution. These categorization and routing approaches may be applicable across various medical fields, including dental, orthopedic, surgical, and rehabilitation contexts, where different types of treatment instructions may require different processing approaches based on complexity, safety considerations, or system capabilities.

[0105] In some embodiments, natural language comments may be provided to a classification model (e.g., an LLM configured to classify instructions based on training, fine-tuning, prompting strategies, etc.) to classify portions of the comments into relevant categories. Instructions from various categories may be provided to a system suited to execute requested operations or adjustments. In some embodiments, some comments that are not applicable to the target goals (e.g., comments that are not clinically relevant, such as a practitioner thanking an Al assistant) may be excluded from further operations. Comments which are related to instructions that can be deterministically carried out (e.g., comments related to specific updates to clinical practices that are common or well understood) may be provided to a system for deterministically performing the requested updates. Comments which are related to instructions for which a more advanced approach is to be implemented (e.g., where no deterministic system has been generated) may be provided to an LLM for generating machine-readable instructions or the like. In some embodiments, presence or absence of instructions belonging to one or more categories may adjust which systems are utilized in implementing instructions, such as providing instructions which cannot be classified or for which no system is in place to a manual resolution pipeline.

[0106] In some embodiments, natural language instructions may be classified to determine whether the natural language instructions include instructions belonging to target categories. The natural language instructions may be classified to determine whether instructions include instructions related to updating dental features. The natural language instructions may be classified to determineAttorney Docket No.: 28510.998 (L0773PCT)whether the instructions include instructions related to dental attachments, such as attachment locations, size, whether to use optimized or custom attachment schemes, stage of treatment for attachments to be utilized, etc. The machine-readable instructions generated from the natural language instructions may comprise updates to one or more treatment plan parameters for a target dental treatment. The treatment plan parameters may comprise dental appliance features for one or more dental appliances to be used for the target dental treatment, such as attachments, bite ramps, geometric appliance features, eruption compensation features (e.g., features such as eruption compensation pontics and eruption compensation tabs that reflect an aligner part that is placed above an erupting tooth), or mandibular advancement features including buccal blocks or occlusal blocks. Eruption compensation features are features in an alignerto create space for erupting permanent teeth while baby teeth fall out, ensuring natural, predictable eruption without obstruction. The treatment plan parameters may also comprise one or more planning targets or treatment planning attributes, such as intended final positions for one or more teeth, tooth velocities for one or more teeth, target treatment outcome, number of treatment stages, amount of overcorrection, staging for a treatment plan, and whether to apply passive aligners. Treatment plan staging may specify, for example, which teeth to move at which times, which groups of teeth to move, how to move single teeth and / or groups of teeth (e.g., amounts of translation and / or rotation along multiple directions and / or axes), and so on. The natural language instructions may be categorized according to the one or more types of treatment plan parameters to be applied for the dental treatment in embodiments.

[0107] In some embodiments, upon determining that a target classification of instruction is present, the instructions belonging to the target classification may be provided to a model or system for interpreting or implementing the instructions. In some embodiments, natural language instructions related to the target category (e.g., dental features, attachments, or the like) may be provided to an LLM for interpretation or implementation of the instructions. For example, an attachment model may include a purpose-trained, fine-tuned, or appropriately prompted LLM for generating machine-readable instructions for attachments and / or for other types of treatment categories (e.g., for other treatment plan parameters). Upon determining that instructions related to attachments and / or other specific types of treatment plan parameters are included in the natural language instructions, the instructions may be provided to the attachment model to be integrated into generation or update of treatment plans, treatment protocols, treatment prescriptions, or the like.

[0108] In some embodiments, an LLM (which may be a general LLM or an LLM configured to process treatment provider instructions related to dental features and attachments) may be provided with a prompt that defines the role of the Al assistant, specifies action types to be extracted, describes tooth numbering systems, enumerates attachment types, defines stage information formats, andAttorney Docket No.: 28510.998 (L0773PCT)specifies output format requirements. An example prompt for an LLM configured to extract attachment-related information from natural language instructions may include the following components.

[0109] The prompt may define the role of the Al assistant as extracting information from doctor instructions related to dental features for use by a technician in preparing a treatment for a patient. The prompt may specify that the response should be provided in a structured format, such as JSON, indicating the type of dental feature, the action required, and the teeth affected by the action.

[0110] The prompt may specify a set of action types to be identified from the natural language instructions. The action types may include: an add action for adding specific dental features to particular teeth, where the doctor may use terminology such as "apply attachment," "schedule attachment," "start attachment," or "put attachment"; a forbid_placement action for forbidding placement of new dental features on specific or all teeth; a delay_placement action for delaying placement of an attachment; a remove_existing action for removing dental features from a previous treatment plan; a keep_existing action for keeping particular dental features from a previous treatment plan; a replace_existi ng action for removing an existing attachment and placing a different one on the same tooth, which may be split into separate remove_existing and add instructions; and a modify_existing action for modifications to already-placed attachments such as resizing, changing position, orchanging alignment.

[0111] The prompt may include descriptions of multiple tooth numbering systems to enable the LLM to identify which system is being used in the natural language instructions. The tooth numbering systems may include: a Palmer system where teeth identifiers are represented with letters indicating upper (U) or lower (L) and right (R) or left (L) positions followed by a number ranging from 1 to 8, such as "UL2" for upper left 2; an FDI (Federation Dentaire Internationale) system where teeth identifiers include a first number ranging from 1 to 4, a separator character, and a second number ranging from 1 to 8, such as "1.2" or "2.4"; a Universal system where adult teeth are numbered from 1 to 32 starting from the upper right third molar and moving clockwise; and an unknown classification for cases where the numbering system is unclear or where teeth are referenced by group names such as "molars," "upper anteriors," or "centrals." The prompt may instruct the LLM to identify the numbering system and preserve the original tooth identifiers from the instruction without modification.

[0112] The prompt may enumerate attachment types to be identified. Optimized attachments may include specific types such as mesial_distal_root_control (also referred to as MDRC, root control, or distal root tip), multLplane, extrusion, rotation, retention (also referred to as deep bite), and expansion_support (also referred to as support). The prompt may specify optional variables for optimized attachments including size (regular or largest), MDRC type (single, dual, or free), and extra data (distal, mesial, horizontal, or vertical). Protocol attachments may include predefined protocols such as G4 (corresponding to mesial_distal_root_control attachments applicable to canines or incisors), G5Attorney Docket No.: 28510.998 (L0773PCT)(corresponding to extrusion attachments applicable to premolars), G7 (corresponding to multLplane attachments applicable to incisors), and G8 (corresponding to expansion_support attachments applicable to premolars and molars). The prompt may instruct the LLM to verify whether protocol conditions are satisfied based on tooth type.

[0113] The prompt may define stage information formats for specifying when actions should be applied during treatment. Stage representations may include: a first_stage indicator for the beginning of treatment (which may be expressed as "stage 0," "start of treatment," or "begin stage"); a last_stage indicatorfor the end of treatment; a passive_aligners indicator for a specific set of stages at the end of treatment; an overcorrection indicator for a specific set of stages; a literaLstage indicator for specific stage numbers; and an all_stages indicator. The prompt may specify optional variables including an offset value representing a number of stages relative to a reference stage, and a time indicator specifying whether an action should be applied before or after a specific stage.

[0114] The prompt may specify output format requirements including adherence to a schema (e.g., a JSON schema). The prompt may instruct the LLM to translate instructions not written in English into English in the output. The prompt may include considerations for handling terminology variations and misspellings, such as recognizing "aft," "attach," "attaches," or misspellings like "atachemens" as references to attachments. The prompt may include instructions for distinguishing attachment-related instructions from other instruction types, such as interproximal reduction (IPR) instructions, passive aligner instructions, pontics instructions, eruption compensation instructions (e.g., for eruption compensation pontics and / or eruption tabs), gable bends instructions, or occlusal marks instructions. In some embodiments, such instructions should be classified as other instructions rather than dental features instructions.

[0115] An example of structured output generated by an LLM based on such a prompt may include an object (e.g., a JSON object) specifying the detected numeric system, an array of dental feature objects each including attachment type information (general type, specific type, and optional parameters), action type, affected teeth, stage information if applicable, and the original instruction text. The output may also include an array for other instructions that are not related to dental features. For example, an instruction such as "add largest dual MDRC to upper anteriors starting at stage 5" may produce output including the numeric system as "unknown," a dental feature object with general type "optimized_attachments," specific type "mesial_distal_root_control," size "largest," MDRC type "dual," action "add," teeth specified as a group "upper_anteriors," and stage information indicating a literal stage of 5.

[0116] In some embodiments, Al models may be utilized in assisting, guiding, and / or integrating various portions of a treatment planning workflow. For example, an Al assistant function may beAttorney Docket No.: 28510.998 (L0773PCT)provided in one or more treatment planning platforms, treatment planning applications, treatment planning programs, or the like. The Al assistant function may be provided via a GUI. The Al assistant function may be implemented via a chat function in some embodiments. The Al assistant function may perform updates to one or more treatment operations, such as performing adjustments to one or more treatment fields (e.g., making selections corresponding to a GUI-based treatment planning or treatment protocol generation program).

[0117] In some embodiments, Al models, LLMs, or the like may be provided with information via prompting, contextual information (e.g., previously used prompts or responses), and / or additional documentation. For example, documents may be integrated into LLM responses via retrieval-augmented generation (RAG). In some embodiments, certain responses may be constrained or limited via prompting strategies or RAG. For example, a library of possible machine-readable commands, a library of explanations of various topics, treatments, or disorders, or the like may be provided. The LLM may be constrained to only produce medical explanations that align with provided documentation, only produce machine-readable commands that are included in the library, or the like.

[0118] In some embodiments, an Al assistant or guide may be inserted into various steps of a treatment planning process and / or a treatment monitoring process. For example, an Al assistant may be included in generation of a treatment protocol (e.g., a set of guidelines customized to a practitioner to be applied to various patients). The Al assistant may also be used in generating, customizing, or updating a specific treatment plan. In some cases, information may be shared between stages of Al assistance. For example, if a practitioner updates specific treatments multiple times, an Al assistant may recommend updating a treatment protocol to include the change that has been targeted repeatedly by the treatment provider.

[0119] In some embodiments, an Al assistant or Al chat function may be used for providing additional information to a treatment provider, or prompting the treatment provider to further clarify instructions. For example, an Al-based (e.g., LLM-based) chat function may provide responses to inquiries about specific treatment options. Treatment options may be provided in a treatment or protocol planning application, browser window, GUI, etc. An Al assistant may be configured to provide additional information about various treatment options responsive to receiving a query. The additional information may be presented in written form, verbal form via audio output or speech synthesis, sign language form via animated visual display, or combinations thereof. An Al assistant may further be configured to ask for additional information upon obtaining a request that is unclear or that does not appear to have any clinical instructions included. In some embodiments, an Al assistant may be provided with various Al tools to, for example, update selectable options of a GUI (e.g., a treatment protocol generation GUI),Attorney Docket No.: 28510.998 (L0773PCT)update a treatment protocol via introduction of machine-readable instructions, update a treatment plan via introduction of machine-readable instructions, or the like.

[0120] In some embodiments, Al models may be utilized in developing prompts for efficiently, accurately, and / or reliably causing LLMs or other models to perform any of the tasks discussed herein. In some cases, Al models such as LLMs may be utilized to improve prompts designed to accomplish a target task. For example, a base prompt, along with examples of situations in which the base prompt has performed poorly, may be provided to an LLM, with instructions to rewrite the prompt to generate a machine-generated prompt that correctly handles the example cases.

[0121] In some embodiments, an LLM may be used to develop a promptfor performing a task related to an existing task. For example, a base prompt may perform a first task, and an LLM may be used to develop a prompt to perform an extension of the first task, a related task, a task with a somewhat increased or adjusted scope of input data, or the like. In some cases, a categorization task into a set of pre-determined categories may be performed as a first task. A second task may include generating additional categories to assign previously unassigned or otherwise unrelated objects to.

[0122] In some embodiments, generating a promptfor an LLM with the assistance of an LLM (which may be the same as the first LLM or a different LLM) may include providing information related to the updated or new prompt. For example, a base prompt intended to solve the same problem or a related problem may be provided. Various additional information may also be provided, such as a description of the intended task, examples of failures of a previous version of the prompt, principles of the target output (such as a machine-readable format for final output), examples of situations in which the new prompt may be expected to perform accurately, etc. Output of the LLM based on these input parameters may be used as a prompt for solving additional problems, or LLM prompt generation may be performed iteratively, and the new prompt may be further provided as a base promptfor further refinement.

[0123] Generation of a prompt for a task related to a previous task using an LLM may be applicable to many situations, problems, and industries. In some embodiments, classification or execution of natural language instructions by dental or orthodontic practitioners may benefit from LLM-based prompt generation. Similarly, practitioners in other medical fields such as orthopedics, physical therapy, surgical specialties, and rehabilitation medicine may benefit from LLM-based prompt generation fortranslating natural language treatment instructions into machine-readable protocols. For example, an orthopedic surgeon may provide natural language instructions regarding joint replacement procedures, fracture fixation approaches, or post-operative rehabilitation protocols, and LLM-based systems may translate these instructions into machine-readable formats for treatment planning systems.Attorney Docket No.: 28510.998 (L0773PCT)

[0124] In some embodiments, an Al model may be trained, retrained, adjusted, or the like for one or more operations described herein. In some embodiments, an Al model may be trained for specific portions of the tasks performed by Al models. For example, and Al model may be specifically trained (adjusted, retrained, or the like) for generating machine-readable instructions based on natural language. Training the Al model may include adjusting parameters of an LLM. Training the Al model may include performing parameter-efficient fine-tuning, low-rank adaptations, adjusting adapter layers, or the like. Training the Al model may be based on one or more test cases, feedback data, feedback evaluation data, indirect feedback data (e.g., based on a number of updates provided to one or more Al-generated protocols), or the like.

[0125] Aspects of the present disclosure provide technological advantages compared to conventional methods. Aspects of the present disclosure may enable generation of a treatment protocol treatment algorithm, and / or treatment plan without and / or while reducing the role of a technician. Such methods may reduce reliance on a technician, reduce turnaround time for treatment protocol updates or generation, reduce additional delays that may be caused by a technician being in a different time zone or having a different working schedule than a practitioner, or the like. Such methods further improve efficiency by reducing a requirement of training for technicians in parsing doctor comments and generating machine-readable instructions related to protocol generation. In some embodiments, a practitioner could generate one or more treatment protocols essentially immediately without the involvement of any additional personnel. These advantages may be realized across various medical fields, including dental, orthodontic, orthopedic, surgical, physical therapy, and rehabilitation medicine contexts, where treatment protocols guide patient care and may benefit from rapid, accurate translation of practitioner preferences into machine-readable formats.

[0126] In some embodiments, options-selection based machine-readable instruction generation may be used along with Al-model based instruction generation. By using these two options together, such as using GUI-provided options for common disorders and Al-based solutions for niche or unusual cases, improvements to efficiency and breadth of options available to a practitioner while reducing or eliminating involvementof a technician trained in generating machine-readable instructions for healthcare treatment may be achieved. For example, dental cases within a scope of options programmed in a GUI-based treatment protocol generation program may be handled deterministically, while dental cases outside a scope of treatment categories may be effectively treated using an Al-based treatment protocol and / or treatment planning solution.

[0127] In some aspects, usage of Al- or LLM-based treatment protocol generation, treatment protocol updating, and / or treatment planning may improve a turnaround time of treatment planning operations. Operations including human intervention, which may include waiting due to differing timeAttorney Docket No.: 28510.998 (L0773PCT)zones or schedules of a practitioner and a technician, waiting for machine-readable instructions to be generated, waiting for validation from the practitioner, may include multiple rounds of updates, etc., may be avoided by providing instructions to an LLM and generating or updating treatment planning operations based on output of the LLM.

[0128] In some embodiments, the systems and methods described herein may be applied to orthopedic treatment planning. Orthopedic treatment protocols may specify treatment approaches for musculoskeletal conditions including joint disorders, fractures, ligament injuries, spinal conditions, and degenerative diseases. Natural language instructions from orthopedic practitioners may be translated into machine-readable protocols that specify surgical approaches, implant types and sizes, fixation methods, rehabilitation timelines, weight-bearing restrictions, and physical therapy regimens. For example, a practitioner may provide natural language instructions such as "use posterior approach for total hip arthroplasty with cementless femoral stem" or "begin partial weightbearing at week 4 post-operatively," and the Al model may generate corresponding machine-readable instructions for the treatment planning system. Treatment categories in orthopedic applications may include joint replacement parameters, fracture fixation specifications, soft tissue repair techniques, spinal instrumentation preferences, and rehabilitation protocol preferences. The GUI-based treatment option selection systems described herein may present orthopedic practitioners with selectable options for surgical approaches, implant preferences, post-operative protocols, and rehabilitation milestones, with selections being converted to machine-readable treatment protocols through deterministic or Al-based mappings.

[0129] In one aspectof the present disclosure, a method includes obtaining treatment provider instructions associated with a target dental treatment. The instructions may be expressed in natural language. The method further includes providing first input including the instructions to an Al model. The method further includes obtaining output from the Al model including a first treatment protocol in association with the target dental treatment. The method further includes providing an alert to the treatment provider, the alert including the treatment protocol.

[0130] In another aspect of the present disclosure, a method includes obtaining a plurality of treatment provider instructions associated with dental treatments. The method further includes obtaining a plurality of machine-readable instructions corresponding to the treatment provider instructions. The method further includes training a machine learning model to generate a trained machine learning model. T raining the model includes providing the plurality of treatment provider instructions as training input and the plurality of machine-readable instructions as target output.

[0131] In another aspect of the present disclosure, a method includes obtaining a data model including one or more fields to be filled. The fields may be associated with a dental treatment. TheAttorney Docket No.: 28510.998 (L0773PCT)method further includes generating a first prompt in natural language associated with a first one or more of the fields. The method further includes presenting the first prompt. The first prompt may be presented via a GUI. The method further includes obtaining a response to the first prompt. The method further includes providing the response to a trained machine learning model. The method further includes filling the one or more fields using output of the trained machine learning model based on the response.

[0132] In another aspect of the present disclosure, a method includes providing a first set of options related to treatment preferences for a first dental conditions. The method further includes obtaining a first selection of one of the first set of options. The method further includes providing the first selection to a model configured to generate machine-readable code to generate a dental treatment plan based on the first selection. The method further includes obtaining form the model the machine-readable code.

[0133] In another aspect of the present disclosure, a method includes providing a first set of treatment options related to a first treatment goal in association with a first dental condition. The method further includes providing a second set of treatment options related to a second treatment goal in association with the first dental condition. The method further includes obtaining a first selection from the first set of treatment options and a second selection from the second set of treatment options. The method further includes generating a treatment protocol in a machine-readable format including the first selection and the second selection. The method further includes obtaining and indication that the first treatment goal is to be applied to a patient in association with the first dental condition. The method further includes generating a treatment plan for the patient corresponding to the first treatment goal based on the treatment protocol.

[0134] In another aspect of the present disclosure, a method includes providing, via a graphical user interface (GUI), a set of treatment categories in association with operations of a dental treatment. The method further includes providing, for each of the set of treatment categories, a corresponding set of treatment options. The method further includes obtaining, for a first of the set of treatment categories, a selection from the set of treatment options via the GUI. The method further includes providing the selection to a model configured to generate a treatment protocol in a machine-readable format. The method further includes displaying the treatment protocol via the GUI.

[0135] In another aspect of the present disclosure, a method includes obtaining treatment provider instructions in natural language. The treatment provider instructions are related to treatment of a dental patient. The method further includes providing the first treatment provider instructions to a trained Al model. The method further includes obtaining output from the Al model, including machine-readable instructions related to the treatment provider instructions. The method further includes adjusting a treatment planning algorithm based on the first machine-readable instructions.Attorney Docket No.: 28510.998 (L0773PCT)

[0136] In another aspect of the present disclosure, a method includes obtaining first instructions in a first machine-readable format configured to generate a treatment plan based on input data. The method further includes obtaining second instructions in natural language corresponding to target adjustments to the first instructions. The method further includes providing the second instructions to a trained Al model. The method further includes obtaining output from the Al model. The output includes third instructions in a second machine-readable format. The method further includes updating the first instructions based on the third instructions.

[0137] In another aspect of the present disclosure, a method includes obtaining treatment provider instructions in natural language. The treatment provider instructions are indicative of differences between target dental treatment for a target dental patient and a set of treatment preferences associated with the treatment provider. The method further includes obtaining a prompt. The prompt includes a description of a set of categories of instructions associated with dental treatment. The prompt further includes a set of examples of machine-readable instructions corresponding to natural language instructions within the category of instructions. The method further includes providing the treatment provider instructions and the prompt as input to an Al model. The method further includes obtaining output from the Al model. The method further includes generating a treatment plan based on the output from the Al model.

[0138] In another aspect of the present disclosure, a method includes obtaining natural language instructions including a first reference to a set of ordered objects according to a first indexing scheme. The method further includes providing the natural language instructions and an accompanying prompt as input to an Al model. The prompt includes a description of the first indexing scheme. The method further includes obtaining output from the Al model. The output includes machine-readable instructions associated with the natural language instructions. The machine-readable instructions include instructions associated with the set of ordered objects. The machine-readable instructions include a second reference to the set of ordered objects according to a first machine-readable indexing scheme.

[0139] In another aspect of the present disclosure, a method includes obtaining treatment provider instructions in natural language associated with treatment of a dental patient. The natural language instructions include a first reference to one or more teeth of the dental patient expressed in accordance with a first indexing scheme. The method further includes providing the natural language instructions and an accompanying prompt as input to an Al model. The prompt includes a description of the first indexing scheme. The method further includes obtaining output from the Al model. The output includes machine-readable instructions related to the treatment provider instructions. The machine-readable instructions include a first reference to a first tooth in accordance with a machine-readableAttorney Docket No.: 28510.998 (L0773PCT)indexing scheme. The method further includes adjusting a treatment planning algorithm based on the machine-readable instructions.

[0140] In another aspect of the present disclosure, a method includes obtaining treatment provider instructions in natural language. The treatment provider instructions are indicative of one or more differences between target dental treatment for a target dental patient and a set of treatment preferences associated with the treatment provider. The treatment provider instructions include a first reference to one or more teeth of the dental patient, expressed in accordance with an indexing scheme. The method further includes obtaining a prompt. The prompt includes a description of the indexing scheme. The prompt includes a description of a set of categories of instructions related to dental treatment. The prompt further includes a set of examples of machine-readable instructions corresponding to natural language instructions within the categories of instructions. The method further includes providing the treatment provider instructions and the prompt as input to an artificial intelligence (Al) model. The method further includes obtaining output from the Al model including a second reference to the one or more teeth, expressed in accordance with a machine-readable indexing scheme. The method further includes generating a treatment plan based on the output from the Al model.

[0141] In another aspect of the present disclosure, a method includes obtaining a base prompt associated with a first target task for a first LLM. The method further includes providing a first prompt generation request, including the base prompt, as input to a second LLM. The method further includes obtaining, as first output from the second LLM, a model-generated prompt. The method further includes providing the model-generated prompt and input associated with a second target task, different than the first target task, to a third LLM. The method further includes obtaining output from the third LLM based on the model-generated prompt and the second target task.

[0142] In another aspect of the present disclosure, a method includes obtaining a base prompt configured to cause a first LLM to assign portions of natural language input to a first set of categories. The method further includes providing a prompt generation request to a second LLM. The prompt generation request includes the base prompt and a description of a target task, which includes generation of additional categories. The method further includes obtaining a model-generated prompt as output from the second LLM. The method further includes providing the model-generated prompt and first input including natural language associated with the third target task to a third LLM. The method further includes obtaining output from the third LLM including assignment of portions of the first input to the second set of categories.

[0143] In another aspect of the present disclosure, a method includes obtaining first natural language instructions from a treatment provider associated with a target treatment. The method furtherAttorney Docket No.: 28510.998 (L0773PCT)includes providing the first natural language instructions to a classification model. The method further includes determining, using the classification model, that a first category of instructions is not present in the first natural language instructions. The method further includes providing at least a portion of the first natural language instructions and a prompt configured to cause an LLM to generate machine-readable instructions corresponding to natural language instructions to the LLM. The method further includes obtaining machine-readable instructions corresponding to the first natural language instructions from the LLM.

[0144] In another aspect of the present disclosure, a method includes obtaining first natural language instructions from a treatment provider including target updates to a target dental treatment. The method further includes providing the first natural language instructions to a first LLM. The first LLM is configured to categorize natural language instructions. The method further includes determining that a first category of instructions is not present in the first natural language instructions. The method further includes providing at least a portion of the first natural language instructions and a prompt configured to cause a second LLM to generate machine-readable instructions corresponding to natural language instructions to the second LLM. The method further includes obtaining machine-readable instructions corresponding to the first natural language instructions from the second LLM.

[0145] In another aspect of the present disclosure, a method includes obtaining first natural language instructions from a treatment provider associated with a target dental treatment. The method further includes providing the first natural language instructions to a classification model. The method further includes determining that a first category of instructions is not present in the first natural language instructions. The method further includes determining that a second category of instructions is present in the first natural language instructions. The method further includes providing at least a portion of the first natural language instructions and a prompt configured to cause an LLM to generate machine-readable instructions corresponding to natural language instructions to the LLM. The method further includes obtaining machine-readable instructions corresponding to the first natural language instructions from the LLM. The method further includes updating a treatment plan to generate an updated treatment plan associated with the target dental treatment based on the machine-readable instructions. The method further includes providing a representation of the updated treatment plan for treatment provider review.

[0146] In another aspect of the present disclosure, a method includes obtaining first natural language comments associated with an update to one of a treatment protocol or a treatment plan. The method further includes providing the first natural language comments to an LLM. The method further includes obtaining, from the LLM, machine-implementable instructions corresponding to the first natural language comments. The method further includes executing the machine-implementable instructions.Attorney Docket No.: 28510.998 (L0773PCT)

[0147] In another aspect of the present disclosure, a method includes obtaining natural language instructions associated with an update to one of a dental treatment protocol or a dental treatment plan. The method further includes providing the first natural language instructions to an LLM. The method further includes obtaining, from the LLM, machine-implementable instructions corresponding to the first natural language comments. The method further includes performing dental treatment planning operations based on the machine-implementable instructions.

[0148] In another aspect of the present disclosure, a method includes providing, via a GUI, a free text entry element for providing instructions associated with updates to a treatment plan. The method further includes obtaining first natural language instructions associated with updating a target treatment plan. The method further includes providing the natural language instructions to an LLM. The method further includes obtaining, from the LLM, machine-readable instructions including updates to the target treatment plan corresponding to the first natural language instructions. The method further includes implementing the machine-readable instructions by performing treatment planning operations.

[0149] FIG. 1 is a block diagram illustrating an exemplary system 100 (exemplary system architecture), according to some embodiments. The system 100 includes a treatment provider device 120, dental arch data capturing equipment 126, treatment planning server 112, appliance manufacturing 121, and data store 140. The treatment planning server 112 may be part of treatment planning system 110. T reatment planning system 110 may further include server machines 170 and 180. Appliance manufacturing 121 may include any combination of computing devices, hardware (e.g., three-dimensional printers, thermoforming equipment, etc.), software, manufacturing equipment, etc., related to generating or manufacturing appliances (e.g., orthodontic appliances, palatal expanders, retainers, etc.) for providing dental treatment. As used herein, when appropriate, techniques, operations, or components related to dental arches and dental arch data may be extended to include operations related to other oral structures, including upper and / or lower gingiva and palate. For example, dental arch data capturing equipment 126 (e.g., such as intraoral scanning systems) may further be used for performing intraoral scans including generating data of other oral structures in addition to teeth. Some aspects of the present disclosure may be applicable outside a dental context, e.g., to other fields of medicine, other manufacturing fields, other fields including translating natural language instructions to machine-readable instructions, etc. For example, in orthopedic applications, the systems and methods described herein may be used to generate treatment protocols for musculoskeletal conditions, joint replacement planning, fracture treatment, spinal surgery planning, and rehabilitation protocols. In such applications, patient data capturing equipment may include imaging systems such as X-ray machines, MRI scanners, CT scanners, or motion capture systems, and appliance manufacturing may include fabrication of orthopedic implants, prosthetics, braces, splints, orAttorney Docket No.: 28510.998 (L0773PCT)custom orthotics. Aspects related to translating indexing schemes to machine-readable schemes may be applicable to many different technologies, fields, etc. Aspects related to prompt generation by providing a prompt-generation request to an LLM may be applicable to various fields.

[0150] Dental arch data capturing equipment 126 may include any combination ofequipmentfor collecting dental arch data, examples of which include intraoral scanning systems (e.g., that includes intraoral scanners and associated computing deices), x-ray machines, cameras, cone beam computed tomography (CBCT) machines, and so on. In some embodiments, dental arch data capturing equipment 126 corresponds to an intraoral scanner as described in U.S. Publication No. 2019 / 0388193, filed June 19, 2019, entitled “Intraoral 3D Scanner Employing Multiple Miniature Cameras and Multiple Miniature Pattern Projectors,” which is incorporated by reference herein. In some embodiments, dental arch data capturing equipment 126 corresponds to an intraoral scanner as described in U.S. Application No. 16 / 910,042, filed June 23, 2020 and entitled “Intraoral 3D Scanner Employing Multiple Miniature Cameras and Multiple Miniature Pattern Projectors,” which is incorporated by reference herein. In some embodiments, dental arch data capturing equipment 126 corresponds to an intraoral scanner as described in U.S. Patent No. 10,835,128, issued November 17, 2020, which is incorporated by reference herein. In some embodiments, dental arch data capturing equipment 126 corresponds to an intraoral scanner as described in U.S. Patent No. 10,918,286, issued February 21 , 2021 , which is incorporated by reference herein. Dental arch data may include data of healthy dental arches, dental arches including malocclusion or teeth misalignment, dental arches containing teeth with caries, dental arches containing gingival recession, gingival swelling, tooth wear, tooth cracks, etc.

[0151] In some embodiments, treatment provider device 120 may be used to generate or collect doctor instructions related to one or more treatment protocols and / or treatment plans, which may be included in instruction data 141 of data store 140. Doctor instructions stored as instruction data 141 may include doctor preferences, treatment goals, treatment priorities, etc. Doctor instructions may be collected via display component 124 of treatment provider device 120, e.g., via a user interface, graphical user interface (GUI), etc. In some embodiments, a set of options related to treatment may be provided to a treatment provider. The options may be presented as drop boxes, selectable icons, tabs, folders, or the like. Instruction data 141 may be based on selection of treatment preferences via the GUI provided by treatment provider device 120. In some embodiments, doctor instructions may be collected in natural language, e.g., via text fill boxes presented by display component 124. Instruction data 141 may include instructions related to generating a treatment protocol (e.g., an expression of treatment preferences of a practitioner), updating a treatment protocol, generating a treatment plan (e.g., adjustments to a default plan or to a protocol tailored to a specific case or patient), updating a treatment plan, etc.Attorney Docket No.: 28510.998 (L0773PCT)

[0152] Instruction data 141 may store doctor comments, notes, and / or instructions related to treatment protocols, treatment plans, etc. Instruction data 141 may relate to or include natural language input by one or more doctors, healthcare professionals, treatment providers, practitioners, etc.Instruction data 141 may be provided via display component 124 of treatment provider device 120. Instruction data 141 may relate to one or more treatment protocols, which may be or include general plans meant to relate to one or more generic, common, repeatedly encountered, or the like healthcare disorders (e.g., dental disorders, malocclusion, misalignment, or the like).

[0153] In some embodiments, natural language or machine-readable instructions may be classified. For example, instructions related to particular stages ortypes of treatment, particular dental disorders, specific appliances or implements, or the like may be grouped together. In some cases, an LLM may be used to perform classification operations, such as determining a category to which natural language instructions or sections of natural language instructions may be assigned. Instruction data 141 may further include classification or categorization data associated with various instructions.

[0154] Doctor instructions may be processed (e.g., by the treatment provider device 120 and / or by the treatment planning server 112). Processing of the instruction data 141 may include generating features. In some embodiments, the features are a pattern in the instruction data 141 (e.g., slope, width, height, peak, etc.) or a combination of values from the instruction data 141. Feature generation may include tokenizing the instruction data 141. Instruction data 141 may include features and the features may be used by treatment planning component 114 for performing signal processing and / or for obtaining treatment protocol data 142, e.g., for generation of healthcare treatments. In some embodiments, features may include segmentation data of instruction data 141. Segmentation may be performed (e.g., using a trained machine learning model trained to perform instance segmentation or semantic segmentation), and may include separation of various portions of doctor input into different sections, portions, or categories, such as sections related to different disorders, treatment types, teeth, or the like. Each instance (e.g., set) of instruction data 141 may correspond to an individual (e.g., practitioner), a group of similar dental arches, a group of teeth, or the like.

[0155] In some embodiments, treatment planning system 110 may generate treatment protocol data 142 and / or treatment planning data 164 based on instruction data 141. In some embodiments, treatment protocol data 142 may be related to encoding practitioner treatment preferences, and treatment planning data 164 may encode treatment planning operations for a specific treatment, specific patient, specific set of dentition, or the like. Treatment planning system 110 may generate protocol data 142 and / or treatment planning data 164 based on input provided, optionally via a GUI, indicating practitioner or clinician treatment preferences. The options presented by the GUI may be curated, e.g., common preferences may be included. The options presented by the GUI may transfer toAttorney Docket No.: 28510.998 (L0773PCT)a protocol design. For example, there may be a deterministic or rule-based mapping generated that translates options input by the treatment provider to treatment protocols and / or treatment plans. A rulebased mapping may be used to produce machine-readable code that, when executed, applies treatment preferences or a treatment protocol. For example, the machine-readable instructions may be executed in reference to a particular patient, and treatment planning operations in view of doctor selections may be performed based on the machine-readable protocol.

[0156] In some embodiments, treatment planning system 110 may generate treatment protocol data 142 and / or treatment planning data 164 using supervised machine learning (e.g., treatment protocol data 142 includes output from a machine learning model that was trained using labeled data, such as incomplete jaw pair data (e.g., data ofone or a few teeth) labeled with complete jaw pair data (e.g., jaw pair data including all teeth of the jaw)). In some embodiments, treatment planning system 110 may generate treatment protocol data 142 and / or treatment planning data 164 based on providing doctor instructions to one or more instances of a natural language processing model, an LLM, or the like. In some embodiments, treatment protocol data 142 and / or treatment planning data 164 may be or include machine readable instructions, e.g., related to target positions of one or more teeth to treat orthodontic disorders, related to treatment operations or steps for treating dental disorders, or the like. In some embodiments, treatment planning system 110 may generate treatment protocol data 142 and / or treatment planning data using unsupervised machine learning. For example, treatment protocol data 142 may include output from a machine learning model that was trained using unlabeled data. The output may include clustering results, principle component analysis, anomaly detection, etc. In some embodiments, treatment planning system 110 may generate treatment protocol data 142 using semisupervised learning (e.g., training data may include a mix of labeled and unlabeled data, etc.). In some embodiments, treatment planning system 110 may generate treatment protocol data 142 and / or treatment planning data using self-supervised learning, e.g., training data may also include target output data, such as in an autoencoder model.

[0157] In some embodiments, generation of treatment protocol data 142 and / or treatment planning data 164 (e.g., by providing instruction data 141 to an LLM) may also include providing further data to an Al model, such as instructions to process the input in a target way. Such instructions may be stored as prompt engineering data 144. Prompt engineering data 144 may include one or more prompts, prompt forms, prompt generation algorithms, or the like for generating accompanying data to be provided along with data associated with doctor input to an Al model. Prompt engineering data 144 may include additional text to be provided to an LLM that may be inserted before, in the middle of, after, or otherwise with a selection of doctor input or data based on doctor input (e.g., pre-processed or processed doctor input). Prompt engineering data 144 may cause an LLM to perform a different taskAttorney Docket No.: 28510.998 (L0773PCT)based on which prompt is provided. For example, one LLM may be used for many different tasks by providing input data accompanied with various additional prompt information. Prompt engineering data may include information directing the LLM in generating machine-readable code. Prompt engineering data 144 may include information directing the LLM in parsing and generating indexing schemes for ordered objects, e.g., dentition of a patient.

[0158] In some embodiments, prompt engineering may include use of an Al model such as an LLM. For example, a description of a target task may be provided to an LLM as a prompt generation request, and the LLM may provide a prompt that is predicted to configure an LLM to perform the target task. The prompt generation request may include further information, such as a related prompt, a description of situations in which the related prompt failed to perform as intended, a description of some examples that the machine-generated prompt may be expected to correctly execute, etc. Information related to LLM prompt generation may also be included in prompt engineering data 142.

[0159] In some embodiments, data store 140 may further include clinical data 146. Clinical data 146 may include patient data, such as three-dimensional models (e.g., surface meshes) of patient dentition. Clinical data 146 may include various thresholds, constraints, or the like related to physical realities available for treatment, such as maximum changes available for orthodontic procedures, maximum speed of adjustment, maximum number of treatment stages, maximum treatment time, and / or other constraints. Clinical data 146 may be used to check machine-readable protocol instructions to determine or verify that the instructions are in accordance with one or more rules, principles, or the like. Clinical data 146 may be used for performing validation of machine-readable instructions produced by an Al model such as an LLM. Clinical data 146 may be used to check or adjust treatment protocols generated by one or more Al models, e.g., to maintain safety of the recommended or generated procedures.

[0160] Data store 140 may further include response generator data 162. In some embodiments, one or more logical checks may be performed. For example, instructions for a treatment protocol generated by an Al model may be checked by providing a natural language prompt indicating a description of the instructions to a doctor, and asking the doctor whether the description is correct. In some embodiments, such a check response may be generated by a response generator, which may be a deterministic (e.g., rule-based) model. Response generation algorithms, responses, rules, etc., may be stored as response generator data 162. In some embodiments, clinical data 146 and / or treatment planning data 164 may include instructions related to performing treatments, such as models of appliances to be manufactured for treatment, manufacturing instructions for aligners, or the like.

[0161] In some embodiments, responses may be generated by an Al model, such as an LLM. For example, a practitioner may provide a query, via a chat function, an Al assistant function, a free textAttorney Docket No.: 28510.998 (L0773PCT)entry function, or the like, related to one or more treatment options, disorders, terminology, best practices, or other aspects relevant to treatment. An LLM may be empowered to generate natural language responses to these queries that clarifies or explains aspects of treatment to the treatment provider. The natural language responses may be presented in written form via a display, verbal form via audio output or speech synthesis, sign language form via animated visual representation, or combinations thereof. In some cases, an LLM may provide a prompt for a practitioner to input additional information. For example, a treatment provider may provide instructions which are not clear (e.g., a confidence in interpretation of the instructions may not meet a target threshold). The LLM, a chat function, a heuristic function, or the like may provide a prompt (e.g., via a chat GUI element) for the practitioner to provide additional clarity that may improve accuracy of further updates, actions, treatments, or the like. The prompt may be presented in written form, verbal form, sign language form, or combinations thereof. These responses, prompting strategies related to the responses, functions for performing deterministic responses, etc., may be included in response generator data 162.

[0162] Data store 140 may further include treatment documentation 165. Treatment documentation 165 may include additional documents related to various aspects of treatment that may be available to an LLM, but are not included in a prompt provided to the LLM. Treatment documentation 165 may include documents that are available for external retrieval by the LLM, e.g., in a retrieval-augmented generation (RAG) process. RAG may provide a route for improved accuracy and reliability of output generated by an Al model such as an LLM. RAG may add an additional external retrieval step to processing performed by an LLM. For example, an LLM may search through an external data source (e.g., treatment documentation 165) to gather relevant passages responsive to obtaining a request. The retrieved relevant passages may be provided into the LLM as additional contexts. The LLM may produce a response to the request based on both the query and the retrieved documentation. In some embodiments, certain output of an LLM may be constrained to the documentation. For example, medical questions may be constrained for safety or regulatory reasons to only be answered with information found within treatment documentation 165. Machine-readable or machine-implementable instructions may be constrained to only include functions that exist within an external library, assessable to the LLM via treatment documentation 165. Updating the documentation may enable an LLM to stay up-to-date without additional training or tweaking of prompting strategies, by updating documents accessible to the LLM in treatment documentation 165.

[0163] T reatment provider device 120, dental arch data capturing equipment 126, treatment planning server 112, data store 140, server machine 170, and server machine 180 may be coupled to each other via network 130 for generating treatment protocol data 142, e.g., to generate treatment protocol machine-readable instructions based on natural language practitioner input. In someAttorney Docket No.: 28510.998 (L0773PCT)embodiments, network 130 may provide access to cloud-based services. Operations performed by treatment provider device 120, treatment planning system 110, data store 140, etc., may be performed by virtual cloud-based devices.

[0164] In some embodiments, network 130 is a public network that provides treatment provider device 120 with access to the treatment planning server 112, data store 140, and other publicly available computing devices. In some embodiments, network 130 is a private network that provides treatment provider device 120 access to dental arch data capturing equipment 126, data store 140, and other privately available computing devices. Network 130 may include one or more Wide Area Networks (WANs), Local Area Networks (LANs), wired networks (e.g., Ethernet network), wireless networks (e.g., an 802.11 network ora Wi-Fi network), cellular networks (e.g., a Long Term Evolution (LTE) network), routers, hubs, switches, server computers, cloud computing networks, and / or a combination thereof.

[0165] Treatment provider device 120 may include computing devices such as Personal Computers (PCs), laptops, mobile phones, smart phones, tablet computers, netbook computers, network connected televisions (“smart TV”), network-connected media players (e.g., Blu-ray player), a set-top-box, Over-the-Top (OTT) streaming devices, operator boxes, etc. Treatment provider device 120 may include a display component 124. Display component 124 may receive user input (e.g., via a Graphical User Interface (GUI) displayed via the treatment provider device 120) of an indication associated with dental arch data. In some embodiments, treatment provider device 120 transmits the indication to the treatment planning system 110, receives output (e.g., treatment protocol data 142) from the treatment planning system 110, determines a treatment protocol or update, and causes the protocol to be displayed to the treatment provider via display component 124.

[0166] T reatment planning server 112, server machine 170, and server machine 180 may each include one or more computing devices such as a rackmount server, a router computer, a server computer, a personal computer, a mainframe computer, a laptop computer, a tablet computer, a desktop computer, Graphics Processing Unit (GPU), accelerator Application-Specific Integrated Circuit (ASIC) (e.g., Tensor Processing Unit (TPU)), etc. Operations of treatment planning server 112, server machine 170, server machine 180, data store 140, etc., may be performed by a cloud computing service, cloud data storage service, etc.

[0167] T reatment planning server 112 may include a treatment planning component 114. In some embodiments, the treatment planning component 114 may receive instruction data 141, (e.g., receive from the treatment provider device 120, retrieve from the data store 140) and generate output (e.g., treatment protocol data 142) based on the input data. In some embodiments, treatment protocol dataAttorney Docket No.: 28510.998 (L0773PCT)142 may include machine-readable instructions (e.g., computer code, code related to a treatment planning software, or the like) for one or more healthcare disorders.

[0168] System 100 may include one or more deterministic or rule-based models, e.g., model 190. A rule-based model may be used to convert preferences input by a doctor to machine-readable instructions (e.g., input by selecting from a set of provided options). A rule-based model may be used to convert machine-readable instructions to natural language, e.g., to perform verification steps. System 100 may include one or more machine leaning or Al models, e.g., model 190. Al models may perform many tasks, including mapping dental arch data to a latent space, splitting an input up into related sections, classifying or categorizing natural language instructions, formatting input text, detecting subject matter, transforming natural language instructions into machine-readable instructions, performing clinical checking, or the like. Model 190 may be trained using dental instruction data. Model 190 may be a general purpose LLM, configured via prompt engineering to perform one or more tasks based on treatment provider input.

[0169] One type of machine learning model that may be used to perform some or all of the above tasks is an artificial neural network, such as a deep neural network. Artificial neural networks generally include a feature representation component with a classifier or regression layers that map features to a desired output space. A convolutional neural network (CNN), for example, hosts multiple layers of convolutional filters. Pooling is performed, and non-linearities may be addressed, at lower layers, on top of which a multi-layer perceptron is commonly appended, mapping top layer features extracted by the convolutional layers to decisions (e.g. classification outputs).

[0170] A recurrent neural network (RNN) is another type of machine learning model. A recurrent neural network model is designed to interpret a series of inputs where inputs are intrinsically related to one another, e.g., time trace data, sequential data, etc. Output of a perceptron of an RNN is fed back into the perceptron as input, to generate the next output.

[0171] A graph convolutional network (GCN) is a type of machine learning model that is designed to operate on graph-structured data. Graph data includes nodes and edges connecting various nodes. GCNs extend CNNs to be applicable to graph-structured data which captures relationships between various data points. GCNs may be particularly applicable to meshes, such as three-dimensional data.

[0172] Many other types and varieties of machine learning models may be utilized for one or more embodiments of the present disclosure. Further types of machine learning models that may be utilized for one or more aspects include transformer-based architectures, generative adversarial networks, volumetric CNNs, etc. Selection of a specific type of machine learning model may be performed responsive to an intended input and / or output data, such as selecting a model adapted toAttorney Docket No.: 28510.998 (L0773PCT)three-dimensional data to perform operations on three-dimensional models of dental arches, a model adapted to two-dimensional image data to perform operations based on images of a patients teeth, etc.

[0173] Deep learning is a class of machine learning algorithms that use a cascade of multiple layers of nonlinear processing units for feature extraction and transformation. Each successive layer uses the output from the previous layer as input. Deep neural networks may learn in a supervised (e.g., classification) and / or unsupervised (e.g., pattern analysis) manner. Deep neural networks include a hierarchy of layers, where the different layers learn different levels of representations that correspond to different levels of abstraction. In deep learning, each level learns to transform its input data into a slightly more abstract and composite representation. In an image recognition application, for example, the raw input may be a matrix of pixels; the first representational layer may abstract the pixels and encode edges; the second layer may compose and encode arrangements of edges; the third layer may encode higher level shapes (e.g., teeth, lips, gums, etc.); and the fourth layer may recognize a scanning role. Notably, a deep learning process can learn which features to optimally place in which level on its own. The "deep" in "deep learning" refers to the number of layers through which the data is transformed. More precisely, deep learning systems have a substantial credit assignment path (CAP) depth. The CAP is the chain of transformations from input to output. CAPs describe potentially causal connections between input and output. For a feedforward neural network, the depth of the CAPs may be that of the network and may be the number of hidden layers plus one. For recurrent neural networks, in which a signal may propagate through a layer more than once, the CAP depth is potentially unlimited.

[0174] A large language model (LLM) is a type of Al model designed to understand and generate human-like text, natural language, or the like. LLMs are generally built using deep learning techniques and trained on large datasets from diverse sources. LLMs often provide natural language understanding, text generation, contextual learning, instruction following based on nuanced or detailed prompts, and other functions. LLMs have advantages based on a large extent of knowledge mapped by the layers of the models, as well as an ability to make correct connections between concepts to generate relevant output.

[0175] Various types of LLMs may be utilized in embodiments. Autoregressive LLMs generate text sequentially by predicting the next token based on preceding tokens, making them well-suited for text generation tasks. Encoder-decoder LLMs process input through an encoder to create contextual representations and then generate output through a decoder, which may be advantageous for translation or transformation tasks such as converting natural language instructions to machine-readable format. Transformer-based LLMs utilize self-attention mechanisms to process relationships between all tokens in an input sequence simultaneously, enabling capture of long-range dependencies in text. Instruction-tuned LLMs are fine-tuned on datasets of instructions and corresponding outputs,Attorney Docket No.: 28510.998 (L0773PCT)improving their ability to follow specific directives. Retrieval-augmented LLMs combine language generation with information retrieval from external knowledge bases, enabling access to domainspecific documentation during inference.

[0176] LLMs operate through several key mechanisms. During training, the model learns statistical patterns and relationships between tokens from large corpora of text data. The model architecture typically includes multiple layers of neural network components including attention layers that determine which parts of the input are most relevant for generating each output token, feed-forward layers that transform representations, and normalization layers that stabilize training. During inference, the model receives an input prompt and generates output by iteratively predicting subsequent tokens based on learned probability distributions. Temperature and sampling parameters may control the randomness and diversity of generated outputs.

[0177] In some embodiments, specially trained LLMs may be utilized that are trained or finetuned specifically for a target environment such as dentistry or orthodontics. Such specially trained LLMs may be trained on domain-specific corpora including dental literature, orthodontic treatment protocols, clinical terminology, tooth numbering systems, and / or examples of machine-readable treatment instructions. Fine-tuning techniques may include full fine-tuning where all model parameters are updated, parameter-efficient fine-tuning such as low-rank adaptation (LoRA) where only a subset of parameters are modified, or adapter-based approaches where additional trainable layers are inserted into a frozen base model. Specially trained LLMs may exhibit improved accuracy in generating machine-readable dental treatment instructions, better understanding of clinical terminology and abbreviations, and / or more reliable adherence to domain-specific output formats in some embodiments.

[0178] Alternatively or additionally, general purpose LLMs may be utilized with specialized prompts to achieve domain-specific functionality without requiring model retraining. Specialized prompts may specify parameters and rules for generating machine-readable instructions for a dental treatment plan, treatment algorithm, or treatment protocol. For example, a prompt may include descriptions of valid instruction categories such as tooth movement instructions, attachment instructions, interproximal reduction instructions, or staging instructions. Prompts may specify examples of natural language instructions and corresponding machine-readable output formats, enabling the LLM to learn the desired transformation through in-context learning. Prompts may specify bounds and thresholds for outputs, such as maximum tooth movement velocities, allowable interproximal reduction amounts, and / or valid stage ranges. Prompts may specify types of outputs including required fields, data types, and schema structures for machine-readable instructions. Prompts may further include descriptions of tooth numbering systems such as Universal Numbering System, Palmer notation, or FDI notation, along with mappings to machine-readable indexing schemes. Through careful prompt engineering, generalAttorney Docket No.: 28510.998 (L0773PCT)purpose LLMs may be configured to reliably generate machine-readable dental treatment instructions that conform to specified formats and constraints.

[0179] In some embodiments, treatment planning component 114 receives doctor protocol descriptions or treatment plan descriptions in natural language, performs signal processing to break down the current data into sets of current data (e.g., via segmentation or paragraph splitting, which may be provided by an LLM such as model 190), provides the sets of current data as input to a trained model 190, and obtains outputs indicative of treatment protocol data 142 from the trained model 190. In some embodiments, model 190 may represent a single general purpose or specifically trained or adjusted LLM, which may be utilized multiple times using different engineered prompts to perform various tasks in association with a set of doctor protocol description, instructions, input, etc.

[0180] In some embodiments, the various models discussed in connection with model 190 (e.g., rule-based model, supervised machine learning model, unsupervised machine learning model, etc.) may be combined in one model (e.g., a hierarchical model), or may be separate models.

[0181] Data may be passed back and forth between several distinct models included in model 190 and treatment planning component 114, or provided to a single model multiple times. In some embodiments, some or all of these operations may instead be performed by a different device, e.g., treatment provider device 120, server machine 170, server machine 180, etc. It will be understood by one of ordinary skill in the art that variations in data flow, which components perform which processes, which models are provided with which data, and the like are within the scope of this disclosure.

[0182] Data store 140 may be a memory (e.g., random access memory), a drive (e.g., a hard drive, a flash drive), a database system, a cloud-accessible memory system, or another type of component or device capable of storing data. Data store 140 may include multiple storage components (e.g., multiple drives or multiple databases) that may span multiple computing devices (e.g., multiple server computers). The data store 140 may store instruction data 141 , treatment protocol data 142, prompt engineering data 144, clinical data 146, and response generator data 162.

[0183] In some embodiments, treatment planning system 110 further includes server machine 170 and server machine 180. Server machine 170 includes a data set generator 172 that is capable of generating data sets (e.g., a set of data inputs and a set of target outputs) to train, validate, and / or test model(s) 190, including one or more machine learning models. Some operations of data set generator 172 are described in detail below with respect to FIG 5A. In some embodiments, data set generator 172 may partition the historical data (e.g., historical instruction data) into a training set (e.g., sixty percent of the historical data), a validating set (e.g., twenty percent of the historical data), and a testing set (e.g., twenty percent of the historical data).Attorney Docket No.: 28510.998 (L0773PCT)

[0184] In some embodiments, treatment planning system 110 (e.g., via treatment planning component 114) generates multiple sets of features. For example a first set of features may correspond to a first subset of instruction data (e.g., data related to a first disorder, first type of treatment, or the like) that correspond to each of the data sets (e.g., training set, validation set, and testing set) and a second set of features may correspond to a second subset of instruction data that correspond to each of the data sets.

[0185] In some embodiments, machine learning model 190 is provided historical data as training data. Training data may be used to adjust one or more parameters of an existing model, e.g., to retrain or focus the model for use in a particular application. Various types of retraining schemes may be used, that may be more efficient than fully retraining an Al model, LLM, or the like. The type of data provided will vary depending on the intended use of the machine learning model. For example, a machine learning model may be trained by providing the model with historical doctor inputs as training input. The machine learning model 190 may be configured to generate machine-readable instructions related to doctor instructions. A machine learning model may be provided with corresponding machine-readable instructions, e.g., in a target programming language. Such a machine learning model may be configured to generate mappings (e.g., in a latent space) between natural language instructions and machine-readable instructions.

[0186] In one embodiment, server machine 180 includes a training engine 182, a validation engine 184, selection engine 185, and / or a testing engine 186. An engine (e.g., training engine 182, a validation engine 184, selection engine 185, and a testing engine 186) may refer to hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, processing device, etc.), software (such as instructions run on a processing device, a general purpose computer system, ora dedicated machine), firmware, microcode, ora combination thereof. The training engine 182 may be capable of training a model 190 using one or more sets of features associated with the training set from data set generator 172. The training engine 182 may generate multiple trained models 190, where each trained model 190 corresponds to a distinct set of features of the training set (e.g., instruction data from a specific subset of treatment categories, such as disorder types, treatment types, disorder severities, or another categorization). For example, a first trained model may have been trained using all features (e.g., X1 -X5), a second trained model may have been trained using a first subset of the features (e.g., X1 , X2, X4), and a third trained model may have been trained using a second subset of the features (e.g., X1 , X3, X4, and X5) that may partially overlap the first subset of features. Data set generator 172 may receive the output of a trained model (e.g., segmented input data into paragraphs each related with a target topic), collect that data into training, validation, and testing data sets, and use the data sets toAttorney Docket No.: 28510.998 (L0773PCT)train a second model (e.g., a machine learning model configured to perform further operations based on the segmented input data, etc.).

[0187] Validation engine 184 may be capable of validating a trained model 190 using a corresponding set of features of the validation set from data set generator 172. For example, a first trained machine learning model 190 that was trained using a first set of features of the training set may be validated using the first set of features of the validation set. The validation engine 184 may determine an accuracy of each of the trained models 190 based on the corresponding sets of features of the validation set. Validation engine 184 may discard trained models 190 that have an accuracy that does not meet a threshold accuracy. In some embodiments, selection engine 185 may be capable of selecting one or more trained models 190 that have an accuracy that meets a threshold accuracy. In some embodiments, selection engine 185 may be capable of selecting the trained model 190 that has the highest accuracy of the trained models 190.

[0188] Testing engine 186 may be capable of testing a trained model 190 using a corresponding set of features of a testing set from data set generator 172. For example, a first trained machine learning model 190 that was trained using a first set of features of the training set may be tested using the first set of features of the testing set. Testing engine 186 may determine a trained model 190 that has the highest accuracy of all of the trained models based on the testing sets.

[0189] In the case of a machine learning model, model 190 may refer to the model artifact that is created by training engine 182 using a training setthat includes data inputs and corresponding target outputs (correct answers for respective training inputs). Patterns in the data sets can be found that map the data input to the target output (the correct answer), and machine learning model 190 is provided mappings that capture these patterns. The machine learning model 190 may use one or more of Support Vector Machine (SVM), Radial Basis Function (RBF), clustering, supervised machine learning, semi-supervised machine learning, unsupervised machine learning, k-Nearest Neighbor algorithm (k-NN), linear regression, random forest, neural network (e.g., artificial neural network, recurrent neural network, CNN, graph neural network, GCN), etc.

[0190] T reatment planning component 114 may provide current data to model 190 and may run model 190 on the input to obtain one or more outputs. For example, treatment planning component 114 may provide target instruction data 141 to model 190 and may run model 190 on the input to obtain one or more outputs. Treatment planning component 114 may be capable of determining (e.g., extracting) treatment protocol data 142 from the output of model 190. Treatment planning component 114 may determine (e.g., extract) confidence data from the output that indicates a level of confidence that predictive data (e.g., treatment protocol data 142) is an accurate representation of the natural language instructions provided by the treatment provider. Treatment planning component 114 may use theAttorney Docket No.: 28510.998 (L0773PCT)confidence data to decide whether to cause a corrective action associated with the dental arch, e.g., providing a prompt to the practitioner to provide additional clarity, additional information, or the like.

[0191] The confidence data may include or indicate a level of confidence that the treatment protocol data 142 is an accurate prediction associated with the input data. In one example, the level of confidence is a real number between 0 and 1 inclusive, where 0 indicates no confidence that the treatment protocol data 142 is an accurate prediction for the input data and 1 indicates absolute confidence that the treatment protocol data 142 accurately predicts machine-readable instructions associated with the input data. Responsive to the confidence data indicating a level of confidence below a threshold level for a predetermined number of instances (e.g., percentage of instances, frequency of instances, total number of instances, etc.) treatment planning component 114 may cause trained model 190 to be re-trained (e.g., based on an updated pool of training data, etc.). In some embodiments, retraining may include generating one or more data sets (e.g., via data set generator 172) utilizing historical data.

[0192] For purpose of illustration, rather than limitation, aspects of the disclosure describe the training of one or more machine learning models 190 using historical data and inputting current data into the one or more trained machine learning models to determine treatment protocol data 142. In other embodiments, a heuristic model, physics-based model, or rule-based model is used to determine treatment protocol data 142 (e.g., without or in addition to using a trained machine learning model. Any of the information described with respect to data inputs to one or more models may be monitored or otherwise used in the heuristic, physics-based, or rule-based model.

[0193] In some embodiments, the functions of treatment provider device 120, treatment planning server 112, server machine 170, and server machine 180 may be provided by a fewer number of machines. For example, in some embodiments server machines 170 and 180 may be integrated into a single machine, while in some other embodiments, server machine 170, server machine 180, and treatment planning server 112 may be integrated into a single machine. In some embodiments, treatment provider device 120 and treatment planning server 112 may be integrated into a single machine. In some embodiments, functions of treatment provider device 120, treatment planning server 112, server machine 170, server machine 180, and data store 140 may be performed by a cloud-based service.

[0194] In general, functions described in one embodiment as being performed by treatment provider device 120, treatment planning server 112, server machine 170, and server machine 180 can also be performed on treatment planning server 112 in other embodiments, if appropriate. In addition, the functionality attributed to a particular component can be performed by different or multiple components operating together. For example, in some embodiments, the treatment planning server 112Attorney Docket No.: 28510.998 (L0773PCT)may determine a corrective action based on the treatment protocol data 142. In another example, treatment provider device 120 may determine the treatment protocol data 142 based on output from the trained machine learning model.

[0195] The treatment protocol data 142 may be utilized by orthodontic treatment planning software to generate a customized treatment plan for a patient. In some embodiments, the treatment planning software may receive the treatment protocol data 142 and process the data in conjunction with patient-specific dental data (e.g., a three-dimensional model of patient dentition obtained from intraoral scans) to determine a sequence of tooth movements required to achieve a desired final tooth arrangement. The treatment planning process may involve analyzing the patient's initial dental configuration, identifying target positions for each tooth based on the treatment protocol data 142, and calculating intermediate stages between the initial and final configurations. The treatment planning software may generate staging information that defines how teeth are to be repositioned incrementally across multiple treatment stages, with each stage corresponding to a dental appliance configured to move teeth from one arrangement to the next.

[0196] In embodiments, a generated treatment protocol may be provided to a treatment planning system and / or treatment management system such as ClinCheck® provided by Align Technology®. A treatment planning system may use digital impressions and / or a treatment protocol or treatment algorithm or pre-generated treatment plan to plan an orthodontic treatment and / or a restorative treatment (e.g., to plan an ortho-restorative treatment). The treatment planning system may plan and simulate orthodontic and / or restorative treatments.

[0197] In an example, an orthodontic treatment planning system may use advanced 3D imaging technology to create virtual models of patients' teeth and jaws based on digital impressions or intraoral scans. These digital models may be used to plan and simulate the entire course of orthodontic treatment, including the movement of individual teeth and the progression of treatment overtime. Orthodontists can specify the desired tooth movements, treatment duration, and other parameters via a treatment protocol (e.g., by providing such treatment information using natural language instructions and having the natural language instructions converted into machine readable code as described herein), to create personalized treatment plans tailored to each patient's unique anatomy, oral health, and preferences. The orthodontic treatment planning system enables orthodontists to simulate the step-by-step progression of orthodontic treatment virtually, showing patients how their teeth will gradually move and align over the course of treatment. Orthodontists can visualize the planned tooth movements in 3D and make adjustments as needed to optimize treatment outcomes. The orthodontic treatment planning system may provide orthodontists and patients with visualizations of the predicted treatment outcomes, including before-and-after simulations that demonstrate the expected changes in toothAttorney Docket No.: 28510.998 (L0773PCT)position and alignment, and how those changes might affect the patients overall oral health. These visualizations help patients understand the proposed treatment plan and make informed decisions about their orthodontic care.

[0198] During treatment, updated data may be gathered about a patients dentition, and such data may be processed, optionally in view of an already generated orthodontic treatment plan, to generate an updated report of the patients overall oral health and / or to update the treatment plan. This may enable the orthodontic treatment planning / management system to perform informed modifications to the treatment plan.

[0199] In some embodiments, the treatment planning process may include receiving a digital representation of a patient's teeth, generating one or more treatment stages based on the digital representation and the treatment protocol data (e.g., which may be automatically generated from natural language instructions provided by a practitioner), and fabricating at least one orthodontic appliance based on the generated treatment stages. The treatment planning software may determine a movement path to move one or more teeth from an initial arrangement to a target arrangement, determine a design for one or more dental appliances shaped to implement the movement path, and generate instructions to fabricate the one or more dental appliances. The treatment protocol data may encode practitioner preferences such as aggression of tooth movement, sequencing of treatment operations, attachment placement preferences, interproximal reduction parameters, and / or other treatment parameters that influence how the treatment plan is generated for a particular patient.

[0200] Once a treatment plan has been generated, the treatment plan may be provided to a dental computer aided drafting (CAD) system, such as Exocad® by Align Technology. The dental CAD system may be used for designing dental restorations such as crowns, bridges, inlays, onlays, veneers, and dental implants. The dental CAD system may provide a comprehensive suite of tools and features that enable dental professionals to create precise and customized dental restorations digitally. The dental CAD system may import digital impressions (e.g., 3D digital models of a patients dental arches) captured using intraoral scanners, and may further import a treatment plan or treatment protocol. The treatment protocol or treatment plan may be used together with a digital impression of a patients dental arches to develop an appropriate restoration for the patient, for implant planning, for planning of surgery for implant placement, for orthodontic treatment planning, and so on.

[0201] In embodiments, the functions of a particular component can be performed by different or multiple components operating together. One or more of the treatment planning server 112, server machine 170, or server machine 180 may be accessed as a service provided to other systems or devices through appropriate application programming interfaces (API).Attorney Docket No.: 28510.998 (L0773PCT)

[0202] In embodiments, a “user” may be represented as a single individual. However, other embodiments of the disclosure encompass a “user” being an entity controlled by a plurality of users and / or an automated source. For example, a set of individual users federated as a group of administrators may be considered a “user.”

[0203] FIG. 2 illustrates workflows 200 for training and implementing one or more machine learning models for performing operations associated with utilizing practitioner instructions to generate treatment protocols treatment algorithms, and / or treatment plans, in accordance with embodiments of the present invention. The illustrated workflows include a model training workflow 205 and a model application workflow 247. The model training workflow 205 is to train or retrain one or more machine learning models (e.g., deep learning models, generative models, LLMS, etc.) to perform one or more data segmentation tasks and / or data generation tasks. The model application workflow 247 is to apply the one or more trained machine learning models to generate treatment protocol data, for instance in the form of machine-readable instructions for protocol generation based on disorder details, based on the input data 250. In some embodiments, the model training workflow may be omitted (e.g., such as where a general purpose LLM is used with specialized prompting focused on dental treatment).

[0204] Training of a neural network may be achieved in a supervised learning manner, which involves feeding a training dataset consisting of labeled inputs through the network, observing its outputs, defining an error (by measuring the difference between the outputs and the label values), and using techniques such as deep gradient descent and backpropagation to tune the weights of the network across all its layers and nodes such that the error is minimized. In many applications, repeating this process across the many labeled inputs in the training dataset yields a network that can produce correct output when presented with inputs that are different than the ones present in the training dataset. In high-dimensional settings, such as large images, this generalization is achieved when a sufficiently large and diverse training dataset is made available.

[0205] The model training workflow 205 and the model application workflow 247 may be performed by processing logic, executed by a processor of a computing device. Workflows 205 and 247 may be implemented, for example, by one or more devices depicted in FIG. 1, such as server machine 170, server machine 180, treatment planning server 112, etc. These methods and / or operations may be implemented by one or more machine learning modules executed on processing devices of devices depicted in FIG. 1.

[0206] Forthe model training workflow 205, a training dataset 210 containing hundreds, thousands, tens of thousands, hundreds of thousands or more examples of input data may be provided. The properties of the input data will correspond to the intended use of the machine learning model(s). For example, a machine learning model for processing natural language instructions to produceAttorney Docket No.: 28510.998 (L0773PCT)machine readable instructions for generating treatment plans may be trained. Training the machine learning model for generating machine readable protocol instructions may include providing a training dataset 210 of natural language input data to be mapped to output machine readable instructions. Training dataset 210 may include additional information, such as contextual information, metadata, etc.

[0207] In some embodiments, workflows 200 may be associated with fine-tuning or adjusting a general-purpose artificial intelligence or machine learning model, e.g., for adjusting operations of an LLM to cause the LLM to be more applicable to the target operations of generating treatment protocol instructions based on natural language instruction input. One or more operations as described with respect to model training workflow 205 and / or model application workflow 247 may be performed in a generalized context, e.g., without particular emphasis on input data related to treatment protocol generation. Such a general-purpose Al model (e.g., an LLM) may produce satisfactory results when utilized to generate protocol data in accordance with the present disclosure. In some embodiments, one or more techniques utilizing a training dataset 201 specific to target operations of the model may be used to adjust a generally trained model to perform target tasks with a higher degree of accuracy.

[0208] Techniques for adjusting a general-purpose Al model may include parameter-efficient fine-tuning operations. Parameter-efficient fine-tuning is a technique to update Al models in a resourceefficient manner. Parameter-efficient fine-tuning may reduce computational and data volume demands by only updating a subset of a models parameters, e.g., according to methods described with respect to model training workflow 205. Parameter-efficient fine-tuning may include adapter layer tuning, which includes introducing small neural network layers or adapters between existing layers of a pre-trained model. During fine-tuning, only the adapter layers are trained. Parameter-efficient fine-tuning may include lor-rank adaptation techniques, which add low-rank matrices to the weight matrices of the model. During fine-tuning, only these low-rank matrices are updated. Parameter-efficient fine-tuning methods may include bias tuning, where only bias terms are adjusted, prefix-tuning, where learnable vectors are added to input embeddings that are adjusted during fine-tuning, techniques where some parameters are allowed to be updated while others are held static, or other methods for improving performance of a pre-trained Al model.

[0209] T raining dataset 210 may reflect the intended use of the machine learning model. A model may be configured to generate machine-readable protocol instructions. For example, a model may be configured to translate natural language protocol descriptions into machine-readable protocol instructions. The machine learning model configured to predict protocol instructions may be provided with data indicative of one or more natural language and machine-readable instruction pairs as part of training dataset 210. Such a model may be trained to receive a natural language description of a treatment protocol, including practitioner generate treatment guidelines or preferences for a particularAttorney Docket No.: 28510.998 (L0773PCT)healthcare disorder, and generate as output machine-readable instructions that may facilitate generating a specific treatment plan based on disorders of a target patient. In some embodiments, an LLM may be trained (e.g., adjusted, retrained) to perform one or more different tasks with respect to generating machine-readable instructions, such as tasks described with respect to FIG. 3D.

[0210] In some embodiments, some or all of the training dataset 210 may be segmented. For example, a model may be trained or configured (e.g., via training adjustments or prompt engineering) to separate input related to multiple topics into sections, each associated with one of the input topics. For example, an input may include descriptions of treatment preferences or protocols related to several disorders, and a segmentermay be used to separate the input into sections related to each target disorder. The segmenter215 may separate portions of data fortraining of a machine learning model. For example, individual topics, such as separate disorders or different treatment categories or the like, may be segmented from each other for generating data sets for training a model to generate treatment protocol data.

[0211] Data of the training dataset 210 may be processed by segmenter 215 that segments the data of training dataset 210 into multiple different features. The segmenter may then output segmentation information 218. The segmenter 215 may itself be a machine learning model, e.g., a machine learning model configured to separate input into different sections, segments, categories, or the like. Segmenter 215 may be a general purpose LLM, may be an LLM trained specifically to be applicable to dental disorders, an LLM trained specifically to segment natural language instructions related to dental treatment protocols, or the like. In some embodiments, training dataset 210 may not be provided to segmenter 215, e.g., training dataset 210 may be provided to train ML models without segmentation.

[0212] In some embodiments, various other pre-processing operations (e.g., in addition to or instead of segmentation) may also be performed before providing input (e.g., training input or inference input) to the machine learning model. Other pre-processing operations may share one or more features with segmenter 215 and / or segmentation information 218, e.g., location in the model training workflow 205. Pre-processing operations may include mesh closing, artifact removal, various text formatters, or other pre-processing that may improve performance of the machine learning models.

[0213] Data from training dataset 210 may be provided to train one or more machine learning models at block 220. T raining a machine learning model may include first initializing the machine learning model. The machine learning model that is initialized may be a deep learning model such as an artificial neural network. An optimization algorithm, such as back propagation and gradient descent may be utilized in determining parameters of the machine learning model based on processing of data from training dataset 210.Attorney Docket No.: 28510.998 (L0773PCT)

[0214] Training of a neural network may be achieved in a supervised learning manner, which involves feeding a training dataset consisting of labeled inputs through the network, observing its outputs, defining an error (by measuring the difference between the outputs and the label values), and using techniques such as deep gradient descent and backpropagation to tune the weights of the network across all its layers and nodes such that the error is minimized. In many applications, repeating this process across the many inputs in the training dataset yields a network that can produce correct output when presented with inputs that are different than the ones present in the training dataset. In high-dimensional settings, such as large images, this generalization is achieved when a sufficiently large and diverse training dataset is made available.

[0215] An artificial neural network includes an input layer that consists of values in a data point (e.g., intensity values and / or height values of pixels in a height map). The next layer is called a hidden layer, and nodes at the hidden layer each receive one or more of the input values. Each node contains parameters (e.g., weights) to apply to the input values. Each node therefore essentially inputs the input values into a multivariate function (e.g., a non-linear mathematical transformation) to produce an output value. A next layer may be another hidden layer or an output layer. In either case, the nodes at the next layer receive the output values from the nodes at the previous layer, and each node applies weights to those values and then generates its own output value. This may be performed at each layer. A final layer is the output layer.

[0216] Processing logic adjusts weights of one or more nodes in the machine learning model(s) based on an error term. The error term may be based upon a difference between output of the machine learning model and target output provided as partof training dataset 210. For example, the error term may be based upon a difference between output of the machine learning model based on a natural language input, and machine-readable instructions associated with the natural language input (e.g., provided by a subject matter expert). Based on this error, the artificial neural networks adjust one or more of their parameters for one or more of their nodes (the weights for one or more inputs of a node). Parameters may be updated in a back propagation manner, such that nodes at a highest layer are updated first, followed by nodes ata next layer, and so on. An artificial neural network contains multiple layers of “neurons”, where each layer receives as input values from neurons at a previous layer. The parameters for each neuron include weights associated with the values that are received from each of the neurons ata previous layer. Accordingly, adjusting the parameters may include adjusting the weights assigned to each of the inputs for one or more neurons atone or more layers in the artificial neural network.

[0217] In some embodiments, portions of available training data (e.g., training dataset 210) may be utilized for different operations associated with generating a usable machine learning model.Attorney Docket No.: 28510.998 (L0773PCT)Portions of training dataset 210 may be separated for performing different operations associated with generating a trained machine learning model. Portions of training dataset 210 may be separated for use in training, validating, and testing of machine learning models. For example, 60% of training dataset 210 may be utilized fortraining, 20% may be utilized for validating, and 20% may be utilized fortesting.

[0218] In some embodiments, the machine learning model may be trained based on the training portion of training dataset 210. T raining the machine learning model may include determining values of one or more parameters as described above to enable a desired output related to an input provided to the model. One or more machine learning models may be trained, e.g., based on different portions of the training data. The machine learning models may then be validated, using the validating portion of the training dataset 210. Validation may include providing data of the validation set to the trained machine learning models and determining an accuracy of the models based on the validation set. Machine learning models that do not meet a target accuracy may be discarded. In some embodiments, only one machine learning model with the highest validation accuracy may be retained, ora target number of machine learning models may be retained. Machine learning models retained through validation may further be tested using the testing portion of training dataset 210. Machine learning models that provide a target level of accuracy in training operations may be retained and utilized for future operations. At any point (e.g., validation, testing), if the number of models that satisfy a target accuracy condition does not satisfy a target number of models, training may be performed again to generate more models for validation and testing.

[0219] Once one or more trained machine learning models are generated, they may be stored in model storage 245, and utilized for generating predictive data associated with dental treatment protocols, such as providing predictions of machine-readable instructions associated with natural language protocol descriptions, operations related to a flow to generate the instructions, or the like.

[0220] In some embodiments, model application workflow 247 includes utilizing the one or more machine learning models trained at block 220. Machine learning models may be implemented as separate machine learning models or a single combined (e.g., hierarchical, ensemble model, or the like) machine learning model in embodiments.

[0221] Processing logic that applies model application workflow 247 may further execute a user interface, such as a graphical user interface. A user may select one or more options using the user interface. Options may include selecting which of the trained machine learning models to use, selecting which of the operations the trained machine learning models are configured to perform to execute, customizing input and / or output of the machine learning models, or the like. For example, a user may only be interested in output of a single or a set of disorders, but may provide doctor-generated natural language input related to a number of disorders or other inputthat is not relevant to the target output.Attorney Docket No.: 28510.998 (L0773PCT)

[0222] Input data 250 is provided to a machine learning model trained in block 220. The input data 250 may correspond to at least a portion or training dataset 210, e.g., be the same type of data, data collected by the same measurement technique, data that resembles data of training dataset 210, or the like. Input data 250 may include new natural language instructions for treatment protocols or treatment plans, e.g., from a new practitioner, a practitioner who wishes to update their standard treatment protocols, etc. Input data 250 may further include ancillary information, metadata, labeling data, etc.

[0223] In some embodiments, input data may be preprocessed. For example, preprocessing operations performed on the training dataset 210 may be repeated for at least a portion of input data 250. Input data 250 may include segmented data, data with anomalies or outliers removed, data with manipulated mesh data, or the like.

[0224] Input data is provided to treatment plan generator 268. Treatment plan generator 268 generates treatment plan data 270 (e.g., treatment protocol data 142 of FIG. 1, treatment plan data 164 of FIG. 1) based on the input data 250. In some embodiments, treatment plan generator 268 includes a single trained machine learning model. In some embodiments, treatment plan generator 268 includes a combination of multiple trained machine learning models. In some embodiments, treatment plan generator 268 includes multiple applications of input provided to a single trained Al model, e.g., an LLM may be provided various prompts including doctor input to perform multiple operations to facilitate generation of treatment plan data 270. In some embodiments, treatment plan generator 268 may include a combination of machine learning models and other models. For example, a combination of machine learning models and numerical optimization models may be included in treatment plan generator 268. In some embodiments, one or more sets of data may be generated based on protocol data, such as data for generating a treatment plan, data for generating manufacturing plans for one or more appliances for treatment, or the like. In some embodiments, a corrective action may be performed based on the treatment plan data 270. The corrective action may include providing an alert to a user, designing a treatment plan, updating a treatment plan, or the like.

[0225] Corrective actions may be associated with design of a treatment protocol, updating of a treatment protocol, providing an alert associated with a treatment protocol to a user, or the like.Corrective actions may be associated with design of a treatment plan, updating of a treatment plan, etc. Corrective actions may be associated with updates to manufacturing data for one or more treatment appliances, updates to manufacturing instructions (e.g., timing of manufacturing) for treatment appliances, etc. Actions performed by system 100 may include generating data for manufacturing of one or more treatment appliances, providing the design data for the treatment appliances to appliance manufacturing 121, manufacturing the appliances, etc.Attorney Docket No.: 28510.998 (L0773PCT)

[0226] Various other actions may be performed using a system similar to that depicted and described in connection with FIG. 2, with appropriate adjustments to categories of input data, training data, etc. In some embodiments, model application workflow 247 may include classification of natural language instructions into various categories. For example, some categories of instructions may be provided to a first system for further processing, some categories of instructions may be provided to a second system for further processing, etc. A classification model may take the place of treatment plan generator 268, and the treatment plan data 270 generated may be classification of treatment planning instructions to be used in further actions by the treatment planning system.

[0227] In some embodiments, prompt generation may be performed as part of model application workflow 247. For example, descriptions of a target task, related prompting strategies, design principles, examples, etc., may be provided as input data 250 to an Al model such as an LLM. The output treatment plan data 270 may include machine-generated prompts predicted to cause an Al model such as an LLM to perform the target task.

[0228] In some embodiments, generation of treatment plan data (e.g., including treatment protocols that express practitioner clinical preferences) may be generated based on a model that is not a machine-learning model, e.g., a rule-based model. For example, a set of options related to dental, orthodontic, or other treatments may be provided via a GUI to the practitioner. The healthcare practitioner may enter, via the GUI, preferences related to various categories of treatment. A model may be used to generate machine-readable instructions expressing a treatment protocol based on the preferences.

[0229] FIG. 3A is a diagram depicting a data flow 300Afor generation of a treatment plan and / or treatment protocol using an Al model, according to some embodiments. Generation of a treatment plan may include generation of a treatment protocol. For example, generation of a plan for a specific patient may be based on a general protocol for a particular type of disorder. Generation of a treatment plan may be based on one or more statements or instructions provided in natural language by a treatment provider, practitioner, doctor, or the like.

[0230] Flow 300A includes protocol statements 302. Protocol statements may be statements made by a practitioner, treatment provider, doctor, or the like with respect to treating one or more disorders. For example, a practitioner associated with orthodontic treatment may generate natural language instructions directed toward methods for treating a number of different disorders that they may regularly encounter, such as a preferred order of operations, a preferred movement or adjustment rate, a preferred technique in association with a target disorder, or the like. The protocol statements 302 may be in natural language and may be related to one or more target disorders, such as multiple dental or orthodontic disorders.Attorney Docket No.: 28510.998 (L0773PCT)

[0231] Protocol statements 302 may include a variety of different types of instructions, preferences, and / or directives. Protocol statements 302 may include dental feature instructions, which may specify placement, modification, or removal of attachments, precision cuts, bite ramps, power ridges, or other features applied to teeth or appliances during treatment. Dental feature instructions may specify attachment types such as optimized attachments (including mesial-distal root control attachments, multi-plane attachments, extrusion attachments, rotation attachments, retention attachments, or expansion support attachments), conventional attachments, or protocol-based attachments (such as G4, G5, G7, orG8 protocol attachments). Dental feature instructions may further specify attachment actions including adding attachments, removing existing attachments, keeping existing attachments, replacing existing attachments, modifying existing attachments, forbidding placement of attachments, or delaying placement of attachments. Dental feature instructions may also specify attachment parameters such as size (regular or largest), attachment configuration (single or dual), orientation (distal or mesial), and treatment stages at which attachments are to be placed or removed. Protocol statements 302 may include interproximal reduction (IPR) instructions, which may specify amounts of enamel to be removed between teeth, locations where IPR is to be performed, maximum IPR limits per contact (such as 0.2 mm, 0.3 mm, 0.4 mm, or 0.5 mm for anterior or posterior contacts), staging of IPR operations, and / or whether IPR is to be applied to upper arch, lower arch, or both arches. Protocol statements 302 may include tooth movement instructions, which may specify target positions for individual teeth or groups of teeth, movement sequences, movement rates, movement priorities, and / or constraints on tooth movement. Tooth movement instructions may address specific movement types such as rotation, torque, tip, intrusion, extrusion, translation, and / or root movement. Protocol statements 302 may include arch treatment instructions, which may specify which arches are to be treated (upper only, lower only, or both), coordination between upper and lower arch movements, and / or arch form preferences. Protocol statements 302 may include extraction instructions, which may identify specific teeth to be extracted, timing of extractions relative to treatment stages, and / or space closure protocols following extractions. Protocol statements 302 may include missing teeth instructions, which may identify teeth that are absent and specify how treatment planning should accommodate missing teeth. Protocol statements 302 may include malocclusion correction instructions, which may specify treatment approaches for different malocclusion classes (Class I, Class II, or Class III), treatment goals (such as molar and canine Class I relationships), distalization patterns, amounts of distalization, and / or priorities between molar and canine correction. Protocol statements 302 may include crowding resolution instructions, which may specify methods for resolving crowding such as expansion, IPR, proclination, or extraction, and may indicate preferences for specific teeth or arch regions. Protocol statements 302 may include spacing instructions, which may specify approaches forAttorney Docket No.: 28510.998 (L0773PCT)closing spaces, maintaining spaces, or distributing spaces, and may indicate whether spacing treatment should extend distal to canines or to other landmarks. Protocol statements 302 may include midline instructions, which may specify midline correction goals, methods for achieving midline correction (such as using IPR or tooth movement), and acceptable midline deviation tolerances. Protocol statements 302 may include anterior-posterior correction instructions, which may specify approaches for correcting anterior-posterior discrepancies, including distalization techniques (such as compact sequential distalization or improved sequential distalization), mesialization approaches, and use of elastics or other auxiliaries. Protocol statements 302 may include posterior crossbite instructions, which may specify methods for correcting posterior crossbites, expansion protocols, and coordination between upper and lower arch widths. Protocol statements 302 may include anterior correction instructions, which may address anterior open bite, anterior deep bite, or anterior crossbite correction approaches. Protocol statements 302 may include anterior leveling instructions, which may specify approaches for leveling the curve of Spee, intrusion or extrusion of anterior teeth, and / or coordination with posterior tooth positions. Protocol statements 302 may include overbite instructions, which may specify target overbite values, methods for correcting deep bite or open bite conditions, and use of bite ramps or other features. Protocol statements 302 may include aligner feature instructions, which may specify preferences for passive aligners, active aligners, overcorrection aligners, or retention aligners, and may indicate staging or sequencing of different aligner types. Protocol statements 302 may include overcorrection instructions, which may specify amounts of overcorrection (e.g., for space closure), tooth positions, or other treatment parameters. Protocol statements 302 may include staging instructions, which may specify the number of treatment stages, stage duration, sequencing of movements across stages, and coordination of different treatment operations across the treatment timeline. Protocol statements 302 may include pontic instructions, which may specify placement of pontics in edentulous spaces, pontic designs, and coordination with adjacent tooth movements. Protocol statements 302 may include treatment length instructions, which may specify target treatment duration, maximum number of aligners, or constraints on treatment timeline. Protocol statements 302 may include patient-specific instructions, which may address unique characteristics of individual patients such as teeth that are crowns, implants, or pontics that should not be moved, teeth with root resorption concerns, teeth with periodontal considerations, or other patient-specific factors that may affect treatment planning. Protocol statements 302 may include polite expressions or non-clinical comments, which may include greetings, expressions of gratitude, or other communications that do not contain clinical instructions but may be included in treatment provider communications.

[0232] Protocol statements 302 are provided to an Al model 304. The Al model 304 may be an NLP model, an LLM, or the like. The Al model 304 may be a general purpose model (e.g., a generalAttorney Docket No.: 28510.998 (L0773PCT)purpose LLM), specifically trained to perform operations related to protocol statements 302, fine-tuned to perform operations related to protocol statements 302, or the like. In some embodiments, additional data may be provided to Al model 304, e.g., via prompt engineering. For example, a prompt may instruct an LLM howto behave, what desired output is, or the like. A prompt may include one or more features of the following example: "you are an Al assistant that helps to convert text description into a C-like programming language for generating treatment protocols." Prompt engineering may further include a description of target settings or parameters (e.g., maximum response length, temperature, etc.). Prompt engineering may further include examples (e.g., few-shot examples, such as "user input: allow pontics placement with no mesial and distal spaces around them. Response: allow pontics(md_space: 0m)" or other examples which may assist the Al model in generating machine-readable instructions related to treatment protocols. Additional prompt examples may include action-related prompts such as: "user input: add optimized attachments to teeth 3, 4, and 5. Response: add_attachment(teeth: [3, 4, 5], type: optimized)"; "user input: remove existing attachments from upper anteriors. Response: remove_attachment(teeth: upper_anteriors, action: remove_existing)"; "user input: keep attachments on canines from previous treatment. Response: modify_attachment(teeth: canines, action: keep_existing)"; and "user input: delay attachment placement until stage 5. Response: schedule_attachment(stage: 5, action: delay_placement)". Prompt examples related to attachment types may include: "user input: add largest dual MDRC attachments to tooth 12. Response: add_attachment(teeth:

[0012] , type: optimized, specific_type: mesial_distal_root_control, size: largest, mdrc_type: dual)"; "user input: place rotation attachments on lower incisors. Response: add_attachment(teeth: lowerjncisors, type: optimized, specific_type: rotation)"; "user input: add extrusion attachments to premolars. Response: add_attachment(teeth: premolars, type: optimized, specific_type: extrusion)"; and "user input: use G4 protocol attachments on 1.2 and 1.3. Response: add_attachment(teeth: [1.2, 1.3], type: protocol, protocol: G4, specific_type: mesial_distal_root_control)". Prompt examples related to tooth numbering systems may include: "user input: extract UR4 and UL4. Response: extract(teeth: [UR4, UL4], numbering_system: palmer)"; "user input: no IPR on teeth 2.1 through 2.5. Response: forbid Jprfteeth: [2.1, 2.2, 2.3, 2.4, 2.5], numbering_system: fdi)"; and "user input: place attachments on 8, 9, 24, and 25. Response: add_attachment(teeth: [8, 9, 24, 25], numbering_system: universal)". Prompt examples related to interproximal reduction may include: "user input: limit IPR to 0.3mm per contact on anteriors.Response: limit_ipr(region: anteriors, amount: 0.3mm)"; "user input: schedule IPR at stage 10.Response: schedule Jpr(stage: 10)"; "user input: allow IPR only distal to canines. Response: allow_ipr(region: distal_to_canines)"; and "user input: no IPR on lower arch. Response: forbid Jpr(arch: lower)". Prompt examples related to treatment staging may include: "user input: start posteriorAttorney Docket No.: 28510.998 (L0773PCT)distalization before anterior movement. Response: set_staging(posterior_distalization: first, anteriorjriovement: after)"; "user input: add passive aligners atthe end of treatment. Response: add_aligners(type: passive, stage: final)"; and "user input: begin attachments at stage 3. Response: schedule_attachment(stage: 3, action: add)". Prompt examples related to tooth movement restrictions may include: "user input: do not move tooth 14, it is an implant. Response: restrict jriovement(teeth:

[0014] , reason: implant)"; "user input: teeth 18 and 19 are pontics, do not include in treatment. Response: excl ude_teeth (teeth: [18, 19], type: pontic)"; and "user input: limit movement on crowned teeth 30 and 31. Response: restrict jrovement(teeth: [30, 31], reason: crown)". Prompt examples related to malocclusion correction may include: "user input: achieve Class I molar relationship. Response: set_goal(type: molar_relationship, target: classj)"; "user input: correct anterior crossbite using elastics. Response: set_correction(type: anterior_crossbite, method: elastics)"; and "user input: distalize upper arch 4mm. Response: set_distalization(arch: upper, amount: 4mm)". Prompt examples related to spacing and crowding may include: "user input: close all spaces using IPR. Response: close_spaces(method: ipr)"; "user input: maintain 2mm space for future implant at site 19. Response: maintain_space(site: 19, amount: 2mm, reason: futurejmplant)"; and "user input: resolve crowding by expansion. Response: resolve_crowding(method: expansion)". Prompt examples related to overbite and overjet may include: "user input: reduce overbite to 2mm. Response: set_overbite(target: 2mm)"; "user input: correct deep bite using bite ramps. Response: correct_deepbite(method: bite_ramps)"; and "user input: reduce overjet by retracting upper anteriors. Response: reduce_overjet(method: retract_upper_anteriors)". Prompt examples related to midline correction may include: "user input: shift upper midline 1mm to the right. Response: adjust_midline(arch: upper, direction: right, amount: 1mm)"; and "user input: achieve coincident midlines using IPR on lower left. Response: adj ust_mi dl i ne(method : ipr, region: lowerjeft, goal: coincident)". Prompt examples related to polite or non-clinical expressions may include: "user input: thank you for your help. Response: polite_expression (action: none)"; and "user input: please proceed with the treatment. Response: polite_expression (action: confirm_proceed)". In some embodiments, multiple prompts related to protocol statements 302 may be provided to one or more Al models to perform various operations as a part of generating machine-readable instructions related to protocol statements 302.

[0233] Output of Al model 304 may include machine-readable instructions 306. Machine-readable instructions 306 may be based on treatment protocols, e.g., may be used to generate treatment plans for specific patients or disorders, may be based on general preferences or include instructions to generate a treatment plan when provided data related to a specific patient or disorder, or the like. In various embodiments, machine-readable instructions 306 may comprise sequences of commands, directives, parameters, or data structures that can be interpreted and executed by a computing device,Attorney Docket No.: 28510.998 (L0773PCT)treatment planning engine, or other processing component. Examples of machine-readable instructions include, but are not limited to, executable code segments, configuration files, structured data payloads, treatment parameter specifications, tooth movement directives, attachment placement instructions, interproximal reduction specifications, staging information, and treatment action commands such as add, remove, keep, replace, modify, delay placement, or forbid placement operations associated with dental features or treatment elements. In some embodiments, machine-readable instructions are or represent a treatment protocol.

[0234] In some embodiments, the machine-readable instructions 306 may be formatted according to a JSON schema. A JSON schema defines the structure, required properties, allowed values, data types, and relationships between different elements of the instructions, enabling validation and consistent interpretation across different system components. The JSON schema may constrain the output of Al models to ensure that generated instructions conform to expected formats and include only valid, supported operations. For example, a JSON schema may specify allowed values for attachment types, tooth numbering systems, treatment actions, stage specifications, and other treatment parameters, thereby ensuring robustness and correctness of the machine-readable instructions.

[0235] In some embodiments, machine-readable instructions 306 may be expressed in a protocol language designed for dental treatment planning. One such protocol language is SPICE-L (Special Instruction Conversion Engine Language), which is a machine-readable JSON format configured to structure free-form and varied instructions from treatment providers into a standardized format suitable for automatic generation of treatment plans. SPICE-L organizes orthodontic instructions into distinct categories, each representing a specific aspect of treatment planning, such as dental features, attachments, tooth movements, staging, and other treatment parameters. The format supports various methods of teeth representation, accommodating different numbering systems (e.g., Universal, Palmer, FDI) and descriptive approaches used by orthodontists. SPICE-L may include an extensible structure allowing for the addition of new categories or instruction types as orthodontic practices evolve. For instructions that do not fit into predefined categories, SPICE-L may include an "other instructions" category to ensure no information is lost. The system may interpret instructions contextually, understanding implied meanings and resolving ambiguities based on orthodontic best practices. Other protocol languages described herein may include IPL (Invisalign Planning Language), which may be designed to represent treatment provider preferences in a machine-readable form for consideration during treatment generation processes. Such protocol languages enable translation of natural language treatment instructions into structured formats that can be processed by treatment planning engines to generate treatment plans automatically.Attorney Docket No.: 28510.998 (L0773PCT)

[0236] Machine-readable instructions 306 may be provided to a treatment building engine 308. T reatment building engine 308 may be configured to determine treatment plan 310 based on machine-readable instructions (e.g., a treatment protocol) and data related to a specific patient or disorder. Treatment building engine 308 may be deterministic, e.g., based on machine-readable instructions 306 and a set of rules or commands, rather than being Al or ML-based, in some embodiments. T reatment building engine 308 may generate one or more treatment plans 310, which may be provided to a practitioner 312 for approval. Upon approval, the treatment plans 310 may be enacted, in some embodiments, e.g., data may be provided to a manufacturing facility to generate one or more appliances for treatment of a disorder. Upon practitioner 312 not accepting the treatment plan 310, additional protocol statements may be generated to adjust treatment protocols, adjust machine-readable instructions 306, adjust treatment plan 310, etc., until an acceptable treatment protocol is developed for generating treatment plans for treating patient disorders. In some embodiments, treatment building engine 308 corresponds to, includes, or is in communication with, a treatment planning system and / or treatment management system, such as ExoCAD or ClinCheck, offered by Align Technologies.

[0237] In embodiments, a chat interface may be provided to a user for development of a treatment plan and / or a treatment protocol. The chat interface may be an interface to one or more Al models (e.g., one ormore LLMs), and may enable a chat agent to interact with a practitioner to develop a dental treatment protocol and / or a dental treatment plan. The chat agent may be implemented as a conversational assistant that receives natural language input from the treatment provider and generates contextually appropriate responses, recommendations, or actions based on the input. The chat agent may utilize one or more LLMs as a foundation for understanding and generating natural language. LLMs are Al models trained on large corpora of text data that learn statistical patterns and relationships between words, phrases, and concepts. When a user provides input to the chat agent, the input text may be tokenized and processed by the LLM, which generates a probability distribution over possible next tokens or responses based on the input context and the model's learned parameters. The LLM may be configured with specific prompts, system instructions, or fine-tuning that constrain or guide its responses toward treatment planning tasks. The chat agent may maintain session context data comprising a history of prior exchanges between the treatment provider and the chat agent, enabling the LLM to generate responses that account for previous instructions, clarifications, and / or preferences expressed during the conversation. The chat agent may be configured to perform multiple functions, including answering questions about treatment options or clinical terminology, generating proposed modifications to treatment protocols ortreatment plans based on natural language requests, requesting clarification when instructions are ambiguous or incomplete, and providing explanations of proposedAttorney Docket No.: 28510.998 (L0773PCT)changes in human-readable format. Responses, explanations, and prompts generated by the chat agent may be presented in written form, verbal form via audio output or speech synthesis, sign language form via animated visual representation, or combinations thereof. The chat agent may be constrained to operate within predefined protocol rules, such that output generated by the underlying LLM is limited to modifications that are valid within a predefined set of protocol commands or treatment options. The chat agent may be provided with access to a library of protocol documentation, clinical explanations, or machine-implementable instructions via retrieval-augmented generation, enabling the chat agent to provide accurate and contextually relevant responses based on authoritative documentation rather than solely relying on the LLM's training data.

[0238] FIG. 3B depicts a graphical user interface 300B for providing a user experience for a practitioner for generating a treatment protocol using an Al model, according to some embodiments. Graphical user interface (GUI) 300B optionally includes a title section 314 and a chat section 316. In some embodiments, practitioner input may be provided in one or more sections, e.g., a text input field may be provided for a practitioner to input descriptions of preferences for a set of treatment types, a text input field may be provided for each treatment type (e.g., disorder type), or the like. In some embodiments, a chat function may be utilized for incorporating practitioner instructions into protocol instructions. In some embodiments, a data model including a number of fields may be generated. The fields may be filled via methods of the present disclosure to generate machine-readable instructions for treatment protocol generation, e.g., via Al translation of natural language input into machine-readable instructions.

[0239] In some embodiments, GUI 300B may be provided in a chat-like configuration, as depicted in FIG. 3B. In such a configuration, different chat elements may be presented for different tasks (e.g., determining protocol for IPR, as indicated in title section 314). In some embodiments, a chat element may be used to determine multiple treatment protocols (e.g., for multiple disorder types). A title element may still be used to assist a practitioner in accurately indicating correct instructions via the chat section 316. In some embodiments, a chat function such as that included in GUI 300B may be utilized as a means of obtaining doctor inputfor treatment protocol, obtaining Al model input from a practitioner, parsing Al output for generating machine-readable instructions, for filling fields of a data model directed at generating treatment protocol instructions (e.g., a data model may include a number of fields, and a chat function may operate along with one or more Al models to generate prompts and obtain practitioner responses until all fields, target fields, or the like of the data model are filled), or the like.

[0240] In some embodiments, GUI 300B may provide machine readable instructions to a practitioner, as indicated in FIG. 3B. In some embodiments, GUI 300B may additionally or alternatively provide the machine-readable instructions to a treatment planning platform (e.g., treatment buildingAttorney Docket No.: 28510.998 (L0773PCT)engine 308 of FIG. 3A), optionally without providing the machine-readable instructions to the practitioner.

[0241] FIG. 3C is a block diagram of a flow 300C for obtaining practitioner instructions via a chat function, according to some embodiments. Flow 300C depicts an example flow of data for generating machine-readable protocol instructions, e.g., via an LLM and a chat function presented to a practitioner by a GUI. Practitioner 330 may provide an instruction 320. Instruction 320 may be or include a description of a treatment protocol, a correction to an existing treatment protocol, or the like. Instruction 320 may be provided based on a prompt, question, or field presented to the practitioner. Instruction 320 may be in natural language.

[0242] In some embodiments, instruction 320 may be provided to Al model 322, e.g., an LLM. Al model 322 may be configured (e.g., by training, by prompt engineering, or the like) to generate machine-readable instruction 324 based on the input instruction 320. The machine-readable instructions 324 may be a treatment protocol in some embodiments.

[0243] Machine-readable instruction 324 generated by Al model 322 may be provided to validation generator 326. Validation generator 326 may generate one or more validation prompts 328 based on the machine-readable instructions 324. Validation generator 326 may provide a natural language description of an addition or update to the treatment protocol associated with instruction 320. Validation generator 326 may be a deterministic model, e.g., may be rule-based to generate a description of code related to treatment protocol. A validation prompt 328 may comprise a human-readable summary or explanation of the operations encoded in the machine-readable instruction 324, enabling a user to verify that the Al model 322 correctly interpreted the original natural language instruction 320. The validation prompt 328 may describe specific treatment parameters, tooth identifiers, treatment stages, or other clinical details extracted from the instruction 320 and encoded in the machine-readable instruction 324. The validation prompt 328 may be output along with the machine-readable instruction 324 for concurrent review, or may be output separately for sequential verification. In some embodiments, the validation prompt 328 may be output via a graphical user interface, such as within a chat interface or a dedicated validation panel, allowing the user 330 to confirm accuracy or provide corrections before the machine-readable instruction 324 is applied to treatment planning operations.

[0244] Validation prompt 328 may be provided to practitioner 330 to obtain a validation response. The validation response may comprise an indication from the practitioner 330 confirming or rejecting the proposed machine-readable instruction 324. The validation response may include an affirmative response indicating that the machine-readable instruction 324 correctly captures the intent of the original natural language instruction 320, a negative response indicating that the machine-readableAttorney Docket No.: 28510.998 (L0773PCT)instruction 324 does not accurately reflect the practitioner's intent, a modification request specifying adjustments to be made to the machine-readable instruction 324, or a clarification providing additional context or details to refine the instruction. The validation response may be provided via the chat interface, through selection of confirmation or rejection options presented in a GUI, or through free-text entry allowing the practitioner 330 to elaborate on desired changes. The validation prompt 328 may be presented in written form, verbal form via audio output or speech synthesis, sign language form via animated visual display, or combinations thereof. The validation response may be utilized as instruction 320 to further update the protocol, update the machine-readable instruction 324, or the like. For example, an affirmative validation response may cause the machine-readable instruction 324 to be enacted, included in the protocol, added to the data model, or the like, and a further field to be investigated by the chat function. A negative validation response may cause the Al model to generate further updates, to provide a prompt to practitioner 330 for clarification, to present alternative interpretations of the original instruction 320, or to request additional information to resolve ambiguities in the treatment protocol specification.

[0245] As an example, a practitioner 330 may choose to update a treatment protocol using a chat function. The practitioner 330 may provide as instruction 320 a target update in natural language related to a treatment protocol, for example, an instruction to not place attachments on target teeth for an orthodontic treatment. The Al model may generate an update or command based on the instruction, for example, a command to disable attachments on target teeth. The response generator may, based on the machine-readable command, generate a validation prompt in natural language which may be provided to the practitioner for validation. For example, in response to a machine-readable command to not use attachments on target teeth, a validation prompt such as “did you mean to disable attachments on all second molars?” may be provided to the practitioner. The practitioner may determine whether the description of the proposed addition to the protocol is appropriate, respond accordingly, and continue exchanging messages with the chat function until a target set of data has been obtained (e.g., until target fields of a data model related to treatment protocols have been filled and validated).

[0246] FIG. 3D is a block diagram of a data flow 300D for generating machine-readable instructions based on practitioner natural language instructions, according to some embodiments. In some embodiments, one or more operations depicted in FIG. 3D may not be utilized, multiple operations may be combined, etc. In some embodiments, one or more operations of flow 300D may be performed by purpose-trained Al models, multiple operations may be performed by the same model (e.g., an LLM configured to perform multiple different operations by prompt engineering), one or more operations may be performed by a general purpose LLM that is provided sufficient context (e.g., prompt) to perform the operations, or the like.Attorney Docket No.: 28510.998 (L0773PCT)

[0247] Instructions 340 are provided to an Al model. The instructions 340 may be doctor or practitioner instructions related to a treatment protocol, presented in natural language. In some embodiments, the instructions may be entered via a GUI, via a text entry field, via a chat function, via a data model, or the like. Instructions 340 may be provided to paragraph splitter 342, which may be or include an Al model (e.g., LLM). In some embodiments, paragraph splitter 342, text formatter 344, title detector 346, transformer(s) 348, default detector 350, clinical checker 354, and / or other operative functions may be performed by one or more agents that provide input to an Al model (e.g., LLM) and obtains output from the Al model for further operations. In some embodiments, e.g., if multiple protocols are expected to be included in instructions 340, instructions 340 may be provided to paragraph splitter 342. The paragraph splitter 342 may analyze the natural language instructions to identify logical boundaries between distinct topics, treatment categories, and / or clinical directives. The paragraph splitter 342 may utilize semantic analysis to detect transitions between different subject matters within the instructions, such as identifying when a practitioner's notes shift from discussing one dental condition to another, one tooth or set of teeth to another, and so on. In some embodiments, the paragraph splitter 342 may identify section boundaries based on linguistic cues including transitional phrases, changes in referenced anatomical structures (e.g., shifting from upper arch to lower arch discussions), changes in treatment modalities (e.g., from attachment placement to interproximal reduction), or explicit section headers or numbering provided by the practitioner. The paragraph splitter 342 may be configured via prompt engineering to recognize domain-specific patterns in orthodontic or dental instructions, such as identifying when instructions transition between different malocclusion types, different treatment phases, or different patient populations (e.g., adult versus teen cases). In some embodiments, the paragraph splitter 342 may output structured data indicating the boundaries of each identified section along with preliminary categorization information that assists downstream processing components. Sections of the input data may be separated into topics, e.g., based on prompt engineering and provided natural language instructions. In some embodiments, each section may be associated with a disorder, e.g., one section for deep bite correction, one for open bite correction, etc. Each section (e.g., paragraph) may be processed separately for subsequent operations, e.g., to generate a protocol for each disorder separated by the paragraph splitter 342.

[0248] Input is provided to text formatter 344. Input may include one section separated by paragraph splitter 342, as well as prompt engineering input configured for an LLM to perform target operations. Input to each module (e.g., by an agent for interfacing with an LLM) of flow 300D may include prompt engineering to configure an LLM to perform target operations. Text formatter 344 may be configured to improve text processability, e.g., by resolving abbreviations, attempting to resolve typographical errors, unifying units, scale, indexing, or other metrics, etc.Attorney Docket No.: 28510.998 (L0773PCT)

[0249] In some embodiments, text formatter 344 performs normalization operations on dental terminology and tooth numbering systems. Treatment providers may express tooth identifiers using different numbering conventions, such as Universal Numbering System (UNS), Palmer notation, or Federation dentaire internationale (FDI) notation. Text formatter 344 may be configured to detect which numbering system is being used in the input text and normalize tooth references to a standardized format for downstream processing. For example, a treatment provider instruction referencing "tooth #3" in Universal notation, "UR6" in Palmer notation, or "1.6" in FDI notation may all refer to the same tooth, and text formatter 344 may convert these references to a unified representation. Text formatter 344 may also resolve variations in dental terminology, such as recognizing that"MDRC," "mesial distal root control," and "root control attachment" refer to the same type of optimized attachment. Additionally, text formatter 344 may handle variations in how treatment providers express attachment-related terms, including misspellings, abbreviations such as "att" for "attachment," or colloquial expressions commonly used in clinical practice.

[0250] Text formatter 344 may further be configured to handle multilingual input and standardize formatting conventions across different languages. In some embodiments, treatment provider instructions may be provided in languages other than English, and text formatter 344 may translate or transliterate such instructions to a standardized language format for subsequent processing by downstream components. Text formatter 344 may also normalize stage references and temporal expressions used by treatment providers. For example, instructions may reference treatment stages using various formats such as literal stage numbers (e.g., "stage 5"), relative references (e.g., "first stage," "last stage," "final aligner"), or offset expressions (e.g., "3 stages before the end"). Text formatter 344 may convert these varied expressions into a consistent machine-readable format.Furthermore, text formatter 344 may identify and separate polite expressions, greetings, or other non-clinical content from substantive treatment instructions, flagging such content for exclusion from clinical processing while preserving the clinically relevant portions of the input for further analysis by subsequent components in flow 300D.

[0251] Input may be provided to title detector 346. Title detector 346 may be configured to predict a topic of input text, e.g., a topic of a section split by paragraph splitter 342. Title detector 346 may generate an understanding of a disorder or topic of a paragraph or section of input text. Detecting and applying a topic title may improve performance of further operations of flow 300D for generating protocol data 360.

[0252] In some embodiments, title detector 346 may be implemented as an Al model, such as an LLM, configured to analyze the semantic content of input text and assign appropriate category labels or topic identifiers. Title detector 346 may identify key concepts, dental conditions, treatment categories,Attorney Docket No.: 28510.998 (L0773PCT)malocclusion types, or other clinically relevant subject matter associated with a section of treatment provider instructions. For example, title detector 346 may determine that a particular section of input text relates to interproximal reduction (IPR) parameters, attachment placement preferences, spacing treatment goals, overbite correction, or anterior-posterior correction. The identified title or topic may be used to route the section to an appropriate transformer 348 or other downstream processing component that is specialized for handling instructions of that particular category. Title detector 346 may utilize pattern recognition, keyword analysis, contextual understanding, or combinations thereof to accurately classify input text sections.

[0253] Title detector 346 may be configured to handle ambiguous or multi-topic sections of input text. In some cases, a section of treatment provider instructions may relate to multiple treatment categories or may include instructions that span different aspects of dental treatment. Title detector 346 may assign multiple topic labels to such sections, or may flag sections for further analysis when the topic cannot be determined with sufficient confidence. In some embodiments, title detector 346 may generate confidence scores associated with topic predictions, enabling downstream components to handle low-confidence predictions differently than high-confidence predictions. Title detector 346 may also be configured to identify sections that do not correspond to any predefined treatment category, which may indicate novel instruction types, non-clinical content, or instructions requiring manual review. The output of title detector 346 may include structured metadata that accompanies the input text through subsequent processing stages, enabling transformer 348 and other components to leverage the topic information when generating machine-readable instructions.

[0254] Input may be provided to one or more transformers 348. Transformer(s) 348 may include multiple transformers, multiple Al models, multiple iterations of providing input data and / or prompt engineering input to an LLM, etc. In some embodiments, different transformers included in transformer(s) 348 may be configured to be applied to different topics, e.g., attachments or other categories of commands. T ransformers 348 may be configured to transform one or more natural language instructions to machine-readable instructions, e.g., of a proprietary language related to a treatment planning software. Different transformers may be configured to enable transformation of different types of instructions. In some embodiments, an updated instruction may be generated based on removing statements from the provided instructions associated with machine-readable instructions generated by the one or more transformers 348.

[0255] The output of transformer(s) 348 may include machine-readable instructions structured in a standardized format, such as a JSON schema or other text-based schema. The structured output may organize orthodontic instructions into distinct categories, each representing a specific aspect of treatment planning. For example, the output may include fields specifying an action to be performedAttorney Docket No.: 28510.998 (L0773PCT)(e.g., add, remove, keep, replace, modify, forbid placement, or delay placement), teeth identifiers indicating which teeth are affected by the action, attachment types specifying the type of dental feature to be applied, treatment stages at which the action is to be performed, and additional parameters such as attachment size, position, or orientation. The output format may support various methods of teeth representation, accommodating different numbering systems such as Universal, Palmer, and FDI numbering systems used by orthodontists. A standardized schema may define the structure, allowed values, and relationships between different elements of the format, constraining the transformer output to only include modifications that are valid within a predefined set of protocol commands.

[0256] In some embodiments, transformer(s) 348 may be configured to extract specific parameters from natural language instructions based on the category of instruction being processed. For attachment-related instructions, the transformer may extract attachment type information including general types (e.g., optimized attachments, conventional attachments, protocol attachments) and specific types (e.g., mesial distal root control, multi-plane, extrusion, rotation, retention, or expansion support attachments). The transformer may further extract optional parameters such as attachment size (e.g., regular or largest), attachment configuration (e.g., single or dual for root control attachments), and directional information (e.g., distal, mesial, horizontal, or vertical). For instructions that do not fit into predefined categories, the transformer output may include an "other instructions" category to ensure no information is lost during the transformation process. The transformer may interpret instructions contextually, understanding implied meanings and resolving ambiguities based on orthodontic best practices. The output structure may be extensible, allowing for the addition of new categories or instruction types as orthodontic practices evolve or as additional treatment parameters are supported by the treatment planning system.

[0257] In some embodiments, different transformers may be configured to handle different types of treatment planning operations or parameters. Each transformer may be specialized to process a particular category of natural language instructions and generate corresponding machine-readable instructions optimized forthat category. The system may include multiple transformers operating in parallel or in sequence, with each transformer receiving instructions that have been classified as belonging to its designated category. The transformers may include an attachment transformer configured to process instructions related to dental attachments, including placement, removal, modification, and configuration of optimized attachments, conventional attachments, and protocolbased attachments such as G4, G5, G7, and G8 protocol attachments. The transformers may further include an interproximal reduction (IPR) transformer configured to process instructions related to IPR operations, including IPR amounts, locations, timing, and scheduling across treatment stages. The transformers may include a tooth movement transformer configured to process instructions related toAttorney Docket No.: 28510.998 (L0773PCT)tooth repositioning, including translation, rotation, torque, tip, intrusion, extrusion, and other movement parameters. The transformers may include a staging transformer configured to process instructions related to treatment staging, including stage sequencing, passive aligners, active aligners, and timing of treatment operations across stages. The transformers may include an extraction transformer configured to process instructions related to tooth extractions, including identification of teeth to be extracted and timing of extractions relative to treatment stages. The transformers may include a spacing transformer configured to process instructions related to space management, including space closure, space maintenance, and distribution of spacing across the dental arch. The transformers may include a midline transformer configured to process instructions related to midline correction, including midline goals, correction methods, and prioritization of upper versus lower midline alignment. The transformers may include an anterior-posterior correction transformer configured to process instructions related to Class II and Class III malocclusion correction, including distalization, mesialization, and bite correction parameters. The transformers may include an overbite transformer configured to process instructions related to overbite and deep bite correction, including intrusion and extrusion parameters for anterior teeth. The transformers may include a crossbite transformer configured to process instructions related to posterior crossbite correction, including expansion and constriction parameters. The transformers may include a crowding transformer configured to process instructions related to crowding resolution, including methods for gaining space such as expansion, procli nation, IPR, and extraction. The transformers may include an overcorrection transformer configured to process instructions related to overcorrection parameters for various tooth movements to account for relapse tendencies. The transformers may include a precision cuts transformer configured to process instructions related to precision cuts in aligners, including cut locations and configurations. The transformers may include a bite ramps transformer configured to process instructions related to bite ramp placement and configuration. The transformers may include a power ridge transformer configured to process instructions related to power ridge features in aligners. The transformers may include a finishing transformer configured to process instructions related to treatment finishing, including final tooth positions and refinement parameters.

[0258] In some embodiments, the different transformers may be implemented as distinct specially trained Al models, such as distinct large language models (LLMs) that have been fine-tuned or trained specifically for their designated category of instructions. Each specially trained Al model may be trained on a dataset comprising natural language instructions within its designated category paired with corresponding machine-readable instructions, enabling the model to learn the specific vocabulary, patterns, and output formats associated with that category. For example, an attachment transformer may be implemented as an LLM that has been fine-tuned on a dataset of attachment-relatedAttorney Docket No.: 28510.998 (L0773PCT)instructions and corresponding JSON-formatted attachment specifications, while a staging transformer may be implemented as a separate LLM that has been fine-tuned on staging-related instructions and corresponding stage configuration outputs. The specially trained Al models may be smaller, more efficient models that are optimized for their specific tasks, enabling faster inference and reduced computational requirements compared to general-purpose models. In some embodiments, the specially trained Al models may be based on architectures such as encoder-decoder models, text-to-text models, or other transformer-based architectures that are well-suited for the task of converting natural language to structured output formats.

[0259] In some embodiments, the different transformers may be implemented using one or more general-purpose Al models, such as one or more LLMs, that are provided with different specialized prompts to configure their behavior for different categories of instructions. Each specialized prompt may include a system message or instruction set that defines the task, specifies the expected input format, describes the target output schema, provides examples of input-output pairs, and includes rules for handling edge cases and ambiguities specific to that category. For example, an attachment transformer may be implemented by providing a general-purpose LLM with a specialized attachment prompt that describes the types of attachment actions (add, remove, keep, replace, modify, forbid placement, delay placement), the attachment type taxonomy (optimized attachments, conventional attachments, protocol attachments), the specific attachment subtypes (mesial distal root control, multi-plane, extrusion, rotation, retention, expansion support), and the expected JSON output schema for attachment instructions. Similarly, an IPR transformer may be implemented by providing the same ora different general-purpose LLM with a specialized IPR prompt that describes IPR parameters, scheduling options, and the expected output format for IPR instructions. The specialized prompts may be developed through iterative refinement processes, where initial prompts are tested against representative datasets and refined based on analysis of false positives, false negatives, and edge cases.

[0260] In some embodiments, the different transformers may be implemented using one or more Al models that are provided with different specialized context or access to specific information via retrieval-augmented generation (RAG) or similar techniques. Each transformer may be configured to retrieve and incorporate relevant documentation, reference materials, or domain-specific knowledge bases when processing instructions within its designated category. For example, an attachment transformer may be provided with access to a library of attachment specifications, including detailed descriptions of each attachment type, clinical indications for each attachment, placement guidelines, and examples of properly formatted attachment instructions. A staging transformer may be provided with access to staging guidelines, movement rate limits, and sequencing rules that inform how treatment stages should be configured. A protocol transformer may be provided with access to protocolAttorney Docket No.: 28510.998 (L0773PCT)documentation describing the specific requirements and constraints of various treatment protocols, such as G4, G5, G7, and G8 protocols, including which teeth are eligible for each protocol and what attachment configurations are required. The RAG-based approach may enable transformers to access up-to-date information without requiring retraining, as the retrieved documentation can be updated independently of the underlying Al model. The retrieved context may be incorporated into the prompt provided to the Al model, enabling the model to generate outputs that are consistent with the retrieved documentation and constrained to valid options defined in the documentation. In some embodiments, the Al model may be configured to limit its output to instructions and parameters that are explicitly defined in the retrieved documentation, preventing the generation of invalid or unsupported instructions.

[0261] In some embodiments, input may be provided to default detector 350. Inputto default detector 350 may include natural language input. Default detector 350 may be configured to identify statements that do not correspond to or require machine-readable equivalents. In some embodiments, only a portion of input may be provided to default detector 350, e.g., only inputs that are not associated with machine-readable statements that were generated by transformer 348. In some embodiments, additional input statements may be provided (e.g., all input) and tracking may be applied to determine whether every statement was either flagged as a default (e.g., not relevant to machine-readable protocol instruction) or transformed to an instruction. For example, a practitioner may provide a statement that is not clinically relevant (e.g., a “thank you” statement), or a statement that has clinical relevance but is not relevant for machine-readable protocol instructions (e.g., attachments for orthodontic care may be automatically included based on various other commands, a statement by a practitioner such as “add attachments as necessary” may be disregarded by default detector 350). If any statements are not accounted for (e.g., either transformed to machine-readable format or identified by default detector as not relevant to machine-readable instructions), further operations may be performed, e.g., the statements may be provided to an LLM configured to generate a prompt asking a practitioner for clarity, the statements may be provided to a sequence of LLM operations to attempt to generate machine-readable instructions again, the entire instruction 340 may be reprocessed, a fault or error may be indicated, or the like.

[0262] Output of one or more Al models (e.g., title detector 346, transformer(s) 348, and / or default detector 350) may be provided to instruction collector 352. Instruction collector 352 may be configured to collect and / or arrange instructions from various sources to generate a treatment protocol associated with a particular topic or set of topics, e.g., labeled in accordance with output of title detector 346.

[0263] Output of instruction collector 352 may be provided for one or more checks. Checkers may determine whether the instructions correlate to the input instructions (e.g., an LLM may be providedAttorney Docket No.: 28510.998 (L0773PCT)with a promptto predict whether the machine-readable instructions are an accurate representation of the natural language instructions they are based on). Checkers may determine if the code is compilable. Clinical checker 354 may be or include an Al model. Clinical checker 354 may increase reliability of the process by configuring an LLM to predict whether the instructions provided by instruction collector 352 correspond to the instructions 340. Clinical checker 354 may further ensure that various safety provisions are adhered to, e.g., maximum safe treatment times, distances, procedures, or the like.

[0264] Clinical checker 354 may perform semantic validation to verify that the machine-readable instructions accurately capture the clinical intent expressed in the original natural language instructions. In some embodiments, clinical checker 354 may receive both the original natural language instructions 340 and the corresponding machine-readable instructions generated by transformer(s) 348, and may utilize an Al model to assess whether the machine-readable instructions faithfully represent the treatment provider's intent. Clinical checker 354 may identify discrepancies between the natural language input and the generated machine-readable output, such as incorrect tooth identifications, misinterpreted treatment actions, or omitted instructions. In some embodiments, clinical checker 354 may generate a confidence score indicating the likelihood that the machine-readable instructions correctly represent the natural language instructions. Instructions that fall below a confidence threshold may be flagged for manual review or may be routed to manual treatment planning 418. Clinical checker 354 may further validate that the generated instructions are compatible with the treatment planning engine and conform to expected schemas or formats required for downstream processing.

[0265] Clinical checker 354 may apply a set of clinical safety heuristics to the machine-readable instructions to ensure that proposed treatment operations do not violate established clinical guidelines or safety constraints. The clinical safety heuristics may include constraints related to maximum tooth movement distances pertreatment stage, maximum interproximal reduction amounts per contact, restrictions on attachment placement for certain tooth types, and limitations on treatment duration. Clinical checker 354 may access clinical data 146 to retrieve applicable safety thresholds and treatment constraints. In some embodiments, clinical checker 354 may determine whether proposed attachment placements are appropriate for the specified teeth, such as verifying that protocol-based attachments are applied only to eligible tooth types (e.g., G4 protocol attachments applied only to canines or incisors, G5 protocol attachments applied only to premolars). Clinical checker 354 may further validate that treatment actions specified in the machine-readable instructions are supported by the treatment planning system and that all required parameters are present and within acceptable ranges.Instructions that fail clinical validation may be rejected, flagged for review, or routed to manual treatment planning for resolution by a trained technician.Attorney Docket No.: 28510.998 (L0773PCT)

[0266] Syntax checker 356 may be used to determine that machine-readable instructions are formatted correctly, may determine that the instructions are compilable, may recommend one or more updates based on predicted target instructions, or the like. The syntax checker 356 may validate that the machine-readable instructions conform to a predefined schema or grammar associated with the treatment planning system. The syntax checker 356 may parse the machine-readable instructions to identify structural errors, missing required fields, invalid parameter values, or malformed expressions. In some embodiments, the syntax checker 356 may compare the machine-readable instructions against a library of valid instruction formats and flag any instructions that do not match expected patterns. The syntax checker 356 may verify that tooth identifiers conform to supported numbering systems, that stage references are within valid ranges, that attachment types correspond to recognized categories, and that action keywords match predefined operations such as add, remove, keep, replace, or modify. The syntax checker 356 may also perform type checking to ensure that parameter values are of expected data types, such as verifying that numerical values are provided where numbers are expected and that string values conform to enumerated options. In some embodiments, the syntax checker 356 may attempt to automatically correct minor syntax errors, such as normalizing terminology variations or correcting common misspellings of attachment-related terms. The syntax checker 356 may generate error reports identifying specific locations and types of syntax violations, enabling targeted correction of the machine-readable instructions before they are provided to subsequent processing stages such as the compiler 358.

[0267] After various checks, the machine-readable instructions may be provided to compiler 358 to compile code based on the machine-readable instructions. The compiler 358 processes the validated machine-readable instructions and transforms them into executable protocol code. In some embodiments, the compiler 358 may perform additional optimization operations on the machine-readable instructions, such as consolidating redundant instructions, ordering instructions for efficient execution, or resolving dependencies between different instruction components. The compiler 358 may generate treatment protocol code in a format compatible with a treatment building engine or treatment planning system. In some embodiments, the compiler 358 may generate code in a domain-specific language designed for orthodontic treatment planning operations. The compiler 358 may further perform linking operations to integrate the compiled instructions with existing treatment protocol libraries or frameworks. In some embodiments, the output of the compiler 358 is protocol data 360, which may be used for generating treatment plans based on practitioner instructions 340. The protocol data 360 may include compiled treatment algorithms, parameter configurations, and / or execution sequences that can be applied to patient-specific dental data to generate customized treatment plans.Attorney Docket No.: 28510.998 (L0773PCT)In some embodiments, the output of compiler 358 is a treatment algorithm or executable treatment plan, or portion thereof.

[0268] FIG. 3E is a block diagram of a data flow 300E for utilizing a GUI-based system for converting practitioner preferences into machine-readable treatment protocols, according to some embodiments. At the beginning of data flow 300E, treatment option form 362 is provided to a practitioner. Treatment option form 362 may be provided on a provider's device, e.g., via a GUI.Treatment option form 362 may include a plurality of treatment categories, each associated with one or more selectable options. For example, treatment option form 362 may include categories such as interproximal reduction (IPR), arch to treat, missing teeth, extractions, malocclusion correction, crowding, spacing, midline, anterior-posterior correction, posterior crossbite, anterior correction, anterior leveling, overbite, aligner features, overcorrection for space closure, passive / active aligners, attachments, precision cuts, bite ramps, and / or power ridge features. Within each category, treatment option form 362 may present specific options for selection by the practitioner. For example, an IPR category may include options to limit anterior IPR per contact with selectable values such as 0.5 mm, 0.4 mm, 0.3 mm, or 0.2 mm, as well as options to limit posterior IPR per contact with similar selectable values. T reatment option form 362 may further include options for scheduling IPR at specific stages, such as based on access to contacts, every certain number of stages, or at specific stages specified by the practitioner. Treatment options may be presented via various GUI elements including drop-down menus, tillable fields, check boxes, radio buttons, sliders, and / or text entry areas. The practitioner may interact with treatment option form 362 by clicking on selectable elements, entering values into text fields, selecting options from drop-down menus, and / or toggling check boxes to indicate preferences. In some embodiments, treatment option form 362 may include a dental arch diagram that allows the practitioner to select specific teeth or segments of the dental arch where particular treatment operations are to be applied or restricted. Treatment option form 362 may further include a button or option to reset settings to default values, such as a "use align defaults" button. In some embodiments, treatment option form 362 may include tabs for different case types, such as primary orders and additional aligners, allowing the practitioner to configure preferences for different treatment scenarios. In some embodiments, treatment option form 362 may be accessed via a web browser, and operations related to doctor instruction collection, treatment protocol generation, etc., may be performed by a server device accessed by the practitioner via the internet. In some embodiments, various operations including doctor preference collection and machine-readable protocol generation may be performed locally.

[0269] In some embodiments, treatment categories may be divided based on patient age groups. For example, treatment options may be divided between adult patients and teen patients, with different treatment options or parameters available for each age group. In some cases, if no division is specifiedAttorney Docket No.: 28510.998 (L0773PCT)for a particular treatment category, the options may apply to both adult and teen age groups. The agebased division may enable treatment providers to specify different clinical preferences for patients of different ages, reflecting differences in treatment approaches, tooth movement rates, compliance expectations, or other age-related factors.

[0270] In some embodiments, treatment categories may be further divided based on malocclusion classification. For example, options for anterior-posterior correction may be divided between Class II malocclusion and Class III malocclusion, with similar but distinct treatment options available for each class. The treatment trees for Class II and Class III malocclusions may include overlapping options but may differ in specific parameters, treatment sequences, or available treatment goals based on the clinical characteristics of each malocclusion class.

[0271] In some embodiments, treatment categories provided may include specific options for interproximal reduction (IPR). IPR options may include selection of jaw sections where IPR is allowed, such as anterior segments, posterior segments, or specific inter-tooth intervals. IPR options may include per-contact limits specifying maximum IPR amounts, such as 0.2 mm, 0.3 mm, 0.4 mm, or 0.5 mm per contact. IPR options may include stage scheduling options specifying when IPR should be performed, such as based on access to contacts, at specific stages, or at regular intervals every certain number of stages.

[0272] In some embodiments, treatment categories may include options for managing spacing and tooth size discrepancy. Spacing options may include equal spacing distribution, spacing concentrated around lateral incisors, spacing distal to canines, or spacing distal to lateral incisors. These options may enable treatment providers to specify how residual spaces should be distributed when tooth size discrepancies exist.

[0273] In some embodiments, treatment categories may include options for managing crowding. Crowding options may include arch expansion limits between specific teeth, such as limiting expansion between upper first molars to a specified measurement in millimeters. These limits may constrain the treatment planning algorithm to avoid excessive arch expansion while resolving crowding.

[0274] In some embodiments, treatment categories may include options for overbite correction. Overbite options may be divided between anterior open bite cases and deep bite cases. For open bite cases, options may include selection of a target final overbite value and selection of treatment approach such as extrusion of anterior teeth, intrusion of posterior teeth, or combinations thereof. For deep bite cases, similar options may be provided with intrusion of anterior teeth as an additional or alternative approach. The treatment provider may select the desired final overbite measurement and the biomechanical approach to achieve that outcome.Attorney Docket No.: 28510.998 (L0773PCT)

[0275] In some embodiments, treatment categories may include options for anterior leveling. Anterior leveling options may relate to vertical control of anterior teeth, enabling treatment providers to specify preferences for how anterior teeth should be vertically positioned relative to one another during treatment.

[0276] In some embodiments, treatment categories may include options for distalization patterns in anterior-posterior correction. Distalization pattern options may include compact sequential distalization, improved sequential distalization, and ordinary distalization, each representing different approaches to moving posterior teeth distally. The GUI may provide explanations of what each distalization pattern means and how they differ from one another. The treatment provider may select an amountof distalization within an allowed range, such as a specific number of millimeters. Additional options may include whether to start anterior teeth movement at the same time as posterior distalization or to perform these movements sequentially. Priority options may also be provided for cases where both molar and canine correction cannot be fully achieved, allowing the treatment provider to specify which should be prioritized.

[0277] Option selection 364 may include a practitioner utilizing treatment option form 362 to input their preferences, protocols, etc., via a GUI. Option selection 364 may include options related to various types of treatments (e.g., different dental disorders, different categories of malocclusions or other conditions, etc.). Option selection 364 may include providing selection of different categories that may apply to several different treatments. For example, a practitioner’s preferences on timing of interproximal reduction (removing enamel from between teeth to create more space) may be applied to many different conditions and treatments.

[0278] Option selection 364 may include obtaining selections of practitioner preferences within one or more treatment categories, treatment preference categories, etc. Option selection 364 may include obtaining various options based on conditions, condition severity, presence of interrelated conditions, etc. Option selection 364 may include different flows for different treatment goals. For example, option selection 364 may provide a different set of treatment preference selections based on a patients desired outcome, such as a dental patient desiring realignment of their front teeth (e.g., the “social six”), a dental patient desiring improved chewing or bite alignment, or the like. Option selection 364 may include a branching tree of options that may be provided, e.g., selection of one option may open or close additional sets of selectable options. Option selection 364 may present a user (e.g., a treatment provider) with a curated, pre-selected list of choices. The practitioner may select from between the options via the GUI, using any input method of relevance to that option, including a dropdown menu, checkbox, radio buttons, selectable icons indicating shape or positions of effected teeth,Attorney Docket No.: 28510.998 (L0773PCT)etc. Additional information with respect to treatment option form 362 and option selection 364 may be found in the discussion in connection with FIG. 3F.

[0279] After doctor preferences have been collected, the preferences may be provided to protocol generation model 366. Protocol generation model 366 may be configured to generate machine-readable protocol instructions based on the practitioner preferences provided in option selection 364. The protocol generation model 366 may be a deterministic model, e.g., for a given set of options selected it may always output the same instructions. The protocol generation model 366 may be a rulebased model, configured to output machine-readable protocol instructions by following a set of instructions that convert practitioner preferences into instructions that express those preferences, and can be executed to generate treatment plans and facilitate treatment that is aligned with the practitioner preferences.

[0280] Output of protocol generation model 366 may be provided for protocol review 368. In some embodiments, code (e.g., machine-readable instructions) may be provided via the GUI. The practitioner may review the code. In some embodiments, multiple versions may be accessible. For example, versions of the machine-readable code based on settings selected by the practitioner before and after a change may be made available for review.

[0281] The practitioner may publish protocol 370, e.g., based on confirming via review that the protocol was generated as expected based on the practitioner preferences. Publishing of the protocol may include posting the protocol to be applied to all future patients of the practitioner, reevaluating treatment plans associated with current patients of the practitioner in view of the new protocol, or the like. In some embodiments, treatment planning operations may be accessed via the same application or portal as the protocol generation. For example, a web browser portal may include a section dedicated to treatment option form 362, and a second section dedicated to generating patient treatment plans based on protocols created via the treatment option form 362.

[0282] In some embodiments, a flow based on obtaining practitioner preferences via a user interface, an embodiment of which is described in connection with FIG. 3E, and a flow based on obtaining natural language practitioner comments, an embodiment of which is described in connection with FIG. 3A, may be combined or used together. For example, the treatment option form 362 may provide options that are commonly used or commonly preferred by practitioners, e.g., due to limited development time of the treatment option form 362 or protocol generation model 366, to avoid excessive visual or information clutter in treatment option form 362, or the like. For cases where the provided options don’t apply to a specific case, don’t meet the providers needs, or are otherwise inadequate, LLM- or Al-based methods may be utilized in protocol generation to augment the option selection methods.Attorney Docket No.: 28510.998 (L0773PCT)

[0283] FIG. 3F depicts an example GUI 300F for treatment protocol generation based on selections of a practitioner, according to some embodiments. GUI 300F may be provided via an application on a provider’s device, via a web portal, or the like. Operations related to GUI 300F may be performed locally, by a server device via the internet, or the like.

[0284] GUI 300F includes protocol preferences user interface (Ul) 372. GUI 300F may include additional elements, e.g., tabs for Ul elements related to active patients, treatment planning operations, appliance manufacturing or shipping information, or other categories of information that may be of relevance to the provider. Protocol preferences Ul 372 may include various selections, options, treatment categories, treatment goals, etc., to be chosen by the healthcare provider for generation of treatment protocols, e.g., generation of machine-readable code capturing the treatment provider’s treatment preferences as a treatment protocol.

[0285] Protocol preferences Ul 372 may include treatment component selection 380. Treatment component selection 380 may include a selection of a stage or component of a treatment plan. For example, a dental or orthodontic treatment may include a number of appliances for rearranging or otherwise adjusting patient dentition. Broad categories may be selectable under treatment component selection 380. For example, in some cases additional appliances may be provided, which are not part of a primary treatment. For example, appliances to be worn to maintain tooth placement (e.g., to be worn at night), rather than to enact change to a dental arch, may be accessed by selecting a treatment component. Various options related to additional appliances, such as how and when to perform interproximal reductions, extractions, and features of the appliances including attachments and hooks, may be selected in accordance with practitioner preferences. Main appliances, for a primary component of the treatment, may have additional available options related to various conditions, various treatments, etc.

[0286] Protocol preferences Ul 372 may include treatment category selection 374. T reatment category selection 374 may include various aspects on which a practitioner may express a preference that will adjust how treatment is performed, adjust treatment planning operations, adjust treatment appliance design and manufacturing, etc. Treatment category selection 374 may include selection of specific conditions or treatments. Treatment category selection 374 may include selection of aspects of treatment that affect treatment of multiple conditions, that affect design or manufacture of treatment appliances generally, or the like. T reatment category selection 374 may be separated or segmented by various categories, such as a section for malocclusion correction, a section for anterior correction, a section for general treatment preferences, etc.Attorney Docket No.: 28510.998 (L0773PCT)

[0287] Treatment category selection 374 may provide a category selection. Options within the category may be presented by the treatment options selection 376 element, upon selection of the category in treatment category selection 374.

[0288] As an example, treatment category selection 374 may include a number of malocclusion categories, anterior correction categories, and general treatment categories. Selectable categories available in treatment category selection 374 may include any treatment categories of relevance (e.g., that may assist in organizing the treatment preferences) and protocol generation questions for a set of treatment providers (e.g., treatment providers providing a specific treatment, treatment providers in a target industry, or the like).

[0289] Treatment category selection 374 may include a number of categories related to treatment of dental and orthodontic conditions with aligner appliances. T reatment category selection 374 may include interproximal reduction. Treatment category selection 374 may include approaches related to single dental arch treatments. Treatment category selection may include an approach to missing teeth. Treatment category selection may include an approach to extractions during treatment. Treatment category selection may include preferences for treating crowding. T reatment category selection may include preferences for treating tooth spacing. Treatment category selection may include treating midline misalignment. Treatment category selection may include anterior-posterior correction.Treatment category selection may include preferences for treating posterior crossbite. Treatment category selection may include treating anterior leveling. Treatment category selection may include treating overbite. T reatment category selection may include appliance features that may be applicable to many treatments. Treatment category selection may include providing preferences related to overcorrection. Treatment category selection may include preferences related to timing and use of passive and active treatment appliances.

[0290] Protocol preferences III 372 may include defaults 378. In some embodiments, a III element may be provided to view or set one or more categories or options to a default, such as default treatment options provided by the treatment planning application or program.

[0291] Protocol preferences III 372 includes treatment options selection 376. A user selection of a treatment category via treatment category selection 374 may cause options related to the selection treatment category to be presented via treatment options selection 376. Treatment options selection 376 may presentone or more sets of selectable options. In some cases, treatment options selection 376 may provide treatment goals, which may each be relevant for different treatment cases. For example, generating a treatment plan for a new patient may include selecting one or more treatment goals, which may cause the protocol script or machine-readable instructions to implement treatment planning operations based on the preferences reflected with respect to those treatment goals.Attorney Docket No.: 28510.998 (L0773PCT)Treatment options selection 376 may provide a branching tree of options, where selection of some goals or preferences may cause additional categories, options, or selections to be presented based on previous choices.

[0292] In some embodiments, treatment options selection 376 may include separated tabs, types, categories, groupings, or the like. For example, different preferences may be expressed by a practitioner for different classifications of disorder (e.g., class II or class III malocclusion, related to one jaw or the other protruding too far, may be treated differently by a practitioner). Different preferences may be expressed for different severities of disorder. Different preferences may be expressed for different types of patients, e.g., developmentally (for example, teens and adults may be treated differently), with respect to patient preferences, or other patient categories. These classifications or categorizations may be presented via treatment options selection 376, e.g., via tabs, as sections or groupings of the presented options, or the like. In some cases, one of the choices for one or classifications may be treated as a default, and if no different preferences are expressed by the practitioner, the system may generate machine-readable treatment protocol instructions that reflect the default selections for all groups or all groups without contradicting instructions.

[0293] Treatment options selection 376 may include options related to interproximal reduction. Interproximal reduction is a process of removing some material or enamel from teeth in the interproximal region, or the region between adjacent teeth. Final positions of teeth after treatment may accommodate different sizes of teeth, and interproximal reduction may be performed in various stages and with respect to various conditions to improve treatment and improve the final fit of the dentition. Different doctors, clinicians, practitioners, etc., may have different preferences of when or how to perform interproximal reduction. In some cases, a picture or model may be presented, for example, presenting zones or dentition or teeth that may be selected for different preferences. In the case of interproximal reduction, for example, segments of teeth where interproximal reduction is allowed may be selected. A maximum amount of interproximal reduction allowed may be selected, e.g., a posterior and anterior limit to interproximal reduction per contact may be selected. Timing of interproximal reduction may be selected, e.g., before or after alignment, delayed by atarget number of treatment stages, or the like. Scheduling preferences may be presented, such as basing scheduling of interproximal reductions based on access to the regions of the teeth to be reduced, performing the interproximal reduction on a regular schedule with respect to treatment stage, performing interproximal reduction at specific target treatment stages, or the like.

[0294] In some embodiments, treatment options selection 376 may include options related to operations of single arch treatment, such as whether to simulate treatment on the opposite arch, perform no movement on the opposite arch, manufacture passive aligners for the opposite arch, etc.Attorney Docket No.: 28510.998 (L0773PCT)

[0295] In some embodiments, treatment options selection 376 may include options related to missing teeth during treatment. Options for placing pontics (an artificial tooth that replaces a missing natural tooth on a fixed dental prosthesis) may be presented for selection. Pontics may be allowed for anterior missing teeth, posterior missing teeth, both, or neither. Any other options related to pontics that may be expressed as a treatment preference or protocol may be included.

[0296] In some embodiments, treatment options selection 376 may include options related to tooth extractions to be performed during treatment. Options may include scheduling extractions, e.g., delay extractions to a target stage of treatment. T reatment options selection 376 may provide options for pontics following extractions, e.g., whether pontics are to be placed for extracted teeth, extracted posterior teeth, extracted anterior teeth, etc.

[0297] In some embodiments, treatment options selection 376 may include treatment options for one or more malocclusions, or bite misalignments. Malocclusion treated with options for treatment presented under treatment options selection 376 may include crowding. Crowding treatment preferences may include a limit to arch expansions between upper first molars. Crowding treatment preferences may provide an options for a maximum measurement of expansions between upper first molars, for example, up to 1 mm of expansions.

[0298] Malocclusion treatment options presented in treatment options selection 376 may include tooth spacing. Spacing may include options for how spaces and tooth size discrepancy are managed in treatment. Options for space management for tooth size discrepancy may include distal to canines, distal to laterals, equally around laterals, or no spaces to account for tooth size discrepancy, for example.

[0299] Malocclusion treatment options may include options for midline correction. Midline correction options may include a treatment goal, such as improving midline with interproximal reduction, or showing a resulting midline after alignment. A general approach to achieving the goal may be selected, such as moving the upper arch, moving the lower arch, or moving both arches to match the opposing arch.

[0300] Malocclusion treatment options may include options for anterior-posterior correction, or treatment of misalignment between the upper and lower jaws in the front-to-back direction. A treatment goal may be selected, related to which tooth alignments to prioritize. Specific treatments or corrections may be applied to the upper arch and / or lower arch. For example lower arch options may include bite correction simulation, mesialization (pulling teeth forward toward the midline), or no correction; upper arch options may include bite correction, distalization (pushing teeth backward away from the midline), or no correction, etc. A distalization pattern may be selected, such as improved sequential distalization (moving teeth in a temporally overlapping sequential pattern), compact sequential distalizationAttorney Docket No.: 28510.998 (L0773PCT)(distalizing many teeth at the same time, which may cause additional stress), sequential distalization (moving a second tooth after the first has arrived in its target placement), or any other preference that may be expressed by a treatment provider for a pattern of distalization. Similar options may be provided for mesialization. An allowed maximum distance of distalization may be selected. A type of bite correction may be selected, e.g., using elastics or surgical intervention. A timing of a surgical intervention and / or elastics use may be selected, e.g., at the beginning or end of treatment, during or between one or more stages of treatment, etc. Options related to timing of treatment may be selected, such as whether or not to begin adjusting positions ofanteriorteeth while still performing posterior distalizatoin, or after posterior distalization. A priority may be set, e.g., if only alignment of molars or canines can be achieved, a selection of which is more important to the treatment provider for a treatment protocol may be selected.

[0301] Malocclusion treatment options may include options for treatment of posterior crossbite, or a misalignment where the upper back teeth bite inside the lower back teeth. Options selected in treatment options selection 376 may include whether or not to perform correction, whether to correct molars and premolars, molars only, premolars only, etc.

[0302] Categories presented by treatment category selection 374 may include anterior leveling, or performing vertical adjustments to anterior teeth. Options presented in treatment options selection 376 may include a general approach to the upper and / or lower arch, e.g., providing the lateral teeth 0.5 mm more gingival than central teeth, leveling incisal edges, leveling gingival margins, or the like.

[0303] Categories presented by treatment category selection 374 may include overbite treatment, with options for overbite treatment presented via treatment options selection 376. Separate sections for anterior open bite and deep bite may be presented. For practitioner preferences in generation of a treatment protocol, whether to extrude or intrude (depending on whether the bite is open or deep, for example) anterior teeth only, extrude or intrude anterior and posterior teeth, and a desired final position (e.g., final overbite) may be selected.

[0304] Treatment category selection 374 may include features of treatment appliances, that may apply to multiple conditions or treatments. Features of treatment appliances may be applicable to multiple dental treatments, multiple treatment goals, multiple types of treatment interventions, etc. Treatment options selection 376 may include options related to attachment size, e.g., attachments for treatment appliances that are applied to a patients teeth. Attachment size may be selected (e.g., selecting an attachment size, a standard size, an indication to use the largest attachments that fit, etc.). Options may be selected differently for different teeth or different zones of teeth, e.g., upper teeth, lower teeth, posterior or anterior teeth, etc. A delay to a target treatment stage for attachments may be provided.Attorney Docket No.: 28510.998 (L0773PCT)

[0305] Options related to additional appliance features for additional treatments may be provided, such as elastic attachments for anterior-posterior correction. Elastic attachments may be disabled, a delay to a target treatment stage for applying elastic attachments may be specified, an interaction between attachments and elastics may be indicated, elastic attachment style may be selected, etc. In some embodiments, a general preference may be expressed by the practitioner, which the treatment protocol may be configured to apply to any case where possible, with different options being implemented when the practitioner preference is unavailable.

[0306] In some embodiments, aligner features available for selection via the GUI may include precision cuts. Precision cuts may be cutouts or hooks on aligners configured to engage elastics for orthodontic correction, such as Class II or Class III elastic correction. Options for precision cuts may include enabling or disabling precision cuts, delaying placement of precision cuts to specific stages of treatment, and prioritizing precision cuts relative to other aligner features such as attachments. The GUI may provide separate options for precision cuts based on malocclusion class (Class II or Class III) and patient age group (adult or teen).

[0307] In some embodiments, aligner features may include bite ramps. Bite ramps may be placed automatically for deep bite cases to assist in bite opening. Options for bite ramp placement may include selection of placement locations such as canines, lateral incisors, central incisors, or combinations thereof. The treatment provider may select any combination of placement locations or may choose not to place bite ramps. Options related to bite ramps may be presented via treatment options selection 376. A selection of bite ramp type (e.g., which teeth it is permissible to utilize bite ramps), whether or not to place bite ramps, whether to include the bite ramps automatically or allow the practitioner to customize bite ramp placement, etc., may be included in treatment options selection 376.

[0308] In some embodiments, treatment options may include overcorrection settings.Overcorrection options may include whether to add additional aligners for overcorrection at the end of treatment. Overcorrection type options may include canine-to-canine overcorrection or molar-to-molar overcorrection. The treatment provider may also select which arch or arches to apply overcorrection to, such as upper arch only, lower arch only, or both arches. Options related to overcorrection may be provided by treatment options selection 376. A number of overcorrection appliances may be selected to add to each treatment plan generated with respect to the treatment protocol. A type of overcorrection may be selected, which dental arch to overcorrect may be selected, etc.

[0309] In some embodiments, treatment options may include passive aligner settings. Passive aligner options may include whether to use passive aligners at the end of active treatment. Options for finishing active aligners may include starting and finishing both arches at the same time, or starting both arches at the same time and finishing each arch when it is ready. These coordination options mayAttorney Docket No.: 28510.998 (L0773PCT)enable treatment providers to specify how the transition from active treatment to passive retention should be managed across the upper and lower arches. Options related to passive appliances may be presented via treatment options selection 376. Passive appliances may be used if the upper and lower dentition require a different amount of time, different number of treatment stages, different number of treatment appliances, or the like for completion of treatment. Whether or not to schedule passive aligners along with active aligners, whether both arches are to start treatment or end treatment at the same time, etc., may be selected by the pracitioner.

[0310] In some embodiments, one or more treatment options presented in treatment options selection 376 may include a description or information related to the option, selection, treatment goal, or the like. For example, while selecting options for midline correction, information may be displayed that explains how midline correction may be affected or may be ineffective based on other option selections. A description may indicate a combination of options, which may include options in the current treatment category and / or other treatment categories, which are predicted to result in the closest adherence to one or more treatment goals. In the case of midline correction, a hint or description may indicate that the best results for midline correction may be achieved by setting anterior-posterior correction to canine class I (in the anterior-posterior correction category of treatment category selection 374, for instance), allowing interproximal reduction, and to not close anterior residual spaces. In some embodiments, selecting a hint icon or hovering a cursor over an option may cause the III to provide additional information. For example, while selecting a distalization pattern in anterior-posterior correction, a short description of each of the options may be provided to ease decision-making of the treatment provider.

[0311] In some cases, related treatments may include links or connections to enable ease of filling the option selection process. For example, in a category for anterior-posterior correction, configuring attachments for elastics or other corrective tools may be particularly relevant to the treatment goals of anterior-posterior correction, and a link to these settings or a copy of the options for those settings may be provided in the anterior-posterior correction section.

[0312] In some embodiments, for each treatment category or treatment option presented via the GUI, a default configuration may be displayed. The default configuration may represent recommended or standard treatment parameters. A 3D model visualization may be provided showing how the default treatment would appear on example dentition, allowing the treatment provider to visualize the expected treatment outcome associated with the default settings. The treatment provider may compare their own selections against the recommended defaults by viewing both the default 3D model and a 3D model reflecting their selected preferences. This comparison capability may assist treatment providers in understanding the implications of their selections and in making informed decisions about treatment parametersAttorney Docket No.: 28510.998 (L0773PCT)

[0313] Upon filling selections in treatment options selection 376, a practitioner may view the treatment protocol in protocol view 382. In some embodiments, protocol view may be in a separate tab or page than other elements of protocol preferences Ul 372, or may be presented together as shown in FIG. 3F. Protocol view 382 may show the machine-readable code or instructions related to the protocol based on input of the practitioner preferences. Generation of protocol view 382 may be based on an indication from a user that they have finished inputting parameters, e.g., a “generate protocol” button may be included in protocol preferences Ul 372. For generating treatment plans, the machine-readable protocol instructions may be used along with additional input, such as a doctor indicating treatment or patient categories (e.g., whether the patient is a teenager or adult), the doctor indicating treatment goals (e.g., complete dental alignment, social six alignment, etc.), the doctor providing any specific case-by-case updates to perform treatment in a different manner than the protocol, etc.

[0314] In some embodiments, protocol preferences Ul 372 may include a 3D model view 384. The 3D model view may be accessed on a different page or tab. The 3D model view 384 may display a model of an effected region in connection with the treatment protocol, with a specific treatment category or treatment option, etc. The 3D model view may provide for inspection a three-dimensional model of dentition in relation to a treatment, treatment category, treatment category options, or the like. In some embodiments, a default option may be presented, e.g., a model highlighting final tooth locations, attachment locations, orthe like of the default treatment selections for a particular treatment category. In some embodiments, treatment provider selection provided in treatment options selection 376 and / or expressed in protocol view 382 may be presented. In some cases, example dentition may be used for the 3D model view 384, ora practitioner may select from a list of dentition, which may include former and / or current patient dentition, in some embodiments. Protocol preferences Ul 372 may include an option to publish protocol 386, which may apply the updated protocol based on updated treatment provider preferences to future treatment planning options, re-assess current treatment plans, etc.

[0315] In some embodiments, each time a treatment provider updates their protocol via the GUI, a new version of the machine-readable code may be generated and stored and / or an updated 3D model may be generated and / or output to a display. The system may maintain a version history comprising multiple treatment protocol versions, with each version associated with a version identifier such as version 1, version 2, version 3, and so on. The GUI may provide an interface for viewing different versions of the treatment protocol, comparing versions, or reverting to a prior treatment protocol version. This version history may enable treatment providers to track changes to their clinical preferences over time and to restore previous configurations if desired.

[0316] In some embodiments, upon updating a protocol via the GUI, such as by clicking an "update template" button or similar control, the new protocol version may be immediately applied.Attorney Docket No.: 28510.998 (L0773PCT)Immediate application may mean that any new treatment plans entered after the update may use the updated protocol. This immediate application may enable treatment providers to quickly implement changes to their clinical preferences without delay or additional confirmation steps beyond the initial update action

[0317] In some embodiments, machine-readable code generation based on GUI selections may be performed locally on a treatment provider's device or by a server accessed via the internet. The GUI-based protocol generation application may be accessed via a web browser, with operations related to preference collection and protocol generation performed by a remote server. Alternatively, various operations including preference collection and machine-readable protocol generation may be performed locally on the treatment provider's device. However, execution of the generated machine-readable code to perform treatment planning operations may require proprietary treatment planning engines that may be hosted on remote servers. Accordingly, while the machine-readable protocol code may be generated locally, the treatment provider may transmit the generated code to a server for execution in connection with patient data to generate treatment plans.

[0318] FIG. 3G depicts an example global clinical preferencestemplate GUI 300G for treatment protocol generation based on selections of a practitioner, according to some embodiments. GUI 300G may share one or more features with GUI 300F of FIG. 3F. GUI 300G may be configured for Flex Rx cases and may include settings applicable to treatment protocol generation for such cases.

[0319] GUI 300G includes additional aligners tab 388. Additional aligners tab 388 may share one or more features with treatment component selection 380. Additional aligners tab 388 may be presented as selectable buttons, tabs, options in a drop-down menu, or in another manner. In the case of GUI 300G, the additional aligners tab 388 is selected, indicating that the current view pertains to additional aligner settings. GUI 300G may also include a primary orders tab that, when selected, displays settings associated with primary treatment orders.

[0320] GUI 300G includes treatment category menu 392. Treatment category menu 392 may share one or more features with treatment category selection 374. T reatment category menu 392 may include a set of treatment categories that are to be used in generating a treatment protocol. Treatment categories displayed in treatment category menu 392 may include IPR, Arch to treat, Missing teeth, Extractions, Malocclusion correction, Crowding, Spacing, Midline, Anterior-Posterior correction, Posterior crossbite, Anterior correction, Anterior leveling, Overbite, Aligner features, Overcorrection for space closure, and / or Passive / active aligners. Treatment categories may be separated into sections or displayed as a scrollable list.

[0321] GUI 300G includes use align defaults button 396. In some embodiments, use align defaults button 396 may act on all treatment components, a single treatment component, a singleAttorney Docket No.: 28510.998 (L0773PCT)treatment category, a single selection within a treatment category, or the like. In some embodiments, selecting use align defaults button 396 may cause treatment settings to be resetto default values provided by the system. Use align defaults button 396 may be positioned at the bottom of the GUI 300G to allow the user to reset settings after reviewing current configurations.

[0322] GUI 300G includes dental arch diagram 390. For some treatment options, it may be helpful to provide a graphical guide to one or more selections. Dental arch diagram 390 displays a representation of upper and lower dental arches, allowing selection of segments where treatment operations such as interproximal reduction (IPR) are allowed. Various segments of dentition may be selected for one or more treatment operations via the dental arch diagram 390, enabling practitioners to visually specify which areas of the dental arches should receive particular treatments.

[0323] GUI 300G includes IPR limit selection fields 394 and / or other numerical selection fields. For some treatment options, it may be convenient to provide a limited list of potential numerical values that may be selected. For other treatment options, it may be useful to provide more or fewer options, or a free entry option, such as free entry element 398. IPR limit selection fields 394 provide options to limit anterior IPR per contact with selectable values such as 0.5, 0.4, 0.3, and 0.2 millimeters, as well as options to limit posterior IPR per contact with the same selectable values. The IPR limit selection fields 394 allow practitioners to specify maximum amounts of interproximal reduction to be performed at each contact point.

[0324] GUI 300G includes stage specification field 398. Stage specification field 398 provides options for scheduling IPR at specific stages of treatment. Stage specification field 398 may include options such as scheduling IPR based on access to contacts, scheduling IPR every certain number of stages, or scheduling IPR at specific stages. Stage specification field 398 may include a text entry area for specifying particular stage numbers at which IPR should be performed. For other treatment options, it may be useful to provide more or fewer options, or a free entry option similar to stage specification field 398.

[0325] FIG. 3H depicts an example clinical preferences template GUI 300H including nested treatment categorization and selection of treatment goals, according to some embodiments. GUI 300H includes malocclusion class tabs 305, which provide class selection such as between different malocclusion categories such as Class II and Class III, with an Adult designation shown below the tabs. In some cases, different severities of disorder, directionality of disorder (e.g., overbite vs underbite), or the like may be treated differently, and further options and selections may be entirely dependent on class selection. In some cases, the same set of selections and options may be provided for each class, while in some cases one or more selections or options may be different between classes. GUI 300H may share one or more features with GUIs 300F and 300G.Attorney Docket No.: 28510.998 (L0773PCT)

[0326] GUI 300H includes a treatment goal configuration panel 307 for treatment goal selection. Treatment goal configuration panel 307 may enable a practitioner to address multiple cases that may arise within a single treatment category. The treatment goal configuration panel 307 contains multiple configuration options including a treatment goal dropdown menu (e.g., set to "Molar and canine class I"), upper arch and lower arch selection fields, a distalization pattern dropdown, an amount of distal i zation specification field (e.g., set to "4 mm"), a checkbox option for starting anterior teeth movement at the same time as posterior distalization, priority selection radio buttons for Molar and Canine, and / or type of bite correction simulation options including Elastics and Surgical. For example, different targets may be applicable, appropriate, or selected for different patients, such as prioritizing aligning particular dental structures over others, prioritizing molar alignment or anterior tooth alignment, or the like. In some cases, options may be selected for multiple treatment goals, and during treatment planning operations for a particular patient, a treatment goal may be selected. Further operations of treatment planning may be performed based on the selected goal, and the options selected in reference to that treatment goal via GUI 300H. The left side of GUI 300H displays a navigation menu listing various treatment categories including IPR, Arch to treat, Missing teeth, Extractions, Malocclusion correction, Crowding, Spacing, Midline, Anterior-Posterior correction, Posterior crossbite, Anterior correction, Anterior leveling, Overbite, Aligner features, Overcorrection for space closure, and Passive / active aligners. The interface includes tabs for Primary orders and Additional aligners at the top, along with a notification indicating that settings apply only for Flex Rx cases and that changing settings will not affect Traditional Rx. A "Use Align Defaults" button and a "Review Align Default" link are provided for accessing default configuration options.

[0327] FIG. 4A is a block diagram of a data flow 400A for generating a treatment plan 420 based on natural language instructions 402, according to some embodiments. At block 402, natural language instructions are obtained by a treatment planning system. The natural language instructions may be related to differences between a treatment protocol (e.g., a default protocol or a protocol based on practitioner preferences) and specific treatment goals for a patient. Alternatively, the natural language instructions may be instructions to generate a new treatment plan from scratch. The natural language instructions 402 may be provided via a text input GUI element of a treatment planning GUI.Alternatively, the natural language input may be received as spoken audio, which may be transformed into text using a speech to text engine (e.g., one or more Al models trained to convert speech into text). The natural language instructions 402 may include one or more references to teeth of the dental patient. The references to teeth may include references to specific teeth. The references may include references to groups of teeth, including named groups of teeth (e.g., upper left molars, anteriors, etc.), ranges of teeth (e.g., all teeth between 7 and 10), teeth referenced by relative position (e.g., mesial ofAttorney Docket No.: 28510.998 (L0773PCT)UR3), teeth referenced by by exclusion (e.g., all anteriors except centrals), or the like. The teeth or groups of teeth may be referred to by an indexing system related to dentition, such as UNS, Palmer, FDI, etc. In some embodiments, an indication of a preferred teeth numbering or indexing system of the practitioner may also be provided as part of natural language instructions 402, or part of construction rules 408 and / or indexing rules 410.

[0328] Various prompt engineering information may also be provided along with natural language instructions 402 to an LLM or other Al model for processing. Prompt information may include construction rules 408 and / or indexing rules 410. Construction rules 408 may include an outline for generating machine-readable instructions related to patient treatment. Construction rules 408 may include examples of machine-readable instructions corresponding to natural language instructions. Construction rules 408 may indicate a similarity of structure between a target machine-readable format and a known format, e.g., "in a machine-readable format similar to JSON" may be included in construction rules 408. Categories of potential instructions may be described and defined, with examples of instructions corresponding to each category provided. Construction rules 408 may specify a set of classifications of treatment instruction categories, such as dental features, attachments, interproximal reduction, passive aligners, overcorrection, treatment length, and other treatment-related categories. For each classification, construction rules 408 may provide one or more examples of machine-readable instructions that correspond to natural language instructions within that category. Construction rules 408 may further specify allowed values, actions, and relationships between different elements of the machine-readable format. For example, construction rules 408 may define a set of permissible actions such as add, remove, keep, replace, modify, forbid placement, or delay placement in connection with dental features. Construction rules 408 may also specify attachment types including optimized attachments, conventional attachments, and protocol attachments, along with their associated parameters such as size, position, and specific type. Construction rules 408 may include a schema definition that constrains the output of the Al model to only include modifications that are valid within a predefined set of protocol commands, ensuring that generated machine-readable instructions conform to required formatting and structural requirements.

[0329] Indexing rules 410 may include similar information, related to various indexing schemes. The indexing rules 410 may include input schemes (e.g., description of various common teeth indexing rule sets, such as Palmer, FDI, Universal, etc.). Indexing rules 410 may provide detailed descriptions of each numbering system to enable the Al model to recognize and interpret tooth references expressed in different formats. For example, indexing rules 410 may specify that in the Palmer system, teeth identifiers are represented with at least one letter at the beginning indicating upper or lower and right or left quadrants, followed by a number ranging from one to eight. Indexing rules 410 may specify that inAttorney Docket No.: 28510.998 (L0773PCT)the FDI system, teeth identifiers are represented with a first number ranging from one to four indicating the quadrant, a separator character, and a second number ranging from one to eight indicating the tooth position. Indexing rules 410 may specify that in the Universal system, adult teeth are numbered from one to thirty-two starting from the upper right third molar and moving clockwise. Indexing rules 410 may further include mappings between tooth types and their corresponding identifiers in each numbering system, such as central incisors, lateral incisors, canines, premolars, and molars. Indexing rules 410 may include an output scheme, e.g., instructions to number objects such as teeth based on positions, instructions to number teeth in order of current position, or the like. Indexing rules 410 may specify a preferred machine-readable indexing scheme for output, enabling consistent representation of tooth references regardless of the input numbering system used by the treatment provider. In some cases, geometric ordering may be applicable to natural language instructions (e.g., a first tooth anterior to a second tooth is a geometric instruction), while standard indexing schemes may use identity of an object without respect to positioning (e.g., in cases where one or more objects of a set are missing, when objects are ordered in a non-standard way, when there are extra teeth in a dental arch, or the like). Indexing rules 410 may include instructions for handling ambiguous or mixed numbering system references, where the treatment provider may use terminology from multiple systems within a single instruction set. Indexing rules 410 may also specify rules for converting natural language tooth group references, such as anteriors, posteriors, molars, or incisors, into specific tooth identifiers in the machine-readable format. Prompt information may also include examples, references to documents to be accessed via RAG, and / or any other prompt information described herein.

[0330] Prompt data and the natural language instructions 402 may be provided to translation model 404. The translation model 404 may be an LLM in embodiments. In some embodiments, the translation model 404 is a general purpose LLM. In some embodiments, the translation model 404 is a specifically trained Al model trained to perform the task of translating natural language instructions 402 into machine-readable instructions 406 in a specific medical field, such as dentistry or orthodontics. In some embodiments, the translation model 404 may be adjusted (e.g., through machine learning tuning techniques, such as parameter efficient fine tuning) to be more likely to produce machine-readable instruction 406 that satisfy one or more quality thresholds.

[0331] Machine-readable instructions 406 may be generated by translation model 404 based on processing of the input prompts. The machine-readable instructions 406 may represent an intermediate representation that encodes the treatment provider's natural language instructions in a structured, machine-interpretable format. In some embodiments, these machine-readable instructions 406 are distinct from both the treatment algorithm and the treatment plan. Alternatively, the machine-readable instructions, treatment algorithm, and / or treatment plan may be merged into a single construct. In someAttorney Docket No.: 28510.998 (L0773PCT)embodiments, the treatment algorithm comprises the computational logic and rules that govern how treatment planning operations are performed, and the machine-readable instructions 406 may be used to adjust or configure this treatment algorithm by adding to it, replacing portions of it, or otherwise modifying its behavior. In some embodiments, the treatment plan represents the final patient-specific output that is generated when the treatment algorithm (as configured by the machine-readable instructions 406) is applied to patient data such as a three-dimensional model of the patient's dentition. Thus, the machine-readable instructions 406 may serve as a bridge between the treatment provider's natural language input and the treatment algorithm, which in turn may generate the treatment plan when executed with patient-specific data. In some embodiments, the machine-readable instructions 406 may be configured to resemble an existing programming language, or may be formatted in a new language tuned to specific challenges to be addressed. A few examples of natural language instructions and corresponding machine-readable instructions, intended to make clear differences between the natural language input to translation model 404 and machine-readable instructions output by translation model 404 follow.

[0332] As a first example, treatment provider instructions may include an instruction to “add attachment UL2.” An output of the translation model 404 may be or include:{“dental_features”: {“add”: [{“feature”: “attachments”,“teeth”: [“UL2”]}}}

[0333] As a second example, treatment provider instruction may include an instruction to add bite ramps to U2-2 for the upper jaw. An output of the translation model 404 may be or include:{“dental_features”: {“add”: [{“feature”: “bite_ramps”,“teeth”: {“begin”: “UL2”, “end”: “UR2”}Attorney Docket No.: 28510.998 (L0773PCT)}}}

[0334] As a third example, treatment provider instructions may include instructions to add 2 passive aligners at the end of treatment for the upper jaw, and 3 passive aligners at the end of treatment for the lower jaw. An output of the translation model 404 may be or include:{“p assi ve_al i g n e rs_p I aceme nt” :{“jaw”: “upper”,“amount’: 2,“position”: “last_stage”},“p assi ve_al i g n e rs_p I aceme nt’:{“jaw”: “lower”,“amount’: 3,“position”: “last_stage”},}

[0335] As a fourth example, doctor instructions may include instructions to add attachments for extrusion to the upper 1’s. Particularly relevantin cases such as this, indexing schemes may be included in instruction parsing, according to indexing rules 410 provided as input to the translation model 404. Teeth may be classified in various ways according to an indexing scheme, which may then be mapped to patient data geometrically. Output of translation model 404 may be or include:{“dental_features”: {“add”: [{“feature”: “attachments”,“teeth”: {“group”: “central incisors”,“jaw”: “upper”Attorney Docket No.: 28510.998 (L0773PCT)},“purpose”: “extrusion”}}}

[0336] As a fifth example, tooth indexing in the machine-readable instructions 406 may include exclusion. For example, a instruction related to upper anteriors except central incisors may produce machine-readable instructions that include a tooth indexing such as:{“teeth”: [{“include”: {“group”: “anteriors”,“jaw”: “upper”},“exclude”: [“UL1”, “UR1 ”]}}

[0337] As a sixth example, indexing of teeth may include references of one or more teeth relative to other teeth. This may be of particular interest in cases where indexed objects are out of order, expected objects are missing, extra objects are present, or the like. An example of a tooth indexing in machine-readable instructions 406 including relative tooth specification may include:{“teeth”: [{“tooth”: “UL3”,“direction”: “mesial”}}

[0338] Results such as these may be obtained by providing, included in a promptto the translation model 404, multiple features including definitions of supported instructions andAttorney Docket No.: 28510.998 (L0773PCT)representations of teeth, examples illustrating howto convert natural language phrases into a target machine-readable format, and guidelines for addressing edge cases.

[0339] Machine readable instructions 406 may then provided for validation 412. Validation 412 may be Al-based in some embodiments. Validation 412 may be heuristic or rules-based validation in some embodiments. Validation 412 may include determining whether the machine-readable instructions 406 are reasonable, whether the machine-readable instructions 406 correlate to best practices in treatment, determining whether machine-readable instructions 406 comply with one or more treatment requirements, etc. Examples of machine-readable instructions 406 that may not comply with validation 412 may include instructions not supported by a treatment planning engine, violations of treatment best practices such as speed of alignment for orthodontic treatments, a target length of time for treatment, or the like. Validation 412 may be performed using multiple validation techniques applied sequentially or in parallel. In some embodiments, validation 412 includes syntax validation to confirm that the machine-readable instructions 406 conform to a required schema or format specification, ensuring that the instructions are parseable and structurally correct for processing by downstream components such as the integration and mapping engine 414. Syntax validation may verify that required fields are present, that data types are correct, that values fall within permitted ranges, and / or that the overall structure of the machine-readable instructions 406 adheres to a predefined schema (e.g., JSON schema) or other format specification.

[0340] In some embodiments, validation 412 includes clinical validation to determine whether the machine-readable instructions 406 adhere to clinical safety constraints and treatment heuristics. Clinical validation may include checking that proposed tooth movements do not exceed maximum safe movement thresholds per treatment stage, thatinterproximal reduction amounts do not exceed safe limits per contact point, that attachment placements are compatible with the specified tooth movements, and / or that the overall treatment duration falls within acceptable ranges. Clinical validation may compare the machine-readable instructions 406 against a database of clinical rules, safety thresholds, and / or best practice guidelines to identify potential violations.

[0341] In some embodiments, validation 412 includes semantic validation to confirm that the machine-readable instructions 406 accurately reflect the intent of the original natural language instructions 402. Semantic validation may involve providing both the natural language instructions 402 and the machine-readable instructions 406 to an Al model configured to predict whether the machine-readable instructions 406 correctly capture the meaning of the natural language instructions 402. The Al model may generate a confidence score indicating the likelihood that the translation is accurate.

[0342] In some embodiments, validation 412 includes compatibility validation to determine whether the machine-readable instructions 406 are compatible with the treatment building engine orAttorney Docket No.: 28510.998 (L0773PCT)treatment planning engine that will execute the instructions. Compatibility validation may verify that all instruction types, parameters, and values in the machine-readable instructions 406 are supported by the target engine, and that no unsupported or deprecated instruction formats are present.

[0343] Validation 412 may produce multiple possible outcomes based on the results of the validation operations. In a first outcome, validation 412 determines that the machine-readable instructions 406 pass all validation checks, and the machine-readable instructions 406 are provided to the integration and mapping engine 414 for further processing and treatment plan generation. In a second outcome, validation 412 identifies one or more validation failures that can be automatically corrected, and validation 412 applies corrections to the machine-readable instructions 406 to generate corrected instructions that are then re-validated or provided to the integration and mapping engine 414. Automatic corrections may include adjusting values that slightly exceed thresholds to fall within acceptable ranges, correcting minor syntax errors, or resolving ambiguities based on default values. In a third outcome, validation 412 identifies one or more validation failures that cannot be automatically corrected, and the machine-readable instructions 406 are directed to manual treatment planning 418 for review and correction by a trained technician. Instructions directed to manual treatment planning 418 may include instructions that violate clinical safety constraints, instructions that contain unsupported operations, instructions that have low semantic validation confidence scores, or instructions that contain ambiguities that require human judgment to resolve.

[0344] In some embodiments, validation 412 generates a validation report that identifies specific validation failures, provides explanations for why each failure occurred, and suggests potential corrections or modifications. The validation report may be provided to a treatment provider or technician to facilitate manual review and correction of the machine-readable instructions 406. In some embodiments, validation 412 maintains a log of validation results for auditing and quality assurance purposes, enabling analysis of common validation failures and identification of opportunities to improve the translation model 404 or the validation rules.

[0345] Upon failure of validation 412, flow may continue to a manual treatment planning 418. Manual treatment planning 418 may include providing instructions (e.g,. natural language instructions 402) to a technician trained to generate a treatment planning algorithm based on practitioner instructions. Other points of data flow 400A may also cause manual treatment planning 418 to be performed, e.g., failure of any earlier steps may also cause flow to be diverted to manual treatment planning 418.

[0346] Upon machine-readable instructions 406 passing validation 412, the instructions may be provided to integration and mapping engine 414. Integration and mapping engine 414 may update or create a treatment algorithm based on the machine-readable instructions 406. The integration andAttorney Docket No.: 28510.998 (L0773PCT)mapping engine 414 serves as a bridge between the validated machine-readable instructions 406 and the patient-specific dental data, translating abstract treatment directives into concrete treatment operations applicable to a particular patient's dentition. In some embodiments, the integration and mapping engine 414 receives the machine-readable instructions 406 along with patient data 416, which may include a three-dimensional model of the patient's dentition obtained from intraoral scan data or other dental arch data capturing equipment. In embodiments, the integration and mapping engine 414 processes these inputs to generate treatment plan 420, which incorporates the updates encoded in natural language instructions 402. In some embodiments, e.g., if integration fails due to incompatibility between the instructions and the patient data, data flow 400A may be directed to manual treatment planning 418 at this stage.

[0347] In some embodiments, integration and mapping engine 414 may perform operations mapping tooth identifiers from the machine-readable instructions 406 to patient data 416. The mapping operations may include resolving references to teeth expressed in various numbering systems (such as Universal, FDI, or Palmer notation) to the specific teeth present in the patient's three-dimensional dental model. In some embodiments, a digital model's teeth (e.g., patient data 416) may be sorted based on geometric position along a jaw arch. Geometric sorting may ensure consistent ordering even in the presence of irregularities such as unerupted, supernumerary, or pontic teeth. The sorting may be cached and reused across multiple instructions within the same case, e.g., to optimize performance. The integration and mapping engine 414 may segment the three-dimensional model to identify individual teeth, determine their positions relative to one another, and establish correspondences between the tooth references in the machine-readable instructions 406 and the actual teeth represented in the patient data 416.

[0348] In some embodiments, instructions may be mapped to the array of teeth. Selection may include iterating through the sorted array and selecting only those teeth that match the description included in machine-readable instructions 406 for any treatment instruction. Matching logic may include individual teeth, tooth groups, intervals, relative positions, exclusion, etc. The integration and mapping engine 414 may apply the treatment operations specified in the machine-readable instructions 406 to the selected teeth, generating staging information that defines how teeth should move from their initial positions to target positions over a series of treatment stages. The engine may also determine placement of dental features such as attachments, precision cuts, and / or bite ramps based on the instructions.

[0349] For some instruction types, one or more interteeth intervals may be utilized. For example, instructions involving interproximal spaces, such as gap closures orinterproximal reduction (IPR), may include references for spaces between teeth. Parsing instructions may include deriving an array ofAttorney Docket No.: 28510.998 (L0773PCT)inte...

Claims

Attorney Docket No.: 28510.998 (L0773PCT)CLAIMSWhat is claimed is:

1. A method, comprising:obtaining, by a processing device, treatment provider instructions associated with a target dental treatment, expressed in a natural language format;providing first input comprising the treatment provider instructions to one or more trained artificial intelligence (Al) models;obtaining from the one or more trained Al models a first treatment protocol in association with the target dental treatment; andproviding an alert to the treatment provider comprising the first treatment protocol.

2. The method of claim 1, wherein:providing the first input to the one or more trained Al models comprises transmitting the first input to a remote computing device that executes the one or more trained Al models; and obtaining the first treatment protocol comprises receiving the first treatment protocol from the remote computing device.

3. The method of claim 1 , wherein the one or more trained Al models perform a safety check to determine whether the first treatment protocol is in accordance with one or more clinical threshold conditions associated with the target dental treatment.

4. The method of claim 1 , wherein operations of the one or more trained Al models comprise separating the treatment provider instructions into a plurality of sections, one of the plurality of sections corresponding to the target dental treatment.

5. The method of claim 1 , wherein operations of the one or more trained Al models comprise transforming one or more natural language statements of the treatment provider instructions into machine readable statements associated with at least a portion of the target dental treatment.

6. The method of claim 5, wherein operations of the one or more trained Al models comprise discarding one or more natural language statements of the treatment provider instructions which do not correspond to machine-readable instructions for the target dental treatment.Attorney Docket No.: 28510.998 (L0773PCT)7. The method of claim 5, wherein transforming the one or more natural language statements of the treatment provider instructions into machine readable statements comprises one or more of:determining that a plurality of natural language statements corresponds to one machine readable statement; ordetermining that one natural language statement corresponds to a plurality of machine readable statements.

8. The method of claim 1 , wherein the one or more trained Al models comprise a large language model.

9. The method of claim 8, wherein the first input provided to the one or more trained Al models further comprises a prompt preface, the prompt preface comprising instructions to the one or more trained Al models to perform one or more operations in connection with the treatment provider instructions to generate the first treatment protocol.

10. The method of claim 8, wherein the first input is provided to the one or more trained Al models to generate first output, and wherein second input comprising the first output is provided to the trained machine learning model to generate second output, wherein the first treatment protocol is based at least in part on the second output.

11. The method of claim 1 , further comprising:providing, via a graphical user interface (GUI), a prompt for a treatment provider to provide the treatment provider instructions;obtaining, via the GUI, the treatment provider instructions; andproviding, via the GUI, a natural language validation prompt associated with the first treatment protocol, wherein the first treatment protocol is generated responsive to obtaining validation from the treatment provider, and wherein generating the natural language validation prompt comprises:obtaining machine-readable instructions associated with first treatment protocol; and processing the first treatment protocol using a response generator model to generate a natural language description of operations of the machine-readable instructions; and outputting the natural language description.

12. The method of claim 11 , wherein the response generator model comprises a deterministic or rule-based model.Attorney Docket No.: 28510.998 (L0773PCT)13. The method of claim 1 , further comprising:generating a request for one or more treatment details;outputting the request; andreceiving additional provider instructions comprising the one or more treatment details in the natural language format;wherein the additional provider instructions are processed by the one or more trained Al models to generate the first treatment protocol.

14. The method of claim 13, further comprising:determining that the one or more treatment details are missing in the treatment provider instructions.

15. The method of claim 1 , further comprising:performing the following by the one or more trained Al models:updating a formatting of the first input to generate second input;separating the second input into a plurality of sections;determining a malocclusion type for each of the plurality of sections;separately processing each section of the plurality of sections to generate a portion of the first treatment protocol;combining, for each of the plurality of sections, the associated portion of the first treatment protocol to generate the first treatment protocol.

16. The method of claim 15, wherein a separate model is used to process sections for each malocclusion type.

17. The method of claim 1 , wherein the treatment protocol is a general treatment protocol usable as a template to generate prescriptions for a plurality of patients.

18. The method of claim 1 , wherein the treatment protocol is a machine readable prescription for the target dental treatment.

19. The method of claim 1 , wherein the first input comprises:an instruction to convert the treatment provider instructions from the natural language format into the treatment protocol;Attorney Docket No.: 28510.998 (L0773PCT)a detailed description of each treatment option that is possible forthe first treatment protocol; one or more examples of each treatment option; andinstructions on howto process unclear, ambiguous, or unsupported statements.

20. A method, comprising:obtaining a plurality of treatment provider instructions associated with dental treatments; obtaining a plurality of machine-readable instructions corresponding to the treatment provider instructions; andtraining a machine learning model to generate a trained machine learning model by providing the plurality of treatment provider instructions as training input and the plurality of machine-readable instructions as target output.

21. The method of claim 20, wherein training the machine learning model comprises adjusting one or more parameters of a large language model.

22. The method of claim 21 , wherein training the machine learning model comprises performing parameter-efficient fine-tuning operations.

23. The method of claim 22, wherein training the machine learning model comprises performing low-rank adaptation operations.

24. The method of claim 21 , wherein training the machine learning model comprises introducing adapter layers between existing layers of the machine learning model, and adjusting parameters of the adapter layers.

25. The method of claim 20, further comprising:obtaining feedback data associated with operation of the trained machine learning model; and retraining the trained machine learning model based on the feedback data.

26. The method of claim 25, wherein the feedback data comprises evaluation data submitted by a user.

27. The method of claim 25, wherein the feedback data comprises indirect feedback data related to one or more of time spent on a dental treatment, number of updates performed on a treatment protocolAttorney Docket No.: 28510.998 (L0773PCT)associated with the dental treatment, or level of confidence of results generated by the trained machine learning model.

28. A method, comprising:obtaining, by a processing device, a data model comprising a plurality of fields of a dental treatment protocol or prescription to be filled, the plurality of fields associated with a dental treatment;generating a first prompt in natural language associated with one or more first fields of the plurality of fields;presenting, via a graphical user interface, the first prompt;obtaining a response to the first prompt;providing the response to a trained machine learning model, wherein the trained machine learning model generates a machine-readable output; andfilling the one or more first fields of the dental treatment protocol or prescription using the machine-readable output of the trained machine learning model.

29. The method of claim 28, further comprising providing a second prompt to verify that the output of the trained machine learning model accurately applies to a dental treatment associated with the first one or more fields, wherein filling the fields is performed responsive to receiving verification based on the second prompt.

30. The method of claim 28, wherein the trained machine learning model comprises a large language model.

31. The method of claim 28, further comprising:generating a second prompt associated with one or more second fields of the plurality of fields; presenting, via the graphical user interface, the second prompt;obtaining a response to the second prompt;providing the response to the second prompt to the trained machine learning model or a second trained machine learning model, wherein the trained machine learning model or the second trained machine learning model generates a second machine-readable output; andfilling the one or more second fields of the dental treatment protocol or prescription using the second machine-readable output.Attorney Docket No.: 28510.998 (L0773PCT)32. A non-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 1-31.

33. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 1-31.

34. A method comprising:providing, by a processing device, a first set of options related to treatment preferences for a first dental condition;obtaining a first selection of one of the first set of options;providing the first selection to a model to generate machine-readable code in a domainspecific language for dental treatment, wherein the machine-readable code constitutes a clinical protocol for generating dental treatment plans; andobtaining from the model the machine-readable code.

35. The method of claim 34, further comprising executing the machine-readable code in association with a dental patient to generate a treatment plan for the first dental condition.

36. The method of claim 35, wherein generating the treatment plan comprises obtaining a three-dimensional intraoral scan of the dental patient, obtaining a second selection of one or more treatment goals, and executing the machine-readable code in view of the intraoral scan and the one or more treatment goals.

37. The method of claim 35, wherein generating the treatment plan includes generating designs for one or more treatment appliances, and wherein the method further comprises providing the designs for manufacturing of the appliances.

38. The method of claim 34, wherein the first set of options are provided via a graphical user interface (GUI), and wherein the first selection is obtained via the GUI.

39. The method of claim 38, further comprising:Attorney Docket No.: 28510.998 (L0773PCT)providing for inspection via the GUI a three-dimensional model depicting example dentition indicating one or more aspects of a default selection or the first selection.

40. The method of claim 38, further comprising providing, via the GUI, an indication of an expected outcome with respect to the first selection.

41. The method of claim 34, further comprising:providing a second set of options related to treatment preferences for a second dental condition;obtaining a second selection of one of the second set of options; andfurther processing the second selection using the model or an additional model to generate the machine-readable code in the domain-specific language for dental treatment, wherein the machine-readable code is associated with the first dental condition and the second dental condition.

42. The method of claim 34, wherein the first dental condition comprises one of:a malocclusion;anterior leveling; oran overbite.

43. The method of claim 34, further comprising providing a second set of options related to treatment operations applicable to multiple dental treatments, wherein the treatment operations comprise one or more of:interproximal reduction;placing pontics; orextracting teeth.

44. The method of claim 34, wherein the first set of options comprises a hierarchical tree structure, and wherein obtaining the first selection causes one or more additional options to be displayed or hidden based on the first selection.

45. The method of claim 34, further comprising:generating a version identifier associated with the machine-readable code;storing the machine-readable code in association with the version identifier; and maintaining a history of prior versions of the machine-readable code.Attorney Docket No.: 28510.998 (L0773PCT)46. A method, comprising:providing, by a processing device via a graphical user interface (GUI), a plurality of treatment parameter fields organized into treatment categories, each treatment parameter field associated with one or more selectable options for orthodontic treatment;obtaining, via the GUI, a selection for each of one or more of the plurality of treatment parameter fields;deterministically generating, based on the selections, machine-readable code in a domainspecific language for orthodontic treatment planning, wherein each selection maps to a corresponding code segment such that identical selections produce identical machine-readable code;validating the machine-readable code to confirm syntactic and semantic correctness; and storing the machine-readable code as a treatment protocol version associated with a treatment provider.

47. The method of claim 46, wherein the plurality of treatment parameter fields are organized into a hierarchical tree structure, and wherein obtaining a selection for a first treatment parameter field causes one or more additional treatment parameter fields to be displayed or hidden based on the selection.

48. The method of claim 46, further comprising:maintaining a version history comprising a plurality of treatment protocol versions; associating each treatment protocol version with a version identifier; andproviding, via the GUI, an interface for viewing or reverting to a prior treatment protocol version.

49. The method of claim 46, wherein the treatment categories comprise one or more of:interproximal reduction parameters including timing and location;attachment parameters including size and delay stages;precision cut parameters including placement and prioritization;bite ramp parameters including placement locations; orovercorrection parameters including type and arch selection.

50. The method of claim 46, further comprising:providing, via the GUI, a division of treatment options based on patient demographics, wherein a first set of options is associated with adult patients and a second set of options is associated with teen patients; andAttorney Docket No.: 28510.998 (L0773PCT)generating the machine-readable code to include conditional logic based on patient demographic classification.

51. The method of claim 46, further comprising:providing, via the GUI, a default treatment option indicator for each of the plurality of treatment parameter fields; anddisplaying a three-dimensional model depicting example dentition corresponding to the default treatment option.

52. The method of claim 46, further comprising:applying the treatment protocol version to generate treatment plans for a plurality of patients; determining that a treatment requirement for a particular patient is outside a scope of the plurality of treatment parameter fields; andproviding the treatment requirement to an artificial intelligence model to generate supplemental machine-readable code for the particular patient53. A method, comprising:providing, by a processing device, a first set of treatment options related to a first treatment goal in association with a first dental condition, and a second set of treatment options related to a second treatment goal in association with the first dental condition;obtaining, by the processing device, a first selection from the first set of treatment options and a second selection from the second set of treatment options;generating a treatment protocol in a machine-readable format comprising the first selection and the second selection;obtaining an indication that the first treatment goal is to be applied to a patient in association with the first dental condition; andgenerating a treatment plan for the patient corresponding to the first treatment goal based on the treatment protocol.

54. The method of claim 53, further comprising:providing a third set of treatment options related to a second dental condition; and obtaining a third selection from the third set of treatment options, wherein the treatment protocol further comprises the third selection.Attorney Docket No.: 28510.998 (L0773PCT)55. The method of claim 53, wherein generating the treatment protocol comprises providing the first selection and the second selection to a model that generates machine-readable treatment protocols based on the first selection and the second selection.

56. The method of claim 53, wherein generating the treatment plan comprises utilizing a three-dimensional model of dentition of the patient to generate one or more treatment appliance designs.

57. The method of claim 56, further comprising providing the one or more treatment appliance designs for manufacturing.

58. The method of claim 53, wherein the first set of treatment options is provided via a graphical user interface (GUI), and wherein the first selection is obtained via the GUI.

59. The method of claim 53, wherein the first dental condition comprises:tooth crowding;tooth spacing;shifted midline;anterior level;anterior-posterior relationship;posterior crossbite; oroverbite.

60. A method, comprising:providing, via a graphical user interface (GUI), a set of treatment categories in association with operations of a dental treatment;providing, for each of the set of treatment categories, a corresponding set of treatment options; obtaining, for a first of the set of treatment categories, a selection from the set of treatment options via the GUI;providing the selection to a model that processes the selection to generate a treatment protocol in a machine-readable format comprising a domain-specific language for orthodontic treatment; anddisplaying the treatment protocol via the GUI.Attorney Docket No.: 28510.998 (L0773PCT)61. The method of claim 60, wherein providing the selection to the model comprises transmitting the first selection to a remote computing device that executes the model, the method further comprising:receiving the treatment protocol from the remote computing device.

62. The method of claim 60, further comprising executing the treatment protocol in connection with a dental patient to generate a treatment plan for the patient.

63. The method of claim 62, further comprising:generating one or more dental treatment appliance designs corresponding to the treatment plan; andproviding the one or more dental treatment appliance designs for manufacturing.

64. The method of claim 60, wherein the set of treatment categories comprises a set of dental conditions, comprising at least one of:tooth crowding;tooth spacing;shifted midline;anterior level;anterior-posterior relationship;posterior crossbite; oroverbite.

65. The method of claim 60, wherein the set of treatment categories comprises treatment options, comprising one or more of:interproximal reduction;placing pontics; orextracting teeth.

66. The method of claim 60, further comprising:providing, for display by the GUI, a model of example dentition, the model comprising indications of treatment areas of interest in association with one of the set of treatment categories.

67. The method of claim 60, further comprising:Attorney Docket No.: 28510.998 (L0773PCT)obtaining, for each of the set of treatment categories, either a selection from an associated set of treatment options or a default selection from the associated set of treatment options, wherein the treatment protocol comprises machine-readable instructions for each of the treatment categories.

68. The method of claim 60, further comprising:obtaining a natural language instruction associated with a dental treatment that is outside a scope of the set of treatment categories;providing the natural language instruction to an artificial intelligence (Al) model; obtaining from the Al model an update to the treatment protocol; andupdating the treatment protocol based on the update.

69. The method of claim 60, further comprising:obtaining dental data of a patient;determining that one or more aspects of dentition of the patient is outside a scope of the set of treatment categories based on the dental data;obtaining a natural language instruction associated with treatment of the patient; providing the natural language instruction to an artificial intelligence (Al) model; obtaining output from the Al model comprising either additional treatment protocol data or first treatment plan data; andgenerating a treatment plan for the patient based on the treatment protocol and either the additional treatment protocol data or the first treatment plan data.

70. A non-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 34-69.

71. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 34-69.

72. A method, comprising:obtaining first treatment provider instructions in natural language, the first treatment provider instructions associated with treatment of a dental patient;Attorney Docket No.: 28510.998 (L0773PCT)providing the first treatment provider instructions and a prompt comprising rules for a domainspecific format for dental treatment plans to a trained artificial intelligence (Al) model;obtaining, as output from the trained Al model, first machine-readable instructions related to the treatment provider instructions structured according to the domain-specific format; and causing a treatment planning algorithm to be adjusted based on the first machine-readable instructions.

73. The method of claim 72, wherein:providing the first treatment provider instructions and the prompt to the trained Al model comprises transmitting at least one of the first treatment provider instructions orthe prompt to a remote computing device that executes the trained Al model; andobtaining the first machine-readable instructions comprises receiving the first machine-readable instructions from the remote computing device.

74. The method of claim 73, wherein causing the treatment planning algorithm to be adjusted comprises:receiving confirmation to apply the first machine-readable instructions; andtransmitting the first machine-readable instructions to the remote computing device or a second remote computing device executing an orthodontic treatment planning application.

75. The method of claim 72, further comprising:obtaining second machine-readable instructions encoding treatment preferences of the treatment provider; andgenerating the treatment planning algorithm based on the second machine-readable instructions.

76. The method of claim 75, further comprising:obtaining treatment provider preferences in natural language; andgenerating the second machine-readable instructions based on the treatment provider preferences.

77. The method of claim 75, further comprising:Attorney Docket No.: 28510.998 (L0773PCT)obtaining a generic treatment planning algorithm, wherein generating the treatment planning algorithm comprises adjusting the generic treatment planning algorithm based on the second machine-readable instructions.

78. The method of claim 72, wherein the prompt comprises a set of classifications of treatment instruction categories, and one or more examples of machine-readable instructions.

79. The method of claim 72, further comprising performing treatment instruction validation on the first machine-readable instructions, wherein treatment instruction validation comprises determining that the first machine-readable instructions do not violate a set of treatment instruction heuristics.

80. The method of claim 72, further comprising:obtaining second treatment provider instructions in natural language;providing the second treatment provider instructions to the trained Al model;obtaining, as output from the trained Al model, second machine-readable instructions; performing treatment instruction validation on the second machine-readable instructions; and responsive to determining that the second machine-readable instructions violate one or more of a set of treatment instruction heuristics, provide the second treatment provider instructions to a manual treatment planning pipeline.

81. The method of claim 72, further comprising:obtaining dental data of the dental patient; andprocessing the dental data using the adjusted treatment planning algorithm to generate a treatment plan for the dental patient.

82. The method of claim 81 , further comprising causing one or more treatment appliances to be manufactured based on the treatment plan.

83. The method of claim 72, wherein the first machine-readable instructions are structured according to a language-independent data-interchange format schema that organizes the treatment provider instructions into distinct categories, each category representing a specific aspect of treatment planning.

84. The method of claim 72, further comprising:Attorney Docket No.: 28510.998 (L0773PCT)obtaining second machine-readable instructions encoding general treatment preferences of the treatment provider;determining a priority relationship between the first machine-readable instructions and the second machine-readable instructions; andadjusting the treatment planning algorithm such that the first machine-readable instructions override corresponding portions of the second machine-readable instructions.

85. A method, comprising:obtaining first instructions in a first machine-readable format configured to represent parameters for a treatment plan based on input data;obtaining second instructions in natural language corresponding to target adjustments to the first instructions;providing the second instructions to a trained artificial intelligence (Al) model;obtaining output from the trained Al model based on the second instructions, the output comprising third instructions in the first machine readable format or a second machine-readable format, the third instructions corresponding to the second instructions; andupdating the first instructions based on the third instructions.

86. The method of claim 85, wherein the treatment plan comprises a dental treatment plan.

87. The method of claim 85, wherein the target adjustments to the first instructions are based on a target dental patient.

88. The method of claim 85, wherein the first instructions encode preferences of a treatment provider, and wherein the second instructions comprise one or more deviations from the preferences of the treatment provider.

89. The method of claim 85, further comprising obtaining fourth instructions in a third machine-readable format associated with treatment preferences of a treatment provider, wherein the first instructions are based on the fourth instructions.

90. The method of claim 89, further comprising:obtaining fifth instructions in natural language, wherein the fifth instructions comprise the treatment preferences of the treatment provider;Attorney Docket No.: 28510.998 (L0773PCT)providing the fifth instructions to the trained Al model; andobtaining, as output from the trained Al model, the fourth instructions.

91. A method, comprising:obtaining, by a processing device, free-text treatment instructions from a treatment provider associated with a specific dental patient, the free-text treatment instructions expressed in natural language;providing the free-text treatment instructions and a prompt to a large language model (LLM), wherein the prompt includes a description of instruction categories and examples of machine-readable instructions corresponding to natural language instructions within each category;obtaining, as output from the LLM, case-specific machine-readable instructions in a structured format, the case-specific machine-readable instructions corresponding to the free-text treatment instructions;performing validation of the case-specific machine-readable instructions to determine compatibility with a treatment planning engine;responsive to determining that the case-specific machine-readable instructions are compatible with the treatment planning engine, providing the case-specific machine-readable instructions and patient data to the treatment planning engine; andgenerating, by the treatment planning engine, a treatment plan for the specific dental patient based on the case-specific machine-readable instructions.

92. The method of claim 91 , further comprising:obtaining general treatment protocol instructions associated with the treatment provider, the general treatment protocol instructions applicable to multiple patients; andcombining the case-specific machine-readable instructions with the general treatment protocol instructions, wherein the case-specific machine-readable instructions have a higher priority than the general treatment protocol instructions such that the case-specific machine-readable instructions override corresponding portions of the general treatment protocol instructions.

93. The method of claim 91 , wherein performing validation of the case-specific machine-readable instructions comprises:determining whether each instruction type in the case-specific machine-readable instructions is supported by the treatment planning engine;Attorney Docket No.: 28510.998 (L0773PCT)determining whether parameter values in the case-specific machine-readable instructions fall within predefined acceptable ranges; andresponsive to determining that an instruction type is unsupported or a parameter value falls outside an acceptable range, directing the free-text treatment instructions to a manualtreatment planning process.

94. The method of claim 91, wherein the structured format comprises a language-independent data-interchange format schema that organizes the case-specific machine-readable instructions into distinct categories, each category representing a specific aspect of treatment planning, and wherein the schema includes a default category for instructions that do not fit into predefined instruction categories.

95. The method of claim 91, wherein the free-text treatment instructions include a reference to one or more teeth expressed according to a first indexing scheme, and wherein the method further comprises:obtaining a three-dimensional model of dentition of the specific dental patient;sorting teeth of the three-dimensional model based on geometric position along a jaw arc; and mapping the reference to the one or more teeth to corresponding teeth in the sorted three-dimensional model based on the geometric position.

96. The method of claim 95, wherein the reference to the one or more teeth comprises one or more of:an interval specification identifying teeth between two specified teeth;a group specification identifying teeth belonging to an anatomical category;a relative position specification identifying teeth based on position relative to a reference tooth; oran exclusion specification identifying teeth by excluding specified teeth from a group.

97. The method of claim 95, wherein the three-dimensional model includes one or more of a supernumerary tooth or a missing tooth, and wherein mapping the reference to the one or more teeth accounts for the supernumerary tooth or the missing tooth based on the geometric position along the jaw arc.

98. A method, comprising:Attorney Docket No.: 28510.998 (L0773PCT)obtaining treatment provider instructions in natural language, wherein the treatment provider instructions are indicative of one or more differences between target dental treatment for a target dental patient and a set of treatment preferences associated with the treatment provider;obtaining a prompt comprising:a description of a plurality of categories of instructions associated with dental treatment, and a plurality of examples of machine-readable instructions corresponding to natural language instructions within the categories of instructions;providing the treatment provider instructions and the prompt as input to a trained artificial intelligence (Al) model;obtaining output from the trained Al model, the output comprising a machine-readable format that is a domain-specific format for orthodontic treatment; andgenerating a treatment plan based on the output from the trained Al model.

99. The method of claim 98, further comprising:generating a treatment algorithm based on output from the trained Al model; and obtaining patient data of the target dental patient, wherein generating the treatment plan comprises applying the treatment algorithm to the patient data.

100. The method of claim 99, further comprising obtaining a standard treatment algorithm, wherein generating the treatment algorithm comprises adjusting the standard treatment algorithm.

101. The method of claim 100, wherein the standard treatment algorithm is associated with the treatment preferences.

102. The method of claim 99, wherein the patient data comprises a three-dimensional model of dentition of the patient.

103. The method of claim 98, wherein the output from the trained Al model comprises machine-readable instructions associated with the first treatment provider instructions, and wherein the method further comprises:performing instruction validation; andresponsive to instruction validation, updating a treatment algorithm based on the output from the trained Al model.Attorney Docket No.: 28510.998 (L0773PCT)104. The method of claim 103, wherein instruction validation comprises determining that the machine-readable instructions to not violate one or more of a set of treatment instruction heuristics.

105. The method of claim 98, further comprising causing one or more treatment appliances to be manufactured based on the treatment plan.

106. A no n-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 72-105.

107. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 72-105.

108. A method, comprising:obtaining, by a processing device, first natural language instructions for treating dentition of a patient, the first natural language instructions comprising a first reference to a plurality of ordered teeth according to a first indexing scheme for at least one of teeth or inter-tooth intervals;providing the first natural language instructions and an accompanying prompt as input to an artificial intelligence (Al) model, wherein the prompt comprises a description of the first indexing scheme; andobtaining, as output from the Al model, first machine-readable instructions for treating the dentition of the patient, wherein the first machine-readable instructions comprise instructions associated with the plurality of ordered teeth, and wherein the first machine-readable instructions comprise a second reference to the plurality of ordered teeth according to a first machine-readable indexing scheme.

109. The method of claim 108, wherein:providing the natural language instructions and the accompanying promptto the Al model comprises transmitting at least one of the natural language instructions or the accompanying promptto a remote computing device that executes the Al model; andobtaining the first machine-readable instructions comprises receiving the first machine-readable instructions from the remote computing device.Attorney Docket No.: 28510.998 (L0773PCT)110. The method of claim 108, wherein the first indexing scheme comprises:a definition of individual tooth identifiers supporting multiple numbering systems;a definition of tooth groups representing anatomical categories;a definition of tooth intervals representing inclusive ranges between two teeth;a definition of relative tooth positions based on mesial or distal direction; andexclusion logic representing a group of exclusions using nested references to include and exclude sets of teeth.

111. The method of claim 108, wherein the prompt further comprises a description of a second indexing scheme.

112. The method of claim 111, wherein the first natural language instructions further comprise a third reference to the plurality of ordered teeth according to the second indexing scheme.

113. The method of claim 108, wherein the prompt further comprises an indication of a preferred indexing scheme associated with the plurality of ordered teeth.

114. The method of claim 108, further comprising associating indices of the first machine-readable indexing scheme to a three-dimensional model of the plurality of ordered teeth, wherein the ordered teeth of the three-dimensional model are indexed according to a second machine-readable indexing scheme, different than the first.

115. The method of claim 114, further comprising:segmenting the three-dimensional model to identify teeth in the three-dimensional model; sorting the identified teeth based on geometric position along a jaw arch;generating an array of teeth corresponding to the machine-readable instructions for treating the dentition of the patient; andmapping teeth of the array of teeth to the sorted teeth of the three-dimensional model.

116. The method of claim 115, further comprising:determining an array of interteeth intervals from the mapped teeth of the array of teeth.

117. The method of claim 108, wherein the first natural language instructions further comprise a fourth reference to a first space between two teeth of the plurality of ordered teeth, and wherein the firstAttorney Docket No.: 28510.998 (L0773PCT)machine-readable instructions comprise a fifth reference to the first space according to the first machine-readable indexing scheme.

118. The method of claim 108, wherein the first natural language instructions further comprise a sixth reference to a subset of the plurality of ordered teeth, and wherein the first machine-readable instructions comprise a seventh reference to the subset of the plurality of ordered teeth according to the first machine-readable indexing scheme.

119. The method of claim 108, wherein the Al model comprises a large language model.

120. The method of claim 108, further comprising performing validation of the first machine-readable instructions, wherein the validation comprises determining that the first machine-readable instructions do not violate a set of heuristics associated with the first machine-readable instructions.

121. The method of claim 108, wherein the first natural language instructions comprise an update to a dental treatment protocol with respect to a dental patient, and the plurality of ordered teeth comprise teeth ofthe dental patient.

122. The method of claim 108, further comprising:determining that the natural language instructions include a reference to an interproximal space between teeth;partitioning the mapped teeth into jaw-specific subarrays; andconstructing interteeth intervals between each pair of adjacent teeth within each jaw-specific subarray.

123. A method, comprising:obtaining, by a processing device, natural language treatment instructions from a treatment provider, the natural language treatment instructions including a reference to one or more teeth expressed according to a first indexing scheme;obtaining an indication of a preferred numbering system associated with the treatment provider;providing the natural language treatment instructions, the indication ofthe preferred numbering system, and a prompt to a large language model (LLM), wherein the prompt comprises:a definition of individual tooth identifiers supporting a plurality of numbering systems,Attorney Docket No.: 28510.998 (L0773PCT)a definition of tooth groups representing anatomical categories,a definition of tooth intervals representing inclusive ranges between specified teeth, a definition of relative tooth positions, andexclusion logic representing a group of exclusions using nested references to include and exclude sets of teeth;obtaining, as output from the LLM, machine-readable instructions in a structured format, the machine-readable instructions including a representation of the one or more teeth; and mapping the representation of the one or more teeth to a three-dimensional model of dentition of a dental patient.

124. The method of claim 123, wherein mapping the representation of the one or more teeth to the three-dimensional model comprises applying a matching predicate based on a type of representation, wherein:for individual teeth, a tooth is selected if its identifier matches an entry in themachine-readable instructions;for tooth groups, a tooth is selected if it belongs to a specified anatomical group, filtered by jaw and side;for intervals, a tooth is selected if its position lies between begin and end identifiers, inclusive; for relative positions, a tooth is selected if it is immediately mesial or distal to a referenced tooth based on arch geometry; andfor exclusion logic, a matching set is computed by subtracting excluded teeth from an included group.

125. The method of claim 123, wherein the natural language treatment instructions include a reference to an interproximal space, and wherein the method further comprises:partitioning mapped teeth into a first subarray for an upper jaw and a second subarray for a lowerjaw;for each subarray, iterating through teeth in order and constructing intervals between each pair of adjacent teeth; andapplying the constructed intervals to generate a treatment plan addressing the interproximal space.

126. The method of claim 123, wherein the three-dimensional model includes one or more of an unerupted tooth, a supernumerary tooth, or a pontic tooth, and wherein sorting the teeth based onAttorney Docket No.: 28510.998 (L0773PCT)geometric position accounts for the one or more of the unerupted tooth, the supernumerary tooth, or the pontic tooth.

127. The method of claim 123, wherein the prompt is extensible to allow addition of new examples and rules as clinical language evolves, and wherein the LLM produces output that conforms to a predefined schema and captures semantic intent of the natural language treatment instructions.

128. The method of claim 123, further comprising:determining that the machine-readable instructions include an unsupported instruction type or an ambiguous reference; andautomatically flagging the orthodontic case for manual review responsive to the determining.

129. The method of claim 123, wherein mapping the representation of the one or more teeth to the three-dimensional model comprises:sorting teeth of the three-dimensional model based on geometric position along a jaw arch, wherein an upper jaw is sorted from right to left along the arch and a lower jaw is sorted from left to rightalong the arch;caching the sorted teeth; andreusing the cached sorted teeth across multiple instructions within a same orthodontic case.

130. A method, comprising:obtaining first treatment provider instructions comprising first natural language instructions associated with treatment of a dental patient, the first natural language instructions comprising a first reference to one or more teeth of the dental patient expressed in accordance with a first indexing scheme for at least one of teeth or inter-tooth intervals;providing the first natural language instructions and an accompanying prompt as input to an artificial intelligence (Al) model, wherein the prompt comprises a description of the first indexing scheme;obtaining, as output from the Al model, first machine-readable instructions related to the treatment provider instructions comprising a first reference to a first tooth in accordance with a first machine-readable indexing scheme; andadjusting a treatment planning algorithm based on the first machine-readable instructions.Attorney Docket No.: 28510.998 (L0773PCT)131. The method of claim 130, wherein the prompt further comprises a description of a second indexing scheme, and wherein the first natural language instructions further comprise a second reference to one or more teeth of the dental patient expressed in accordance with the second indexing scheme.

132. The method of claim 130, further comprising performing treatment instruction validation on the first machine-readable instructions, wherein treatment instruction validation comprises determining that the first machine-readable instructions do not violate a set of treatment instruction heuristics.

133. The method of claim 130, further comprising:obtaining second treatment provider instructions in natural language;providing the second treatment provider instructions to the trained Al model;obtaining, as output from the trained Al model, third machine-readable instructions; performing treatment instruction validation on the third machine-readable instructions; and responsive to determining that the third machine-readable instructions violate one or more of a set of treatment instruction heuristics, provide the second treatment provider instructions to a manual treatment planning pipeline.

134. The method of claim 130, further comprising:obtaining dental data of the dental patient;mapping a first instruction associated with the first tooth to a second machine-readable indexing scheme associated with the dental data; andprocessing the dental data using the treatment planning algorithm in view of mapping the first instruction to the second machine-readable indexing scheme to generate a treatment plan for the dental patient.

135. The method of claim 134, further comprising causing one or more treatment appliances to be manufactured based on the treatment plan.

136. A method, comprising:obtaining treatment provider instructions in natural language indicative of one or more differences between target dental treatment for a target dental patient and a set of treatment preferences associated with the treatment provider, wherein the treatment provider instructionsAttorney Docket No.: 28510.998 (L0773PCT)comprise a first reference to one or more teeth of the dental patient expressed in accordance with a first indexing scheme;obtaining a prompt comprising:a description of the first indexing scheme,a description of a plurality of categories of instructions associated with dental treatment, and a plurality of examples of machine-readable instructions corresponding to natural language instructions within the categories of instructions;providing the treatment provider instructions and the prompt as input to an artificial intelligence (Al) model;obtaining output from the Al model comprising a second reference to the one or more teeth expressed in accordance with a second indexing scheme; andcausing a treatment plan to be generated based on the output from the Al model.

137. The method of claim 136, wherein the prompt further comprises a description of a second indexing scheme, and wherein the treatment provider instructions further comprise a second reference to one or more teeth of the dental patient expressed in accordance with the second indexing scheme.

138. The method of claim 136, further comprising:generating a treatment algorithm based on output from the trained Al model; and obtaining patient data of the target dental patient, wherein generating the treatment plan comprises applying the treatment algorithm to the patient data.

139. The method of claim 138, wherein the patient data comprises a three-dimensional model of the patient's dentition, and wherein the method further comprises mapping the second indexing scheme to a third indexing scheme of the three-dimensional model.

140. The method of claim 138, wherein the third indexing scheme is based on tooth identification, and wherein the second indexing scheme is based on jaw geometry of the dental patient.

141. The method of claim 136, further comprising performing treatment instruction validation on the output from the Al model, wherein treatment instruction validation comprises determining that the output from the Al model does not violate a set of treatment instruction heuristics.Attorney Docket No.: 28510.998 (L0773PCT)142. A non-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 108-141.

143. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 108-141.

144. A method, comprising:obtaining, by a processing device, a large language model (LLM) base prompt associated with a first target task;providing a first prompt generation request, comprising the LLM base prompt, a task description for a second target task different from the first task, a set of design principles associated with the first task, and one or more examples, as input to a first LLM;obtaining, as first output from the first LLM, a model-generated prompt for the second target task;providing the model-generated prompt and input associated with a specific instance of the second target task to a second LLM; andobtaining second output from the second LLM based on the model-generated prompt and the second target task.

145. The method of claim 144, wherein the first prompt generation request further comprises a set of unannotated, real-world examples that serve as semantic anchors defining a scope and nature of the second target task without prescribing specific outputs.

146. The method of claim 144, further comprising:storing the model-generated prompt in a prompt registry; andusing the model-generated prompt in one or more downstream pipelines for automated text understanding.

147. The method of claim 144, wherein the model-generated prompt includes:a detailed task description;a list of categories and subcategories to be extracted;interpretation rules for linguistic patterns and edge cases;Attorney Docket No.: 28510.998 (L0773PCT)output formatting requirements including adherence to a schema; andguidance for handling ambiguous or compound instructions.

148. The method of claim 144, wherein:providing the first prompt generation request to the first LLM comprises transmitting the first prompt generation request to a remote computing device that executes the first LLM;obtaining the model-generated prompt comprises receiving the model-generated promptfrom the remote computing device;providing the model-generated prompt and the input associated with the specific instance of the second target task to the second LLM comprises transmitting the model-generated prompt and the input to the remote computing device or a second remote computing device that executes the second LLM; andobtaining the output from the second LLM comprises receiving the second output from the remote computing device or the second remote computing device.

149. The method of claim 144, wherein the set of design principles comprises a description of target properties for the model-generated prompt,.

150. The method of claim 144, further comprising:obtaining second output from the first LLM prior to obtaining the first output, the second output comprising a preliminary model-generated prompt;performing review and refinement analysis of the preliminary model-generated prompt to refine the preliminary model-generated prompt and generate the model-generated prompt.

151. The method of claim 150, wherein the review and refinement analysis is performed iteratively across multiple cycles, wherein each cycle processes a focused subset of representative data and key insights are explicitly carried forward between cycles to overcome context window limitations of the first LLM.

152. The method of claim 151, wherein the one or more examples comprise a plurality of examples, and wherein the review and refinement analysis comprises:generating a schema by the first LLM based on processing of the first prompt generation requestor a subsequent prompt generation request;Attorney Docket No.: 28510.998 (L0773PCT)evaluating the schema by the first LLM by processing the plurality ofexamples in view of the schema;determining, based on a result of the evaluating:whether the schema captures semantics of the first prompt generation request or the subsequent prompt generation request;whether any use cases are not covered or are misrepresented; andwhether any inconsistencies are present.

153. The method of claim 152, wherein one or more first examples of the plurality ofexamples are evaluated using a first instance of the first LLM in parallel with one or more second examples of the plurality ofexamples being evaluated using a second instance of the first LLM.

154. The method of claim 152, further comprising:identifying one or more weaknesses of the schema;suggesting one or more improvements to the schema to address the one or more weaknesses, wherein the one or more improvements comprise at least one of:a clarification of one or more edge cases;addition of an additional rule; oraddition of an additional example.

155. The method of claim 152, further comprising:repeating the review and refinement analysis in an iterative manner until the schema satisfies one or more criteria, wherein the schema is refined with each iteration of the review and refinement analysis.

156. The method of claim 144, further comprising:validating the model-generated prompt by applying the model-generated promptto at least some of the one or more examples and confirming that an output has a structure that conforms to a schema defined in the base prompt.

157. The method of claim 144, wherein the second target task comprises generating machine-readable instructions , and wherein the method further comprises executing the output from the second LLM comprising the machine-readable instructions.Attorney Docket No.: 28510.998 (L0773PCT)158. The method of claim 157, wherein the second target task comprises generating machine-readable treatment planning instructions for a dental treatment, and wherein executing the output from the second LLM comprises generating a treatment plan for a dental patient.

159. The method of claim 158, further comprising:generating manufacturing data for one or more dental treatment appliances associated with the treatment plan; andmanufacturing the one or more dental treatment appliances in accordance with the manufacturing data.

160. The method of claim 144, wherein the first target task comprises assigning portions of input text to a first set of categories, and wherein the second target task comprises developing a second set of categories based on additional input text, wherein the second set of categories shares one or more categories with the first set of categories.

161. A method, comprising:obtaining, by a processing device, a base prompt configured to cause a large language model (LLM) to assign portions of natural language input to a first set of categories;providing a first prompt generation request, comprising the base prompt and a description of a target task comprising generation of a second set of categories to augment the first set of categories, as input to a first LLM;obtaining, as output from the first LLM, a model-generated prompt;providing the model-generated prompt and first input comprising natural language associated with the target task to a second LLM; andobtaining output from the second LLM based on the model-generated prompt, wherein the output comprises assignment of portions of the first input to the second set of categories.

162. The method of claim 161 , wherein the natural language input comprises a set of instructions, and wherein the first set of categories comprise categories that the instructions may belong to.

163. The method of claim 162, wherein the natural language input comprises instructions related to healthcare treatment of a patient.Attorney Docket No.: 28510.998 (L0773PCT)164. The method of claim 163, wherein the natural language input comprises instructions related to dental treatment of the patient.

165. The method of claim 161, wherein the prompt generation request further comprises a description of target properties of the model-generated prompt.

166. The method of claim 161 , wherein the prompt generation request further comprises one or more examples of natural language inputthat may be provided that is to be categorized into a category that the first set of categories does not comprise.

167. The method of claim 161 , further comprising:obtaining second output from the first LLM based on a second prompt generation request; providing the second output, comprising a preliminary model-generated prompt, and the second prompt generation request for review and refinement analysis; andobtaining the first prompt generation request based on the review and refinement analysis of the second output.

168. The method of claim 161, further comprising providing the model-generated promptfor validation, wherein providing the model-generated prompt to the second LLM is performed based on the validation.

169. The method of claim 161 , further comprising providing instructions assigned to one or more categories by the second LLM to a third LLM, and obtaining output from the third LLM comprising machine-readable instructions associated with the natural language instructions.

170. The method of claim 169, further comprising executing the machine-readable instructions.

171. The method of claim 170, wherein the machine-readable instructions comprise instructions for performing orthodontic treatment planning, and wherein the method further comprises:generating, based on the machine-readable instructions, manufacturing data for one or more orthodontic appliances; andmanufacturing the one or more orthodontic appliances.

172. A method, comprising:Attorney Docket No.: 28510.998 (L0773PCT)obtaining, by a processing device, a base prompt configured to cause a large language model (LLM) to convert natural language dental treatment instructions into a structured, machine-readable format;obtaining a task description for a dental text processing task, the task description specifying a target type of dental treatment instructions to be processed;obtaining a set of design principles specifying structural and behavioral requirements for a model-generated prompt, the design principles including a target output schema for dental treatment data;obtaining a set of unannotated dental treatment instructions from treatment providers, the unannotated dental treatment instructions illustrating inputs the model-generated prompt is expected to handle;providing the base prompt, the task description, the set of design principles, and the set of unannotated dental treatment instructions as input to a first LLM;obtaining, as output from the first LLM, an initial schema comprising a structured representation of dental treatment categories, treatment parameters, and formatting rules;performing iterative review and refinement of the initial schema using the first LLM, wherein each iteration processes at least a subset of the unannotated dental treatment instructions and carries forward key insights to subsequent iterations;generating, based on the refined schema, the model-generated promptfor the dental text processing task; andvalidating the model-generated prompt by applying the model-generated prompt to test dental treatment instructions and confirming that output conforms to the refined schema.

173. The method of claim 172, wherein performing iterative review and refinement comprises:passing a batch of the unannotated dental treatment instructions through the initial schema; analyzing outputs to assess how well the schema captures semantics of the unannotated dental treatment instructions;identifying dental treatment instruction types that are not covered or are misinterpreted; identifying ambiguities or inconsistencies in dental terminology interpretation; and refining the schema based on the analysis.

174. The method of claim 172, wherein performing iterative review and refinementfurther comprises:Attorney Docket No.: 28510.998 (L0773PCT)using the first LLM to identify weaknesses in the schema related to dental treatment instruction interpretation; andusing the first LLM to suggest improvements to the schema, wherein the improvements comprise one or more of refining dental treatment categories, clarifying edge cases involving dental terminology, or adding missing rules and examples for dental treatment instructions.

175. The method of claim 172, wherein the model-generated prompt comprises:a detailed task description for converting dental treatment instructions to machine-readable format;a list of dental treatment categories and subcategories to be extracted, the categories including one or more of tooth movement instructions, attachment instructions, interproximalreduction instructions, or staging instructions;interpretation rules for dental terminology and clinical language patterns;output formatting requirements including adherence to a schema for dental treatment data; input and output format specifications with dental treatment instruction examples; and guidance for handling ambiguous or compound dental treatment instructions.

176. The method of claim 172, further comprising:storing the validated model-generated prompt in a prompt registry; andproviding the model-generated promptfor use in one or more dental treatment planning pipelines to convert treatment provider instructions into machine-readable treatment planning instructions.

177. The method of claim 172, wherein the set of design principles comprises one or more of:a required output format for dental treatment data;dental treatment categories to be extracted including orthodontic treatment parameters; expected robustness to variation in dental terminology and tooth numbering systems; extensibility requirements for accommodating new dental treatment instruction types; or mandatory inclusion of representative dental treatment instruction examples.

178. The method of claim 172, wherein the target type of dental treatment instructions comprises one or more of:case-specific treatment instructions fora particular dental patient;Attorney Docket No.: 28510.998 (L0773PCT)treatment modification instructions requesting changes to an existing dental treatment plan; orthodontic finishing instructions specifying final tooth positioning requirements; or clinical protocol instructions specifying treatment preferences applicable to multiple patients.

179. A no n-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 144-178.

180. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 144-178.

181. A method, comprising:obtaining, by a processing device, first treatment instructions for a target dental treatment of a patient;determining that the first treatment instructions comprise one or more manual comments in a natural language format;processing the treatment instructions using a classification model, wherein the classification model categorizes the first treatment instructions into one or more dental treatment categories;determining that each of the one or more dental treatment categories belongs to a specified subset of dental treatment categories;responsive to determining that the one or more dental treatment categories belong to the specified subset of dental treatment categories, providing at least a portion of the first treatment instructions and a prompt to a large language model (LLM) to cause the LLM to generate machine-readable instructions corresponding to the specified subset of dental treatment categories; and obtaining the machine-readable instructions corresponding to the treatment instructions from the LLM.

182. The method of claim 181 , wherein:providing the at least the portion of the first treatment instructions and the prompt to the LLM comprises transmitting at least one of the portion of the first treatment instructions or the prompt to a remote computing device that executes the LLM; andobtaining the machine-readable instructions comprises receiving the machine-readable instructions from the remote computing device.Attorney Docket No.: 28510.998 (L0773PCT)183. The method of claim 181, further comprising performing treatment planning operations for the target dental treatment based on the machine-readable instructions.

184. The method of claim 183, further comprising:generating manufacturing data for one or more treatment appliances based on the treatment planning operations; andcausing the one or more treatment appliances to be manufactured based on the manufacturing data.

185. The method of claim 181 , further comprising:obtaining second treatment instructions;determining, using the classification model, that the second treatment instructions comprise instructions belonging to a dental treatment category other than the specified subset of dental treatment categories; andproviding the second treatment instructions for manual processing.

186. The method of claim 181 , wherein the LLM is configured to accept instructions belonging to the specified subset of dental treatment categories as input.

187. The method of claim 181 , further comprising determining, using the classification model, that the first treatment instructions comprise one or more instructions belonging to a treatment category not included in the specified subset of dental treatment categories, wherein the one or more instructions are not used in generating the machine-readable instructions.

188. The method of claim 181 , wherein the machine-readable instructions comprise instructions for placement of attachments to one or more teeth of a patient for the target dental treatment of the patient.

189. The method of claim 181 , wherein the LLM extracts teeth identifiers of one or more teeth to receive attachments, one or more treatment stages at which to place the attachments, one or more treatment actions to be performed, and attachment types for the attachments.

190. The method of claim 181 , wherein the machine-readable instructions comprise a text-based schema.Attorney Docket No.: 28510.998 (L0773PCT)191. The method of claim 181 , further comprising:determining that the first treatment instructions include terminology variations or misspellings of attachment-related terms; andnormalizing the terminology variations or misspellings to standard attachment terminology prior to generating the machine-readable instructions.

192. The method of claim 181 , wherein the machine-readable instructions include stage information represented in one or more formats comprising: a first stage indicator representing a beginning of treatment, a last stage indicator representing an end of treatment, a literal stage number, an offset value representing a number of stages relative to a reference stage, or a time indicator specifying whether an action is to be applied before or after a specified stage.

193. A method, comprising:obtaining, by a processing device, first natural language instructions from a treatment provider comprising target updates to a target dental treatment;providing the first natural language instructions to a first large language model (LLM), wherein the first large language model is configured to categorize natural language instructions;determining, using the first LLM, that a first category of instructions is not present in the first natural language instructions associated with dental treatment;providing at least a portion of the first natural language instructions and a prompt configured to cause a second LLM to generate machine-readable instructions corresponding to natural language instructions to the second LLM; andobtaining machine-readable instructions corresponding to the first natural language instructions from the second LLM.

194. The method of claim 193, further comprising integrating the machine-readable instructions into treatment planning operations.

195. The method of claim 194, further comprising causing one or more treatment appliances to be manufactured based on the treatment planning operations.

196. The method of claim 193, further comprising:obtaining second natural language instructions;Attorney Docket No.: 28510.998 (L0773PCT)determining, using the first LLM, that the second natural language instructions comprise instructions belonging to the first category of instructions; andproviding the second natural language instructions for manual processing.

197. The method of claim 193, further comprising determining, using the first LLM, that the first natural language instructions comprise instructions belonging to a second category of instructions, wherein the second LLM is configured to accept instructions belonging to the second category of instructions as input.

198. The method of claim 193, further comprising determining, using the first LLM, that the first natural language instructions comprise instructions belonging to a third category of instructions, wherein the third category of instructions comprises instructions that are not to be included in the target treatment.

199. The method of claim 193, wherein the machine-readable instructions comprise updates to one or more treatment plan parameters for the target dental treatment.

200. The method of claim 199, wherein the one or more treatment plan parameters comprise dental appliance features for one or more dental appliances to be used for the target dental treatment.

201. The method of claim 200, wherein the dental appliance features comprise at least one of attachments, bite ramps, eruption compensation, or geometric appliance features.

202. The method of claim 200, wherein the dental appliance features comprise mandibular advancement features selected from at least one of buccal blocks or occlusal blocks.

203. The method of claim 199, wherein the one or more treatment plan parameters comprise one or more planning targets.

204. The method of claim 203, wherein the one or more planning targets comprise at least one of intended final positions for one or more teeth, tooth velocities for one or more teeth, target treatment outcome, number of treatment stages, treatment plan staging, amount of overcorrection, and whether to apply passive aligners.Attorney Docket No.: 28510.998 (L0773PCT)205. A method, comprising:obtaining, by a processing device, first natural language instructions from a treatment provider associated with a target dental treatment;providing the first natural language instructions to a classification model;determining, using the classification model, that a first category of instructions is not present in the first natural language instructions, and that a second category of instructions is present in the first natural language instructions;providing at least a portion of the first natural language instructions and a prompt configured to cause a large language model (LLM) to generate machine-readable instructions corresponding to natural language instructions to the LLM;obtaining machine-readable instructions corresponding to the first natural language instructions from the LLM;updating a treatment plan to generate an updated treatment plan associated with the target dental treatment based on the machine-readable instructions; andproviding a representation of the updated treatment plan for treatment provider review.

206. The method of claim 205, wherein the representation of the updated treatment plan comprises one or more of:a natural language description of the updated treatment plan;a medical algorithm depicting the updated treatment plan; ora visualization of a three-dimensional model depicting predicted properties of dentition associated with the updated treatment plan.

207. The method of claim 205, further comprising:obtaining an indication that the updated treatment plan has been accepted;generating manufacturing data for one or more treatment appliances in view of the updated treatment plan being accepted; andcausing the one or more treatment appliances to be manufactured.

208. The method of claim 205, wherein the at least a portion of the first natural language instructions comprise instructions belonging to the second category of instructions.

209. The method of claim 208, wherein the second category of instructions comprises instructions associated with dental features.Attorney Docket No.: 28510.998 (L0773PCT)210. The method of claim 208, further comprising:determining, using the classification model, that a third category of instructions is present in the first natural language instructions, wherein the third category of instructions comprises instructions that are not applicable to the treatment plan; andexcluding instructions belonging to the third category of instructions from the at least a portion of the first natural language instructions provided to the LLM.

211. The method of claim 205, further comprising:obtaining second natural language instructions;determining, using the classification model, that the second natural language instructions comprise instructions belonging to the first category of instructions; andproviding the second natural language instructions for manual processing.

212. A method, comprising:obtaining, by a processing device, treatment modification comments from a treatment provider associated with a dental treatment, the treatment modification comments expressed in natural language;providing the treatment modification comments to a classification model configured to categorize natural language instructions into a plurality of treatment categories;determining, using the classification model, that the treatment modification comments include instructions belonging to a dental features category and do not include instructions belonging to categories that require manual processing;providing the treatment modification comments to a specialized interpretation model configured to extract attachment-related parameters from natural language instructions;obtaining, from the specialized interpretation model, machine-readable instructions comprising one or more of teeth identifiers, treatment stages, attachment actions, or attachment types;performing postprocessing validation on the machine-readable instructions to confirm compatibility with a treatment planning system; andapplying the machine-readable instructions to update the dental treatment.

213. The method of claim 212, further comprising:determining that the treatment modification comments include terminology variations or misspellings of attachment-related terms; andnormalizing the terminology variations or misspellings to standard attachment terminology;Attorney Docket No.: 28510.998 (L0773PCT)wherein the attachment actions comprise one or more of add, remove, keep, replace, or modify.

214. The method of claim 212, further comprising:determining that the treatment modification comments are expressed in a non-English language; andtranslating the treatment modification comments to English in the machine-readable instructions.

215. A non-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 181-214.

216. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 181 -214.

217. A method, comprising:providing a chat interface associated with a treatment protocol or a treatment plan for a dental treatment;obtaining, via the chat interface, first natural language comments associated with an update to one of the treatment protocol or the treatment plan;converting the first natural language comments into one or more proposed structured, valid protocol changes for the treatment protocol or the dental treatment;generating a preview and human-readable explanations of the one or more proposed structured, valid protocol changes;outputting the preview and the human-readable explanations of the one or more proposed structured, valid protocol changes; andresponsive to receiving confirmation to implement the one or more proposed structured, valid protocol changes, updating the treatment protocol or the dental treatment.

218. The method of claim 217, wherein the one or more proposed structured, valid protocol changes comprise adjustments to one or more fields that correspond deterministically to machine-readable code.Attorney Docket No.: 28510.998 (L0773PCT)219. The method of claim 217, wherein the converting and the generating are performed by a large language model (LLM).

220. The method of claim 219, further comprising providing a library of machine-implementable instructions to the LLM.

221. The method of claim 217, wherein the one or more proposed structured, valid protocol changes comprise adjustments to machine-readable code to be applied to the treatment protocol or treatment plan.

222. The method of claim 217, wherein the first natural language comments are associated with an update to the treatment protocol, and wherein the method further comprises:obtaining, by the processing device, second natural language comments associated with an update to the treatment plan that is a specific application of the treatment protocol to a patient;converting the second natural language comments into one or more additional structured, valid protocol changes for the dental treatment;generating a second preview of the one or more additional proposed structured, valid protocol changes;outputting the second preview and human-readable explanations of the one or more additional proposed structured, valid protocol changes; andresponsive to receiving confirmation to implement the one or more additional proposed structured, valid protocol changes, updating the dental treatment.

223. The method of claim 222, wherein obtaining the first natural language comments and obtaining the second natural language comments is performed via a text entry field of a graphical user interface.

224. The method of claim 223, further comprising:obtaining third natural language comments prior to receiving the first natural language instructions;providing, via the graphical user interface, a prompt to provide additional information; and obtaining the first natural language instructions in view of the prompt.Attorney Docket No.: 28510.998 (L0773PCT)225. The method of claim 222, wherein at least a portion of the first natural language comments are provided to a large language model (LLM) as additional context with the second natural language comments.

226. The method of claim 217, wherein the chat interface is configured to operate at a plurality of protocol levels comprising:a prescription level for modifications specific to a single patient;a global clinical protocol level for modifications applicable to all patients of the treatment provider; anda personal protocol level for customized treatment preferences of the treatment provider.

227. The method of claim 217, further comprising:causing the conversational assistant to automatically manipulate one or more graphical user interface elements to effect the one or more proposed structured, valid protocol changes, wherein the manipulation is visible to the treatment provider.

228. The method of claim 217, further comprising:detecting that the treatment provider has requested a same or similar change across a plurality of patients;generating a recommendation to apply the change to a global treatment protocol applicable to future patients; andresponsive to obtaining confirmation from the treatment provider, updating the global treatment protocol.

229. The method of claim 217, further comprising:maintaining the one or more proposed structured, valid protocol changes in a draft state prior to receiving confirmation; andpublishing the one or more proposed structured, valid protocol changes to an active protocol state responsive to receiving confirmation.

230. A method, comprising:obtaining, by a processing device, first natural language instructions associated with an update to one of a dental treatment protocol or a dental treatment plan;providing the first natural language instructions to a large language model (LLM);Attorney Docket No.: 28510.998 (L0773PCT)obtaining, from the LLM, machine-implementable instructions corresponding to the first natural language instructions; andcausing dental treatment planning operations to be performed based on the machine-implementable instructions.

231. The method of claim 230, wherein:providing the first natural language instructions to the LLM comprises transmitting the first natural language instructions to a remote computing device that executes the LLM; andobtaining the machine-implementable instructions comprises receiving the machine-implementable instructions from the remote computing device.

232. The method of claim 230, further comprising:obtaining a natural language inquiry associated with the dental treatment protocol or dental treatment plan;providing the natural language inquiry to the LLM;obtaining, from the LLM, an explanation based on the natural language inquiry;providing the explanation for review, wherein the first natural language instructions are provided in view of the explanation.

233. The method of claim 232, further comprising providing documentation comprising a library of machine-implementable instructions and associated explanations to the LLM, wherein the explanation based on the natural language inquiry is generated based on the documentation.

234. The method of claim 233, wherein the LLM is configured to limit machine-implementable instructions output by the LLM to instructions in the documentation.

235. The method of claim 230, further comprising performing verification operations on the machine-implementable instructions, comprising determining that the machine-implementable instructions adhere to existing safety heuristics, wherein performing the dental treatment planning operations is further based on the verification operations.

236. The method of claim 230, further comprising manufacturing one or more dental treatment appliances based on the dental treatment planning operations.Attorney Docket No.: 28510.998 (L0773PCT)237. A method, comprising:providing, via a graphical user interface (GUI), a free text entry element for providing instructions associated with updates to a treatment plan;obtaining first natural language instructions associated with updating a target treatment plan via the free text entry element;converting the first natural language instructions into structured, valid protocol comments fora dental treatment protocol;providing the first natural language instructions to a large language model (LLM) to generate machine-readable instructions comprising updates to the target treatment plan corresponding to the first natural language instructions; andimplementing the machine-readable instructions by performing treatment planning operations.

238. The method of claim 237, further comprising:obtaining second natural language instructions via the free text entry element;providing the second natural language instructions to the LLM;obtaining, from the LLM, a clarifying inquiry associated with the second natural language instructions;providing the clarifying inquiry; andresponsive to providing the clarifying inquiry, obtaining via the free text entry element the first natural language instructions.

239. The method of claim 237, further comprising:determining that a treatment protocol may be updated based on the first natural language instructions or the machine-readable instructions;providing a prompt comprising a proposed update of the treatment protocol;obtaining a response to the prompt via the free text entry element;determining, using the LLM, that the response to the prompt comprises confirmation of the proposed update; andperforming the proposed update responsive to obtaining the response.

240. The method of claim 237, further comprising providing an indication of the machine-readable instructions for review via the GUI, wherein implementing the machine-readable instructions is performed based on obtaining confirmation responsive to providing the indication of the machine-readable instruction for review.Attorney Docket No.: 28510.998 (L0773PCT)241. The method of claim 237, further comprising providing a library of machine-implementable instructions to the LLM, wherein the LLM generates the machine-readable instructions by performing retrieval augmented generation in view of the library.

242. The method of claim 237, further comprising manufacturing one or more treatment appliances based on the treatment planning operations.

243. A method, comprising:providing, by a processing device, a conversational assistant interface for a treatment provider to interact with a dental treatment planning system using natural language;obtaining, via the conversational assistant interface, a natural language request from the treatment provider associated with modifying one or more treatment parameters;determining a protocol level at which the modification is to be applied, the protocol level comprising one of a patient-specific prescription level, a global clinical protocol level applicable to multiple patients, ora personal protocol level customized to the treatment provider;generating, using a large language model (LLM) constrained to operate within predefined protocol rules, one or more proposed modifications corresponding to the natural language request; providing, via a graphical user interface (GUI), a preview of the one or more proposed modifications in a draft state;obtaining, via the GUI, confirmation or rejection of each of the one or more proposed modifications; andresponsive to obtaining confirmation, publishing the confirmed modifications to an active protocol state at the determined protocol level.

244. The method of claim 243, wherein generating the one or more proposed modifications comprises:constraining output of the LLM to only include modifications that are valid within a predefined set of protocol commands; andproviding the LLM with access to a library of protocol documentation including available treatment options and protocol constraints.

245. The method of claim 243, further comprising:Attorney Docket No.: 28510.998 (L0773PCT)causing the conversational assistant to automatically manipulate one or more GUI elements to effect the confirmed modifications, wherein the manipulation comprises opening dropdown menus, selecting options, and clicking on interface elements visible to the treatment provider.

246. The method of claim 243, further comprising:detecting that the natural language request corresponds to a modification at the patientspecific prescription level;determining that the modification is applicable to multiple patients;generating a recommendation to promote the modification to the global clinical protocol level; andresponsive to obtaining confirmation of the recommendation, updating the global clinical protocol to include the modification.

247. The method of claim 243, further comprising:maintaining session context data associated with the treatment provider, the session context data comprising a history of prior natural language requests and corresponding modifications;detecting that the treatment provider has requested a same or similar modification across a plurality of patient treatments; andgenerating a recommendation to apply the modification to the global clinical protocol level based on the detected pattern.

248. The method of claim 243, wherein generating the one or more proposed modifications comprises:recognizing, by the LLM, a start of a command sequence in the natural language request; and triggering a predefined command sequence to complete the modification, wherein the predefined command sequence comprises a series of GUI manipulations associated with the recognized command.

249. The method of claim 243, further comprising:obtaining a query from the treatment provider regarding a treatment option or clinical terminology;accessing, by the LLM, a library of clinical explanations including tool tips from the treatment planning system; andAttorney Docket No.: 28510.998 (L0773PCT)providing, via the conversational assistant interface, a natural language explanation responsive to the query using terminology specific to the treatment planning system.

250. A non-transitory computer readable medium comprising instructions that, when executed by a processing device, cause the processing device to perform the method of any of claims 217-249.

251. A system comprising:one or more computing device each comprising a memory and one or more processors, wherein the one or more computing devices are configured to perform the method of any of claims 217-249.

Images