Patent ID: 12251242

DETAILED DESCRIPTION

It should be appreciated that all combinations of the concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are contemplated as being part of the inventive subject matter disclosed herein. It also should be appreciated that terminology explicitly employed herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.

Following below are more detailed descriptions of various concepts related to, and embodiments of, inventive methods, apparatus and systems configured to provide for automated initiation, titration and management of a medication regimen in a patient with type 2 diabetes via a series of voice-based and/or chat-based interactions between the patient and an artificial intelligence (AI) conversational agent.

It should be appreciated that various concepts introduced above and discussed in greater detail below may be implemented in any of numerous ways, as the disclosed concepts are not limited to any particular manner of implementation. Examples of specific implementations and applications are provided primarily for illustrative purposes. The present disclosure should in no way be limited to the exemplary implementation and techniques illustrated in the drawings and described below.

Before the present invention and specific exemplary embodiments of the invention are described, it is to be understood that this invention is not limited to the particular embodiments described, and as such may vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present invention will be limited only by the appended claims.

Where a range of values is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit unless the context clearly dictates otherwise, between the upper and lower limit of that range and any other stated or intervening value in that stated range is encompassed by the invention. The upper and lower limits of these smaller ranges may independently be included in the smaller ranges, and are also encompassed by the invention, subject to any specifically excluded limit in a stated range. Where a stated range includes one or both of the endpoint limits, ranges excluding either or both of those included endpoints are also included in the scope of the invention.

As used herein, the term “behaviorome” means the set of all behaviors of an individual or a group of individuals that may be observed and analyzed to create a plurality of digital behavior markers for the individual or group of individuals.

As used herein, the terms “computer,” “processor” and “computer processor” encompass a personal computer, a workstation computer, a tablet computer, a smart phone, a microcontroller, a microprocessor, a field programmable object array (FPOA), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic array (PLA), or any other digital processing engine, device or equivalent capable of executing software code including related memory devices, transmission devices, pointing devices, input/output devices, displays and equivalents.

As used herein, the terms “conversational agent” or “conversational AI agent” or “agent” refer to any device, system and/or program configured to autonomously execute one or more objective function in response to one or more inputs. Said terms may be used interchangeably. The one or more inputs may comprise one or more user-generated inputs, sensor-based inputs, internal system inputs, external system inputs, environmental percepts, and the like. Examples of conversational agents may include, but are not limited to, one or more virtual assistant, personal assistant or chatbot.

As used herein, the terms “drug regimen” or “medication regimen” mean a prescribed systematic form of treatment for a course of drug(s).

As used herein, the term “dosing regimen” means a frequency of administration, the dose per a single administration, the time interval between administrations, duration of treatments, and how a drug is to be taken. In accordance with certain aspects of the present disclosure, the term “dosing regimen” may comprise one or more aspects of a drug regimen. In certain contexts, the terms “dosing regimen” and “drug regimen” may be used interchangeably.

As used herein, the term “exemplary” means serving as an example or illustration and does not necessarily denote ideal or best.

As used herein, the term “includes” means includes but is not limited to, the term “including” means including but not limited to. The term “based on” means based at least in part on.

As used herein, the term “interface” refers to any shared boundary across which two or more separate components of a computer system may exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations thereof.

As used herein, the term “mobile device” includes any portable electronic device capable of executing one or more digital functions or operations; including, but not limited to, smart phones, tablet computers, personal digital assistants, wearable activity trackers, smart watches, smart speakers, and the like.

As used herein, the terms “provider” and “practitioner” refer to a healthcare professional or healthcare provider that is responsible for one or more aspects of a patient's care; including, but not limited to, a doctor, a nurse, a physician's assistant, a pharmacist, a technician, and the like. The terms “provider” and “practitioner” may be used interchangeably throughout the present disclosure. As used herein, the term “practitioner user” refers to a provider/practitioner who is also a user of the voice-based system for management of type 2 diabetes, as described herein.

As used herein, the term “patient” refers to any recipient of health care services that are performed or facilitated by a practitioner; including, but not limited to, an individual with type 2 diabetes. As used herein, the term “patient user” refers to a patient who is also a user of the voice-based system for management of type 2 diabetes, as described herein.

As used herein, a “portal” makes network resources (applications, databases, etc.) available to end users. The user can access the portal via a web browser, smart phone, tablet computer, and other client computing devices. Portals may include network enabling services such as e-mail, chat rooms and calendars that interact seamlessly with other applications.

As used herein, “remote patient intervention” refers to a model of care that incorporates the use of remote patient monitoring data to provide real-time disease and medication management for patients based on physician-approved protocols. Autonomous diabetes medication dosing instructions of the present disclosure is an example of remote patient intervention.

As used herein, the term “smart speaker” refers to an internet-enabled speaker that is controlled by spoken commands and is capable of streaming audio content, relaying information, and communicating with other devices. In accordance with certain aspects of the present disclosure, a smart speaker may be configured to execute a client-side instance of a conversational AI agent.

As used herein, the term “transmit” and its conjugates means transmission of digital and/or analog signal information by electronic transmission, Wi-Fi, BLUETOOTH technology, wireless, wired, or other known transmission technologies including transmission to an Internet web site.

As used herein, a “GLP-1 agonist drug” comprises a class of prescription medications that helps lower blood sugar levels for people with type 2 diabetes, including semaglutide, tirzepatide, liraglutide, retatrutide, dulaglutide, exenatide, and lixisenatide.

As used herein, a “biguanide drug” comprises a class of prescription medications that helps lower blood sugar levels for people with type 2 diabetes, including metformin IR (immediate release) and metformin ER (extended release).

As used herein, a “SGLT-2 inhibitor drug” comprises a class of prescription medications that helps lower blood sugar levels for people with type 2 diabetes, including empagiflozen, canagiflozen, dapagiflozen, bexagliflozin, and sotagliflozin.

Certain aspects of the present disclosure provide for a remote patient intervention system comprising a portable integrated electronic device and computer-readable media configured to operably engage with at least one remote virtual server, preferably a secured HIPAA-compliant server, to provide one or more cloud-based control services; including, but not limited to, automated speech recognition (ASR), natural language processing (NLP), natural language understanding (NLU), dialogue management, and text-to-speech (TTS) conversion, among others. In various embodiments, the cloud-based control services together may comprise a conversational artificial intelligence (AI) agent configured to perform natural language or speech-based automated dynamic multi-turn conversations with a user of the portable integrated electronic device. The portable integrated electronic device enables the user to access, interact, and engage with said conversational AI agent to remotely receive at least one medication prescription, therapeutic dose titration, and dose regimen, among others. In various embodiments, said portable integrated electronic device may provide recording and/or monitoring of the user's medication adherence, medication adverse reactions, and one or more behavioral phenotype for the user (e.g., including social demographics, health literacy, technical literacy, illness perception, and clinical complexity, among others). In various embodiments, said portable integrated electronic device may provide recording and/or monitoring of custom user interactions, including but not limited to device check-in frequency, user speech complexity, clinical flexibility, user personality, and user persistence, among others. In various embodiments, said portable integrated electronic device listens (e.g., via at least one microphone) and interacts with the user (e.g., via at least one speaker) to determine at least one intent based on NLU of the user's speech. Said portable integrated electronic device may be configured to record and/or monitor one or more user voice utterances and transmit voice data to at least one cloud-based control service virtual server via a telecommunication network. The cloud-based control service may perform ASR, NLP and/or NLU on the utterances to determine intents expressed by the utterances via one or more scripted computing skills. In response to an identified intent, the control service may perform one or more corresponding actions. In various embodiments, an action may be performed at the control service and/or by commanding said portable integrated electronic device to perform a function. The combination of the portable integrated electronic device and one or more applications executed by the control service may comprise a conversational AI agent. The conversational AI agent may provide conversational interactions, utilizing ASR, NLP, NLU, or TTS conversion, and the like, to perform said functions, interact with the user (i.e., patient), query questions to the user, and provide said user with non-clinical self-management instructions, questionnaire, education, health-related information, nutrition, carb counts, instructional video, tasks, alerts, and the like. The portable integrated electronic device may be optimally configured for low device operation latency and for parsimonious memory usage, promptly responsive for enhancing user experience.

Certain aspects of the present disclosure provide for a portable integrated electronic voice-based device comprising or more microprocessor, microcontroller, read-only memory device, memory storage device, flash memory, I-O device, buttons, volume control button, display, user interface, rechargeable battery, microUSB, USB-C, CODEC, microphone, speaker, speaker amplifier, wireless transceiver IC, including but not limited to Bluetooth, Wi-Fi or cellular, micro GSM/GPRS chipset, micro SIM module, antenna, haptic sensor, power management IC, vibrating motor (output), preferably configured in combination, to function fully as an Internet-of-Things (IoT) device. The portable integrated electronic device is communicably engaged (e.g., via a communications network) with one or more remote cloud-based or virtual servers capable of providing ASR-response, NLP/NLU-processing, predictive algorithm processing, reminders, alerts, general and specific information for the remote management of patients with an acute, chronic, condition, or disease, including but not limited to diabetes, cancer, hypertension, kidney disease, infectious disease and heart failure, among others. In various embodiments, the portable integrated electronic device may be communicably engaged with one or more external devices, including but not limited to, a point-of-care testing (POCT) device, a glucose meter, a wearable continuous glucose meter, an HbA1C meter, a lactate meter, an IoT sensor, a remote or mobile patient monitor for EKG, ECG, variable heart rate, blood pressure, a capillary blood collection device, or the like, a mobile phone, and a smart appliance, among others.

Certain aspects of the present disclosure provide for a behaviorome platform comprising a patient engagement engine comprising the portable integrated electronic device. In various embodiments, the patient engagement engine enables the execution of at least one proprietary derived clinical protocol for instructing a patient user via at least one conversational AI agent. In various embodiments, said device, operating alone or engaged in combination with said cloud-based control service server, uses one or more proprietary derived voice dataset to deliver personalized interactions with a user of the device (e.g., a patient). In various embodiments, one or more said behavioral phenotype or custom interactions are collected, processed, and analyzed by the patient engagement engine to provide the user with autonomous medication management (including, for example, initiation and titration of one or more diabetes drug), personalized intervention, and/or to monitor medication adherence and persistence using one or more clinically validated survey or questionnaire (e.g., via a generative chat interface or voice-based multi-turn interaction). In various embodiments, one or more said behavioral phenotype or said custom interactions are collected, processed, and analyzed by the patient engagement engine to provide (in real-time, synchronously, or asynchronously) the user with non-clinical self-management instructions or education for therapeutic titration, medication dose adjustment, medication dosing regimen, perform a blood measurement with a home-use meter, glucose meter (i.e., glucometer), or POCT device, recommend nutrition or physical exercise, care plan, and a personalized intervention, among others. In various embodiments, said device may provide said information to a user on a mobile phone application.

Certain aspects of the present disclosure provide for a physician portal for the remote patient intervention system comprising said portable integrated electronic device, a secured HIPAA-compliant remote application World Wide Web (“Web”) server, an EMR database, cloud-based control service server, client computing devices, dashboard, and non-transitory computer-readable media. The remote application Web server may be accessible through one or more client computing devices, including but not limited to, desktop, laptop, tablet, mobile phone, smart phone, and smart appliances, among others. The remote Web server may contain IT support applications software that may include a database for storing patient and/or user(s) information. The applications software may provide an interactive physician portal or WWW portal between healthcare providers, nurses, clinical staff, insurer, and patients for communication and sending prescription information, among other functions. In various embodiments, the remote Web server may communicate or engage operably with an electronic health record (EHR) or an electronic medical record (EMR) system. The remote Web server may communicate with said EHR or EMR system using an application programming interface (API). In various embodiments, said dashboard may be configured to enable a healthcare provider to access the physician portal. In various embodiments, one or more client device may be communicably engaged with the application server, the client device being configured to display a graphical user interface (GUI) or a mobile application containing non-limiting information including patient engagement, patient behaviorome, remote patient intervention, non-clinical self-management, patient and healthcare provider interactions, user log, medication log, blood sugar log, therapeutic titration, medication dose adjustment or changes, medication dosing regimen, date, time, hourly or daily blood glucose values, HbA1C values, health record, analytical test results, user self-management performance trends, medication adherence, persistence, nutrition habits, physical habits, behaviors, care plan, protocol, patient weight, frequency, goal fasting blood sugar range, among others. In various embodiments, the GUI or mobile application may contain text, graphics, video, or charts, among others. In various embodiments, the dashboard and GUI may be accessible over the Internet. In various embodiments, the physician portal may be incorporated into a product comprising a hardware implementation or software instructions stored and executable from one or more non-transitory storage medium located locally on a client device or mobile computing platform (e.g., smart phone) or remotely on a cloud server or cloud service.

Certain aspects of the present disclosure provide for a remote patient intervention system comprising: a portable voice-based electronic device configured to execute an instance of a GUI comprising a plurality of user prompts associated with diabetes or a disease or disorder of a patient user; an integral or remote processor communicatively engaged with said electronic device; and a non-transitory computer readable medium having instructions stored thereon that, when executed, cause the processors to perform one or more operations, the one or more operations comprising operations for: receiving a plurality of user-generated voice or touch screen inputs in response to the plurality of user prompts; receiving one or more sensor inputs; receiving one or more external data inputs comprising at least one patient voice dataset; aggregating the plurality of user-generated inputs, the one or more sensor inputs, and the one or more external data inputs to define an aggregated dataset; analyzing the aggregated dataset according to at least one conversational AI framework comprising at least one rules-based or large language AI model, wherein the at least one conversational AI framework comprises at least one dependent variable corresponding to a current or future state of a patient behaviorome or a patient engagement engine; generating at least one conversational AI prompt according to the at least one conversational AI framework; and generating, with the processor, at least one activity recommendation in response to at least one diagnostic measure, the at least one activity recommendation corresponding to at least one patient action associated with the current or future state of glycemic control. In various embodiments, the system further comprises at least one said portable voice-based electronic device communicatively engaged with at least point of care testing (POCT) device, including but not limited to a portable or wearable continuous glucose monitoring system (CGM), among others.

Certain aspects of the present disclosure provide for computer-implemented methods for performing a remote patient intervention. In various embodiments, a conversational AI encounter with a user of a portable voice-based electronic device may be triggered by voice, proximity, or touch. The user may be instructed to complete the setup of said device and account linkage. The user may be asked to set up a wireless link (e.g., via BLUETOOTH) to a monitoring device, such as a continuous glucose monitor (CGM). The user may be instructed to conduct one or more non-limiting maintenance tasks such as making sure the CGM is worn correctly, making sure data is transmissible, and sensor replacement reminder or refill. The user may be asked to confirm understanding of any provider-driven changes such as a medication dose change, the addition of an alternate medication, any necessary medication change instructions, any necessary calibration of medication (e.g., with one or more meals), and any addition of non-glycemic medications (e.g., blood pressure medication, cholesterol medication, etc.) that may affect a clinical protocol. In various embodiments, the device may then collect data for any non-limiting driven changes such as diabetes medication adherence, blood sugar results, specific information on meals that may cause changes in CGM blood sugar levels, and side effects. The conversational AI agent then may ask the user to confirm the understanding of any changes, information about meals, side effects, exercise and other behaviorome tasks, among others.

Certain aspects of the present disclosure provide for computer-implemented methods for performing a remote patient intervention comprising one or more oral medication titration protocols. In various embodiments, oral medication titration protocols may comprise non-limiting oral medications used for the treatment of diabetes such as non-insulin glycemic medications, statins, angiotensin receptor blockers, among others. In various embodiments, glycemic control oral medication protocols may comprise one or more non-limiting principles such as starting prescriptions, identifying contraindicated medications, setting doses manually, selection of titration priorities, checking all device user's medication side effects, device usage risk assessment and lock-out if a device user is admitted to a hospital, titration duration, titration procedure to prevent side effect confounders, and initiation of glycemic medications based on HbA1C percentages, among others.

Certain aspects of the present disclosure provide for computer-implemented methods for performing a remote patient intervention comprising one or more diabetes medication titration protocols. In various embodiments, diabetes medication titration protocols may comprise glycemic goals, GLP-1 agonist drug protocol, biguanide drug protocol, SGLT-2 inhibitor drug protocol, medication interactions, clinical status change, titration considerations, medication intensification, medication de-intensification, patient hypoglycemia intervention, goal fasting blood glucose range, starting medication dose, maximum permitted medication dose, dose frequency, titration schedule, minimum titration requirements, hyperglycemia and hypoglycemia protocols, among others.

Certain aspects of the present disclosure provide for one or more non-transitory computer-readable medium encoded with instructions for commanding one or more processors of said portable device, client computing device, or cloud-based control service remote server to execute one or more steps of one or more methods or processes within a remote patient intervention system, behaviorome platform, or patient engagement engine comprising one or more operations for: receiving a plurality of data from one or more data sources, the plurality of data comprising one or more voice-based patient user generated input or response, conversational AI queries or responses, cloud-based computing server input or output, client computing device input or output; aggregating the plurality of data to define an aggregated voice dataset; analyzing the aggregated voice dataset according to at least one AI framework comprising at least one rules-based or large language model generative AI framework, wherein the at least one said AI framework comprises at least one dependent variable corresponding to a current or future state of serum electrolyte values, creatinine, blood urea nitrogen (BUN), medication adherence, side effects, blood glucose, blood lipids, or HbA1C of a patient; using at least one clinical protocol and generating at least one autonomous adjustment medication dose recommendation for a diabetic patient user, preferably type 2, to achieve better glycemic and diabetes disease management control and health self-management, in a non-clinical setting. An object of the present disclosure provides for a remote patient intervention system for patient self-management of a medication regimen for management of type 2 diabetes in a non-clinical setting.

Further objects and advantages of the present disclosure include computer-implemented methods for performing voice-based, conversational AI titration protocols for a diabetes medication dosing regimen. Diabetes medication titration protocols may comprise glycemic goals, GLP-1 agonist drug protocol, biguanide drug protocol, SGLT-2 inhibitor drug protocol, basal protocol, types of medication to administer, titration considerations, medication intensification, medication de-intensification, patient hypoglycemia intervention, prandial protocol, goal fasting blood glucose range, starting medication dose, maximum permitted medication dose, dose frequency, titration schedule, minimum titration requirements, adverse event protocols, patient safety protocols, hyperglycemia and hypoglycemia protocols, among others. In accordance with certain embodiments, a medication titration protocol may comprise one or more default and editable prescription parameters within a graphical user interface of a practitioner (e.g., primary care provider) application.

Further objects and advantages of the present disclosure include computer-implemented methods for performing a remote patient intervention comprising one or more oral medication titration protocols. In various embodiments, oral medication titration protocols may comprise one or more non-limiting oral medications used for the treatment of diabetes such as non-insulin glycemic medications, statins, angiotensin receptor blockers, glucagon-like peptide 1 agonists, sodium-glucose cotransporter 2 inhibitors, glucose-dependent insulinotropic polypeptide combination medications, biguanides, among others. In various embodiments, glycemic control oral medication protocols may comprise one or more non-limiting principles such as starting prescriptions, identifying contraindicated medications, setting doses manually, selection of titration priorities, checking medication side effects for all patient medications and medication combinations, device usage risk assessment and lock-out parameters (e.g., lock-out if a qualifying adverse event takes place, lock-out if a qualifying laboratory result takes place, lock-out in response to a practitioner input, etc.) titration duration, titration procedure to prevent side effect confounders, initiation of medication based on HbA1c percentages, among others. In accordance with certain aspects of the present disclosure, a “lock-out” comprises one or more operations under the one or more diabetes medication titration protocols may be temporarily or permanently discontinued.

Further objects and advantages of the present disclosure provide for one or more non-transitory computer-readable medium encoded with instructions for commanding one or more processors of a smart speaker device, a client computing device, and/or cloud-based control service remote server to execute one or more steps of one or more methods or processes within a remote patient intervention system, behaviorome platform, and/or patient engagement engine comprising one or more operations for: receiving a plurality of data from one or more data sources, the plurality of data comprising one or more voice-based patient user generated input or response, conversational AI queries or responses, cloud-based computing server input or output, client computing device input or output; aggregating the plurality of data to define an aggregated voice dataset; analyzing the aggregated voice dataset according to at least one AI framework comprising at least one rules-based or large language model generative AI framework, wherein the at least one said AI framework comprises at least one dependent variable corresponding to a current or future state of serum electrolyte values, creatinine, blood urea nitrogen (BUN), medication adherence, side effects, blood glucose, blood lipids, or hemoglobin A1C of a patient; and generating at least one autonomous adjustment medication dose recommendation according to at least one clinical protocol for a patient with type 2 diabetes to achieve better glycemic and diabetes disease control and health self-management, in a non-clinical setting (e.g., at home).

Turning now descriptively to the drawings, in which similar reference characters denote similar elements throughout the several views,FIG.1depicts an architecture diagram of a system100for remote management of type 2 diabetes in and through which certain aspects of the present invention may be implemented. In accordance with certain aspects of the present disclosure, system100is configured to enable a voice-based remote patient intervention system for initiation and titration of a medication regimen in a patient user22with type 2 diabetes. System100comprises a practitioner computing environment, a patient computing environment and an application computing environment configured to enable configuration of a clinical protocol for management of type 2 diabetes by a practitioner user24; configuration of a clinical algorithm for initiation and titration of a diabetes medication regimen; and configuration of a conversational AI model to enable a plurality of generative, voice-based interactions between a conversational agent122and patient user22. Practitioner user24may be a primary care provider for patient user22. In accordance with certain embodiments, a patient environment of system100may comprise a smart speaker102, an end user device104and, optionally, a continuous glucose monitor106. End user device104may comprise a smart phone, tablet computer, desktop computer, personal digital assistant, or other personal computing device. Continuous glucose monitor106may be a body-worn device comprising a sensor, a transmitter and a user interface configured to be worn by patient user22to monitor blood glucose on a continual basis. Continuous glucose monitor106may be communicably engaged with end user device104via a wireless data transfer interface (e.g., BLUETOOTH) to transmit blood glucose data for patient user22to a software application executing on end user device104. Examples of continuous glucose monitor106may include the FREESTYLE LIBRE, manufactured by ABBOTT LABORATORIES, and the DEXCOM G7, manufactured by DEXCOM INC.

In accordance with certain embodiments, a practitioner environment of system100may include a practitioner computing device108, a healthcare provider server114and a healthcare provider database116. Practitioner computing device108may be communicably engaged with healthcare provider server114via a local area or a wide area network interface. Healthcare provider database116may be communicably engaged with healthcare provider server114to store and retrieve a plurality of health records; e.g., health records associated with management of type 2 diabetes for patient user22. Practitioner computing device108, healthcare provider server114and healthcare provider database116may be operably engaged according to a HIPAA-compliant network architecture. In certain embodiments, system100may comprise one or more external electronic medical record (EMR)/electronic health record (EHR) server130and external EMR/EHR database132. External EMR/EHR server130and external EMR/EHR database132may comprise one or more third-party medical server, including one or more laboratory information management system (LIMS) server, third-party payor server, government server, and the like.

In accordance with certain aspects of the present disclosure, the elements of the patient environment, the practitioner environment, and, optionally, the external EMR/EHR server130and external EMR/EHR database132, may be communicably engaged with the application computing environment via communications network118. The application computing environment may comprise a cloud computing environment. Communications network118may comprise one or more network interfaces to enable one or more real-time data transfer interfaces between the elements of system100; including, for example, one or more application programming interface (API) or software development kit (SDK). In accordance with certain aspects of the present disclosure, the application computing environment comprises at least one application server110and an application database112. In accordance with certain embodiments, application database112may comprise a knowledge base comprising a plurality of subject-matter information from which the conversational AI model may draw to generate responses to one or more user queries. Application server110may comprise one or more computing modules and control services to enable one or more functions and operations of system100. In accordance with certain aspects of the present disclosure, application server110comprises a diabetes management application120, a large language model engine121, and a conversational agent122service. Large language model engine121may comprise a large language model configured to drive a plurality of generative text-to-speech outputs of conversational agent122. In accordance with certain aspects of the present disclosure, system100may comprise an external server133comprising a third-party large language model service. Large language model engine121may be communicably engaged with external server133via at least one data transfer interface to execute one or more functions or operations for configuring, implementing and/or executing the conversational AI model.

In accordance with certain aspects of the present disclosure, patient user22provides a voice input to smart speaker102to invoke one or more functions of conversational agent122. The voice input is converted by smart speaker102into a digital audio format and is streamed to application server110(as described in more detail herein) and is received at conversational agent122(e.g., in real-time). In various embodiments, one or more invocations from smart speaker102and generative voice outputs (e.g., diabetes medication initiation and titration instructions) may be communicated bi-directionally between smart speaker102and conversational agent122.

In accordance with certain aspects of the present disclosure, an exemplary use case of system100is initiated within the practitioner environment. In accordance with certain embodiments, practitioner user24may instantiate a practitioner instance120′ of diabetes management application120at a user interface of practitioner computing device108. Practitioner instance120′ may comprise a graphical user interface configured to enable practitioner user24to input a plurality of clinical parameters for management of type 2 diabetes for patient user22; e.g., in accordance with one or more clinical protocols (as described in more detail herein below). In certain embodiments, practitioner instance120′ may comprise a plurality of pre-populated data for patient user22comprising a plurality of health record data to assist practitioner user24in configuring the clinical parameters. Practitioner instance120′ may be configured to communicate the user-generated data (e.g., via a hypertext transfer protocol) to application server110via communications network118. Application server110may receive and process the user-generated data according to one or more data processing operations for diabetes management application120. In accordance with certain embodiments, diabetes management application120is configured to process the user-generated data to configure a clinical algorithm for initiation and titration of a medication regimen for the patient. Diabetes management application120may provide one or more outputs to conversational agent122comprising parameters for the clinical algorithm. Large language model engine121may execute one or more operations with internal or external large language models under the direction of conversational agent122. In accordance with certain aspects of the present disclosure, the conversational agent122may comprise an AI framework comprising a neural network architecture configured to enable one or more automated speech recognition (ASR), natural language processing (NLP), natural language understanding (NLU), dialogue management, text-to-speech (TTS) converter function.

In accordance with certain aspects of the present disclosure, application server110may receive one or more clinical data inputs for patient22via one or more of end user device104, continuous glucose monitor106, external EMR/EHR server130and/or healthcare provider server114. Clinical data inputs may include, but are not limited to, basic metabolic panel (e.g., sodium, potassium, chloride, bicarbonate, BUN, creatinine, glucose, magnesium, phosphate, calcium, uric acid, and the like), hemoglobin A1C, medication adherence based on patient-reported data (e.g., prescription (“Rx”) fill data, log data, and other data sources), blood pressure data and other physiological sensor data, patient-reported side effects, and the like. In certain embodiments, patient-reported data may be received via a graphical user interface of a patient instance120” of diabetes management application120. Diabetes management application120may receive and process the clinical data inputs according to the clinical algorithm and provide one or more outputs to large language model engine121in accordance with the same. Conversational agent122may generate a first generative voice prompt and output the generative voice prompt to patient user22via smart speaker102. In accordance with certain aspects of the present disclosure, the first generative voice prompt comprises a medication initiation prompt for patient user22to begin a diabetes medication regimen according to the clinical protocol.

In accordance with certain aspects of the present disclosure, patient user22may provide a voice input at smart speaker102in response to the medication initiation prompt (e.g., to confirm initiation of the diabetes medication regimen according to the clinical protocol). Diabetes management application120may process the voice input and, optionally, the clinical data (e.g., at one or more time points) according to the clinical algorithm and provide one or more outputs to conversational agent122with the same. In accordance with certain aspects of the present disclosure, conversational agent122may generate a second or subsequent generative voice prompt with the help of large language model engine121and output the second or subsequent generative voice prompt to patient user22via smart speaker102. In accordance with certain aspects of the present disclosure, the second or subsequent generative voice prompt comprises a diabetes medication dosage instruction for the patient according to the clinical algorithm. In certain instances, the medication dosage instruction may comprise a titration instruction for at least one medication. In certain instances, the medication dosage instruction may comprise a medication dosage instruction for two or more medications.

Referring now toFIG.2, a schematic diagram200of smart speaker102and a plurality of remote patient monitoring devices244, through which one or more aspects of the present disclosure may be implemented, is shown. In accordance with certain aspects of the present disclosure, smart speaker102may comprise one or more microprocessor202or microcontroller, read-only memory device204, flash memory206, memory storage device208, I-O device210, buttons212(e.g., volume control button), display214(e.g., user interface) rechargeable battery216, microUSB218, CODEC220, digital-to-analog converter (DAC)/analog-to-digital converter (ADC)222, microphone224, speaker226, speaker amplifier228, wireless transceiver ICs230(e.g., including, but not limited to, BLUETOOTH and Wi-Fi), micro GSM/GPRS chipset232, micro SIM module234, antenna236, sensors238, vibrating motor (output)240, and power management IC242. In accordance with certain embodiments, elements202-240may be operably configured in combination, each component engaged electronically, via one or more I2C or I2S and controlled by microprocessor202to function as a self-contained portable Internet-of-Things (IoT) device. In certain embodiments, microprocessor202may comprise a SoC MT8163 SoC or MT7658CSN ICs (MEDIATEK, Hsinchu, Taiwan) incorporating wireless transceiver ICs230and a GPS receiver. In various embodiments, flash memory206may comprise an embedded Multi-Chip (eMCP) with RAM and eMMC-flash memory integrated in a single IC (e.g., available from several vendors including, MICRON (Boise, ID), SAMSUNG (Suwon-si, South Korea), and SK HYNIX (Icheon-si, South Korea). In various embodiments, DAC/ADC222may comprise one or more converters; for example, TEXAS INSTRUMENTS (Dallas, TX) TLV320ADC, TLV320ADC3101, TLV320DAC. In various embodiments, speaker amplifier228may be embedded with DAC/ADC222whereby the output of the chip feeds into speaker226. In various embodiments, CODEC220may comprise an ultra-low power audio CODEC (e.g., TLV320DAC3202, TEXAS INSTRUMENTS). In various embodiments, microprocessor202may comprise a System on Chip (SoC); for example, an MT8516B SoC (MEDIATEK, Hsinchu, Taiwan), designed specifically for voice assistance devices. In various embodiments, I-O device210may comprise one or more LEDs controlled by one or more LED drivers (e.g., LP55231, available from TEXAS INSTRUMENTS, or IS31FL3236, available from LUMISSIL MICROSYSTEMS, Milpitas, CA). In various embodiments, buttons212may comprise tactile buttons. In various embodiments, power management IC242may comprise MT6323 (MEDIATEK, Hsinchu, Taiwan) with buck regulator components or an integrated power management IC TPS65910A1 (TEXAS INSTRUMENTS). In various embodiments, sensors238may comprise non-limiting haptic, visible light, infrared, and acoustic sensors, among others. Microphone224may comprise, for example, a V6 MEMS microphone available from KNOWLES SISONIC (Itasca, IL). In certain embodiments, microphone224may comprise a microphone array with built-in advanced DSP algorithms including, but not limited to, ReSpeaker v2, Matrix Creator, PS3 eye, Conexant 4, MiniDSP UMA-8, Microsemi AcuEdge ZLK38AVS, among others.

In accordance with certain aspects of the present disclosure, smart speaker102is communicably engaged with one or more remote cloud-based or virtual servers (e.g., application server110ofFIG.1) capable of providing ASR-response, NLU-processing, predictive algorithm processing, reminders, alerts, general and specific information for remote management of patient user22ofFIG.1with an acute, chronic, condition, or disease, including but not limited to diabetes, cancer, hypertension, infectious disease, kidney disease, heart failure, among others. In various embodiments, device102may be communicably engaged (e.g., via antenna236) with the plurality of remote patient monitoring devices244. In accordance with certain embodiments, the plurality of remote patient monitoring devices244may include, but are not limited to, continuous glucose monitor (CGM)106, a glucometer248, a remote or mobile patient monitor250, end user smart speaker102and/or smart appliance254. In certain embodiments, patient monitor250may comprise one or more physiological sensors configured to measure one or more physiological data for a patient, including EKG, ECG, variable heart rate, blood pressure and the like. Plurality of remote patient monitoring devices244may further comprise one or more point-of-care testing (POCT) device, glucose meter, lactate meter, capillary blood collection device, IoT sensor and the like. In certain embodiments, smart speaker102may act as a broker between the plurality of remote patient monitoring devices244and application server110ofFIG.1.

Referring now toFIG.3(with cross-references toFIG.1), a system diagram of a voice-based system300for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, system300comprises an embodiment of system100, as shown and described inFIG.1. In accordance with certain aspects of the present disclosure, smart speaker102is communicably engaged with application server110via communication network118in order to execute a local instance of conversational agent122. Application server110preferably comprises a secured HIPAA-compliant server. In accordance with certain aspects of the present disclosure, application server110is configured to provide one or more cloud-based control services to smart speaker102via one or more computing module executing on application server110. In certain embodiments, the one or more cloud-based control services include automated speech recognition (ASR)312, natural language processing (NLP)314, natural language understanding (NLU)316, dialogue management318, and text-to-speech (TTS) converter320. In various embodiments, the cloud-based control services, together with smart speaker102, drive the operations of conversational agent122to perform natural language or speech-based automated, dynamic multi-turn conversations with patient user22. Smart speaker102enables patient user22to access, interact, and engage with conversational agent122to receiving a plurality of generative voice prompts for remotely managing at least one medication prescription, therapeutic dose titration and/or dose regimen. In various embodiments, smart speaker102may provide for recording, tracking and monitoring of the user's medication adherence, medication adverse reactions, and the user's behavioral phenotype; including, but not limited to, social demographics, health literacy, technical literacy, illness perception, and clinical complexity, among others. In various embodiments, smart speaker102may provide for recording, tracking and monitoring of voice-based interactions between patient user22and smart speaker102; including, but not limited to, device check-in frequency, user speech complexity, clinical flexibility, user personality, and user persistence, among others. In various embodiments, smart speaker102listens to and interacts with patient user22to determine at least one intent based on NLU of the user's speech. Smart speaker102may be configured to record or monitor one or more voice utterances302from patient user22and transmit them to application server110via communication network118. Communication network118may comprise a LAN, WAN, wireless network, cellular network, or Internet connection/protocol. The control service executed by application server110may perform ASR312, NLP314and/or NLU316on the voice utterances302from patient user22to determine intents expressed by the utterances via one or more scripted computing skills in accordance with the conversational AI model. In response to an identified intent, the control service may perform one or more corresponding actions. In various embodiments, an action may be performed at the control service or by instructing smart speaker102to perform a function, including outputting a generative voice prompt304to patient user22. The combination of smart speaker102and one or more applications executed by the control service may serve as conversational agent122. Conversational agent122may facilitate multi-turn conversational interactions, utilizing ASR312, NLP314, NLU316, and TTS320conversion to perform said functions, interact with patient user22, query questions to patient user22, and provide patient user22with one or more prompts for management of type 2 diabetes in patient user22; including, but not limited to, non-clinical self-management instructions, education, health-related information, nutrition, carb counts, instructional video, tasks, alerts, and the like. In accordance with certain aspects of the present disclosure, conversational agent122may provide one or more generative voice prompts to instruct patient22to fill a prescription32and/or provide instructions for administering a dose of insulin34and/or medication36in accordance with a clinical protocol. Insulin34may comprise basal or prandial insulin in accordance with the clinical protocol. In certain embodiments, medication36may comprise a medication for management of type 2 diabetes; including, but not limited to, metformin immediate release, metformin extended release, semaglutide, tirzepatide, liraglutide, retatrutide, dulaglutide, exenatide, exenatide extended release, lixisenatide, empagliflozin, canagliflozin, ertugliflozin, bexagliflozin, sotagliflozin, rosuvastatin, atorvastatin, fluvastatin, lovastatin, pravastatin, simvastatin, and pitavastatin. In certain embodiments, medication36may comprise one or more medication for management of hypertension in association with managing type 2 diabetes; including, but not limited to, losartan, valsartan, olmesartan, candesartan, irbesartan, telmisartan, amlodipine, hydrochlorothiazide, chlorthalidone, azilsartan, eprosartan, chlorothiazide, indapamide, metolazone, amiloride, spironolactone, triamterene, eplerenone, lisinopril, captopril, benazepril, enalapril, fosinopril, moexipril, perindopril, quinapril, ramipril and trandolapril. In certain embodiments, medication36may further comprise one or more medication for management of hypertension in association with managing type 2 diabetes; including, but not limited to, bumetanide, torsemide, acebutolol, atenolol, betaxolol, bisoprolol, carvedilol, carvedilol phosphate, labetalol, metoprolol tartrate, metoprolol succinate, nadolol, nebivolol, penbutolol, pindolol, propranolol IR, propranolol LA, solatol, timolol, diltiazem, felodipine, isradipine, nicardipine, nifedipine LA, nisoldipine, verapamil, doxazosin, prazosin, terazosin, methyldopa, clonidine, guanfacine, hydralazine, minoxidil, and sacubitril/valsartan.

An object of the present disclosure provides for the combined function of smart speaker102and the one or more cloud-based control services of application server110. According to certain aspects of the present disclosure, application server110performs services/functions generally understood and referred to as “cloud computing,” “on-demand computing,” “software as a service (SaaS),” “platform computing,” “network-accessible platform,” “cloud services,” “data centers,” and the like. The term “cloud” generally encompasses a collection of hardware and software that forms a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services, etc.) suitably provisioned to provide on-demand self-service, network access, resource pooling, elasticity, and measured service, among other features. In various embodiments, a cloud-based control service may be implemented through a SaaS model, including but not limited to: AMAZON Web Services, AMAZON Lex, AMAZON Lambda, available through AMAZON (Seattle, WA); CLOUD AI, GOOGLE Cloud, available through Google, Inc. (Mountain View, Calif.); AZURE AI, available through Microsoft, Inc. (Redmond, Wash.). These services may provide access to one or more remote servers containing hardware and software to operate in conjunction with smart speaker102.

In lieu of being bound to a specific configuration, the one or more cloud-based control services of application server110may provide speech services implementing automated computing modules, ASR312, NLP314, and dialogue management318, TTS320, and applications providing commands back to smart speaker102. Computing module ASR312may recognize human speech in an audio signal transmitted by smart speaker102received from a built-in microphone. Module NLP314may determine the intent of patient user22based on his or her speech that is recognized by ASR312. The speech services may also include speech generation functionality that synthesizes speech audio. The control service may also use dialogue management318to provide a plurality of system prompts to patient user22to coordinate speech; for example, dialogues about medication titration, blood glucose values, or interactions with the user in conjunction with the speech services. Speech dialogues may be used to determine patient user22intents using speech prompts. One or more applications may serve as a command interpreter that determines functions or commands corresponding to intents expressed by the user's speech. In alternative embodiments, commands may correspond to functions that are to be performed by smart speaker102and a command interpreter may, in those cases, provide smart speaker102commands or instructions to smart speaker102for implementing such functions. The command interpreter may implement “built-in” capabilities that are used in conjunction with smart speaker102. The control service may be configured to use a library of installable applications including one or more software applications; for example, medication titration, behavioral modification, and medication persistence.

The one or more cloud-based control services may interact with other network-based services (e.g., AMAZON Lambda) to obtain information, access additional database, application, or services on behalf of patient user22. Dialogue management318may be configured to coordinate dialogues or interactions with patient user22based on speech as recognized by ASR312and/or interpreted by NLP314. The one or more cloud-based control services may also use TTS320responsive to dialogue management318to generate speech for playback on smart speaker102. These cloud-based control service modules may function based on models or rules, which may include acoustic models, specify grammar, lexicons, phrases, responses, among others, created through various training or machine learning techniques, including a large language model and generative pre-trained transformer. Dialogue management318module may utilize dialogue models that specify logic for conducting dialogues with patient user22. In various embodiments, a dialogue may comprise an alternating sequence of natural language statements or utterances302by patient user22and system generated speech or textual responses304via smart speaker102. The dialogue models embody logic for creating responses based on received patient user22statements to prompt patient user22for more detailed information of the intents or to obtain other information from patient user22.

An application selection component or intent router identifies, selects, and/or invokes installed smart speaker102applications and/or application server110applications in response to user intents identified by NLP314. In response to a determined user intent, the intent router can identify one of the installed applications capable of servicing the user intent. The application can be called or invoked to satisfy the user intent or to conduct further dialogue with patient user22to further refine the user intent. Each of the installed applications may have an intent specification that defines the serviceable intent. The one or more cloud-based control services may use the intent specifications to detect user utterances, expressions, or intents that correspond to the applications. An application intent specification may include natural language understanding models for use by NLP314. In addition, one or more installed applications may contain specified dialogue models for creating and coordinating speech interactions with patient user22. The dialogue models may be used by dialogue management318in conjunction with the dialogue models to create and coordinate dialogues with patient user22and to determine user intent either before or during operation of the installed applications.

NLP314and dialogue management318may be configured to use the intent specifications of the applications either to conduct dialogues, to identify expressed intents of patient user22, identify and use the intent specifications of installed applications, in conjunction with NLP314models and dialogue models, to determine when patient user22has expressed an intent that can be serviced by the application, and to conduct one or more dialogues with patient user22. As an example, in response to an utterance302by patient user22, the control service may refer to the intent specifications of multiple applications, including both smart speaker102applications and application server110applications. The control service may then invoke the corresponding application. Upon invocation, the application may receive an indication of the determined intent and may conduct or coordinate further dialogues with patient user22to elicit further intent details. Upon determining sufficient details regarding the user intent, the application may perform its designed functionality in fulfillment of the intent. Smart speaker102may be optimally configured for low device operation latency and for parsimonious memory usage to enable prompt responsiveness to enhance user experience.

Referring now toFIG.4, a functional block diagram of a routine400for configuring a clinical protocol within the voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100, as shown and described inFIG.1. In accordance with certain aspects of the present disclosure, routine400comprises one or more operations402-430to enable a practitioner user (e.g., practitioner user24ofFIG.1) to configure a clinical protocol for management of type 2 diabetes in a patient (e.g., patient user22ofFIG.1) via a practitioner instance of a diabetes management application (e.g., practitioner instance120′ of diabetes management application120ofFIG.1). The operations in routine400may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention

In accordance with certain embodiments, routine400comprises one or more steps or operations for launching an instance of a diabetes management application (e.g., practitioner instance120′ of diabetes management application120ofFIG.1) at a client device associated with the practitioner user (Step402). The instance of the diabetes management application may comprise a graphical user interface configured to enable the practitioner user in providing a plurality of inputs for configuring a clinical protocol for the patient. In accordance with certain embodiments, routine400may comprise one or more steps or operations (e.g., presenting one or more user interface elements) to enable the practitioner user to select a patient to be associated with the clinical protocol (Step404) and select and label one or more clinical protocols to be associated with that patient (Step406). Routine400may further comprise one or more steps or operations (e.g., presenting one or more user interface elements) to enable the practitioner user to configure one or more clinical parameters for the selected protocol(s) (Step408). In accordance with certain embodiments, the one or more clinical parameters may include, but are not limited to, parameters for configuring a diabetes medication prescription protocol or other medication prescription protocols407, patient weight (or other patient data)410, dosage amount412, dosage frequency414and a goal fasting blood sugar range416(e.g., including goal hemoglobin A1C). Routine400may further comprise one or more steps or operations (e.g., presenting one or more user interface elements) to enable the practitioner user to configure one or more medication titration parameters for the selected protocol(s) (Step418). In accordance with certain embodiments, the one or more medication titration parameters for the selected protocol(s) may comprise titration parameters applicable to varying trigger conditions (e.g., blood sugar ranges, hypoglycemic events, hypertensive events, laboratory test result data, and the like). For example, a first set of titration parameters, titration parameters A420, may comprise a first set of titration parameters for modifying a medication dosage regimen for at least one medication (e.g., a GLP-1 agonist drug, a biguanide drug, or a SGLT-2 inhibitor drug) under a first set of conditions for the patient (e.g., average fasting blood sugar falling within a first specified range). A second set of titration parameters, titration parameters B422, may comprise a second set of titration parameters for modifying the medication dosage regimen for the at least one medication under a second set of conditions for the patient (e.g., average fasting blood sugar falling within a second specified range). Routine400may enable the practitioner user to configured additional titration parameters, e.g., titration parameters N424, comprising one or more successive titration parameters for modifying the medication dosage regimen for the at least one medication under one or more safety or efficacy conditions for the patient (e.g., blood sugar ranges, hypoglycemic events, hypertensive events, laboratory test result data, and the like). In accordance with certain aspects of the present disclosure, titration parameters N424may comprise one or more parameters for terminating the clinical protocol, changing the clinical protocol, and/or temporarily locking the clinical protocol in response to one or more triggering conditions (e.g., safety or efficacy conditions for the patient).

Routine400may further comprise one or more steps or operations (e.g., presenting one or more user interface elements) to enable the practitioner user to configure one or more time-based parameters (e.g., protocol duration or titration frequency) for administering the protocol and/or titrating the medication regimen according to the titration parameters (Step426). Routine400may further comprise one or more steps or operations (e.g., presenting one or more user interface elements) to enable the practitioner user to configure a maximum dosage for the medication regimen (Step428) and submit a prescription to at least one networked server via the practitioner interface (Step430). In accordance with certain aspects of the present disclosure, the prescription comprises the practitioner-generated inputs received at steps408-428.

Referring now toFIG.5, illustrations of a user interface screen500associated with a practitioner instance of a diabetes management application are shown. In accordance with certain aspects of the present disclosure, the practitioner instance of the diabetes management application comprises practitioner instance120′ of diabetes management application120ofFIG.1. In accordance with certain embodiments, user interface screen500is implemented in accordance with routine400ofFIG.4. In accordance with certain embodiments, user interface screen500comprises a graphical user interface comprising a plurality of graphical elements502-510configured to enable the practitioner user to configure one or more clinical protocol(s) and prescription(s) for a patient. In accordance with certain embodiments, user interface screen500may comprise a graphical element502configured to enable the practitioner user to select one or more glycemic medication protocols for the patient (e.g., default, conservative, off). In accordance with certain embodiments, each protocol may comprise parameters for a biguanide drug regimen, a SGLT-2 inhibitor drug regimen and a GLP-1 agonist drug regimen. In said embodiments, user interface screen500may comprise interface elements504for configuring a biguanide drug regimen associated with the selected protocol. Interface elements504may comprise a graphical element (e.g., a toggle button) for turning the biguanide drug regimen ON or OFF within the selected protocol; a graphical element for selecting a biguanide drug (e.g., metformin IR), a current (i.e., prescribed) dose, a maximum dosage for titration, and a minimum number of days between titrations. In said embodiments, user interface screen500may comprise interface elements506for configuring a SGLT-2 inhibitor drug regimen associated with the selected protocol. Interface elements506may comprise a graphical element (e.g., a toggle button) for turning the SGLT-2 inhibitor drug regimen ON or OFF within the selected protocol; a graphical element for selecting a SGLT-2 inhibitor drug (e.g., empagliflozin), a current (i.e., prescribed) dose, a maximum dosage for titration, and a minimum number of days between titrations. In said embodiments, user interface screen500may comprise interface elements508for configuring a GLP-1 agonist drug regimen associated with the selected protocol. Interface elements508may comprise a graphical element (e.g., a toggle button) for turning the GLP-1 agonist drug regimen ON or OFF within the selected protocol; a graphical element for selecting a GLP-1 agonist drug (e.g., semaglutide SQ), a current (i.e., prescribed) dose, a maximum dosage for titration, and a minimum number of days between titrations. In certain embodiments, user interface screen500may comprise one or more interface elements510to enable the practitioner user to input one or more baseline laboratory values for the patient user (e.g., baseline chromium, baseline potassium, and baseline sodium).

Referring now toFIG.6, a process flow diagram of a routine600for configuring a clinical algorithm within a voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100as shown and described inFIG.1. In certain embodiments, one or more steps or operations of routine600may be successive or sequential to one or more steps or operations of routine400, as shown and described inFIG.4. In accordance with certain aspects of the present disclosure, routine600comprises one or more steps or operations602-618for configuring and implementing a clinical algorithm at an application server (e.g., application server110ofFIG.1). The one or more steps or operations602-618may be embodied as one or more operations of diabetes management application120executing on application server110, as shown and described inFIG.1. The operations in routine600may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, routine600may comprise one or more steps or operations for configuring one or more endpoints within the voice-based system for management of type 2 diabetes (Step602). The one or more endpoints may comprise one or more client devices (e.g., end user device104inFIG.1), one or more remote patient monitoring devices (e.g., CGM106inFIG.1), and/or one or more external data sources (e.g., external EMR/EHR server130inFIG.1). Step602may further comprise one or more steps or operations for configuring one or more data transfer protocols between the application server and the one or more endpoints. Routine600may proceed by executing one or more steps or operations for configuring one or more user profiles and/or user permissions for one or more users (e.g., patient user22and practitioner user24ofFIG.1) of the diabetes management application (Step604). Routine600may proceed by executing one or more steps or operations for receiving a plurality of user-generated inputs/configurations via a data transfer protocol with the practitioner instance of the diabetes management application (Step606). In accordance with certain aspects of the present disclosure, one or more operations of step606may be dependent on an output of routine400ofFIG.4. Routine600may proceed by executing one or more steps or operations for processing the plurality of user-generated inputs/configurations received at step606according to one or more data processing steps (Step608). According to certain aspects of the present disclosure, the one or more data processing steps at step608are configured to configure a clinical algorithm within the diabetes management application. In accordance with said aspects, the one or more data processing steps at step608further comprise one or more steps or operations for configuring one or more single medication protocol(s) for the patient user (Step610), configuring one or more medication-to-medication protocol(s) (i.e., multi-medication protocols) for the patient user (Step612) and configuring one or more safety protocol(s) for the patient user (Step614). Routine600may further comprise one or more steps or operations for configuring one or more data ingestion protocols (e.g., for the one or more endpoints) (Step616). The one or more data ingestion protocols may comprise protocols for processing clinical data inputs from the one or more endpoints; including, but not limited to, basic metabolic panel data (e.g., sodium, potassium, chloride, bicarbonate, BUN, creatinine, glucose, magnesium, phosphate, calcium, uric acid, and the like), hemoglobin A1C data, medication adherence data based on patient-reported data (e.g., Rx fill data, Rx log data), blood pressure data, physiological sensor data, patient-reported side effects, and the like. Routine600may further comprise one or more steps or operations for storing the clinical algorithm at the application server and implementing the clinical algorithm within one or more operations of the diabetes management application (Step618).

Referring now toFIG.7, a process flow diagram of an exemplary clinical algorithm700is shown. In accordance with certain aspects of the present disclosure, clinical algorithm700comprises a non-limiting example of at least one clinical algorithm that may be configured as an output of routine600inFIG.6. Clinical algorithm700may further provide an example of a clinical algorithm that may be configured in response to the plurality of practitioner-generated inputs and configurations received pursuant to routine400inFIG.4. Clinical algorithm700is intended to be illustrative (i.e., not limiting) and it is anticipated that the functions and operations of the clinical algorithm will be driven by a myriad of configurable parameters for management of type 2 diabetes in a patient. The operations in clinical algorithm700may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, clinical algorithm700may comprise a sequence of operations702-718for medication initiation and titration in a medication regimen for a patient with type 2 diabetes. In accordance with certain embodiments, clinical algorithm700may comprise at least one operation based on an input of the patient's weight (e.g., the patient weighs 100 kg) (Block702). If YES, then clinical algorithm700is configured to output a first medication dosage instruction, e.g., administer 20 units of Glargine QAM (0.2 U/kg). In accordance with certain aspects of the present disclosure, the patient reports their fasting blood glucose and medication dosage log for a specified time period (e.g., three consecutive days) via one or more conversational interactions with the conversational AI agent. In response to said data inputs, algorithm700may comprise at least one operation to determine whether a patient's average fasting blood sugar over those three days is above 180 mg/dL (Block704). If YES, then algorithm700is configured to titrate the medication dosage (e.g., administer 25 units QAM (+25%)). In accordance with certain aspects of the present disclosure, the patient reports their fasting blood glucose and medication dosage log for a specified time period (e.g., three consecutive days) via one or more conversational interactions with the conversational AI agent. In response to said data inputs, clinical algorithm700may comprise at least one operation to determine whether the patient's average fasting blood sugar is below 90 ml/dL (Block706). If YES, then clinical algorithm700is configured to titrate the medication dosage (e.g., administer 17 units QAM (−3 U)).

Clinical algorithm700may further comprise at least one operation to determine whether the patient recorded or logged the required data for three consecutive days (Block708). If NO, then clinical algorithm700is configured to drive at least one function of the conversational AI agent to generate a voice-based prompt to remind the patient to log the data and no dose adjustments will be made until three consecutive days of logged data are received (Block714). Clinical algorithm700may further comprise at least one operation to determine whether the patient has a “hypoglycemic event” (Block710). If YES, then clinical algorithm700is configured to drive at least one function of the conversational AI agent to generate a voice-based prompt to instruct a patient to adjust the medication dosage per a predetermined hypoglycemia protocol (Block718). Clinical algorithm700may further comprise at least one operation to determine whether the patient is correctly taking the medication dose as prescribed (e.g., in response to processing the patient log data) (Block712). If NO, then clinical algorithm700is configured to adjust the medication dosage according to the patient-reported data and is configured to drive at least one function of the conversational AI agent to generate a voice-based prompt to the patient (Block716). For example, if clinical algorithm700prescribed 10 units of Glargine QAM and during the three-day adjustment period the patient's average fasting blood sugar is within goal, but the patient reported taking 8 units one night, then 9 units, then 8 units, then clinical algorithm700may drive at least one function of the conversational AI agent to instruct the patient to take 9 units (e.g., the maximum dose taken in that period). However, if a patient reports taking some medication doses that are both above the patient's prescription and below the patient's prescription within the same period, then the clinical algorithm700will not adjust the medication dosage.

Referring now toFIG.8, a process flow diagram of a routine800for configuring a large language model within the voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100as shown and described inFIG.1. In certain embodiments, one or more steps or operations of routine800may be successive or sequential to one or more steps or operations of routine400, as shown and described inFIG.4, and/or one or more steps or operations of routine600, as shown and described inFIG.6. In accordance with certain aspects of the present disclosure, routine800comprises one or more steps or operations802-812for configuring a large language model at an application server (e.g., application server110ofFIG.1). The one or more steps or operations802-812may be embodied as one or more processor-executable instructions of large language model engine121executing on application server110, as shown and described inFIG.1. The operations in routine800may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, routine800may comprise one or more steps or operations for analyzing one or more clinical algorithm (e.g., pursuant to an output of routine600inFIG.6) to extract one or more variables (Step802). In accordance with certain embodiments, the one or more variables may comprise one or more clinical parameters configured by the practitioner user pursuant to routine400inFIG.4(e.g., via user interface screen500ofFIG.5). Routine800may proceed by executing one or more steps or operations for configuring a plurality of LLM agenda items according to the one or more variables (Step804). The LLM agenda items may include, for example, a “New Medication Recommendation” item, a “GLP-1 Education” item, a “Medication Initiation” item, a “Medication Titration” item, and other items based on the clinical algorithm(s). Routine800may proceed by executing one or more steps or operations for configuring a plurality of agenda prompts according to the plurality of LLM agenda items (Step806). The plurality of agenda prompts may include, for example, one or more generative prompts associated with a desired outcome of the plurality of LLM agenda items. Routine800may proceed by executing one or more steps or operations for classifying one or more LLM intents; e.g., according to each agenda prompt in the plurality of agenda prompts (Step808). In certain embodiments, classifying the LLM intents may comprise one or more steps or operations for analyzing a plurality of conversational or user-utterance data to create embeddings comprising clusters of semantically similar sentences. In accordance with certain embodiments, the clustered groupings may each comprise an intent, each of which may be classified according to the plurality of agenda prompts. Routine800may proceed by executing one or more steps or operations for configuring one or more slot values for the large language model; e.g., corresponding to the LLM intents (Step810). In accordance with certain embodiments, the slot values comprise different parameters for the user's query/response. Upon completion of steps802-810, routine800may comprise one or more steps or operations for deploying the LLM (e.g., at large language model engine121) (Step812). In certain embodiments, routine800may comprise one or more steps or operations for training the LLM according to the configurations from steps802-810(Step814). In accordance with certain embodiments, step814may comprise analyzing a library of training data from other users of the voice-based system for management of type 2 diabetes. In certain embodiments, one or more operations of step814may be performed on a continuous basis in response to new user data.

In accordance with certain aspects of the present disclosure, an example of an output of routine800may comprise the LLM configurations shown in Table 1 below.

TABLE 1Example LLM Configuration 1Agenda Item:New Medication RecommendationDescription:This item is added to the agenda to initiate a newmedication per the clinical algorithm. The purposeof this agenda item is to confirm the patient consentsto starting the new medication and answer anyquestions the patient might have about the newmedication.LLM Usage:Answer specific medication questions based onknowledge baseIdentify reason (from given list) that patient isapprehensiveSlots:questions_about_med: bool REQUIREDcomfortable_starting_med: bool REQUIREDrecommendation_confirmation: bool REQUIRED

In accordance with certain aspects of the present disclosure, another example of an output of routine800may comprise the LLM configurations shown in Table 2 below.

TABLE 2Example LLM Configuration 2Agenda Item:GLP-1 EducationDescription:This idem is added to the agenda when a patient agreesto start a GLP-1 agonist. This item will only occurafter the patient has alreadypicked up the GLP-1agonist. The purpose of this agenda item is toeducate the patient on GLP-1 agonist use. Educationitems include how to administer a GLP-1 agonist(injection site, medication pen, sharps disposal),how to store medication and how to check bloodsugars (CGM vs glucometer).LLM Usage:Answer specific medication questions based onknowledge baseSlots:picked_up_rx: bool REQUIREDneeds_education: boolhas_CGM: boolunderstands_blood_sugar_checks: bool

In accordance with certain aspects of the present disclosure, another example of an output of routine800may comprise the LLM configurations shown in Table 3 below.

TABLE 3Example LLM Configuration 3Agenda Item:Medication InitiationDescription:This item is added to the agenda when a providerwants to initiate a new medication and the patienthas agreed to start taking it. The purpose of thisagenda item is to confirm that the patient has pickedup the new medication, understands the prescriptionand is informed about possible side effects.LLM Usage:Identify issue with picking up RxAnswer specific side effect question based on ourknowledge baseSlots:picked_up_rx: bool REQUIREDrecommendation_confirmation: bool REQUIREDunderstands_side_effects: bool REQUIREDissues_with_rx: boolrx_issue: categorical

In accordance with certain aspects of the present disclosure, another example of an output of routine800may comprise the LLM configurations shown in Table 4 below.

TABLE 4Example LLM Configuration 4Agenda Item:Medication TitrationDescription:This agenda item occurs when a patient checks-inafter initiation of a new medication. The purpose ofthis agenda item is to ask about adherence and sideeffects and provide a dose adjustment if needed.LLM Usage:Confirm conditions for medication titrationSlots:rx_started: boolpicked_up_rx: boolmed_adherence_1: bool REQUIREDmed_adherence_2: boolmed_adherence_3: boolmed_adherence_4: boolmed_dose_1: float REQUIREDmed_dose_2: floatmed_dose_3: floatmed_dose_4: floatmed_adherence_confirmation: bool REQUIREDside_effects_present: boolside_effects_severity: boolhas_enough_medication: boolrecommendation_confirmation: bool REQUIRED

Referring now toFIG.9, a process flow diagram of a routine900for executing a user session within a voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100as shown and described inFIG.1. In certain embodiments, one or more steps or operations of routine900may be successive or sequential to one or more steps or operations of routine400, as shown and described inFIG.4, and/or one or more steps or operations of routine600, as shown and described inFIG.6, and/or one or more steps or operations of routine800, as shown and described inFIG.8. In accordance with certain aspects of the present disclosure, routine900comprises one or more steps or operations902-928for receiving and processing a plurality of user utterances to generate a conversational agent output in accordance with a conversational AI model. The one or more steps or operations902-928may be embodied as one or more processor-executable instructions of large language model engine121and/or conversational agent122, as shown and described inFIG.1. The one or more steps or operations in routine900may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, routine900may comprise one or more steps or operations for invoking one or more custom operations or functions of a conversational agent accessible to a patient in a non-clinical setting and executable via a smart speaker in conjunction with a conversational agent. In various embodiments, a custom operations or functions may comprise an Intent Schema, Slot Types definitions and Sample Utterances. In various embodiments, a developer may define one or more intents in the Intent Schema. In various embodiments, intents may be programmed in JavaScript Object Notation (JSON) data structure, a lightweight data-interchange format, based on a sub-net of the JavaScript programming language. In various embodiments, intents may represent one or more actions to be performed by the conversational agent. In various embodiments, a Sample Utterance may be words spoken by a user to invoke a request. In various embodiments, an intent may possess an intent signature defined to it which starts with an action and sets the type of action's properties. In various embodiments, a Slot may be a statically typed argument that is passed into an intent. In various embodiments, one or more operations or functions of the conversational agent may comprise the steps of a New Session, Launch Request, Intent Request, and a Session End Request.

In accordance with an illustrative example as shown inFIG.9, routine900may comprise a process flow for recommending a new medication (e.g., metformin) to a patient user. Routine900may be initiated upon executing one or more steps or operations for receiving a user invocation at a smart speaker device configured to execute an instance of a conversational agent (Step902a). In accordance with Step902a, the patient user may speak a wake word utterance (e.g., “Hey UpDoc”) to the smart speaker. In certain embodiments, the conversational agent may initiate the system invocation without the use of a wake word (e.g., at one or more designated time intervals) (Step902b). In response to the invocation, routine900may comprise one or more steps or operations to initiate a Session Start to create a new conversation session with the conversational agent (Step904). Routine900may proceed in response to receiving at least one user utterance via the conversational agent (Step906). Per step906, the patient user may ask the conversational agent a question (e.g., “What is metformin?”). In various embodiments, a new session may comprise one or more YES or NO process options determined by a switch state with (event.request.type) parameters for either a Launch Request, Intent request, or End Session Request. In accordance with certain instances, a user question may comprise an invocation name (e.g., metformin). In accordance with said instances, routine900may execute one or more steps or operations to initiate a Launch Request (Step908). The conversational agent may respond accordingly using a flash briefing function and providing a Speech Output containing the requested information (Step910).

In an alternative instance, a User Utterance may comprise the option to advance to an Intent Request where parameters (event.request.intent.name) determine the execution of the domain logic for one or more intent (Step912). The Intent Request may comprise a user inquiry (e.g., “How does metformin work?”). In accordance with certain embodiments, routine900may comprise one or more operations for initiating an http request to retrieve a knowledge base response (Step914). In accordance with said embodiments, routine900may execute one or more steps or operations to perform the http request in accordance with a “newmed” API (Step916) and receive a response containing the API data (Step918). In accordance with certain embodiments, API data may be processed through a JSON parse (Step920) and subsequently manipulated according to one or more data transform operations (Step922). At this junction, a process option (YES/NO) determines whether to generate a response. In accordance with certain embodiments, if YES, then one or more helper functions may be used to generate a data structure (e.g., returned from a conversational AI engine) and subsequently transmitted to the smart speaker via a generateresponse step (Step924). A response data structure may comprise a SpeechletResponse (Step926) that specifies the output text for the smart speaker to speak via Speech Output step910, as well as whether to end the session via a Session End (Step928). If NO, The conversational agent may respond accordingly using a flash briefing function and providing a Speech Output (Step910) and end the session via a Session End (Step928).

Referring now toFIG.10, a process flow block diagram of a multi-turn user interaction1000with a conversational agent of the voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100as shown and described inFIG.1. In certain embodiments, one or more steps or operations of multi-turn user interaction1000may be successive or sequential to one or more steps or operations of routine400, as shown and described inFIG.4, and/or one or more steps or operations of routine600, as shown and described inFIG.6, and/or one or more steps or operations of routine800, as shown and described inFIG.8. In certain embodiments, one or more steps or operations of multi-turn user interaction1000may be embodied within one or more steps or operations of routine900, as shown and described inFIG.9. In accordance with certain embodiments, multi-turn user interaction1000may comprise a plurality of multi-turn user interactions1002-1042for initiating a new medication for the patient user according to a conversational AI model agenda item. The one or more steps or operations in multi-turn user interaction1000may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, a session of multi-turn user interaction1000may be initiated upon a wake word utterance (Block1002) by a patient user to a smart speaker (e.g., smart speaker102ofFIG.1) configured to execute a conversational agent (e.g., conversational agent122ofFIG.1) of the voice-based system for management of type 2 diabetes. The conversational agent may process the wake word utterance as a session invocation (Block1004) and instantiate a session start (Block1006) of multi-turn user interaction1000. In accordance with certain aspects of the present disclosure, the conversational agent may be configured to generate a generative voice output according to a conversational AI model agenda item for recommending a new medication for the patient user (Block1007). The conversational agent may proceed by generating a generative voice output to prompt the patient user to confirm whether the patient user has any questions about the new medication (Block1008). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to confirm whether the patient user has any questions (Block1010). Multi-turn interaction1000may comprise a decision block1012for driving the next turn in the multi-turn interaction based on the content of the user response from block1010. If user response1010comprises a YES response (i.e., the patient user has questions about the new medication), the conversational agent proceeds by processing the patient user's question(s) according to the conversational AI model to generate a generative voice output comprising a knowledge library response to the patient user's question(s) (Block1014). In accordance with certain embodiments, multi-turn interaction1000may repeat the interaction sequence of blocks1008-1014until all of the patient user's questions about the new medication have been answered. If user response1010comprises a NO response (i.e., the patient user does not have questions about the new medication), then the conversational agent proceeds by generating a generative voice prompt to confirm whether the patient user consents (i.e., agrees to take) to the new medication (Block1016). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to indicate consent to the new medication (Block1018).

Multi-turn interaction1000may comprise a decision block1020for driving the next turn in the multi-turn interaction based on the content of the user response from block1018. If user response1018comprises a NO response (i.e., the patient user does not consent to the new medication), the conversational agent proceeds by generating a generative voice output to prompt the user to identify issues/discomfort with the new medication (Block1024). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to identify issues/discomfort with the new medication (Block1026). The conversational agent proceeds by processing the user response from block1026according to the conversational AI model to determine the patient user's issue with the new medication and generates a generative voice output comprising a knowledge library response to the patient user's issue (Block1028). The conversational agent proceeds by generating a generative voice output to prompt the user to confirm whether the user's issue/discomfort with the new medication has been resolved (Block1030). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to confirm resolution (Block1032). Multi-turn interaction1000may comprise a decision block1034for driving the next turn in the multi-turn interaction based on the content of the user response from block1032. If user response1032comprises a NO response (i.e., the patient user's issue/discomfort with the new medication has not been resolved), the conversational agent proceeds by generating a generative voice output to instruct the patient user to follow-up with the patient's primary care provider and concludes the interaction (Block1040). If user response1032comprises a YES response (i.e., the issue/discomfort with the new medication has been resolved), then multi-turn interaction1000proceeds to block1022.

If user response1018comprises a YES response (i.e., the patient consents to the new medication), the conversational agent proceeds by generating a generative voice output to confirm the new prescription (Block1022). The conversational agent proceeds by generating a generative voice output to prompt the user to confirm one or more aspects of the new prescription (e.g., pharmacy location, prescription start date, etc.) (Block1036). The patient user provides a voice response to the conversational agent in response to the generative voice output to confirm understanding (Block1038). The conversational agent proceeds by generating a generative voice output to confirm the prescription has been sent to the patient user's pharmacy and concludes the interaction (Block1042).

In accordance with certain aspects of the present disclosure, data from each turn of multi-turn interaction1000is stored in an application database (e.g., application database102ofFIG.1). The diabetes management application (e.g., diabetes management application120ofFIG.1) is configured to process the data to execute one or more operations; for example, provide a notification to the provider user that the patient user has an unresolved issue for follow-up or provide a prescription for the new medication to a third-party server (e.g., pharmacy).

An illustrative example of multi-turn interaction1000may be embodied as Conversation Flow10-1, as shown below.

Conversation Flow10-1

Patient user: “[wake word]”

Conversational Agent: “Based on your latest numbers, your diabetes is still not well controlled. To help better control your blood sugars, your doctor recommends that we start a once-a-day oral medication called metformin. Have you heard of this medication?”

Patient user: “Yes” [or “No” ]

Conversational Agent: “Metformin is one of the first line treatments for diabetes. The main side effect of metformin in 10% of patients can be stomach upset, but it reduces the risk of heart attacks by 50%. Do you have any questions about metformin?”

Patient user: “No”

Conversational Agent: Are you comfortable with your doctor starting metformin at this time?

Patient user: “Yes”

Conversational Agent: “Ok great, I'll notify your doctor so they can send a prescription to your pharmacy. Once you've picked this up and are ready to start, check back in with me. Do you understand?”

Patient user: “Yes”

An illustrative example of multi-turn interaction1000may be embodied in Conversation Flow10-2, as shown below.

Conversation Flow10-2

Conversational Agent: “Do you have any questions about starting semaglutide?”

Patient user: “Yes”

Conversational Agent: “What do you want to know?”

Patient user: “[specific question]”

Conversational Agent: “[knowledge base response]”

Conversational Agent: “Do you have any other questions?”

[repeat block until all questions have been answered]

An illustrative example of multi-turn interaction1000may be embodied in Conversation Flow10-3, as shown below.

Conversation Flow10-3

Conversational Agent: “Are you comfortable with starting semaglutide at this time?”

Patient user: “No”

Conversational Agent: “It's normal to feel apprehensive about starting semaglutide. What makes you feel uncomfortable about this?”

Patient user: “[reason for discomfort]”

Conversational Agent: “[knowledge base response]”

Conversational Agent: “Do you have any other questions about semaglutide?”

Patient user: “No”

Conversational Agent: “Now that we've talked about it a little, how do you feel about starting semaglutide?”

Patient user: “I still don't want it.”

Conversational Agent: “That's perfectly ok. I'll let your doctor know that you're not ready to start semaglutide.”

Referring now toFIG.11, a process flow block diagram of a multi-turn user interaction1100with a conversational agent of the voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100as shown and described inFIG.1. In certain embodiments, one or more steps or operations of multi-turn user interaction1100may be successive or sequential to one or more steps or operations of routine400, as shown and described inFIG.4, and/or one or more steps or operations of routine600, as shown and described inFIG.6, and/or one or more steps or operations of routine800, as shown and described inFIG.8. In certain embodiments, one or more steps or operations of multi-turn user interaction1100may be embodied within one or more steps or operations of routine900, as shown and described inFIG.9. In certain embodiments, one or more aspects of multi-turn user interaction1100may be driven by, or otherwise dependent upon, one or more outputs of multi-turn user interaction1000ofFIG.10. The one or more steps or operations in multi-turn user interaction1100may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, a session of multi-turn user interaction1100may be initiated upon a wake word utterance (Block1102) by a patient user to a smart speaker (e.g., smart speaker102ofFIG.1) configured to execute a conversational agent (e.g., conversational agent112ofFIG.1) of the voice-based system for management of type 2 diabetes. The conversational agent may process the wake word utterance as a session invocation (Block1104) and instantiate a session start (Block1106) of multi-turn user interaction1100. In accordance with certain aspects of the present disclosure, the conversational agent may be configured to generate a generative voice output according to a conversational AI model agenda item for initiating a new medication regimen for the patient user (Block1108). The conversational agent may proceed by generating a generative voice output to prompt the patient user to confirm receipt of the medication (Block1110). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to confirm receipt of the medication (Block1112). Multi-turn interaction1100may comprise a decision block1114for driving the next turn in the multi-turn interaction based on the content of the user response from block1112. If user response1112comprises a NO response (i.e., the patient user has not received the new medication), the conversational agent may proceed by generating a generative voice output to prompt the patient user to identify the issue with obtaining the new medication (Block1116). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to specify the issue with obtaining the new medication (Block1120). The conversational agent proceeds by generating a generative voice output to report the issue (e.g., to a practitioner user) and conclude the interaction (Block1122).

If user response1112comprises a YES response (i.e., the patient user confirms receipt of the new prescription), then the conversational agent proceeds by generating a generative voice output providing dosage instructions to the patient user per the clinical protocol (Block1118). The conversational agent proceeds by generating a generative voice prompt to confirm the patient user's understanding of the dosage instructions (Block1124). The patient user provides a voice response to the conversational agent in response to confirm the patient user's understanding of the dosage instructions (Block1126). Multi-turn interaction1100may comprise a decision block1128for driving the next turn in the multi-turn interaction based on the content of the user response from block1126. If user response1126comprises a NO response (i.e., the patient user does not understand the dosage instructions), the conversational agent proceeds by generating a generative voice output to prompt the user to identify questions with the dosage instructions (Block1132). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to identify questions with the dosage instructions (Block1134). The conversational agent proceeds by processing the user response from block1134according to the conversational AI model to determine the patient user's issue with the new medication and generates a generative voice output comprising a knowledge library response to the patient user's questions (Block1136). The conversational agent proceeds by generating a generative voice output to prompt the user to confirm whether the user's questions have been resolved (Block1138). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to confirm resolution (Block1142). Multi-turn interaction1100may comprise a decision block1144for driving the next turn in the multi-turn interaction based on the content of the user response from block1142. If user response1142comprises a NO response (i.e., the patient user's questions have not been resolved), then multi-turn interaction1100proceeds to block1132. If user response1142comprises a YES response (i.e., the patient user's questions have been resolved), then multi-turn interaction1100proceeds to block1130. If user response1126comprises a YES response (i.e., the patient confirms understanding of the medication dosing instructions), the conversational agent proceeds by generating a generative voice output to provide education of one or more side effects of the new medication to the patient user (Block1130). The conversational agent proceeds by generating a generative voice output to prompt the user to confirm understanding of the side effects of the new medication (Block1140). The patient user provides a voice response to the conversational agent in response to the generative voice output to confirm understanding of the side effects of the new medication (Block1146). Multi-turn interaction1100may comprise a decision block1148for driving the next turn in the multi-turn interaction based on the content of the user response from block1146. If user response1146comprises a NO response (i.e., the patient user does not understand the side effect), then multi-turn interaction1100proceeds to block1132. If user response1146comprises a YES response (i.e., the patient user understands the side effects), then conversational agent proceeds by generating a generative voice output to provide at least one check-in instruction and concludes the interaction (Block1150).

In accordance with certain aspects of the present disclosure, data from each turn of multi-turn interaction1100is stored in an application database (e.g., application database112ofFIG.1). The diabetes management application (e.g., diabetes management application110ofFIG.1) is configured to process the data to execute one or more operations; for example, provide a notification to the provider user that the patient user has started the new prescription.

An illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-1, as shown below.

Conversation Flow11-1

Patient user: “[wake word]”

Conversational agent: “Have you picked up the new prescription we sent called Glargine?”

Patient user: “Yes”

Conversational agent: “Great, based on your sugar readings, your doctor and I would like you to start taking 10 units of Glargine every night before you go to bed. Do you understand?”

Patient user: “Yes”

Conversational agent: “Great! The main side effect to look out for with Glargine is [side effect]. Check back in with me tomorrow. Do you understand?”

Patient user: “Yes”

Another illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-2, as shown below.

Conversation Flow11-2

Conversational agent: “Have you picked up the new prescription we sent called Lispro?”

Patient user: “Yes”

Conversational agent: “Great, based on your sugar readings, your doctor and I would like you to start taking 4 units of Lispro right before breakfast, lunch and dinner, every day. Do you understand?”

Another illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-3, as shown below.

Conversation Flow11-3

Patient user: “[wake word]”

Conversational agent: “Have you picked up the new prescription we sent for metformin immediate release?”

Patient user: “Yes”

Conversational agent: “Great, to start, take one 500 mg tablet of metformin immediate release every evening before bed. Do you understand?”

Patient user: “Yes”

Conversational agent: “Great! The main side effect to look out for with metformin is stomach upset. Our next phase starts Monday, I'll remind you. Feel free to check in before then.”

Another illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-4, as shown below.

Conversation Flow11-4

Conversational agent: “Have you picked up the new prescription we sent called Glargine?”

Patient user: “No”

Conversational agent: “Have you had any issues picking up the prescription?”

Patient user: “No”

Conversational agent: “Ok no worries, check back in when you've picked up the prescription. Do you understand?”

Another illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-5, as shown below.

Conversation Flow11-5

Conversational agent: “Have you had any issues picking up the prescription?”

Patient user: “Yes”

Conversational agent: “What was the issue?”

Patient user: “It wasn't at the pharmacy”

Conversational agent: “Sorry to hear that! I will inform your doctor right away. I'll let you know when this issue is resolved.”

Another illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-6, as shown below.

Conversation Flow11-6

Conversational agent: “Have you picked up the new prescription we sent called Glargine?”

Patient user: “No”

Conversational agent: “Have you had any issues picking up the prescription?”

Patient user: “Yeah, the pharmacist said they didn't have it.”

Conversational agent: “Sorry to hear that! [generative response]”

Another illustrative example of multi-turn interaction1100may be embodied as Conversation Flow11-7, as shown below.

Conversation Flow11-7

[Patient has Question about Side Effects]

Conversational agent: “The main side effect to look out for with Glargine is [side effect]. Check back in with me tomorrow. Do you understand?”

Patient user: “[question about side effects]”

Conversational agent: “[knowledge base response]”

Referring now toFIG.12, a process flow block diagram of a multi-turn user interaction1200for a conversational agent of the voice-based system for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, the voice-based system for management of type 2 diabetes comprises system100as shown and described inFIG.1. In certain embodiments, one or more steps or operations of multi-turn user interaction1200may be successive or sequential to one or more steps or operations of routine400, as shown and described inFIG.4, and/or one or more steps or operations of routine600, as shown and described inFIG.6, and/or one or more steps or operations of routine800, as shown and described inFIG.8. In certain embodiments, one or more steps or operations of multi-turn user interaction1200may be embodied within one or more steps or operations of routine900, as shown and described inFIG.9. In certain embodiments, one or more aspects of multi-turn user interaction1200may be driven by, or otherwise dependent upon, one or more outputs of multi-turn user interaction1000ofFIG.10and/or multi-turn user interaction1100ofFIG.11. The one or more steps or operations in multi-turn user interaction1200may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, a session of multi-turn user interaction1200may be initiated upon a wake word utterance (Block1202) by a patient user to a smart speaker (e.g., smart speaker102ofFIG.1) configured to execute a conversational agent (e.g., conversational agent122ofFIG.1) of the voice-based system for management of type 2 diabetes. The conversational agent may process the wake word utterance as a session invocation (Block1204) and instantiate a session start (Block1206) of multi-turn user interaction1200. In accordance with certain aspects of the present disclosure, the conversational agent may be configured to generate a generative voice output according to a conversational AI model agenda item for initiating a medication log and patient check-in (Block1208). The conversational agent may proceed by generating a generative voice output to prompt the patient user to confirm adherence to the assigned medication regimen and receive one or more medication log entries (Block1210). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to confirm adherence and/or provide one or more medication log entries (Block1212). Multi-turn interaction1200may comprise a decision block1214for driving the next turn in the multi-turn interaction based on the content of the user response from block1212. If user response1212comprises a NO response (i.e., the patient user has not adhered to the medication regimen or fails to provide one or more log entries), the conversational agent may proceed by generating a generative voice output to prompt the patient user to identify the issue with adherence and/or log entries (Block1216). The patient user provides a voice response to the conversational agent in response to the generative voice prompt to specify the adherence or medication log issue (Block1220). The conversational agent proceeds by generating a generative voice output to provide a knowledge base response according to the issue with adherence and/or log entries (Block1224). Multi-turn interaction1200may proceed to block1218. If user response1212comprises a YES response (i.e., the patient user is adherent and/or provides medication log data), then the conversational agent proceeds by generating a generative voice output confirming the user input(s) (Block1218). The conversational agent proceeds by generating a generative voice prompt to provide check-in and/or log instructions to the user (Block1226). In certain interactions, block1226may comprise a generative voice output to conclude the interaction with the patient user.

In certain interactions, multi-turn interaction1200may proceed according to a conversational AI model agenda prompt for titrating the patient user's medication dosage according to the clinical algorithm (Block1228). The conversational agent may proceed by generating a generative voice output comprising a titration instruction for the patient user's medication (Block1230) and a generative voice output to prompt the user to confirm understanding of the titration instruction (Block1232). The patient user provides a voice response to the conversational agent in response to confirm understanding of the titration instruction (Block1234). Multi-turn interaction1200may comprise a decision block1236for driving the next turn in the multi-turn interaction based on the content of the user response from block1234. If user response1234comprises a NO response (i.e., the patient user does not understand the titration instruction), then the conversational agent generates a knowledge base response based on the patient's issue (Block1238) and multi-turn interaction1200proceeds to block1232. If user response1234comprises a YES response (i.e., the patient user confirms understanding of the titration instruction), then the conversational agent proceeds by generating a generative voice output to provide check-in instructions for the next conversational interaction and concludes the interaction (Block1240).

In accordance with certain aspects of the present disclosure, data from each turn of multi-turn interaction1200is stored in an application database (e.g., application database122ofFIG.1). The diabetes management application (e.g., diabetes management application120ofFIG.1) is configured to process the data to execute one or more operations; for example, provide a notification to the provider user that the patient's prescription has been titrated according to the clinical protocol.

An illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-1, as shown below.

Conversation Flow12-1

Patient user: “[wake word]”

Conversational agent: “Thanks for checking in. Did you take your dose of Lantus last night?”

Patient user: “Yes”

Conversational agent: “Great, how many units did you take?”

Patient user: “10 units”

Conversational agent: “Great, based on the blood sugars logged by your CGM, your doctor and I would like you to increase your dose of Lantus to 12 units every night. Do you understand?”

Patient user: “Yes”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-2, as shown below.

Conversation Flow12-2

Patient user: “[wake word]”

Conversational agent: “Have you missed any medication doses whatsoever since we last caught up eight days ago?”

Patient user: “No”

Conversational agent: “You have been doing a great job logging your medication and we do not need to check in as frequently. Keep taking 10 U of Glargine every night. Let's check back in again sometime next week. If a sooner visit is needed, I will let you know. Do you understand?”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-3, as shown below.

Conversation Flow12-3

Patient user: “[wake word]”

Conversational agent: “Have you missed any medication doses whatsoever since we last caught up eight days ago?”

Patient user: “Yes”

Conversational agent: “In the last nine days, how many times have you forgotten to take your medication?”

Patient user: “Four times”

Conversational agent: “It's ok, it can be tough to remember to take your medications sometimes. Please increase your dose of Glargine to 11 units every night remembering the best you can. [I will also provide extra reminders to help out]. Check back in with me tomorrow. Do you understand?”

Alternate: Conversational agent: “It's ok, it can be tough to remember to take your medications sometimes. Please continue taking 10 U Glargine every night remembering the best you can. [I will also provide extra reminders to help out]. Check back in with me tomorrow. Do you understand?”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-4, as shown below.

Conversation Flow12-4

Conversational agent: “Did you take all three doses of lispro yesterday?”

Patient user: “Yes”

Conversational agent: “Did you take the same dose for breakfast, lunch and dinner?”

Patient user: “Yes”

Conversational agent: “What dose did you take before each meal?”

Patient user: “Three units”

Conversational agent: “I'm logging that you took three units before breakfast, lunch and dinner, is that correct?”

Patient user: “Yes”

Conversational agent: “You have been doing a great job logging your medication and we do not need to check in as frequently. Let's check back in again sometime next week. If a sooner visit is needed, I will let you know.”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-5, as shown below.

Conversation Flow12-5

Conversational agent: “Have you missed any medication doses whatsoever since we last caught up three days ago?”

Patient user: “No”

Conversational agent: “Great, keep taking 3 U of lispro before each meal. You're doing a great job! Let's catch up again next week. If a sooner visit is needed, I will let you know.”

[Alternate]

Conversational agent: “Great, I want you to increase your lispro to 4 U before each meal. Check back in with me tomorrow.”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-6, as shown below.

Conversation Flow12-6

Conversational agent: “Did you take all three doses of lispro yesterday?”

Patient user: “No”

Conversational agent: “Did you take your lispro with breakfast yesterday?”

Patient user: “No”

Conversational agent: “Did you take your lispro with lunch yesterday?”

Patient user: “No”

Conversational agent: “Did you take your lispro with dinner yesterday?”

Patient user: “Yes”

Conversational agent: “How many units did you take?”

Patient user: “Three units”

Conversational agent: “I'm logging that you took three units before dinner, is that correct?”

Patient user: “Yes”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-7, as shown below.

Conversation Flow12-7

Conversational agent: “Have you missed any doses of lispro whatsoever since we last caught up 9 days ago?”

Patient: “Yes”

Conversational agent: “In the last 9 days, about what percent of time have you been taking your lispro before meals?”

Patient user: “50%”

Conversational agent: “It's ok, it can be tough to remember to take your medications sometimes. Please continue taking 3 U lispro before each meal remembering the best you can. [I will also provide extra reminders to help out]. Check back in with me tomorrow.”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-8, as shown below.

Conversation Flow12-8

Patient user: “[wake word]”

Conversational agent: “Have you missed any doses of your metformin immediate release over the last 5 days?”

Patient user: “No”

Conversational agent: “Do you think you are experiencing any side effects from your metformin immediate release? Side effects to look out for include diarrhea, nausea, stomach aches, body aches, and feeling sick.”

Patient user: “No”

Conversational agent: “You're doing a great job logging in with me. Please continue 500 mg metformin immediate release every evening before bed. Do you understand?”

Patient user: “Yes”

Conversational agent: “Great, our next phase starts Monday, I'll remind you. Feel free to check in before then.”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-9, as shown below.

Conversation Flow12-9

Conversational agent: “Today, we're going to make an adjustment to your metformin. Your doctor and I would like you to start taking 500 mg metformin immediate release twice a day. Once in the morning, and once at night. Do you understand?”

Patient user: “Yes”

Conversational agent: “Great! Do you have enough pills in your current bottle to start twice a day metformin immediate release today?”

Patient user: “Yes”

Conversational agent: “Great. Go ahead and start taking twice a day metformin immediate release. I will send an updated prescription to your pharmacy within a business day for you to pick up. Our next phase starts in 2 weeks. Feel free to check in before then.”

Another illustrative example of multi-turn interaction1200may be embodied as Conversation Flow12-10, as shown below.

Conversation Flow12-10

Patient user: “[wake word]”

Conversational agent: “Hey! Have you picked up your new prescription for 500 mg metformin immediate release twice a day?”

Patient user: “Yes”

Conversational agent: “Have you started that prescription?”

Patient user: “Yes”

Conversational agent: “When did you start taking your new prescription?”

Patient user: “Today”

Conversational agent: “Great! Are you experiencing any new side effects?”

Patient user: “No”

Conversational agent: “Great, based on our treatment plan, you should continue metformin immediate release twice a day. Let's check back in two weeks when your next phase begins.”

Referring now toFIG.13, a process flow diagram of a voice-based method1300for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, method1300may be embodied as one or more functions or operations within system100, as shown and described inFIG.1, and/or system300, as shown and described inFIG.3. Method1300may comprise one or more steps or operations1302-1336for configuring one or more clinical protocols and algorithms for autonomous management and titration of at least one medication for management of type 2 diabetes in a patient user. The one or more steps or operations in method1300may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, method1300may comprise one or more steps or operations for configuring one or more user profiles for a diabetes management application executing on an application server (Step1302). The user profiles may include a patient user profile (e.g., associated with a patient with type 2 diabetes) and a practitioner user profile (e.g., associated with a primary care provider for the patient with type 2 diabetes). Method1300may comprise one or more steps or operations for configuring (e.g., with the application server) one or more data transfer interfaces between one or more client devices in a network (Step1304). The client devices may include a smart speaker for the patient user, a patient user device (e.g., a smart phone) and a practitioner user device (e.g., a desktop workstation). In certain embodiments, method1300may comprise one or more steps or operations for configuring one or more data transfer interfaces with one or more remote patient monitoring (RPM) devices associated with the patient user (Step1306). The RPM devices may include, for example, a CGM device, a wearable activity tracker, a blood pressure monitor, and the like. In certain embodiments, method1300may comprise one or more steps or operations for configuring one or more data transfer interfaces (e.g., APIs) with one or more external servers (Step1308). The external servers may include, for example, an EMR/EHR server, a LIMS server, a payor server, and the like. In accordance with certain aspects of the present disclosure, method1300may comprise one or more steps or operations for receiving and processing a plurality of user generated data (Step1312). The plurality of user generated data may include a plurality of inputs via a practitioner user interface for configuring one or more clinical protocols for management of type 2 diabetes for the patient user (e.g., pursuant to routine400, as shown inFIG.4). In certain embodiments, method1300may comprise one or more steps or operations for receiving and processing one or more data inputs from the one or more RPM devices (Step1314). For example, the application server may receive one or more sets of blood glucose data for the patient via the CGM device. In certain embodiments, method1300may comprise one or more steps or operations for receiving and processing one or more sets of clinical data for the patient; e.g., via the external servers (Step1316). The clinical data may comprise laboratory test results, electronic medical records, and the like.

In accordance with certain aspects of the present disclosure, method1300may comprise one or more steps or operations for configuring one or more clinical protocols for the patient user via the diabetes management application at the application server (Step1318). The one or more clinical protocols may comprise protocols for managing the treatment of type 2 diabetes in the patient user according to the practitioner user's configurations, the RPM data and the clinical data. Method1300may further comprise one or more steps or operations for configuring (e.g., via the diabetes management application at the application server) one or more clinical algorithms for initiation, titration and termination of one or more medications for treatment of type 2 diabetes in the patient user in accordance with the clinical protocol(s) (Step1320). Method1300may further comprise one or more steps or operations for configuring a conversational AI model via a conversational AI engine executing on the application server (Step1322). In certain embodiments, the conversational AI engine is configured to analyze one or more variables or objects of the one or more clinical algorithms to configure the conversational AI model.

In accordance with certain aspects of the present disclosure, method1300may comprise one or more steps or operations for initiating an interaction between a conversational agent and the patient user (Step1324). In accordance with certain embodiments, the conversational agent is instantiated via a smart speaker present in the patient user's home or other non-clinical setting. In certain embodiments, step1324is instantiated in response to the patient user speaking a wake word utterance to the smart speaker. Method1300may further comprise one or more steps or operations for generating one or more prompts via the conversational agent and outputting the prompts as computer voice outputs at the smart speaker (Step1326) and receiving one or more patient voice inputs at the smart speaker in response to the prompts (Step1328). In accordance with certain embodiments, steps1326-1328may be embodied as one or more multi-turn conversational interactions between the patient user and the conversational agent; for example, as shown and described inFIGS.10-12. Method1300may further comprise one or more steps or operations for processing the voice data received pursuant to step1328at the application server; e.g., according to the clinical algorithm(s)/protocol(s) (Step1330). In certain embodiments, method1300may further comprise one or more steps or operations for processing the RPM data (e.g., CGM data) and/or clinical data (e.g., lab test results) either concomitantly or independently with the voice data (Step1332). In accordance with certain aspects of the present disclosure, method1300may comprise one or more steps or operations for determining at least one prescription for the patient user (Step1334) and outputting a generative prompt as a computer voice output at the smart speaker to the patient user, wherein the generative prompt comprises dosage instructions for the prescription for the patient user (Step1336).

Referring now toFIG.14, a process flow diagram of a voice-based method1400for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, method1400may be embodied as one or more functions or operations within system100, as shown and described inFIG.1, and/or system300, as shown and described inFIG.3. Method1400may be successive or sequential to one or more steps or operations of method1300, as shown and described inFIG.13. Method1400may comprise one or more steps or operations1402-1422for autonomous management and titration of at least one medication for management of type 2 diabetes in a patient user. The one or more steps or operations in method1400may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, method1400may comprise one or more steps or operations for receiving one or more patient-generated inputs associated with management of type 2 diabetes in the patient user (Step1402). In certain embodiments, the patient-generated inputs comprise one or more voice inputs at the smart speaker in response to at least one conversational interaction with the conversational agent. The patient-generated inputs may comprise medication log data (e.g., how much medication the patient user took and when) as well as patient health data, such as blood glucose data, side effect data, questionnaire response data, and patient-reported general well-being data. Method1400may further comprise one or more steps or operations for receiving (e.g., at the application server) CGM data and/or RPM data for the patient user from the CGM device and/or other RPM devices (Step1404) and/or clinical data from the patient user via an external server or a client device (Step1406). Method1400may comprise one or more steps or operations for processing one or more of the patient-generated data, the CGM data, the RPM data and/or the clinical data according to the clinical algorithm at the application server (Step1408). In accordance with certain aspects of the present disclosure, method1400may comprise one or more steps or operations for determining whether to titrate one or more prescribed medication for the patient user according to the clinical algorithm (Step1410). If YES, then the diabetes management application titrates the prescribed medication for the patient user according to the clinical algorithm and updates the dosage instructions for the prescribed medication per the titration in the application database (Step1416). Method1400may proceed by executing one or more steps or operations for outputting a generative prompt as a computer voice output at the smart speaker to the patient user at the next conversational interaction, wherein the generative prompt comprises instructions for titrating the prescribed medication and a prompt to confirm the patient user's understanding/consent to the titrated dosage instructions (Step1418). Method1400may comprise one or more steps or operations for receiving and processing at least one voice response from the patient user via the smart speaker (Step1420) and confirming the titrated dosage instructions for the patient user in response to the at least one voice response (Step1422). If the output of step1410is NO, then the diabetes management application maintains the current dosage instructions for the prescribed medication in the application database (Step1412). Method1400may proceed by executing one or more steps or operations for outputting a generative prompt as a computer voice output at the smart speaker to the patient user at the next conversational interaction, wherein the generative prompt comprises instructions for maintaining the current dosage instructions for the prescribed medication (Step1414). In accordance with certain embodiments, one or more of steps1402-1422may be embodied as one or more multi-turn conversational interactions between the patient user and the conversational agent; for example, as shown and described inFIGS.10-12.

Referring now toFIG.15, a process flow diagram of a voice-based method1500for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, method1500may be embodied as one or more functions or operations within system100, as shown and described inFIG.1, and/or system300, as shown and described inFIG.3. Method1500may be successive or sequential to one or more steps or operations of method1300, as shown and described inFIG.13, and/or method1400, as shown and described inFIG.14. Method1500may comprise one or more steps or operations1502-1532for modifying or discontinuing one or more clinical protocol for autonomous management and titration of at least one medication for management of type 2 diabetes in a patient user. The one or more steps or operations in method1500may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure, method1500may comprise one or more steps or operations for receiving at least one patient-generated dataset associated with management of type 2 diabetes in the patient user (Step1502). In certain embodiments, the at least one patient-generated dataset may comprise one or more voice inputs at the smart speaker in response to at least one conversational interaction with the conversational agent. The at least one patient-generated dataset may comprise medication log data (e.g., how much medication the patient user took and when). The at least one patient-generated dataset may comprise physiological data such as blood glucose data, blood pressure data, EKG data, lab results, and the like. The patient-generated inputs may also comprise patient health data, side effect data, lab results, questionnaire response data, and general well-being data. Method1500may further comprise one or more steps or operations for receiving (e.g., at the application server) CGM data and/or RPM data for the patient user via the CGM device and/or other RPM devices (Step1504) and/or clinical data from the patient user via an external server or a client device (Step1506). Method1500may comprise one or more steps or operations for processing one or more of the patient-generated data, the CGM data, the RPM data and/or the clinical data according to the clinical algorithm at the application server (Step1508). In accordance with certain aspects of the present disclosure, method1500may comprise one or more steps or operations for determining whether to modify at least one prescription for the patient user according to the clinical algorithm (Step1510). If YES, then the diabetes management application modifies the prescription for the patient user according to the clinical algorithm and updates the prescription in the application database (Step1512). Method1500may proceed by executing one or more steps or operations for outputting a generative prompt as a computer voice output at the smart speaker to the patient user at the next conversational interaction, wherein the generative prompt comprises instructions for modifying a prescribed medication and a prompt to confirm the patient user's understanding/consent to the modified prescription (Step1514). Method1500may comprise one or more steps or operations for receiving and processing at least one voice response from the patient user via the smart speaker (Step1516) and confirming the patient user's understanding/consent to the modified prescription in response to the at least one voice response (Step1520). If the output of step1510is NO, then method1500may proceed by executing one or more steps or operations for determining whether to change the clinical protocol for the patient user according to one or more clinical parameters (Step1522). For example, the clinical protocol may be updated in response to the patient starting a new medication; e.g., transitioning from a prescription for metformin only to a prescription for metformin and another glycemic medication, such as semaglutide. If YES, method1500comprises one or more steps or operations for modifying or updating the clinical protocol for the patient user within the diabetes management application/database (Step1524) and updating the conversational AI model via the conversational AI engine per the protocol modification (Step1526). In accordance with certain aspects of the present disclosure, method1500may comprise one or more steps or operations for communicating a notification of the modification to the clinical protocol at a practitioner user interface of the diabetes management application (Step1532).

In accordance with certain aspects of the present disclosure, if the output of step1522is NO (i.e., the clinical protocol is not changed/modified), then method1500may proceed by executing one or more steps or operations for determining whether one or more of the at least one patient-generated dataset, the CGM/RPM data and/or the clinical data exceeds at least one threshold value for at least one safety trigger according to the clinical protocol (Step1528). In accordance with certain embodiments, the at least one safety trigger may comprise at least one condition under which continuing the clinical protocol may be unsafe for the patient. For example, the patient has experienced successive hypoglycemic events, the patient's blood pressure is in excess of a threshold value, or the patient has started another medication that is contraindicated with at least one of the medications under the current protocol. If YES, method1500may comprise one or more steps or operations for locking or stopping the clinical protocol per the diabetes management application (Step1530) and communicating a notification to the practitioner user interface of the diabetes management application to inform the practitioner user that the clinical protocol has been locked/stopped and the reasons therefor (Step1532).

Referring now toFIG.16, a process flow diagram of a voice-based method1600for management of type 2 diabetes is shown. In accordance with certain aspects of the present disclosure, method1600may be embodied as one or more functions or operations within system100, as shown and described inFIG.1, and/or system300, as shown and described inFIG.3. Method1600may comprise one or more steps or operations1602-1618for an artificially intelligent, voice-based method for prescribing, managing and administering at least one medication for management of type 2 diabetes (e.g., an SGLT-2 inhibitor drug and/or a GLP-1 agonist drug and/or a biguanide drug) to a patient. The one or more steps or operations in method1600may be performed in the order presented, in a different order, or simultaneously. Further, in some exemplary embodiments, some of the operations may be omitted, added, modified, skipped, or the like without departing from the scope of the invention.

In accordance with certain aspects of the present disclosure provide, method1600may comprise one or more steps or operations for receiving (e.g., from a practitioner user via a first client device) a plurality of user-generated inputs comprising a plurality of clinical parameters for management of type 2 diabetes in a patient (Step1602). The plurality of user-generated inputs may comprise one or more inputs at a graphical user interface of a practitioner instance of a diabetes management application (e.g., as shown inFIG.5). Method1600may proceed by executing one or more steps or operations for configuring (e.g., with at least one server communicably engaged with the first client device) a clinical algorithm for initiation and titration of a diabetes drug regimen for the patient according to the plurality of user-generated inputs (Step1604). In accordance with various aspects of the present disclosure, the diabetes drug may comprise one or more GLP-1 agonist drug and/or biguanide drug and/or SGLT-2 inhibitor drug. Method1600may proceed by executing one or more steps or operations for configuring (e.g., with the at least one server) a conversational AI model according to the clinical algorithm (Step1606). Method1600may proceed by executing one or more steps or operations for receiving (e.g., with the at least one server) a first set of blood sugar data or hemoglobin A1C data for the patient (e.g., via at least one continuous blood glucose monitoring device or glucometer) (Step1608). Method1600may proceed by executing one or more steps or operations for outputting (e.g., with a conversational agent) a first generative voice prompt to the patient according to the conversational AI model (Step1610). In accordance with certain embodiments, the conversational agent comprises a smart speaker communicably engaged with at least one server via a network interface. In accordance with certain embodiments, the first generative voice prompt comprises a medication initiation prompt for at least one medication for management of type 2 diabetes for the patient. In certain embodiments, the at least one medication comprises one or more GLP-1 agonist drug, biguanide drug and/or SGLT-2 inhibitor drug. Method1600may proceed by executing one or more steps or operations for receiving (e.g., with the conversational agent) a first voice input from the patient in response to the first generative voice prompt (Step1612). In accordance with certain embodiments, the first voice input comprises a response to the medication initiation prompt by the patient (i.e., confirmation of the prescription by the patient). Method1600may proceed by executing one or more steps or operations for processing (e.g., with the at least one server) the first set of blood sugar data or hemoglobin A1C data and the first voice input according to the clinical algorithm (Step1614). Method1600may proceed by executing one or more steps or operations for outputting (e.g., with the conversational agent) a second generative voice prompt according to the conversational AI model (Step1616). In certain embodiments, the second generative voice prompt comprises a first dosage instruction for the diabetes drug regimen for the patient according to the clinical algorithm. In accordance with certain aspects of the present disclosure, method1600may conclude upon the patient administering a first dose of the diabetes drug to himself or herself in accordance with the first dosage instruction (Step1618).

In accordance with certain aspects of the present disclosure, method1600may further comprise one or more steps or operations for establishing a data transfer interface between a continuous glucose monitor device or glucometer for the patient and the at least one server. In certain embodiments, the first set of blood sugar data or hemoglobin A1C data for the patient comprises data collected via the continuous glucose monitor device or glucometer. In accordance with certain aspects of the present disclosure, method1600may further comprise one or more steps or operations for outputting (e.g., with the conversational agent) a third generative voice prompt according to the conversational AI model, wherein the third generative voice prompt comprises a medication log prompt for the diabetes drug regimen; receiving (e.g., with the conversational agent) a second voice input from the patient in response to the third generative voice prompt, wherein the second voice input comprises medication log data for the patient; and recording (e.g., with the at least one server) the medication log data for the patient according to the second voice input. In accordance with certain aspects of the present disclosure, method1600may further comprise one or more steps or operations for receiving (e.g., with the at least one server) a second set of blood sugar data or hemoglobin A1C data for the patient; and analyzing (e.g., with the at least one server) the second set of blood sugar data or hemoglobin A1C data and the medication log data for the patient according to the clinical algorithm. In accordance with certain aspects of the present disclosure, method1600may further comprise one or more steps or operations for outputting (e.g., with the conversational agent) a fourth generative voice prompt according to the conversational AI model, wherein the fourth generative voice prompt comprises a second medication dosage instruction for the diabetes drug regimen for the patient according to the clinical algorithm; and administering, by the patient, a second dose of medication to the patient in accordance with the second medication dosage instruction. In accordance with certain aspects of the present disclosure, method1600may further comprise one or more steps or operations for outputting (e.g., with the conversational agent) a fifth generative voice prompt according to the conversational AI model, wherein the fifth generative voice prompt comprises a check-in prompt for the patient; receiving (e.g., with the conversational agent) a third voice input from the patient in response to the fifth generative voice prompt, wherein the third voice input comprises a response to the check-in prompt; and recording (e.g., with the at least one server) response data for the patient according to the third voice input.

Referring now toFIG.17, a processor-implemented computing device in which one or more aspects of the present disclosure may be implemented is shown. According to an embodiment, a processing system1700may generally comprise at least one processor1702, or processing unit or plurality of processors, memory1704, at least one input device1706and at least one output device1708, coupled together via a bus or group of buses1710. In certain embodiments, input device1706and output device1708could be the same device. An interface1712can also be provided for coupling the processing system1700to one or more peripheral devices, for example interface1712could be a PCI card or PC card. At least one storage device1714which houses at least one database1716can also be provided. The memory1704can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The processor1702could comprise more than one distinct processing device, for example to handle different functions within the processing system1700. Input device1706receives input data1718and can comprise, for example, a keyboard, a pointer device such as a pen-like device or a mouse, audio receiving device for voice-controlled activation such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, etc. Input data1718could come from different sources, for example keyboard instructions in conjunction with data received via a network. Output device1708produces or generates output data1720and can comprise, for example, a display device or monitor in which case output data1720is visual, a printer in which case output data1720is printed, a port for example a USB port, a peripheral component adaptor, a data transmitter or antenna such as a modem or wireless network adaptor, etc. Output data1720could be distinct and derived from different output devices, for example a visual display on a monitor in conjunction with data transmitted to a network. A user could view data output, or an interpretation of the data output, on, for example, a monitor or using a printer. The storage device1714can be any form of data or information storage means, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc.

In use, the processing system1700is adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, at least one database1716. The interface1712may allow wired and/or wireless communication between the processing unit1702and peripheral components that may serve a specialized purpose. In general, the processor1702can receive instructions as input data1718via input device1706and can display processed results or other output to a user by utilizing output device1708. More than one input device1706and/or output device1708can be provided. It should be appreciated that the processing system1700may be any form of terminal, server, specialized hardware, or the like.

It is to be appreciated that the processing system1700may be a part of a networked communications system. Processing system1700could connect to a network, for example the Internet or a WAN. Input data1718and output data1720could be communicated to other devices via the network. The transfer of information and/or data over the network can be achieved using wired communications means or wireless communications means. A server can facilitate the transfer of data between the network and one or more databases. A server and one or more databases provide an example of an information source. Thus, the processing computing system environment1700illustrated inFIG.17may operate in a networked environment using logical connections to one or more remote computers. The remote computer may be a personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above.

It is to be further appreciated that the logical connections depicted inFIG.17include a local area network (LAN) and a wide area network (WAN) but may also include other networks such as a personal area network (PAN). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. For instance, when used in a LAN networking environment, the computing system environment1700is connected to the LAN through a network interface or adapter. When used in a WAN networking environment, the computing system environment typically includes a modem or other means for establishing communications over the WAN, such as the Internet. The modem, which may be internal or external, may be connected to a system bus via a user input interface, or via another appropriate mechanism. In a networked environment, program modules depicted relative to the computing system environment1700, or portions thereof, may be stored in a remote memory storage device. It is to be appreciated that the illustrated network connections ofFIG.17are exemplary and other means of establishing a communications link between multiple computers may be used.

FIG.17is intended to provide a brief, general description of an illustrative and/or suitable exemplary environment in which embodiments of the below described present invention may be implemented.FIG.17is an example of a suitable environment and is not intended to suggest any limitation as to the structure, scope of use, or functionality of an embodiment of the present invention. A particular environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in an exemplary operating environment. For example, in certain instances, one or more elements of an environment may be deemed not necessary and omitted. In other instances, one or more other elements may be deemed necessary and added.

In the foregoing description, certain embodiments have been described with reference to acts and symbolic representations of operations that are performed by one or more computing devices, such as the computing system environment1700ofFIG.17. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processor of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains them at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner understood by those skilled in the art. The data structures in which data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while an embodiment is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that the acts and operations described hereinafter may also be implemented in hardware.

Embodiments may be implemented with numerous other general-purpose or special-purpose computing devices and computing system environments or configurations. Examples of well-known computing systems, environments, and configurations that may be suitable for use with an embodiment include, but are not limited to, personal computers, handheld or laptop devices, personal digital assistants, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network, minicomputers, server computers, game server computers, web server computers, mainframe computers, and distributed computing environments that include any of the above systems or devices.

Embodiments may be described in a general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. An embodiment may also be practiced in a distributed computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although any methods and materials similar or equivalent to those described herein can also be used in the practice or testing of the present invention, exemplary methods and materials are now described. All publications mentioned herein are incorporated herein by reference to disclose and describe the methods and/or materials in connection with which the publications are cited.

It must be noted that as used herein and in the appended claims, the singular forms “a”, “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a stimulus” includes a plurality of such stimuli and reference to “the signal” includes reference to one or more signals and equivalents thereof known to those skilled in the art, and so forth.

Any publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present invention is not entitled to antedate such publication by virtue of prior invention. Further, the dates of publication provided may differ from the actual publication dates which may need to be independently confirmed.

As will be appreciated by one of skill in the art, the present invention may be embodied as a method (including, for example, a computer-implemented process, a business process, and/or any other process), apparatus (including, for example, a system, machine, device, computer program product, and/or the like), or a combination of the foregoing. Accordingly, embodiments of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may generally be referred to herein as a “system.” Furthermore, embodiments of the present invention may take the form of a computer program product on a computer-readable medium having computer-executable program code embodied in the medium.

Any suitable transitory or non-transitory computer readable medium may be utilized. The computer readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. More specific examples of the computer readable medium include, but are not limited to, the following: an electrical connection having one or more wires; a tangible storage medium such as a portable computer diskette, a hard disk, a random-access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a compact disc read-only memory (CD-ROM), or other optical or magnetic storage device.

In the context of this document, a computer readable medium may be any medium that can contain, store, communicate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer usable program code may be transmitted using any appropriate medium, including but not limited to the Internet, wireline, optical fiber cable, radio frequency (RF) signals, or other mediums.

Computer-executable program code for carrying out operations of embodiments of the present invention may be written in an object oriented, scripted or unscripted programming language such as Java, Perl, Smalltalk, C++, or the like. However, the computer program code for carrying out operations of embodiments of the present invention may also be written in conventional procedural programming languages, such as the “C” programming language or similar programming languages.

Embodiments of the present invention are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products. It will be understood that each block of the flowchart illustrations and/or block diagrams, and/or combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer-executable program code portions. These computer-executable program code portions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a particular machine, such that the code portions, which execute via the processor of the computer or other programmable data processing apparatus, create mechanisms for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer-executable program code portions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the code portions stored in the computer readable memory produce an article of manufacture including instruction mechanisms which implement the function/act specified in the flowchart and/or block diagram block(s).

The computer-executable program code may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational phases to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the code portions which execute on the computer or other programmable apparatus provide phases for implementing the functions/acts specified in the flowchart and/or block diagram block(s). Alternatively, computer program implemented phases or acts may be combined with operator or human implemented phases or acts in order to carry out an embodiment of the invention.

As the phrase is used herein, a processor may be “configured to” perform a certain function in a variety of ways, including, for example, by having one or more general-purpose circuits perform the function by executing particular computer-executable program code embodied in computer-readable medium, and/or by having one or more application-specific circuits perform the function.

Embodiments of the present invention are described above with reference to flowcharts and/or block diagrams. It will be understood that phases of the processes described herein may be performed in orders different than those illustrated in the flowcharts. In other words, the processes represented by the blocks of a flowchart may, in some embodiments, be performed in an order other than the order illustrated, may be combined or divided, or may be performed simultaneously. It will also be understood that the blocks of the block diagrams illustrate, in some embodiments, merely conceptual delineations between systems and one or more of the systems illustrated by a block in the block diagrams may be combined or share hardware and/or software with another one or more of the systems illustrated by a block in the block diagrams. Likewise, a device, system, apparatus, and/or the like may be made up of one or more devices, systems, apparatuses, and/or the like. For example, where a processor is illustrated or described herein, the processor may be made up of a plurality of microprocessors or other processing devices which may or may not be coupled to one another. Likewise, where a memory is illustrated or described herein, the memory may be made up of a plurality of memory devices which may or may not be coupled to one another.

In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of” and “consisting essentially of” shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03.

While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of, and not restrictive on, the broad invention, and that this invention is not limited to the specific constructions and arrangements shown and described, since various other changes, combinations, omissions, modifications and substitutions, in addition to those set forth in the above paragraphs, are possible. Those skilled in the art will appreciate that various adaptations and modifications of the just described embodiments can be configured without departing from the scope and spirit of the invention. Therefore, it is to be understood that, within the scope of the appended claims, the invention may be practiced other than as specifically described herein.