CN112367945A - Generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument according thereto - Google Patents
Generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument according thereto Download PDFInfo
- Publication number
- CN112367945A CN112367945A CN201980045508.4A CN201980045508A CN112367945A CN 112367945 A CN112367945 A CN 112367945A CN 201980045508 A CN201980045508 A CN 201980045508A CN 112367945 A CN112367945 A CN 112367945A
- Authority
- CN
- China
- Prior art keywords
- patient
- medical instrument
- treatment plan
- engine
- dynamic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000011282 treatment Methods 0.000 title claims abstract description 414
- 238000000034 method Methods 0.000 claims abstract description 65
- 238000010146 3D printing Methods 0.000 claims abstract description 52
- 238000004519 manufacturing process Methods 0.000 claims abstract description 31
- 238000012545 processing Methods 0.000 claims description 81
- 238000004891 communication Methods 0.000 claims description 79
- 238000007726 management method Methods 0.000 claims description 59
- 238000002203 pretreatment Methods 0.000 claims description 26
- 238000010801 machine learning Methods 0.000 claims description 22
- 238000013439 planning Methods 0.000 claims description 21
- 238000013461 design Methods 0.000 claims description 16
- 238000012552 review Methods 0.000 claims description 15
- 238000007639 printing Methods 0.000 claims description 12
- 239000003999 initiator Substances 0.000 claims description 8
- 239000012190 activator Substances 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 89
- 239000007858 starting material Substances 0.000 description 19
- 230000011218 segmentation Effects 0.000 description 18
- 238000013500 data storage Methods 0.000 description 17
- 238000003860 storage Methods 0.000 description 16
- 238000012384 transportation and delivery Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 10
- 238000013528 artificial neural network Methods 0.000 description 8
- 238000003066 decision tree Methods 0.000 description 8
- 238000013135 deep learning Methods 0.000 description 8
- 210000000214 mouth Anatomy 0.000 description 8
- 230000008569 process Effects 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 210000003128 head Anatomy 0.000 description 5
- 210000003625 skull Anatomy 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 239000008186 active pharmaceutical agent Substances 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 239000002537 cosmetic Substances 0.000 description 3
- 230000002349 favourable effect Effects 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 238000007689 inspection Methods 0.000 description 3
- 239000000463 material Substances 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 238000003384 imaging method Methods 0.000 description 2
- 230000001902 propagating effect Effects 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 230000004580 weight loss Effects 0.000 description 2
- 206010006326 Breath odour Diseases 0.000 description 1
- 102000004190 Enzymes Human genes 0.000 description 1
- 108090000790 Enzymes Proteins 0.000 description 1
- 208000032139 Halitosis Diseases 0.000 description 1
- 241000699670 Mus sp. Species 0.000 description 1
- 208000009782 Plagiocephaly Diseases 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000003190 augmentative effect Effects 0.000 description 1
- 230000003796 beauty Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000009223 counseling Methods 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- 238000012938 design process Methods 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 229940079593 drug Drugs 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007717 exclusion Effects 0.000 description 1
- 238000002474 experimental method Methods 0.000 description 1
- 230000001815 facial effect Effects 0.000 description 1
- 208000007565 gingivitis Diseases 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 230000007721 medicinal effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000007781 pre-processing Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 102000004169 proteins and genes Human genes 0.000 description 1
- 108090000623 proteins and genes Proteins 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 210000000130 stem cell Anatomy 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 208000011580 syndromic disease Diseases 0.000 description 1
Images
Classifications
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61C—DENTISTRY; APPARATUS OR METHODS FOR ORAL OR DENTAL HYGIENE
- A61C13/00—Dental prostheses; Making same
- A61C13/0003—Making bridge-work, inlays, implants or the like
- A61C13/0006—Production methods
- A61C13/0019—Production methods using three dimensional printing
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
- G16H20/30—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to physical therapies or activities, e.g. physiotherapy, acupressure or exercising
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61C—DENTISTRY; APPARATUS OR METHODS FOR ORAL OR DENTAL HYGIENE
- A61C7/00—Orthodontics, i.e. obtaining or maintaining the desired position of teeth, e.g. by straightening, evening, regulating, separating, or by correcting malocclusions
- A61C7/002—Orthodontic computer assisted systems
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61C—DENTISTRY; APPARATUS OR METHODS FOR ORAL OR DENTAL HYGIENE
- A61C7/00—Orthodontics, i.e. obtaining or maintaining the desired position of teeth, e.g. by straightening, evening, regulating, separating, or by correcting malocclusions
- A61C7/08—Mouthpiece-type retainers or positioners, e.g. for both the lower and upper arch
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B33—ADDITIVE MANUFACTURING TECHNOLOGY
- B33Y—ADDITIVE MANUFACTURING, i.e. MANUFACTURING OF THREE-DIMENSIONAL [3-D] OBJECTS BY ADDITIVE DEPOSITION, ADDITIVE AGGLOMERATION OR ADDITIVE LAYERING, e.g. BY 3-D PRINTING, STEREOLITHOGRAPHY OR SELECTIVE LASER SINTERING
- B33Y50/00—Data acquisition or data processing for additive manufacturing
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B33—ADDITIVE MANUFACTURING TECHNOLOGY
- B33Y—ADDITIVE MANUFACTURING, i.e. MANUFACTURING OF THREE-DIMENSIONAL [3-D] OBJECTS BY ADDITIVE DEPOSITION, ADDITIVE AGGLOMERATION OR ADDITIVE LAYERING, e.g. BY 3-D PRINTING, STEREOLITHOGRAPHY OR SELECTIVE LASER SINTERING
- B33Y80/00—Products made by additive manufacturing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N20/00—Machine learning
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
Abstract
The invention relates to a system and a method for generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument set according to the 3D printed medical instrument treatment plan, the method comprising: generating a dynamic 3D printing medical instrument treatment plan generation model; obtaining a patient record; receiving 3D scan data of a patient; generating a 3D printed medical instrument treatment plan by applying the patient record and the 3D scan data to a dynamic 3D printed medical instrument treatment plan generation model; providing a 3D printed medical instrument treatment plan to a healthcare practitioner; providing a manufacturing request to a manufacturer system for manufacturing a 3D printed medical instrument set; providing a 3D printed medical instrument set to a patient; receiving feedback from a healthcare practitioner regarding the 3D printed medical instrument treatment plan; the dynamic 3D printed medical instrument treatment plan generation model is modified based on the feedback.
Description
Drawings
Fig. 1 is a block diagram of an example of a system for providing medical treatment including a 3D printed medical instrument.
Fig. 2 is a block diagram of an example of a patient system included in a system for providing medical treatment including a 3D printed medical instrument.
Figure 3 is a block diagram of an example of a healthcare practitioner system included in a system for providing medical treatment that includes a 3D printed medical instrument.
Fig. 4 is a block diagram of an example of a patient-specific 3D medical instrument manufacturer system included in a system for providing medical treatment including a 3D printed medical instrument.
Fig. 5 is a block diagram of an example of a dynamic 3D printed medical device treatment system for providing a practitioner matching recommendation service.
Fig. 6 is a block diagram of an example of a dynamic 3D printing modality handling system for providing a practitioner referral auction service.
Fig. 7 is a block diagram of an example of a dynamic 3D printed medical instrument treatment system for providing a 3D medical instrument treatment plan.
Fig. 8 is a block diagram of an example of a dynamic 3D printing medical instrument handling system for providing a 3D medical instrument manufacturer selection service.
Fig. 9 is a block diagram of an example of an ad broker system included in a system for providing medical treatment that includes a 3D printed medical instrument.
Fig. 10 is a flowchart of an example of a method for providing a practitioner matching recommendation service.
Figure 11 is a flow chart of an example of a method for providing a practitioner referral auction service.
Fig. 12 is a flow chart of an example of a method for generating a 3D medical instrument treatment plan and providing a 3D medical instrument set based on the 3D medical instrument treatment plan.
Fig. 13 is a flow chart of an example of a method for providing 3D medical device manufacturer selection services.
Fig. 14 is a flowchart of an example of a method for providing a 3D print advertisement service.
Fig. 15 is a block diagram of an example of elements in a system for providing medical treatment including a 3D printed medical instrument.
Fig. 16 is a block diagram of an example of a market entry system for a 3D printing appliance.
FIG. 17 is a conceptual diagram of a side view of a 4D full aligner.
FIG. 18 is a conceptual diagram of a side view of a 4D partial aligner.
Fig. 19 is a conceptual diagram of top and bottom views of a 4D full aligner.
Fig. 20 is a conceptual diagram of top and bottom views of a 4D partial aligner.
Fig. 21 is a conceptual diagram of top and bottom views of a 4D minimum aligner.
Detailed Description
Fig. 1 is a block diagram 100 of an example of a system for providing medical treatment including a 3D printed medical instrument. As used herein, 3D printing is intended to include larger dimensions such as 4D, but to exclude smaller dimensions such as 2D. For example, an aligner (aligner) may be used to assist in the process of constructing teeth from a patient's own stem cells. The aligner will assist the process by holding the structures together and enabling the delivery of enzymes, proteins, biochemicals that can assist in the successful growth of one or more teeth. Such an aligner is referred to as "4D". This concept is illustrated in fig. 17 to 21. The system of the example of fig. 1 includes a computer-readable medium 102, a dynamic 3D printed medical instrument handling system 104 coupled to the computer-readable medium 102, a patient system 106 coupled to the computer-readable medium 102, a healthcare practitioner system 108 coupled to the computer-readable medium 102, a patient-specific 3D medical instrument manufacturer system 110 coupled to the computer-readable medium 102, and an ad broker system 112 coupled to the computer-readable medium 102.
Computer-readable media 102 is intended to represent a variety of potentially applicable technologies. For example, the computer-readable medium 102 may be used to form a network or a portion of a network. Where two components are co-located on a device, the computer-readable medium 102 may include a bus or other data conduit or plane. Where the first component is co-located on one device and the second component is located on a different device, the computer-readable medium 102 may include a wireless or wired back-end network or LAN. The computer-readable medium 102 may also contain relevant portions of a WAN or other network, if applicable.
As used herein, "computer-readable medium" is intended to include all media which is statutory (e.g., in the united states, as specified in clause 35, clause 101 of the united states code), and specifically excludes all substantially non-statutory media insofar as such exclusion is necessary to render a claim as including computer-readable media valid. Known quorum computer-readable media include hardware (e.g., registers, Random Access Memory (RAM), non-volatile (NV) storage, etc.), but may or may not be limited to hardware.
The suitable systems or devices described herein may be implemented as a computer system, multiple computer systems, or portions of a computer system or multiple computer systems. Generally, a computer system will include a processor, memory, non-volatile storage, and an interface, and the examples described herein assume a stored program architecture, although this is not a clear requirement of a machine. A typical computer system will usually include at least a processor, memory, and a device (e.g., a bus) coupling the memory to the processor. The processor may be, for example, a general purpose Central Processing Unit (CPU) such as a microprocessor, or a special purpose processor such as a microcontroller. A typical CPU includes a control unit, an Arithmetic Logic Unit (ALU), and memory (typically including a special set of memory units called registers).
By way of example, and not limitation, memory may include Random Access Memory (RAM) such as dynamic RAM (dram) and static RAM (sram). The memory may be local, remote, or distributed. The bus may also couple the processor to non-volatile storage. The non-volatile storage section is typically a magnetic floppy disk or hard disk, a magneto-optical disk, an optical disk, a Read Only Memory (ROM) such as a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or other form of storage section for large amounts of data. Some of this data is typically written to memory through a direct memory access process when executing software on a computer system. The non-volatile storage may be local, remote, or distributed. The non-volatile storage is optional, as the system can be created with all applicable data available in the memory.
In the stored program architecture, software is typically stored in a non-volatile storage. In practice, for large programs, it is not even possible to store the entire program in memory. However, it should be understood that for software to be run (if necessary), the software is moved to a computer readable location suitable for processing, and for illustrative purposes, this location is referred to herein as memory. Even where software is moved to memory for execution, processors typically use hardware registers to store values associated with the software, as well as local caches, ideally to speed up execution. As used herein, where a software program is referred to as being "implemented in a computer-readable storage medium," it is assumed that the software program is stored at a known or convenient location (from non-volatile storage to hardware registers) as applicable. A processor is said to be "configured to execute a program" in the event that at least one value associated with the program is stored in a register readable by the processor.
In one example of operation, a computer system may be controlled by operating system software that is a software program that includes a file management system (such as a disk operating system, etc.). One example of operating system software with associated file management system software is known from Microsoft corporation of Redmond, Washington
A series of operating systems and their associated file management systems. Operating system software and associated file managementAnother example of system software is the Linux operating system and its associated file management system. The file management system is typically stored in non-volatile storage and causes the processor to perform various actions required by the operating system to input and output data and to store data in memory, including storing files on non-volatile storage.
The bus may also couple the processor to the interface. An interface may include one or more input and/or output (I/O) devices. By way of example, and not limitation, I/O devices may include keyboards, mice or other pointing devices, disk drives, printers, scanners, and other I/O devices, including display devices. By way of example, and not limitation, the display device may include a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), or some other suitable known or convenient display device. The interface may include one or more modems or network interfaces. It should be appreciated that a modem or network interface can be considered part of the computer system. The interfaces may include analog modems, ISDN modems, cable modems, token ring interfaces, satellite transmission interfaces (e.g., "direct PC"), or other interfaces for coupling a computer system to other computer systems. The interfaces enable the computer system and other devices to be coupled together in a network.
The computer system may be compatible with, or implemented as part of, or by a cloud-based computing system. As used herein, a cloud-based computing system is a system that provides virtualized computing resources, software, and/or information to client devices. Computing resources, software, and/or information may be virtualized by maintaining centralized services and resources that are accessible to edge devices via a communication interface, such as a network. "cloud" may be a marketing term and, for purposes herein, may include any network described herein. Cloud-based computing systems may involve subscription of services or use of a common pricing model. A user may access the protocols of the cloud-based computing system through a web browser or other container application located on a client device of the cloud-based computing system.
The computer system may be implemented as an engine, a portion of an engine, or by multiple engines. As used herein, an engine includes one or more processors or portions thereof. A portion of one or more processors may include some portion of hardware that is less than the entire hardware comprising any given one or more processors, such as a subset of registers, a portion of a processor dedicated to one or more threads in a multithreaded processor, or a time slice in which a processor is fully or partially dedicated to performing a portion of an engine function, etc. As such, the first and second engines may have one or more dedicated processors, or the first and second engines may share one or more processors with another engine or other engines. Depending on implementation-specific or other considerations, the engines may be centralized, or their functions may be distributed. The engine may comprise hardware, firmware, or software embodied in a computer-readable medium for execution by a processor. The processor uses the implemented data structures and methods (such as those described with reference to the figures herein) to convert data into new data.
The engines described herein or the engines that may implement the systems and apparatus described herein may be cloud-based engines. As used herein, a cloud-based engine is an engine that can run applications and/or functions using a cloud-based computing system. All or part of the applications and/or functions may be distributed across multiple computing devices and need not be limited to only one computing device. In some embodiments, the cloud-based engine may execute functions and/or modules that the end user accesses through a web browser or container application without the functions and/or modules being installed locally on the end user's computing device.
As used herein, a data store is intended to include a repository having any suitable organization of data, including tables, Comma Separated Value (CSV) files, traditional databases (e.g., SQL), or other suitable known or convenient organizational formats. For example, the data store may be implemented as software embodied in a physical computer-readable medium on a general-purpose or special-purpose machine, in firmware, hardware, a combination thereof, or in a suitable known or convenient device or system. Although the physical location and other characteristics of the data storage association component (such as a database interface, etc.) are not important to understanding the techniques described herein, the data storage association component may be considered to be "part of" the data storage, part of some other system component, or a combination thereof.
The data store may include data structures. As used herein, a data structure is associated with a particular way of storing and organizing data in a computer such that the data structure can be used efficiently within a given context. Data structures are generally based on the ability of a computer to fetch and store data anywhere within its memory, specified by addresses, i.e., bit strings that can themselves be stored in memory and manipulated by a program. Thus, some data structures are based on computing the addresses of data items using arithmetic operations; while other data structures are based on using the structure itself to store the addresses of the data items. Many data structures use two principles that are sometimes combined in ways that are not meaningless. The implementation of a data structure typically requires the writing of a collection of processes for creating and manipulating instances of the structure. The data storage described herein may be cloud-based data storage. The cloud-based data store is a data store compatible with the cloud-based computing system and engine.
The dynamic 3D printed medical instrument treatment system 104 is intended to represent hardware configured to provide treatment to a patient using at least one 3D printed medical instrument. In a particular implementation, the dynamic 3D printed medical instrument treatment system 104 includes a suitable computing device to be operated by a service provider. Depending on the context, multi-device treatments are appropriate, including medical treatments using a series of patient-specific 3D printed medical devices such as aligners (and holders) for orthodontic treatments, helmets for plagiocephaly (bungalow syndrome) treatments, and devices suitable for aesthetic treatments such as bands or other accessories that become smaller and smaller according to weight loss protocols. Depending on the context, dynamic 3D printing instruments may be used outside the medical/dental field (including beauty, gaming, toys, aerospace, automotive, energy, etc.). Depending on the context, single device handling of the condition, improvement of the problem, or aesthetic improvement is appropriate, such as an on-demand optical frame or lens customized for face or head shape and prescription, an on-demand earmuff, earbud, or hearing aid customized for ear shape, an automotive steering wheel handle or bicycle handlebar, etc., customized for hand shape, or a custom-shaped printed garment or accessory, etc. In particular implementations, the 3D printed medical device treatment service includes selecting a healthcare practitioner that suits a particular patient, determining a treatment plan that suits a particular patient and/or practitioner, selecting a 3D printed medical device manufacturer that suits a particular patient and/or practitioner.
In a particular implementation, the dynamic 3D printed medical instrument treatment system 104 is configured to generate a dynamic healthcare practitioner matching recommendation model when making a healthcare practitioner's selection. In a particular implementation, a dynamic healthcare practitioner matching recommendation model is used to match patient records and preferences with one or more potential practitioner candidates. In particular implementations, the patient record includes attribute information of the patient (e.g., age, gender, race, residence, etc.) as well as information related to the pre-treatment state of the patient (e.g., pre-treatment tooth arrangement), which may be obtained, for example, from photographs taken of the patient. In particular implementations, patient preferences may include geographic location, budget range, pain level throughout treatment, treatment duration, pre-and post-treatment status (e.g., aesthetic appearance), automatic or manual, Virtual Reality (VR)/Augmented Reality (AR), and so forth. In a particular implementation, the dynamic 3D printed medical device treatment system 104 applies the patient records and patient preferences to a dynamic healthcare practitioner matching recommendation model to perform healthcare practitioner matching when making healthcare practitioner selections.
In a particular implementation, the dynamic 3D printed medical instrument handling system 104 is configured to organize a practitioner referral auction in making a selection by a healthcare practitioner. In a particular implementation, when organizing a practitioner referral auction, the dynamic 3D printed medical device treatment system 104 selects a plurality of healthcare practitioners that generally match the patient records and patient preferences and sends an invitation to the selected healthcare practitioners for practitioner referral auction. Depending on implementation-specific or other considerations, the dynamic 3D-printed healthcare instrument handling system 104 may employ a dynamic healthcare practitioner matching recommendation model to select healthcare practitioners for auctions. In particular implementations, participants may join the auction in real-time or asynchronously based on presets.
In a particular implementation, in making the determination of the treatment plan, the dynamic 3D printed medical instrument treatment system 104 is configured to generate a dynamic 3D medical instrument treatment plan generation model. In a particular implementation, the dynamic 3D medical instrument treatment plan generation model is a data structure based on patient records and treatment conditions. In particular implementations, the treatment plan may include an expected post-treatment state (e.g., final location data) of the patient body part, a transitional state of the patient body part, a treatment period (e.g., duration and phase), an expected pain level, an estimated price, a type and design of the 3D printed medical instrument to be used for each of the different phases of treatment, and a manner and duration of attaching the 3D printed medical instrument, among others. For example, a 3D (or 4D or higher dimension) animation to show a transition from the pre-treatment state to the post-treatment state may be generated for display on a screen and/or in an AR/VR. In particular implementations, the treatment condition includes the same information as patient preferences, budget ranges, duration of medical treatment, post-treatment state (e.g., post-treatment tooth arrangement), and acceptable pain levels, etc. In a particular implementation, in making the determination of the treatment plan, the dynamic 3D printed medical instrument treatment system 104 applies the patient records and the treatment conditions to the dynamic 3D medical instrument treatment plan generation model to make the determination of the treatment plan.
In a particular implementation, upon selection of the 3D-printed medical instrument manufacturer, the dynamic 3D-printed medical instrument treatment system 104 is configured to generate a dynamic manufacturer selection model. In a particular implementation, the dynamic manufacturer selection model matches the treatment plan with the manufacturer records to determine one or more potential manufacturer candidates. In a particular implementation, the manufacturer record includes manufacturer information such as geographic location, expected delivery time, manufactured instrument type and design, price range, on-time delivery rating, practitioner rating, and patient rating. In a particular implementation, upon selecting the 3D-printed medical instrument manufacturer, the dynamic 3D-printed medical instrument treatment system 104 applies the patient records and treatment plans to the dynamic manufacturer selection model to match the 3D-printed medical instrument manufacturer.
Depending on implementation-specific or other considerations, one or more functions of the dynamic 3D printing medical instrument handling system 104 may be distributed locally to applicable systems such as the healthcare practitioner system 108 and the patient-specific 3D medical instrument manufacturer system 110. For example, the healthcare practitioner system 108 and/or the patient-specific 3D medical instrument manufacturer system 110 may install locally an application that includes a dynamic 3D medical instrument treatment plan generation model for generating a treatment plan. In another example, the healthcare practitioner system 108 may install locally an application that includes a dynamic manufacturer selection model for selecting a 3D printed medical instrument manufacturer.
The patient system 106 is intended to represent various suitable computing devices to be operated by the patient, such as smartphones, tablets, laptops, desktop computers, smart TVs, smart watches, smart speakers, or IoT devices, among others. In a particular implementation, the patient system 106 is configured to receive patient attribute information for generating a patient record. In a particular implementation, the patient system 106 is configured to capture an image of a patient's body part (e.g., a tooth arrangement image) to be used by the dynamic 3D-printed medical instrument treatment system 104 to determine a pre-treatment state of the patient, and to transmit the captured image of the patient's body part. In particular implementations, the patient system 106 is configured to receive information relating to a matching healthcare practitioner so that the patient can select the healthcare practitioner. In a particular implementation, the patient system 106 is configured to receive information related to the treatment plan such that the patient agrees to the treatment plan. In a particular implementation, the patient system 106 is configured to receive information about the selected manufacturer, such that the patient selects the manufacturer from which the 3D printed medical device is to be manufactured.
The healthcare practitioner system 108 is intended to represent a suitable computing device, such as a smartphone, tablet, laptop, desktop computer, smart TV, smart watch, smart speaker, or IoT device, etc., to be operated by a healthcare practitioner. In particular implementations, the healthcare practitioner system 108, at least one component of the healthcare practitioner system 108, and/or a device coupled to the healthcare practitioner system 108 may be provided at the healthcare provider (practitioner) facility. In particular implementations, the healthcare practitioner system 108 is configured to receive user input relating to practitioner attribute information and to send the user input for use in generating healthcare practitioner records. In a particular implementation, the healthcare practitioner system 108 is configured to capture a 3D image of the patient body part (e.g., a tooth arrangement 3D scan image) to be used by the dynamic 3D printing modality treatment system 104 to generate a treatment plan, and to transmit the captured 3D image of the patient body part. In particular implementations, the healthcare practitioner system 108 is configured to receive information relating to patient records, patient preferences, and/or treatment conditions for review by a healthcare practitioner. In a particular implementation, the healthcare practitioner system 108 is configured to receive information relating to a treatment plan for review by a healthcare practitioner. In a particular implementation, the healthcare practitioner system 108 is configured to receive information relating to the selected manufacturer, such that the healthcare practitioner selects the manufacturer from which the 3D printed medical instrument is to be manufactured.
In particular implementations, the healthcare practitioner system 108 is configured to manufacture trial 3D printed medical instruments so that a patient visiting the healthcare practitioner can experiment with the 3D printed medical instrument prior to commencing a 3D printed medical instrument procedure. For example, the trial 3D printing medical instrument may have a patient-specific shape that is formed to fit the patient's body part, particularly the current state of the patient's body part. In particular implementations, the trial aligner may be referred to as a no-movement tray or a zero-stage tray. The trial aligner is a subset of trial medical devices, which may also be referred to as ambulatory medical devices and zero-phase medical devices. In another particular implementation, the trial aligner may be referred to as an initial moving tray designed to cause initial movement of the patient's body part. In both cases, the aligner may be referred to as a starter aligner.
In a particular implementation, the healthcare practitioner system 108 is configured to manufacture a starter 3D printed medical instrument so that a patient visiting the healthcare practitioner can start the 3D printed medical instrument as the first in the 3D printed medical instrument treatment group. For example, the activator 3D printing medical instrument may have a shape formed to move the patient body part towards the final position to the first stage. The initiator 3D printing medical instrument may use some calculation to start printing from the current record, but it is expected that the calculation requirements will not be too high; the patient will still be able to obtain the starter 3D printed medical device at the end of an appointment of the industry expected length, and will likely obtain the entire group if the 3D printing is fast enough. The starter aligner may be referred to as a pre-programmed moving pallet or a stage pallet. The starter aligner may also be a trial aligner, in which case it may be referred to as a no-movement tray or a zero stage tray. The starter aligner is a subset of starter medical devices, which may also be referred to as a non-ambulatory medical device and a zero-stage medical device or a pre-programmed ambulatory medical device and a one-stage medical device.
In a particular implementation, the healthcare practitioner system 108 is configured to manufacture a re-guided 3D printed medical instrument such that a patient visiting the healthcare practitioner can be re-guided with the 3D printed medical instrument after one of the 3D printed medical instrument sets is lost or damaged. For example, the re-directing 3D printing medical instrument may have a shape formed to move a patient body part from a current stage towards a final position, thereby replacing an unused medical instrument to support a new group. Advantageously, the redirecting aligner may be fired a bit further than the lost or damaged aligner (assuming it has worn before being lost), and the redirecting aligner may contain the correction to address tooth recurrence. The re-directed 3D printing medical instrument may use some calculation to start printing from the current record, but the calculation requirements are not expected to be too high; the patient will still be able to obtain the re-guided 3D printed medical instrument at the end of an appointment of the industry expected length, and will likely obtain the entire collection if the 3D printing is fast enough. The re-guide aligner may be referred to as a pre-programmed moving tray or a phase reset tray. The re-guide aligner is a subset of the re-guide medical devices, which may also be referred to as pre-programmed ambulatory medical devices and a phase-reset medical device. The lead medical device is a superset of the trial medical device, the initiator medical device, and the reboot medical device, and is intended to represent the first medical device according to a lead date (e.g., a first appointment or a later appointment).
The patient-specific 3D medical instrument manufacturer system 110 is intended to represent various suitable computing devices to be operated by a 3D printing medical instrument manufacturer, such as smartphones, tablets, laptops, desktop computers, smart TVs, smart watches, smart speakers, or IoT devices, among others. In particular implementations, the patient-specific 3D healthcare provider system 110, at least one component of the healthcare practitioner system 108, and/or the device coupled to the healthcare practitioner system 108 may be provided at the 3D printing healthcare practitioner's facility. In a particular implementation, the patient-specific 3D medical instrument manufacturer system 110 is configured to receive specifications of 3D medical instruments used in treatment planning. The patient-specific 3D medical instrument manufacturer system 110 may or may not also receive 3D printing specifications for setting up 3D printing. In a particular implementation, the healthcare practitioner system 108 is configured to manufacture patient-specific 3D medical instruments based on the treatment, such that the manufactured instruments are delivered to the patient directly or through the healthcare practitioner.
The ad broker system 112 is intended to represent hardware configured to provide advertising services for 3D medical treatment related traffic. In a particular implementation, the 3D medical treatment-related business may include medical providers, wherein the medical providers include healthcare practitioners and 3D-printed medical instrument manufacturers. In a particular implementation, the advertisements provided by the advertising service may include images of the patient's body part before and after treatment with the 3D printing modality. In particular implementations, when making a selection of an advertisement (e.g., an advertisement image), the ad broker system 112 is configured to generate a dynamic advertisement selection model. In particular implementations, the dynamic advertisement selection model is a computer algorithm configured to determine one or more advertisement images deemed to match attributes (e.g., age, gender, race, income level, etc.) of the targeted advertisement recipients. Further, in certain implementations, upon selection of an advertisement, the ad broker system 112 sends information related to the advertisement to the patient system 106 and/or healthcare practitioner system 108 to obtain consent of the patient and/or healthcare practitioner. The market entry solution is described later with reference to fig. 16.
In an example of system operation, shown by way of example in fig. 1, the patient system 106 provides a patient body part image to the dynamic 3D printed medical instrument treatment system 104. The dynamic 3D-printed medical instrument treatment system 104 generates a dynamic practitioner matching recommendation model for selecting a medical practitioner, a dynamic treatment plan generation model for generating a treatment plan, and a dynamic manufacturer selection model for selecting a 3D-printed medical instrument manufacturer. The patient system 106 receives information about the selected healthcare practitioner, the generated treatment plan, the selected manufacturer, and the advertisement consent request. The healthcare practitioner system 108 receives information about the patient record, the treatment condition, the generated treatment plan, and the selected manufacturer, and sends a request to generate the treatment plan, the manufacturer's selection, and a request to manufacture the 3D printed medical instrument. The patient-specific 3D medical instrument manufacturer system 110 manufactures the 3D printed medical instrument based on the received request. The ad broker system 112 generates a dynamic advertisement selection model and provides an advertisement image selected based on the dynamic advertisement selection model on an advertisement medium selected based on the dynamic advertisement selection model.
Advantageously, a system for providing medical treatment based on patient-specific 3D printed medical instruments using dynamic machine learning techniques can provide dynamic machine learning-based practitioner selection, treatment planning, manufacturer selection, and advertising selection. Computer-based machine learning techniques enable more accurate and efficient outputs that are useful to patients and medical practitioners.
Fig. 2 is a block diagram 200 of an example of a patient system included in a system for providing medical treatment that includes a 3D printed medical instrument. The diagram 200 includes a patient interface engine 202, a patient scan engine 204 coupled to the patient interface engine 202, an image sensor 206 coupled to the patient scan engine 204, and a patient image data store 208 coupled to the image sensor 206 and the patient interface engine 202. In a particular implementation, the patient system depicted in fig. 2 corresponds to the patient system 106 in fig. 1.
The patient interface engine 202 is intended to represent hardware configured to interface with a patient to obtain selections, feedback, consent, and patient information, etc., and to communicate with external systems such as dynamic 3D printing modality treatment systems, healthcare practitioner systems, patient-specific 3D modality manufacturer systems, and ad broker systems. In a particular implementation, the patient interface engine 202 receives information about one or more potential practitioner candidates matching the patient through a dynamic 3D printing medical device treatment system and presents the received information to prompt the patient to make a selection. In a particular implementation, the patient interface engine 202 receives information from the dynamic 3D printed medical device handling system about healthcare practitioners who match the patient through auctions and presents the received information to prompt the patient to provide consent. In a particular implementation, the patient interface engine 202 receives a medical treatment plan from a dynamic 3D printed medical instrument treatment system or healthcare practitioner system and presents the medical treatment plan to prompt the patient for an examination. In a particular implementation, the patient interface engine 202 receives information about one or more potential 3D printed medical device manufacturers and presents the information to prompt the patient to make a selection.
Patient scanning engine 204 is intended to represent hardware configured to generate patient image data of a patient's body part (e.g., an oral part, a head, etc.) scanned by image sensor 206. The image data may be 2D image data or 3D image data, depending on implementation-specific or other considerations. When generating 3D image data, the patient scan engine 204 may include a specially manufactured 3D image processing module that includes depth map computation functionality, or a 2D image processing module with additional functional modules for 3D imaging. Depending on implementation or configuration specific factors, a 3D image or some other component may be required in addition to a 2D image, since a 2D image or only a 2D image may be considered to provide insufficient data to print an instrument suitable for a particular application (such as a holder suitable within a patient's mouth, etc.). For example, a home kit of aligners may include an impression kit mailed as an addition to a 2D image uploaded by a patient, both of which must be considered before the aligner or set of aligners are delivered to the patient (as they arrive via mail or in some other suitable manner). In contrast, according to the techniques described herein, a 3D image scanned in the office without the impression set is sufficient for the same day of the aligner.
Patient image data store 208 is intended to represent a data store to store one or more images of the patient's body part captured by image sensor 206. In a particular implementation, the entry of the patient image table includes an identification of an object within the patient body part image, an identification of the patient, parameter values associated with the patient image table, and storage location information of the object within the patient body part image.
In a particular implementation, the patient exhibits treatment results without ever involving a practitioner. In such an implementation, the patient may immediately start the first device set, and the practitioner may complete the rest of the workflow remotely at a later time. This system-backed intelligence can be motivated by machine learning to improve efficiency and outcome. In addition, components of a healthcare practitioner system such as described with reference to fig. 3 may be automated and implemented on a patient device, on a platform (e.g., in the cloud), or in some other manner that provides patient access to an associated expert system. Similarly, components of a patient specific 3D medical instrument manufacturer system such as described with reference to fig. 4 may be automated or physically implemented by or on behalf of a patient.
In an example of system operation, shown by way of example in fig. 2, the patient interface engine 202 receives an indication from the patient to capture an image. The patient scanning engine 204 is used to scan a relevant portion of the patient, such as the mouth. The image sensor 206 captures 2D and/or 3D images of the patient's body parts, such as images of the teeth and gums. The patient image data storage unit 208 stores a patient body part image. The patient interface engine 202 then provides the relevant image or images to someone else.
Fig. 3 is a block diagram 300 of an example of a healthcare practitioner system included in a system for providing a medical treatment including a 3D printed medical instrument. The diagram 300 includes a practitioner interface engine 302, a patient registration engine 304 coupled to the practitioner interface engine 302, a practitioner 3D scan engine 306 coupled to the practitioner interface engine 302, an image sensor 307 coupled to the practitioner 3D scan engine 306, a segmentation engine 308 coupled to the practitioner 3D scan engine 306, a final position data store 310 coupled to the segmentation engine 308, a patient transaction engine 312 coupled to the patient registration engine 304 and the final position data store 310, a guide aligner 3D print engine 314 coupled to the patient transaction engine 312 and the final position data store 310, and a local 3D printer 316 coupled to the guide aligner 3D print engine 314. In a particular implementation, the healthcare practitioner system depicted in fig. 3 corresponds to the healthcare practitioner system 108 in fig. 1.
The practitioner interface engine 302 is intended to represent hardware configured to interface with a healthcare practitioner.
The patient registration engine 304 is intended to represent hardware configured to register a patient to receive 3D-printing modality-based treatment. In a particular implementation, at patient registration, a patient record is generated that includes patient attributes (e.g., age, gender, race, residence, etc.). The record includes one or more images of the patient's body part (e.g., images of the teeth and gums) available from the patient system. Practitioners, such as dentists, often have multiple chairs and operating rooms. At many points, there is a vacancy and a surplus of capacity in the office, both in terms of space and staff time. Advantageously, since the patient has some control over the treatment process as described previously herein, the service requirements can be matched to the supply in the form of space and staff bandwidth. The excess capacity may be used for various related services such as scanning, progress checks, emergency situations, etc.
The practitioner 3D scan engine 306 is intended to represent hardware configured to generate patient 3D image data of a patient body part (e.g., oral cavity part, head, etc.) based on image data of the patient body part scanned by the image sensor 307. In particular implementations, in generating patient 3D image data, the practitioner 3D scan engine 306 may include a specially manufactured 3D image processing module that includes depth map computation functionality, or a 2D image processing module with additional functional modules for 3D imaging.
The segmentation engine 308 is intended to represent hardware configured to segment the physical state of a patient based on patient 3D image data of the patient. In a particular implementation, the segmenting includes identifying a patient body object or sub-part within the patient body part based on patient 3D image data of the patient and determining a location of the identified sub-part. For example, the segmentation may include identifying individual teeth in one or more images of the teeth and gums.
The final position data store 310 is intended to mean a data store to store final position data. The final location data may be determined according to aesthetic preferences of a medical practitioner applied to the image object, possible success rates of such treatment, or other considerations, and may be customized based on the practitioner's experience and skill level data and based on past results delivered by the practitioner or other similar professional. For example, a dentist may have aesthetic preferences for tooth placement (which may be represented using tooth objects oriented to match the final position) as well as aesthetic preferences for the entire face/head.
The patient transaction engine 312 is intended to represent hardware configured to enable a patient to purchase 3D-printing based medical treatment of a medical instrument. In a particular implementation, the transaction includes a contract between the patient and the healthcare practitioner, and a payment for a medical treatment based on the 3D printed medical instrument. In the alternative, subscription payment, payment in digital currency, or payment in exchange for other services, etc. are used.
Guide aligner 3D print engine 314 is intended to represent hardware configured to generate 3D printer data that guides 3D printing of medical instruments based on patient 3D image data. In a particular implementation, 3D printer data directing 3D printing of a medical instrument includes a plurality of 2D image data layers suitable for 3D printing. Guiding a 3D printed medical appliance may or may not result in an appliance that moves a body part (e.g., teeth) from a first position to a second position. A trial 3D printed medical device may be provided to enable a patient to be accustomed to wearing the device.
The local 3D printer 316 is intended to represent hardware configured to produce a guided 3D printing medical instrument based on patient 3D image data generated by the guide aligner 3D print engine 314. Depending on implementation and/or configuration specific factors, the boot 3D print medical instrument may be implemented as a trial 3D print medical instrument, a starter 3D print medical instrument, or a re-boot 3D print medical instrument.
In the example of system operation shown by way of example in fig. 3, a practitioner interface engine 302 is used to interface with a medical practitioner. The patient registration engine 304 registers patients and generates patient records. The practitioner 3D scan engine 306 generates 3D scan data of the patient's body part based on the obtained 2D and/or 3D image data. The segmentation engine 308 segments the patient body part based on the 3D scan data of the patient body part. The final position data storage unit 310 stores final position data of the body part to be moved. The patient transaction engine 312 facilitates payment for 3D-based printing of dental procedures of medical instruments. The guide aligner 3D print engine 314 generates 3D printer data that guides 3D printing of the medical instrument based on the 3D scan data of the patient's body part. The local 3D printer 316 produces a guide 3D printing medical instrument based on the 3D printer data generated by the guide aligner 3D print engine 314.
Fig. 4 is a block diagram 400 of an example of a patient-specific 3D medical instrument manufacturer system included in a system for providing medical treatment including a 3D printed medical instrument. The diagram 400 includes a provider interface engine 402, a setup engine 404 coupled to the provider interface engine 402, a phasing engine 406 coupled to the setup engine 404, a treatment planning engine 408 coupled to the phasing engine 406, an inspection and approval engine 410 coupled to the phasing engine 406 and the treatment planning engine 408, a 3D manufacturing engine 412 coupled to the inspection and approval engine 410, and an instrument suite providing engine 414 coupled to the 3D manufacturing engine 412. In a particular implementation, the patient-specific 3D medical instrument manufacturer system depicted in fig. 4 corresponds to the patient-specific 3D medical instrument manufacturer system 110 in fig. 1.
The setup engine 404 is intended to represent hardware configured to set up a medical treatment based on a 3D printing medical instrument. In setting up a 3D print based dental procedure, the setup engine 404 retrieves a patient record comprising 3D scan data and final position data. In a particular implementation, the set 3D-printed medical instrument-based medical treatment is associated with a particular patient and a particular healthcare practitioner and is managed in association with a patient record for the patient and a healthcare practitioner record for the healthcare practitioner. The settings engine 404 may generate multiple settings for a single patient. For example, one version may show the front teeth after straightening, and another version may show all the teeth after straightening. Each such setting has time, cost and success rate implications. The practitioner may choose to share some or all versions with the patient to allow for patient selection.
The staging engine 406 is intended to represent hardware configured to determine a treatment status of a 3D-printed medical instrument based dental treatment based on patient records and patient inputs. In particular implementations, the treatment conditions may include a budget range, a treatment duration, pre-treatment and post-treatment states (e.g., post-treatment tooth alignment), and acceptable pain levels, among others. Staging requires determining the configuration of the instruments from the first instrument to the last instrument, where the first instrument moves the body part from the home position and the last instrument moves the body part to the final position.
The treatment planning engine 408 is intended to represent hardware configured to generate a treatment plan based on patient records and treatment conditions. In particular implementations, the treatment plan may include expected pre-treatment and post-treatment states (e.g., final location data) of the patient body part, treatment periods (e.g., duration and phase), expected pain levels, estimated prices, transitional states of the patient body part, treatment periods (e.g., duration and phase), types and designs of 3D printed medical instruments to be used for the different phases of treatment, and ways and durations of attaching the 3D printed medical instruments, among others. For example, a 3D animation may be generated to show a transition from the pre-treatment state to the post-treatment state.
The review and approval engine 410 is intended to represent hardware configured to provide treatment plans to and receive approval of treatment plans from patients and/or healthcare practitioners. In certain implementations, the engines 406, 408, 410 cycle until the treatment plan is approved.
The 3D manufacturing engine 412 is intended to represent hardware configured to generate 3D data of a 3D medical instrument set based on patient 3D image data, treatment plan and final position. In a particular implementation, the 3D data of the 3D medical instrument set includes a plurality of 2D image data layers suitable for 3D printing. Alternatively, the 3D medical device may be manufactured in a known or convenient manner.
The instrument set provisioning engine 414 is intended to represent hardware configured to prepare a 3D medical instrument set, such as an aligner, for delivery to a patient. The hardware may print all instruments for one case, or batch over time. With batch processing, the patient may be scanned repeatedly, which may or may not require a meeting with a practitioner or other party capable of scanning. The batch size may be customized based on patient information or according to preferences, with larger batches being more suitable for simpler situations. Based on the difficult movements in one case, the patient may be advised to scan at certain points in their treatment, where the batch size may be associated with the duration between certain points. In certain implementations, the scanning occurs remotely and the instrument is transported to the patient. The repeated scans facilitate comparing the actual progress with predicted progress associated with the plan, thereby enabling the instrument manufacturer to respond to the actual progress rather than the predicted progress, which may be inaccurate. Due to the value of such a dynamic self-correction loop, even after advances in 3D printing and improvements in treatment planning are achieved through advanced machine learning techniques, such a dynamic self-correction loop may persist, even though it may in some instances replace printing everything at once, but in the foreseeable future it will not replace printing everything at once. Delivery may be accomplished by physically delivering the device to the patient, by mail, or in other suitable manner.
In the example of system operation shown by way of example in fig. 4, the provider interface engine 402 is used to receive patient information. The setup engine 404 sets up 3D medical instrument treatment. Until approval is obtained, the staging engine 406 determines a treatment condition of the 3D medical device treatment; the treatment planning engine 408 provides a treatment plan and the review and approval engine 410 obtains approval of the treatment plan. The 3D manufacturing engine 412 generates 3D data for a 3D medical treatment instrument set based on the patient 3D image data. The instrument set provision engine 414 prepares for delivery of a 3D medical treatment instrument set based on the 3D data generated by the 3D manufacturing engine 412.
Fig. 5 is a block diagram 500 of an example of a dynamic 3D printed medical instrument handling system for providing practitioner matching recommendation services. The exemplary architecture shown in fig. 5 includes a matching data communication engine 502, a patient record processing engine 504 coupled to the matching data communication engine 502, a patient record data store 506 coupled to the patient record processing engine 504, a practitioner record processing engine 508 coupled to the matching data communication engine 502, a practitioner record data store 510 coupled to the practitioner record processing engine 508, a dynamic practitioner matching recommendation model management engine 512 coupled to the matching data communication engine 502, the patient record processing engine 504, and the practitioner record processing engine 508, and a dynamic practitioner matching recommendation model data store 514 coupled to the dynamic practitioner matching recommendation model management engine 512. In a particular implementation, the dynamic 3D printed medical instrument treatment system depicted in fig. 5 corresponds to the dynamic 3D printed medical instrument treatment system 104 in fig. 1.
The match data communication engine 502 is intended to represent hardware configured to communicate with patient systems and healthcare practitioner systems. In particular implementations, upon communication with the patient system, the matching data communication engine 502 receives patient information for generating patient records. Depending on implementation-specific or other considerations, the patient information may include patient attributes of the patient (e.g., age, gender, race, residence, etc.) as well as information related to the patient's pre-treatment status information (e.g., pre-treatment tooth arrangement). In particular implementations, the matching data communication engine 502 receives practitioner information for generating practitioner records when communicating with a healthcare practitioner system. Practitioner information may include geographic location, scheduling, practice floor, price range, and rating of healthcare practitioners, depending on implementation-specific or other considerations.
In particular implementations, the match data communication engine 502 is further configured to provide information to the patient system regarding potential practitioner candidates selected by the healthcare practitioner match and receive a user selection input of one of the potential practitioner candidates from the patient system. Further, in certain implementations, upon receiving a user selection input, the matching data communication engine 502 provides the patient record and treatment status to the healthcare practitioner system of the selected healthcare practitioner via the user selection input.
The patient record processing engine 504 is intended to represent hardware configured to generate patient records based on patient information obtained by the matching data communication engine 502. In particular implementations, the patient record includes information contained in the patient information and is a self-captured 2D image of the patient's body part (e.g., teeth) that is also transmitted from the patient system, and may or may not include detailed 3D scan data. In particular implementations, the patient record includes the patient's preferences for treatment, such as geographic location, budget range, pain level throughout the treatment period, treatment period (e.g., duration), and post-treatment status, among others.
The patient record data store 506 is intended to represent a data store of one or more patient records generated by the patient record processing engine 504. In certain implementations, in storing one or more patient records, the patient record data store 506 manages the stored patient records using a patient record table that includes a plurality of entries that each correspond to a patient record. For example, an entry of the patient record table includes an identification of the patient record, an identification of the patient, a parameter value associated with the patient table, and storage location information of the patient record. In certain implementations, when storing one or more patient records, the patient record data store 506 also stores a machine learning model applicable to the one or more patient records stored therein.
The practitioner record processing engine 508 is intended to represent hardware configured to generate practitioner records based on healthcare practitioner information obtained by the matching data communication engine 502. In particular implementations, the practitioner record includes information included in the practitioner information, such as the geographic location, schedule, practice floor, price range, and rating of the healthcare practitioner.
The practitioner record data store 510 is intended to represent a data store to store one or more practitioner records generated by the practitioner record processing engine 508. In certain implementations, in storing one or more practitioner records, the practitioner record data store 510 manages the stored practitioner records in the same or similar manner as the patient record data store 506 that stores patient records.
The dynamic practitioner matching recommendation model management engine 512 is intended to represent hardware configured to generate a dynamic healthcare practitioner matching recommendation model. In particular implementations, the dynamic healthcare practitioner matching recommendation model is configured to determine one or more potential practitioner candidates that are deemed to match the patient records and preferences. In particular implementations, the dynamic healthcare practitioner matching recommendation model may include a plurality of parameters for determining outcome potential practitioner candidates for a particular patient, and parameter values of the parameters may be modified by applicable machine learning techniques. In a particular implementation, the parameters of the dynamic medical practitioner matching recommendation model may include the geographic location of the patient, patient preferences (treatment status), and the geographic location, schedule, practice floor, price range, and rating of the practitioner.
In a particular implementation, the dynamic practitioner-matching recommendation model management engine 512 is configured to determine potential practitioner candidates by applying patient records, treatment conditions, and practitioner records to the dynamic healthcare practitioner-matching recommendation model. Depending on implementation-specific or other considerations, one or more practitioners whose practitioner records match the treatment condition and/or patient records may be selected as potential practitioner candidates.
In particular implementations, the dynamic practitioner matching recommendation model management engine 512 is configured to provide information (e.g., practitioner records) related to potential practitioner candidates to a patient system of the patient so that the patient can select one of the potential practitioner candidates that is to medically treat the patient. Further, in particular implementations, upon the patient selecting one of the potential practitioner candidates, the dynamic practitioner matching recommendation model management engine 512 is configured to receive a user selection input indicative of one of the potential practitioner candidates and provide the patient record and treatment status to the practitioner system of the selected practitioner upon receipt of the user selection input.
In a particular implementation, the dynamic practitioner matching recommendation model management engine 512 is configured to receive user feedback from the patient system. Depending on implementation-specific or other considerations, the user feedback may include applicability (e.g., how the service conditions provided by the practitioner match the treatment conditions of the patient), convenience of the appointment time, number of appointments, and patient subjectively determined quality of service (QoS). Further, in particular implementations, the dynamic practitioner matching recommendation model management engine 512 is configured to modify the dynamic healthcare practitioner matching recommendation model based on user feedback. In particular implementations, the dynamic practitioner matching recommendation model management engine 512 modifies specific parameter values and/or weighted balances of parameters of the dynamic medical practitioner matching recommendation model according to applicable machine learning techniques such as decision tree learning, association rule learning, artificial neural networks, deep learning, and the like.
The dynamic practitioner matching recommendation model data store 514 is intended to represent a data store to store one or more dynamic healthcare practitioner matching recommendation models generated by the dynamic practitioner matching recommendation model management engine 512. In particular implementations, when storing one or more dynamic healthcare practitioner matching recommendation models, the dynamic practitioner matching recommendation model data store 514 manages the stored dynamic healthcare practitioner matching recommendation models in the same or similar manner as the patient record data store 506 storing patient records and/or the practitioner record data store 510 storing practitioner records.
In the example of system operation illustrated by way of example in fig. 5, the match data communication engine 502 communicates with the patient system to obtain patient information to generate a patient record and communicates with the healthcare practitioner system to obtain healthcare practitioner information to generate a practitioner record. The patient record processing engine 504 generates a patient record based on the patient information obtained by the matching data communication engine 502 and stores the generated patient record in the patient record data store 506. The practitioner record processing engine 508 generates practitioner records based on the healthcare practitioner information obtained by the matching data communication engine 502, and stores the generated practitioner records in the practitioner record data storage 510. The dynamic practitioner matching recommendation model management engine 512 generates a dynamic healthcare practitioner matching recommendation model and stores the generated dynamic healthcare practitioner matching recommendation model in the dynamic practitioner matching recommendation model data storage 514.
Further, in the example of system operation illustrated by way of example in fig. 5, the dynamic practitioner matching recommendation model management engine 512 determines treatment status based on patient records, obtains practitioner records, and determines potential practitioner candidates using a dynamic healthcare practitioner matching recommendation model. The dynamic practitioner matching recommendation model management engine 512 receives user selection input to select one of the potential practitioner candidates, providing the patient record and treatment status to the practitioner system of the selected practitioner. The dynamic practitioner matching recommendation model management engine 512 receives user feedback from the patient system and modifies the dynamic healthcare practitioner matching recommendation model based on the user feedback.
Fig. 6 is a block diagram 600 of an example of a dynamic 3D printing modality handling system for providing practitioner referral auction services. An example of a dynamic 3D printing medical instrument handling system shown in fig. 6 includes an auction data communication engine 602, a patient record processing engine 604 coupled to the auction data communication engine 602, a patient record data store 606 coupled to the patient record processing engine 604, a practitioner record processing engine 608 coupled to the auction data communication engine 602, a practitioner record data store 610 coupled to the practitioner record processing engine 608, a practitioner referral auction engine 612 coupled to the auction data communication engine 602, the patient record processing engine 604 and the practitioner record processing engine 608. In a particular implementation, the dynamic 3D printed medical instrument treatment system depicted in fig. 6 corresponds to the dynamic 3D printed medical instrument treatment system 104 in fig. 1 and/or the dynamic 3D printed medical instrument treatment system in fig. 5.
In a particular implementation, the auction data communication engine 602, the patient record processing engine 604, the patient record data store 606, the practitioner record processing engine 608, and the practitioner record data store 610 operate in the same or similar manner as the match data communication engine 502, the patient record processing engine 504, the patient record data store 506, the practitioner record processing engine 508, and the practitioner record data store 510 in fig. 5.
The practitioner referral auction engine 612 is intended to represent hardware configured to generate and manage healthcare practitioner referral auction instances for selecting healthcare practitioners to whom patient records are provided based on an auction. Depending on implementation specific or other considerations, the healthcare practitioner referral auction instance is a computer program configured to select one or more potential practitioner candidates to which an invitation to the healthcare practitioner referral auction is provided based on the patient record, the patient preferences (treatment status), and the practitioner record of the registered healthcare practitioner. In particular implementations, healthcare practitioner referral auction instances may be performed based on a plurality of parameters used to determine potential practitioner candidates for a particular patient, and parameter values of the parameters may be modified by applicable machine learning techniques. In the alternative, a fixed pricing model may be used instead of an auction to take into account patient parameters from practitioner records, treatment conditions, and patient records. In such an implementation, FIG. 6 may be modified to replace the "auction" with a "fixed pricing model".
In a particular implementation, the practitioner referral auction engine 612 is configured to determine a treatment status based on the patient record obtained from the patient record data store 606 and obtain a practitioner record from the practitioner record data store 610 that registers a healthcare practitioner. Further, in particular implementations, the practitioner referral auction engine 612 is configured to select one or more potential practitioner candidates based on the practitioner record, the treatment condition, and the patient record. Further, in selecting one or more potential practitioner candidates, the healthcare practitioner referral auction engine 612 is configured to provide auction data (e.g., an invitation for the healthcare practitioner referral auction) to the healthcare practitioner systems of the potential practitioner candidates. In particular implementations, the auction data includes a generic version of the patient record as well as information related to the auction procedure (e.g., restrictions on bid numbers, expiration dates, etc.), information related to service referral fees, and the like.
In a particular implementation, the practitioner referral auction engine 612 is configured to provide auction data (e.g., an invitation for a healthcare practitioner to refer to an auction) to a healthcare practitioner system of a potential practitioner candidate. In particular implementations, the auction data includes a generic version of the patient record and/or disposition condition as well as information related to the auction procedure (e.g., restrictions on bid numbers, expiration dates, etc.), information related to service referral fees, and the like. In a particular implementation, the practitioner referral auction engine 612 is configured to receive bids from a healthcare practitioner system of one or more potential practitioner candidates. In a particular implementation, the bid includes an agreed upon amount of charge entered by the healthcare practitioner. In particular implementations, the practitioner referral auction engine 612 is configured to select a winning practitioner based on the bid amount (or adjusted bid amount) or other applicable criteria. In particular implementations, the practitioner referral auction engine 612 is configured to send a complete version of the patient record and/or treatment condition to the healthcare practitioner system of the winning practitioner. In certain implementations, the practitioner referral auction engine 612 sends the patient record and/or disposition status when the patient agrees to use the winning practitioner.
In the example of system operation shown by way of example in fig. 6, the auction data communication engine 602 communicates with the patient system to obtain patient information to generate a patient record and communicates with the healthcare practitioner system to obtain healthcare practitioner information to generate a practitioner record. The patient record processing engine 604 generates a patient record based on the patient information obtained by the matching data communication engine 602 and stores the generated patient record in the patient record data storage 606. The practitioner record processing engine 608 generates practitioner records based on healthcare practitioner information obtained through the auction data communication engine 602, and stores the generated practitioner records in the practitioner record data storage section 610. The practitioner referral auction engine 612 generates a healthcare practitioner referral auction instance and uses it in conducting a healthcare practitioner referral auction in the healthcare practitioner referral auction instance.
Fig. 7 is a block diagram 700 of an example of a dynamic 3D printed medical instrument treatment system for providing a 3D medical instrument treatment plan. The example of the dynamic 3D printed medical instrument treatment system shown in fig. 7 includes a treatment plan communication engine 702, a patient record processing engine 704 coupled to the treatment plan communication engine 702, a patient record data store 706 coupled to the patient record processing engine 704, a dynamic treatment plan generative model management engine 708 coupled to the treatment plan communication engine 702 and the patient record processing engine 704, a dynamic treatment plan generative model data store 710 coupled to the dynamic treatment plan generative model management engine 708, a treatment plan processing engine 712 coupled to the treatment plan communication engine 702 and the dynamic treatment plan generative model management engine 708, and a treatment plan data store 714 coupled to the treatment plan processing engine 712. In a particular implementation, the dynamic 3D printed medical instrument handling system depicted in fig. 7 corresponds to the dynamic 3D printed medical instrument handling system in fig. 1, 5, and/or 6.
The treatment plan communication engine 702 is intended to represent hardware configured to communicate with patient systems, healthcare practitioner systems, and patient-specific 3D medical instrument manufacturer systems. In a particular implementation, the treatment plan communication engine 702 is configured to communicate with a patient system to obtain patient information. In a particular implementation, the treatment plan communication engine 702 is configured to communicate with a healthcare practitioner system to receive a request for generating a medical treatment plan based on patient records and treatment conditions. In a particular implementation, the treatment plan communication engine 702 is configured to communicate with a 3D medical instrument manufacturer system to send a request to manufacture a patient-specific 3D medical instrument group.
Advantageously, the treatment planning communication engine 702 may be implemented as part of or in conjunction with a practice management system in a dental office, including a practice management system implemented in the office to manage patient scheduling prior to incorporating the techniques described herein. Other engines described below, such as the dynamic treatment plan generation model management engine 708 and the treatment plan processing engine 712, may run in the background and may, for example, asynchronously create treatment plans for related patients for physician presentation at appointment time and sharing before or after. This may be used as a conversion tool for the patient, as the patient may utilize the treatment plan to display possible situations.
In particular implementations, the patient record processing engine 704 and the patient record data store 706 operate in the same or similar manner as the patient record processing engine 504 and the patient record data store 506, respectively, of fig. 5.
The dynamic treatment plan generation model management engine 708 is intended to represent hardware configured to generate a dynamic 3D medical instrument treatment plan generation model. Depending on implementation-specific or other considerations, the dynamic 3D medical instrument treatment plan generation model is a computer algorithm configured to determine a 3D medical instrument treatment plan based on the patient record and the treatment condition. In particular implementations, the dynamic 3D medical instrument treatment plan generation model may include a plurality of parameters for determining an outcome potential practitioner candidate dynamic 3D medical instrument treatment plan for a particular patient, and parameter values of the parameters may be modified by applicable machine learning techniques. In particular implementations, the parameters of the dynamic 3D medical device treatment plan generation model may include a pre-treatment state of the patient, an expected post-treatment state of the patient, a treatment period (e.g., duration and phase), an expected pain level, and a budget range, among others.
In a particular implementation, the dynamic treatment plan generation model management engine 708 is configured to receive user feedback from the patient system and/or healthcare practitioner system. Depending on implementation-specific or other considerations, the user feedback may include practitioner suitability (e.g., how a service condition provided by the practitioner matches a treatment condition of the patient), practitioner quality of service (QoS) subjectively determined by the practitioner, manufacturer suitability (e.g., how a machine condition provided by the manufacturer matches a treatment plan), manufacturer quality of service (QoS) subjectively determined by the patient and/or practitioner. Further, in a particular implementation, the dynamic treatment plan generation model management engine 708 is configured to modify the dynamic 3D medical instrument treatment plan generation model based on user feedback. In particular implementations, the dynamic treatment plan generation model management engine 708 modifies specific parameter values and/or weighted balances of parameters of the dynamic 3D medical instrument treatment plan generation model according to applicable machine learning techniques such as decision tree learning, association rule learning, artificial neural networks, deep learning, and so forth.
The dynamic treatment plan generative model data store 710 is intended to represent a data store to store one or more 3D medical instrument treatment plan generative models generated by the dynamic treatment plan generative model management engine 708. In certain implementations, in storing one or more 3D medical instrument treatment plan generative models, the dynamic treatment plan generative model data store 710 manages the stored 3D medical instrument treatment plan generative models in the same or similar manner as the patient record data store 506 of fig. 5, which stores patient records.
The treatment plan processing engine 712 is intended to represent hardware configured to generate a 3D medical instrument treatment plan by applying patient records including 3D scan data and treatment conditions to the dynamic 3D medical instrument treatment plan generation model. In particular implementations, the 3D instrument treatment plan may include an expected post-treatment state of the patient, a treatment period (e.g., duration and phase), an expected pain level, an estimated price, a type and design of the 3D printed medical instrument to be used for each of the different phases of treatment, and a manner and duration of attaching the 3D printed medical instrument, among others. For example, the type and design of the 3D printed medical instrument may include the material, color, and patient-specific shape of the 3D printed medical instrument. For example, the manner and duration of attaching the 3D printed medical instrument may include acceptable patient movement or activity during the attachment of the 3D printed medical instrument, and a time range in days, weeks, or months that the 3D printed medical instrument should be attached.
The treatment plan data store 714 is intended to represent a data store to store one or more 3D medical instrument treatment plans generated by the treatment plan processing engine 712. In certain implementations, in storing one or more 3D medical instrument treatment plans, the treatment plan data store 714 manages the stored 3D medical instrument treatment plans in the same or similar manner as the patient record data store 506 of fig. 5, which stores patient records.
In the example of system operation illustrated by way of example in fig. 7, the treatment plan communication engine 702 communicates with the patient system to obtain patient information to generate a patient record, communicates with the healthcare practitioner system to receive a request to generate a treatment plan, and communicates with the patient-specific 3D medical instrument manufacturer system to send a request to manufacture a patient-specific 3D medical instrument set. The patient record processing engine 704 generates a patient record based on the patient information obtained by the matching data communication engine 702 and stores the generated patient record in the patient record data store 706. The dynamic treatment plan generation model management engine 708 generates a dynamic treatment plan generation model, and stores the generated dynamic treatment plan generation model in the dynamic treatment plan generation model data storage unit 710. The treatment plan processing engine 712 generates a treatment plan by applying the patient records and the treatment conditions to the dynamic treatment plan generation model, and stores the generated treatment plan in the treatment plan data store 714.
Fig. 8 is a block diagram 800 of an example of a dynamic 3D printing medical instrument handling system for providing 3D medical instrument manufacturer selection services. The example of the dynamic 3D printed medical instrument treatment system shown in fig. 8 includes a manufacturer selection communication engine 802, a treatment plan processing engine 804 coupled to the manufacturer selection communication engine 802, a treatment plan data store 806 coupled to the treatment plan processing engine 804, a manufacturer record processing engine 808 coupled to the manufacturer selection communication engine 802, a manufacturer record data store 810 coupled to the manufacturer record processing engine 808, a dynamic manufacturer selection model management engine 812 coupled to the manufacturer selection communication engine 802, the treatment plan processing engine 804, and the manufacturer record processing engine 808, and a dynamic manufacturer selection model data store 814 coupled to the dynamic manufacturer selection model management engine 812. In a particular implementation, the dynamic 3D printed medical instrument handling system depicted in fig. 8 corresponds to the dynamic 3D printed medical instrument handling system in fig. 1, 5, 6, and/or 7.
The manufacturer-selected communication engine 802 is intended to represent hardware configured to communicate with patient systems, healthcare practitioner systems, and 3D medical instrument manufacturer systems. In a particular implementation, the manufacturer-selection communication engine 802 is configured to communicate with a 3D medical instrument manufacturer system to obtain manufacturer information. Depending on implementation-specific or other considerations, the manufacturer information may include geographic location, expected delivery time, manufactured equipment type and design, price range, on-time delivery rating, practitioner rating, and patient rating, among others.
In a particular implementation, the manufacturer selection communication engine 802 is configured to provide information regarding potential manufacturer candidates selected through 3D healthcare instrument manufacturer selection and receive a user selection input of one of the potential manufacturer candidates from the patient system or healthcare practitioner system. Further, in particular implementations, upon receiving a user selection input, the manufacturer selection communication engine 802 provides the patient records and treatment plans to the 3D medical instrument manufacturer system of the selected manufacturer through the user selection input.
In a particular implementation, the treatment plan processing engine 804 and the treatment plan data store 806 operate in the same or similar manner as the treatment plan processing engine 712 and the treatment plan data store 714, respectively, in fig. 7.
Manufacturer record processing engine 808 is intended to represent hardware configured to generate manufacturer records based on manufacturer information obtained through manufacturer selection communication engine 802. In particular implementations, the manufacturer record includes information included in the manufacturer information, such as geographic location, expected delivery time, manufactured equipment type and design, price range, on-time delivery rating, practitioner rating, and patient rating, among others.
Manufacturer record data store 810 is intended to represent a data store to store one or more manufacturer records generated by manufacturer record processing engine 808. In particular implementations, upon storing one or more practitioner records, the manufacturer record data store 810 manages the stored manufacturer records in the same or similar manner as the treatment plan data store 806 that stores the treatment plan.
Dynamic manufacturer selection model management engine 812 is intended to represent hardware configured to generate a dynamic manufacturer selection model. Devices for the same patient may be manufactured by the same manufacturer or multiple manufacturers, allowing for portability of patient delivery, consistent with certain specific tools/advantages that manufacturers have on certain devices and other devices. This approach facilitates batch printing for the same situation and allows consumers to obtain service wherever they are (e.g., lose aligner-i am on vacation/not at home).
Depending on implementation-specific or other considerations, the dynamic manufacturer selection model is configured to determine one or more potential manufacturer candidates that are considered to match the treatment plan based on the treatment plan and the manufacturer records. In particular implementations, the dynamic manufacturer selection model includes a plurality of parameters for determining final potential manufacturer candidates for a particular patient, and parameter values of the parameters may be modified by applicable machine learning techniques. In particular implementations, the parameters of the dynamic manufacturer-selected model may include the geographic location of the patient, treatment plan-specific parameters such as treatment period (e.g., duration and phase), expected pain level, estimated price, type and design of 3D medical instrument to be used for each different phase of treatment, and the manner and duration of attaching the 3D medical instrument, among others.
In a particular implementation, the dynamic manufacturer selection model management engine 812 is configured to determine potential manufacturer candidates by applying the patient records, the treatment plan, and the manufacturer records to the dynamic manufacturer selection model. Depending on implementation-specific or other considerations, one or more 3D medical instrument manufacturers whose manufacturer records match the treatment plan and/or patient records may be selected as potential manufacturer candidates.
In particular implementations, the dynamic manufacturer selection model management engine 812 is configured to provide information (e.g., manufacturer records) regarding potential manufacturer candidates to the patient system and/or healthcare practitioner system so that the patient or healthcare practitioner can select one of the potential manufacturer candidates that will manufacture the patient-specific 3D medical instrument. Further, in particular implementations, upon selection of one of the potential manufacturer candidates by the patient or healthcare practitioner, the dynamic manufacturer selection model management engine 812 is configured to receive a user selection input indicative of one of the potential manufacturer candidates and provide the patient record and treatment plan to the 3D medical instrument manufacturer system of the selected manufacturer upon receipt of the user selection input.
In a particular implementation, the dynamic manufacturer selection model management engine 812 is configured to receive user feedback from the patient system and/or healthcare practitioner system. Depending on implementation-specific or other considerations, the user feedback may include practitioner suitability (e.g., how a service condition provided by the practitioner matches a treatment condition of the patient), a practitioner quality of service (QoS) subjectively determined by the patient, manufacturer suitability (e.g., how a machine condition provided by the manufacturer matches a treatment plan), a manufacturer quality of service (QoS) subjectively determined by the patient and/or the practitioner. Further, in particular implementations, dynamic manufacturer selection model management engine 812 is configured to modify the dynamic manufacturer selection model based on user feedback. In particular implementations, the dynamic manufacturer selection model management engine 812 modifies specific parameter values and/or weighted balances of parameters of the dynamic manufacturer selection model according to applicable machine learning techniques, such as decision tree learning, association rule learning, artificial neural networks, deep learning, and so forth.
Dynamic manufacturer selection model data store 814 is intended to represent a data store that stores one or more dynamic manufacturer selection models generated by dynamic manufacturer selection model management engine 812. In certain implementations, when storing one or more dynamic manufacturer selection models, the dynamic manufacturer selection model data store 814 manages the stored dynamic manufacturer selection models in the same or similar manner as the dynamic practitioner matching recommendation model data store 514 of fig. 5, which stores dynamic healthcare practitioners matching recommendation models.
In the example of system operation illustrated by way of example in fig. 8, the manufacturer selection communication engine 802 communicates with the 3D medical instrument manufacturer system to obtain manufacturer information and communicates with the patient system and/or healthcare practitioner system to provide information relating to potential manufacturer candidates for selection of one of the potential manufacturer candidates. The treatment plan processing engine 804 generates a treatment plan and stores the generated treatment plan in the treatment plan data storage 806. The manufacturer record processing engine 808 generates a manufacturer record based on the manufacturer information obtained by the manufacturer selection communication engine 802, and stores the generated manufacturer record in the manufacturer record data storage section 810. The dynamic manufacturer selection model management engine 812 generates a dynamic manufacturer selection model, and stores the generated manufacturer selection model in the dynamic manufacturer selection model data storage unit 814.
Further, in the example of system operation illustrated by way of example in fig. 8, the dynamic manufacturer selection model management engine 812 uses the dynamic manufacturer selection model to determine potential manufacturer candidates. The dynamic manufacturer selection model management engine 812 receives user selection input to select one of the potential manufacturer candidates to provide the treatment plan and patient records to the manufacturer system of the selected manufacturer. The dynamic manufacturer selection model management engine 812 receives user feedback from the patient system and/or healthcare practitioner system and modifies the dynamic manufacturer selection model based on the user feedback.
Fig. 9 is a block diagram 900 of an example of an ad broker system included in a system for providing medical treatment that includes a 3D printed medical instrument. The example of the ad broker system shown in fig. 9 includes an ad broker communications engine 902, an ad processing engine 904 coupled to the ad broker communications engine 902, an ad media data store 906 coupled to the ad processing engine 904, and an ad propagation engine 908 coupled to the ad media data store 906 and the ad broker communications engine 902. In a particular implementation, the ad broker system depicted in FIG. 9 corresponds to the ad broker system 112 in FIG. 1.
The ad broker communications engine 902 is intended to represent hardware configured to communicate with healthcare practitioner systems, manufacturer systems, and patient systems. In particular implementations, the ad broker communications engine 902 receives an advertisement request to disseminate an advertisement of a 3D-printed medical instrument, a 3D-printed accessory, and/or a related service when communicating with healthcare practitioner systems and/or manufacturer system patients and/or systems. Depending on implementation-specific or other considerations, the advertisement request may involve a payment transaction before or after the advertising service is conducted. In particular implementations, the ad broker communications engine 902 receives patient records to be used for advertising when communicating with healthcare practitioner systems and/or manufacturer systems and/or patient systems. Depending on implementation-specific or other considerations, the patient record used for advertising may include a pre-treatment status (e.g., a photograph of a patient's body part). In particular implementations, when communicating with a patient system, ad broker communications engine 902 is configured to send an ad usage consent request and receive ad usage consent returned from the patient system. Depending on implementation-specific or other considerations, advertisement usage consent may be obtained before or after 3D-printing medical device-based treatment.
The advertisement processing engine 904 is intended to represent hardware configured to generate advertisement images based on patient records. In particular implementations, the advertisement image may include a photograph of the patient's body part representing the pre-treatment state, the state after application of the 3D printed medical instrument, or a modified image (e.g., changing color, hiding portions of the image, etc.) of the patient's body part or the 3D printed medical instrument for advertising purposes.
In particular implementations, the advertisement processing engine 904 is configured to generate a dynamic advertisement selection model. Depending on implementation-specific or other considerations, the dynamic advertisement selection model is configured to determine one or more advertisement images and/or advertisement media to be disseminated based on attributes of the advertisement images and attributes of the advertisement request. In particular implementations, the dynamic advertisement selection model may include a plurality of parameters for determining the resulting advertisement image and/or advertisement media for a particular advertiser (e.g., healthcare practitioner, manufacturer, etc.), and the parameter values of the parameters may be modified by applicable machine learning techniques. In particular implementations, the parameters of the dynamic advertisement selection model may include geographic location of distribution (e.g., country, state, county, city, etc.), time, exposure (e.g., view count), and targeted advertisement recipient attributes, among others.
In particular implementations, the ad processing engine 904 is configured to determine the ads to distribute by applying attributes of the ad media and attributes of the ad request to a dynamic ad selection model. Depending on implementation-specific or other considerations, one or more advertisement images matching the advertisement request may be selected as the advertisement image to be distributed.
In particular implementations, the advertisement processing engine 904 is configured to obtain advertisement results. Depending on implementation-specific or other considerations, the advertising results may include statistics related to sales of 3D printed medical device treatment services, sales of 3D printed medical devices, sales of 3D printed accessories, access counts to links associated with propagating advertisements, and other applicable marketing criteria. Further, in particular implementations, the advertisement processing engine 904 is configured to modify the dynamic advertisement selection model based on the advertisement results. In particular implementations, the advertisement processing engine 904 modifies specific parameter values and/or weighting balances of parameters of the dynamic advertisement selection model according to applicable machine learning techniques, such as decision tree learning, association rule learning, artificial neural networks, deep learning, and so forth.
The advertising media data store 906 is intended to represent a data store to store one or more advertising images, audio files, or multimedia files generated by the advertising processing engine 904. In particular implementations, when storing advertising media, the advertising media data store 906 manages the stored advertising media using an advertising media table that includes a plurality of entries each corresponding to advertising media content. For example, the entry of the advertising media table includes an identification of the advertising image, an identification of the patient, a parameter value associated with the advertising media table, and storage location information of the advertising image. In particular implementations, when storing advertising media, the advertising media data store 906 also stores machine learning models applicable to one or more patient records stored therein.
The ad propagation engine 908 is intended to represent hardware configured to provide the determined ads to distribute to the ad platform corresponding to the determined ad media. In particular implementations, the advertising platform may include a particular website, a particular web application, a particular TV program, a particular radio program, a social channel, and other applicable platforms.
In the example of system operation shown by way of example in fig. 9, the ad broker communications engine 902 communicates with healthcare practitioner systems and/or manufacturer systems to receive ad requests and patient records, and communicates with patient systems to obtain ad usage consent. The advertisement processing engine 904 generates an advertisement image based on the patient record, and stores the generated advertisement image in the advertisement image data storage 906. The advertisement processing engine 904 generates a dynamic advertisement selection model and uses the dynamic advertisement selection model to determine the advertisement images to be disseminated as well as the advertisement media. The ad propagation engine 908 provides the determined ad image to the ad platform corresponding to the determined ad media. The ad processing engine 904 obtains the ad results and modifies the dynamic ad selection model based on the ad results.
Figure 10 is a flowchart 1000 of an example of a method for providing a practitioner matching recommendation service. This flow diagram, and other flow diagrams described herein, illustrate modules (and potential decision points) organized in a manner that is helpful for understanding. However, it should be appreciated that modules may be reassembled for parallel execution, reordered, or modified (altered, removed, or enhanced) where circumstances permit. The flow diagram 1000 begins with block 1002: a dynamic healthcare practitioner matching recommendation model for a 3D instrument based medical treatment is generated. An applicable engine, such as the dynamic practitioner matching recommendation model management engine described herein, generates a dynamic healthcare practitioner matching recommendation model. Depending on implementation-specific or other considerations, the dynamic healthcare practitioner matching recommendation model may include as parameters the geographic location of the patient, the preferences of the patient, and the geographic location, scheduling, practice floor, price range, and rating of the practitioner.
The flow diagram 1000 continues to block 1004: a treatment condition is determined based on the patient record. An applicable engine, such as a patient record processing engine, described herein, determines a treatment condition based on a patient record. In particular implementations, the patient record may include attribute information of the patient (e.g., age, gender, race, residence, etc.) as well as information related to the pre-treatment state of the patient (e.g., pre-treatment tooth arrangement). For example, the information related to the pre-treatment state may include a self-captured 2D picture of a patient's body part (e.g., teeth) and may not include detailed 3D scan data. In particular implementations, the treatment conditions of a treatment (e.g., an orthodontic treatment) may include a budget range, a treatment period (e.g., a length of time), a post-treatment state (e.g., a post-treatment tooth arrangement), and an acceptable pain level, among others. Depending on implementation-specific or other considerations, the treatment condition may also be determined based on patient input through an applicable system described herein, such as a patient system.
Flow diagram 1000 continues to block 1006: a practitioner record is obtained of the registered practitioner. An applicable engine such as a practitioner record processing engine described herein obtains a practitioner record that registers a practitioner. In a particular implementation, the practitioner record of a registered practitioner includes the geographic location, schedule, practice floor, price range, and rating of the registered practitioner. Depending on implementation specific or other considerations, the information included in the practitioner record is obtained based on the healthcare practitioner's input through an applicable system such as a healthcare practitioner system as described herein.
The flow diagram 1000 continues to block 1008: potential practitioner candidates are determined by applying practitioner records, treatment conditions and patient records to a dynamic medical practitioner matching recommendation model. An applicable engine, such as the dynamic practitioner matching recommendation model management engine described herein, determines potential practitioner candidates. Depending on implementation-specific or other considerations, one or more practitioners whose practitioner records match the treatment condition and/or patient records may be selected as potential practitioner candidates. In certain implementations, information of potential practitioner candidates is provided to the patient by the patient system so that the patient can review the information.
The flow diagram 1000 continues to block 1010: a user selection input is received from the patient system. An applicable engine, such as the match data communication engine described herein, receives a user selection input. Depending on implementation-specific or other considerations, the user selection input may include information relating to the healthcare practitioner selected by the patient.
The flow diagram 1000 continues to block 1012: providing the patient record and the treatment condition to a practitioner system of the selected practitioner. An applicable engine, such as a patient record processing engine, described herein, retrieves patient records and treatment conditions for the patient and causes the patient records and treatment conditions for the patient to be provided to a healthcare practitioner system of a selected practitioner so that the selected practitioner can review the patient records and treatment conditions and schedule counseling and/or treatment.
The flow diagram 1000 continues to block 1014: user feedback is received from the patient system. An applicable engine such as the match data communication engine described herein receives user feedback from the patient system. Depending on implementation-specific or other considerations, the user feedback may include applicability (e.g., how the service condition provided by the practitioner matches the treatment condition of the patient) and patient subjectively determined quality of service (QoS).
The flow diagram 1000 ends with block 1016: the dynamic healthcare practitioner matching recommendation model is modified based on the user feedback. An applicable engine described herein, such as a dynamic practitioner matching recommendation model management engine, modifies the dynamic healthcare practitioner matching recommendation model based on user feedback. In particular implementations, the specific parameter values and/or weighting balance of the parameters of the dynamic healthcare practitioner matching recommendation model are modified according to applicable machine learning techniques such as decision tree learning, association rule learning, artificial neural networks, deep learning, and the like. After block 1016, the flow diagram 1000 returns to block 1004 for a new practitioner match.
Figure 11 is a flow diagram 1100 of an example of a method for providing a practitioner referral auction service. Flow diagram 1100 begins with block 1102: an auction instance is generated for healthcare practitioner referrals including the 3D printed medical instruments. An applicable engine such as the practitioner referral auction engine described herein generates a healthcare practitioner referral auction instance.
Flow diagram 1100 continues to block 1104: a treatment condition is determined based on the patient record. An applicable engine, such as a patient record processing engine, described herein, determines a treatment condition based on a patient record. In particular implementations, block 1104 may be performed in a manner similar to block 1004 of FIG. 10.
Flow diagram 1100 continues to block 1106: a practitioner record is obtained of the registered practitioner. An applicable engine such as a practitioner record processing engine described herein obtains a practitioner record that registers a practitioner. In particular implementations, module 1106 may be executed in a manner similar to module 1006 in FIG. 10.
Flow diagram 1100 continues to block 1108: potential practitioner candidates are determined based on the practitioner record, the treatment condition, and the patient record. An applicable engine such as a practitioner referral auction engine described herein determines potential practitioner candidates. Depending on implementation-specific or other considerations, one or more practitioners whose practitioner records match the treatment condition and/or patient records may be selected as potential practitioner candidates. In a particular implementation, information of the treatment condition is provided to a healthcare practitioner system of a potential practitioner candidate so that it can review the information.
Flow diagram 1100 continues to block 1110: bids are received from healthcare practitioner systems of potential practitioner candidates. An applicable engine such as an auction data communication engine, as described herein, receives bids from healthcare practitioner systems of potential practitioner candidates. In a particular implementation, the bids include particular values indicating pricing and timestamps for treatment. The practitioner can also create presets of these values for specific case types to enable the auto-bidding function.
The flow diagram 1100 ends with block 1112: select a winning practitioner candidate and send the complete patient record and treatment status to the winning practitioner. An applicable engine, such as a practitioner referral auction engine, described herein, selects a winning practitioner and sends the complete patient record and disposition status to the winning practitioner. In particular implementations, bidding amounts, time stamps, other applicable criteria may be employed to select winning practitioners.
Fig. 12 is a flowchart 1200 of an example of a method for generating a 3D medical instrument treatment plan and providing a 3D medical instrument set based on the 3D medical instrument treatment plan. The flow diagram 1200 begins with block 1202: a dynamic 3D medical instrument treatment plan generation model is generated. An applicable engine, such as the dynamic treatment plan generation model management engine described herein, generates a dynamic 3D medical instrument treatment plan generation model. Depending on implementation-specific or other considerations, the dynamic 3D medical instrument treatment plan generation model may include, as parameters, a pre-treatment state of the patient, an expected post-treatment state of the patient, a treatment period (e.g., duration and phase), an expected pain level and budget range, and the like.
Flow diagram 1200 continues to block 1204: a patient record is obtained. An applicable engine, such as the patient record processing engine described herein, obtains a patient record for a patient. In particular implementations, the patient record may include attribute information of the patient (e.g., age, gender, race, residence, etc.) as well as information related to the pre-treatment state of the patient (e.g., pre-treatment tooth arrangement). For example, the information related to the pre-treatment state may include a self-captured 2D image of a patient body part (e.g., teeth) and may not include detailed 3D scan data.
Flow diagram 1200 continues to block 1206: 3D scan data of a patient is received. An applicable engine, such as a treatment planning communication engine, described herein receives 3D scan data of a patient from an applicable source, such as a healthcare practitioner system and/or a patient system. In a particular implementation, when the healthcare practitioner system includes a 3D scanning device to obtain 3D scan data of a patient, the practitioner system transmits the 3D scan data from the healthcare. In a particular implementation, when a medical practitioner obtains an impression of a body part of a patient, the impression may be delivered and 3D scan data may be obtained by scanning the impression.
Flow diagram 1200 continues to block 1208: a 3D instrument treatment plan is generated by applying the patient records and the 3D scan data to a dynamic 3D medical instrument treatment plan generation model. An applicable engine such as the dynamic treatment plan generation model management engine described herein generates a 3D instrument treatment plan. In particular implementations, the 3D instrument treatment plan may include, inter alia, an expected post-treatment state of the patient, a treatment period (e.g., duration and phase), an expected pain level, an estimated price, a type and design of the 3D medical instrument to be used for each different phase of the treatment, and a manner and duration of attaching the 3D medical instrument. For example, the type and design of the 3D medical instrument may include the material, color, and patient-specific shape of the 3D medical instrument. For example, the manner and duration of attaching the 3D medical instrument may include acceptable patient movement or activity during the attachment of the 3D medical instrument, and a time range in days, weeks, or months that the 3D medical instrument should be attached.
Flow diagram 1200 continues to block 1210: providing the generated 3D modality treatment plan to a healthcare practitioner system. An applicable engine, such as the treatment plan communication engine described herein, provides the generated 3D modality treatment plan to the healthcare practitioner system so that the healthcare practitioner can review the generated 3D modality treatment plan for approval. In a particular implementation, the generated 3D medical instrument treatment plan is also provided to the patient by the healthcare practitioner, or directly to the patient system, to obtain patient consent. In a particular implementation, approval of the 3D medical instrument treatment plan by the healthcare practitioner and/or consent of the patient to the 3D medical instrument treatment plan is returned for further processing.
Flow diagram 1200 continues to block 1212: print the starter 3D print medical instrument at the healthcare practitioner system for patient pick up. A suitable device, such as a local 3D printer of a healthcare practitioner system, may manufacture the instant initiator 3D printed medical instrument. Advantageously, the activator 3D-printed medical instrument may be printed (if the patient sends an image, or if the image is obtained, for example, via a dental record in a dentist office) prior to meeting with the patient. Alternatively, the starter 3D-printed medical instrument may be printed during a consultation or after a short wait, allowing the patient to leave with the starter 3D-printed medical instrument. Advantageously, such an instrument may be appropriately characterized as a "same day aligner" or an "aligner usable in less than an hour" (in the case of an aligner). In the context of dental, medical, and cosmetic products, the aligner may be made available while seated for some other procedure, and may be appropriately characterized as a "wait-free aligner" because the aligner may be provided prior to completion of some other procedure (e.g., hair cutting, pedicuring, etc.). In a particular implementation, the patient's consent may be made prior to printing the starter 3D printing medical instrument.
Flow diagram 1200 continues to block 1214: a manufacturing request for manufacturing the 3D medical instrument set is provided to the manufacturer system. An applicable engine, such as a treatment plan communication engine, described herein provides the manufacturing request to the manufacturer system along with the approved 3D instrument treatment plan. In a particular implementation, the manufacturer system manufactures a 3D printed medical instrument set specifically designed for the patient based on the approved 3D instrument treatment plan. In particular implementations, the manufactured 3D medical device may be inspected by a healthcare practitioner or other professional (e.g., technician) and may be remanufactured based on whether the manufactured 3D medical device meets the criteria required for manufacturing. In a particular implementation, the manufactured 3D medical device is delivered to a patient such that the patient wears the 3D medical device for treatment.
Flow diagram 1200 continues to block 1216: user feedback is received from a healthcare practitioner system and/or a patient system. An applicable engine such as a treatment planning communication engine, as described herein, receives user feedback. Depending on implementation-specific or other considerations, the user feedback may include practitioner suitability (e.g., how a service condition provided by the practitioner matches a treatment condition of the patient), practitioner quality of service (QoS) subjectively determined by the practitioner, manufacturer suitability (e.g., how a machine condition provided by the manufacturer matches a treatment plan), manufacturer quality of service (QoS) subjectively determined by the patient and/or practitioner.
Flow diagram 1200 ends with block 1218: the dynamic 3D medical instrument treatment plan generation model is modified based on the user feedback. An applicable engine described herein, such as a dynamic treatment plan generation model management engine, modifies the dynamic 3D medical instrument treatment plan generation model. In particular implementations, the specific parameter values and/or weighted balance of the parameters of the dynamic 3D medical instrument treatment plan generation model are modified according to applicable machine learning techniques such as decision tree learning, association rule learning, artificial neural networks, deep learning, and so forth. After block 1218, the flow diagram 1200 returns to block 1204 for a new treatment plan.
Fig. 13 is a flow chart 1300 of an example of a method for providing 3D medical device manufacturer selection services. Flow diagram 1300 begins with block 1302: a dynamic 3D medical instrument manufacturer selection model is generated. An applicable engine, such as the dynamic manufacturer selection model management engine described herein, generates a dynamic 3D medical instrument manufacturer selection model. Depending on implementation-specific or other considerations, the dynamic 3D medical device manufacturer selection model may include the geographic region of the manufacturer, the device types and designs manufactured, price ranges, on-time delivery ratings, practitioner ratings, and patient ratings, among others.
Flow diagram 1300 continues to block 1304: a patient record and a treatment plan are obtained. An applicable engine, such as a patient record processing engine, described herein obtains patient records and treatment plans for a patient. In a particular implementation, the treatment plan for the patient may be generated by an applicable process such as that described in fig. 12.
Flow diagram 1300 continues to block 1306: a manufacturer record is obtained. An applicable engine, such as the manufacturer record processing engine described herein, obtains the manufacturer records of the registered manufacturers. In a particular implementation, the manufacturer records of the registered manufacturer include geographic location, expected delivery time, manufactured instrument type and design, price range, on-time delivery rating, practitioner rating, and patient rating, among others. Depending on implementation-specific or other considerations, the information included in the manufacturer record is obtained based at least in part on the manufacturer's input through an applicable system, such as the manufacturer system, described herein.
Flow diagram 1300 continues to block 1308: manufacturer candidates are determined by applying the patient record, the treatment plan and the manufacturer record to a dynamic 3D medical instrument manufacturer selection model. An applicable engine, such as the dynamic manufacturer selection model management engine described herein, determines manufacturer candidates. Depending on implementation-specific or other considerations, one or more 3D-printed medical instrument manufacturers whose manufacturer records match the patient records and/or treatment plans may be selected as manufacturer candidates. In a particular implementation, information of the treatment plan, in particular the type and design of the 3D printed medical instrument of the patient, is provided to the manufacturer system of the manufacturer candidate so that it can examine the information.
Flow diagram 1300 continues to block 1310: information relating to the manufacturer candidate is provided to the patient system or practitioner system. An applicable engine, such as the manufacturer selection communication engine described herein, provides information about manufacturer candidates to a patient system or a practitioner system so that the patient system or practitioner system can present information for selecting a 3D printed medical device manufacturer.
Flow diagram 1300 continues to block 1312: user selection input is received from a patient system or a practitioner system. An applicable engine, such as the manufacturer-selected communication engine described herein, receives a user selection input. Depending on implementation-specific or other considerations, the user selection input may include information relating to the 3D-printed medical device manufacturer selected by the patient or healthcare practitioner.
Flow diagram 1300 continues to block 1314: the selected manufacturer system is provided with a manufacturing request for manufacturing the 3D medical instrument set. An applicable engine, such as the manufacturer selection communication engine described herein, provides the selected manufacturer system with manufacturing requests with approved 3D instrument treatment plans. In particular implementations, module 1314 may perform in a similar manner as module 1214 in fig. 12.
Flow diagram 1300 continues to block 1316: user feedback is received from a healthcare practitioner system and/or a patient system. The applicable engine, such as the manufacturer-selected communication engine described herein, receives user feedback. In particular implementations, module 1316 may perform in a similar manner as module 1216 in fig. 12.
Flow diagram 1300 ends with block 1318: the dynamic 3D medical instrument manufacturer selection model is modified based on the user feedback. An applicable engine, such as the dynamic manufacturer selection model management engine described herein, modifies the dynamic manufacturer selection model. In particular implementations, the specific parameter values and/or weighted balance of the parameters of the dynamic manufacturer selected model are modified according to applicable machine learning techniques such as decision tree learning, association rule learning, artificial neural networks, deep learning, and the like. Following block 1318, flow diagram 1300 returns to block 1304 for a new manufacturer selection.
Fig. 14 is a flowchart 1400 of an example of a method for providing a 3D print advertising service. Flow diagram 1400 begins with block 1402: a dynamic advertisement selection model is generated. An applicable engine, such as the ad processing engine described herein, generates a dynamic ad selection model. Depending on implementation-specific or other considerations, the dynamic advertisement selection model may include a targeted geographic area for the advertisement recipient, targeted advertisement recipient attributes (e.g., age, gender, race, income level, etc.), advertisement attributes (e.g., type and nature of service, product, etc.), duration and budget range, and so forth.
Flow diagram 1400 continues with block 1404: patient records are obtained based on advertising requests from the practitioner and/or the manufacturer system. An applicable engine, such as the ad broker communications engine described herein, receives ad requests from practitioner and/or manufacturer systems and obtains patient records. Depending on implementation-specific or other considerations, the patient record used for advertising may include a pre-treatment state (e.g., a photograph of the patient's body part) and a pre-treatment state (e.g., a photograph of the patient's body part).
Flow diagram 1400 continues with block 1406: generating an advertisement based on the patient record. An applicable engine, such as the advertisement processing engine described herein, generates advertisements based on patient records. In particular implementations, the advertisement may include a photograph of the patient's body part showing the pre-treatment state and the post-treatment state, a simulation of the patient's body with the medical instrument attached, or an image of the patient's body part or instrument modified for advertising purposes (e.g., changing color, hiding portions of the image, etc.).
Flow diagram 1400 continues with block 1408: a request for consent to the use of the advertisement is sent to the patient system. An applicable engine, such as the ad broker communications engine described herein, sends a request for ad usage consent to the patient system.
Flow diagram 1400 continues with block 1410: advertisement usage consent is received from the patient system. An applicable engine such as the ad broker communications engine described herein receives ad usage consent from the patient system.
Flow diagram 1400 continues to block 1412: advertisements to be propagated and advertising media to propagate advertisements are determined by applying advertisements and advertisement requests to a dynamic advertisement selection model. An applicable engine, such as the ad processing engine described herein, determines the ads to be disseminated as well as the ad media. In particular implementations, a targeted geographic area of the advertisement recipient, targeted advertisement recipient attributes (e.g., age, gender, race, income level, etc.), advertisement attributes (e.g., type and nature of service, product, etc.), duration and budget range, etc., are extracted from the advertisement request, and an advertisement image having attributes (e.g., age, gender, etc.) similar to the targeted advertisement recipient and/or advertisement media (e.g., a particular website, browser, etc.) associated with the targeted advertisement recipient is determined.
Flow diagram 1400 continues with block 1414: providing the determined advertisement to an advertisement platform corresponding to the determined advertising medium. An applicable engine, such as the ad propagation engine described herein, provides the determined ad images to an ad platform. In particular implementations, the advertising platform may include a particular website, a particular web application, a particular TV program, a particular radio program, a social channel, and other applicable platforms.
Flow diagram 1400 continues to block 1416: an advertising result is obtained. An applicable engine such as the ad broker communications engine described herein obtains the ad results. In particular implementations, the advertisement results may include statistics indicating sales of 3D printed medical device treatment services, sales of 3D printed medical devices, access counts to links associated with propagating advertisements, and other applicable marketing criteria.
Flow diagram 1400 ends with block 1418: the dynamic advertisement selection model is modified based on the advertisement results. An applicable engine such as the ad broker communications engine described herein modifies the dynamic ad selection model. In particular implementations, the particular parameter values and/or weighted balance of the parameters of the dynamic advertisement selection model are modified according to applicable machine learning techniques, such as decision tree learning, association rule learning, artificial neural networks, deep learning, and so forth. After block 1418, flow diagram 1400 returns to block 1404 for a new advertisement selection.
Fig. 15 is a block diagram 1500 of an example of elements in a system for providing medical treatment including a 3D printed medical instrument. For illustrative purposes, the system shown in fig. 15 is directed to a patient-specific 3D printed dental appliance, such as an orthodontic aligner or the like, to fit the mouth of a patient. The system depicted in fig. 15 includes a patient registration engine 1502, an image scanner 1504, a dental scan data store 1506, a patient record data store 1507, a segmentation engine 1508, a final position data store 1510, a patient transaction engine 1512, a boot starter aligner 3D print engine 1514, a local 3D printer 1516, a setup engine 1518, a staging engine 1520, a treatment planning engine 1522, an examination and approval engine 1524, and an aligner set providing engine 1526.
The image scanner 1504 is intended to represent hardware configured to scan a patient's teeth to generate dental scan data. In a particular implementation, the image scanner 1504 includes a 3D scanner coupled to a patient system and/or a healthcare practitioner system described herein, and the dental scan data includes 3D scan data. In a particular implementation, the image scanner 1504 includes a 2D camera coupled to the patient system and/or healthcare practitioner system described herein, and the dental scan data includes a 2D image.
The dental scan data store 1506 is intended to represent a data store to store generated dental scan data. In a particular implementation, the patient registration engine 1502 includes some or all of the images of the dental scan data store 1506 in the applicable patient records of the patient records data store 1507. The dashed arrow from the patient registration engine 1502 to the image scanner 1504 is intended to indicate that the image scanner 1504 may or may not have created a suitable image prior to patient registration. For example, a potential patient may take an image with a smartphone.
The segment data storage 1509 includes segment data. Since the segmentation data includes a coordinate system, the setting engine 1518 may use a function of converting an object (tooth) into a subjectively ideal form, which is referred to as a final position.
The raw and final position data store 1510 is intended to represent a data store to store the raw and final positions and orientations of the patient's teeth. It may be noted that the final position may depend on aesthetic differences between different orthodontists (and patients), and the determination of the final position is not traditionally considered as part of the segmentation step; it is assumed herein that a suitably configured AI (not shown) obtains the segmented data and manipulates it to the desired final position. Alternatively or additionally, the setup engine 1518 may generate additional intermediate positions, but in this example, assume that the positions are processed by the phasing engine 1520.
The patient transaction engine 1512 is intended to represent hardware configured to conduct transactions of 3D printed medical instruments based on dental procedures. In a particular implementation, the transactions include contract document transactions between the patient and the dental practitioner, and payments for dental procedures based on 3D printed medical instruments. It may be desirable to be able to display the raw and final positions to a potential patient, which is why the setup engine 1518 does at least enough work to provide the final positions (or at least final position simulations) in the raw and final position data store 1510 for use by the patient matters engine 1512.
The raw position data store 1513 may be part of the raw and final position data store 1510, but is shown separately to clearly show that the lead starter aligner 3D print engine 1514 only requires raw position coordinates (including other parameters of the mouth) to ensure the aligner fits.
The guide starter aligner 3D print engine 1514 is intended to represent hardware configured to generate 3D print data of a guide starter based on the position of an object representing teeth. In a particular implementation, the 3D print data comprises a plurality of 2D image data layers suitable for 3D printing.
The local 3D printer 1516 is intended to represent hardware configured to produce a starter 3D aligner based on 3D data generated by the boot starter aligner 3D print engine 1514. In a particular implementation, the starter 3D aligner is intended for trial use rather than for disposal purposes. For example, the activator 3D aligner has no patient specific tooth profile and is generally shaped to fit the patient's gum curve.
The setup engine 1518 is intended to represent hardware configured to set a tooth straightening treatment when the patient transaction engine 1512 completes a transaction. In setting the tooth straightening treatment, the setup engine 1518 retrieves the patient record including the segmentation data and passes the raw and final position data to the staging engine 1520.
The phasing engine 1520 is intended to represent hardware configured to determine parameters of a tooth straightening treatment using an aligner set. In particular implementations, the treatment parameters may include a budget range, a dental treatment period (e.g., duration), a post-treatment state (e.g., post-treatment tooth arrangement), and an acceptable pain level, among others.
The treatment planning engine 1522 is intended to represent hardware configured to generate a treatment plan based on patient records and treatment conditions. In particular implementations, the treatment plan may include the patient's expected post-treatment tooth arrangement, treatment period (e.g., duration and stage), expected pain level, estimated price, type and design of 3D printed medical instruments to be used for the different stages of treatment, and the manner and duration of attaching the 3D printed medical instruments, among other things.
The review and approval engine 1524 is intended to represent hardware configured to present and receive approval of treatment plans generated by the treatment planning engine 1522 to patients, dental practitioners, and/or experts in the staging field. In certain implementations, control may be passed between the staging engine 1520, the treatment planning engine 1522, and the review and approval engine 1524 multiple times before passing control to the aligner set providing engine 1528.
The aligner set provisioning engine 1526 is intended to represent hardware configured to generate aligners for a patient to be delivered to the patient. In a particular implementation, the set of aligners is 3D printed at the same location as the guide aligner. In the alternative, the aligner set is manufactured in a known or convenient manner, as time is not necessarily important as opposed to guiding the aligner.
Fig. 16 is a block diagram 1600 of an example of a market entry system for a 3D printing appliance. The graph 1600 includes a patient registration engine 1602, a patient records data store 1604 coupled to the patient registration engine 1602, a patient compliance engine 1606 (a.k.a. an API engine) coupled to the patient registration engine 1602 and the patient records data store 1604, a patient social network data store 1608 coupled to the patient compliance engine 1606, at least one patient device 1610 coupled to the patient social network data store 1608, a patient matters engine 1612 coupled to the patient records data store 1604, a scanning engine 1614 coupled to the patient matter engine 1612, an image sensor 1615 coupled to the scanning engine 1614, a segmentation engine 1616 coupled to the scanning engine 1614, an initial and final location data store 1618 coupled to the patient matter engine 1612 and the segmentation engine 1616, an initiator device 3D print engine 1620 coupled to the initial and final location data store 1618, and a 3D printer 1622 coupled to the initiator device 3D print engine 1620. In particular implementations, components previously described herein are configured to work with (or be implemented in conjunction with) market entry components such as the patient compliance engine 1606 and the patient social network data store 1608, and the like.
The patient registration engine 1602 is intended to represent hardware configured to register a patient that is to receive 3D-printing medical instrument-based treatment. In a particular implementation, the patient registration engine 1602 depicted in fig. 16 corresponds to the patient registration engine 304 in fig. 3.
Patient record data store 1604 is intended to represent a data store of one or more patient records. In the example of FIG. 16, patient records data store 1604 includes information about patients in the customer cycle that is updated as customers opt-in, take action on social media, and utilize services. In a particular implementation, patient record data store 1604 depicted in fig. 16 corresponds to patient record data store 506 in fig. 5.
The patient compliance engine 1606 is intended to represent hardware configured to seek evidence of compliance with goals, etc., that have an impact on aspects of the services provided. The patient compliance engine 1606 can also clear posts that are bad, inappropriate, or otherwise not compliant. In particular implementations, the patient compliance engine includes a plurality of APIs adapted to interface with social networks and other sources (such as Facebook, Instagram, Google, or the like). The patient may be informed of the target in person (such as in a dental office or at a kiosk) via physical media such as a flyer, letter, or magazine article, or via electronic media such as an advertisement, blog, or messaging. The targets may include, for example, blogs, logs, or public conveniences that are analyzed to obtain quantities (and in some embodiments quality), and may include prepared statements, images, and/or formats. For example, a potential patient may be asked to publish an image of their face, a "preference" and a unique customer barcode or optical code, etc., in order to identify potential patients that are well-rated for the activity.
Additional benefits to the goal may include discounts on service or subscription models, etc., or unlocking special functions (such as unique, rare, or otherwise desirable cosmetic items). In particular implementations, the goals are determined according to a balance of balance model and a sliding scale designed to ensure that the activities of the potential patients may increase profits for the service provider and/or other interested parties. In particular implementations, the human agent searches through social media to track the frequency of potential patient posts, and then calculates an appropriate discount for such activity. The potential patient may also be identified using facial recognition, possibly including identifying correctable features such as misaligned teeth. The patient compliance engine 1606 stores the additional benefits or reviews earned by the potential patient in the patient record data store 1604 in association with the potential patient earned the additional benefits or reviews earned.
The patient social network data store 1608 is intended to represent a data store of content from a social media network. The patient social network datastore 1608 may be characterized as all social media content used by the patient compliance engine 1606, which may include long-term storage of content or a buffer that persists only while the content is analyzed; the precise location of the data is not as important as its utility to the patient compliance engine 1606. In certain implementations, the iframe on the home page is fed by the patient compliance engine 1606 looking for potential patient posts that may be fed in real-time into the iframe. The potential patient receives a favorable comment and has a friend post of the liking, which can be used to obtain goods or services from a service provider or related party or can be donated to a charity. Issuing favorable comments and charitable donations should leave others exciting to do the same.
The at least one patient device 1610 is intended to represent one or more devices used by a potential patient to provide social networks with content ultimately included in the patient social network data store 1608 as a result of explicit notification or exhaustive search of the social networks. Assistance may be provided to the potential patient via the at least one patient device 1610. For example, a potential patient may access rules and controls through a browser of at least one patient device 1610, such as a human agent that may select or facilitate selection of appropriate photos and text or rejection of inappropriate photos and text.
The scan engine 1614 is intended to represent hardware configured to generate patient image data of a patient body part (e.g., oral cavity portion, head, etc.) using the image sensor 1615. In particular implementations, the scanning engine 1614 corresponds to the patient scanning engine 204 and/or the practitioner 3D scanning engine 306 of fig. 2 and 3, respectively, and the image sensor 1615 corresponds to the image sensor 206, the image sensor 307, and/or the image scanner 1504 of fig. 2, 3, and 15, respectively.
The segmentation engine 1616 is intended to represent hardware configured to segment a patient's physical state based on patient 3D image data of the patient. The segmentation engine 1616 may run in the background while the patient is engaged in some other procedure or patient transaction. In particular implementations, segmentation engine 1616 corresponds to segmentation engine 308 and/or segmentation engine 1508 of fig. 3 and 15, respectively.
The initial and final position data store 1618 is intended to represent a data store to store initial and final position data for use by the patient transaction engine 1612 and medical device-level data for use by the initiator device 3D print engine 1620. The patient transaction engine 1612 serves as a treatment planning "center" in communication with the patient compliance engine 1606, image sensor 1615, and 3D printer 1622. Advantageously, this enables communication between the customer (patient) and on-demand printing in the medical and cosmetic fields, such as dentistry and orthodontics. In particular implementations, initial and final position data store 1618 corresponds to final position data store 310 and/or original and final position data store 1510 of fig. 3 and 15, respectively.
The initiator device 3D print engine 1620 is intended to represent hardware for receiving communications from the treatment planning engine, the scanner, and the 3D printer 1622.
In an example of operation, a potential patient uses at least one patient device 1610 to access a website or download an app or the like. A potential patient may order a kit for home preparation and scanning. Alternatively, the potential patient may desire to have a scanning service, such as a kiosk or a dental office. Once scanned, the stl file is created and sent to the treatment planning engine, the treatment plan is created, and the treatment plan is sent to the physician manufacturer who approved the treatment plan. The stl file is sent to a 3D printer, the mold is printed, and devices such as aligners are thermoformed. In the alternative, the stl file is sent to a 3D printer to print devices such as aligners and the like. The client makes an API echo check, social media sharing begins, and social media comes across birth. Upon online payment by the consumer or upon hit printing by the 3D printer, the customer is prompted to send comments to stimulate social media related to the received service. When 3D printing is completed, if the 3D printing device is to be delivered, a barcode/label is placed on the 3D printing device for UPS (or other delivery service) and a tracking number is obtained.
Advantageously, when the doctor clicks on the print (sends to the printer) on his or her computer, the back-end is seamlessly controlled by the patient transaction engine, and the patient compliance engine is handled for the doctor without input or assistance from the doctor. For example, when a mold begins printing, the customer may be echoed with an electronic signal (serial number) stating that the customer aligner just started printing. As the patient chooses to comply, the patient compliance engine may take relevant photos, go to an applicable social media website, and post "Emily gets Smylio Smile" or the like, or the patient may be requested to post the same.
Fig. 17 is a conceptual diagram 1700 of a side view of a 4D full aligner. The conceptual diagram 1700 includes a conceptual diagram of a toothed skull (no reference numeral), an aligner 1702, and a reservoir (resevoir) 1704. In the example of fig. 17, the aligners 1702 include a top aligner and a bottom aligner (collectively "aligners 1702"). Aligner 1702 is intended to represent an aligner that is operatively connected to substantially all of the teeth of a patient and thus may be referred to as a "full aligner". The aligner 1702 may be referred to as a 4D aligner because it is a physical (3D) object with an additional (4 th) vector associated with a reservoir 1704 that may release a drug over time. Advantageously, the 3D printed medical device may be built in a reservoir or functionally similar structure as part of the design process of the custom instrument. For aligners, one or more reservoirs may be placed along the gum line, along the edges of the teeth, between the teeth, or along the surface of the teeth, as shown in the example of fig. 17. It should be noted that the aligner described herein is not limited to a 4D aligner. For example, the aligner may be a 3D aligner having one or more reservoirs for chemicals that have a medical effect (e.g., for halitosis, gingivitis, stimulated weight loss, etc.) by being released therefrom or residing therein, or a device such as a sensor that resides in the reservoir and monitors the physical state of the patient.
Fig. 18 is a conceptual diagram 1800 of a side view of a 4D partial aligner. Conceptual diagram 1800 includes a conceptual diagram of a toothed skull (no reference numeral), aligner 1802, and reservoir 1804.
Fig. 19 is a conceptual diagram 1900 of top and bottom views of a 4D full aligner. Conceptual view 1900 includes a conceptual view of a toothed skull (no reference numeral), aligner 1902, and reservoir 1904.
Fig. 20 is a conceptual diagram 2000 of top and bottom views of a 4D partial aligner. The conceptual diagram 2000 includes a conceptual diagram of a toothed skull (no reference numeral), an aligner 2002, and a reservoir 2004.
Fig. 21 is a conceptual diagram 2100 of top and bottom views of a 4D minimum aligner. Conceptual view 2100 includes a conceptual view of a toothed skull (no reference numeral), aligner 2102, and reservoir 2104.
The entire workflow between the computer (treatment planning engine) and the thermal former and printer (including the materials used by the printer) as well as the direct production process (direct fabrication of devices such as aligners) can be managed using the techniques described herein. These and other examples provided herein are intended to be illustrative and do not necessarily limit the described implementations. As used herein, the term "implementation" means an implementation that is intended to be illustrative, by way of example, and not limiting. The techniques described in the previous text and figures may be mixed and matched as the case may be to produce alternative implementations.
Claims (21)
1. A method for generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument set based on the 3D printed medical instrument treatment plan, the method comprising:
generating a dynamic 3D printing medical instrument treatment plan generation model;
obtaining a patient record for a patient;
receiving 3D scan data of the patient;
generating a 3D printed medical instrument treatment plan by applying the patient record and the 3D scan data of the patient to the dynamic 3D printed medical instrument treatment plan generation model;
providing the 3D printed medical instrument treatment plan to a healthcare practitioner;
providing a manufacturing request to a manufacturer system for manufacturing a 3D printed medical instrument set;
providing the 3D printed medical instrument set to the patient;
receiving feedback from the healthcare practitioner regarding the 3D printed medical instrument treatment plan;
modifying the dynamic 3D-printed medical instrument treatment plan generation model based on feedback from the healthcare practitioner.
2. The method of claim 1, further comprising printing an activator 3D printing medical instrument configured to cause initial movement of one or more body parts of the patient.
3. The method according to claim 1, wherein the dynamic 3D printed medical instrument treatment plan generative model comprises attributes selected from the group consisting of: a pre-treatment state of the patient, an expected post-treatment state of the patient, a treatment schedule, an expected pain level, a budget range, and combinations thereof.
4. The method according to claim 1, wherein the 3D printed medical instrument treatment plan comprises attributes selected from the group consisting of: an expected post-treatment state of the patient, a treatment schedule, an expected pain level, an estimated cost, a type of 3D printed medical instrument to be used for each of the different phases of the 3D printed medical instrument treatment plan, a design of a 3D printed medical instrument to be used for each of the different phases of the 3D printed medical instrument treatment plan, a manner of attaching the 3D printed medical instrument, a duration of attaching the 3D printed medical instrument, and combinations thereof.
5. The method of claim 1, wherein the patient record includes 2D images of one or more body parts of the patient obtained by the patient using a mobile device.
6. The method of claim 1, wherein the 3D scan data is obtained by scanning one or more body parts of the patient or scanning an impression of one or more body parts of the patient using a 3D scanning device.
7. The method according to claim 1, wherein modifying the dynamic 3D printed medical instrument treatment plan generation model based on feedback from the healthcare practitioner is performed using machine learning techniques.
8. The method of claim 1, wherein the 3D printed medical instrument is a 3D printed dental instrument.
9. The method according to claim 1, wherein the 3D printed medical instrument treatment plan is provided to the healthcare practitioner for approval.
10. The method of claim 1, wherein the feedback from the healthcare practitioner comprises manufacturer quality of service information.
11. A system for generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument set based on the 3D printed medical instrument treatment plan, the system comprising:
a dynamic treatment plan generation model management engine;
a patient record processing engine;
a treatment planning communication engine;
wherein, in operation:
the dynamic treatment plan generation model management engine generates a dynamic 3D printing medical instrument treatment plan generation model;
the patient record processing engine obtains a patient record for a patient;
the treatment planning communication engine receives 3D scan data of the patient;
the dynamic treatment plan generation model management engine generates a 3D printed medical instrument treatment plan by applying the patient record and 3D scan data of the patient to the dynamic 3D printed medical instrument treatment plan generation model;
the treatment plan communication engine provides the 3D printed medical instrument treatment plan to a healthcare practitioner;
the treatment planning communication engine providing a manufacturing request to a manufacturer system for manufacturing a 3D printed medical instrument set to be provided to the patient;
the treatment plan communication engine receiving feedback from the healthcare practitioner regarding the 3D printed medical instrument treatment plan;
the dynamic treatment plan generation model management engine modifies the dynamic 3D printed medical instrument treatment plan generation model based on feedback from the healthcare practitioner.
12. The system of claim 11, further comprising a 3D printing engine, wherein, in operation, the 3D printing engine uses a 3D printing device to print an initiator 3D printing medical instrument configured to cause initial movement of one or more body parts of the patient.
13. The system according to claim 11, wherein the dynamic 3D printed medical instrument treatment plan generative model includes attributes selected from the group consisting of: a pre-treatment state of the patient, an expected post-treatment state of the patient, a treatment schedule, an expected pain level, a budget range, and combinations thereof.
14. The system of claim 11, wherein the 3D printed medical instrument treatment plan includes attributes selected from the group consisting of: an expected post-treatment state of the patient, a treatment schedule, an expected pain level, an estimated cost, a type of 3D printed medical instrument to be used for each of the different phases of the 3D printed medical instrument treatment plan, a design of a 3D printed medical instrument to be used for each of the different phases of the 3D printed medical instrument treatment plan, a manner of attaching the 3D printed medical instrument, a duration of attaching the 3D printed medical instrument, and combinations thereof.
15. The system of claim 11, wherein the patient record includes 2D images of one or more body parts of the patient obtained by the patient using a mobile device.
16. The system of claim 11, further comprising a scan engine, wherein, in operation, the scan engine obtains the 3D scan data by scanning one or more body parts of the patient or scanning an impression of one or more body parts of the patient using a 3D scanning device.
17. The system of claim 11, wherein in operation, the dynamic treatment plan generation model management engine modifies the dynamic 3D printed medical instrument treatment plan generation model based on feedback from the healthcare practitioner using machine learning techniques.
18. The system of claim 11, wherein the 3D printed medical instrument is a 3D printed dental instrument.
19. The system according to claim 11, further comprising an review and approval engine, wherein in operation, the review and approval engine provides the 3D printed medical instrument treatment plan to the healthcare practitioner for approval.
20. The system of claim 11, wherein the feedback from the healthcare practitioner comprises manufacturer quality of service information.
21. A system for generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument set based on the 3D printed medical instrument treatment plan, the system comprising:
means for generating a dynamic 3D printed medical instrument treatment plan generation model;
means for obtaining a patient record for a patient;
means for receiving 3D scan data of the patient;
means for generating a 3D printed medical instrument treatment plan by applying the patient record and 3D scan data of the patient to the dynamic 3D printed medical instrument treatment plan generation model;
means for providing the 3D printed medical instrument treatment plan to a healthcare practitioner;
means for providing a manufacturing request to a manufacturer system for manufacturing a 3D printed medical instrument set to be provided to the patient;
means for receiving feedback from the healthcare practitioner regarding the 3D printed medical instrument treatment plan; and
means for modifying the dynamic 3D-printed medical instrument treatment plan generation model based on feedback from the healthcare practitioner.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862669312P | 2018-05-09 | 2018-05-09 | |
| US62/669,312 | 2018-05-09 | ||
| PCT/US2019/031635 WO2019217764A1 (en) | 2018-05-09 | 2019-05-09 | Generating a 3d-printed medical appliance treatment plan and providing 3d-printed medical appliances in accordance therewith |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112367945A true CN112367945A (en) | 2021-02-12 |
Family
ID=68467568
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980045508.4A Pending CN112367945A (en) | 2018-05-09 | 2019-05-09 | Generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument according thereto |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20210236251A1 (en) |
| EP (1) | EP3790504A4 (en) |
| CN (1) | CN112367945A (en) |
| WO (1) | WO2019217764A1 (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2021092524A1 (en) | 2019-11-07 | 2021-05-14 | Smylio Inc. | Saliva collection and testing system |
| US11842484B2 (en) | 2021-01-04 | 2023-12-12 | James R. Glidewell Dental Ceramics, Inc. | Teeth segmentation using neural networks |
| US11191618B1 (en) | 2021-01-06 | 2021-12-07 | Arkimos Ltd | Systems and methods for forming a dental appliance |
| US20230255725A1 (en) * | 2022-02-14 | 2023-08-17 | International Business Machines Corporation | Digital twin based on orthodontic alignment |
| EP4293677A1 (en) * | 2022-06-16 | 2023-12-20 | Koninklijke Philips N.V. | Dental treatment provider recommendation |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20160024894A (en) * | 2016-02-16 | 2016-03-07 | 최병억 | System for designing customized nasal implant |
| CN105916455A (en) * | 2013-11-25 | 2016-08-31 | 普罗米修斯外科有限公司 | Method and apparatus for use in the production of surgical guide |
| WO2017186255A1 (en) * | 2016-04-26 | 2017-11-02 | Hafez Mahmoud Alm El Din | An apparatus and system for acquiring data from bones and joints, plan surgery and manufacture instruments or implants |
| US20170360578A1 (en) * | 2014-12-04 | 2017-12-21 | James Shin | System and method for producing clinical models and prostheses |
| WO2018067966A1 (en) * | 2016-10-07 | 2018-04-12 | New York Society For The Relief Of The Ruptured And Crippled, Maintaining The Hostpital For Special Surgery | Patient specific 3-d interactive total joint model and surgical planning system |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8439672B2 (en) * | 2008-01-29 | 2013-05-14 | Align Technology, Inc. | Method and system for optimizing dental aligner geometry |
| WO2013112882A1 (en) * | 2012-01-26 | 2013-08-01 | Justin Daya | Systems and methods of on-demand customized medicament doses by 3d printing |
| US20160022466A1 (en) * | 2014-07-24 | 2016-01-28 | Lim Innovations, Inc. | Sequential series of orthopedic devices that include incremental changes in form |
| CN107106260A (en) * | 2014-12-30 | 2017-08-29 | 3M创新有限公司 | The dental instrument of the occlusal surface of exposure is provided |
| US10213277B2 (en) * | 2015-06-09 | 2019-02-26 | Align Technology, Inc. | Dental appliance binding structure |
| US10842594B2 (en) * | 2016-05-24 | 2020-11-24 | Clearcorrect Operating, Llc | Virtual modeling of gingiva adaptations to progressive orthodontic correction and associated methodology of appliance manufacture |
| US10463455B2 (en) * | 2016-08-12 | 2019-11-05 | Global Dental Science, LLC | Formed denture and method of making same |
| GB201617507D0 (en) * | 2016-10-14 | 2016-11-30 | Axial3D Limited | Axial3D UK |
| US11000334B1 (en) * | 2017-07-12 | 2021-05-11 | K2M, Inc. | Systems and methods for modeling spines and treating spines based on spine models |
| US11096763B2 (en) * | 2017-11-01 | 2021-08-24 | Align Technology, Inc. | Automatic treatment planning |
-
2019
- 2019-05-09 CN CN201980045508.4A patent/CN112367945A/en active Pending
- 2019-05-09 EP EP19800745.2A patent/EP3790504A4/en active Pending
- 2019-05-09 US US17/053,975 patent/US20210236251A1/en active Pending
- 2019-05-09 WO PCT/US2019/031635 patent/WO2019217764A1/en unknown
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105916455A (en) * | 2013-11-25 | 2016-08-31 | 普罗米修斯外科有限公司 | Method and apparatus for use in the production of surgical guide |
| US20170360578A1 (en) * | 2014-12-04 | 2017-12-21 | James Shin | System and method for producing clinical models and prostheses |
| KR20160024894A (en) * | 2016-02-16 | 2016-03-07 | 최병억 | System for designing customized nasal implant |
| WO2017186255A1 (en) * | 2016-04-26 | 2017-11-02 | Hafez Mahmoud Alm El Din | An apparatus and system for acquiring data from bones and joints, plan surgery and manufacture instruments or implants |
| WO2018067966A1 (en) * | 2016-10-07 | 2018-04-12 | New York Society For The Relief Of The Ruptured And Crippled, Maintaining The Hostpital For Special Surgery | Patient specific 3-d interactive total joint model and surgical planning system |
Also Published As
| Publication number | Publication date |
|---|---|
| EP3790504A1 (en) | 2021-03-17 |
| EP3790504A4 (en) | 2022-03-09 |
| WO2019217764A1 (en) | 2019-11-14 |
| US20210236251A1 (en) | 2021-08-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112367945A (en) | Generating a 3D printed medical instrument treatment plan and providing a 3D printed medical instrument according thereto | |
| US11501363B2 (en) | 3D platform for aesthetic simulation | |
| US11798046B2 (en) | Health-care systems and methods | |
| US11094414B2 (en) | Arrangements for intraoral scanning | |
| US20190244264A1 (en) | Health-care e-commerce systems and methods | |
| US20210267717A1 (en) | Dental impression kit and methods therefor | |
| US20220160475A1 (en) | Dental impression retake kit and methods therefor | |
| US20170329922A1 (en) | Telemedicine platform with integrated e-commerce and third party interfaces | |
| CN106796706A (en) | Dentistry and orthodontia service and marketing | |
| US7383198B1 (en) | Delivery information systems and methods | |
| US20090023113A1 (en) | Dental Appliance On-Line Ordering Including Display Of End Product Image And Mold Three-Dimensional Scanning For Digital Transmission | |
| WO2007081757A2 (en) | Total dentist | |
| KR102084885B1 (en) | Nail art system using AR | |
| US20180368953A1 (en) | Dental impression kit and methods therefor | |
| US20230223126A1 (en) | Digital Health Platform with Prescription Management and Integrated E-Commerce Curation | |
| US20220262468A1 (en) | System and method for managing electronic medical records | |
| Adams et al. | Exploratory qualitative study to understand the underlying motivations and strategies of the private for-profit healthcare sector in urban Bangladesh | |
| US11694249B2 (en) | Prepaid bundled health, dental, and veterinary services with virtual payment distribution | |
| KR102615253B1 (en) | System for providing dental prosthesis production information and method thereof | |
| US20220013219A1 (en) | Computer-implemented method and related system for providing clear aligners directly to patients | |
| US11830052B2 (en) | Prepaid bundled health, dental, and veterinary services with virtual payment distribution | |
| EP3671756A1 (en) | Computer-implemented method for creating a 3d-printing file of at least one dental aligner for dental self-treatment of a customer based on at least one digital image of the customer's teeth, and data processing system for carrying out the steps of the method | |
| US20230410961A1 (en) | Subscription-based oral health network | |
| WO2020128102A1 (en) | Computer-implemented method for creating a 3d-printing file of at least one dental aligner for dental self-treatment of a customer based on at least one digital image of the customer's teeth, and dental aligner, in particular 3d-printed |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |