WO2024026361A1

WO2024026361A1 - Methods and apparatuses for teledentistry

Info

Publication number: WO2024026361A1
Application number: PCT/US2023/071045
Authority: WO
Inventors: Sepand HOKMABADI; Devin PICCIOLINI
Original assignee: Hokmabadi Dental Corporation
Priority date: 2022-07-26
Filing date: 2023-07-26
Publication date: 2024-02-01

Abstract

Provided herein are systems and methods for providing dental care to patients of a dental practice. The systems and methods can include virtual consultation hardware, software, and process flows that enable an expert dentist to focus solely on examining new and current patients, without the need to perform surgeries or in-person dental care. In one implementation, an expert dentist performs virtual consultations of new and current patients. The virtual consultation can include video conferencing, phone calls, texts, or emails. The expert dentist can review the patient's dental history, concerns, needs, and current diagnostics to prepare a treatment plan for the patient.

Description

METHODS AND APPARATUSES FOR TELEDENTISTRY

PRIORITY CLAIM

[0001] This patent application claims priority to U.S. provisional patent application no. 63/369,474, titled “METHODS AND APPARATUSES FOR TELEDENTISTRY”, and filed on July 26, 2022, which is herein incorporated by reference in its entirety.

INCORPORATION BY REFERENCE

[0002] All publications and patent applications mentioned in this specification are incorporated herein by reference in their entirety to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

BACKGROUND

[0003] Dental School’s focus primarily or exclusively on training Dental Surgeries and very little attention is paid to diagnosing. This lack of training on diagnosis leads to inconsistent and unpredictable recommendations from Dentist leads to patients’ having compromised oral health and poor experiences.

[0004] Traditional dental practices typically have one or more dentists to provide dental care to patients. The most experienced dentist in a dental practice (typically 10+ of experience at one location) can be referred to as an expert dentist. These expert dentists provide patients with better clinical outcomes due to better assessment of occlusal risk, periodontal risk, decay risk while spending more time truly understanding the patients’ expectation. Since being in the same location for many years helps the expert dentist see the clinical results of their recommendations over a longer period of time, these expert dentists have more experience and a better understanding with long term clinical outcomes. Expert dentists also typically participate in continuing education beyond that needed for license renewal, which helps diagnose more advanced problems. Additionally, expert dentists often have more experience with technology to help identify problems earlier, such as digital x-rays, pantographic x-rays, intro-oral cameras, 3D tooth scanners, CBCT, etc. The physical limitation of a dental practice generally limits how much time, how many patients and in what geography the expert dentist can treat patients. For example, an expert dentist may be limited to seeing approximately 2,000 active patients, and accept up to only 50 new patients per month.

[0005] Traditional dental practices typically utilize a single location for all dental services, including new patient registration, initial exams, dental work, and hygiene visits. Referring to flowchart 100 of FIG. 1, a traditional dental diagnosing model includes, at block 102, bringing in new patients to the office or physical location (approximately 20-40 new patients per month depending on the number of dental practitioners). At block 104, the new patients typically arrive at the dental office and have a brief conversation to discuss dental health, concerns, prior treatment, insurance, etc. At block 106, these new patients typically are moved to an exam room in which they meet with a dentist (such as an expert dentist) for a brief exam and discussion about dental health and treatment planning. Next, at block 108, any dental surgery is performed by one of the dentists, and finally at block 110, the new patient is scheduled to receive routine preventative care dental hygiene appointments, typically twice per year for cleaning and evaluation. Since the expert dentist in a typical dental practice generally spends his or her time performing complicated procedures and surgeries, access to new and current patients for preventative care, diagnosis, and treatment planning is generally limited. The limitations of exams by the expert dentist leads to lowered standard of care in the industry. There is a need to increase access to expert dentists by the patient populations of traditional dental practices.

[0006] Traditional dental practices also typically use proprietary dental or patient management software that includes scheduling information, patient information, dental records, and any other type of data related to the practice or the dental care of the patients. These dental or patient management software suites are typically not customizable and are not configured or designed to interface with other software systems. Numerous challenges arise in trying to increase access to expert dentists, including virtually, while maintaining communication and or functionality with traditional dental or patient management software.

SUMMARY OF THE DISCLOSURE

[0007] Implementations address the need to improve access to care for patients, the safety of dental diagnosis, quality of dental care, access to expert dentists, and efficiency of dental practices. The present application addresses these and other technical problems by providing technical solutions and/or automated agents that register new dental patients, acquire patient dental history data and desired outcomes, provide video and/or teleconferencing between a patient and an expert dentist for diagnosis and treatment planning, and communications and scheduling systems within a dental practice for coordinating patient care.

[0008] In particular, described herein are methods and systems that may allow dental practices to operate more efficiently and in a cost-effective manner. For example, described herein are systems that may guide one or more dental practitioner, including dentist, dental technician, and the like, in pre-screening and processing of patients, providing information and prompts to the technician or dentist during various phases of patient care management, may assist in training the dentist, and may shepherd patients through a number of coordinated pretreatment and treatment encounters. These methods and apparatuses (e.g., software, firmware, etc.) may be particularly effective at enhancing interaction with a larger number of patients than has previously been possible.

[0009] For example, described herein are methods and systems configured to coordinate one or more dental professionals (e.g., auxiliaries, such as dental technicians, interviewers, etc., junior dentists, and senior dentists) in working with, including transitioning between, individual patients. In particular, these methods and systems for performing them, may include initial patient screening, including scheduling, prompting one or more auxiliary in collecting patient information, such as X-rays, insurance information, patient medical history, dental history, etc. The methods and apparatuses may include one or more interactive screens for engaging the auxiliary and preparing to automatically assign and prepare patient information for review by a dentist (e.g., a senior dentist). For example, the method or system may include coordinating the review of patient X-rays for possible treatment, review of insurance, review of patient-reported concern(s), determine and/or review patient risk of cavities, gum disease and biting forces, review of medical history, and/or review of dental history. In particular, this information may be compiled into a compact presentation for rapid review. Information may be digitally stored and displayed, and may be annotated by the auxiliary, senior dentist, and/or junior dentist.

[0010] For example, during an initial patient encounter, a patient may be seen in a dental office and may initially be interviewed by an auxiliary. A patient file may be opened at the time of the first encounter, which may automatically both guide the auxiliary in collecting patientspecific encounter information, and may also automatically or semi -automatically schedule the next step in the patient treatment, such as an interview with an expert dentist. The Auxiliary may be trained and guided (e.g., by the systems described herein) in asking the patient specific questions, and may collect the resulting responses in a patient response database that is shared with the senior and junior dentists. For example, the auxiliary may collect and save imaging data (e.g., X-rays, scans, etc.) of the patient’s teeth as part of this initial screening. The auxiliary may also collect the patient’s medical history, insurance information and may be prompted (e.g., by the software) to inquire about the reasons for seeking dental care. As part of this initial engagement, the auxiliary may take X-rays or other imaging of the teeth. While processing the patient, the system may prompt and prepare a senior dentist, and may schedule an encounter (e.g., within a fixed period of time, such as one hour, 45 minutes, 30 minutes, etc.) with the patient. Multiple patients may be concurrently processed, and the system may coordinate collection of patient data, assigning a senior dentist, and may contact and prepare each senior dentist. [0011] The senior dentist may have one or (more commonly) more separate patients scheduled for remote consultation. The system may communicate the schedule and preparatory information (e.g., a compact or streamlined set of patient information). For example, patients may be scheduled in 10 min increments at a first location; while at this first location, an auxiliary may perform testing on the patient’s teeth, either before or in combination with a remotely located senior dentist. For example, the auxiliary may measure pockets, cracked teeth, etc. [0012] The senior (or a junior) dentist may then review the patient’s information and may be prompted and kept on time and target by the software during an encounter with the patient. For example, the senior dentist may, following the prompted review of the compiled/collected patient data (or an extracted version of the patient data), meet with the patient, and may diagnose the patient, after determining patient concerns. The type of care to be provided may be characterized in one or more categories, such as type 1 (urgent care), type 2 (preventative care), type 3 (cosmetic care), etc. The system may categorize (e.g., the dentist may select from a menus of options) the type of care to be provided, which may further refine the treatment to be provided, including selectin the junior dentist to handle the case, and scheduling the next (treatment) patient encounter(s).

[0013] For example, described herein are methods for providing dental treatment to a patient with a dental treatment system, comprising the steps of: obtaining patient information relating to a patient; obtaining dental diagnostic information relating to a patient’s dental health; initiating a virtual consultation between the patient and an expert dentist; obtaining a dental treatment plan from the expert dentist; and presenting the dental treatment plan to the patient.

[0014] In one aspect, a method for providing dental treatment to a patient with a computer implemented dental treatment system, comprising the steps of: making API calls to two or more 3rd party software programs with a middleware software system to obtain patient information relating to a patient; generating or updating data in a lookup table with the middleware software system that associates first API data from a first 3rd party software program corresponding to the patient with second API data from a second 3rd party software program corresponding to the patient; and providing a custom API specification from the middleware software system to an application suite that defines how to use or implement API calls from the application suite to the middleware software system to access data in the lookup table.

[0015] In some aspects, the 3rd party software programs provide payment services, scheduling services, communications services, locations services, and or medical history data storage services.

[0016] In one aspect, the patient information is selected from the group consisting of personal information, concerns with dental health, medical history, dental history, insurance coverage, custom needs, obstacles to receiving dental care, X-ray imaging, radiograph imaging, intraoral imaging, infrared imaging, caries detection results, oral cancer screening information, lesion screening information, and plaque detection information, cold test information, bite stick test information, probing information, palpitation information, decay probing information, or EPT test information, payment information, invoice information, and communication information.

[0017] In some aspects, the first API data comprises payment information for the patient. [0018] In another aspect, the first API data comprises scheduling information for the patient. [0019] In some aspects, the first API data comprises patient history information for the patient.

[0020] In one aspect, the application suite comprises a mobile application.

[0021] In some aspects, the application suite comprises an online form.

[0022] In one aspect, the application suite comprises a customer relationship management (CRM) program.

[0023] In some aspects, the method includes outputting data from the lookup table.

[0024] In one aspect, outputting comprises displaying the data from the lookup table on a monitor.

[0025] A system is provided, comprising: one or more processors; memory coupled to the one or more processors, the memory configured to store computer-program instructions, that, when executed by the one or more processors, implement a computer-implemented method, the computer-implemented method comprising: making API calls to two or more 3rd party software programs with a middleware software system to obtain patient information relating to a patient; generating or updating a lookup table with the middleware software system that associates first API data from a first 3rd party software program corresponding to the patient with second API data from a second 3rd party software program corresponding to the patient; and providing a custom API specification from the middleware software system to an application suite that defines how to use or implement API calls from the application suite to the middleware software system to access data in the lookup table.

[0026] In some aspects, the 3rd party software programs provide payment services, scheduling services, communications services, locations services, and or medical history data storage services.

[0027] In one aspect, the patient information is selected from the group consisting of personal information, concerns with dental health, medical history, dental history, insurance coverage, custom needs, obstacles to receiving dental care, X-ray imaging, radiograph imaging, intraoral imaging, infrared imaging, caries detection results, oral cancer screening information, lesion screening information, and plaque detection information, cold test information, bite stick test information, probing information, palpitation information, decay probing information, or EPT test information, payment information, invoice information, and communication information.

[0028] In some aspects, the first API data comprises payment information for the patient. [0029] In another aspect, the first API data comprises scheduling information for the patient. [0030] In some aspects, the first API data comprises patient history information for the patient.

[0031] In one aspect, the application suite comprises a mobile application.

[0032] In some aspects, the application suite comprises an online form.

[0033] In one aspect, the application suite comprises a customer relationship management (CRM) program.

[0034] In some aspects, the method includes outputting data from the lookup table.

[0035] In one aspect, outputting comprises displaying the data from the lookup table on a monitor.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The novel features of the invention are set forth with particularity in the claims that follow. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which:

[0037] FIG. l is a block diagram illustrating a traditional dental diagnosing model.

[0038] FIG. 2A is a diagram showing an example of a computing environment configured to digitally scan a dental arch and determine a post-treatment tooth position score.

[0039] FIG. 2B is a diagram showing an example of a patient information engine(s).

[0040] FIG. 2C is a diagram showing an example a scheduling engine(s).

[0041] FIG. 2D is a diagram showing an example of a communication engine(s).

[0042] FIG. 2E is a diagram showing an example of a payment engine(s).

[0043] FIG. 2F is a diagram showing an example of a middleware engine(s).

[0044] FIG. 3 illustrates a schematic diagram of a traditional way of accessing 3rd party software services from a suite of software applications that may include a mobile app, an online or web form, and a CRM.

[0045] FIG. 4 shows a schematic diagram that correlates with a middleware engine which manages and handles communications between a middleware software system and various 3rd party API’s and also between the middleware software system and an application suite of programs that can include, for example, a mobile app, an online form, and a CRM.

DETAILED DESCRIPTION

[0046] Described herein are apparatuses (e.g., systems, computing device readable media, devices, etc.) and methods for improving the quality of dental diagnosis, dental care, access to expert dentists, and efficiency of dental practices. The present application addresses these and other technical problems by providing technical solutions and/or automated agents that register new dental patients, acquire patient dental history data and desired outcomes, provide video and/or teleconferencing between a patient and an expert dentist for diagnosis and treatment planning, and communications and scheduling systems within a dental practice for coordinating patient care. Apparatuses and methods described herein can provide a more uniform, higher standard of care, provide more accurate diagnosing and services, provide fewer dental complications, improve the overall patient experience, and vastly improve the profitability of a dental practice.

[0047] An “individual,” as used herein, may be any subject (e.g., human, non-human, adult, child, etc.) and may be alternatively and equivalently referred to herein as a “patient”, a “patient under treatment”, or a “subject.” A “patient,” as used herein, may but need not be a medical patient. An “individual” or a “patient,” as used herein, may include a person who receives dental treatment, including dental evaluations, dental cleanings, and dental surgery.

[0048] FIG. 2A is a diagram showing an example of a computing environment 200A configured to facilitate providing dental evaluations and services to one or more individuals. The environment 200A includes a computer-readable medium 202, a dental diagnostic system(s) 204, a communication system(s) 206, and a dental treatment system 208. One or more of the modules in the computing environment 200A may be coupled to one another or to modules not explicitly shown.

[0049] The computer-readable medium 202 and other computer readable media discussed herein are intended to represent a variety of potentially applicable technologies. For example, the computer-readable medium 202 can be used to form a network or part of a network. Where two components are co-located on a device, the computer-readable medium 202 can include a bus or other data conduit or plane. Where a first component is co-located on one device and a second component is located on a different device, the computer-readable medium 202 can include a wireless or wired back-end network or LAN. The computer-readable medium 202 can also encompass a relevant portion of a WAN or other network, if applicable. [0050] The dental diagnostic system(s) 204 may include one or more computer systems configured for diagnosing dental problems or diseases, including, for example, X-ray imaging systems, radiograph instruments, intraoral cameras or scanners, infrared devices, caries detection systems, oral cancer and lesion screening systems, plaque detection systems, etc. A “dental arch,” as used herein, may include at least a portion of an individual’s dentition formed by the individual’s maxillary and/or mandibular teeth, when viewed from an occlusal perspective. A dental arch may include one or more maxillary or mandibular teeth of an individual, such as all teeth on the maxilla or mandible or an individual. The dental diagnostic system(s) 204 may include memory, one or more processors, and/or sensors to detect an individual’s dental arch. In some implementations, the dental diagnostic system(s) 204 is configured to produce 2D or 3D scans or images of the individual’s dentition.

[0051] The communications system(s) 206 may include one or more computer system configured to communicate audio, video, or text messages between two or more devices or systems. For example, the communications system(s) can comprise one or more personal computers, tablets, smartphones, fax machines, etc. The communications can be in the form of text messages, emails, audio messages, video messages, audible alerts, etc. The communications system(s) 206 may include memory, one or more processors, and a display device and/or audio device to display or announce the communication. The communications system(s) 206 may be implemented as part of a computer system, a display or speaker of tablet, smartphone, personal computer, etc.

[0052] The dental treatment system 208 may include one or modules including patient information engine(s) 210, scheduling engine(s) 212, communication engine(s) 214, payment engine(s) 216, and Middleware engine(s) 218. One or more of the modules of the dental treatment system 208 may be coupled to each other or to modules not shown. The dental treatment system 208 may include a computer system, including memory and one or more processors, configured to facilitate providing dental evaluations and services to one or more individuals.

[0053] In some embodiments, the dental treatment system 208 can be implemented as software on a computer system. For example, the dental treatment system 208 can be implemented as an “app” or as software on one or more smartphones, tablets, personal computers, or the like. In one implementation, the patient information engine(s) 210 is configured to receive, store, and process patient information relating to an individual’s dental health and history. In another implementation, the scheduling engine(s) 212 is configured to receive, store, and process individual schedules and availability of patients and/or dental practitioners, and is further configured to generate schedules and/or calendars coordinating the dental care of patients with the availability of dental practitioners, while accounting for space and equipment constraints of the dental practice (e.g., patient rooms, x-ray availability, etc.). In another implementation, the communication engine(s) 214 is configured to obtain as an input, generate, transmit, receive, and/or alert one or more communication devices with communications including text, audio, and/or video communications. In one or more implementations, the payment engine(s) 216 is configured to receive or generate invoices, provide invoice and payment information to patients, and receive or process patient payments. [0054] In some embodiments, the services provided by the patient information engine(s) 210, scheduling engine(s) 212, communication engine(s) 214, and/or payment engine(s) 216 may be implemented on separate remote computing systems and accessed by the dental treatment system via the cloud. For example, patient information and/or medical history may be stored and managed by a first remote computing system, scheduling information and/or schedule processing/generation may be stored and managed by a second remote computing system, communications including SMS, messaging, and video conferencing may be implemented and managed by a third remote computing system, and payment processing and invoice generation may be implemented and managed by a fourth remote computing system. In these embodiments, each remote computing system may implement its own proprietary application programming interface (API) for accessing data stored on that remote computing system. Therefore, in the embodiment shown in FIG. 2A, in some implementations, middleware engine(s) 218 is configured to provide in-house custom APIs to wrap all the API endpoints that are used to access the other computing systems, such as the API endpoint for the patient information engine(s), the API endpoint for the scheduling engine(s), the API endpoint for the communication engine(s), and the API endpoint for the payment processing engine(s).

[0055] As used herein, any “engine” may include one or more processors or a portion thereof. A portion of one or more processors can include some portion of hardware less than all of the hardware comprising any given one or more processors, such as a subset of registers, the portion of the processor dedicated to one or more threads of a multi -threaded processor, a time slice during which the processor is wholly or partially dedicated to carrying out part of the engine’s functionality, or the like. As such, a first engine and a second engine can have one or more dedicated processors, or a first engine and a second engine can share one or more processors with one another or other engines. Depending upon implementation-specific or other considerations, an engine can be centralized, or its functionality distributed. An engine can include hardware, firmware, or software embodied in a computer-readable medium for execution by the processor. The processor transforms data into new data using implemented data structures and methods, such as is described with reference to the figures herein. [0056] The engines described herein, or the engines through which the systems and devices described herein can be implemented, can be cloud-based engines. As used herein, a cloudbased engine is an engine that can run applications and/or functionalities using a cloud-based computing system. All or portions of the applications and/or functionalities can be distributed across multiple computing devices, and need not be restricted to only one computing device. In some embodiments, the cloud-based engines can execute functionalities and/or modules that end users access through a web browser or container application without having the functionalities and/or modules installed locally on the end-users’ computing devices.

[0057] As used herein, “datastores” may include repositories having any applicable organization of data, including tables, comma-separated values (CSV) files, traditional databases (e.g., SQL), or other applicable known or convenient organizational formats. Datastores can be implemented, for example, as software embodied in a physical computer-readable medium on a specific-purpose machine, in firmware, in hardware, in a combination thereof, or in an applicable known or convenient device or system. Datastore-associated components, such as database interfaces, can be considered "part of a datastore, part of some other system component, or a combination thereof, though the physical location and other characteristics of datastore- associated components is not critical for an understanding of the techniques described herein. [0058] Datastores can include data structures. As used herein, a data structure is associated with a particular way of storing and organizing data in a computer so that it can be used efficiently within a given context. Data structures are generally based on the ability of a computer to fetch and store data at any place in its memory, specified by an address, a bit string that can be itself stored in memory and manipulated by the program. Thus, some data structures are based on computing the addresses of data items with arithmetic operations; while other data structures are based on storing addresses of data items within the structure itself. Many data structures use both principles, sometimes combined in non-trivial ways. The implementation of a data structure usually entails writing a set of procedures that create and manipulate instances of that structure. The datastores, described herein, can be cloud-based datastores. A cloud-based datastore is a datastore that is compatible with cloud-based computing systems and engines.

[0059] FIG. 2B is a diagram showing an example of a patient information engine(s) 210a. As described above, the patient information engine(s) can be a software module or component implemented within the dental treatment system (e.g., as software or an app). The patient information engine(s) 210a may include a dental diagnostic engine 216, a dental history engine 218, an API engine 219, and a patient information datastore 220. One or more of the modules of the patient information engine(s) 210a may be coupled to each other or to modules not shown. The patient information engine(s) 210a of the dental treatment system 208 may implement automated agents to configured to process patient information from the dental diagnostic system(s) 204 and from other sources, including from medical record databases, patient record databases, dental record databases, insurance company databases, and/or direct input by a dental or medical practitioner. The patient information can comprise, for example, dental insurance, personal information such as name, age, gender, etc. The patient information can further comprise prior dental history including prior dental treatments, prior dental x-rays or dental imaging, etc. The patient information can also comprise diagnostic information from the dental diagnostic system(s) 204, such as new/current dental imaging, scans, etc. Additionally, the patient information can comprise a new diagnosis or evaluation performed by a dental practitioner. The patient information can be stored on and received from a proprietary dental or patient management system. The patient information described herein can be automatically entered or transferred into the patient information engine(s) 210, or alternatively, can be manually input or entered by a dental practitioner.

[0060] The dental diagnostic engine 216 may implement one or more automated agents configured to receive, process, and/or generate dental diagnostic information relating to a patient’s dental health. In one implementation, the dental diagnostic engine is configured to receive dental diagnostic information from the dental diagnostic system(s) 204. As described above, this dental diagnostic information can include X-ray imaging information, radiograph information, intraoral cameras or scanning information, infrared information, caries detection information, oral cancer and lesion screening information, plaque detection information, etc. The dental diagnostic engine 216 may also receive dental diagnostic information resulting from a dental examination by a dental practitioner. This dental diagnostic information can be entered automatically into the dental diagnostic information (e.g., from another dental or patient management software), or may be input manually by the dental practitioner. In some embodiments, the dental diagnostic engine is configured to automatically interface with the dental or patient management software.

[0061] The dental history engine 218 may implement one or more automated agents configured to receive, process, and/or generate prior dental history information. Prior dental history information can include, for example, prior dental treatment and/or diagnostic information including previous dental surgeries, dental treatments, and/or dental evaluations. In one implementation, the dental history engine 218 can implement one or more automated agents to obtain dental history information including, for example, personal information such as the patient’s name, phone number, DOB, address, patient number, etc. that would allow for lookup of a prior treatment. The dental history information can be obtained by the dental history engine automatically (e.g., via communication with a dental database or other dental or patient management software), or alternatively, can be manually input by a dental practitioner. [0062] In some embodiments, the patient information engine(s) are remote software program(s) residing on a remote computing system. In these embodiments, the patient information engine(s) may include an API engine 219 configured to provide a software interface between the patient information engine(s) and other software programs or computing devices. The API engine 219 may include an API specification that defines calls to the API engine (i.e., the API specification explains or defines how to use or implement API calls to the patient information engine(s). Calls to the API engine 219 may request some or all data from the dental diagnostic engine, dental history engine, and/or the patient information datastore.

[0063] The patient information datastore 220 may be configured to store patient information related to a patient’s dental history or dental health. The patient information can be generated, accessed, or processed by the dental diagnostic engine 216, dental history engine 218, or the API engine 219. The patient information may comprise the data or information described above, including dental diagnostic information and/or prior dental history information. In some implementations, the patient information can be stored on the cloud, such as in the computer readable medium 202.

[0064] FIG. 2C is a diagram showing an example of a scheduling engine(s) 212a. As described above, the scheduling engine(s) can be a software module or component implemented within the dental treatment system (e.g., as software or an app). The scheduling engine(s) 212a may include a treatment scheduling engine 222, a practice scheduling engine 224, an API engine 225, and a scheduling datastore 226. One or more of the modules of the patient scheduling engine(s) 212a may be coupled to each other or to modules not shown. The scheduling engine(s) 212a of the dental treatment system 208 may implement automated agents to configured to receive, process, and/or store scheduling information, including individual schedules and availability of patients, dental practitioners, physical room or equipment availability of a dental practice, and/or virtual waiting room or exam room availability and status. The scheduling information can comprise, for example, availability of individual patients to receive dental diagnostics or treatment at a dental practice. In another implementation, the scheduling information can comprise availability of dental practitioners, including dental assistants, dental hygienists, and dentists to evaluate, diagnose, treat, or communicate with patients either in person or virtually (e.g., by video call, phone call, or text/email messaging). The scheduling information can further comprise access to or availability of office space, evaluation rooms, surgical rooms, virtual waiting rooms or exam rooms, and diagnostic equipment of a dental practice. The scheduling information can be stored on and received from a proprietary dental or patient management system. In some embodiments, the treatment scheduling engine 222 is configured to update and/or manage the virtual waiting rooms of a dental practice, allowing providers such as dentists to view which patients are checked-in and waiting in a virtual waiting room. The scheduling information described herein can be automatically entered or transferred into the scheduling engine(s) 212a, or alternatively, can be manually input or entered by a dental practitioner.

[0065] The treatment scheduling engine 222 may implement one or more automated agents configured to receive, generate, and coordinate the availability of patients to receive dental care with the availability of dental practitioners to provide dental care. For example, the treatment scheduling engine 222 can receive, either automatically or by manual input, the availability of a patient. The treatment scheduling engine 222 can also receive, either automatically or by manual input, the availability of dental practitioners, including dental staff, dental hygienists, and dentists. The availability of patients and/or dental practitioners can account for vacation time, breaks, working schedules, etc. In some implementations, the treatment scheduling engine 222 can link or communicate with a scheduling database that can include one or more individual schedules of patient’s and/or dental practitioners. The treatment scheduling engine 222 can determine availability of patients and/or dental practitioners based on scheduling information from the scheduling database. In other implementations, individual schedules and/or availability are input manually, such as by dental staff, into a scheduling software or database to coordinate schedules and availability. The scheduling information can be stored on and received from a proprietary dental or patient management system.

[0066] The practice scheduling engine 224 may implement one or more automated agents configured to receive, generate, and coordinate the availability of treatment rooms, virtual waiting rooms or exam rooms, surgical rooms, and/or dental diagnostic or treatment systems or hardware of a dental practice. In some implementations, the practice scheduling engine 224 can communicate with the treatment scheduling engine 222 to coordinate the availability of patients and/or dental practitioners with the availability of treatment rooms, virtual waiting rooms or exam rooms, surgical rooms, and/or dental diagnostic or treatment systems or hardware For example, the practice scheduling engine 224 can receive, either automatically or by manual input, the availability of a patient for a physical visit to a dental facility or alternatively the availability and/or presence of the patient in a virtual waiting room. The treatment scheduling engine 222 can also receive, either automatically or by manual input, the availability of dental practitioners, including dental staff, dental hygienists, and dentists. The availability of patients and/or dental practitioners can account for vacation time, breaks, working schedules, etc. In some implementations, the practice scheduling engine 224 can link or communicate with a scheduling database that can include information related to the availability or usage of dental treatment rooms, dental surgical rooms, or dental equipment of a dental practice. In other implementations, availability of rooms or dental equipment are input manually, such as by dental staff, into a scheduling software or database to coordinate schedules and availability. The practice information can be stored on and received from a proprietary dental or patient management system.

[0067] In some embodiments, the scheduling engine(s) are remote software program(s) residing on a remote computing system. In these embodiments, the scheduling engine(s) may include an API engine 225 configured to provide a software interface between the scheduling engine(s) and other software programs or computing devices. The API engine 225 may include an API specification that defines calls to the API engine (i.e., the API specification explains or defines how to use or implement API calls to the patient information engine(s). Calls to the API engine 225 may request some or all data from the treatment scheduling engine, practice scheduling engine, and/or the scheduling datastore.

[0068] The scheduling datastore 226 may be configured to store scheduling information. As described above, the scheduling information can comprise, for example, availability of individual patients to receive dental diagnostics or treatment at a dental practice or in a virtual waiting room or virtual exam room. In another implementation, the scheduling information can comprise availability of dental practitioners, including dental assistants, dental hygienists, and dentists to evaluate, diagnose, treat, or communicate with patients. The scheduling information can further comprise access to or availability of office space, evaluation rooms, surgical rooms, and diagnostic equipment of a dental practice. The scheduling information can be generated, accessed, or processed by the treatment scheduling engine 222, practice scheduling engine 224, or the API engine 225. In some implementations, the scheduling information can be stored on the cloud, such as in the computer readable medium 202.

[0069] FIG. 2D is a diagram showing an example of a communication engine(s) 214a. The communication engine(s) 214a may include a text communication engine 228, an audio communication engine 230, a video communication engine 232, and a communication datastore 234. One or more of the modules of the communication engine(s) 214a may be coupled to each other or to modules not shown. The communication engine(s) 214a of the dental treatment system 208 may implement automated agents to configured to obtain as an input, generate, transmit, receive, and/or alert one or more communication devices with communications including text, audio, and/or video communications. The communication devices can include electronic devices not limited to personal computers, laptops, tablets, smartphones, fax machines, etc. The communications can include, for example, text messages, emails, voice messages, voice calls, video messages, video calls, faxes, visual alerts including blinking lights, and/or audible alerts such as beeps, alarms, or other audible notifications. In general, the communication engine(s) 214a facilitate communications between team members of a dental practice and patients of the dental practice, such as between a proprietary software or app loaded or installed on the patients’ smartphones, tablets, or personal computers and between an app or software loaded or installed on the dental providers’ smartphones, tablets, or personal computers.

[0070] The text communication engine 228 may implement one or more automated agents configured to receive, process, and/or generate text communications between one or more communication devices. The text communication engine can be implemented in an app loaded or installed on the patient’s smartphone, tablet, or personal computer. In some implementations, the text communications are between dental providers or employees of a dental practice relating to the dental care, diagnosis, or treatment of one or more patients. In other implementations, the text communications are between dental providers and a patient relating to the dental care, diagnosis, or treatment of the patient. In one implementation, the text communication is simply a notification to a dental provider that a patient is ready to be examined either in-person or remotely (e.g., via audio or video communications in a virtual waiting room or exam room). In some implementations, the text communication can be in the form of text messages, email messages, etc. The text communications can be automatically generated by the text communication engine 228. For example, the text communication engine 228 of the communication engine(s) 214a may communicate with the scheduling engine(s) 212a, and may be configured to automatically generate a text communication when a patient is scheduled to receive dental treatment or diagnosis from a dental practitioner. In some implementations, the text communication can be sent to one or more dental practitioners or patients. In another implementation, the text communication engine 228 may communicate with the patient information engine(s) 210a, and may be configured to automatically generate a text communication to a dental provider with patient information including dental history, diagnosis, or a dental treatment plan.

[0071] The audio communication engine 230 may implement one or more automated agents configured to receive, process, and/or generate audio communications between one or more communication devices. The audio communication engine can be implemented in an app loaded or installed on the patient’s smartphone, tablet, or personal computer. In some implementations, the audio communications are between dental providers or employees of a dental practice relating to the dental care, diagnosis, or treatment of one or more patients. In other implementations, the audio communications are between dental providers and a patient relating to the dental care, diagnosis, or treatment of the patient. In one implementation, the audio communication is simply an audible notification to a dental provider that a patient is ready to be examined either in-person or remotely (e.g., via audio or video communications). In some implementations, the audio communication can be in the form of audio messages, telephone calls, audible beeps, or alerts, etc. The audio communications can be automatically generated by the audio communication engine 230. For example, the audio communication engine 230 of the communication engine(s) 214a may communicate with the scheduling engine(s) 212a, and may be configured to automatically generate an audio communication when a patient is scheduled to receive dental treatment or diagnosis from a dental practitioner. In some implementations, the audio communication can be sent to one or more dental practitioners or patients. In another implementation, the audio communication engine 230 may communicate with the patient information engine(s) 210a, and may be configured to automatically generate an audio communication to a dental provider with patient information including dental history, diagnosis, or a dental treatment plan.

[0072] The video communication engine 232 may implement one or more automated agents configured to receive, process, and/or generate video communications between one or more communication devices. The video communication engine can be implemented in an app loaded or installed on the patient’s smartphone, tablet, or personal computer. In some implementations, the video communications are between dental providers or employees of a dental practice relating to the dental care, diagnosis, or treatment of one or more patients. In other implementations, the video communications are between dental providers and a patient relating to the dental care, diagnosis, or treatment of the patient. In one implementation, the video communication is simply a notification to a dental provider that a patient is ready to be examined either in-person or remotely (e.g., via audio or video communications). In another implementation, the video communication engine is implemented as a virtual waiting room. The provider(s) of a dental practice can interact with a software implementation of the video communication engine to see a list of scheduled patient appointments along with an indication if individual patients have “checked-in” virtually for their virtual consultation. In this embodiment, the provider(s) will be able to see the patients that are checked-in and waiting for examination. Furthermore, the provider(s) can select or interact with the checked-in patients (e.g., such as by selecting, touching, or clicking a software interface associated with the patient) to load into a video or virtual call or meeting with the patient that is private and separate from the virtual waiting room (e.g., a virtual examination room). In some implementations, the video communication can be in the form of video messages, videos of the patient’s dental anatomy or of dental scans, etc. The video communications can be automatically generated by the video communication engine 232. For example, the video communication engine 232 of the communication engine(s) 214a may communicate with the scheduling engine(s) 212a, and may be configured to automatically generate a video communication when a patient is scheduled to receive dental treatment or diagnosis from a dental practitioner. In some implementations, the video communication can be sent to one or more dental practitioners or patients. In another implementation, the video communication engine 232 may communicate with the patient information engine(s) 210a, and may be configured to automatically generate a video communication to a dental provider with patient information including dental history, diagnosis, or a dental treatment plan.

[0073] As described above, in some implementations, the video communication engine 232 can implement a virtual waiting room which queues patients waiting to have a virtual consultation with an expert dentist or other dental provider. The virtual waiting room can be, for example, a first-come first-served virtual waiting room in which patients are queued according to the time at which they enter the waiting room. Alternatively, the virtual waiting room can be queued according to previously scheduled dental appointments, and the provider(s) can view which patients have checked-in or are available for consultation. Information can be communicated to each patient regarding an approximate wait time and/or queue number while they are waiting for the virtual consultation. In one embodiment, the expert dentist can pull individual patients from the queue for the virtual consultation. Patients can be pulled automatically according to their queue number, or in other implementations the expert dentist can choose to speak to a chosen individual patient. When the provider(s) pull a patient, the patient and the provider(s) or expert dentist are moved to a private virtual communication, such as a private video call, phone call, or the like.

[0074] In some embodiments, the communication engine(s) are remote software program(s) residing on a remote computing system. In these embodiments, the communication engine(s) may include an API engine 233 configured to provide a software interface between the scheduling engine(s) and other software programs or computing devices. The API engine 233 may include an API specification that defines calls to the API engine (i.e., the API specification explains or defines how to use or implement API calls to the patient information engine(s). Calls to the API engine 233 may request some or all data from the text communication engine, audio communication engine, video communication engine, and/or the communication datastore. [0075] The communication datastore 234 may be configured to store communication information related to communications between dental providers or between a patient and a dental provider. The communication information can be generated, accessed, or processed by the text communication engine 228, the audio communication engine 230, the video communication engine 232, or the API engine 233. In some implementations, the communication information can be stored on the cloud, such as in the computer readable medium 202.

[0076] FIG. 2E is a diagram showing an example of a payment engine(s) 216a. The payment engine(s) 216a may include an invoice generation engine 236, a payment processing engine 238, an API engine 239, and a payment information datastore 240. One or more of the modules of the payment engine(s) 216a may be coupled to each other or to modules not shown. The payment engine(s) 216a of the dental treatment system 208 may implement automated agents to configured to generate invoices based on services provided, communicate invoices to patients, apply credits or insurance to invoices, and generally handle and organize billing processes between a dental or medical provider and one or more patients. The payment engine(s) 216a may be further configured to accept or apply payments from patients to outstanding invoices, apply insurance payments to invoices, and/or apply credits to invoices. Payment and/or invoice information can be stored on and/or received from a proprietary dental or patient management system. The payment and/or invoice information described herein can be automatically entered or transferred into the payment engine(s) 216a, or alternatively, can be manually input or entered by a dental practitioner.

[0077] The invoice generation engine 236 may implement one or more automated agents configured to receive, process, and/or generate invoices based on services provided, such as services provided to a patient. For example, a dental practice may provide a dental consultation, a dental cleaning, a dental surgery (such as a filling, an extraction, a root canal, etc.) and the invoice generation engine can be configured to generate an invoice for services provided. Additionally, the invoice generation engine 236 may be configured to communicate invoices to patients, such as by email, SMS, through a patient web portal, or by other means known in the art.

[0078] The payment processing engine 238 may implement one or more automated agents configured to receive, process, and/or apply payments to an outstanding invoice. In some embodiments, payments can be applied via credit card payment, check payment, cash payment, or wire payments to outstanding invoices. The payments can be applied over the web, over the telephone, or in person. In some embodiments, the payment processing engine can be configured to apply payments from multiple sources to an invoice, such as from multiple payment types. Additionally, the payment processing engine may be configured to apply insurance payments or credits to outstanding invoices to pay some or all of the outstanding balance on an invoice. The payment processing engine 238 may additionally be configured to confirm receipt of payment and communicate receipts of payment to the patient and/or dental or medical practice. [0079] In some embodiments, the payment engine(s) are remote software program(s) residing on a remote computing system. In these embodiments, the payment engine(s) may include an API engine 239 configured to provide a software interface between the payment engine(s) and other software programs or computing devices. The API engine 239 may include an API specification that defines calls to the API engine (i.e., the API specification explains or defines how to use or implement API calls to the patient information engine(s). Calls to the API engine 233 may request some or all data from the invoice generation engine, payment processing engine, and/or the payment information datastore.

[0080] The payment information datastore 240 may be configured to store communication information related to payments and invoices between dental providers or between a patient and a dental provider. The payment and invoice information can be generated, accessed, or processed by the invoice engine 236, the payment processing engine 238, or the API engine 239. In some implementations, the payment information can be stored on the cloud, such as in the computer readable medium 202.

[0081] FIG. 2F is a diagram showing an example of a middleware engine(s) 218a. The middleware engine(s) 218a may include a callback engine 242, lookup table engine 244, a custom API engine 245, and a middleware datastore 246. One or more of the modules of the middleware engine(s) 218a may be coupled to each other or to modules not shown. The middleware engine(s) 218a of the dental treatment system 208 may implement automated agents configured to call on 3rd party APIs when services or information from 3rd party or remote computing systems or computer programs are required or requested. The middleware engine(s) 218a may further implement automated agents configured to generate, update, and maintain a lookup table that associates and correlates all of the API references numbers from all of the 3rd party software solutions for a particular patient. Additionally, the middleware engine(s) 218a may further implement automated agents configured to generate custom API calls to various 3rd party APIs.

[0082] The callback engine 242 may implement one or more automated agents configured to call on 3rd party APIs when services or information from 3rd party or remote computing systems or computer programs are required or requested. The 3rd party or remote computing services can provide software solutions for location services, payment processing services, data analytics and data engineering services, communication services, scheduling services, etc. For example, the middleware engine(s) 218a may implement automated agents to make API calls to 3rd party software solutions by companies including but not limited to Google, Twilio, Agora, Ascend, Square, etc. The API calls can be implemented with custom callback scripts and/or time interval scripts to customize the ways and timing for calling data from the various APIs. In some implementations, the callback engine can implement machine learning or artificial intelligence software to determine when or how to make API calls to the 3rd party or remote computing systems.

[0083] The lookup table engine 244 may implement one or more automated agents configured to associate an API reference number for one or more patients from a first 3rd party software program with API reference numbers for one or more patients from second, third, fourth, etc. 3rd party software programs. The lookup table can contain all the API reference numbers for each patient, and can further organize patient data, payment data, scheduling data, etc. for each patient. For example, the lookup table engine 244 may be configured to organize and associate payment information from a first 3rd party software service or program (e.g., Square) with communications information from a second 3rd party software service or program (e.g., Twilio). Since the various 3rd party software programs all use their own reference numbers for each patient or customer, there is otherwise no way to associate information for a patient with a first service with information for that same patient with a second service. The lookup table engine 244 provides a solution for organizing and associating various patient data/information and API reference numbers for a large number of patients across a large number of 3rd party software programs.

[0084] The custom API engine 245 may implement one or more automated agents configured to generate custom APIs to wrap all the API endpoints of various 3rd party software programs. The custom API engine can then provide a custom API specification that defines calls to the custom API engine 245. A separate suite of software applications, which can be included in the dental treatment system, can then make API calls to the custom API engine, which in turn can provide data or requested information to the separate suite of software applications. As described above, the dental treatment system can provide a suite of applications providing for virtual medical treatment, examination, scheduling, and payment. This application suite can include an app on patient and/or medical providers smartphones, tablets, etc. Additionally, the suite can include web forms or online access to the dental treatment system, such as via a web browser on a personal computing device. Additionally, the dental treatment system can interface with a customer relationship management (CRM) program configured to manage all the relationships and interactions between patients, potential patients, and the dental practice and practitioners.

[0085] The middleware datastore 246 may be configured to store information related to the middleware engine and a suite of applications (e.g., mobile apps, webapps, CRM). In some implementations, the middleware datastore is configured to store information relating to patients and the various 3rd party software services in a lookup table that associates API reference numbers for each patient across all the 3rd party software services. The stored information, including the lookup table information, can be generated, accessed, or processed by the callback engine 242, the lookup table engine 244, or the custom API engine 245. In some implementations, the information can be stored on the cloud, such as in the computer readable medium 202.

[0086] Systems and methods are provided herein that enable a dental practitioner, such as an expert dentist, to see, speak to, communicate with, diagnose, and treat more patients than would be possible under a traditional dental care model. Additionally, systems and methods are provided herein that enable the dental practitioner, such as the expert dentist, to spend more time with each patient, facilitating better diagnosis, treatment planning, and care than is possible under a traditional dental care model.

[0087] Coordination of the communications between the patient(s) and the expert dentist can be managed by the computing environment 200 A, such as by the scheduling engine(s) 212 of the dental treatment system 208. For example, the scheduling engine(s) 212 can generate a daily, weekly, or monthly schedule that provides appointments/time slots for communications between a dental practitioner, such as an expert dentist, and all the patients receiving treatment that day. The schedule can take into account the dental practitioner’s availability, the scheduled physical appointments of the patients, the type of in-person treatment the patients are scheduled to receive (e.g., cleaning, cavity filling, surgery, etc.), and the availability of physical dental offices and/or diagnostic/treatment equipment. As described above, in some implementations the expert dentist can receive an alert or notification from the computing environment 200A when a patient is ready to meet virtually with the expert dentist. The communication can be coordinated through a virtual waiting room in which patients who are ready to meet virtually with a provider can checkin to the waiting room or be entered into a queue, and the provider can select individual patients from the waiting room to perform a virtual examination (e.g., via video call through an app loaded on the patient’s phone).

[0088] As described above, the dental treatment system provided herein can include communication and interaction between numerous devices, software platforms, and databases. For example, the system can support both patients and providers accessing the system for communications, virtual visits, and scheduling via their own mobile devices, tablets, and/or personal computers (via a web interface). Furthermore, the dental practice’s own customer relationship management (CRM) software must be integrated with the dental treatment system. Additionally, the dental treatment system must be further configured to communicate with and retrieve information from a number of different software programs/databases, with each software program typically having its own application programming interface (API). For example, the dental treatment system may be required and/or configured to access other software platforms that provide communications services (e.g., messaging, SMS, video calling), payment processing services, data analytics and data engineering services, scheduling services, etc. Some examples of software companies that provide such services which are accessed through APIs include, but are not limited to, Google, Twilio, Agora, Ascend, Square, etc.

[0089] FIG. 3 illustrates a schematic diagram of a traditional way of accessing 3rd party software services from a suite of software applications that may include a mobile app, an online or web form, and a CRM. In this example, each software application in the suite must individually make API calls to each of the 3rd party software programs anytime information is processed or accessed, resulting in costly and time consuming server processing times. Additionally, it is extremely complex to associate data from one API with data from another API, such as associating payment information or credit card data from Square for one patient with patient information for that patient in Ascend. In many instances, there is no way to monitor for changes in one API without messy interval callbacks, which is also costly from a server side. And these API calls typically request all data from a specific API, resulting in all data for all patients being called and returned.

[0090] In contrast, referring to FIG. 4, a schematic diagram is shown that correlates with the dental treatment system above, particularly the middleware engine which manages and handles communications between a middleware software system and various 3rd party API’s and also between the middleware software system and an application suite of programs that can include, for example, a mobile app, an online form, and a CRM. As described above, the middleware software system can make API calls to various 3rd party API’s when data is required, such as payment data, scheduling data, or any of the other data types described above. When these API calls are made and data is transmitted from the 3rd party API’s to the middleware software system, the middleware software system can be configured to generate, update, and/or maintain a lookup table that associates API reference numbers for one or more patients with the data from that API for those patients. Any time API calls are made, the lookup table can be updated with changes to the data. Additionally, the middleware software system can provide custom Dental Practice API’s that can be called by the application suite. Thus, when any program in the application suite, such as the mobile app, requests patient data, a custom API will be called to the middleware software system, and the middleware software system can response or transmit the requested data from the lookup table.

[0091] As a result of incorporating the systems and methods described herein, a welcome or new patient center can register up to 300-400 new patients per month (or more). The methods and apparatuses described herein allow an expert dentist to treat up to 8,000 active patients resulting in a broader range of patients that enjoy better clinical outcomes in the long term. Patients’ measurement of improved oral health can be measured through the average amount accepted per exam. The more the patient accepts per exam, the healthier their mouth is becoming. The less they accept, their existing problems continue to get worse. A typical average acceptance per examination for a dental practice is approximately $185 (e.g., if disease was detected and treatment for it was recommended, the patient average acceptance was $185 of treatment). However, implementing the methods and systems described herein can increase the average acceptance from approximately $185 to $300 which is a 62% increase per examination. The 62% increase in acceptance means patients’ oral health can be improved 62% more with the methods described herein vs a traditional method.

[0092] Various alternatives, modifications, and equivalents may be used in lieu of the above components. Although the final position of the teeth may be determined using computer-aided techniques, a user may move the teeth into their final positions by independently manipulating one or more teeth while satisfying the constraints of the prescription.

[0093] Additionally, the techniques described here may be implemented in hardware or software, or a combination of the two. The techniques may be implemented in computer programs executing on programmable computers that each includes a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), and suitable input and output devices. Program code is applied to data entered using an input device to perform the functions described and to generate output information. The output information is applied to one or more output devices.

[0094] Each program can be implemented in a high-level procedural or object-oriented programming language to operate in conjunction with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.

[0095] Each such computer program can be stored on a storage medium or device (e.g., CD- ROM, hard disk, or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described. The system also may be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.

[0096] Thus, any of the methods (including user interfaces) described herein may be implemented as software, hardware or firmware, and may be described as a non-transitory computer-readable storage medium storing a set of instructions capable of being executed by a processor (e.g., computer, tablet, smartphone, etc.), that when executed by the processor causes the processor to control perform any of the steps, including but not limited to: displaying, communicating with the user, analyzing, modifying parameters (including timing, frequency, intensity, etc.), determining, alerting, or the like.

[0097] While preferred embodiments of the present disclosure have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. Numerous different combinations of embodiments described herein are possible, and such combinations are considered part of the present disclosure. In addition, all features discussed in connection with any one embodiment herein can be readily adapted for use in other embodiments herein. It is intended that the following claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby.

[0098] When a feature or element is herein referred to as being “on” another feature or element, it can be directly on the other feature or element or intervening features and/or elements may also be present. In contrast, when a feature or element is referred to as being “directly on” another feature or element, there are no intervening features or elements present. It will also be understood that, when a feature or element is referred to as being “connected”, “attached” or “coupled” to another feature or element, it can be directly connected, attached, or coupled to the other feature or element or intervening features or elements may be present. In contrast, when a feature or element is referred to as being “directly connected”, “directly attached” or “directly coupled” to another feature or element, there are no intervening features or elements present. Although described or shown with respect to one embodiment, the features and elements so described or shown can apply to other embodiments. It will also be appreciated by those of skill in the art that references to a structure or feature that is disposed “adjacent” another feature may have portions that overlap or underlie the adjacent feature.

[0099] Terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. For example, as used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items and may be abbreviated as “/”.

[0100] Spatially relative terms, such as “under”, “below”, “lower”, “over”, “upper” and the like, may be used herein for ease of description to describe one element or feature’s relationship to another element(s) or feature(s) as illustrated in the figures. It will be understood that the spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. For example, if a device in the figures is inverted, elements described as “under”, or “beneath” other elements or features would then be oriented “over” the other elements or features. Thus, the exemplary term “under” can encompass both an orientation of over and under. The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein interpreted accordingly. Similarly, the terms “upwardly”, “downwardly”, “vertical”, “horizontal” and the like are used herein for the purpose of explanation only unless specifically indicated otherwise.

[0101] Although the terms “first” and “second” may be used herein to describe various features/elements (including steps), these features/elements should not be limited by these terms, unless the context indicates otherwise. These terms may be used to distinguish one feature/element from another feature/element. Thus, a first feature/element discussed below could be termed a second feature/element, and similarly, a second feature/element discussed below could be termed a first feature/element without departing from the teachings of the present invention.

[0102] Throughout this specification and the claims which follow, unless the context requires otherwise, the word “comprise”, and variations such as “comprises” and “comprising” means various components can be co-jointly employed in the methods and articles (e.g., compositions and apparatuses including device and methods). For example, the term “comprising” will be understood to imply the inclusion of any stated elements or steps but not the exclusion of any other elements or steps.

[0103] In general, any of the apparatuses and/or methods described herein should be understood to be inclusive, but all or a sub-set of the components and/or steps may alternatively be exclusive, and may be expressed as “consisting of’ or alternatively “consisting essentially of’ the various components, steps, sub-components, or sub-steps.

[0104] As used herein in the specification and claims, including as used in the examples and unless otherwise expressly specified, all numbers may be read as if prefaced by the word “about” or “approximately,” even if the term does not expressly appear. The phrase “about” or “approximately” may be used when describing magnitude and/or position to indicate that the value and/or position described is within a reasonable expected range of values and/or positions. For example, a numeric value may have a value that is +/- 0.1% of the stated value (or range of values), +/- 1% of the stated value (or range of values), +/- 2% of the stated value (or range of values), +/- 5% of the stated value (or range of values), +/- 10% of the stated value (or range of values), etc. Any numerical values given herein should also be understood to include about or approximately that value unless the context indicates otherwise. For example, if the value “10” is disclosed, then “about 10” is also disclosed. Any numerical range recited herein is intended to include all sub-ranges subsumed therein. It is also understood that when a value is disclosed that “less than or equal to” the value, “greater than or equal to the value” and possible ranges between values are also disclosed, as appropriately understood by the skilled artisan. For example, if the value “X” is disclosed the “less than or equal to X” as well as “greater than or equal to X” (e.g., where X is a numerical value) is also disclosed. It is also understood that throughout the application, data is provided in a number of different formats, and that this data represents endpoints and starting points, and ranges for any combination of the data points. For example, if a particular data point “10” and a particular data point “15” are disclosed, it is understood that greater than, greater than or equal to, less than, less than or equal to, and equal to 10 and 15 are considered disclosed as well as between 10 and 15. It is also understood that each unit between two particular units are also disclosed. For example, if 10 and 15 are disclosed, then 11, 12, 13, and 14 are also disclosed.

[0105] Although various illustrative embodiments are described above, any of a number of changes may be made to various embodiments without departing from the scope of the invention as described by the claims. For example, the order in which various described method steps are performed may often be changed in alternative embodiments, and in other alternative embodiments one or more method steps may be skipped altogether. Optional features of various device and system embodiments may be included in some embodiments and not in others. Therefore, the foregoing description is provided primarily for exemplary purposes and should not be interpreted to limit the scope of the invention as it is set forth in the claims.

[0106] The examples and illustrations included herein show, by way of illustration and not of limitation, specific embodiments in which the individual matter may be practiced. As mentioned, other embodiments may be utilized and derived there from, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. Such embodiments of the inventive patient matter may be referred to herein individually or collectively by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept, if more than one is, in fact, disclosed. Thus, although specific embodiments have been illustrated and described herein, any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

Claims

CLAIMS What is claimed is:

1. A method for providing dental treatment to a patient with a computer implemented dental treatment system, comprising the steps of: making API calls to two or more 3^rd party software programs with a middleware software system to obtain patient information relating to a patient; generating or updating data in a lookup table with the middleware software system that associates first API data from a first 3^rd party software program corresponding to the patient with second API data from a second 3^rd party software program corresponding to the patient; and providing a custom API specification from the middleware software system to an application suite that defines how to use or implement API calls from the application suite to the middleware software system to access data in the lookup table.

2. The method of claim 1, wherein the 3^rd party software programs provide payment services, scheduling services, communications services, locations services, and or medical history data storage services.

3. The method of claim 1, wherein the patient information is selected from the group consisting of personal information, concerns with dental health, medical history, dental history, insurance coverage, custom needs, obstacles to receiving dental care, X-ray imaging, radiograph imaging, intraoral imaging, infrared imaging, caries detection results, oral cancer screening information, lesion screening information, and plaque detection information, cold test information, bite stick test information, probing information, palpitation information, decay probing information, or EPT test information, payment information, invoice information, and communication information.

4. The method of claim 1, wherein the first API data comprises payment information for the patient.

5. The method of claim 1, wherein the first API data comprises scheduling information for the patient.

6. The method of claim 1, wherein the first API data comprises patient history information for the patient.

7. The method of claim 1, wherein the application suite comprises a mobile application.

8. The method of claim 1, wherein the application suite comprises an online form.

9. The method of claim 1, wherein the application suite comprises a customer relationship management (CRM) program.

10. The method of claim 1, further comprising outputting data from the lookup table.

11. The method of claim 10, wherein outputting comprises displaying the data from the lookup table on a monitor.

12. A system comprising: one or more processors; memory coupled to the one or more processors, the memory configured to store computer-program instructions, that, when executed by the one or more processors, implement a computer-implemented method, the computer-implemented method comprising: making API calls to two or more 3^rd party software programs with a middleware software system to obtain patient information relating to a patient; generating or updating a lookup table with the middleware software system that associates first API data from a first 3^rd party software program corresponding to the patient with second API data from a second 3^rd party software program corresponding to the patient; and providing a custom API specification from the middleware software system to an application suite that defines how to use or implement API calls from the application suite to the middleware software system to access data in the lookup table.

13. The system of claim 12, wherein the 3^rd party software programs provide payment services, scheduling services, communications services, locations services, and or medical history data storage services.

14. The system of claim 12, wherein the patient information is selected from the group consisting of personal information, concerns with dental health, medical history, dental history, insurance coverage, custom needs, obstacles to receiving dental care, X-ray imaging, radiograph imaging, intraoral imaging, infrared imaging, caries detection results, oral cancer screening information, lesion screening information, and plaque detection information, cold test information, bite stick test information, probing information, palpitation information, decay probing information, or EPT test information, payment information, invoice information, and communication information.

15. The system of claim 12, wherein the first API data comprises payment information for the patient.

16. The system of claim 12, wherein the first API data comprises scheduling information for the patient.

17. The system of claim 12, wherein the first API data comprises patient history information for the patient.

18. The system of claim 1, wherein the application suite comprises a mobile application.

19. The system of claim 12, wherein the application suite comprises an online form.

20. The system of claim 12, wherein the application suite comprises a customer relationship management (CRM) program.

21. The system of claim 12, further comprising outputting data from the lookup table.

22. The system of claim 21, wherein outputting comprises displaying the data from the lookup table on a monitor.